Skip to main content

Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)
draft-yusef-dispatch-ccmp-indication-07

Yes

(Gonzalo Camarillo)

No Objection

(Benoît Claise)
(Jari Arkko)
(Martin Stiemerling)
(Stephen Farrell)
(Stewart Bryant)

Note: This ballot was opened for revision 05 and is now closed.

Gonzalo Camarillo Former IESG member
Yes
Yes (for -05) Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2013-10-10) Unknown
Thanks for addressing all of my Comments
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-10-10) Unknown
Version -07 addresses my comments.  Thanks.
Benoît Claise Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection (2013-10-09 for -06) Unknown
It sounds like there was agreement to make this document Informational, but it is not reflected in the datatracker. Gonzalo: Please update.

2.1:

   The Call-Info header consists of two parts: a URI and a parameter.
   The purpose of the URI is to provide the XCON-URI of the conference
   focus, and the purpose of the parameter is to indicate that the
   conference focus supports CCMP.

Talking about "the purpose of the parameter", when the parameter *is* the "purpose parameter" is bound to be confusing. I suggest rewording to not use the word "purpose" here. How about just "The URI provides the XCOM-URI..., and the parameter indicates..."?
Richard Barnes Former IESG member
No Objection
No Objection (2013-10-08 for -06) Unknown
Support Barry and Sean's comments.
Sean Turner Former IESG member
No Objection
No Objection (2013-10-07 for -06) Unknown
What Barry said.

And, don't you have to pick one as the MTI?
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-10-05 for -06) Unknown
I had one comment you might want to consider:

In 1  Introduction

   This document
   describes two options to address the above limitation, depending on
   the need of the UA. The first option uses the Call-Info [RFC3261]
   header, and the second option defines a new value for the 'purpose'
   parameter in the 'service-uris' element in the SIP conferencing event
   package [RFC4575].

If I keep reading, I find out what the target audience is for both options, but the first clues I get are in 2.1 and 2.2, and both explanations are buried pretty deeply in those sections. Could you add something in the Introduction, or even in Section 2, that tells implementers which option they should look at first?

I agree  with the resolutions you've worked out with Barry on his Discuss and his Comments, so thank you for that, too.
Stephen Farrell Former IESG member
No Objection
No Objection () Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (2013-10-10) Unknown
Is there an intention to retain Appendix A following publication?   It seems unnecessary, although I am sure it was useful during the lifetime of the document as an internet draft.