Hi Paul,

Thanks the response; reply is inline.  I'll send
draft-ietf-insipid-session-id-15 comments/questions separately.


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

It helps address the above two comments.  Since it looks like it conflicts
with my mentioned call setup assumption, I'll likely have additional
questions/comments.


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

Retry was potentially addressed good enough since I don't think implementers
would interpret "peer endpoint MAY change at any time" as including retries.
However since it doesn't need to pass authentication (and draft overrides
RFC 3261 section 8.2's "all state changes MUST NOT be performed"), I'm not
sure where within the processing steps (like RFC 3261 section 8.2) they will
place the decision to update the stored remote UUID.

Unknown or unsupported request situations are interesting.  Even though the
request is unknown or unsupported, the draft still mandates allowing it to
update the UUID.

Malformed message situations are interesting.  The draft currently allows a
malformed messages to update the UUID.  I can't wait until I hear "I sent
you a malformed message containing Session-ID, why didn't you update the
stored remote UUID?"

Large SIP message situations are interesting.  Even though a device might
reject large messages, the draft still mandates processing the message
enough to update the UUID.


> >Since CANCEL can contain an older UUID, it potentially
> >isn't the best choice for inclusion as the remote-uuid.

You should likely discuss the impacts of CANCEL if you are really intending
to allow it to roll back the UUID.  Otherwise, implementers might not think
that the draft truly intended for the rollback to occur.


> >Because of race conditions, the "most recently received
> >UUID" is not necessarily the most recent UUID sent by
> >the remote endpoint.

Potentially addressed good enough.  However, adding a statement about race
conditions within the draft would help silence complaints if anyone was
thinking that the draft provides a way to ensure all of the devices truly
know the current Session-ID.


> >If a device returns 500 because lower CSeq, it seems
> >strange that the UAS MUST update the stored UUID.

Potentially addressed good enough since I don't think implementers would
interpret "peer endpoint MAY change at any time" as including requests
containing lower cseq.


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

As far as I know, the draft indicates yes.  Is this acceptable?


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

As far as I know, the draft indicates yes.  Is this acceptable and should it
be mentioned within section 11?  I'm glad that the draft only indicates that
the B2BUA SHOULD (instead of MUST) communicate the update to the remote
device.


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

Sounds okay from a UAC perspective; however since the Call-ID can change, I
don't see how that mandate is always possible from a UAS perspective.



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

Basically any cases where the B2BUA likely has a more accurate view of the
current remote UUID.  For instance, section 9.3 example.  Similarly, the
endpoint may be incorrect concerning section 6's "believes may be a new peer
endpoint" check and included non-null remote UUID.  Similarly, consider race
conditions (although it could also cause B2BUA to be wrong).