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

[Oscar Novo <[e-mail]>]

Hi,

Continuing the conversation... (I have format a bit the text to make it more clear for everyone.)
I've submitted a new version with the changes

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

[Robert]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.

[ON1] I have added the following to the section:

"XCON-URI is a URI conference identifier and even though its cosntrcution is similar to a URL, in this case, the XCON-URI can not be resolved to addresses and/or ports."
 
/------------------------Question--------------------------------------------/

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

[RObert] 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.


[ON1] I have modified the text as you suggested.

/------------------------Question--------------------------------------------/

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

[RObert] 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?

[ON1] I have added the following text:

"This element contains a set of <entry> child element - each containing a new element conference-password"

/------------------------Question--------------------------------------------/

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

[RObert] 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). 

[ON1] I have modified the text as you suggested.

/------------------------Question--------------------------------------------/

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

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

[ON1] As we agreed in the WG, the semantic of those elements will be defined in further documents. 

/------------------------Question--------------------------------------------/

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

[RObert] 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.

[ON1] I have added some text accordingly.

/------------------------Question--------------------------------------------/

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

[RObert] Then,  please add text
 explaining who the instructions are intended for and when they should
 be invoked.

[ON1] Is not the current text self-explanatory? Which instructions would you suggest? 


/------------------------Question--------------------------------------------/

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

[RObert] 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.


[ON1] I have added some text to the security section.