[Insipid] draft-ietf-insipid-session-id-10: comments

[Brett Tate <[e-mail]>]

Hi,

The following are a few comments concerning
draft-ietf-insipid-session-id-10.

Thanks,
Brett

------

Section 1 paragraph 4: "This procedures" should be "The procedures".

Section 6 paragraph 1: "be used the peer" should be "be used if the peer".

Section 7 paragraph 1: Since proxies cannot alter a Call-ID (without
becoming B2BUA), "proxies and" should potentially be removed from the
first sentence.

Section 7 paragraph 6: Concerning early dialogs, the CANCEL correlates to
the INVITE instead of a specific early dialog.  Thus the paragraph should
likely be reworded to always reflect the INVITE when CANCEL not traversing
a dialog.  For instance if received multiple 18x creating multiple early
dialogs and received Session-IDs {B1, A} and {B2, A}, the current
paragraph appears to recommend that the CANCEL include one of these within
the CANCEL.

Section 7 paragraph 7: Should potentially recommend what should occur when
B2BUA sends re-INVITE without SDP to obtain SDP to setup another session.
More specifically, should the re-INVITE contain a new 3PCC generated UUID?
The other options would be to resurrect the discarded UUID or use the
currently connected session's UUID.

Section 9.1: Concerning the SIP messages, the B2BUA appears to be a proxy.
Thus from a RFC 7092 perspective, I guess that it is a Proxy-B2BUA that
hasn't originated any requests.

Section 9.1: The F3 and F4 Via branch "z9hG4bKnashds8" should instead
reflect INVITE's Via branch.

Section 9.1: The F4 Contact or F5 Request-URI potentially need a different
ip-address (although maybe reflecting missing Record-Route without "lr").
F4 Contact reflects F3 Contact and doesn't match F5 Request-URI.

Section 9.1: Concerning F6, the B2BUA's Via header appears to be missing.
And existing Via should contain a received parameter.

Section 9.2: Should potentially clarify if the REFER is mid-dialog even if
section 9.9 is out-of-dialog REFER.

Section 9.3 bullet 2: I'm glad that the example isn't mandating sending a
request to update the Session-ID after transfer.  However you might want
to reword the last sentence since Alice won't remain "completely unaware"
of the transfer since Alice's device would notice the transfer caused
Session-ID modification when subsequent messaging occurs on the dialog.

Section 9.4 bullet 4: Potentially should clarify why this example is
quickly updating the Session-ID but section 9.3 example does not.

Section 9.8.1 figure 10: What should be the CANCEL session-id if Bob-1 had
sent two 18x creating two early dialogs with Session-IDs {B1x, A} and
{B1y, A}?

Section 10 paragraph 4: "following" should be "follow".

Section 10 paragraph 5: "rules for" should be "rules that".

Section 10 bullets: Some currently start upper case; others currently
start lower case.

Section 10 bullet 7: "include and" should be "include a"

Section 10 last bullet: Should potentially reword the bullet.  I'm not
sure if second sentence is indicating to ignore unknown parameters, remove
unknown parameters, or something else (like reiterating that the above
bullets do not apply to them).

Section 14.2 RFC5589: "RFC 5359" should be "RFC 5589".