Hi John, Sorry for not getting back sooner, some comments inline. On 5/2/11 5:57 PM, John MacAuley wrote:
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?
We think we can get by without using WS-Addressing. As you have pointed out, there are other ways to work around the NAT/Firewall/Proxy issue, and we are fine with alternatives.
- 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.
Actually it's more a matter of wording. We think that this should be in a separate document (e.g. BCP) that outlines the discussions we've had to support the idea of unique transactionIDs.
- 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.
The reason we've brought this up is that we have not come up with a practical use case that would have the callback and request interface being different.
- 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. Sorry about that. Just to clarify, ReservationRequestType and ReservationInfoType both the same ReservationGroup. We see that the ReservationRequestType may differ from the ReservationInfoType (i.e. the request may have a bunch of information that the confirm may have, or vice-versa)
- 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.
We should discuss this is a larger group to see if other folks have an issue with it. Thanks again John! - Chin
Thanks ESnet OSCARS developers _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg