Henrik - Just so other people on the list see your comments who may not be following code.google issues. Everyone - To clear up some confusion I may have introduced. Issue #97 was added to track the addition of serviceType independent of the removal of the service attributes. I though it better to treat the two updates separately. i will be submitting an update to close #97 in a few minutes. In comment #2 below, Henrik asks if we could discard the serviceAttributes element all together and include the service specific element from external namespaces directly in the parent element. Yes we can definitely do this, and there will be no loss of information. The only difference is that we will no longer have the service related elements wrapped in the serviceAttributes clild element. In this case the XSD would be simplified to the following: <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="serviceType" type="xsd:string" minOccurs="0" /> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> The XML example would also appear as follows: <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <serviceType>ETS.Bidirectional</serviceType> <p2p:p2pService> <bandwidth>1000</bandwidth> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> <labels> <attribute type="vlan"> <value>1901</value> </attribute> </labels> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> <labels> <attribute type="vlan"> <value>1901</value> </attribute> </labels> </destSTP> </p2p:p2pService> <surf:sNCP>Protected</surf:sNCP> </criteria> This change would remove the need for an additional type, and flatten the request a little further. Does anyone have any additional comments? John Project Member Reported by jmacauley, Jul 4 (2 days ago) As part of service definition decoupling from the NSI CS core protocol we need to add a ServiceType string value to reservation criteria to indicate the type of service being requested. This string value will correspond to the service definition template for the service being offered. Based on this ServiceType string value, and NSA will be able to determine the serviceAttributes required to meet the service request, and look up the service definition template. The current ReservationRequestCriteriaType definition is: <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="bandwidth" type="xsd:int" minOccurs="0" /> <xsd:element name="serviceAttributes" type="ftypes:TypeValuePairListType" minOccurs="0" /> <xsd:element name="path" type="tns:PathType" minOccurs="0" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> </xsd:complexType> This will be modified to: <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="serviceType" type="xsd:string" /> <xsd:element name="bandwidth" type="xsd:int" minOccurs="0" /> <xsd:element name="serviceAttributes" type="ftypes:TypeValuePairListType" minOccurs="0" /> <xsd:element name="path" type="tns:PathType" minOccurs="0" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> </xsd:complexType> All other types containing criteria will also be modified to contain the serviceType element. Yesterday (34 hours ago) Delete commentProject Member #1 thostrup Isn't this suggestion different than the one presented in NSI_Service_Decoupling.pdf? There the criteria was essentially a schedule along with a bunch of serviceAttributes Yesterday (34 hours ago) Delete commentProject Member #2 thostrup Hi, so the current suggestion: <criteria version="1"> <schedule> <startTime>2013-‐09-‐30T09:30:10Z</startTime> <endTime>2013-‐09-‐30T10:30:10Z</endTime> </schedule> <serviceAttributes> <p2p:p2pService> .. Could we consider dumping the serviceAttributes alltogether, and going for something like this: <criteria version="1"> <schedule> <startTime>2013-‐09-‐30T09:30:10Z</startTime> <endTime>2013-‐09-‐30T10:30:10Z</endTime> </schedule> <p2p:p2pService> ... I.e., having a single ANY element. The QName of the element would define the service request type. Today (moments ago) Delete commentProject Member #3 jmacauley In response to comment #1 - I added the serviceType issue separately from the removal of service parameters into serviceAttributes. In response to comment #2 - Yes we could definitely do this, but I thought encapsulating the elements in the serviceAttributes sub element would provide a cleaner separation. I am okay with this change. On 2013-07-06, at 1:25 PM, John MacAuley <john.macauley@surfnet.nl> wrote:
People,
As agreed I have added the serviceType string to identify the corresponding Service Description that will identify the elements carried in the serviceAttributes. The updated document is attached. I will open issues to track the updates and submit the changes to the code.google repository.
John
<NSI_Service_Decoupling-v2.pdf> _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg