Hey John-

I have a few concerns about this sample Reservation Request:

- I chg'd security attributes to <sessionSecutiyAttrib>  as I believe there are two levels of authorization: First, the RA NSA must be authenticated and authorized to even talk to the PA NSA.   Second, the service request itself must be authorized by the network(s) along the path.   So I also added an authorization element to the service parameters

- I added a "serviceDefinition" field in the reservation request.   While this could be omitted, I think its useful to explicitly state the service you are expecting...and it could help the pathfinder construct a candidate path.

- I put all schedule inside the service parameters - these are constraints on the service...not something independent of the service.

- Changed the STP names:  I added a "NORDUnet" network name and a simple "foo" local part just to make sure the request functions with these legal names.

- I removed the path object from the source and dest STPs - This is arguable, but I felt this was more consistent with the other service parameters.   I don't think we have a justification anymore for a PathObject with intermediate STPs...such a thing is just a Tree style segmentation.  But if folks want to keep this PO with the src and dst, I don't have a big deal with it. 

I am almost of a mind to suggest we define all service parameters like you did the security attributes:
<attribute>
    <attributeName> NameThing </attributeName>
    <attributeValue> abcd </attributeValue>
</attribute>
This would make the service definition XSD easier I think.

Let me know what you think.
Jerry

On 3/23/11 10:37 PM, John MacAuley wrote: 
Peoples,

I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.

John.






_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg