Centralized Conferencing Manipulation Protocol
draft-ietf-xcon-ccmp-15

[Ballot comment]
---

-15 fixed the last thing - mention of HTTP proxy auth (thanks)

--- original discuss on -13, addressed by -14

(1) Not requiring HTTP or TLS client-authentication mechanism seems to me to be
a mistake. Its more likely that HTTP authentication will be maintained in
future (e.g. extended for oauth, saml, etc) than that CCMP will be.  I would
suggest getting rid of the "not required" in section 9 on that.

(2) The response codes in 5.4 seem to be a subset of those from rfc 2616.  I
think it'd be better to not replicate the descriptive text about those, nor the
codes themselves - how is the combination of HTTP response codes and CCMP
response codes supposed to work? E.g. if I get a HTTP 200 but a CCMP 404 in one
response then what? I could imagine coders getting this wrong, or having
difficulty doing the right thing with libraries.

--- original comments on -13

(1) This could do with being rephrased. "Their identifiers, respectively the
conference XCON-URI and the conferencing client XCON-USERID, and their XML
representations compliant with the XML Schema defined in the XCON data model
are widely used for creating the CCMP requests and responses."

(2) The AUTO_GENERATE_X stuff on p12 seems complex - I don't think I really
followed the description and I wondered if it'd be easy to write code for this.
I'd suggest maybe looking at that text again to see if there's a way to make it
clearer for an implementer who hasn't been involved in the WG.

(3) In 4.4, if a client's timer expires and it closes the connection, then
what, if anything, is the server supposed to do? E.g. if the request was ok and
the server has done an update but not yet sent the 200 response for some
reason. I think the server doesn't have to do anything (e.g. try to unwind the
update), but that'd be good to say.

(4) What is the limit of the xPathFilter mechanism? Could I use it to select
all the users or conferences with the password foo? Maybe there's some security
considerations text needed for that?

[Ballot discuss]
The remaining discuss point emerged from discussion of the
original discuss on -13, but doesn't seem to be reflected in
-14.

>> [MB3] I asked coders that are also co-authors and they do agree we
>> should add some text on the use of proxy authentication.
>> [/MB3]

I think the fix is to say somewhere that:

  "clients [MUST|SHOULD|MAY] include support for HTTP proxy
  authentication"

I'd be happier with MUST|SHOULD will also clear with a
MAY since I reckon that everyone will include it anyway once
they're alerted to it.

[Ballot comment]
As with draft-ietf-xcon-common-data-model, section 3 of this document repeats things from RFC 5239. I think this introduces a danger that the documents will "get out of sync": If the normative text happens to differ between the documents, it's unclear which is authoritative. If there's disagreement in even non-normative text, it introduces the potential for confusion. Strike all of section 3. Completely redundant with RFC 5239, which is a normative reference anyway.

Intro to section 4 [fixed]

4.2 [fixed]

4.3 [fixed]

4.4 [fixed]

5.2 [fixed]

5.3 Overall - I wouldn't mind seeing all of the XML *not* repeated here. It's already in section 11.

5.3 [fixed]

5.3.1 [fixed]

6 - I think this should either be in an appendix or in draft-ietf-xcon-examples.

[Ballot comment]
#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) Sec 10.1 - A reference to RFC 6125 is needed to ensure the server's ID is properly checked.

[MB] Are you suggesting that we change the following sentence to something like the following?
OLD:
  Note that in order for the
  presented certificate to be valid at the client, the client must be
  able to validate the certificate.
NEW:
  Note that in order for the
  presented certificate to be valid at the client, the client must be
  able to validate the certificate, using a mechansim such as that specified in RFC 6125.
[/MB]

[spt] this or a pointer to 2818.

[Ballot discuss]
This is an updated discuss based on -14:

This is an updated discuss.  1-4 and 6 were addressed in -14.  asking if I missed the fix for #5.

#1) cleared

#2) cleared

#3) cleared

#4) cleared

#5) I couldn't find an explicit statement that clients and server MUST support both the request and response.  Do we need that or is it assumed?

[MB2]  It's really assumed, but we can add a statement in either section 4.4 or section 5. [/MB2]

[spt] Can you point me to the text?  I think I'm missing it.

#6) cleared

[Ballot comment]
--- original discuss on -13, addressed by -14

(1) Not requiring HTTP or TLS client-authentication mechanism seems to me to be
a mistake. Its more likely that HTTP authentication will be maintained in
future (e.g. extended for oauth, saml, etc) than that CCMP will be.  I would
suggest getting rid of the "not required" in section 9 on that.

(2) The response codes in 5.4 seem to be a subset of those from rfc 2616.  I
think it'd be better to not replicate the descriptive text about those, nor the
codes themselves - how is the combination of HTTP response codes and CCMP
response codes supposed to work? E.g. if I get a HTTP 200 but a CCMP 404 in one
response then what? I could imagine coders getting this wrong, or having
difficulty doing the right thing with libraries.

--- original comments on -13

(1) This could do with being rephrased. "Their identifiers, respectively the
conference XCON-URI and the conferencing client XCON-USERID, and their XML
representations compliant with the XML Schema defined in the XCON data model
are widely used for creating the CCMP requests and responses."

(2) The AUTO_GENERATE_X stuff on p12 seems complex - I don't think I really
followed the description and I wondered if it'd be easy to write code for this.
I'd suggest maybe looking at that text again to see if there's a way to make it
clearer for an implementer who hasn't been involved in the WG.

(3) In 4.4, if a client's timer expires and it closes the connection, then
what, if anything, is the server supposed to do? E.g. if the request was ok and
the server has done an update but not yet sent the 200 response for some
reason. I think the server doesn't have to do anything (e.g. try to unwind the
update), but that'd be good to say.

(4) What is the limit of the xPathFilter mechanism? Could I use it to select
all the users or conferences with the password foo? Maybe there's some security
considerations text needed for that?

[Ballot discuss]
The remaining discuss point emerged from discussion of the
original discuss on -13, but doesn't seem to be reflected in
-14.

>> [MB3] I asked coders that are also co-authors and they do agree we
>> should add some text on the use of proxy authentication.
>> [/MB3]

I think the fix is to say somewhere that:

  "clients [MUST|SHOULD|MAY] include support for HTTP proxy
  authentication"

I'd be happier with MUST|SHOULD will also clear with a
MAY since I reckon that everyone will include it anyway once
they're alerted to it.

[Ballot comment]
The OPS-DIR review performed by Juergen Quittek raised a few issues and made a number of suggestions. None of them are critical, but in case the document is open to fix other issues I suggest to consider these ones as well:

1) Section 2: Terminology
>    First-Party:  A request issued by the client to manipulate their own
>      conferencing data.
>
>    Third-Party:  A request issued by a client to manipulate the
>      conference data of another client.

"First-Party" and "Third-Party" alone are not requests.
At least the term is not used this way in the draft.
Rather "third-party request" is used in the text for Referring to requests.
I would suggest:

NEW
  First-Party request:  A request issued by the client to
      manipulate their own conferencing data.

  Third-Party request:  A request issued by a client to
      manipulate the conference data of another client.


2) Section 3, third paragraph, 1st line:

OLD
  Conference object and conference users do represent key elements

NEW
  Conference object and conference user objects do represent key elements

Implementation and operation of the protocol would become drastically simpler if the CCMP server would not be required anymore to create users. Just creating user objects would probably be sufficient already

3) Section 3.2, 1st paragraph, lines 7-8

OLD
  or a common administrator.  The Conference Control Server creates
  individual users, assigning them a unique Conference User Identifier

NEW
  or a common administrator.  The Conference Control Server creates
  individual user objects, assigning them a unique Conference User
  Identifier


4) Section 4.1, 2nd paragraph

OLD
  create:  for the creation of a conference, a conference user, a
      sidebar, or a blueprint.

NEW
  create:  for the creation of a conference object, a conference
      user object, a sidebar, or a blueprint.


5) Section 4.3, item (b), line 2:

OLD
        in the request has (have) been replaced by the newly created

NEW
        in the request have been replaced by the newly created


6) Section 5.3.4, paragraph after Figure 8, line 7:
What is "the referenced conference document"?
Is it the conference object?


7) Section 5.3.5, 1st paragraph, Last two lines:
Again "conference document", see issue 6)


8) Section 5.2.12, first bullet item, line two:
"ten standard message names"
It would be helpful to add a reference to Table 1.


9) Section 7, first lines:
>    If a conference control client is not pre-configured to use a
>    specific conference control server for the requests, the client MUST
>    first discover the conference control server before it can send any
>    requests.
Is this really a capital "MUST"? Would the client be able to send any request before discovering the server?

[Ballot comment]
(1) This could do with being rephrased. "Their identifiers, respectively the
conference XCON-URI and the conferencing client XCON-USERID, and their XML
representations compliant with the XML Schema defined in the XCON data model
are widely used for creating the CCMP requests and responses."

(2) The AUTO_GENERATE_X stuff on p12 seems complex - I don't think I really
followed the description and I wondered if it'd be easy to write code for this.
I'd suggest maybe looking at that text again to see if there's a way to make it
clearer for an implementer who hasn't been involved in the WG.

(3) In 4.4, if a client's timer expires and it closes the connection, then
what, if anything, is the server supposed to do? E.g. if the request was ok and
the server has done an update but not yet sent the 200 response for some
reason. I think the server doesn't have to do anything (e.g. try to unwind the
update), but that'd be good to say.

(4) What is the limit of the xPathFilter mechanism? Could I use it to select
all the users or conferences with the password foo? Maybe there's some security
considerations text needed for that?

[Ballot discuss]
(1) Not requiring HTTP or TLS client-authentication mechanism seems to me to be
a mistake. Its more likely that HTTP authentication will be maintained in
future (e.g. extended for oauth, saml, etc) than that CCMP will be.  I would
suggest getting rid of the "not required" in section 9 on that.

(2) The response codes in 5.4 seem to be a subset of those from rfc 2616.  I
think it'd be better to not replicate the descriptive text about those, nor the
codes themselves - how is the combination of HTTP response codes and CCMP
response codes supposed to work? E.g. if I get a HTTP 200 but a CCMP 404 in one
response then what? I could imagine coders getting this wrong, or having
difficulty doing the right thing with libraries.

[Ballot comment]
Intro to section 4:

  CCMP is a client-server, XML-based protocol, which has been
  specifically conceived to provide users with the necessary means for
  the creation, retrieval, modification and deletion of conference
  objects.  CCMP is also state-less, which means implementations can
  safely handle transactions independently from each other.
  Conference-related information is encapsulated into CCMP messages in
  the form of XML documents or XML document fragments compliant with
  the XCON data model representation.

That's a bit fluffy. How about instead:

  CCMP is a client-server, XML-based protocol for user creation,
  retrieval, modification and deletion of conference objects.  CCMP
  is a stateless protocol, such that implementations can safely
  handle transactions independently from each other.  CCMP messages
  are XML documents or XML document fragments compliant with the
  XCON data model representation. [REF?]
 
See also use of the word "conceived" in the intro to 4 and in 5.3.1. Could tighten up the language there.

4.2 would be much easier to read if you stated the requirement (that responses with documents MUST have a version) first and then gave the explanation. Implementers don't need dramatic build-up. Get to the point. Then most of the explanation can be reduced.

4.4 first paragraph (or two; I can't tell if what spans the page break is 1 paragraph or two)
can be reduced to:

  CCMP is implemented using HTTP, placing the CCMP request messages into
  the body of an HTTP POST operation and placing the CCMP responses into
  the body of the HTTP response messages. For information as to why this
  implementation method was chosen, refer to Appendix A.

Then trim the second to last paragraph of 4.4 to get rid of redundancies.

5.3 Overall - I wouldn't mind seeing all of the XML *not* repeated here. It's already in section 11.

5.3 Intro - Move the discussion of optionsRequest/optionsResponse down to 5.3.12. No need to distinguish it here.

6 - I think this should either be in an appendix or in draft-ietf-xcon-examples.

[Ballot discuss]
As with draft-ietf-xcon-common-data-model, section 3 of this document repeats things from RFC 5239. I think this introduces a danger that the documents will "get out of sync": If the normative text happens to differ between the documents, it's unclear which is authoritative. If there's disagreement in even non-normative text, it introduces the potential for confusion. Strike all of section 3. Completely redundant with RFC 5239, which is a normative reference anyway.

The intro to section 4 gives an implementation requirement without using 2119 language:

  Each operation in the protocol model, as summarized in Section 4.1 is
  atomic and either succeeds or fails as a whole.  The conference
  server must ensure that the operations are atomic in that the
  operation invoked by a specific conference client completes prior to
  another client's operation on the same conference object.

4.3 needs a reference to the data model document.

5.2 defines the "version" parameter as optional. However, there are clearly instances (specified in 4.2) where it is required. 5.2 should probably indicate that.

5.3.1 - "A blueprintsRequest message REQUIRES no "confObjID" and "operation" parameters". Do you mean that they are OPTIONAL or that they MUST NOT be present? "REQUIRES no" is not appropriate.

[Ballot comment]
BTW, I appreciated the many examples, although they might have been
moved to an appendix to clear the floor for the main meat of text
(is that metaphor too horribly mixed?). I also wasn't convinced by
including all of the schema fragments in-line as well as in Section 11,
but this is probably a stlistic choice that is not important.

---

Nit

5.4.

  All CCMP response messages MUST include a ""response-code"".  The

You probably don't need the quad-quotes.

[Ballot discuss]
A very weighty tome that I cannot pretend to have read in full detail.
I am relying on the WG and responsible ADs for assurance of quality,
but I noticed a few smaller issues that I believe need to be resolved
before publication.

---

Section 4

  The specification recommends the use of HTTP as
  a transport solution, including CCMP requests in HTTP POST messages
  and CCMP responses in HTTP 200 OK replies.  This implementation
  approach is further described in Section 4.4.

Section 9

  This section describes the use of HTTP [RFC2616] and HTTP Over TLS
  [RFC2818] as transport mechanisms for the CCMP protocol, which a
  conforming conference Server and Conferencing client MUST support.

Section 10 

  3.  The protocol MUST support a confidentiality and integrity
      mechanism.  As described in Section 9, implementations of CCMP
      MUST implement the HTTP transport over TLS [RFC2818].

So it looks like Section 4 is under-egging the situation and you need
s/recommends/requires/

It is probable that Seciton 4.4 needs to be tightened in this regard as
well.

---

I think the 2119 language needs to be tightened up. As a completely
random example:

Section 5.1

  operation:  An optional parameter refining the type of specialized
      request message.  The "operation" parameter is REQUIRED in all
      requests except for the "blueprintsRequest" and "confsRequest"
      specialized messages.

Why "optional" in lowercase but "REQUIRED" in uppercase?

I think the only sure way to sort this will be to grep all the lowercase
versions of the 2119 words and think about them carefully.

---

Section 5.1

  conference-password:  An optional parameter that MUST be inserted in
      all requests whose target conference object is password-protected
      (as per the  element in
      [I-D.ietf-xcon-common-data-model]).

This "MUST" implies that ommission would be treated as a malformed
message, not a password failure (i.e. 400 not 401). Does it matter?
But later I see you have defined 424 which is probably what you would
use. Add some clarity?

---

Shouldn't the sample phone number (uri="tel:+390817683823") be taken
from one of the set of "unreal" phone numbers?

---

Section 7

  This document proposes the use of DNS to locate the conferencing
  server.

What is the upshot of this proposal? Does a conformant implementation
get to choose? Is this language you can tighten as s/propose/specifies/

[Ballot comment]
[In progress - Will likely become DISCUSS]

Strike all of section 3. Completely redundant with RFC 5239.

Intro to section 4:

  CCMP is a client-server, XML-based protocol, which has been
  specifically conceived to provide users with the necessary means for
  the creation, retrieval, modification and deletion of conference
  objects.  CCMP is also state-less, which means implementations can
  safely handle transactions independently from each other.
  Conference-related information is encapsulated into CCMP messages in
  the form of XML documents or XML document fragments compliant with
  the XCON data model representation.

That's a bit fluffy. How about instead:

  CCMP is a client-server, XML-based protocol for user creation,
  retrieval, modification and deletion of conference objects.  CCMP
  is a stateless protocol, such that implementations can safely
  handle transactions independently from each other.  CCMP messages
  are XML documents or XML document fragments compliant with the
  XCON data model representation. [REF?]
 
Might I suggest that anywhere you find the word "conceived" in this document (see elsewhere in the intro to 4, 5.3.1, and 6.9) there is an opportunity to do some shortening and clarification.

The intro to section 4 gives an implementation requirement without using 2119 language:

  Each operation in the protocol model, as summarized in Section 4.1 is
  atomic and either succeeds or fails as a whole.  The conference
  server must ensure that the operations are atomic in that the
  operation invoked by a specific conference client completes prior to
  another client's operation on the same conference object.

4.2 would be much easier to read if you stated the requirement (that responses with documents MUST have a version) first and then gave the explanation. Implementers don't need dramatic build-up. Get to the point. Then most of the explanation can be reduced.

4.3 needs a reference to the data model document.

4.4 first paragraph (or two; I can't tell if what spans the page break is 1 paragraph or two)
can be reduced to:

  CCMP is implemented using HTTP, placing the CCMP request messages into
  the body of an HTTP POST operation and placing the CCMP responses into
  the body of the HTTP response messages. For information as to why this
  implementation method was chosen, refer to Appendix A.

Then trim the second to last paragraph of 4.4 to get rid of redundancies.

5.2 defines the "version" parameter as optional. However, there are clearly instances (specified) where it is required. 5.2 should probably indicate that.

5.3 - Move the discussion of optionsRequest/optionsResponse down to 5.3.12. No need to distinguish it here.

5.3.1 - "A blueprintsRequest message REQUIRES no "confObjID" and "operation" parameters". Do you mean that they are OPTIONAL or that they MUST NOT be present? "REQUIRES no" is not appropriate.

[Ballot comment]
1. Section 4 states:

  The conference
  server must ensure that the operations are atomic in that the
  operation invoked by a specific conference client completes prior to
  another client's operation on the same conference object.

Change "must" to "MUST"?

2. Also in Section 4:

  The specification recommends the use of HTTP as
  a transport solution...

Change to the following?

  Implementations SHOULD use HTTP as the transport...

3. In Section 4.2:

  The "version" parameter is not REQUIRED for requests...

There is no "not REQUIRED" in RFC 2119. I suggest:

  The "version" parameter is OPTIONAL for requests...

4. In Section 5, the terms "mandatory" and "optional" are used for the
various parameters. Using RFC 2119 language, are these really "REQUIRED"
and "OPTIONAL"?

5. The table in Section 5.4 has bad line breaks. I suggest changing this:

  +---------------+------------+------------+------------+------------+
  | Response code | Create    | Retrieve  | Update    | Delete    |
  +---------------+------------+------------+------------+------------+

to this:

  +----------+-------------+-------------+-------------+-------------+
  | Response | Create      | Retrieve    | Update      | Delete      |
  | Code    |            |            |            |            |
  +----------+-------------+-------------+-------------+-------------+

or even to this:

  +------+--------------+--------------+--------------+--------------+
  | Code | Create      | Retrieve    | Update      | Delete      |
  +------+--------------+--------------+--------------+--------------+

That will give you more room in each column.

6. Various examples have "form the server" instead of "from the server".

7. In schema snippet from Section 6.9, the example extension does not
specify an XML namespace, implying that the extension is qualified by
the base namespace. This would be wrong. The examples are right, here.

8. Section 9 states:

  A conferencing client that conforms to this specification is not
  required to support HTTP authentication [RFC2617] or cookies
  [RFC6265].

There is no "not required" in RFC 2119. Do you mean that it is OPTIONAL
for a conferencing server to support RFC 2617 and RFC 6265?

9. In Section 10.4, please add an informational reference to RFC 4732.

[Ballot discuss]
1. Section 4.2 appears to assume that HTTP is the transport; for
example:

  If the
  modifications are all successfully applied, the server sends back to
  the client a "200" response which also carries information about the
  current server-side version of the modified object.

If that is so, please either change SHOULD to MUST (i.e., make HTTP
mandatory-to-implement as a baseline data transfer protocol) or at
least add a note to the effect that HTTP is a SHOULD but all the
examples use HTTP.

This would also be consistent with Section 9, which states:

  This section describes the use of HTTP [RFC2616] and HTTP Over TLS
  [RFC2818] as transport mechanisms for the CCMP protocol, which a
  conforming conference Server and Conferencing client MUST support.

2. In Section 4.3:

  The XCON data model identifies some elements/attributes as mandatory.
  Since the XML documents carried in the CCMP need to be compliant with
  the XCON data model, there can be a problem in cases of client-
  initiated operations, like the creation/update of conference objects.
  In such cases, not all of the mandatory data can be known in advance
  to the client issuing a CCMP request.  As an example, a client has no
  means to know, at the time it issues a conference creation request,
  the XCON-URI that the server will assign to the yet-to-be-created
  conference and hence it is not able to appropriately fill with that
  value the mandatory "entity" attribute of the conference document
  contained in the request.  To solve this issue, the CCMP client fills
  all mandatory data model fields, for which no value is available at
  the time the request is constructed, with fake values in the form of
  a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a
  unique numeric index for each data model field for which the value is
  unknown.

Instead of sending fake values, how about fixing the data model so that
these elements and attributes are not mandatory?

3. The CCMP namespace is "urn:ietf:params:xml:ns:xcon:ccmp". Why is it
not "urn:ietf:params:xml:ns:xcon-ccmp"? On the meaning of ":" here
please see Section 3 of RFC 3553...

  Declaration of structure:

      The namespace is primarily opaque.  The IANA, as operator of the
      registry, may take suggestions for names to assign but they
      reserve the right to assign whatever name they desire, within
      guidelines set by the IESG.  The colon character (":") is used to
      denote a very limited concept of hierarchy.  If a colon is present
      then the items on both sides of it are valid names.  In general,
      if a name has a colon then the item on the left hand side
      represents a class of those items that would contain other items
      of that class.  For example, a name can be assigned to the entire
      list of DNS resource record type codes as well as for each
      individual code.  The URN for the list might look like this:

            urn:ietf:params:dns:rr-type-codes

      while the URN for the SOA records type code might look like this:

            urn:ietf:params:dns:rr-type-codes:soa

It appears that "urn:ietf:params:xml:ns:xcon" is not a valid name. Thus
"urn:ietf:params:xml:ns:xcon-ccmp" seems better. Notice also that the
XCON conference info URN is "urn:ietf:params:xml:ns:xcon-conference-info"
not "urn:ietf:params:xml:ns:xcon:conference-info".

4. Section 9 states:

  a conferencing server may not be a fully compliant HTTP server

Do you mean "might" or "MAY"? I.e., is it OPTIONAL for a conferencing
server to fully comply with HTTP?

[Ballot comment]
#1) Section 5.1 subject references AAA, a reference is needed - it kind of came out of the blue.

[MB] Okay. [/MB]

#2) Sec 6 message 1 has:

xcon-userid:alice@example.com

shouldn't it be:

xcon-userid:Alice@example.com

[MB] Yes, this needs to be corrected. [/MB]

#3) Sec 9 - "REQUIRED" is not 2119 language.

[MB] "REQUIRED" is in the 2119 template that we used and is specified in  RFC 2119 in the following context:

1. MUST  This word, or the terms "REQUIRED" or "SHALL", mean that the
  definition is an absolute requirement of the specification.

[/MB]

[spt] duh - homer simpson moment. [/spt]

#4) Sec 10.1: r/the client must be
  able to validate the certificate./the client MUST be
  able to validate the certificate.

[MB] Okay. [/MB]

#5) Sec 10.1 - A reference to RFC 6125 is needed to ensure the server's ID is properly checked.

[MB] Are you suggesting that we change the following sentence to something like the following?
OLD:
  Note that in order for the
  presented certificate to be valid at the client, the client must be
  able to validate the certificate.
NEW:
  Note that in order for the
  presented certificate to be valid at the client, the client must be
  able to validate the certificate, using a mechansim such as that specified in RFC 6125.
[/MB]

[spt] this or a pointer to 2818.

[Ballot comment]
#1) Section 5.1 subject references AAA, a reference is needed - it kind of came out of the blue.

[MB] Okay. [/MB]

#2) Sec 6 message 1 has:

xcon-userid:alice@example.com

shouldn't it be:

xcon-userid:Alice@example.com

[MB] Yes, this needs to be corrected. [/MB]

#3) Sec 9 - "REQUIRED" is not 2119 language.

[MB] "REQUIRED" is in the 2119 template that we used and is specified in  RFC 2119 in the following context:

1. MUST  This word, or the terms "REQUIRED" or "SHALL", mean that the
  definition is an absolute requirement of the specification.

[/MB]

[spt] duh - homer simpson moment. [/spt]

#4) Sec 10.1: r/the client must be
  able to validate the certificate./the client MUST be
  able to validate the certificate.

[MB] Okay. [/MB]

#5) Sec 10.1 - A reference to RFC 6125 is needed to ensure the server's ID is properly checked.

[MB] Are you suggesting that we change the following sentence to something like the following?
OLD:
  Note that in order for the
  presented certificate to be valid at the client, the client must be
  able to validate the certificate.
NEW:
  Note that in order for the
  presented certificate to be valid at the client, the client must be
  able to validate the certificate, using a mechansim such as that specified in RFC 6125.
[/MB]

[spt] this would work for me.

[Ballot discuss]
This is an updated discuss.  I've included the authors responses to the first 4 between [MB] and [/MB].  #5 and #6 are new.

#1) This document sometimes uses optional and mandatory to indicate support requirements.  These should be changed to use 2119 language.  E.g., in 5.1, 5.2, and 5.3.12.

[MB] Agreed. [/MB]

#2) Sec 4 includes the following:

The specification recommends the use of HTTP as
a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies.

Should it be "RECOMMEND"?  There were musts earlier but I think they were specified in other RFCs.

[MB] Definitely yes. [/MB]

#3) Sec 4.4 includes the following:

In addition, to mitigate
the situation clients MUST NOT wait indefinitely for a response and
MUST implement a timer (in the range of seconds) such that when it
expires, the client MUST close the connection

Is there some recommendation you could give about how long to wait?  1 minute, 5 minutes?

[MB] It should be in 10s of seconds.  I think 60 secs would be an upper range. I'm inclined to suggest 30 secs as the default. [/MB]

#4) Sec 5.3.5 includes the following:

  Through a "usersRequest" message the CCMP client manipulates the XML
    element of the conference document associated with the
  conference identified by the "confObjID" parameter complusory
  included in the request.

Is "complusory" supposed to mean it's mandatory?  It would be better to just use the 2119 language.

[MB] Yes. [/MB]

#5) I couldn't find an explicit statement that clients and server MUST support both the request and response.  Do we need that or is it assumed?

#6) In the CCMP Request there are 5 fields defined.  All are optional.  Doesn't at least one field need to be a MUST? If there's no required field - can an implementation that sends no fields in a CCMP Request considered compliant?  I had the same kind of comment against the xcom-common-data-model: It seems odd to me that the protocol would specify sub-elements all of which are optional.  Maybe this is done all the time in XML land and I'm just picking on this draft?  In ASN.1-land, where I'm from, it's like having a CHOICE and not explaining which one of the choices is a MUST.

[Ballot comment]
[In progress - Will likely become DISCUSS]

This document is too long. Much of it can be attributed to importing text from other normatively referenced documents. Some of it can be attributed to being too verbose and just a poor writing style. I think this needs to be fixed.

Strike all of section 3. Completely redundant with RFC 5239.

Intro to section 4:

  CCMP is a client-server, XML-based protocol, which has been
  specifically conceived to provide users with the necessary means for
  the creation, retrieval, modification and deletion of conference
  objects.  CCMP is also state-less, which means implementations can
  safely handle transactions independently from each other.
  Conference-related information is encapsulated into CCMP messages in
  the form of XML documents or XML document fragments compliant with
  the XCON data model representation.

That's a bit fluffy. How about instead:

  CCMP is a client-server, XML-based protocol for user creation,
  retrieval, modification and deletion of conference objects.  CCMP
  is a stateless protocol, such that implementations can safely
  handle transactions independently from each other.  CCMP messages
  are XML documents or XML document fragments compliant with the
  XCON data model representation. [REF?]
 
Might I suggest that anywhere you find the word "conceived" in this document (see elsewhere in the intro to 4, 5.3.1, and 6.9) there is an opportunity to do some shortening and clarification.

The intro to section 4 gives an implementation requirement without using 2119 language:

  Each operation in the protocol model, as summarized in Section 4.1 is
  atomic and either succeeds or fails as a whole.  The conference
  server must ensure that the operations are atomic in that the
  operation invoked by a specific conference client completes prior to
  another client's operation on the same conference object.

4.2 would be much easier to read if you stated the requirement (that responses with documents MUST have a version) first and then gave the explanation. Implementers don't need dramatic build-up. Get to the point. Then most of the explanation can be reduced.

4.3 needs a reference to the data model document.

4.4 first paragraph (or two; I can't tell if what spans the page break is 1 paragraph or two)
can be reduced to:

  CCMP is implemented using HTTP, placing the CCMP request messages into
  the body of an HTTP POST operation and placing the CCMP responses into
  the body of the HTTP response messages. For information as to why this
  implementation method was chosen, refer to Appendix A.

Then trim the second to last paragraph of 4.4 to get rid of redundancies.

5.2 defines the "version" parameter as optional. However, there are clearly instances (specified) where it is required. 5.2 should probably indicate that.

[Ballot comment]
[In progress]

This document is too long. Much of it can be attributed to importing text from other normatively referenced documents. Some of it can be attributed to being too verbose and just a poor writing style. I think this needs to be fixed.

Strike all of section 3. Completely redundant with RFC 5239.

Intro to section 4:

  CCMP is a client-server, XML-based protocol, which has been
  specifically conceived to provide users with the necessary means for
  the creation, retrieval, modification and deletion of conference
  objects.  CCMP is also state-less, which means implementations can
  safely handle transactions independently from each other.
  Conference-related information is encapsulated into CCMP messages in
  the form of XML documents or XML document fragments compliant with
  the XCON data model representation.

That's a bit fluffy. How about instead:

  CCMP is a client-server, XML-based protocol for user creation,
  retrieval, modification and deletion of conference objects.  CCMP
  is a stateless protocol, such that implementations can safely
  handle transactions independently from each other.  CCMP messages
  are XML documents or XML document fragments compliant with the
  XCON data model representation. [REF?]
 
Might I suggest that anywhere you find the word "conceived" in this document (see elsewhere in the intro to 4, 5.3.1, and 6.9) there is an opportunity to do some shortening and clarification.

The intro to section 4 gives an implementation requirement without using 2119 language:

  Each operation in the protocol model, as summarized in Section 4.1 is
  atomic and either succeeds or fails as a whole.  The conference
  server must ensure that the operations are atomic in that the
  operation invoked by a specific conference client completes prior to
  another client's operation on the same conference object.

4.2 would be much easier to read if you stated the requirement (that responses with documents MUST have a version) first and then gave the explanation. Implementers don't need dramatic build-up. Get to the point. Then most of the explanation can be reduced.

4.3 needs a reference to the data model document.

4.4 first paragraph (or two; I can't tell if what spans the page break is 1 paragraph or two)
can be reduced to:

  CCMP is implemented using HTTP, placing the CCMP request messages into
  the body of an HTTP POST operation and placing the CCMP responses into
  the body of the HTTP response messages. For information as to why this
  implementation method was chosen, refer to Appendix A.

Then trim the second to last paragraph of 4.4 to get rid of redundancies.

5.2 defines the "version" parameter as optional. However, there are clearly instances (specified) where it is required. 5.2 should probably indicate that.

[Ballot comment]
What is the scope of the uniqueness for an XCON-USERID?  Is
XCON-USERID intended to be used across multiple conferences or is it
specific to a conference?

[Ballot comment]
#1) Section 5.1 subject references AAA, a reference is needed - it kind of came out of the blue.

#2) Sec 6 message 1 has:

xcon-userid:alice@example.com

shouldn't it be:

xcon-userid:Alice@example.com

#3) Sec 9 - "REQUIRED" is not 2119 language.

#4) Sec 10.1: r/the client must be
  able to validate the certificate./the client MUST be
  able to validate the certificate.

#5) Sec 10.1 - A reference to RFC 6125 is needed to ensure the server's ID is properly checked.

[Ballot comment]
#1) Section 5.1 subject references AAA, a reference is needed - it kind of came out of the blue.

#2) Sec 6 message 1 has:

xcon-userid:alice@example.com

shouldn't it be:

xcon-userid:Alice@example.com

#3) Sec 9 - "REQUIRED" is not 2119 language.

#4) Sec 10.1: r/the client must be
  able to validate the certificate./the client MUST be
  able to validate the certificate.

[Ballot discuss]
#1) This document sometimes uses optional and mandatory to indicate support requirements.  These should be changed to use 2119 language.  E.g., in 5.1, 5.2, and 5.3.12.

#2) Sec 4 includes the following:

The specification recommends the use of HTTP as
a transport solution, including CCMP requests in HTTP POST messages
and CCMP responses in HTTP 200 OK replies.

Should it be "RECOMMEND"?  There were musts earlier but I think they were specified in other RFCs.

#3) Sec 4.4 includes the following:

In addition, to mitigate
the situation clients MUST NOT wait indefinitely for a response and
MUST implement a timer (in the range of seconds) such that when it
expires, the client MUST close the connection

Is there some recommendation you could give about how long to wait?  1 minute, 5 minutes?

#4) Sec 5.3.5 includes the following:

  Through a "usersRequest" message the CCMP client manipulates the XML
    element of the conference document associated with the
  conference identified by the "confObjID" parameter complusory
  included in the request.

Is "complusory" supposed to mean it's mandatory?  It would be better to just use the 2119 language.

IANA understands that, upon approval of this document, there are seven
IANA Actions that need to be completed.

First, in the Namespace registry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new XML namespace is to be registered as follows:

ID: ccmp
URI: urn:ietf:params:xml:ns:xcon:ccmp
Registration template: [ as provided section 12.1 of the approved document ]
Reference: [ RFC-to-be ]

Second, in the Schema registry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new XML schema is to be registered as follows:

ID: ccmp
URI: urn:ietf:params:xml:schema:xcon:ccmp
Filename: [ as provided in section 11 of the approved document ]
Reference: [ RFC-to-be ]

Third, in the Application Media Types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

a new media type is to be registered as follows:

MIME media type name: application
MIME subtype name: ccmp+xml
Reference: [ RFC-to-be ]

Fourth, in the S-NAPTR Application Service Tags registry in the
Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

a new Application Service Tag will be registered as:

Tag: XCON
Reference: [ RFC-to-be ]

Fifth, in the S-NAPTR Application Protocol Tags registry in the
Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

a new Application Protocol Tag will be registered as:

Tag: CCMP
Reference: [ RFC-to-be ]

Sixth, IANA is to create a new registry called the "CCMP Message Type"
registry. The reference for the new registry is [ RFC-to-be ]. The
registration procedure for the new registry is: specification required.

There are a set of initial registrations in the new registry. They are
as follows:

Message Type: optionsRequest
Description: Used by a conference control client to query a conferencing
system for its capabilities, in terms of supported messages (both
standard and non-standard).
Reference: [ RFC-to-be ]

Message Type: optionsResponse
Description: The optionsResponse returns a list of CCMP messages (both
standard and non-standard) supported by the specific conference server.
Reference: [ RFC-to-be ]

Message Type: blueprintsRequest
Description: Used by a conference control client to query a conferencing
system for its capabilities, in terms of available conference blueprints.
Reference: [ RFC-to-be ]

Message Type: blueprintsResponse
Description: The blueprintsResponse returns a list of blueprints
supported by the specific conference server.
Reference: [ RFC-to-be ]

Message Type: confsRequest
Description: Used by a conference control client to query a conferencing
system for its scheduled/active conferences.
Reference: [ RFC-to-be ]

Message Type: confsResponse
Description: The "confsResponse" returns the list of the currently
activated/scheduled conferences at the server.
Reference: [ RFC-to-be ]

Message Type: confRequest
Description: The "confRequest" is used to create a conference object
and/or to request an operation on the conference object as a whole.
Reference: [ RFC-to-be ]

Message Type: confResponse
Description: The "confResponse" indicates the result of the operation on
the conference object as a whole.
Reference: [ RFC-to-be ]

Message Type: userRequest
Description: The "userRequest" is used to request an operation on the
"user" element in the conference object.
Reference: [ RFC-to-be ]

Message Type: userResponse
Description: The "userResponse" indicates the result of the requested
operation on the "user" element in the conference object.
Reference: [ RFC-to-be ]

Message Type: usersRequest
Description: This "usersRequest" is used to manipulate the "users"
element in the conference object, including parameters such as the
"allowed-users-list", "join-handling", etc.
Reference: [ RFC-to-be ]

Message Type: usersResponse
Description: This "usersResponse" indicates the result of the request to
manipulate the "users" element in the conference object.
Reference: [ RFC-to-be ]

Message Type: sidebarRequest
Description: This "sidebarRequest" is used to retrieve the information
related to a sidebar or to create, change or delete a specific sidebar.
Reference: [ RFC-to-be ]

Message Type: sidebarResponse
Description: This "sidebarResponse" indicates the result of the
sidebarRequest.
Reference: [ RFC-to-be ]

Seventh, IANA is to create a new registry called the "CCMP Response
Code" registry. The reference for the new registry is [ RFC-to-be ].The
registration procedure for the new registry is: specification required.

There are a set of initial registrations in the new registry. They are
as follows:

Response code: 200
Description: This code indicates that the request was successfully
processed.
Reference: [ RFC-to-be ]

Response code: 409
Description: This code indicates that a requested "update" cannot be
successfully completed by the server. An example of such situation is
when the modification of an object cannot be applied due to conflicts
arising at the server's side (e.g. because the client version of the
object is an obsolete one and the requested modifications collide with
the up-to-date state of the object stored at the server).
Reference: [ RFC-to-be ]

Response code: 400
Description: This code indicates that the request was badly formed in
some fashion.
Reference: [ RFC-to-be ]

Response code: 401
Description: This code indicates that the user was not authorized for
the specific operation on the conference object.
Reference: [ RFC-to-be ]

Response code: 403
Description: This code indicates that the specific operation is not
valid for the target conference object.
Reference: [ RFC-to-be ]

Response code: 404
Description: This code indicates that the specific conference object was
not found.
Reference: [ RFC-to-be ]

Response code: 420
Description: This code is returned in answer to a "userRequest/create"
operation, in the case of a third-party invite, when the "confUserID"
(contained in the "entity" attribute of the "userInfo" parameter) of the
user to be added is unknown.
Reference: [ RFC-to-be ]

Response code: 421
Description: This code is returned in the case of requests in which the
"confUserID" of the sender is invalid.
Reference: [ RFC-to-be ]

Response code: 422
Description: This code is returned in response to all requests wishing
to access/manipulate a password-protected conference object, when the
"conference-password" parameter contained in the request is wrong.
Reference: [ RFC-to-be ]

Response code: 423
Description: This code is returned in response to all requests wishing
to access/manipulate a password-protected conference object, when the
"conference-password" parameter is missing in the request.
Reference: [ RFC-to-be ]

Response code: 424
Description: This code is returned in response whenever the server wants
to authenticate the requestor through the "subject" parameter and such a
parameter is not provided in the request.
Reference: [ RFC-to-be ]

Response code: 425
Description: This code indicates that the conferencing system cannot
delete the specific conference object because it is a parent for another
conference object.
Reference: [ RFC-to-be ]

Response code: 426
Description: This code indicates that the target conference object
cannot be changed (e.g., due to policies, roles, privileges, etc.).
Reference: [ RFC-to-be ]

Response code: 510
Description: This code indicates that the request could not be processed
within a reasonable time, with the time specific to a conferencing
system implementation.
Reference: [ RFC-to-be ]

Response code: 500
Description: This code indicates that the conferencing system
experienced some sort of internal error.
Reference: [ RFC-to-be ]

Response code: 501
Description: This code indicates that the specific operation is not
implemented on that conferencing system.
Reference: [ RFC-to-be ]

IANA understands that these seven actions are the only IANA Actions
required upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Centralized Conferencing Manipulation Protocol) to Proposed Standard


The IESG has received a request from the Centralized Conferencing WG
(xcon) to consider the following document:
- 'Centralized Conferencing Manipulation Protocol'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-xcon-ccmp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-xcon-ccmp/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Alan Johnston is the Document Shepherd. I have personally reviewed the
draft-ietf-xcon-ccmp-10.txt version of this document and
believe it is ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has had good review both within and outside the working
group. I have no concerns about the reviews that have been performed.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No known issues. No known IPR.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The XCON Working Group has a relatively small, but committed group of
about a dozen individuals who have participated over many years and
contributed large amounts of effort and text. We have developed our
consensus around this document slowly. As such, I believe it is a
strong consensus.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

The document does have normative and informative references.

If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes.

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries?

Yes.

Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This document registers a new XML namespace, a new XML schema, and
the MIME type for the schema, the "XCON" Application Service tag,
the "CCMP" Application Protocol tag. This document also defines
registries for the CCMP operation types and response codes.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?



The IESG has approved the following document:

- 'Centralized Conferencing Manipulation Protocol'
as a Proposed Standard

This document is the product of the Centralized Conferencing Working
Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-10.txt

Technical Summary

The Centralized Conferencing Manipulation Protocol (CCMP) allows a
multimedia conferencing system client to create, retrieve, change,
and delete objects that describe a centralized conference. CCMP is a
means to control basic and advanced conference features such as
conference state and capabilities, participants, relative roles, and
details. CCMP is a stateless, XML-based, client server protocol.

Working Group Summary

This document is a product of the XCON working group.
Its contents have been uncontroversial in working group
discussions.

Document Quality

There are multiple implementations of CCMP.

Personnel

Alan Johnston is the Document Shepherd for this document.
Robert Sparks is the responsible Area Director.

[Note]: '(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Alan Johnston is the Document Shepherd. I have personally reviewed the
draft-ietf-xcon-ccmp-10.txt version of this document and
believe it is ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has had good review both within and outside the working
group. I have no concerns about the reviews that have been performed.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No known issues. No known IPR.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The XCON Working Group has a relatively small, but committed group of
about a dozen individuals who have participated over many years and
contributed large amounts of effort and text. We have developed our
consensus around this document slowly. As such, I believe it is a
strong consensus.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

The document does have normative and informative references.

If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes.

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries?

Yes.

Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This document registers a new XML namespace, a new XML schema, and
the MIME type for the schema, the "XCON" Application Service tag,
the "CCMP" Application Protocol tag. This document also defines
registries for the CCMP operation types and response codes.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?



The IESG has approved the following document:

- 'Centralized Conferencing Manipulation Protocol'
as a Proposed Standard

This document is the product of the Centralized Conferencing Working
Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-10.txt

Technical Summary

The Centralized Conferencing Manipulation Protocol (CCMP) allows a
multimedia conferencing system client to create, retrieve, change,
and delete objects that describe a centralized conference. CCMP is a
means to control basic and advanced conference features such as
conference state and capabilities, participants, relative roles, and
details. CCMP is a stateless, XML-based, client server protocol.

Working Group Summary

This document is a product of the XCON working group.
Its contents have been uncontroversial in working group
discussions.

Document Quality

There are multiple implementations of CCMP.

Personnel

Alan Johnston is the Document Shepherd for this document.
Robert Sparks is the responsible Area Director.' added by Cindy Morgan