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

["Paul E. Jones" <[e-mail]>]

Brett,

We're trying to close on these last comments and do some editorial work. 
  Please me reply inline...

>General comment: I find the concepts of endpoint and intermediary
>confusing within the draft.  For instance if a proxy/B2BUA decides to
>reject an INVITE during call setup, does section 6 or section 7 apply?  
>I
>assume that section 6 applies (if it didn't relay the related request).
>If the proxy/B2BUA rejects a mid-dialog request (while acting as an
>intermediary for the session), section 7 applies.  Adding something to
>section 2 to clarify ambiguity might help.  If a device which can act 
>as
>endpoint or intermediary rejects a re-INVITE for an unknown dialog by
>sending 481, should it do so following section 6 or section 7?

Yes, this would be useful.  And it goes along with your next issue.


>General comment: I find the use of UA within draft occasionally 
>ambiguous
>concerning if it includes or excludes intermediaries such as B2BUA and
>proxy's UAS when it is used.

I've made an attempt to address this confusion and to be more consistent 
in terminology, adding some language to Section 2 as you suggest, as 
well.

>
>Section 5 paragraph 2: What does "accepted" mean?  For instance, does
>returning a failure response such as 407 or 401 mean that you accepted 
>the
>session?  Should adjust text to remove the ambiguity.

Prior to seeing your message, I saw that and was equally confused.  I 
think the intent was to refer to sessions that are terminated.  And I do 
mean terminated, since sessions that are not terminated might include 
provisional responses with a null UUID.  I changed the language.  See if 
it makes more sense when I post the draft soon.


>Section 5 paragraph 2: Should potentially remove "UA-generated" since 
>the
>next paragraph mentions that it can be generated by a proxy.

Indeed, that's confusing.  And a lot of the procedure is replicated in 
the section on intermediary procedures.  I've shortened this section a 
bit.


>  Section 5 paragraph 7: In my opinion, the MUST should be changed to 
>SHOULD
>(along with similar changes elsewhere); however since I guess the 
>working
>group disagrees... Should add text somewhere concerning the impacts of
>race conditions, retries, CANCEL, authentication, overload, et cetera 
>upon
>the "most recently received UUID" algorithm.  For instance if "most
>recently received UUID" was processed as a retry, it potentially isn't 
>the
>best choice for inclusion as the remote-uuid.  Since CANCEL can contain 
>an
>older UUID, it potentially isn't the best choice for inclusion as the
>remote-uuid.  Because of race conditions, the "most recently received
>UUID" is not necessarily the most recent UUID sent by the remote 
>endpoint.
>If a device returns 500 because lower CSeq, it seems strange that the 
>UAS
>MUST update the stored UUID.  If the "most recently received UUID" 
>hasn't
>passed authentication (i.e. returning 401, 407, or 403), should the
>request (or the related ACK) still be allowed to alter the stored UUID?
>If an overloaded device returns a failure response (such as 503), is 
>the
>overloaded device actually supposed to still update the stored UUID to 
>be
>compliant with this mandate?  If this draft is mandating an overloaded
>server process an unauthenticated request to update stored information, 
>it
>should be mentioned within section 11.

Whew!  OK, that's a lot to chew on. :)

First, I removed the text in section 5, since that (too) was redundant.  
However, I don't think that addresses your more serious concern w.r.t. 
race conditions.

Most messages will be coming in sequentially.  There are possibilities 
that an intermediary throws back an error message with a "null" UUID.  
So, what I did was add text to section 6 that said the endpoint needs to 
take note of non-null values.  If the value is null, that might just be 
a stateless intermediary returning an error, because it doesn't know 
what the other end's UUID value is.

I think that will address part of the issue.  Maybe that and other 
changes help to close all of them; not sure.  Have a look at the new 
draft and tell me what you think.


>Section 6 paragraph 2: Should clarify authentication behavior.  For
>instance, RFC 3261 allows the challenger to behave mostly stateless 
>(such
>as by not retrying 401/407); however this draft currently appears to
>mandate maintaining additional information and perform related
>modifications.

I see value in keeping that state.  This is in line with also 
maintaining the UUID value even in the face of getting a 3xx, too.  We 
want this to effectively persist from the moment the user lifts the 
handset and makes a call to the moment the user hangs up the phone.

>Section 6 paragraph 3: What is the intended impact of the paragraph if
>received 3xx-6xx (such as 302, 401, 407, 422, 488, or 503) for INVITE
>during call setup and it causes sending related subsequent INVITE?  For
>instance, does it require the subsequent out-of-dialog INVITE to 
>contain
>the updated remote-uuid (instead of null)?  I wasn't sure if there was 
>any
>leeway for the endpoint to think that the INVITEs are part of different
>communication sessions (from remote endpoint perspective).

For any of those, the local UUID would be retained.  The remote-UUID is 
not retained, because the peer changed (or potentially will change).  
I've added a new paragraph to the endpoint procedure section to explain 
this.

>Section 6 paragraph 7: "shall" potentially should be "SHALL".
To be consistent with the rest of the text, I changed it to MUST.


>Section 7 paragraph 3: The paragraph potentially should clarify the
>forking interaction (such as the aggregation concept mentioned in RFC 
>3261
>section 16.7) since only 1 of the potentially many Session-ID headers 
>will
>be relayed.  For instance, the Session-ID of the selected 
>"communication
>session" (sent within response) might be forked to all of the
>"communication sessions" (if received within subsequent transaction).

Good catch.  For that, I propose that the intermediary set the 
"local-uuid" value to "null".


>
>Section 7 paragraph 3: If the intermediary knows it is relaying the
>request to a different session, can it fix the remote-uuid (such as
>changing it to null)?
For the response aggregation case, definitely.  For what other cases are 
you thinking that should happen?


>Section 7 last paragraph: Change "were last received by an endpoint" to
>"it last sent towards an endpoint".

Changed it!


>Section 9 paragraph 2: Concerning statement that the section is
>non-normative, be aware that the section does contain some MUST 
>(although
>might not be in conflict).
I changed MUST to something else.  No normative language.


>
>Section 9.3 last bullet: replace "include" with "includes".

Thanks!


>  Section 14.2: Potentially should add the rest of the RFC 3725 title.
>

Wow, that's an impressive catch when you're looking at reference titles. 
  I fixed that!

We'll have a new revision posted within a day or so.

Paul