Re: [XCON] AD review: draft-ietf-xcon-ccmp-10

[Simon Pietro Romano <[e-mail]>]

Hi guys,

let me jump into the discussion, just to clarify a couple of pints which 
still look a bit obscure...
I'm sorry I wasn't able to get in synch with Mary, before. We had to 
meet in Beijing, but in the end I could not make it :-(.
Please see in-line ([spromano]) my considerations.

 > >> Technical:

 > >>
 > >> * Is there any text that prevents a ccmp request from being empty?
 > >>  (all of the elements in the schema have minOccurs="0"). If not,
 > >>  either some should be added, or the text should say something
 > >>  about how a server should react to a request built this way.
 > > [MB]  [MB] We don't allow an empty request in that you always have a
 > > message type and usually an operation, noting that there there is no
 > > operation for
 > > a blueprintsRequest or confsRequest, as stated in section
 > > 5.1 under the operation parameter description. Each message has other
 > > required and optional parameters and if the
 > > request doesn't have the mandatory parameters, a 400 response would be
 > > sent.  A note in that regards to section 5.3.   [/MB]
 > >

/[spromano] For the sake of completeness, we must say that the CCMP 
schema allows to have empty "optionsRequest" messages.
/
 > >> * The AUTO_GENERATE mechanism's definition is currently hard to find,

 > >>  (it's at the end of 4.1), and easy to miss that it's a normative
 > >>  requirement on server behavior. (I couldn't find the place where
 > >>  the behavior was defined for my first several reads of this 
document).
 > >>  This behavior should be defined with 2119 terms. What definition
 > >>  exists in this section requires the wildcard to have the form of
 > >>  AUTO_GENERATE_X, but there are several examples and places in the 
text
 > >>  (here and in the examples document), particularly for xcon-userid:
 > >>  constructs where AUTO_GENERATE appears without the _X.
 > > [MB]  AUTO_GENERATE_X is an example and it isn't normative.  The
 > > normative aspect is that all the mandatory fields MUST be initialized.
 > > If there is no value, such as for the identifiers, then an
 > > appropriate wildcard string MUST be included.  The
 > > [e-mail] is one of example of the string that can
 > > be used for the XCON-URI.  I had intended to add text related to this,
 > > but in re-reviewing the diff, the changes I thought I made didn't make
 > > it, so this change is still needed and I'll update the doc again as
 > > soon as submissions open up again.   [/MB]
 > >>

/[spromano] I have to admit that the point raised by Robert is an 
important one. I believe that the wildcard identifier MUST be unique for 
all implementations of the protocol: if the server does not see an 
'official' 'AUTO_GENERATE_N' identifier (with 'N' properly set), it 
cannot understand that it (i.e. the server) has to create a brand new 
identifier. The server might just think that the received identifier is 
an existing one and would just go and look for the associated element, 
thus generating an error. /By the way, I checked the documents and I 
realized that we often put in the examples just '/AUTO_GENERATE', 
whereas the correct example wildcard should be '//AUTO_GENERATE_1'. I 
think we must correct this, if everybody (understands and) agrees with 
the proposed approach.
/

 > >> * Can you add a note explaining that the server chooses the contents

 > >>  of the URI when it creates a conference or user? The examples for
 > >>  creating users, such as 6.7, imply that some bits (Ciccio in this 
case)
 > >>  are copied from the request's userInfo into the response's userInfo
 > >>  AUTO_GENERATEd URI. While a server might choose to do something like
 > >>  that, it's not required to.
 > > [MB] A note has been added with regards to the server choosing the
 > > XCON-USERID. Not sure that addresses your second concern. [/MB]
 > >>

/[spromano] Example 6.7 should just be taken as 'an' example. URI 
generation does not necessarily depend on the user's nickname contained 
in the <display-text> element. We made this choice in the document just 
to simplify and increase readability. In case you think this might be 
misleading, we can clarify the point.
/

 > >> * I would like the writeup to name who verified the schema and 
examples

 > >>  (and what tool they used). How did the reviewer ensure the 
snippets of
 > >>  schema in the sections that describe various elements exactly matches
 > >>  the full schema listed in section 11?

/[spromano] Here at the University of Napoli, we had Roberta Presta (who 
is co-authoring the call-flow draft) validate each and every piece of 
XML snippet (both schema and messages) that you find in the latest 
version of the draft. We used for this the JAXB APIs. The same holds for 
the XCON examples document, of course.

Hope this helps move the discussion forward.

Cheers,

Simon


/


Il 07/12/2010 22:33, Mary Barnes ha scritto:
> I'll try to get that done by the end of the week (ideally tomorrow) - 
> sorry it got lost in the meeting and post-meeting shuffle.
>
> Mary.
>
> On Tue, Dec 7, 2010 at 10:37 AM, Robert Sparks <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Mary -
>
>     When do you expect to make the revision you indicate below
>     (adding text about AUTO_GENERATE_X?)
>
>     RjS
>
>     On Oct 26, 2010, at 4:45 PM, Mary Barnes wrote:
>
>     > Robert and WG,
>     >
>     > We have updated the document to address the issues raised below:
>     > http://tools.ietf.org/html/draft-ietf-xcon-ccmp-11
>     >
>     > As well, there are some small updates the XML schema.  The
>     > diff is a useful way to review the changes:
>     >
>     http://tools.ietf.org/wg/xcon/draft-ietf-xcon-ccmp/draft-ietf-xcon-ccmp-11-from-10.diff.html
>     >
>     > I have a few responses inline below [MB] on the changes.
>     >
>     > Regards,
>     > Mary.
>     >
>     > On Tue, Sep 14, 2010 at 10:51 AM, Robert Sparks
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     >> Summary: There are some minor issues to address before moving
>     to IETF LC.
>     >>
>     >> This is a good document - it was very easy to read. Thanks to
>     all who worked
>     >> to get it into the shape it's in.
>     >>
>     >> Administrative:
>     >> * Please send a request to type-review for application/ccmp+xml.
>     > [MB] Alan sent a request. As best as I could tell from the
>     discussion
>     > on the ietf-types mailing list,  the primary issue raised is the
>     same
>     > one that was raised with regards to HELD - making UTF-8
>     mandatory.  I
>     > added text inline with the final changes that we made to HELD around
>     > this issue in section 4.2, which  the use of HTTP and
>     > application/ccmp+xml:
>     >
>     >   The XML documents in the CCMP
>     >   messages MUST be encoded in UTF-8.  This specification follows the
>     >   recommendations and conventions described in [RFC3023],
>     including the
>     >   naming convention of the type ('+xml' suffix) and the usage of the
>     >   'charset' parameter.  The 'charset' parameter MUST be included
>     with
>     >   the XML document.
>     >
>     >>
>     >> * I would like the writeup to name who verified the schema and
>     examples
>     >>  (and what tool they used). How did the reviewer ensure the
>     snippets of
>     >>  schema in the sections that describe various elements exactly
>     matches
>     >>  the full schema listed in section 11?
>     >>
>     >> Technical:
>     >>
>     >> * Is there any text that prevents a ccmp request from being empty?
>     >>  (all of the elements in the schema have minOccurs="0"). If not,
>     >>  either some should be added, or the text should say something
>     >>  about how a server should react to a request built this way.
>     > [MB]  [MB] We don't allow an empty request in that you always have a
>     > message type and usually an operation, noting that there there is no
>     > operation for
>     > a blueprintsRequest or confsRequest, as stated in section
>     > 5.1 under the operation parameter description. Each message has
>     other
>     > required and optional parameters and if the
>     > request doesn't have the mandatory parameters, a 400 response
>     would be
>     > sent.  A note in that regards to section 5.3.   [/MB]
>     >
>     >>
>     >> * The AUTO_GENERATE mechanism's definition is currently hard to
>     find,
>     >>  (it's at the end of 4.1), and easy to miss that it's a normative
>     >>  requirement on server behavior. (I couldn't find the place where
>     >>  the behavior was defined for my first several reads of this
>     document).
>     >>  This behavior should be defined with 2119 terms. What definition
>     >>  exists in this section requires the wildcard to have the form of
>     >>  AUTO_GENERATE_X, but there are several examples and places in
>     the text
>     >>  (here and in the examples document), particularly for xcon-userid:
>     >>  constructs where AUTO_GENERATE appears without the _X.
>     > [MB]  AUTO_GENERATE_X is an example and it isn't normative.  The
>     > normative aspect is that all the mandatory fields MUST be
>     initialized.
>     > If there is no value, such as for the identifiers, then an
>     > appropriate wildcard string MUST be included.  The
>     > [e-mail] <mailto:[e-mail]>
>     is one of example of the string that can
>     > be used for the XCON-URI.  I had intended to add text related to
>     this,
>     > but in re-reviewing the diff, the changes I thought I made
>     didn't make
>     > it, so this change is still needed and I'll update the doc again as
>     > soon as submissions open up again.   [/MB]
>     >>
>     >> * The draft calls out "first party" and "third party" actions,
>     but doesn't
>     >>  define those terms.
>     > [MB] Definitions have been added to the terminology section. [/MB]
>     >>
>     >> * The document should call out why <standard-message-list> and
>     >> <extended-message-list> were separated, and what makes that
>     separation
>     >>  useful. What will an implementation do differently if a
>     message name
>     >>  it doesn't understand shows up in a <standard-message-list> vs
>     in an
>     >> <extended-message-list>?
>     > [MB] Done. [/MB]
>     >>
>     >> * Can you add a note explaining that the server chooses the
>     contents
>     >>  of the URI when it creates a conference or user? The examples for
>     >>  creating users, such as 6.7, imply that some bits (Ciccio in
>     this case)
>     >>  are copied from the request's userInfo into the response's
>     userInfo
>     >>  AUTO_GENERATEd URI. While a server might choose to do
>     something like
>     >>  that, it's not required to.
>     > [MB] A note has been added with regards to the server choosing the
>     > XCON-USERID. Not sure that addresses your second concern. [/MB]
>     >>
>     >> * It should be more clearly stated in 6.9 that the
>     "confSummaryRequest"
>     >>  is hypothetical and is not actually being defined.
>     > [MB] Clarified that it's an example. [/MB]
>     >>
>     >> * The URL sub-namespace registration html is not well formed
>     >>  (There's a spurious <a/>).
>     > [MB] Fixed. [/MB]
>     >>
>     >> * Is there a privacy leak with cloning existing conferences?
>     What text
>     >>  prevents any member from cloning the conference to see who is
>     in what
>     >>  sidebar? Was the intent to not allow cloning of conferences
>     that are
>     >>  in progress?
>     > [MB] We do allow cloning of active
>     > conferences IF the client has the appropriate
>     privileges/authorization
>     > and thus the appropriate privacy is provided.   However,
>     > sidebars are the only situation where that is done and we do
>     have general
>     > text that a conference server SHOULD only allow authorized
>     entities to
>     > perform operations.  Perhaps we need to make that a MUST? I added
>     > add some text in the cloning section that the only scenario
>     > under which an active conference would be cloned would be a sidebar.
>     > [/MB]
>     >>
>     >> * The security considerations section should call out that most
>     CCMP commands
>     >>  can pend indefinitely - clients need to be ready to wait an
>     arbitrary amount
>     >>  of time to get the response (see section 6.3 of xcon-examples
>     and consider
>     >>  Alice not responding and the IVR not timing out, Alice using
>     an automaton
>     >>  to keep the IVR from completing its script when it did have
>     timeout protection,
>     >>  etc. The document should say what a client should do when it
>     is no longer
>     >>  willing to wait (close the underlying connection?), and point
>     out what
>     >>  servers can do if they have lots of pending requests starting
>     to pile up.
>     > [MB] Added text to the 6th item on DoS attacks in the security
>     section
>     > - not sure if that's the exact right place, but hopefully the text
>     > addresses the concern. [/MB]
>     >>
>     >> _______________________________________________
>     >> XCON mailing list
>     >> [e-mail] <mailto:[e-mail]>
>     >> https://www.ietf.org/mailman/listinfo/xcon
>     >>
>
>
>
> _______________________________________________
> XCON mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xcon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: [phone] -- Fax: [phone]
                 e-mail: [e-mail]
           http://www.comics.unina.it/simonpietro.romano

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