Hey John-

I concur with the justification for versioning, but I have several concerns with your proposed method:

The NSI layer protocol itself should be self consistent without requiring SOAP or WSDLs or XML namespaces. - i.e. IF we want an NSA to recognize different versions of a peer NSA, we should specify this in the NSI layer - not SOAP to do this.   So the version identifier should be an explicit part of the NSI layer message - not the SOAP or some other implementation specific mechanism.

IMO, feature negotiation is a more complex task - you need to determine if feature negotiation is an available feature before you can use it to negotiate features:-) And again, if these are NSI features, then NSI should negotiate them - not other underlying layers that do not have any insight into NSI functional comaptibilities.

Also, with versioning, an NSA will possibly have several versions it has to portray depending upon the segmentation it chose. If we assume the highest common version is always used, we may find a single service tree builds in one version, but then a leaf node has an older version and all the parental NSAs in the service tree need to reprocess the request using an older version. ...(I am not quite sure how this version selection should be handled.. but it is a problem we need to think through before deciding about feature negotiation. )

---IMO, the simplest way to do the versioning is to have a simple version ID in the NSI primitive message. Maybe attached to the Sending NSAID. And a "incompatible version" error message if one of the NSAs cannot speak a compatible version.
---We could alternatively put the version identifier in the NSA topology object along with the CSproviderEndpoint. e.g. CSproviderVersion "2.0" or something.   This topology based versioning has the added benefit that an NSA can learn the version of a candidate path NSA *before* sending the first message and adjust its dialect accordingly.
---We could have a separate version negotiation protocol...   I think this is overkill at this time.

The NSI protocol layer should have its own explicit means of identifying the version of the primitive it just sent or received. We really have to be careful to not link "NSI Features" to non-NSI layer implementation specifics.

Thoughts?
Jerry

On 6/27/12 3:49 PM, John MacAuley wrote:

Peoples,

I had hoped to get time in Delft to go over the new interface Discovery service but we ran out of time.  I have submitted the WSDL and supporting schema to the repository and attached a short slide package discussing the queryServices() operation.  Please have a look and provide comments.  If there are specific schema changes you would like to see please create an issue in code.google.com to track them.

The new interface can be viewed @ http://code.google.com/p/ogf-nsi-project/source/browse/#svn%2Ftrunk

Thank you,
John.

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