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

[Oscar Novo <[e-mail]>]

 
Hello Robert,

Thank you very much for your review. A new version of the document including your suggestions has been released, http://www.ietf.org/id/draft-ietf-xcon-common-data-model-20.txt
More details inline as [ON].

Cheers,

Oscar


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Sparks
Sent: 14. syyskuuta 2010 19:00
To: [e-mail]
Subject: [XCON] AD review: draft-ietf-xcon-common-data-model-19

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]) 

[ON] Alan Johnston - the co-chair of XCON- already requested a URI review of the document on 19 of April. The review was done by Ted Hardie and accepted it. The 19 version of the document already includes the feedback of that review. 

* 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.

[ON] The verification of the schema and examples has been reviewed by Jari Urpalainen, co-author of this document. Many tools have been used to verify the schema and examples but the main tools are the online W3C schema validation written by Jari (http://validate.openlaboratory.net/), and the Oxygen XML editor (http://www.oxygenxml.com/) for editing and transform the schemas.
  
Technical:

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

[ON] Note that the port is an optional element. Besides that, an XCON-URI can be viewed as a key to access a specific conference object. So, having a direct mapping to a URL can be useful some times for some conferences. In fact, Ted Hardie approved the XCON-URI as it is. 

* 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...

[ON] The paragraph in section 4.6.5.10 has been rephrase accordingly.

* 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)?

[ON] Changed accordingly

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

[ON] I've changed it as SHOULD. 'lang' is a recommend attribute to specify the recommend language used in the document. 

* 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. 

[ON] The paragraph has been changed accordingly.

* 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.

[ON] Actually, the Data Model does not define the semantics of their elements. The conference policy - which is not part of the data model - should do that.


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

[ON] Changed accordingly

* 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.

[ON] Changed to MUST

* 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).

[ON] are you referring to <mixing-end-offset> element? I think the text is correct here. If the element is not present, the conference is not bounded. Not been bounded has a different meaning than need to be extended.  


* 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"?

[ON] The implementors MUST follow the normative RELAX NG Schema defined in section 5. The text of the document is trying to explain and sumarize the most importants features of that schema. In this case, the <entry> element does not have any extra meaning to be mention in the document.

On the other hand, as I stated before, it's out of the scope of the document to explain the different policies or semantic scenarios btw elements.
 

* 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.

[ON] right

* 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".

[ON] Long ago, in the WG was consensus to define some semantics for the controls. 
Regarding the text, I have re-phrased the sentence accordingly.

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

[ON] OK

* 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?

[ON] I recommend you to read Section 3.3. It explains the mapping of the 'The Conference Object Identifier'(XCON-URI) with the other Ids.


* 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.

[ON] I refer to previous comments: the semantic of the data model is out of the scope of this document.

* 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. 

[ON] The policy is out of the scope of this document. We're just trying to define a range between the different values without getting involve in the policy.

* 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?

[ON] The security considerations section has been updated and the REFER document has been mentioned in sections 4.6.5.7 through 9.

* 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.

[ON] The Data Model is an extensible schema. We just indicate to the implementor how to limit the schema if it's not extended. The trailing slash has been included in the <notAllowed> element.

* 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? 

[ON] It's unclear to me that those questions have to be solved in this document. Many of those questions are already answer in other documents such as the framework document (Sidebar Manipulations section). Besides, the security considerations of the framework document are implicit in the data model. 
However, I've mentioned the possible security considerations cloning or using sidebars in the conferencing object. 

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

[ON] The paragraph has been re-phrase.

* 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.

[ON] The paragraph has been re-phrase.

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

[ON] Changed accordingly

  
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.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. 
* 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.
* 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.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?
* 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.
* 9.3 "URI Schemes register." -> "URI Schemes registry."

[ON] All these nits have been fixed in the new version

* 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.

[ON]Changed to "A conference participant can subscribe himself to a floor control event in two different ways."

* 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.

[ON] Chnaged to "The Conference Information Data Model contains sensitive data which needs to be protected from compromises."


_______________________________________________
XCON mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/xcon