I'm in favor of allowing unmodified values in modify request, it
will make it easier to use and I'm sure there are more use cases
like the one you describe.
Cheers,
HansT.
On 30/11/2016 18:08, John MacAuley
wrote:
Always embarrassing when the Dutch and Japanese delegations point
out my lack of skills in the English language ;-)
I guess I should have used "assigns the values" held in the
modification request which would describe what we are doing.
If you would like I could remove the "If a
modification request contains modifiable elements that are the
same as the currently reserved values". I thought it might
get us out of a sticky situation with a failed commit on a
modification where only part of the modify was committed.
This way another modify could be sent down to fix the part
that failed, although, it would probably fail again.
Yes, this does
make it a little bit more clear, but questions
remain.
I understand that if you want to modify one of the
elements you have to send it in a Modify request
as a standalone element. So if I want to modify
two elements I have to send them in two separate
elements like below?
I'm I correct
that this implies that it is not allowed to send a
complete p2p element with all the elements in it
and only change the ones you want modified?
My thought on this was no. You cannot add the full
p2p element as this would imply (or set an
expectation) that members of that element are
modifiable when they are in fact not.
Furthermore, the first paragraph says that only
the elements to be modified are included in the
request, but the second paragraphs says that if a
modification request contains modifiable elements
that are the same as the currently reserved
values, the modification request should proceed
through the reserve state machine lifecycle as if
changed values were successfully applied,
effectively only increment the criteria version.
So is it allowed to send elements that did not
change or not?
I believe this condition came out of a discussion with
you back in December 2015 :-)
The idea was that if capacity was already 500 and
you requested a modification to 500 then we would
accept this as a valid request and run through the
connection state machine returning success. This
assumes the philosophy that a service modification to
an existing value is not invalid (i.e. setting a
boolean variable to true that is already true is not a
programming error). Nothing is stopping the NSA from
actually doing a modification internally to change the
capacity from 500 to 500.
Does this make sense?
Yes and no ;-) You do confirm that the behavior should be
as described in document. Although I doubt if you can call
changing something to the same to be a change.
change
verb
make or become different.
noun
an act or process through which something becomes
different.
That is why i think that the phrase "only the elements to
be modified are included" is in conflict with the phrase
"If a modification request contains modifiable elements
that are the same as the currently reserved values". But
nevertheless, this is how we will implement it, and for
the record, we will prevent the uPA doing unneeded calls
to the underlying NRM.
Cheers,
HansT.
On 23/11/2016 16:44, John MacAuley wrote:
I will read the section again since
it must not be clear. Here is what a modify
message looks like for capacity:
This is include only the capacity element
that is defined in the p2p schema as a
standalone element for the purposed of
modification. This is not including the full
<p2ps> element and using optionality.
It is including the <capacity> element.
If you look at the p2p service schema this is
parameter defined as modifiable in the p2p
service (startTime and endTime are in the CS
schema itself).
You may ask why it was done this way… It
allowed us to have the original reservation
request have mandatory elements for the
service, but the modify to only contain those
elements being changed.
The CS 2.1 document states in section
15.7 that only the elements to be
modified are included in a modify
request. However, in the schema the p2p
parameters directionality, capacity,
sourceSTP and destSTP are not optional.
As a result the example modify requests
in figure 154 and 155 will not pass
schema validation.
If the four parameters are made optional
in the schema it will also be possible
to leave them out in the initial reserve
request, which will cause problems
because all four of them belong to the
minimum set of parameters in this stage.
Or the schema is left as is making it
mandatory to always send the minimum set
of parameters in every modify request,
in this case section 15.7 should be
updated to reflect this.