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.