Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

[Brett Tate <[e-mail]>]

Hi Paul,

Thanks for the response and welcome to the discussion.  Reply is inline.

> I propose a simpler solution that should address your
> concerns and make it easy for implementers to understand
> what should be done in these scenarios. This would
> require a slight modification to the draft as it stands
> today. I am therefore seeking your and the working group’s
> approval to move forward with this change. If we can all
> agree on this in concept, I will put together some
> concrete text for inclusion in the draft.

To get more feedback, you might need to raise the topic in a new thread.


> In a nutshell, I propose that we make a minor change to
> the text to explicitly call out the conditions under
> which a UUID should be stored by endpoints and
> intermediaries. I propose that an endpoint or intermediary
> only store an updated remote UUID under the following
> conditions:
>
> When receiving a request (other than ACK) that is accepted
> (results in a 1XX or 2XX response), the received UUID must
> be retained. If the request results in any other kind of
> response, it should not be retained. This can, of course,
> lead to conditions where a request is received, a
> provisional response is sent (and therefore the UUID is
> retained) and then for whatever reason, an error
> (4XX/5XX/6XX) or redirect (3XX) response is sent. In such
> a case, we will never “roll back” the Session ID.

Concerning the mentioned "1xx", you might want to exclude 100 since 100
isn't end-to-end (even if using proxies instead of B2BUAs).  For instance if
100 is only sent between two of the intermediaries, a resulting 500 response
doesn't mean that everyone agrees that the uuid actually changed.  However,
I guess that the same could be said for all non-reliable 1xx since a 18x
sent by endpoint could be dropped (or received after 500).

You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx.
Some within the SIP working groups prefer to allow ACK-for-2xx to update
things.  For instance, see draft-ietf-insipid-session-id-16 section 9.7; the
3pcc sends the updated uuid within the ACK.

The proposal currently appears to violate (or alter) RFC 3261 section 8.2:
"If it is rejected, all state changes MUST NOT be performed".  Similarly it
also appears to impact the following RFC 6141 section 3.3 SHOULD: "If any of
the changes requested in a re-INVITE or in any transaction within it have
already been executed, the UAS SHOULD return a 2xx response".

You might want to exclude CANCEL and its 2xx response from the algorithm
(although decision might be influenced by decision concerning 100 response).
CANCEL and related 2xx response are not end-to-end (even if using proxies
instead of B2BUAs).


> The only additional rule for stateful intermediaries is
> that if they accept a request and then forward that request
> to another destination (therefore there was no error found
> with the message), this will also trigger the intermediary
> to update the retained UUID.

The proposal means that not all of the devices will necessarily agree if a
uuid changed during failure situation.

Concerning "therefore there was no error found" statement, be aware that
forwarding a request does not necessarily mean that no error was found (i.e.
device can be lenient) or that the request won't eventually be rejected
(with 400 or other failure response).


> The remote UUID in all responses must match the UUID
> received in the request if the SIP stack is able to process
> the Session-ID header. This applies even if the UUID is not
> going to be retained. If a re-INVITE {C,B} contains an
> error but the Session-ID is successfully extracted from the
> re-INVITE, the 4XX response should contain {B,C} (assuming
> the receiving endpoint is still using B as the local UUID.
> Otherwise B should be replaced with the correct Local UUID).
>
> To deal with issues where a response with a Session ID
> different than what is being retained is sent in an error
> response and the ACK for that response contains the new
> Session ID which we chose not to retain because it was as
> a result of an error, the document will state that a
> Session ID received in an ACK must never update the
> retained value. This should never be an issue because the
> Session ID in the ACK should always match that of the
> matching request, so if the endpoint receiving the request
> updated the Session ID on the request, it does not need to
> do so again for the ACK.

Concerning "Session ID in the ACK should always match that of the matching
request", it isn't always true.  For instance, see
draft-ietf-insipid-session-id-16 section 9.7; the 3pcc sends the updated
uuid within the ACK.

You might want to distinguish between a ACK-for-2xx versus ACK-for-non-2xx.
Some within the SIP working groups prefer to allow ACK-for-2xx to update
things.


> Endpoints and intermediaries always update their Remote
> Session ID based on any responses received regardless of
> the type of response (provided the response is
> syntactically valid and can be processed, of course).

Sending a non-reliable response (1xx-6xx) is not necessarily the best way to
update something because of race conditions and similar ambiguities.
However, the proposal is basically the same as the draft.


> There will always be feature interactions that result in
> temporarily mismatched Session IDs when intermediaries are
> involved, but I don’t think the above proposal makes this
> any worse of a problem in real-world applications.

I'm currently not sure if the proposal is better or worse than draft version
16.

>From the rejecting device perspective, the proposal appears to be better.
The proposal currently appears to leave partial changes up to rejecting
device (i.e. intermediaries allowed change but rejecting device did not)
without any indication to modifier to know if change was successful at the
remote endpoint.  This is about the same as changing some of the MUST to
SHOULD (or MAY) within the current draft which would allow the rejecting
device to make the decision concerning which is better for the situation.


> Please see my responses inline to address your concerns….

I'll respond separately if I have any comments different from those within
this reply.

Thanks,
Brett