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
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.
Doing this update to the document now. 1. Adding the nil-able startTime and endTime to indicate now and forever respectively. 2. Stating if a value is provided in a modify that is unchanged it is accepted and the modify proceeds without changing that value. 3. If the requested modify results in no changes to the current schedule, the modify should proceed as off a successfully modify was performed. 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" />). Comments? John On 2015-12-22, at 6:59 AM, Hans Trompert <Hans.Trompert@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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@SURFnet.nl <mailto:Hans.Trompert@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@ogf.org <mailto:nsi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nsi-wg
On 2016-03-14, at 5:32 AM, Hans Trompert <hans.trompert@surfnet.nl> wrote:
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.
Correct.
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.
I was going to allow it for backwards compatibility in the initial reserve phase. Remember we are trying to maintain schema recompile compatibility wherever we can. Although I do agree having the two separate ways of specifying now and forever is not the best, it would allow existing clients to remain unmodified. There is also no ambiguity in the initial reserve so supporting both does not create a problem. The use of reserve for modify would only use the <startTime xsi:nil="true" /> and <endTime xsi:nil="true" /> options.
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?
Technically yes. But only those criteria that can be modified.
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.
Yes, I need to get the wording correct for this.
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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (2)
-
Hans Trompert -
John MacAuley