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)

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.

I support Alexey's discuss issue #4 and Gonzalo's issues #3 and 8.

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.

Please see my GEN-ART review comments on 3/16 (http://www.ietf.org/mail-archive/web/gen-art/current/msg05149.html).