Conference Information Data Model for Centralized Conferencing (XCON)
RFC 6501

Note: This ballot was opened for revision 32 and is now closed.

(Robert Sparks) Yes

(Jari Arkko) No Objection

Comment (2011-05-24 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This was an overall OK document. I did have a few small question marks, however:

I am wondering if <language> can contain multiple languages or appear multiple times. The text says nothing exact but seems to indicate just one language. Some of the schema definitions seems to say that multiple languages can appear. Please clarify and align.

Then I had a question on this:
   In order to facilitate the comparison of the XCON-USERID identifiers,
   all the components of the identifiers MUST be converted to lowercase.
   After normalizing the URI strings, the URIs comparison MUST applied a
   character-by-character basis as prescribed by RFC3986, Section 6.2.1.

Question: is this sufficient to deal with internationalized user identifiers?
I'm about as far as one can be from an i18n expert, but I thought there were
situations were you'd have to map characters to other characters in order
to do proper comparisons. Maybe that's not needed for user identifiers.
Please check.

Can notifications come after the end of the conference,  too? 
The data type is integer, not NonNegativeInteger:

              <xs:element name="notify-end-of-conference"
                type="xs:integer" minOccurs="0"/>

Please clarify and ensure you meant all integers.

Are mixing start offsets really absolute time values? By their name, I was expecting an offset not an absolute value. Either approach is fine with me, of course, but perhaps the document needs to say explicitly that the offsets are actually absolute values and not differences to the start/end time.

       element xcon:mixing-start-offset {
         time-type,
         attribute required-participant { single-role-type },
         anyAttribute
       }?,

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-05-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
On the basis of trusting that others who have greater knowledge of this subject matter have reviewed this document I am voting no-objection.

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-05-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
There are enough detailed Discuss points from other people that I can't find much to add.

Please note that you should not include references from the Abstract which is supposed to be stand-alone text.

I was a little surprised that there isn't an Informative reference to draft-ietf-xcon-ccmp.

Is http://www.relaxng.org/ the right reference to give for Relax NG given that it is published as an international standard by ISO?

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-05-22)
No email
send info
(1) Typo: "the URIs comparison MUST applied a character-by-character
basis"

(2) In 3.2.2 if you don't want IP addresses to be used, then why not
just say so? Maybe add text that says that xcon:foo@10.0.0.1 is not
the same as xcon:foo@167772161 (but for one of the proper example IP
addresses) if that's what is meant.

(3) I think this (on p25) could do with rephrasing: "A
'closedAuthenticated' policy MUST have each conference participant in
the allowed users list (listed under the <allowed-users-list> element)
with each participant being sufficiently (up to local policy)
authenticated."

(4) In 4.6.5, maybe s/authenticated user identities/authenticated user
identifiers/ - a pet peeve of mine, but probably more correct as
identifiers.

(5) 4.6.5.3 seems a bit overstated - given that the highest level of
protection still has non-anonymous identifiers for the user in the
common model, calling if anonymous seems wrong and liable to give the
wrong impression. I'd suggest changing the name of this to
"<hide-name>". (This is not a discuss because I guess it could be that
code depending on this name is out there already and its a small
point.) If changing the name's not doable, then maybe add a sentence
that implementations SHOULD make it clear to users that real anonymity
is not being provided.

(Russ Housley) No Objection

(Pete Resnick) (was Discuss, No Objection) No Objection

Comment (2011-09-19)
No email
send info
All issues addressed.

(Dan Romascanu) No Objection

(Peter Saint-Andre) (was Discuss) No Objection

(Sean Turner) (was Discuss) No Objection

(Gonzalo Camarillo) Recuse