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

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

Brett,

Thanks for the feedback.  I will try to incorporate your suggestions, 
resolve identified issues, etc. and address input I received from 
others.  I'll try to get a new draft out this week.

Paul

------ Original Message ------
From: "Brett Tate" <[e-mail]>
To: [e-mail]; [e-mail]
Sent: 3/30/2015 9:19:06 AM
Subject: draft-ietf-insipid-session-id-14: comments and questions

>Hi,
>
>The following are some comments concerning
>draft-ietf-insipid-session-id-14.
>
>Sorry about the delay.
>
>Thanks,
>Brett
>
>---------
>
>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?
>
>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.
>
>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.
>
>Section 5 paragraph 2: Should potentially remove "UA-generated" since 
>the
>next paragraph mentions that it can be generated by a proxy.
>
>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.
>
>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.
>
>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).
>
>Section 6 paragraph 7: "shall" potentially should be "SHALL".
>
>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).
>
>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)?
>
>Section 7 last paragraph: Change "were last received by an endpoint" to
>"it last sent towards an endpoint".
>
>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).
>
>Section 9.3 last bullet: replace "include" with "includes".
>
>Section 14.2: Potentially should add the rest of the RFC 3725 title.