Media Control Channel Framework
RFC 6230
Note: This ballot was opened for revision 12 and is now closed.
(Robert Sparks) Yes
(Jari Arkko) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) (was Discuss, No Record, Discuss) No Objection
Comment (2010-04-07)
No email
send info
send info
In the Abstract: "... suitable to meet the requirements of a distributed, centralized conference system, as defined by the IETF." This sentence about the scope of the document is confusing. It could be rephrased so that it is clear that the document deals with centralized conferences as defined in XCON (i.e., a central conference server) where the central conference server is distributed. Fix the following sentence in Section 4.2: The Control Client entity then creates a to the Control Server, using B2BUA type functionality. Also in Section 4.2, the reference to the 3pcc spec should appear the first time 3pcc is mentioned. In Section 10, the Content-Length in the SIP messages in the examples could be easily calculated for completeness (e.g., it would be zero in the BYE request and its response)
(Ralph Droms) No Objection
(Lars Eggert) (was Discuss) No Objection
(Adrian Farrel) No Objection
(Russ Housley) No Objection
(Alexey Melnikov) (was Discuss) No Objection
Comment (2010-11-25)
No email
send info
send info
Framework Transaction: A Framework Transaction is defined as a sequence composed of a control framework message originated by either a Control Client or Control Server and responded to with a control Framework response code message. Note that the control framework has no "provisional" responses. A control framework transaction MUST complete within 5 seconds and is referenced Why this value is hardcoded value? How did you decide on 5 seconds? throughout the draft as 'Transaction-Timeout'. [The following was formerly a DISCUSS:] 1) In Section 4.1: The 'cfw-id' attribute MUST be globally unique over space and time (using an appropriate algorithm) and MUST NOT clash with instances of the 'cfw-id' used in other SIP offer/answer exchanges. I think the text here (and in Section 4.2) would benefit from a description of some way to generate unique ids.
(Tim Polk) No Objection
Comment (2010-04-08 for -)
No email
send info
send info
I support Alexey's discuss issue #4 and Gonzalo's issues #3 and 8.
(Peter Saint-Andre) (was Discuss) No Objection
Comment (2010-04-15)
No email
send info
send info
The document could benefit from a copy edit. For example: 1. The abstract is overly broad. The first sentence could describe dozens of different documents: This document describes a Framework and protocol for application deployment where the application programming logic and media processing are distributed. Perhaps at least specifiy more fully the target applications? 2. Why is "Framework" capitalized (e.g., in the abstract)? 3. Some acronyms are not spelled out on first use in the document (e.g., SIP, RTP, SDP). 4. Section 2 refers to both BCP 14 and BCP 15 (!). 5. It's not a good idea to place conformance text in the terminology section ("A control framework transaction MUST complete within 5 seconds..."). 6. Much of the overview is dedicated to justification of the protocol, often with marketing-style language "Generic protocol allows for easy extension", "The ability to select a Control Server based on Service level capabilities is extremely powerful when considering a distributed, clustered architecture", etc.). This text might have been useful during WG discussions but seems out of place in the finished document. 7. Some references are missing. For example, the Overview mentions "standard SIP third party call control" but does not refer to a specification for this standard on first mention. Similarly, Section 12.2 mentions IPsec but does not provide a reference. 8. Section 13.1 uses the term "RFC Editor submission" but RFC 5226 uses the term "RFC Editor Independent submission". The document could also benefit from proofreading, but I have not provided a list of typographical and grammatical errors.
(Sean Turner) No Objection
Comment (2010-04-07 for -)
No email
send info
send info
Please see my GEN-ART review comments on 3/16 (http://www.ietf.org/mail-archive/web/gen-art/current/msg05149.html).