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
_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon
