[XCON] AD review: draft-ietf-xcon-common-data-model-19

[Robert Sparks <[e-mail]>]

Summary: There are a few issues to address. A revised ID will be needed
         before progressing to IETF Last Call.

Administrative:

* If this hasn't been done already, the shepherd needs to request URI review
  for xcon: and xcon-userid: ([e-mail]) 

* Who verified the schema and examples, and what tool was used? Who verified
  that the alternate representations of the schema in Appendix A and B represent
  the same thing as the schema in section 5 (and how)? I'd like to include this 
  in the "Document Quality" section of the writeup.
  
Technical:

* Why does the xcon: URI allow [ ":" port ] ?

* The document often says <foo> is defined in RFC4575, where I think
  it's trying to say <foo> is identical to the element with the same
  name defined in RFC4575. This leads to awkward constructs like those
  in section 4.6.5.10 where it says "The <endpoint> element is defined
  in RFC4575." and "The <endpoint> element in this document does not
  defined (sic) the 'state' attribute...". It would be better to say
  The <endpoint> element is identical to the element with the same
  name in RFC4575 except that the 'state' attribute is not included...

* In 3.3.2,(definition of XCON-URI)  why is the normalization of 
  identifiers SHOULD and not MUST? Similarly, why is this normalization 
  SHOULD in 4.6.5 (XCON-USERID)?

* In 4.2 should the "should" in "should have an extra attribute 'lang'" be
  SHOULD (or perhaps MUST?). What makes this attribute "extra"?

* It's not clear that the <user> elements <roles> element can contain
  more than one <entry>. The text in 4.6.5.4 can be read to say there
  can be only one. 

* Is it clear that when a conference is set up with a constraint
  like <mixing-start-offset required-participant="participant">
  will require someone with a role of "participant" to join before
  mixing will start? Specifically, someone joining with a role of
  "moderator" that does not also have the role "participant" will
  not trigger the start of mixing.

* 4.2.9 : <request-user> is obliquely described. This should be a
  definition. Perhaps replace "It is possible to defines" with "defines"?

* 4.2.9, definition of <request-user>: Is the phrase "when the
  system has to send a notification" intended to normatively require
  the system to send a notification? Should "has to" be replaced with
  MUST? If not, "has to" is probably the wrong thing to say.

* 4.2.9, <allowed-extended-mixing-end-offset>'s description is not clear.
  Should this say "indicates that the conference may be extended"?
  If so, the text should probably mention who can extend the conference
  and how (or contain a pointer to existing text that says those things).

* 4.2.10, It is not clear from this text that the <conference-password>
  element is a child of <entry>, which is a child of <conf-uris>. The
  text implies it is a child of <conf-uris>. Should the definition of
  <conference-password> be pulled into its own section? The schema
  allows it to occur in places other than <conf-uris> - what text
  prevents it from occurring in, say, <associated-aors> or any of the
  other places that uses "uris-type"?

* 4.2.11, What is the sentence "Future extensions to this schema
  may define new values and register them with IANA." trying to
  accomplish? By new values, does it mean new <purpose> values?
  I suggest deleting this sentence.

* 4.2.13 This text: "The <mute> element is used in conjunction with an 
  audio stream to cease transmission of associated media.  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." seems to be the only place the semantics of <mute> are
  defined - have I missed a description somewhere else? I think the
  second sentence above should say "any audio from the associated
  stream".

* 4.4.1, Where the text says "would be rejected", should it be
  saying "MUST be rejected"?

* 4.5.1, This section is not clear. <conference-ID> as defined
  in this document allows only a xsd:unsignedLong. What is it
  trying to say when it says it can be represented by an XCON-URI?

* 4.6.3 and 4.6.4 : if the same user appears in an <allowed-users-list>
  and in a <deny-users-list>, which takes precedence? This should be
  made clear here, and the issue raised in the security considerations
  section.

* 4.6.5.3 : What determines "equal or lesser permissions"? Is that
  a matter of local policy at a given server? If so, that should be
  called out. 

* 4.6.5.7 through 9 : Are these sections relying on base 3515 behavior
  to normatively define what the focus will do with REFERs it accepts
  based on the admission policies being set here? If so, please say
  so and provide a reference to 3515. (If not, point to where the behavior
  is defined). Either way, the security considerations section needs to
  call out the dangers of accepting a REFER, pointing into 3515's security
  considerations section. Among other things, what happens if I REFER
  the conference to itself?

* In the Schama in section 5, there are several comment blocks 
  instructing someone to redefine something as <empty/> or <notAllowed> 
  (no trailing slash?).  Is this an established convention documented 
  somewhere? If so, can you provide a pointer? If not, please add text 
  explaining who the instructions are intended for and when they should 
  be invoked.

* The security considerations section is very short. I would have expected at
  least some discussion specific to the protection of new elements such as
  conference-password. I also think some discussion on leaking information
  through cloning existing conferences is warranted. Who can clone an existing
  conference? Will they get the members of every sidebar every time? What 
  happens if an eavesdropper (or malicious user) replays a cloning create
  request? If the existing conference had dial-out users, will the clone 
  immediately call them? 

* I don't understand what the first paragraph of 8.1 is trying to say. 
  Can it be rephrased?

* The second paragraph of 8.2 is not at all clear. This should clearly state 
  what the problem is, and provide more detail on the proposed way to avoid 
  the problem.  It's not clear at all what this mapping database is, what it 
  means to protect its integrity, who's responsible for maintaining it, or 
  what to do when a conflict occurs, particularly if the confict is caused by 
  an attempted access by a malicious user.

* The instructions in 9.1 about where the schema starts and ends do not match 
  what the schema section contains.

  
Editorial:

* s/guideline that can be used/guideline/g

* 4.2.9 : "possibility to defined different policies". defined->define

* 4.2.9 : in the section on mixing-end-offset: 
           "child element that specifies" -> "child element specifies"

* 4.2.10 : "<conf-uris> contains" -> "<conf-uris> element contains"

* 4.3 <host-info> is not a required element, but 4.3 says it "is set
  before conference activation". (That language is copied from 4575).
  Should it say "is usually set"? 

* 4.5.2, second paragraph first sentence. This one doesn't parse for me.
  It would if you added a word "There are two methods with which", but
  I don't know if that preserves the intended meaning.

* 4.5.4 (and this occurs elsewhere in the document):    
   "The <conference-floor-policy> element has one or more <floor> child
   elements.  Every <floor> child elements has an attribute 'id' that
   uniquely identifies a floor or floors within a conference. "
  Doesn't parse - should it say
   The <conference-floor-policy> element has one or more <floor> child
   elements.  Every <floor> child element has an attribute 'id' which
   uniquely identifies a floor within a conference. 
  ? If so, what do you think led to the odd construct that's there now?

* 4.6.5.10 : "does not defined the 'state'"-> "does not define the 'state'"
  (But this may be moot if the section is rewritten per my comment above)

* 4.6.5.10: the section says <floor> is the only <endpoint> element not
  defined as in 4575, but then immediately says <to-mixer> and <from-mixer>
  are also defined in this document. 

* Deep in section 7 (on page 50) there is
    <uri>conf223></uri>
  I suspect that's supposed to be an XCON-URI of some sort?
  Similary, there are many occurances of
    <user entity="bob534"/> 
  and other similarly formed values for entity that are supposed to be
  XCON-USERIDs.

* At the end of section 7, there's a paragraph talking about using two
  backslashes to break lines to meet the 72 character max-line-length
  limit for RFCs. This convention does not appear to be used in the
  document (it contains no backslashes at all). I suggest deleting the
  paragraph.

* In the security considerations section: 
  "The Conference Information Data Model contains sensitive data
  which should not be analyzed or given to anyone." This should be
  rephrased.

* 9.3 "URI Schemes register." -> "URI Schemes registry."