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

[Oscar Novo <[e-mail]>]

Hello Robert,

I've only included in this thread questions which need some answers, leaving all the other questions out of the thread for a matter of clarity.


> [Robert] Do you intend to allow users of the data model to give meaning to a <conference-password> appearing inside an <associated-aors>?
>The schema allows it (or am I reading the schema wrong?). Did the group _intend_ for the schema to allow that, and do they anticipate that it will have >any meaning at some point? Or should there be text that forbids that element appearing anywhere but <entry>? 

[O] The data model uses the <associated-aors> child element defined in RFC4575. In this case, the data model doesn't extend the <associated-aors> child element with the <conference-password>.

I could add the following text to 4.6.5.2.: 

   "The <associated-aors> child element is explained in [RFC4575], section 5.6.2. This document does not extend the <associated-aors> child element with new elements or attributes."


>/------------------------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.
>> 
>> 
>> [ON1] As we agreed in the WG, the semantic of those elements will be defined in further documents. 

> [Robert]I could possibly accept that if the group had defined a model that contained a <list> and handed semantics off to some attribute of the list >(such as ><list name="allowed users">).

>It doesn't. It defines lists and telegraphs semantics with the name. With what you've specified so far, you are encouraging a low level of >interoperability.

>I'll start a separate thread on this.

[O] The <allowed-users-list> and <deny-users-list> are linked with the <user-admission-policy> element. This element lets an organizer to choose an admission policy for the conference. The data model defines three types of admission: closedAuthenticated, openAuthenticated, anonymous. 
	- The "anonymous" policy allows everyone to connect to the conference.
	- The "closedAuthenticated" allows the users listed in the <allowed-users-list> to connect to the conference
	- The "openAuthentication" allows anyone capable of authenticating to join the conference. 

In the first case, banning a user is not support. In the second case, banning a user can be accomplished by removing the user from the <allowed-users-list>. In the third case, a <deny-users-list> is needed to support the concept.

I can understand the use of the <deny-users-list> is unclear in the document at this point. 
I'm planning to add the following text in the 4.6.2 <user-admission policy>:

""openAuthenticated": An 'openAuthenticated' policy requires each conferencing participant to be sufficiently authenticated. Typically this implies that anyone capable of authenticating with the conferencing system may join the conference.
The 'openAuthenticated' policy permits the specification of "banned" conferencing participants. Such banned users are prevented from re-joining the conference until they have been un-banned. An 'openAuthenticated' policy requires a deny users list (listed under the <deny-users-list> XML element) to support banning of conferencing participants from a conference."

Do the text above clarify your question?



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

>[Robert] No, it's not self-explanatory - if it were, we wouldn't be having this conversation.
>I suggest pulling it into an "Implementer note", introducing the note with a sentence or two explaining that this is something you can do if you know >>you are not going to use any extensions.

[O] Right, what about adding the following text in every extensibility elements?

"If extensions (check section 6) beyond this specification are not used, re-define anyAttribute as <empty/> and remove the definition below"

Would it be clear adding the text above?

Oscar