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
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 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 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@ogf.org>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
I agree with Joe that this is a new concept. I also think we have dealt with this naming issue for a while, and I think it important in how the effort is perceived by the outside community. We also spent a long time discussing this during the time when Inder wasn't able to participate so he has not heard all the discussion. The original decision to call each side of the interface a agent, to call one side the requester agent (rather than user) and to call the other side a Network Service agent (not provider) was one we all agreed on. We changed it, in my opinion, because the name was getting confused with other names such that discussion became confusing - and the fact that WS uses requester - provider seemed the only reasonable solution - though at the time I noted that we needed to get approval of this from the original participants. We didn't get approval of original participants, so we need to rethink this. We have also changed other names in the meantime, so for me going back to requester agent and service agent on Network Service Interface seems quite reasonable. I agree that we have talked about this quite a lot - way more than I wish. I would like to make a decision, hopefully tomorrow, to 1) go back to the original name, 0r 2) to pick a different name, or 3) to stick with the name we have. John On Dec 15, 2009, at 1:46 PM, Joe Mambretti wrote:
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: . . .
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
On Dec 15, 2009, at 11:46 AM, Joe Mambretti wrote:
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.
I agree that we should move forward beyond the familiar and comfortable, especially in the research group. However, I believe new terminology should only be needed for new concepts. Existing concepts should use standards based terminology as much as possible so the solutions we come up with can be understood by the widest groups of people and also to aid in the adoption of these protocols into existing applications and tools. jeff
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
participants (4)
-
Inder Monga -
Jeff W.Boote -
Joe Mambretti -
John Vollbrecht