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.