[Nsi-wg] Comments on NSI CS WSDLs and XSD

[John MacAuley]

Chin,

Thank you and your team for taking the time to go through the WSDL and XSD.  Comments below.

On 2011-05-02, at 7:06 PM, Chin Guok wrote:

> Feedback on the NSI WSDL's:
> 
> NSI Connection Interface WSDL
> -------------------------------------------
> - The names of messages should be discussed. It is suggested that 
> opposites be chosen to make the function of the messages more obvious 
> for example Provision and Unprovision, Reserve and Unreserve, etc. In 
> any case, before we finalize the 1.0 specification, some more thought 
> needs to be put into the naming.

There was a long discussion in Hong Kong lead by Inder on this exact topic.  People found it hard to come up with symmetric names.  For example, "unprovision" is technically incorrect as "deprovision" is the commonly used term, while "unreserve" is the correct symmetric term for "reserve".  why don't we discuss this one on the conference call on Wednesday?

> 
> - The replyTo in the NSI CS request message contains the callback SOAP 
> address. Does it places constraint if the RA is behind a NAT'ed address? 
> We may need implementation guidance on this scenario [there are multiple 
> options like SOAP proxy, Broker etc.]

SOAP is definitely not NAT/Firewall/Proxy safe as addresses can be embedded in the headers and message payload.  This is similar to many protocols that are not supported directly by the hardware.  An inherent problem with event driven HTTP communications if a connection is not left up from client to server for asynchronous message delivery.  This is why HTTP application protocols like REST use long duration GET or long poll mechanisms to pass through the firewall in a single direction.

If you have a SOAP proxy or broker that is SOAP aware then we would want to use WS-Addressing to handle the routing based on the SOAP header.  In this case, replyTo and messageID are in the header and the proxy will know how to route them.

The other option is to configure your NSA with the IP address of the Firewall/HTTP proxy so that it provides this address in the SOAP replyTo field, then add the URL mapping to the proxy back through to the NSA.

Do we want to move to WS-Addressing for asynchronous communications that may be supported by your SOAP proxy?

> 
> - transaction ID: the soft guidance on the transaction ID does not help 
> since if there is a possibility that the ID is not global, the software 
> cannot take advantage of it if it is globally unique. The group should 
> decide on one or the other i.e. either mandate it Global or do not 
> provide any guidance (other than the fact that it should be locally 
> unique).
> 

So can I assume that this is in the context of the transactionID generated by OSCARS and not a concern that the UUID RFC is incorrect and cannot generate a unique transactionID?  WS-Addressing uniquely identifies each SOAP message using the same mechanism and is  globally unique.

> - Notification message for out of bound messaging from the PA to RA 
> should be considered as a way for the network to notify the RA of 
> exceptions. A Notify message with restrictions on CS Service oriented 
> notifications only should be put in place as a general notification 
> service is not yet defined, and may not be standardized for a while.

I will not comment on this and leave it to the team on Wednesday.

> 
> NSI Connection Types XSD
> ---------------------------------------
> 
> - Need to understand better the rationale between choosing the current 
> format of NsiExceptionType as a concatenation string with variables. 
> Wouldn't key/value pairs be more useful and easily allow interpretation 
> at both ends through standardized key-value pairs?
> 

If you feel that this would be better I am in no way attached to this mechanism.  I took it from the 3GPP ParlayX standards.

> - nsaAddress should be defined. Can it be used as a callback URI? It 
> will be nice to have it as the same format as the replyTo address above.

For this address I had hoped to put in an official OGF URN for the NSA (although it could be any valid format).  Putting the web services interface address in here is possible, but would this be the callback or the request interface (do we want the flexibility to have them different?).  We would need a way to make it protocol implementation independent (which we can with a URI) so we maintain the current XSD abstraction from the WSDL.

> 
> - Bandwidth should not be mandatory. This is a connection service, 
> bandwidth should be optional.

Okay, I will make it optional.

> 
> - For the NSI Message Types, the ReserveType (for example), stands for 
> both ReserveRequest and ReserveResponse. Should there be a ResponseType 
> that is different?

Can you give me the specific XSD issue you have.  I can't seem to find what you are referencing.  

> - Can names of the states as defined in ConnectionStateType be 
> "normalized" to better reflect the messages, e.g. there is canceling, 
> but terminated is used instead of canceled
> 

If someone wants to update the state machine and send me the corrected states I will update the enumeration.

> 
> Thanks
> ESnet OSCARS developers
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110502/145a9518/attachment.bin