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

[Mary Barnes <[e-mail]>]

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
>