Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-32

[Ballot discuss]
[Still applies to -31]
After getting most of the way though draft-ietf-xcon-ccmp and draft-ietf-xcon-examples-08, I have decided to move this to DISCUSS. These three documents repeat things from documents to which they normatively refer. Aside from increasing the overall length of what are already very long documents, I think this actually introduces a danger that the documents will "get out of sync": If the normative text happens to differ between the documents, it's unclear which is authoritative. If there's disagreement in even non-normative text, it introduces the potential for confusion. I really think the redundant text needs to be eliminated and the documents shortened.

In this document: RFCs 3986, 4575, and 5239 are all normative references and are absolutely required reading to use this document. Therefore I don't see any reason for all of the redundancies in this document, and note the potential for problems above. So:

Intro - Paragraphs 2, 3, 4 and figure are redundant and unneeded. Strike.

(Indeed, figure 1 is subtly different from the ones in 5239. Maybe not in any important way, but why introduce the potential for confusion.)

4.1 - Shorten:

  A conference object document begins with the root element
  , which is defined in [RFC4575].  The
  attributes 'state' and 'version' defined in [RFC4575] are
  not used for this element in this specification because these
  attributes only apply to notification mechanisms.

  This specification adds the child element
  to the  element.

4.2 - Shorten:

  The  element, which is defined in [RFC4575],
  describes the conference as a whole.  This specification adds the
  child elements , , , , and . This specification also adds a new
    child element to the  child element of the
    child element, and adds the , , and
    child elements to the  child element of the
    child element.

Strike 4.2.2, 4.2.3, 4.2.4, 4.2.5

4.2.10 - Just define  here.

Strike 4.2.11, 4.2.12

4.2.13 - Just define , , and  here.

Strike 4.3, 4.4.2, 4.4.3, 4.4.4, 4.6.5.1, 4.6.5.2, 4.6.5.5, 4.6.5.6

[Ballot comment]
ABNF issue: In 3.3.1, conf-object-id is very liberal. Is everyone OK with the idea of a conf-object-id of "---...+++===///"? (I understand that 3986 also allows "---...", but I'm just checking. [Update 2011-05-24: The author claims this is desirable. I am willing to take his word for it, but leave this comment in just in case.]

Editorial: Top of section 4 - The use of the word "operator" twice here is goofy. [Fixed.]

Also, why is the figure specified as "non-normative". What could be taken as normative in there?

4.2.1 - "defined in IANA [IANA-Lan]". That looks funny. [Fixed.]

4.2 - Why is "lang" on the  rather than on its children? And why does it need to be called out normatively in this document? (Shouldn't all elements have a lang aatribute? Why is this one special?)

[Ballot discuss]
Updated on 2011-06-17 to reflect publication of version -30...

1. [fixed]

2. [clarified via discussion]

3. [fixed]

4. [clarified via discussion]

5. [clarified via discussion]

6. [fixed]

7. Section 4.2 states:

  The  element, which is defined in [RFC4575],
  describes the conference as a whole.  It SHOULD have an attribute
  'lang' to specify the language used in the contents of this element.

However, the 'lang' attribute is not specified in RFC 4575 schema. The
RelaxNG definition in this document includes not 'lang' but 'xml:lang':

conference-description-type =
  element conference-description {
    attribute xml:lang { xsd:language }?

If you mean 'xml:lang' instead of 'lang' then please say so.

NOTE: I really think this should be 'xml:lang' because that does not
require a change to the schema and therefore we are not updating
RFC 4575 (any XML element can include 'xml:lang' by inheritance).

8. [fixed]

9. [clarified via discussion, this was WG consensus]

10. [clarified via discussion]

11. [clarified via discussion]

12. [fixed]

[Ballot discuss]
Updated on 2011-06-17 to reflect publication of version -30...

1. [fixed]

2. [clarified via discussion]

3. [fixed]

4. [clarified via discussion]

5. Please add a note that the XCON-URI construction does not directly
support characters outside the ASCII range, but that such characters can
be encoded (at least in the "host" portion) using the rules in RFC 3987.

6. [fixed in Section 4.1]

Please fix this elsewhere -- for example in Sections 4.6, 4.6.5, 4.7, and 4.8.

7. Section 4.2 states:

  The  element, which is defined in [RFC4575],
  describes the conference as a whole.  It SHOULD have an attribute
  'lang' to specify the language used in the contents of this element.

However, the 'lang' attribute is not specified in RFC 4575 schema. The
RelaxNG definition in this document includes not 'lang' but 'xml:lang':

conference-description-type =
  element conference-description {
    attribute xml:lang { xsd:language }?

If you mean 'xml:lang' instead of 'lang' then please say so.

NOTE: I really think this should be 'xml:lang' because that does not
require a change to the schema and therefore we are not updating
RFC 4575 (any XML element can include 'xml:lang' by inheritance).

8. [fixed]

9. [clarified via discussion, this was WG consensus]

10. Section 4.2.9 states the following about the
element (same for ):

      The  has the mandatory
      'required-participant' attribute.  This attribute contains one of
      the following values: "none", "administrator", "moderator",
      "user", "observer", and "participant".  The roles' semantic
      definitions are out of the scope of this document and is subject
      to future policy documents.  More values can be specified in the
      future.

Not defining the attribute values seems problematic. Yes, we all have
a common-sense idea of what administrators and moderators (etc.) are,
but why leave the definitions to future policy documents? And given
that more values can be specified in the future, is a registry in
order?

11. [clarified via discussion]

12. [fixed]

[Ballot discuss]
(1) I agree with the secdir reviewer (Tero Kivinen) [1] that passwords
and personally identifying information do warrant specific protection
in the DB. The security considerations seems to nearly, but not quite
do this, when it says that the DB SHOULD be accessed via TLS or
equivalent. However, I think you need two more things: a) to say when
its ok to not follow the SHOULD but also b) you need to RECOMMEND that
the (sensitive parts of the) DB be encrypted as stored in long term
storage (i.e. disk) which is different from how its accessed via the
network.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html

[Ballot comment]
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?

[Ballot comment]
ABNF issue: In 3.3.1, conf-object-id is very liberal. Is everyone OK with the idea of a conf-object-id of "---...+++===///"? (I understand that 3986 also allows "---...", but I'm just checking. [Update 2011-05-24: The author claims this is desirable. I am willing to take his word for it, but leave this comment in just in case.]

Editorial: Top of section 4 - The use of the word "operator" twice here is goofy. This is notation, not a formal operation. I say just strike it. [Update 2011-05-24: To be fixed.]

Also, why is the figure specified as "non-normative". What could be taken as normative in there? [Update 2011-05-25: To be fixed.]

4.2.1 - "defined in IANA [IANA-Lan]". That looks funny. [Update 2011-05-24: To be fixed.]

4.2 - Why is "lang" on the  rather than on its children? And why does it need to be called out normatively in this document? (Shouldn't all elements have a lang aatribute? Why is this one special?)

[Ballot discuss]
After getting most of the way though draft-ietf-xcon-ccmp and draft-ietf-xcon-examples-08, I have decided to move this to DISCUSS. These three documents repeat things from documents to which they normatively refer. Aside from increasing the overall length of what are already very long documents, I think this actually introduces a danger that the documents will "get out of sync": If the normative text happens to differ between the documents, it's unclear which is authoritative. If there's disagreement in even non-normative text, it introduces the potential for confusion. I really think the redundant text needs to be eliminated and the documents shortened.

In this document: RFCs 3986, 4575, and 5239 are all normative references and are absolutely required reading to use this document. Therefore I don't see any reason for all of the redundancies in this document, and note the potential for problems above. So:

Intro - Paragraphs 2, 3, 4 and figure are redundant and unneeded. Strike.

(Indeed, figure 1 is subtly different from the ones in 5239. Maybe not in any important way, but why introduce the potential for confusion.)

4.1 - Shorten:

  A conference object document begins with the root element
  , which is defined in [RFC4575].  The
  attributes 'state' and 'version' defined in [RFC4575] are
  not used for this element in this specification because these
  attributes only apply to notification mechanisms.

  This specification adds the child element
  to the  element.

4.2 - Shorten:

  The  element, which is defined in [RFC4575],
  describes the conference as a whole.  This specification adds the
  child elements , , , , and . This specification also adds a new
    child element to the  child element of the
    child element, and adds the , , and
    child elements to the  child element of the
    child element.

Strike 4.2.2, 4.2.3, 4.2.4, 4.2.5

4.2.10 - Just define  here.

Strike 4.2.11, 4.2.12

4.2.13 - Just define , , and  here.

Strike 4.3, 4.4.2, 4.4.3, 4.4.4, 4.6.5.1, 4.6.5.2, 4.6.5.5, 4.6.5.6

[Ballot comment]
1. Section 3.4 says:

  Note that some of the elements described above such , , , or  are not defined in the data model in this specification but are
  defined in the data format of [RFC4575].  We describe them here
  because they are part of the basic structure of the data model.

In fact *only*  is defined in this specification.
It would be good to make that clear.

2. In Section 4.2.13:

      *  The  element is used in conjunction with an audio stream
        to cease transmission of any audio from the associated stream.
        That means that for the entire duration where mute is
        applicable, all current and future participants of the
        conference are muted and will not receive any audio.

To be precise, muting applies to the sending of audio, not the receiving
of audio.

3. I haven't had time to complete detailed checking of the RelaxNG
schema (compact or XML syntax), the W3C XML Schema document, or the
examples. However, including the formal definition in three different
representations might introduce the possibility that they are out of
sync. The fact that only the compact syntax is normative helps.
Finally, I merely note that the formal definition in RFC 4575 uses
W3C XML Schema, whereas the formal definition in this document uses
RelaxNG; the disconnect might make it difficult for implementers to
compare and reuse the formal definition.

[Ballot discuss]
First, my apologies for not reviewing this document earlier in the
process, as requested by the RAI ADs.

1. RFC 4575 says that a conference object MUST be encoded using UTF-8,
yet this document says it SHOULD be encoded using UTF-8. Why the change?
How would a UTF-16-encoded conference object be handled? I strongly
suggest changing the SHOULD to MUST.

2. Section 3.3 states:

  When created within the
  conferencing system, the 'conference ID' has a 1:1 mapping to the
  unique conference object Identifier(XCON-URI).

However, Section 3.3.1 defines XCON-URI as:

  XCON-URI = "xcon" ":" [conf-object-id "@"] host

Is there a 1:1 mapping between the "conference ID" and the full
XCON-URI, or between the "conference ID" and the conf-object-id rule?

3. Section 3.3.1 says that "the XCON-URI can not be resolved to
addresses and/or ports". Does this mean that an application MUST NOT
attempt to resolve an XCON-URI, or only that such URIs are not designed
to be resolvable?

4. Regarding Section 3.3.2, why not just reference Section 6 of RFC
3986?

5. Please add a note that the XCON-URI construction does not directly
support characters outside the ASCII range, but that such characters can
be encoded (at least in the "host" portion) using the rules in RFC 3987.

6. Section 4.1 states:

  Note that the
    element does not have the attributes 'state' and
  'version' defined in [RFC4575] for this element because these
  attributes only apply to notification mechanisms.

What does it mean to say that the element "does not have" the attributes?
Does it mean that for this usage, the attribute MUST NOT be included? If
so then it appears that this document might be updating RFC 4575.

(Similar text appears in Section 4.6, Section 4.6.5, etc.)

7. Section 4.2 states:

  The  element, which is defined in [RFC4575],
  describes the conference as a whole.  It SHOULD have an attribute
  'lang' to specify the language used in the contents of this element.

However, the 'lang' attribute is not specified in RFC 4575 schema. The
RelaxNG definition in this document includes not 'lang' but 'xml:lang':

conference-description-type =
  element conference-description {
    attribute xml:lang { xsd:language }?

If you mean 'xml:lang' instead of 'lang' then please say so.

8. A number of elements have boolean values, such as Section 4.2.6:

  The  element represents a boolean value.  If set to
  TRUE, the conference is allowed to create sidebar conferences.  If
  absent, or set to FALSE, the conference can not create sidebar
  conferences.

Please note that in W3C XML Schema Part 2 (Datatypes), there are two
lexical representations for boolean values: "true"/"1" for the concept
TRUE and "false"/"0" for the concept FALSE. You might want to add a
general note about this somewhere in the text (or in each section say
'"true" or "1"' instead of 'TRUE', '"false" or "0"' instead of 'FALSE').

9. Given that the conference object is entirely defined in XML, why
does the  child of the  element contain the
textual representation of an iCalendar object (RFC 5545) instead of
the XML representation (draft-daboo-et-al-icalendar-in-xml, on the
same telechat as this document)?

10. Section 4.2.9 states the following about the
element (same for ):

      The  has the mandatory
      'required-participant' attribute.  This attribute contains one of
      the following values: "none", "administrator", "moderator",
      "user", "observer", and "participant".  The roles' semantic
      definitions are out of the scope of this document and is subject
      to future policy documents.  More values can be specified in the
      future.

Not defining the attribute values seems problematic. Yes, we all have
a common-sense idea of what administrators and moderators (etc.) are,
but why leave the definitions to future policy documents? And given
that more values can be specified in the future, is a registry in
order?

11. Section 4.6.3 states:

  The  child element
  stores persistent information about users who are not actively part
  of an ongoing chatroom session.  The  element stores
  the following information:

  o  user: The  element stores the name, nickname, the conference
      user identifier (XCON-USERID) and email address of a user.  It has
      three attributes: 'name', 'nickname' and 'id' and an
      element.  Future extensions to this schema may define new elements
      for the  element.

Why is it required to store email address? What are the privacy and
security implications of storing email addresses (e.g., possible
directory harvesting attacks)?

12. Section 6 states:

  The Conference Information Data Model defined in this document is
  meant to be extensible toward specific application domains.  Such
  extensions are accomplished by defining elements, child elements and
  attributes that are specific to the desired application domain.  The
  IETF MAY extend the data model schema with unqualified attributes or
  extension elements from the "urn:ietf:params:xml:ns:" "sub-namespace"
  in the future.  Other instances are free to define extension elements
  or attributes under other namespaces.

I see no reason to talk about the "urn:ietf:params:xml:ns:" tree here,
although if you want to talk about it then the MAY seems out of place
and it would be good to provide a pointer to RFC 3553. I would suggest:

  The Conference Information Data Model defined in this document is
  meant to be extensible.  Extensions are accomplished by defining
  elements or attributes qualified by namespaces other than
  "urn:ietf:params:xml:ns:conference-info" and
  "urn:ietf:params:xml:ns:xcon-conference-info" for use wherever
  the schema allows such extensions (i.e., where the RelaxNG
  definition specifies "anyAttribute" or "anyElement").

[Ballot comment]
ABNF issue: In 3.3.1, conf-object-id is very liberal. Is everyone OK with the idea of a conf-object-id of "---...+++===///"? (I understand that 3986 also allows "---...", but I'm just checking. [Update 2011-05-24: The author claims this is desirable. I am willing to take his word for it, but leave this comment in just in case.]

Editorial: Top of section 4 - The use of the word "operator" twice here is goofy. This is notation, not a formal operation. I say just strike it. [Update 2011-05-24: To be fixed.]

Also, why is the figure specified as "non-normative". What could be taken as normative in there?

4.2.1 - "defined in IANA [IANA-Lan]". That looks funny. [Update 2011-05-24: To be fixed.]

Overall issue: RFCs 3986, 4575, and 5239 are all normative references and are absolutely required reading to use this document. Therefore I don't see any reason for all of the redundancies in this document. (This document is long enough as it is; shortening would be good.) So:

Intro - Paragraphs 2, 3, 4 and figure are unneeded. Strike.

3.3.2 - No need to specify lowercase here. Just ref 3986.

4.1 - Shorten:

  A conference object document begins with the root element
  , which is defined in [RFC4575].  The
  attributes 'state' and 'version' defined in [RFC4575] are
  not used for this element in this specification because these
  attributes only apply to notification mechanisms.

  This specification adds the child element
  to the  element.

4.2 - Why is "lang" on the  rather than on its children? And why does it need to be called out normatively in this document? (Shouldn't all elements have a lang aatribute? Why is this one special?) Also, shorten:

  The  element, which is defined in [RFC4575],
  describes the conference as a whole.  This specification adds the
  child elements , , , , and . This specification also adds a new
    child element to the  child element of the
    child element, and adds the , , and
    child elements to the  child element of the
    child element.

Strike 4.2.2, 4.2.3, 4.2.4, 4.2.5

4.2.10 - Just define  here.

Strike 4.2.11, 4.2.12

4.2.13 - Just define , , and  here.

Strike 4.3, 4.4.2, 4.4.3, 4.4.4, 4.6.5.1, 4.6.5.2, 4.6.5.5, 4.6.5.6

[Ballot comment]
This was an overall OK document. I did have a few small question marks, however:

I am wondering if  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:

             

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
      }?,

[Ballot discuss]
(1) I agree with the secdir reviewer (Tero Kivinen) [1] that passwords
and personally identifying information do warrant specific protection
in the DB. The security considerations seems to nearly, but not quite
do this, when it says that the DB SHOULD be accessed via TLS or
equivalent. However, I think you need two more things: a) to say when
its ok to not follow the SHOULD but also b) you need to RECOMMEND that
the (sensitive parts of the) DB be encrypted as stored in long term
storage (i.e. disk) which is different from how its accessed via the
network.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html

(2) I would think that conference object identifier URIs (and maybe
also other URIs that are not typed by people) MUST or SHOULD be
unguessable. The reason is that this provides a defence-in-depth for
cases where e.g.  TLS is not used when it ought be etc. Basically, if
a URI is unlikely to be typed by a person, then it seems best to make
sure they're unguessable and since this is something that
implementations often get wrong this would seem like a good place for
that statement.

(5) 4.2.12 What does "set by an administrator" mean for a data model?
How could I tell by looking? If it said "typically set..." that'd be
fine but it currently reads like normative text.

(7) Section 6 says "The IETF MAY extend the data model schema..." What
does that mean? Why the 2119 MAY? Is a standards-track document
needed, or informational, what about ISE/IRTF or other streams?

(8) Security considerations: what does "There is no other encoding
considerations for XCON-USERID or XCON-URI not discussed in RFC 3986
[RFC3986]." mean? I don't get it anyway.

[Ballot comment]
ABNF issue: In 3.3.1, conf-object-id is very liberal. Is everyone OK with the idea of a conf-object-id of "---...+++===///"? (I understand that 3986 also allows "---...", but I'm just checking.

Editorial: Top of section 4 - The use of the word "operator" twice here is goofy. This is notation, not a formal operation. I say just strike it. Also, why is the figure specified as "non-normative". What could be taken as normative in there?

Overall issue: RFC 4575 is a normative reference already, it is absolutely required reading to use this document. RFC 3986 is also a normative reference. Therefore I don't see any reason for all of the redundancies in this document. (This document is long enough as it is; shortening would be good.) So:

Intro - Paragraphs 2 & 3 and figure are unneeded.

3.3.2 - No need to specify lowercase here. Just ref 3986.

4.1 - Shorten:

  A conference object document begins with the root element
  , which is defined in [RFC4575].  The
  attributes 'state' and 'version' defined in [RFC4575] are
  not used for this element in this specification because these
  attributes only apply to notification mechanisms.

  This specification adds the child element
  to the  element.

4.2 - Why is "lang" on the  rather than on its children? And why does it need to be called out normatively in this document? (Shouldn't all elements have a lang aatribute? Why is this one special?) Also, shorten:

  The  element, which is defined in [RFC4575],
  describes the conference as a whole.  This specification adds the
  child elements , , , , and . This specification also adds a new
    child element to the  child element of the
    child element, and adds the , , and
    child elements to the  child element of the
    child element.

4.2.1 - "defined in IANA [IANA-Lan]". That looks funny.

Strike 4.2.2, 4.2.3, 4.2.4, 4.2.5

4.2.10 - Just define  here.

Strike 4.2.11, 4.2.12

4.2.13 - Just define mixing-mode>, , and  here.

Strike 4.3, 4.4.2, 4.4.3, 4.4.4, 4.6.5.1, 4.6.5.2, 4.6.5.5, 4.6.5.6

[Ballot comment]
#1) I support Stephen's discuss.

#2) Should this document indicate that it updates RFC 4575?

#3) Sec 1 includes the following:

  This core data set called the 'conference information data model' is
  defined in this document using an Extensible Markup Language (XML)-
  based.

I think this sentence is missing some additional words.

#4) Sec 4.5.4: r/is optional/is OPTIONAL
r/The optional/The OPTIONAL

[Ballot discuss]
#1) Mandatory is used a couple of times in the document to indicate support level for certain attributes (e.g., in Sec 4.2.9).  I think these should be changed to use 2119 language.

#2) Sec 4 include the following:

  The operator "!" preceding an element indicates
  that the element is mandatory in the data model.

Shouldn't mandatory be REQUIRED (i.e., use 2119 language).

#3) I'm trying to reconcile the following statement from Sec 4.2.9 and Figure 3:

  Every  element contains the following child elements:

I read that to mean the child elements MUST be present.  Is that the case? 

Same thing in 4.2.13:

  Each  element contains the following child elements:

#3) Sec 4.2, 4.3, 4.4, 4.6: Which of the sub-elements MUST be supported?  E.g., is it allowable to have an empty  or ? If so how's that handled?

#4) Sec 4.5: Which of the four elements MUST be supported?  Is  a MUST?  What happens when  isn't included - is there default behavior like ?

#5) Sec 4.5.4 includes the following:

  The  element has one or more  child
  elements.

Doesn't this mean "floor" is a MUST?  Then, Figure 3 needs to be updated and this sentence should be reworded to clearly state it's a MUST support.

#6) Sec 4.6.5.10 needs to indicate that it MUST be included in every .

[Ballot comment]
(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  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
"". (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.

[Ballot discuss]
(1) I agree with the secdir reviewer (Tero Kivinen) [1] that passwords
and personally identifying information do warrant specific protection
in the DB. The security considerations seems to nearly, but not quite
do this, when it says that the DB SHOULD be accessed via TLS or
equivalent. However, I think you need two more things: a) to say when
its ok to not follow the SHOULD but also b) you need to RECOMMEND that
the (sensitive parts of the) DB be encrypted as stored in long term
storage (i.e. disk) which is different from how its accessed via the
network.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html

(2) I would think that conference object identifier URIs (and maybe
also other URIs that are not typed by people) MUST or SHOULD be
unguessable. The reason is that this provides a defence-in-depth for
cases where e.g.  TLS is not used when it ought be etc. Basically, if
a URI is unlikely to be typed by a person, then it seems best to make
sure they're unguessable and since this is something that
implementations often get wrong this would seem like a good place for
that statement.

(3) Is "password" the right choice as the only way to authenticate to
a conference? Would it be better to have an authenticator element that
can be a password but could be extended in other ways later (e.g.  to
use kerberos or oauth or saml or whatever)?

(4) How is I18N handled for passwords? (This may be well-known from
elsewhere but it's not well-known to me:-)

(5) 4.2.12 What does "set by an administrator" mean for a data model?
How could I tell by looking? If it said "typically set..." that'd be
fine but it currently reads like normative text.

(6) (page 20) I was surprised by the  element - are
these really the only possibilities? I assume not, but I expected a
more abstract layout description to allow for UI innovation by clients
- this seems a bit too implementation specific. (If I'm told that the
WG really had consensus on this and no-one else thinks its an issue
I'll clear this bit.)

(7) Section 6 says "The IETF MAY extend the data model schema..." What
does that mean? Why the 2119 MAY? Is a standards-track document
needed, or informational, what about ISE/IRTF or other streams?

(8) Security considerations: what does "There is no other encoding
considerations for XCON-USERID or XCON-URI not discussed in RFC 3986
[RFC3986]." mean? I don't get it anyway.

IANA has questions about the IANA Actions related to the document.

Upon approval of this document, IANA understands that there are four
actions that need to be completed.

First, the document requests the registration of a schema. While the
schema is documented in Section 5 of the document, the URI provided in
the IANA Actions appears to be a namespace URI.

IANA Question -> For the xcon-conference-info schema, what is the
correct URI?

Second, in the IETF XML namespace registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new namespace will be registered as follows:

ID: xcon-conference-info
URI: urn:ietf:params:xml:ns:xcon-conference-info
Registration Template: [ As provided in Section 9.2 of the approved
document ]
Reference: [ RFC-to-be ]

Third, in the Permanent URI Schemes subregistry of the Uniform Resource
Identifer (URI) Schemes located at:

http://www.iana.org/assignments/uri-schemes.html

a new registration will be added as follows:

URI Scheme: xcon
Description: Centralized Conferencing
Reference: [ RFC-to-be ]

Fourth, in the Permanent URI Schemes subregistry of the Uniform Resource
Identifer (URI) Schemes located at:

http://www.iana.org/assignments/uri-schemes.html

a new registration will be added as follows:

URI Scheme: xcon-userid
Description: Centralized Conferencing User Registration
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required upon approval
of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Conference Information Data Model for Centralized Conferencing (XCON)) to Proposed Standard


The IESG has received a request from the Centralized Conferencing WG
(xcon) to consider the following document:
- 'Conference Information Data Model for Centralized Conferencing (XCON)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-xcon-common-data-model/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-xcon-common-data-model/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Alan Johnston is the Document Shepherd. I have personally reviewed the
draft-ietf-xcon-common-data-model-19.txt version of this document and
believe it is ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has had good review both within and outside the working
group. I have no concerns about the reviews that have been performed.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No known issues. No known IPR.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The XCON Working Group has a relatively small, but committed group of
about a dozen individuals who have participated over many years and
contributed large amounts of effort and text. We have developed our
consensus around this document slowly. As such, I believe it is a
strong consensus.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

The document does have normative and informative references.

If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes.

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries?



Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation? \

The document does register a new URI scheme. The URI scheme has been
reviewed on the URI Review List.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?



The IESG has approved the following document:

- 'Conference Information Data Model for Centralized Conferencing
(XCON)'  as a Proposed Standard

This document is the product of the Centralized Conferencing Working
Group.

The IESG contact persons are Gonzalo Camarillo and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-19.txt

Technical Summary

The conference information data model is designed to convey
information about the conference and about participation in a
centralized conference. The conference information data model
constitutes an extension of the data format specified in the
Session Initiation Protocol (SIP) Event Package for Conference State.

Working Group Summary

This document is a product of the XCON working group.
Its contents have been uncontroversial in working group
discussions.

Document Quality

Alan Johnston has reviewed the document for quality.

Personnel

Alan Johnston is the Document Shepherd for this document.
Cullen Jennings is the responsible Area Director.