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.
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
Okay, i changed my mind. terminateReservationRequest is just too long. I am going to shorten it to terminateRequest. No need to update the state machine. I will just do it in the WSDL. John. On 2011-07-06, at 12:31 PM, John MacAuley wrote:
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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Guy, I remember Jerry bringing this up in a call a couple of weeks ago and thought I would ask if we did anything to clarify or change the definitions. In the WSDL at the moment we have the following in all request, confirmed, and failed messages: <xsd:element name="requestorNSA" type="xsd:anyURI" /> <xsd:element name="providerNSA" type="xsd:anyURI" /> The issue brought up was the confusion between who is requestor, and who is a provider in a message exchange. I have captured some rules below to describe my interpretation, however, do we think it might be better to change these to toNSA and fromNSA? Not too sure... So in a request message from a parentNSA in an RA role to a childNSA in a PA role we would have: requestorNSA = parentNSA providerNSA = childNSA I assume in the response we would also have: requestorNSA = parentNSA providerNSA = childNSA So the simple rules for an NSA implementor are: 1. My NSA identifier in requestorNSA when sending a request to children, and the child NSA identifier in providerNSA. 2. My NSA identifier in providerNSA when sending a confirmed/failed to a parent, and the parent NSA identifier in requestorNSA. Now for the interesting bits: 1. Any pair of NSA can be both a parent NSA can be a child NSA to each other. In this scenario we would use the appropriate roles to cover when we are a parent or child. 2. The forcedEnd message is a request sent from a child to a parent. In this case the child propagating the forcedEnd message up the tree would put its NSA identifier in providerNSA and the parent in requestorNSA even though semantically this is a request message. 3. The Query message is also an interesting case since it can not only be sent to children, but from a child NSA to a parent NSA to retrieve information about common reservations. I would recommend the following rules to keep the proper context with respect to a reservation: 1. My NSA identifier in requestorNSA when sending to a child of a reservation, and the child NSA identifier in providerNSA. 2. My NSA identifier in providerNSA when sending to a parent were I am a child in the reservation, and the parent NSA identifier in requestorNSA. Comments? Discussion? John.
Peoples, I have updated the WSDL and XML schema based on the decisions reached at Wednesday's meeting. The only remaining item I need to get done, and I think it can wait until after OGF, is to add the security policies to the WSDL so we can sign the messages to validate authenticity. This will not impact the core XML schema. Here are the changes in this version: 1. Cosmetic change to operation primitive names: 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: cancelRequest changes to terminateRequest and changes to term.rq in the state machine. cancelConfirmed changes to terminateConfirmed and changes to term.cf in the state machine. cancelFailed changes to terminateFailed and changes to term.fl in the state machine. State machine change Canceling state changes to Terminating. 2. Removed the NsaType and changed requestorNSA and providerNSA to be of type anyURI. This removes the additional per-NSA security attributes. 3. Changed connectionId definition to be an anyURI and stated it must be a Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122. 4. Removed security attributes from confirmed messages. 5. Extended the NsiExceptionType to use an attribute type/value pairs for added flexibility. 6. Added simpleTypes for NsaIdType, GlobalReservationIdType, ConnectionIdType, and uuidType so there is a single location requiring modification if we decided to change the types. John.
Hi John, I think requester and provider operations should be separated as attachments. (I have not checked its grammar.) Because a requester module and a provider module may be different. And I have a cosmetic suggestion. Could you use spaces, instead of 4-character tab? I think you use 4-character tab in the wsdl and schema files, but it is not general for editors, such as emacs and vi. Thanks, Atsuko 2011/7/8 John MacAuley <john.macauley@surfnet.nl>:
Peoples,
I have updated the WSDL and XML schema based on the decisions reached at Wednesday's meeting. The only remaining item I need to get done, and I think it can wait until after OGF, is to add the security policies to the WSDL so we can sign the messages to validate authenticity. This will not impact the core XML schema.
Here are the changes in this version:
1. Cosmetic change to operation primitive names:
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: cancelRequest changes to terminateRequest and changes to term.rq in the state machine. cancelConfirmed changes to terminateConfirmed and changes to term.cf in the state machine. cancelFailed changes to terminateFailed and changes to term.fl in the state machine.
State machine change Canceling state changes to Terminating.
2. Removed the NsaType and changed requestorNSA and providerNSA to be of type anyURI. This removes the additional per-NSA security attributes.
3. Changed connectionId definition to be an anyURI and stated it must be a Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122.
4. Removed security attributes from confirmed messages.
5. Extended the NsiExceptionType to use an attribute type/value pairs for added flexibility.
6. Added simpleTypes for NsaIdType, GlobalReservationIdType, ConnectionIdType, and uuidType so there is a single location requiring modification if we decided to change the types.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
I am good with these changes and will issue a new update. I have a constant battle with spaces versus tabs. I just went back to tabs :-) ----- Original Message -----
From: "Atsuko Takefusa" <takefusa@acm.org> To: "John MacAuley" <john.macauley@surfnet.nl> Cc: "nsi-wg@ogf.org WG" <nsi-wg@ogf.org> Sent: Tuesday, July 12, 2011 10:57:31 AM Subject: Re: [Nsi-wg] Updated NSI WSDL - July 7th 2011
Hi John,
I think requester and provider operations should be separated as attachments. (I have not checked its grammar.) Because a requester module and a provider module may be different.
And I have a cosmetic suggestion. Could you use spaces, instead of 4-character tab? I think you use 4-character tab in the wsdl and schema files, but it is not general for editors, such as emacs and vi.
Thanks,
Atsuko
2011/7/8 John MacAuley <john.macauley@surfnet.nl>:
Peoples,
I have updated the WSDL and XML schema based on the decisions reached at Wednesday's meeting. The only remaining item I need to get done, and I think it can wait until after OGF, is to add the security policies to the WSDL so we can sign the messages to validate authenticity. This will not impact the core XML schema.
Here are the changes in this version:
1. Cosmetic change to operation primitive names:
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: cancelRequest changes to terminateRequest and changes to term.rq in the state machine. cancelConfirmed changes to terminateConfirmed and changes to term.cf in the state machine. cancelFailed changes to terminateFailed and changes to term.fl in the state machine.
State machine change Canceling state changes to Terminating.
2. Removed the NsaType and changed requestorNSA and providerNSA to be of type anyURI. This removes the additional per-NSA security attributes.
3. Changed connectionId definition to be an anyURI and stated it must be a Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122.
4. Removed security attributes from confirmed messages.
5. Extended the NsiExceptionType to use an attribute type/value pairs for added flexibility.
6. Added simpleTypes for NsaIdType, GlobalReservationIdType, ConnectionIdType, and uuidType so there is a single location requiring modification if we decided to change the types.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST
Hello, I would like to point out that now there are two ReservationRequestType (org.ogf.schemas.nsi._2011._07.connection._interface and org.ogf.schemas.nsi._2011._07.connection.types packages). Other thing is, I would get rid of the 'V10' from the ConnectionPortV10 interface name. And the last thing is that downloading referenced schemas takes even longer today than yesterday (up to 6 minutes), so maybe they should be distributed altogether with the NSI wsdls. Br michal -----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John MacAuley Sent: Friday, July 08, 2011 3:56 AM To: nsi-wg@ogf.org WG Subject: [Nsi-wg] Updated NSI WSDL - July 7th 2011 Peoples, I have updated the WSDL and XML schema based on the decisions reached at Wednesday's meeting. The only remaining item I need to get done, and I think it can wait until after OGF, is to add the security policies to the WSDL so we can sign the messages to validate authenticity. This will not impact the core XML schema. Here are the changes in this version: 1. Cosmetic change to operation primitive names: 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: cancelRequest changes to terminateRequest and changes to term.rq in the state machine. cancelConfirmed changes to terminateConfirmed and changes to term.cf in the state machine. cancelFailed changes to terminateFailed and changes to term.fl in the state machine. State machine change Canceling state changes to Terminating. 2. Removed the NsaType and changed requestorNSA and providerNSA to be of type anyURI. This removes the additional per-NSA security attributes. 3. Changed connectionId definition to be an anyURI and stated it must be a Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122. 4. Removed security attributes from confirmed messages. 5. Extended the NsiExceptionType to use an attribute type/value pairs for added flexibility. 6. Added simpleTypes for NsaIdType, GlobalReservationIdType, ConnectionIdType, and uuidType so there is a single location requiring modification if we decided to change the types. John.
I have updated the schema to make the imports local. It will be in the next version I send out. I will look at the duplicate types. Read the attached document with respect to V10. It is an interesting approach I have never tried before. I will make a slide for the WSDL discussion this weekend. I am good removing it, but we should discuss John. On 2011-07-14, at 9:58 AM, Michał Balcerkiewicz wrote:
Hello,
I would like to point out that now there are two ReservationRequestType (org.ogf.schemas.nsi._2011._07.connection._interface and org.ogf.schemas.nsi._2011._07.connection.types packages). Other thing is, I would get rid of the 'V10' from the ConnectionPortV10 interface name. And the last thing is that downloading referenced schemas takes even longer today than yesterday (up to 6 minutes), so maybe they should be distributed altogether with the NSI wsdls.
Br michal
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John MacAuley Sent: Friday, July 08, 2011 3:56 AM To: nsi-wg@ogf.org WG Subject: [Nsi-wg] Updated NSI WSDL - July 7th 2011
Peoples,
I have updated the WSDL and XML schema based on the decisions reached at Wednesday's meeting. The only remaining item I need to get done, and I think it can wait until after OGF, is to add the security policies to the WSDL so we can sign the messages to validate authenticity. This will not impact the core XML schema.
Here are the changes in this version:
1. Cosmetic change to operation primitive names:
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: cancelRequest changes to terminateRequest and changes to term.rq in the state machine. cancelConfirmed changes to terminateConfirmed and changes to term.cf in the state machine. cancelFailed changes to terminateFailed and changes to term.fl in the state machine.
State machine change Canceling state changes to Terminating.
2. Removed the NsaType and changed requestorNSA and providerNSA to be of type anyURI. This removes the additional per-NSA security attributes.
3. Changed connectionId definition to be an anyURI and stated it must be a Universally Unique Identifier (UUID) URN as per ITU-T Rec. X.667 | ISO/IEC 9834-8:2005 and IETF RFC 4122.
4. Removed security attributes from confirmed messages.
5. Extended the NsiExceptionType to use an attribute type/value pairs for added flexibility.
6. Added simpleTypes for NsaIdType, GlobalReservationIdType, ConnectionIdType, and uuidType so there is a single location requiring modification if we decided to change the types.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi, I mean they are of diffrent type with the same name, and if this is your intention, thats ok. br michal Quoting John MacAuley <john.macauley@surfnet.nl>:
I have updated the schema to make the imports local. It will be in the next version I send out.
I will look at the duplicate types.
Read the attached document with respect to V10. It is an interesting approach I have never tried before. I will make a slide for the WSDL discussion this weekend. I am good removing it, but we should discuss
John.
---------------------------------------------------------------- This message was sent using PSNC Webmail system.
Got it. Different name spaces but will cause issues with bulk importing in Java. I will have a look at renaming it. John. On 2011-07-14, at 3:52 PM, michalb@man.poznan.pl wrote:
Hi,
I mean they are of diffrent type with the same name, and if this is your intention, thats ok.
br michal
Quoting John MacAuley <john.macauley@surfnet.nl>:
I have updated the schema to make the imports local. It will be in the next version I send out.
I will look at the duplicate types.
Read the attached document with respect to V10. It is an interesting approach I have never tried before. I will make a slide for the WSDL discussion this weekend. I am good removing it, but we should discuss
John.
---------------------------------------------------------------- This message was sent using PSNC Webmail system.
Hi On Wed, 6 Jul 2011, John MacAuley wrote:
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.
Hmm... this pulls in http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd which again pulls http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd Which is a dead link. This causes my client to hang, and crash after a timeout. This might be the client which does not know about xmldsig magic, or an error in the schema, but I don't think we should have a schema which links to something which does not exist (I doubt my client is the only library which has this behaviour). Also it seems the default link has switched to https (which is good), but I find usage of TLS AND SAML at the same time to be a bit odd. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility.
7. Modified all security attributes to use the saml:attribute element as
Hello, Similar to Henrik, we (PSNC) are also experiencing the problem (at generating sources stage): Metadata contains a reference that cannot be resolved: 'http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd'. There was an error downloading 'http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd'. The underlying connection was closed: The connection was closed unexpectedly. Although from time to time, we are lucky enough to get referenced schemas and source code is generated (but takes over 3 minutes to accomplish this task, so as Henrik pointed out, it means timeout in a client). Br michal -----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Henrik Thostrup Jensen Sent: Wednesday, July 13, 2011 4:29 PM To: nsi-wg@ogf.org WG Subject: Re: [Nsi-wg] Updated NSI WSDL Hi On Wed, 6 Jul 2011, John MacAuley wrote: 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. Hmm... this pulls in http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd which again pulls http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd Which is a dead link. This causes my client to hang, and crash after a timeout. This might be the client which does not know about xmldsig magic, or an error in the schema, but I don't think we should have a schema which links to something which does not exist (I doubt my client is the only library which has this behaviour). Also it seems the default link has switched to https (which is good), but I find usage of TLS AND SAML at the same time to be a bit odd. Best regards, Henrik Henrik Thostrup Jensen <htj at ndgf.org> NORDUnet / Nordic Data Grid Facility. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (5)
-
Atsuko Takefusa -
Henrik Thostrup Jensen -
John MacAuley -
michalb＠man.poznan.pl -
Michał Balcerkiewicz