Subject: [XCON] Policies in the data model

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 Jan 2007 08:00:00 +0200

Hi,

we are preparing a new revision of the data model draft and would like
to discuss how to encode policies. The current revision of the draft
uses the concept of roles, which are ordered by their predefined
priority. Each element in the data model have a read-only and a
read-write attributes that specify which is the minimum priority (i.e.,
role) a user needs to read or modify, respectively, the contents of the
element.

We believe that the roles are not defined clearly enough in the draft
and that we need a more flexible way to convey policies in conference
documents.

Our proposal would be to remove the concept of ordered roles and use
unordered groups instead. It would be possible, then, to assign
different rights to different groups.

Another thing we would like to have is documents whose policies are easy
to read (and understand) by humans. Therefore, we would like to be able
to assign a certain policy to the main elements of the data model (i.e.,
the elements directly under the <conference-info> element) and only be
able to make it stricter (i.e., not to relax it) for their child
elements. This way, by simply checking the main elements, it will be
easy to understand whether or not the policy in the document meets the
policy requirements of the conference's administrator.

The resulting XML format would be something like this:

<main-element>
     <access type="read-write">
         <group>2</group>
         <group>3</group>
         <user>bob</user>
     </access>
     <sub-element-1>
         <access-restriction type="read-write">
             <group>3</group>
         </access-restriction>

         [contents of sub-element-1]

     </sub-element-1>
     <sub-element-2>
         <access-restriction type="read-write">
             <user>bob</user>
         </access-restriction>

         [contents of sub-element-2]

     </sub-element-2>
     <sub-element-3>

         [contents of sub-element-3]

     </sub-element-3>

</main-element>

In the example above, the contents of <sub-element-1> can be modified by
users in group 2 and Bob, the contents of <sub-element-2> can be
modified by users in groups 2 and 3, and the contents of <sub-element-3>
can be modified by users in groups 2 and 3, and Bob.

Comments?

Cheers,

Gonzalo

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Morgan, Dave" <[email-masked]>
Date: Thu, 25 Jan 2007 16:25:34 -0500

Gonzalo, this is an interesting proposal let me see if I can accurately
summarize what you are proposing:

1) You propose a method to aggregate users and their privileges called
"groups" in a non-hierarchical manner which replaces the hierarchical
roles that were proposed
2) You propose a method to associate policy directly into the hierarchy
of the data model using an "access" attribute
3) You are introducing inheritance into the data model for sub-elements
with respect to their parent's "access."
4) You allow user names, such as <user>bob</user>, to be directly
specified in the access specification.

If my interpretation is correct, then let me comment on each of the
following:

1) In the prior draft we had policies defined for roles, but now those
policies in essence are being specified in the data model.  I like that
idea, our prior notion of hierarchical roles always seemed to fail when
dealing with exceptions.  But there's nothing that prevents me from
defining a group as <group>moderator</group>.  I'm ok with that, and I'd
prefer to name the element <group> than <role> which would only cause
confusion.

Just a couple more questions on the groups.  Who can create a group, who
puts users in a group, and who sets the policies for the group?  For
standard group names such as administrator, moderator, and participant,
maybe the data model can have some default settings.  But how would I
add a group called "remote-students" and what do you think would be the
mechanism to specify their privileges throughout the model?

2) In your example below you use both <access> and <access-restriction>,
I'm not clear on the distinction.  Are you saying in the main element
that you allow access to group2, group3, and bob, but in the sub-element
<access-restriction> for group3 means they are denied read-write access?
Can I draw the conclusion that group2 and bob will still have read-write
access?  So all children inherit the parent's access unless there is a
restriction.  That seems to be an efficient solution.

3) One of the places where the inheritance model has to be thought
through carefully is in the <users> element. We have to make sure that
the data model allows <bob> to change only the attributes we want him to
change such as "display-text" and "language."  But maybe we don't want
him to have read-write access to "allow-users-dynamically" and that
function can only be set by the <group>administrator</group>.  

A couple of other questions on 3), do we drop the roles from the data
model?  What about the privileges-control-list?  The only thing I liked
about the privileges-control-list was the <validity> element, which
allowed elements to be changed within a time interval.

4) I really like the idea of allowing the user name, "bob" for example,
to be included in the access groups.  

My overall comment is that we're dealing with a trade-off, either you
assign the read-write policies on the relevant data model elements
within the definition of each individual or group (or role), or you do
the converse and assign the read-write privileges of each individual or
group within the data model element.  Which is more elegant?

Dave

------------------------------------------------------------------------

David P. Morgan, PhD 
VP, Enterprise Technology & Architecture 
Fidelity Investments Systems Company 
Phone: 617 563-2178 
Fax: 617 385 2122 
Mailing: 82 Devonshire St, MZ V3C 
Boston, MA 02109-3614 
Office: 245 Summer Street, 3rd Floor

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 1:00 AM
To: XCON
Cc: Oscar Novo; Morgan, Dave; [email-masked]
Subject: Policies in the data model

Hi,

<main-element>

     </sub-element-1>
     <sub-element-2>

     </sub-element-2>
     <sub-element-3>

     </sub-element-3>

</main-element>

Comments?

Cheers,

Gonzalo

---

From: Srivatsa Srinivasan <[email-masked]>
Date: Thu, 25 Jan 2007 17:53:07 -0800

This model can be useful for certain, preferably atomic, sub-elements of
the XML schema that pertain to specific conferencing features. Such an
example would be the controls element or elements that control other
aspects of conferencing (like display-text). But, adopting a generic model
for the entire schema without specifying the applicability can be quite
disastrous for inter-op. How would this model solve some of the following:

        - What if one feature maps to one or more XML sub-elements?

        - What if one or more features map to the same XML sub-elements and
         there are differing restrictions to those?

        - What if one feature maps to a certain sub-element of the data model
           and also to one or more commands (over the control protocol)?

This may be simple for atomic sub-elements of the document and I am okay
with those having such a model (provided we understand how this relates to
roles), but we need to be careful when generalizing this design as it may
yield some pretty complex automata to implement.

Regards,
Srivatsa.

> Sent: Wednesday, January 24, 2007 10:00 PM
> To: XCON
> Cc: [email-masked]; [email-masked]
> Subject: [XCON] Policies in the data model
>
> Hi,
>