Subject: [XCON] Removing Policies from the framework document (and data model)

From: "Mary Barnes" <[email-masked]>
Date: Wed, 25 Apr 2007 15:18:22 -0500

There had been a thread on "Policies in the data model" prior to IETF-68
and we discussed that point at the meeting:
http://www3.ietf.org/proceedings/07mar/minutes/xcon.htm
But, there was no clear conclusion, although it did seem most folks were
in favor of completing the data model without the policy information.
However,  some of us thought we needed some basic information such as
read/write access (and roles). 

Per the recent discussion and suggestion on updates to the framework, it
has been suggested to remove the references to policy.  I can easily see
how the text in section 5 can be generalized - I'm proposing to get rid
of section 5.2 altogether and merge 5.1 text with 5 and just have a
general statement on policy. 

However, there is the fundamental concept in the "cloning tree" model
whereby the child is created as either being independent of the parent
and thus subject to the parent's policies or independent. I think that's
an important concept that we've had in the framework for quite some
time.  The context in which policies are discussed is around read/write
access restrictions. In my mind, I think this requires the basic concept
of the read/write access to be a requirement on implementation of the
data model, although not necessarily something that is an explicit part
of the data model.  This view is consistent with the existing text in
the framework document.  

In short, I'm proposing we remove the explicit text suggesting that
policies are part of the data model, but keep the text that discusses
the read/write access such as the following from section 5.2: 
  "Conference policies collectively refers to a set of rights,
   permissions and limitations pertaining to operations being performed
   on a certain conference object.

   The set of rights describes the read/write access privileges for the
   conference object as a whole.  This access would usually be granted
   and defined in terms of giving the read-only or read-write access to
   clients with certain roles in the conference.  As such, the policies
   represented by the set of rights are reflected in the system
realization
   (Section 7) and not part of a more general policy framework or
model." 

And, then reword the last two paragraphs as follows:

   "A policy framework and model for centralized conferencing, including
a mechanism for 
    defining the permissions and  limitations,  is an item for future
study."

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 29 Apr 2007 13:01:45 +0300

Hi,

the arguments given in our last face-to-face meeting to remove all 
policy-related stuff from the data model at this point were:

1) if we specify something now, when, at a later point, we study the 
problem carefully, what we do now may influence what we can do in the 
future. It would be better to be able to work on the problem without 
this type of restrictions.

2) defining two ways to define policies may lead to conflicts and 
collisions. We would need extra rules (and, thus, extra complexity) to 
resolve such conflicts.

Therefore, I would prefer if we worked on policies afterwards and did 
not include any policy-related mechanism at this point.

Cheers,

Gonzalo

Mary Barnes wrote:
> _http://www3.ietf.org/proceedings/07mar/minutes/xcon.htm_
> 
>    represented by the set of rights are reflected in the system realization
>    (Section 7) and not part of a more general policy framework or model."
> 
> ------------------------------------------------------------------------
>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 30 Apr 2007 11:33:41 -0500

I don't at all have a problem with the decision to remove policies from
the data model and not include any mechanisms at this time. 

But, I still think we need to talk about policies in the context of the
framework (and in particular the read/write and how the child may or may
not also inherit policy properties from the parent).  I think there are
implied requirements on the policy solution in the framework and I don't
want to lose the context of those.  And, given the other thread
proposing that the framework is informational, there would be nothing
normative in this text.  

And, it should be clear that the policy mechanism is not defined in this
document and will be defined in another document, either as part of the
protocol document or a separate document.  For the record, I am opposed
to this WG deciding at this time to work on a separate policy document.
I think the work plan of completing the data model and then working out
the details of the Conference Control Protocol should be worked, as I
think the policy may be dependent upon the protocol choice. 

The text I need to remove from the framework would be around policy
information being an integral part of the data model. I think the
general consensus seems to be that they are not. Folks, please speak up
now if you disagree with this point.

I'll proposed the detailed text changes in a separate email in case
folks what to debate this general topic further. And, it would be good
for some other voices to chime in with opinions. 

Mary

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Sunday, April 29, 2007 5:02 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: Re: [XCON] Removing Policies from the framework document (and
data model)

Hi,

Cheers,

Gonzalo

realization
model."

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Apr 2007 19:59:36 +0300

Hi Mary,

> proposing that the framework is informational, there would be nothing

sure, we can talk about that in the framework... but if we do that, I 
would suggest delaying the publication of the framework until we have a 
clear idea on how policies will be specified. Talking about read/write 
and inheritance without knowing how policies are going to be implemented 
seems a little risky to me.

> think the policy may be dependent upon the protocol choice. 

I am afraid I do not fully understand the work plan you propose in the 
paragraph above. Could you please clarify it for me?

> now if you disagree with this point.

I believe we have consensus on working on the policy issues in a 
different Internet Draft. However, such an internet draft may very well 
define policy elements that are an extension of the data model. In that 
case, policies would indeed be part of the data model (they would 
actually be an extension of the data model).

If by "integral part" you mean that they are defined as part of the data 
model and not as an extension, then I agree with your statement.

> for some other voices to chime in with opinions. 

Yes, it would be great to hear different opinions.

Cheers,

Gonzalo

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 30 Apr 2007 12:22:59 -0500

More comments embedded below [MB].

Mary

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Monday, April 30, 2007 12:00 PM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: Re: [XCON] Removing Policies from the framework document (and
data model)

Hi Mary,

[MB] I do not think we need to delay the framework.  I don't think that
the idea of the child inheriting policy is so much a policy issue as it
is a system implementation issue. The inheritance concept was a basic
approach that we agreed long ago - the mechanisms to achieve that aren't
specified, but the idea is an important concept for describing how one
might design a conferencing system to support these various protocols.
The whole idea of the framework is to provide a context for describing
the protocols.  I honestly think the text remains at an abstract enough
level that it's not going to limit an implementation, but rather guide
it.  I think it would be really good if this group could agree that they
agree on these basic concepts before moving forward, but it really
matters not to me if we want to keep the framework within the WG until
all the protocol work is done.   But, I didn't think that was the
direction the chairs intended us to go.   

<Editor hat off> I'm actually very happy to start talking about how we
can very easily implement policies based on XACML. And, I feel quite
comfortable in saying that the high level concepts in the framework
don't seem to cause any problems if that is selected. 
<Editor hat back on>
[/MB]

I am afraid I do not fully understand the work plan you propose in the 
paragraph above. Could you please clarify it for me?
[MB] My concern is that the group will rathole if we decide to go off
and define a policy control framework for the data model before we agree
the protocol for the conference control based on that data model. I
think once the group can agree a conference control protocol, the policy
approach might well be a straightforward choice of selecting something
that's already been developed. 
[/MB]

I believe we have consensus on working on the policy issues in a 
different Internet Draft. However, such an internet draft may very well 
define policy elements that are an extension of the data model. In that 
case, policies would indeed be part of the data model (they would 
actually be an extension of the data model).
[MB] I think we had consensus to not work on policy in the data model
and to not work on policy in the framework.  However, my point above, I
think it's pre-mature for this group to start working a policy model.
Per the point above, I understood the work plan for this working group
to be to work on the protocol once we completed the data model.
[/MB]

model and not as an extension, then I agree with your statement.
[MB] Yes, on this one point, we agree. [/MB]

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Apr 2007 20:28:11 +0300

Hi Mary,

I am OK with letting the chairs decide whether or not we should delay 
the publication of the framework.

I am also OK with starting working on the control protocol as soon as 
the data model is WGLCed.

Cheers,

Gonzalo