Subject: [XCON] My review of draft-ietf-xcon-ccmp-03

From: <[email-masked]>
Date: Thu, 22 Oct 2009 12:21:58 +0200

Hello,

I have now completed my review of draft-ietf-xcon-ccmp-03, for which I volunteered in Stockholm meeting. I apologize for the embarrasingly long time this took.

Document: draft-ietf-xcon-ccmp-03
Reviewer: Simo Veikkolainen
Review date: Oct 22, 2009

General comments
----------------

The document seems to be in a good shape, I only had minor concerns and comments. Note that I didn't review the schema because as I'm not very fluent in XML.

P. 7 "... the conference server SHOULD indicate that the data has been modified and return the current conference object to the client." It might be beneficial that some operations succeed even if the object does not reflect the current state. Example: adding a user.

P. 13 "[...] delete: to remove from the system a conference object or a conference user" Does this apply also to conference sidebars?

P. 36 When updating conference information, it was not always clear whether the 'xxxInfo' should contain the entire element as defined by the XCON data model, or is it possible to update just part of the element. For example, when performing sending userRequest with operation 'update', does the userInfo contain a complete <user> element as defined by the data model? This should be clearly indicated when describing each update operation.

P. 72 The documents states that "For the case of users joining the conference using the CCMP, TLS is RECOMMENDED". However, this does not cover client authentication. What should the client authentication mechanism to be (in case of CCMP), especially when Section 11 says a conferencing client SHOULD NOT be required to support HTTP authentication.

P. 73 Section 12.3 states that the privacy of the conference users is accomplished by manipulation of the "provide-anonymity" element. The description of how the "provide-anonymity" element is manipulated leaves some issues: for example, is it allowed to delete the "provide-anonymity" element, and if yes, how can this be done?

P. 65 An example of how Alice removes a participant from the conference would be useful.

Editorial and nits
-------------------
- check the usage of REQUIRED keyword in the whole document. Often, the word is capitalized when actually there is no normative statement made. For example: "[...] no additional information is REQUIRED in the 'confResponse'" on page 29.

P. 15 "A specialized response message MUST [...]" should be "A specialized request message MUST [...]"

P. 29 "In case of of a confRequest" -> duplicate "of"

P. 29 "A response code of 'success' indicates that the referenced conference document has not been changed by the conference server." This should be "[...] has been changed [...]", right?

P. 31 "If the 'userInfo' parameter is included [...]" Parameter name should be 'usersInfo'

P. 34 Delete "We remark that" from the beginning of the second paragraph.

P. 36 "In both cases [...]" Which both cases do you refer to?

P. 36 "In case of of [...]" Delete latter "of"

P. 36 "[...] MUST be included in the 'confResponse' and the 'userInfo' parameter MUST contain the entire <user> element which to which [...]" -> delete "which to"

P. 53 in the signalling diagram, what is "bp123"? Shouldn't this be the XCON URI?

P. 58 Similarly, what is "conf456Updates" in the signalling diagram?

P. 71 1st bullet: reference is missing.

P. 71 2nd bullet: MSUT -> MUST. I would also reword this to require that the client must be able check the server's identity (using a certificate). 

Regards,
Simo