>NSI are familiar and comfortable with the requester/provider standards terminology.
When this initiative began, one of the motivations was to develop an architectural framework for emerging and innovative concepts - not legacy formulations. This initiative should move beyond "familiar and comfortable" concepts.

At 12:39 PM 12/15/2009, Inder Monga wrote:

John,

Since we are revisiting the naming of the agents again (and again) -

I would like to voice support  for the current terminology of requester and provider agent by providing reference following diagram in the Web Services specifications that supports it. We should not let our experiences with the network/internet service provider color our judgement, as the applications that  we hope will use NSI are familiar and comfortable with the requester/provider standards terminology.

Web Services Architecture

W3C Working Group Note 11 February 2004

:
http://www.w3.org/TR/ws-arch/#gengag
<1385314.gif>



On Dec 15, 2009, at 8:13 AM, John Vollbrecht wrote:

We will have a call tomorrow at 9ET.  I suggest that this be the last 
call this year and that we restart calls either Jan 6 or Jan 13.  We 
can continue exchanges on skype and by email during this time.

I would like to try to have a skeleton document to start discussing by 
the middle of January and a document for OGF ready by early February.  
To do this we will have to make some assignments tomorrow or soon 
after, and probably work in smaller groups to come up with wording.

I have two issues that need to be decided for the document.

1) Naming of two sides of NSI interface.  We originally named these 
the requestor agent and network service agent.  This after significant 
discussion, especially about the fact that we should not use provider 
because it had connotations of the commercial providers.  Later we 
decided to go ahead and use the name provider because Network Service 
Agent was confusing with other names like Network Service Actor.  Also 
requestor and provider are terms used by others so seemed reasonable.  
The person who was most strongly against using the name provider was 
not on the call when we made the decision to change, and he continues 
to feel strongly that it is a bad name.

I think we made a decision not to use provider and should not change 
it without agreement from the parties involved in the decision.  
Therefore I would like to change the name of different sides of the 
NSI to something else.  Suggestions are a) requester agent- service 
agents,  b) client  agent - server agents.

We need to determine the name in order to make the document.  I think 
this is a NSI group decision, and I am hoping we can decide tomorrow.

2) There is an issue with naming end points on the transport resource 
controlled by an NSA.  To explain-

A NS Service agent  deals with connections between ports.   In NML 
terms the ports are part of a group of connected links and nodes.  The 
edge of the group might be a node or a link.  The problem is that in 
NML terms a link does not have a port.   So we need to have a 
different name for the end points of connections.  I think the options 
are make up a NSI name for the end points, or to have NML define a name.

A couple issues with possible solutions.  a) If NSI define a name for 
endpoints then it will have to map back to NML concept for port in 
case of node and I am not sure what for a link.  b) if NML were to say 
that both links and nodes have ports, then node ports would not be 
physical, or perhaps they would be defined by a connector at the 
physical layer.

I note that in G.800 both links and nodes have ports, and where ports 
are connected there is a point.  This seems useful when saying that 
segments are connections between ports and segments are concatenated 
at points.  I am not sure how it fits with other NML concepts.

This seems a decision that needs input from NML to decide. Probably 
this will take some discussion and we may have to have interim names 
till we decide.

--
I would like to talk about these on the call tomorrow. We can continue 
online if needed.

 I will send a second email will a proposed outline of a architecture 
doc and call info.

Let me know if you have suggestions for other agenda items.

John


_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

Joe Mambretti, Director                                           tel 312.503.0735
International Center for Advanced Internet Research   fax 312.503.0745
750 North Lake Shore Drive, Suite 600                            www.icair.org
Northwestern University, Chicago, Illinois 60611

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg