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

[Chin Guok]

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.

- 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.]

- 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).

- 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.

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?

- 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.

- Bandwidth should not be mandatory. This is a connection service, 
bandwidth should be 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 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


Thanks
ESnet OSCARS developers