[Nsi-wg] NSI - Call Issues

Tue Dec 15 12:46:23 CST 2009

 >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>http://www.w3.org/TR/ws-arch/#gengag
>[]
>
>
>
>
>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
>><mailto:nsi-wg at ogf.org>nsi-wg at ogf.org
>>http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
>_______________________________________________
>nsi-wg mailing list
>nsi-wg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20091215/3bdabb91/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1385314.gif
Type: image/gif
Size: 8682 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20091215/3bdabb91/attachment-0001.gif