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

[Robert Sparks <[e-mail]>]

That's probably too restrictive. It's not hard to imagine an authorization policy of "allow anyone on allowed unless they also appear on deny"
where someone not on either list gets one kind of rejection and someone on deny gets a different kind of rejection".  I don't think we buy anything
by preventing someone from specifying that as long as their specification is clear.

RjS

On Jan 14, 2011, at 1:14 AM, Oscar Novo wrote:

> 
> Hi Robert,
> 
>> This is all good, but the last paragraph as written will require any future standardization effort that wants to create a new policy to include an RFC
>> that Updates this one. That may be required anyhow, but I want to make sure the group considers this consequence explicitly. It is not immediately
>> obvious to me what we might do differently.
> 
> Right, I didnt think about that. Actually, allowing both lists may not be good idea. Most likely future extensions will create their own elements or will use the allowed-users-list and the deny-users-list separately. It might be better to disallow both list at the same time in future extensions.
> 
> What about changing the last paragraph to:
> 
>        In all other cases, the appearance of an <allowed-users-list> and <deny-users-list> MUST be ignored. Future specifications describing the use of        these lists MUST disallow both appearing at the same time too.
> 
> Oscar
> 
> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]]
> Sent: 13. tammikuuta 2011 22:45
> To: Oscar Novo
> Cc: [e-mail]; Gonzalo Camarillo
> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
> 
> One comment inline
> 
> On Jan 13, 2011, at 5:20 AM, Oscar Novo wrote:
> 
>> Hi Robert,
>> 
>> As you said, our ideas start to converge. So, I think a real-time meeting wouldn't be necessary at this moment. If the XCON chairs or you still think it's needed, I don't have any problem to set up a meeting with the group.
>> 
>> Now, here's the answers to your last e-mail. Let me know what you think about them and I can start working in a new version of the draft ASAP:
>> 
>> The data model document is a normative document and it constitutes a superset of the data format defined in 4575.
>> 
>> The XML in the document has been reviewed many times. Jari and myself have validated the XML schema against 4575 too. However, I think it's a good idea Peter Saint-Andre reviewed again the XML.
>> 
>> I think changing the namespace name of the document will mess up the things around. Note that there are other documents in the XCON WG using similar syntax, for instance, "Conference Event Package Data Format Extension for XCON" uses xcon-conference-info-diff.
>> 
>> I agree to include the following text in section 4.2.10:
>> 
>> The schema in Section 5 allows <conference-password> to appear anywhere uris-type is expanded.
>> This document  only provides meaning for <conference-password>
>> appearing as a descendent of  the <conf-uris> element. Future
>> standardization may give meaning to <conference-password> appearing
>> in other elements of type uris-type. In the absence of such standardization, <conference-password>  MUST NOT appear in elements of type uris-type other than <conf-uris>.
>> 
>> Regarding the new text in 4.6.2 <user-admission policy> section. Would the following text fullfil your requirements?:
>> 
>>  The <user-admission-policy> is an element that lets an organizer (or a participant with appropriate rights) choose a policy for the
>>  conference that controls how users are authenticated into the conference, using a mechanism of the conference's choosing.  Since a
>>  variety of signaling protocols are possible, a variety of authentication mechanism - determined by every individual conference
>>  servers - may need to be mapped from the different protocols. The specific types of authentication mechanism are beyond the scope of
>>  this document.  The list of possible values are:
>> 
>>  o  "closedAuthenticated": A 'closedAuthenticated' policy MUST have each conference participant in the allowed users list
>>     (listed under the <allowed-users-list> XML element) with each participant being sufficiently (up to local policy) authenticated.
>>     Conference join requests for users not in the allowed users list or participants not authenticated should be rejected unless a
>>     <join-handling> action of 'confirm' is selected in which case the user is placed on a pending list as indicated earlier. An 'closedAuthenticated'        policy MUST NOT include a <deny-users-list>. If <deny-users-list> appears in the data model, it MUST be ignored.
>>  o  "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 SHOULD have a deny users list (listed under the <deny-users-list> XML element) to support banning of conferencing         participants from a conference. An 'openAuthenticated' policy MUST NOT include an <allowed-users-list>. If <allowed-users-list> appears in the data     model, it MUST be ignored.
>>  o  "anonymous": An 'anonymous' policy allows any join requests in and is the least restrictive policy. An 'anonymous' policy MUST NOT include either        an <allowed-users-list> or a <deny-users-list>. If any of these lists appear in the data model, they MUST be ignored.
>> 
>>  In all other cases, the appearance of an <allowed-users-list> and <deny-users-list> MUST be ignored. Future specifications describing the use of these
>>  lists MUST either disallow both appearing at the same time or provide clear guidance on how to process the lists when they occur concurrently,
>>  especially when both lists contain the same user.
> 
> This is all good, but the last paragraph as written will require any future standardization effort that wants to create a new policy to include an RFC that Updates this one. That may be required anyhow, but I want to make sure the group considers this consequence explicitly. It is not immediately obvious to me what we might do differently.
> 
>> 
>> Concerning your last question, as you suggested, I will remove the comments from all the extensibility elements.
>> 
>> Cheers,
>> 
>> Oscar
>> 
>> -----Original Message-----
>> From: Robert Sparks [mailto:[e-mail]]
>> Sent: 12. tammikuuta 2011 22:33
>> To: Oscar Novo
>> Cc: [e-mail]; Gonzalo Camarillo
>> Subject: Re: [XCON] AD review: draft-ietf-xcon-common-data-model-19
>> 
>> Hi Oscar -
>> 
>> I think we're making progress and might be starting to converge. Let me know if you want to shift to real-time after responding to this message - I can ask the chairs to set up a conference for us to iron any last things out with the group if we need it.
>> 
>> RjS
>> 
>> On Jan 5, 2011, at 6:04 AM, Oscar Novo wrote:
>> 
>>> 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 was initially quite puzzled by this response. I went back and reread this document (and 4575s) definitions carefully, and I think I might see where we haven't been coming together.
>> 
>> Your statement above isn't quite right. This document restates the syntax defined in 4575 (using a RelaxNG schema), and shows where you take advantage of the extension points that were already in that grammar by adding elements using another namespace.
>> 
>> Using the grammar defined in this document, conference-password can be produced within associated-aor (and service-uris, host-info, users, and any other place uris-type gets invoked).
>> 
>> So to address my primary question instead of your proposal to add text to 4.6.5.2 below, I suggest instead to add this as a new paragraph at the end of section 4.2.10:
>> 
>> The schema in Section 5 allows <conference-password> to appear anywhere uris-type is expanded.
>> This document  only provides meaning for <conference-password>
>> appearing as a descendent of  the <conf-uris> element. Future
>> standardization may give meaning to <conference-password> appearing
>> in other elements of type uris-type. In the absence of such standardization, <conference-password>  MUST NOT appear in elements of type uris-type other than <conf-uris>.
>> 
>> I'll ask the xml directorate to review how we're restating 4575's schema. (Has such a review already been performed?).
>> One question I have is whether this is a normative update to 4575 as written.
>> 
>> Also, while talking through this with others, I had several people comment that "xcon-conference-info" namespace and the "conference-info" namespaces are so visually similar that it's easy to misunderstand what this document is trying to do. How much implementation of xcon-conference-info exists now? Would it be feasible to change it to something more distinct from conference-info?
>> 
>>> 
>>> 
>>> 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?
>> 
>> The additional text would help, but it's not sufficient yet.
>> Given what you say here, I'm looking for something that says:
>> 
>> If you are using an anonymous policy, you must not include either an allowed-users-list or a deny-users-list (and must ignore any that appeared).
>> If you are using an openAuthenticated policy, you may include a deny-users-list, but must not include an allowed-users-list (you must ignore any deny-users-list that appears).
>> If you are using a closedAuthenticated policy, you must include an allowed-users-list, and must not include a deny-users-list (you must ignore any deny-users-list that appears).
>> In all other cases, the appearance of an allowed-users-list and deny-users-list has no meaning defined by this document. Future specifications describing the use of these lists must either disallow both appearing at the same time or provide clear guidance on how to process the lists when they occur concurrently, especially when both lists contain the same user.
>> 
>> And I think it needs to say those things using 2119 words.
>> 
>> 
>>> 
>>> 
>>> 
>>>> /------------------------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?
>> 
>> Thinking about this some more, I believe this is dangerous, and is not something we should recommend as part of standardizing this model.
>> Basically, you're saying that an implementation that believes it isn't going to exercise an extension point can stub those extension points out.
>> In practice, this will result in incompatible versions of the schema being fielded, and in the worst of cases, when the implementer was _wrong_ about this implementation (or the things around it) wanting to use the extension points, results in a brittle system. We certainly can't prevent an implementer from making this simplification if they choose to do so, but it's a hazardous practice that is very likely to make rolling out extensions in the future more difficult.
>> 
>> I think you should remove the comments from the document altogether.
>> 
>> 
>> RjS
>> 
>>> 
>>> Oscar
>> 
>