[Nsi-wg] Comments on NSI CS WSDLs and XSD
Chin Guok
chin at es.net
Mon May 2 18:06:30 CDT 2011
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
More information about the nsi-wg
mailing list