Re: [apps-discuss] AppsDir review of draft-yusef-dispatch-ccmp-indication-04

[Mary Barnes <[e-mail]>]

Hi Glenn,

Sorry for the delay in responding.  Thanks for your careful review.  Our
responses are below [MB].

Mary


On Fri, Jul 19, 2013 at 5:21 AM, Glenn Parsons
<[e-mail]>wrote:

> Hello all,
>
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
>
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
>
> Document:  draft-yusef-dispatch-ccmp-indication-04
>
> Title: Conference Focus Indicating CCMP Support
>
> Reviewer: Glenn Parsons
> Review Date: July 19th, 2013
>
> Summary: The document is needs some improvements in explanation and then
> would be ready for publication.
>
> Major issues:
>
> There are 4 approaches described here.  And two are standardized.  The
> abstract indicates that pros/cons are explained, but these only appear for
> the two not chosen.  The reader would benefit from understanding the
> difference in choosing between the two approaches standardized.  Further,
> what is the recommendation for the two not chosen?  Could these still be
> used and they are shown as a guide?  Or must they not be used?
>

[MB] Very good point.  We did have some of this text in earlier versions
and can pull that back into this version.  For the Call-Info header
(section 2.1), the following is the reason it was selected as a preferred
solution - we can add this to the first paragraph right after the intro
sentence:
 The use of the Call-Info header is consistent with SIP in terms of the
mechanism by which a UA determines the capabilities of a SIP intermediary.
It also enables the discovery of the CCMP capability by any network element
that is not using the conference event package.

For section 2.2, we can add text something like the following after the
first sentence:

Note that the definition of an additional URI 'purpose' of 'ccmp'
associated with the 'confs-uris' element in the SIP conferencing event
package was also considered (as discussed in A.2). However, it was decided
that the use of the 'service-uris' element was a bit cleaner since clients
that had no interest in CCMP wouldn't need to even bother looking at that
element in the event package.

As far as the two not chosen, since both require specification (i.e., IANA
registrations), it wouldn't make sense for someone to use those. We
included them in the appendix for completeness in case someone later asked
why we didn't standardize those approaches. We can add a paragraph in the
appendix reflecting this and note that the consensus of the community at
the time of this specification was that the two mechanisms being
standardized in this specification were more than sufficient.
[/MB]

>
> Minor Issues:
>
> In the abstract:
>
> ...the XCON conference event package RFC 4575 [RFC4575] ... This appears
> to be incorrect.  Do you want to refer the RFC 6502 or 4575 here?  I
> suspect it is the former, and if so some mention of this in the body of the
> document (like in 2.1 with XCON-URI) is needed as well as a reference.
>
[MB] Yep - you are correct.[/MB]

>
> In the Introduction:
>
>  RFC 5238 [RFC5239] defines a... ->  RFC 5239 [RFC5239] defines a...
>
[MB] We'll fix this. [/MB]

>
> In 2.1, 4.2:
> Focus -> conference focus.  Perhaps a reference to the definition of this
> term would be helpful.
>
[MB] We probably should reword the first paragraph of section 2 to provide
some more background, introducing the term,  maybe something like the
following:

This section defines two mechanisms that can be used to discover whether
the conference which a client has joined, per the SIP signaling procedures
defined in RFC 4579, supports CCMP. Specifically, the mechanisms allow the
client to know that the URI representing the conference focus, as defined
in RFC 4579 and RFC 5239, is an XCON-URI as defined in RFC 6501.
[/MB]

>
>
> Nits:
>
> None.
>