Hi Guy - This is a really nice aggregation of what we have from before. I think we can get this worked out over the next couple months if people have time. I am not sure how we want to proceed with editing this - I am not sure it is quite ready for online editing, but it is close. I have some comments below - let me know if you would like them in the doc instead. In Section 2 - doc says " The protocol includes a set of defined primitives that are a intended to provide the control necessary to manage Connections." I think primitive is not quite the right word - perhaps command sequences or something like that. Also, control might be replaced with "ability". and the command sequences might be ReserveConnection/ProvisionConnection/CancelConnection (replace "Request" with "Connection" Also, I think we need a Notify message/ sequence. Perhaps there is a way around this - I am not sure. The connection state doesn't seem right. I think there should be state for reservation sequence, for provision sequence and cancel sequence. I think a state for the connection as a whole is also a good idea. -- I think the intent of this sequence is for a single network (i.e. not multi-NSA), so a multi-NSA state is also needed at some (probably later) point. Section 3 - I think we decided (though not without lots of discussion, so I may be wrong) that connection was not necessarily data, that it could be done by switching waves, or fibers (with mirrors). If so we need to define connection a bit more abstractly. If not we need to be clear in the group about what we think this service supports. I am happy either way. In relation to this, saying data stream must be preserved would not be correct in the more abstract interpretation of connection. Section 4 I like the lifecycle diagram for the connection as a whole. Some edits to bring it closer to the front of the section might be good. Section 9 (path object) I think this would be better after section 10 which describes mutli-network pathfinding (which presumably generates paths). --- A couple subjects that I think should be in this doc some specifics of delegation of resources from one NSA to another maintenance of resource state in NSAs, particularly broker NSAs, during lifecycle of a connection tiyng authorization sequence to path sequence [authorization is tied to trust, path to topology] description of how federated networks relate to each other description of topology of federated network describe what is in a path object and how it relates to NSAs -- I hope this helps -- John On Aug 9, 2010, at 11:51 AM, Guy Roberts wrote:

Hello All,

I have tidied up the remaining parts of the NSI architecture document and created a new ‘Connection Service’ document:

http://forge.gridforum.org/sf/go/doc16045?nav=1

Please take a look in preparation for Wednesday’s call.

The following is dial-in information for Wednesday’s NSI call:

Time: 7:30 PDT 10:30 EDT, 15:30 BST, 16:30 CEST, 23:30 JST

Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180

Agenda,

Review the draft Connection Service Informational document.

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