Skip to main content

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