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

[Brett Tate <[e-mail]>]

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.