Elwyn,
Thanks for the review. Please see my comments below:
------ Original Message ------
From: "Elwyn Davies" <[email protected]>
To: "General Area Review Team" <[email protected]>
Cc: [email protected]
Sent: 9/23/2013 9:17:42 AM
Subject: Gen-art LC review of draft-ietf-insipid-session-id-reqts-08.txt
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-insipid-session-id-reqts-08.txt
Reviewer: Elwyn Davies
Review Date: 23 September 2013
IETF LC End Date: 24 September 2013
IESG Telechat date: (if known) -
Summary:
Amost ready with very minor issues/nits. The only issue that is of any
consequence to my mind is handling of legacy B2BUAs etc.
Major issues:
None.
Minor issues:
s4.3: I am not clear whether there needs to be any special
consideration
if the B2BUA doesn't support Session-ID. There could be a number of
other cases to consider. In particular whether the B2BUA would forward
the Session-ID if it didn't understand it. Does this also affect
SBCs?
There will be special considerations for B2BUAs. REQ3 requires B2BUAs
to pass it unchanged. Of course, there is the possibility that existing
devices will not; we cannot change that. However, devices compliant
with the spec should. The intent is that the solution document will
spell out what B2BUAs should do when they receive a Session-ID and when
they do not. This will be fully covered in the solution specification
currently being progressed.
Nits/editorial comments:
s1: The purpose of the document is not explicitly set out in s1 -
although of course it is clear in the abstract. s1 should contain a
near copy of the abstract which also states that the document proposes
requirements for a new SIP header (I assume) called "Session-ID".
You're right. I struggled with placement. Finally, I decided that it
sounds best as the last paragraph of Section 1 (just copying the entire
abstract). Sound OK?
I could mention "Session-ID" as the name of the header, but this
actually could be dangerous. At present, we're struggling with
interworking with an already-existing (and implemented) I-D that uses
"Session-ID". We hope to re-use the same header and provide
interworking with that draft. However, if we find we cannot, we may
want to select a different header name.
s1, para 2:
This important fact makes it
impossible for call identifiers to be exchanged end-to-end when a
network uses one or more session protocols.
I would have thought that using just one session protocol didn't give
problems.
Do you mean "... uses more than one session protocol."?
Good catch. I changed it to "uses both of these session protocols".
s1, last para: Expand acronym PBX.
Done.
s3.1, para 6: s/some constraint/some constraints/ [arguable!]
Sounds better.
s3.2, Figure 1: [very nitty] Might be desirable to indicate the
existence of the middlebox(es) on the message arrows
(e.g., .....()..... or some such). Also label A and B as user agents.
I changed it to show "UA-A" and "UA-B". I'm not sure what to put in the
lines going left/right to showcase a B2BUA. Something like this?
UA-A UA-B
SIP message(s) ------- [ B2BUAs ] --------> SIP message(s)
SIP message(s) <------ [ B2BUAs ] --------- SIP message(s)
I'm not sure that's more readable. What did you have in mind?
s3.2, 4th bullet: s/(e.g., Alice and Bob)/(e.g., between Alice and
Bob)/
Done.
s3.2, 5th bullet and sub-bullets: The 2nd sub-bullet is a bit
confusing: Maybe:
OLD:
o A call between any two user agents wherein two or more user
agents are engaged in a conference call via a conference focus
o Each call between the user agent and the conference focus
would be a communication session
o Each communication session is a distinct communication
session
NEW
o A call between any two user agents wherein two or more user
agents are engaged in a conference call via a conference focus:
o each call between the user agent and the conference focus
would be a communication session, and
o each of these is a distinct communication session.
Done.
s3.2, 6th bullets and sub-bullets: Add periods (full stops) at end of
each.
Periods just at the end of the two sub-bullets starting with "The call
between Alice..."?
s4.1: Acronyms UA, B2BUA and SBC need expansion (UA and B2BUA are
effectively used in s1. SBC may need a reference (RFC 6135?)
Did you mean RFC 5853?
s4.1: Desirable to specify that "(SIP) dialog" is defined in s12 of RFC
3261.
Done.
s4.2: Once you have expanded SBC in s4.1 you could use it in s4.2!
Done.
s4.3, para 1: s/SIP users, device or domain identity./SIP users, device
or domain identities./
Done.
s4.3, para 1: s/or when security issue arise (e.g./or when a security
issue arises (e.g.,/
I think that should have been "security issues arise", so I changed it
to that.
s4.7, para 1: s/between two or more parties./between two or more
parties
other than the one setting up the call./
Done.
s7, para 2: s/In adherence with/In adhering to/
Done.
Thanks!
Paul
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
