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

["Paul Giralt (pgiralt)" <[e-mail]>]

Brett,

Thanks again. See inline...

> 
> I don't have a strong preference.  The SHOULD would allow intermediaries to
> defer to prior hop within situation or deployment model where intermediary
> might be less confident about the accuracy of the stored value.
> 


I’m going to put it as a MUST for now and hopefully will get comments if anyone feels this should be a SHOULD. Seems like the intermediary would be in a better position to know the latest UUID and the intermediary should follow the SHOULD that says to update the other endpoint when the UUID changes.

> 
> If not intentional, the proposed new bullet for CANCEL appears to cause the
> remote UUID of CANCEL's 200/481 to contain the stored value.  However, I'm
> not positive since unsure if another bullet applies at the same time
> concerning how to build the CANCEL responses.
> 

The remote UUID of CANCEL’s 200 / 481 contains the UUID from the CANCEL per Bullet 1 in Section 8. Don’t think we need any special cases here.

> Also concerning the new bullet for CANCEL, the "not passed not end-to-end"
> appears to have an extra "not”.

Thanks. Fixed.

> 
>> As you mentioned, without updating the UUID on a failure
>> response, we don’t have a value for ACK. Having the value
>> in the ACK outweighs any potential out of sync that may
>> occur in a rare scenario where the UUID changes on a
>> failure response. I’m inclined to leave as-is.
> 
> I don't have a strong opinion on the topic.  However the ACK for non-2xx
> could be a special situation where it can contain failure response's local
> UUID without needing to allow it to update the stored value.  This would be
> similar to INVITE failure response (or 3xx) during call setup causing a
> resubmit with higher cseq (without remote UUID); however excluding 3xx, I
> didn't really notice any text concerning the topic.
> 

Ok thanks. Since you don’t have a strong opinion and I’d rather err on the side of less special cases, I’m going to leave as-is for now. If anyone else has a strong opinion to the contrary we can revisit.

> 
> 
>> To answer your specific questions - if it really did play
>> out the way you outlined above and the 503 does include a
>> session identifier (and it happens to be different than
>> the one in the 2xx), then yes, the 503 should cause an
>> update and the remote UUID in the ACK for the 503 would
>> reflect the 503’s value (which would also now be the stored
>> value because we accept stored values from the 503). Not
>> ideal, but this scenario does not seem realistic to me.
>> Please correct me if I’m missing something.
> 
> The RFC 3263 advancing of mid-dialog requests based upon short time
> intervals occurs.  Devices that do it currently pick a winning
> branch/response for updating local data and relaying as needed (selecting
> "best" response is discussed within RFC 5057 section 5.1 note 9).
> 
> The thing that you might be missing is that the draft (depending upon
> interpretation) is asking devices that RFC 3263 advance mid-dialog requests
> based upon time (and/or 503) to allow every responding branch to update the
> stored value even though 1 or none where selected as the winning response
> when selecting how to respond.
> 
> However as I mentioned above, I don't have a strong opinion on the topic.


Thanks for clarifying. I think implementations should do what they feel is best to select the “right” UUID to use. The implementation would know best and I’m hesitant to complicate the draft to provide specific guidance. I may add a statement indicating the spirit of the guidelines.

I’ll incorporate all your feedback into draft 19 and get it out shortly.

-Paul