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

[Paul Kyzivat <[e-mail]>]

This discussion is reinforcing my belief that this mechanism is a mess - 
that the chance is slim to none of getting consistent results in all the 
connected devices.

	Thanks,
	Paul

On 1/5/16 12:51 PM, Brett Tate wrote:
> 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
>
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid
>