All, Yesterday while doing some bug testing I ran across an issue in the specification of recursive query results in relation to versioned reservations. I have had a couple of reads through the CS 2.0 document and believe we need to better specify how modifications are handled, especially relating to results returned in query* operations. I believe this is due to different sections being written with different understandings of the behaviour at the time. I know we changed a few times how the version numbers would be handled. This is visible in the text. Section 4.3.1 describes what I believe people have implemented. If there is no committed version of a reservation then only the base reservation information is returned (connectionId, globalReservationId, description, requesterNSA, and connectionStates) with no <criteria> element. This means no versioning and no service specific information is visible in a query. Once a version is committed then the <criteria> information for that version is returned. If the reservation is being modified then the <criteria> for the last committed version is returned. 4.3.1 Reservation State Machine (page 11) Modification of a reservation is supported in NSI CS v2.0. The reserve request message is used for both the initial reservation and subsequent modifications. A version number is specified in the reservation request message. The number is an integer and should be monotonically increasing with each subsequent modification. The version number is updated after a commit results in a transition back to the ReserveStart state. A query will return the currently committed reservation version number, however, if the initial version of the reservation has not yet been committed, the query will return base reservation information (connectionId, globalReservationId, description, requesterNSA, and connectionStates) with no versioned reservation criteria. Details of how the version number should be managed can be found in Section 6.1.6. Question: While a reservation is being modified does the <reservationState> reflect the current state of the modification even though the <criteria> represents the last committed version? I believe it does. This needs to be added to section 4.3.1 text for clarification. Sections 6.1.6 and 8.5.1.30 are currently in conflict. I believe I wrote 8.5.1.30 when we were using "0" as a special version number to show the currently uncommitted first reservation criteria. This decision was later changed to what is described in 6.1.6. We need to update the text in 8.5.1.30 to better reflect reality. 6.1.6 Reservation Versioning Information (page 26) To support the modification of reservations, the notion of versioning has been introduced to identify the instance of a reservation over its lifetime. Versioning MUST be used as follows: Version numbers are integer values ≥ 0 (zero) Version numbers are assigned by the RA when a reservation request (i.e. NSI_rsv.rq) is made to a PA If a version number is not specified in an NSI_rsv.rq, it is assumed to be 0 (zero) regardless of whether the request is theinitial or a subsequentrequest. An NSI_rsv.rq with a version number ≤ the (highest) current committed reservation version number will result in a failed request and an appropriate error 8.5.1.30 ReservationRequestCriteriaType (page 89) Type definition for a reservation and modification request criteria. Only those values requiring change are specified in the modify request. The version value specified in a reservation or modify request MUST be a positive integer larger than the previous version number. A version value of zero is a special number indicating an allocated but not yet reserved reservation and cannot be specified by the RA. Lastly we have an issue with the current definition of the ChildRecursiveType that holds the reservation results of a child NSA in the recursive query. Instead of having the <criteria> element as 0..unbounded like it is for the base reservation, I missed updating the schema definition for modify and still have the child <criteria> element as 1..unbounded. Therefore, the recessive query breaks when attempting during the reservation phase for the first version. Below is a pictorial of the issue. I will take an action to update the schema. John
