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

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 6 Apr 2016 02:36:11 +0000

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

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 6 Apr 2016 02:36:19 +0000

Brett,

Thanks. Fixed.

-Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 6 Apr 2016 06:50:26 -0400

Hi,

Thanks for the response; reply is inline.

> > 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
> 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.

If bullet 1 applies, draft-ietf-insipid-session-id-19 bullet 5 needs a
modification similar to bullet 3's "note" to make it obvious.  Without such
a note, it looks like the last sentence of bullet 5 applies when building
CANCEL response.  The is especially true since bullet 1 has an exception
indicating that it doesn't apply to CANCEL.

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Thu, 7 Apr 2016 02:27:50 +0000

> indicating that it doesn't apply to CANCEL.

I’ve added similar verbiage to bullet 5 to make it clear but after reading bullet 1 again, I will be removing the statement "(with the exception of ACK or CANCEL as described below)” because there is no response to an ACK anyway, so it doesn’t really make sense and we want bullet 1 to apply to CANCEL as well. I’m not sure I remember why I added that in the first place, but it seems wrong. Let me know if you see any issue with this. 

Were you planning on any additional feedback on draft-ietf-insipid-session-id-19? If not, I’ll upload -20 with these final modifications. 

-Paul

---

From: Brett Tate <[email-masked]>
Date: Thu, 7 Apr 2016 07:18:38 -0400

Hi,

> I’ve added similar verbiage to bullet 5 to make it clear
> but after reading bullet 1 again, I will be removing the
> statement "(with the exception of ACK or CANCEL as
> described below)” because there is no response to an ACK
> anyway, so it doesn’t really make sense and we want bullet
> 1 to apply to CANCEL as well. I’m not sure I remember why
> I added that in the first place, but it seems wrong. Let
> me know if you see any issue with this.

The change sounds correct.

> Were you planning on any additional feedback on
> draft-ietf-insipid-session-id-19?

No.  However if I find time before or during WGLC, I'll review whatever is
the current version of the draft.

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Sun, 10 Apr 2016 22:22:55 +0000

Thanks Brett.

I’ll get -20 out tonight.

-Paul

> On Apr 7, 2016, at 7:18 AM, Brett Tate <[email-masked]> wrote:
> 
> Hi,
>