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

[Robert Sparks <[e-mail]>]

Hello Oscar - 

I've replied to your questions and continued the conversation on some points inline.

RjS

On Oct 15, 2010, at 8:42 AM, Oscar Novo wrote:

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

It's certainly valid for the :port construct to be part of a URI fashioned like this one, but my concern is not whether it's a valid URI construct, but what it means for the protocol using it.
I think it stands a good chance of introducing confusion, leading implementers to the incorrect conclusion that these URIs would be resolved to addresses and then to ports. It needs
to be very clear in the document that this isn't the case.

Personally, I think removing the construct from the URI would be the best thing to do, but I'd be OK with leaving it as long as the document is very explicit about what it does and doesn't mean.


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

No, I was referring to <allowed-extended-mixing-end-offset> - the last bullet of section 4.2.9

The current text says
o  <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
      end-offset> refers to the possibility to extend the conference.
It is not clear what "the possibility to extend" means. I suggest what you want to say is
o  <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
      end-offset> element indicates if the conference is allowed to be extended.

And suggest a pointer to the appropriate section of whatever document defines extending conferences.


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

This is a data model question, and the text is unclear. Can you clarify the text to address the point in my first two sentences?

The document is already reflecting semantic decisions the group has already made - it may not be the authoritative document,
for those semantics, but it is describing them, especially when it help to clarify what the model allows.

Your response that the implementation must conform to the schema doesn't help resolve my concern that the schema allows
<conference-password> to appear in other places than what you describe here. Do you intend to allow users of the data model
to give meaning to a <conference-password> appearing inside an <associated-aors>?

In case we're talking past each other - you seem to be making an argument to remove the discussion of <conference-password> from
this section altogether (since you are discussing it's semantics). Was that your intent?

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

That helps me, but it's not going to help future readers of this document.

The section is not clear. It is particularly confusing when you say
"the 'conference-ID' can be represented by the unique conference object
   Identifier (XCON-URI)." In this context, it appears to be saying that you
can put an XCON-URI in as the content of a <conference-ID> element.

Would replacing the section with this text work?

4.5.1.  <conference-ID>


   The <conference-ID> represents a conference instance within floor
   control.  When BFCP serves as the floor control protocol, the 
   <conference-ID> is a 32-bit BFCP conference identifier
   defined in [RFC4582] section 5.1. Note that when created within 
   the conferencing system, there is a 1:1 mapping between this
    <conference-ID> and the unique conference object Identifier 
  (XCON-URI) (see section 3.3). 


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

Where _is_ the semantics for these element defined? Could you please add a pointer from
this section to the document that provides that definition?

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

I don't understand what you mean by range. Ironically, what you actually seem to be to doing is assigning semantics to these values :)

I suggest that you reinforce at this point that "equal or lesser permissions" is determined by local 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.

Then,  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? 
> 
> [ON] It's unclear to me that those questions have to be solved in this document.
Calling attention to a potential problem is not the same as solving it. 
> Many of those questions are already answer in other documents such as the framework document (Sidebar Manipulations section).
Then pointers from this section to those documents would help.
> Besides, the security considerations of the framework document are implicit in the data model. 

Right now, you only say
"  The security considerations for authentication (Section 11.1)
   described in the centralized conferencing framework [RFC5239] also
   apply to this document."
If you intend the considerations in 5239 to apply more comprehensively to this document,
you should adjust that text.

> However, I've mentioned the possible security considerations cloning or using sidebars in the conferencing object. 
Thanks

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