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