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

From: [email-masked]
Date: Mon, 02 Nov 2009 18:44:40 +0100

Hi Simo,

I've just circulated the new draft, together with detailed answers to  
Richard's review. We'll also prepare a detailed answer to your own  
review in the next few days. In the meanwhile, if you have a look at  
version -04, you'll notice that most of your questions/suggestions  
should already be reflected in the document.

I would really appreciate if you can take some more time out of your  
busy schedule to read the document before next Thursday's session!

Thanks a lot in advance,

Simon

Quoting [email-masked]:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xcon
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/