Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-32
Yes
(Robert Sparks)
No Objection
(Dan Romascanu)
(Peter Saint-Andre)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)
Recuse
(Gonzalo Camarillo)
Note: This ballot was opened for revision 32 and is now closed.
Robert Sparks Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-05-26)
Unknown
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?
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2011-05-24)
Unknown
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 }?,
Pete Resnick Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2011-09-19)
Unknown
All issues addressed.
Peter Saint-Andre Former IESG member
(was Discuss)
No Objection
No Objection
(2011-09-19)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2011-06-08)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2011-05-22)
Unknown
(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.
Stewart Bryant Former IESG member
No Objection
No Objection
(2011-05-23)
Unknown
On the basis of trusting that others who have greater knowledge of this subject matter have reviewed this document I am voting no-objection.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
Recuse
Recuse
()
Unknown