Subject: [XCON] Comments on draft-ietf-xcon-ccmp-06.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Mar 2010 14:09:48 +0200

Hi,

a few comments on the following draft:

http://www.ietf.org/id/draft-ietf-xcon-ccmp-06.txt

I would split the Abstract in several sentences so that it is clearer.
Something like the following:

  "The Centralized Conferencing Manipulation Protocol (CCMP) allows an
   XCON 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 state-less, XML-based, client server protocol that carries,
   in its request and response messages, conference information in the
   form of XML documents and fragments conforming to the centralized
   conferencing data model schema."

The last paragraph of the Introduction mentions a few sections. For
completeness, I would mention all the sections of the document so that
its whole structure is clear to the reader.

Remove the option that forces sections to start at the beginning of a
page. It is a waste of space.

Merge sections 2 and 3 in a common Terminology section.

I think the last sentence of Section 4.1 is too long. It could be made
two sentences.

The last paragraph of Section 4.2 could be clarified. It is a bit confusing.

I think we should work a bit more on the structure of the document. I
like the fact that Section 4 puts this protocol into a larger context
(i.e., that of the XCON framework). However, I do not think Section 4
should include normative statements. It should simply describe where
this protocol fits in the XCON framework in a non normative way.

Including a protocol overview section is also a good idea. However,
protocol overview sections are typically non-normative high-level
descriptions of the protocol. They give readers the necessary
information for them to better understand the normative protocol
specification that comes afterwards. So, I would remove all normative
statements from Section 5 as well.

I would also clarify that the examples in Section 7 are not normative.

Section 9. The sentence that starts with "This would REQUIRE" is not
clear enough. It should be clearer when this normative statement applies.

The following sentence mixes clients and servers. It could be clarified
as well:

  "PC-based clients behind NATs could provide a SIP
   event URI, whereas web servers would probably find the HTTP model
   much easier to program."

Section 9 describes several possibilities in which a conference can be
implemented (e.g., using different signalling protocols). It would be
good if that section discussed who makes that decision and the
interoperability implications it has. If there is something that is
mandatory to implement, it should be mentioned. Otherwise, explaining
that, for example, a SIP-based client will not be able to receive
non-SIP-based notifications would be useful.

In Japan, the WG decided to leave policy out of scope. This document
should explain that fact and its implications. That is, what type of
functionality is missing because we currently lack a policy mechanism.

Thanks,

Gonzalo