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-yusef-dispatch-ccmp-indication-04
Reviewer: Ben Campbell
Review Date: 2013-07-16
IETF LC End Date: 2013-07-16
Summary: This draft is almost ready for publication as a proposed standard, but
I think there are some clarifications needed first.
Major issues:
-- None
Minor issues:
-- Abstract:
Is the abstract current? It says you will discuss pros and cons of a few
options, and recommend two. I guess you did recommend two, but the others have
been relegated to the appendix. There are no pros and cons listed for the two
recommended choices, which seems rather odd.
It also mentions that these are mechanisms to be used by SIP clients. That's
not repeated in the introduction. Is this entire draft intended exclusively for
SIP clients?
-- 2.
It would be helpful to give more guidance on when one would use one method over
the other. 2.1 mentions that it might be an "easier way for a UA that is not
interested in the URI". I'm not sure what it means for a UA to be interested or
not interested in a URI--maybe you mean "A UA that does not otherwise need to
parse the URI"?
-- 2.1:
I assume this section is intended to be SIP specific. It would help to say that
somewhere, and include a 3261 citation for Call-Info. There are hints that the
entire draft is SIP specific in the abstract, but that doesn't get repeated
elsewhere. (In fact, the only non-abstract citation to 3261 is in the IANA
considerations.)
Also, the section seems underspecified. It says the ccmp value can go in any
INVITE, INVITE response, or OPTIONS response. It would help to describe how UAs
would actually use it. Simply naming the actors would help; as it is, they are
obscured by the passive voice in "... can be used...", and the reader is left
to infer the intent based on his knowledge of SIP.
--2.2:
I assume this section is _not_ necessarily SIP specific. If that's the intent,
it would be helpful to say so.
-- Appendices:
There's more detail and discussion around the discarded methods than the
recommended ones in sections 2.X. It would be helpful to have those sections
have at least this much explanation.
-- section 3:
You say this draft introduces no additional security considerations. Statements
like that turn out false more often than not. For example, is there no security
consideration created by having a SIP UA identify itself as a conference focus
in an INVITE? (Even if the answer is no, it's helpful to have text along the
line of "we thought about this and decided it was not a consideration due
<reasons>"
Further, you say "... beyond those applicable to the mechanisms described
within". The mechanisms in sections 2.X are "described within". I assume those
aren't the ones you mean here.
Nits/editorial comments:
-- Abstract:
The abstract should not contain citations. It will be published in multiple
places without the rest of the document, orphaning the citations.