Subject: Policy Terminology: Policy Domain

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Mar 2000 00:12:03 -0500

The presentation today mentioned that there was some ambiguity to the 
definition of "policy domain".  I have a question in that regard.

The definition of Policy Domain says
     "A policy domain is a collection of objects that have been
      explicitly grouped together in order to administratively share the
      same policies."
Later on, in talking about nested policy domains the definition says:
     "Note, however, that a nested domain is not necessarily a subset of the
      parent domain, because an object in the nested domain may not be a direct
      member of its parent domain."

What does this mean?  If you have a nested policy domain, do all of the 
policies of the parent domain apply to it, or not?  From the first section, 
and from trying to understand the purpose of nesting, I would expect all of 
the policies of a domain to apply to all domains nested within it.  Either 
I have completely misunderstood the point of the sentence about "is not 
necessarily a subset of the parent domain", or else these policies are not 
intended to apply to the nested domains.  Can someone please tell me 
explicitly whether we intend for child policies domains to inherent the 
policies of their parent domains, and then explain the sentence quoted 
above in the context of the answer?

Thank you,
Joel M. Halpern

---

From: Morris Sloman <[email-masked]>
Date: Mon, 27 Mar 2000 10:33:51 +0100

At 06:12 27/03/00, Joel M. Halpern wrote:
>policies of the parent domain apply to it, or not?  From the first 
>section, and from trying to understand the purpose of nesting, I would 
>expect all of the policies of a domain to apply to all domains nested 
>within it.  Either I have completely misunderstood the point of the 
>sentence about "is not necessarily a subset of the parent domain", or else 
>these policies are not intended to apply to the nested domains.  Can 
>someone please tell me explicitly whether we intend for child policies 
>domains to inherent the policies of their parent domains, and then explain 
>the sentence quoted above in the context of the answer?
>
>Thank you,
>Joel M. Halpern

If you think of a domain as being similar to a file system directory then 
the above may be easier to follow.  Members of a sub-directory are not 
members of a parent directory.

A policy applying to a domain should, by default, propagate to nested 
domains.

Consider domain D1 with member objects a, b, c and nested domains D1, D2.

D2 contains member objects d, e  and D3 contains member objects f, g.

{a, b, c} are direct members of D1
{d, e, f, g) are indirect members of D1

When determining the objects to which a policy applies you have to 
'flatten' the domain structure to determine the set of objects in the scope 
of the policy.

A policy applying to D1 will propagate to nested domain and hence apply to 
objects {a, b, c, d, e, f, g}

A policy applying to D2 will only apply to objects {d, e}

In set theory there would be no distinction between direct and indirect 
members.

Nested domains can be used to group objects to reflect LAN structures, 
Organisational structures etc.

In our policy notation we provide the option of limiting the propagation of 
policies to nested domains (if that is required) so it is possible to 
specify a policy applying to D1 that only applies to objects {a, b, c}.

Morris Sloman

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Mar 2000 18:29:53 -0500

Sorry to copy so much, but all the comments are up here.  The rest is for 
context.

Morris, I have two issues with what your clarification:
1) I believe the text that says "may not be a direct member of its parent" 
is completely misleading.  Most readers will, after scratching their head, 
conclude that direct does not change the meaning and that the sentence says 
that the members of the child are not members of the parent.  But for 
policy purposes they are members.    This is because there is no important 
"collection criteria" other than whether there is common policy.
2) I believe that having provision for a child domain to not inherit the 
parent's policies is counter-productive.  It will lead to users 
mis-understanding the impact of behavior.  If the child is not inheriting 
the policies of the parent, why is it a nested domain?  Just make it 
separate.  If you are trying to use the domain nesting to keep human 
readable information (engineering is part of corporate, but has different 
policies from corporate), nesting is not a good way to achieve that.  This 
is because if the policies are not inherited, then the relationship is not 
a policy relationship.  Thus, it should be represented some other way than 
the nesting of policy domains.

Yours,
Joel M. Halpern

At 10:33 AM 3/27/00 +0100, you wrote:
>>[My question asked what this was supposed to mean.]
>
>
>A policy applying to a domain should, by default, propagate to nested domains.
>
>'flatten' the domain structure to determine the set of objects in the 
>scope of the policy.
>
>In our policy notation we provide the option of limiting the propagation 
>of policies to nested domains (if that is required) so it is possible to

---

From: Morris Sloman <[email-masked]>
Date: Tue, 28 Mar 2000 21:58:50 +0100

At 00:29 28/03/00 , you wrote:
>conclude that direct does not change the meaning and that the sentence 
>says that the members of the child are not members of the parent.  But for 

Joel

Everyone is used to hierarchical directory structures.
Domains are very similar.

I am not sure what you mean by a "collection criteria".  the membership of 
a domain is not defined by a predicate eg a domain is not defined by all 
files of type .doc.  A manager may choose to explicitly include all files 
of type .doc into  a particular domain if there is a reason to do so.

The domain structure may be defined in order to support partitioning of 
responsibility, the many different types of policy ( authorisation, QoS, 
configuration ......) which can apply to objects.

>mis-understanding the impact of behavior.

Our notation specifies quite clearly whether a policy propagates to nested 
domains so it is not difficult to understand.  This just reflect user 
requirements  - eg you may wish to specify a backup policy that backs up a 
top level domain in one place but a different type of policy for a sub-tree 
structure of domains within the top level one.

>  If the child is not inheriting the policies of the parent, why is it a 
> nested domain?  Just make it separate.

this may not be practical - a domain structure may need to reflect 
organisation structure.  Separating the structure requires repeating the 
policies.

I want to specify a policy X for all people in the organisation  O.
I want another policy Y that applies only to Department D1 within the 
organisation, and policy Z that applies to Group G1 within D1

I can do this quite easily if D1 is a sub-domain of O, and G1 is a 
subdomain of G1.  I only need to specify 3 policies.

>  If you are trying to use the domain nesting to keep human readable 
> information (engineering is part of corporate, but has different policies 
> from corporate), nesting is not a good way to achieve that.

We think it achieves exactly that, because that is the way people will 
specify policies - There are corporate policies eg access to services, 
available to everyone and some specific to Engineering.  Corporate policies 
should also  apply to Engineering.

>  This is because if the policies are not inherited, then the relationship 
> is not a policy relationship.

There is not just one policy applying to the domain structure - there will 
be many different ones. In most cases, policies propagate but you can limit 
the propagation if there is a need to do so.
You may also have to set up a domain sub-structure specifically  for a 
particular type of policy.  We allow objects to be members of multiple 
domains - ie overlapping domains.

>   Thus, it should be represented some other way than the nesting of 
> policy domains.

Why invent something new when you have a well understood, simple concept of 
hierarchical nested domains ( cf directories) that serve the purpose very 
well?

Morris
__________________________________________________

Professor Morris Sloman
Imperial College of Science Technology and Medicine
Department of Computing
180 Queen's Gate
London SW7 2BZ, U.K.
Phone: +44 20 7594 8279    Fax: +44 20 7581 8024
Email: [email-masked]
WWW: http://www-dse.doc.ic.ac.uk/~mss

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Mar 2000 18:47:16 -0500

If the text below is your intent:

>configuration ......) which can apply to objects.

then the definition of Policy Domain should not assert that all members of 
a Policy Domain share the same policy.  I (like most people as you say) 
understand the notion of folder / directory for grouping related 
things.  But noone asserts that all members of a directory share the same 
policies.  We should either assert that all members share policies, and 
mean it, or we should not make that the definition.  I am not hung up on 
which path we take, but the current definitions try to take both sides of 
the street at once.

Yours,
Joel M. Halpern