Peoples, Hans and I have been working through behaviours of the Modify operation as the NSI CS document is a little vague on some of the more detailed aspects of the operation. Our most recent discussion focused on the modification of startTime. For example, let us say reservation X has a startTime of "now + 1 hour", but I would like to modify the startTime to start "now". In an initial reservation request we specify at startTime of now by omitting the <startTime> element, however, for a modify operation we cannot distinguish from a startTime not specified for modification and the startTime intentionally missing to indicate "now". In the current schema definition we cannot use an empty <startTime> element as it is an illegal xsd:dateTime. So that only leaves us with the option of specifying a <startTime> reasonably close to now, but well all now how troublesome this is with our current implementations. There is a solution to this issue. If we modify the existing schema to allow for the "nillable" option on startTime we can now specify an empty <startTime xsi:nil="true" /> element to handle this "start time of now" case. This would require a non-backwards compatible change for modify, but I am not sure how may NSA implementations of modify exist. The second issue is what happens if in the modify request a parameter with the same value is provided? Do we fail the modify or continue with the same value? For example, if a modify is received with the same startTime but a different endTime do we reject to modify since it contains the same startTime, or do we accept the modify and only change the endTime? I would assume we accept the modify operation an proceed with modification of endTime. What happens if only one parameter, say capacity, is specified and it contains the same value as the current reservation version? Thanks, John