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

[Brett Tate <[e-mail]>]

Hi,

Thanks for the response; reply is inline.

> > 8) Section 8

<snip>

> Totally agree and I avoided using the word “guarantee” for
> the specific reason you outline, but I guess “ensure” might
> be too strong as well. How’s this?

<snip>

Looks okay to me.


> I’m not sure what the best approach here is, but I’m inclined
> to say that the intermediary MUST fix the remote UUID when
> relaying a request / response although I’d be okay with a
> SHOULD. Do you have any opinion?

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.


> > 12) Section 8 bullet 3: Clarify the last sentence since
> > unsure what "latest UUID value" means: stored UUID or
> > request's UUID.
>
> It means the request’s UUID. Fixed.

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.

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


> > 14) Section 8 bullet 5: Allowing failure responses to
> > update the cached UUID is a little odd (although it
> > provides a value for ACK).  It can potentially cause
> > a disagreement concerning session identifier.
>
> I think the value changing in a failure response is in
> itself an unlikely scenario to begin with and this
> scenario is not likely to occur.

The most likely causes of a change within failure response would be because
of race conditions and not following a SHOULD.


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


> > If there were multiple failure responses causing resubmit
> > with higher cseq, the last change is cached on
> > intermediary.  If session identifier is subsequently
> > missing from 2xx response (or other final response), the
> > intermediary will have a cached UUID which does not get
> > relayed to the endpoint (except maybe when section 7
> > paragraph 12 is applicable).
>
> I’m not understanding why the 2xx would suddenly be
> missing the session identifier in this case.

Among other potential reasons, an intermediary that doesn't support this
draft generated the 2xx response and none of the other intermediaries added
the header.


> I already addressed this case above to ensure that a
> missing session identifier when one was present in
> previous messages does not overwrite. Does this address
> your concern here?

Yes; it allows the intermediary the option to follow section 7 next to last
paragraph.


> When multiple locations are attempted, wouldn’t they be
> attempted in series?

Yes; however similar to the Happy Eyeballs stuff being discussed within
sipcore, the advancement might be quick and the responses may (or may not)
be processed as though requests sent simultaneously.


> I would think that the 503 would actually come back
> before the request that leads to the 2xx if the session
> establishment really does succeed.

That would be nice since it avoids a compliant intermediary (depending upon
interpretation) from doing something which is obviously not preferred.  If
the draft defers to the intermediary/endpoint (explicitly or implicitly),
they can do what they think is best.


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