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

[Robert Sparks <[e-mail]>]

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
>>