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

[Mary Barnes <[e-mail]>]

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:

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