[Nsi-wg] Modify behaviors

[Hans Trompert]

Hi John,

I believe I agree with you, but just to make sure:

On 11/03/16 17:34, John MacAuley wrote:
> Doing this update to the document now.
>
> 1. Adding the nil-able startTime and endTime to indicate now and
> forever respectively.

So <startTime/> means start now and <endTime/> means last forever. Do we
still want to allow omitting the complete startTime and endTime tags in
the initial reservation to indicate the same? I would like to propose
that we do not allow that anymore, this to make the behavior the same
for the first and any subsequent reservation request.

> 2. Stating if a value is provided in a modify that is unchanged it is
> accepted and the modify proceeds without changing that value.

So I can copy the complete set of criteria from the previous
reservation, modify only the value(s) I want changed and leave the other
values unchanged?

> 3. If the requested modify results in no changes to the current
> schedule, the modify should proceed as off a successfully modify was
> performed.

... with only result that the new version of the reservation is higher
than the previous one.

> 4. If a startTime in the past is is received in either the initial
> reservation request, or a subsequent modification operation, it should
> be considered as a startTime of now (<startTime xsi:nil="true" />).

OK.

Cheers,
    HansT.


>
> On 2015-12-22, at 6:59 AM, Hans Trompert <Hans.Trompert at SURFnet.nl
> <mailto:Hans.Trompert at SURFnet.nl>> wrote:
>
>>
>> On 21/12/15 19:41, John MacAuley wrote:
>>>
>>> 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.
>>
>> Exactly, that was the reason why we came up with the possibility to
>> leave startTime or endTime empty to specify 'start now' and 'last
>> forever' reservations. I don't look forward to implement all kind of
>> workarounds again.
>>
>>> 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.
>>
>> It is not because I proposed this of course ;-), but I believe this
>> is the best solution to modify start or end time without having to
>> change the current semantics around startTime and endTime.
>>
>>> 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?
>>
>> Seen from a practical perspective, you already have to keep track of
>> the current reservation details to implement idempotency, so it is
>> very easy to check if a value specified in a modify is different from
>> the current value, only question is what are you going to do after
>> that, are you going send back an error or are you just going to
>> accept it as a no-op.
>>
>> Related to this, is it allowed to send a modify that does not change
>> any of parameters of the reservation? And will that then result in a
>> new reservation with a higher criteria version?
>>
>> Cheers,
>>     HansT.
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20160314/f342ba3a/attachment.html>