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

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

Brett,

Thanks for your feedback.  Please see my replies inline:

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

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

Fixed.

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

Good catch! Fixed.

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

I'm not entirely clear on what you're suggesting.  All the current 
paragraph says is that if an intermediary sends a CANCEL and it doesn't 
have the value B1, for example, it is to use {A, "null"} as the 
Session-ID.


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

What changes in the text are you proposing?  The temporary value would 
persist until such time as a the 3PCC device learns what the actual UUID 
values are for Alice or Bob.  If a re-INVITE is sent, the 3PCC device 
would send either the same fabricated UUID to Bob if it does not know 
Alice's UUID.  Or, it will send Alice's UUID if it knows it.


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

B2BUAs don't have to originate requests.  This example (and all others 
that use B2BUA) shows a classic B2BUA.  I don't think it will help to 
make this clearer introducing a new type of device like "Proxy-B2BUA".


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

Fixed

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

I think you're saying that F4 needs to contain a Record-Route header.  
Correct?
I've added "Record-Route: <sip:server10.biloxi.example.com;lr>"

I think the ACK from Alice to the B2BUA was also wrong.  I've changed 
that to reflect Bob's address.  That is, the ACK should have:
ACK sip:bob@192.168.10.20 SIP/2.0


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

Fixed (I think; please check the next draft I'll post for this all all 
other corrections).


>Section 9.2: Should potentially clarify if the REFER is mid-dialog even 
>if
>section 9.9 is out-of-dialog REFER.
OK.  Added a sentence in parentheses.

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

That is certainly true up to this point that Alice would be unaware of 
the transfer, but you're right that she would become aware in the future 
when she receives a message from Carol.  I tried to make that a little 
clearer.

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

I'm not sure what you are referring to here.  Nowhere do we purposely go 
out of the way to update a Session-ID.  Those values are only updated 
when there is otherwise a reason to send a message.


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

I don't fully understand your question.  However, if there is a single 
call initiated from Alice to Bob-1, then there would only be {B1} at 
Bob-1, not {B1x} and a {B1y}.  If you're asking about the case where 
Alice made two separate calls to Bob-1, then Alice would be using two 
separate {A1} and {A2} values.

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

Fixed.

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

Fixed.


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

Fixed.


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

Fixed.


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

I tried to fix that.  Please let me know if this is clearer.


>
>Section 14.2 RFC5589: "RFC 5359" should be "RFC 5589".
Fixed it.

Thanks for the very thorough review.  This really helps!

Paul