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

[Mary Barnes <[e-mail]>]

Simon,

Thanks for looking at this in detail. My responses inline below [MB2].

Mary.

On Thu, Dec 9, 2010 at 8:59 AM, Simon Pietro Romano <[e-mail]>wrote;wrote:

>  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.
> *
>
[MB2] I had thought that at a minimum the optionsRequest message must
contain a confUserID as described in the paragraph after the bulleted list
in section 5.3.12:
   The only parameter needed in the optionsRequest is the sender
   confUserID, which is mirrored in the homologous parameter of the
   corresponding optionsResponse.

At a minimum we should change the word "needed" to either REQUIRED or MAY.
 If it's MAY, then we need to described how the message is handled in the
case where there isn't a confUserID.  Is one assigned, etc.?

Either way, we need to update the text in the paragraph following the list
of message types in section 5.3 to include optionsRequest/optionsResponse as
another message pair that doesn't require an operation (along
with blueprintsRequest/blueprintsResponse and confsRequest/confsResponse as
currently stated).
[/MB2]

* *
>
> > >> * 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.
> *
>
[MB2]  It's not at all clear to me why there is a need for a
unique/"official" dummy UserID in the request to create a new UserID.  The
intent of the userRequest with a create operation is to create a generate an
"official" XCON-USERID at the conferencing server.  I did not understand the
intent to be that these were globally unique nor that the client really
cared what value it might receive, since they are all managed by the
conference server.  I can see in the case that a conferencing client is
requested to add a number of users to a conference, none of whom have an
XCON-USERID that it might be helpful for the dummy UserID in the conference
object to be unique. But, I still can't see the motivation for an official
schema for that. If there is a normative requirement for these to have
certain values, then we need some sort of registry and a mechanism to
configure the client or for the client to retrieve appropriate values to be
used.  But, in that case, why not just have the client go to retrieve the
unique values and just skip having the conferencing server assign the unique
values?  Basically, it's not clear to me why the client needs to ensure
uniqueness for the identifiers when it's up to the conferencing system to
allocate.
[/MB2]

> * *
> > >> * 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]>wrote;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]>
>> 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] 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]
>> >> https://www.ietf.org/mailman/listinfo/xcon
>> >>
>>
>>
>
> _______________________________________________
> XCON mailing [e-mail]://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~~~~~~~~~~~~~~~~~~~~~~~~~
>                           \ (    (   )
>                            \_)    ) /
>                                  (_/
>
>
>