Peoples, Here is a summary of the decisions for the open WSDL items from today's call. Open Questions: 1. Should security attributes be removed from confirmed messages? Agreement was reached to remove security attributes from confirmation messages. They provide no additional value and we will place a requirement on the transport layer to authenticate and guarantee delivery to intended recipient. 2. Do we need security attributes in the NsaType as well as the common message body? We could not find a justification for additional security attributes in the NsaType if the transport layer is authenticating and validating message integrity. 3. Do we need to support a connectionId mapping to multiple child component connections for a single reservation? The Requestor NSA references a reservation using connectionId, however, this can map to multiple Provider NSA connectionId. Do we care about the children connection? At one point Jerry indicated he wanted a recursive query operation so that it pulls back all children connections down the tree as well. Currently, the WSDL assumes a summary model where the queried connectionId represents an aggregation of child states. Agreement was reached to leave this capability out of release 1.0 of the protocol specification. The global reservation ID can be used to query individual NSA for any associated connection segments if needed in the short term. 4. Can we change the connectionId to a URI and model as a globally unique Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122? Agreement was reached to change the connectionId to a URI type and require population with a Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122. 5. Do we make the renaming cosmetic change? Agreement was reached to perform the name changes as follows: Request a reservation: reserveRequest changes to reservationRequest and remains rsv.rq in the state machine. reserveConfirmed changes to reservationConfirmed and remains rsv.cf in the state machine. reserveFailed changes to reservationFailed and remains rsv.fl in the state machine. Terminate a reservation: cancelReservationRequest changes to terminateReservationRequest and changes to term.rq in the state machine. cancelReservationConfirmed changes to terminateReservationConfirmed and changes to term.cf in the state machine. cancelReservationFailed changes to terminateReservationFailed and changes to term.fl in the state machine. State machine change Canceling state changes to Terminating. John. On 2011-07-06, at 9:52 AM, John MacAuley wrote:
NSI'ers,
I have attached an updated set of WSDL and XSD files. There are still a few open items to solve before we can close on an official draft v1. Here is a list of changes and open questions.
1. Added generic OGF disclaimer to all files.
2. Namespace change based on GWD-C.083 http://www.ogf.org/documents/GFD.84.pdf
http://schemas.ogf.org/nsi/2011/07/connection/types http://schemas.ogf.org/nsi/2011/07/connection/interface http://schemas.ogf.org/nsi/2011/07/connection/service
3. Shortened the default SOAP endpoint URL to https://localhost:8443/nsi/ConnectionService_v1_0. This is typically ignored by all compilers.
4. Modified port names and bindings in service definition to have versioning information (i.e. ConnectionService_v1_0).
5. On or about May 9th we discussed removing the replyTo fields from the interface specification and agreed to use the nsaAddress field to identify the SOAP endpoint. I did not make this change for two reasons:
a) Jerry's request to keep the XSD file transport protocol free would be violated if we decided to stick a transport specific address in the field. Many of us had planned on using our NSA's URN within this field anyways. b) Jerry has requested we stop using nsaAddress and change it to a more abstract nsaId.
This will allow us to keep the CS payload separate from the Web Services transport.
6. Added the forcedEnd notification needed as part of the new state machine.
7. Modified all security attributes to use the saml:attribute element as per Mary's security proposal. Now import http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd. Created the SubjectAttributeSequenceType to hold these attributes.
8. Updated state machine states in ConnectionStateType.
9. Added ConnectionStateType to the GenericFailedType to relate current state machine.
10. Fixed a non UTF-8 character issue with a comment "STP’s".
11. Renamed techSpecAttrs in ServiceParametersType to serviceAttrs.
12. Renamed techSpecAttrs in ServiceTerminationPointType to stpSpecAttrs.
Open Questions: 1. Should security attributes be removed from confirmed messages?
2. Do we need security attributes in the NsaType as well as the common message body?
3. Do we need to support a connectionId mapping to multiple child component connections for a single reservation? The Requestor NSA references a reservation using connectionId, however, this can map to multiple Provider NSA connectionId. Do we care about the children connection? At one point Jerry indicated he wanted a recursive query operation so that it pulls back all children connections down the tree as well. Currently, the WSDL assumes a summary model where the queried connectionId represents an aggregation of child states.
4. Can we change the connectionId to a URI and model as a globally unique Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122?
5. Do we make the renaming cosmetic change?
Request a reservation: reserveRequest -> reservationRequest reserveConfirmed -> reservationConfirmed reserveFailed -> reservationFailed
Terminate a reservation: cancelReservationRequest -> terminateReservationRequest cancelReservationConfirmed -> terminateReservationConfirmed cancelReservationFailed -> terminateReservationFailed
State machine change Terminating (Canceling) – a terminateReservationRequest (cancelRequest) has been sent and a cancelation is ongoing
John. <July.5.2011.Specification.zip>
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg