Subject: RE: PolicyRepository (Re: Preliminary results from PCIMe technica l meeting, 1/24/01 - 1/26/01)

From: Ed Ellesson <[email-masked]>
Date: Thu, 8 Feb 2001 10:26:14 -0500

Hi, everyone,  

I'm still breathing, re-surfacing at my new job, with a start-up, and with a
new email address.  Sorry for the absence from interaction with the list.  I
was at the PCIMe technical meeting, week before last, and then was at the
Policy 2001 workshop in Bristol, UK last week.  

With regard to our conflicting use of the term "repository":

As co-chair, I want to see a consensus that resolves the confusion that
current and future users of the model have and will have, with regard to our
conflicting fuse of the term "repository", albeit in different contexts: the
PCIM and PCIMe documents, and the Policy Framework (four-box picture)
document.  I have to agree with Yoram R. that our use of the term
"repository" has been very confusing.  It causes extreme confusion with
people who are new to the model, and it even causes confusion with people
who have been working with it for some time, when they try to relate it to
the four box framework.  What brought this issue to a head, in the PCIMe
technical meeting two weeks ago, is that this conflict  made it hard to even
talk about, and think about, the technical problems we were dealing with,
since we had to continually qualify the context, every time we opened our
mouths.    

<Begin, as contributor>

As a contributor, I have a personal opinion that agrees with Bob, I think,
and that is I would prefer to change the term in the Policy Model, since we
are making other deprecatory changes there anyway.  If there were no other
deprecations to to the model to be made, then I would favor changing the
name in the four box picture.    

The reason, in my opinion, that we did not change it before this, is that
when we were focused on PCIM and QPIM,  the issue of confusion with the term
"Policy Repository" in the four box picture did not come up, because we were
not focused on the four box picture at all then.  But as soon as we start
talking about the model in the context of the four box framework, we get
ourselves all tangled up again, just as Yoram explained in his note.  

If this was the only change we had to make that involved deprecating
something in PCIM, I would agree that it would make more sense to change the
name in the four box architecture picture to remove the confusion, since
that document needs a lot of revision work anyway, before it goes to
informational rfc.  (In fact, it was my suggestion to consider this option,
that Bob referred to in his note.)  

However, since we have to make some deprecation changes to PCIM anyway, I
would favor making the change to the name of the class in the model, since I
believe new people coming to the model will more intuitively understand the
use of "repository" in the four-box framework context, than in the context
of the model.  

This is just my two cents (or less) as a contributor.  

<End, as contributor>

As co-chair, I am seeking consensus, and will, of course, accept whatever
the sense of the working group turns out to be.  To that end, I would like
to see more comments on this issue from the authors and other contributors,
and from the other members of the mailing list, as well as the AD's, if they
have an opinion regarding changing/deprecating something that we have
already  so recently sent to proposed standard.  In that sense, this project
becomes something of a "PCIM-bis", similar to other working groups who have
gone through iteration of their standards with implementation experience.

Looking for more comments, positions, etc.

Ed Ellesson
LongBoard, Inc. 
[email-masked]
919-361-3230

 -----Original Message-----
From: 	Yoram Ramberg [mailto:[email-masked]] 
Sent:	Thursday, February 08, 2001 3:20 AM
To:	Lee Rafalow; [email-masked]
Subject:	Re: PolicyRepository (Re: Preliminary results from PCIMe
technical meeting, 1/24/01 - 1/26/01)

(finally we have a thread to talk about it and I can't be blamed for 
starting it!)

I admit that I've experienced some confusion in the way we use the term 
'repository' to denote various things. Here's an attempt to organize this 
somewhat:

Policy repository: This term has been used mostly to refer to storage. It 
has been synonymous at times with the term 'policy database'.

Reusable-objects repository: This term has been used to refer to the 
classes that model the collection(s) of objects that are "reusable", i.e., 
can be managed centrally but referred to ("used") by other objects. An 
example is a reusable condition used by many rules.

Repository: Has also been used to refer to a directory (LDAP). This was 
mostly used in schema documents but sipped sometime into info model docs as 
well.

To me the first two have been confusing and required me to do a double take 
several times while reading (even text I myself had written!). In 
particular this becomes tricky when reading through text such as this (not 
a real example, just a possible one, but we have a couple of places that 
almost read like this):

"The object may be placed in the reusable-objects repository. Several 
reusable-objects repositories may exist in the policy repository. The 
administrator is free to locate the repositories anywhere within his/her 
own organization repository as long as objects associated with 
reusable-objects have access to the repositories where they 
reside.'"    Not easy, is it?

While I learned to deal with it (after all, life has presented me with 
greater challenges before and since), it would be nice to take this 
opportunity and get it cleared out once and for all.

I'll refrain from making a proposal for new terminology but I support this 
effort for the reasons explained above.

*Yoram

At 11:17 AM 2/6/01 -0500, Lee Rafalow wrote:
>John,  Thanks for your comments.  I'm breaking responses into different
>threads for the different topics.  I think this one is easy.
>
> > >  2.2.1. Changes to PolicyRepository
> > >
> > >    Because of the potential for confusion with the Policy
> > > Framework component Policy Repository (from the four-box
> > > picture: Policy Management Tool, Policy Repository, PDP,
> > > PEP), it was determined that "PolicyRepository" is a bad
> > > name for the PCIM class representing a container of
> > > reusable policy elements.  Thus the class PolicyRepository
> > > has been replaced with the class ReusablePolicyContainer.
> > > To accomplish this change, it was necessary to deprecate
> > > the PCIM class PolicyRepository and its three
> > associations,
> > > and replace them with a new class ReusablePolicyContainer
> > > and new associations.
> >
> > <js>
> > I don't agree with this change. If this was so confusing,
> > why has the name withstood the examination of all for over a
> > year in this working group? Deprecating a class and its
> > associations to fix a problem that has not been complained
> > about is a bad decision.
> > </js>
>
>I don't believe the name has withstood the examination.  I've been confused
>about PolicyRepository since its inception and we've talked about this
>several times.  I know others are also confused (including some people in
>your own company).  One suggestion has been made that we change the name of
>the policy repository in the architecture drawing but that IS a policy
>repository by the English use of the words whereas the PolicyRepository
>class isn't a repository at all, it's an admindomain subclassed container
>object for reusable policy components.  So, we concluded we ought to call
it
>that: ReusablePolicyContainer.  If we were going to do something dramatic
>here, we'd change its superclass to a collection...but that hasn't been
>proposed.
>
>What's the harm in what we're proposing?  Well, it does necessitate
>deprecating a few classes but this is the time to do that if we're going
to.
>PCIM is Proposed and we've been asked to reconcile PCIM and the other
>drafts.  Is it essential to do this?  No, I don't think so, but I do think
>we should.  If there are any implementations out there that have carved
this
>in stone...we'll, we're deprecating its use, we're not deleting it.
>
>I think this is a red herring and not worth debating unless there's some
>reason for concern that I don't grok.  But if someone thinks it's a
critical
>error to change the names of some classes in an Information Model, well, I
>yield...but tell me why it's critical.  We're going to deprecate other
>things in the process, so it can't be that we can't change PCIM.
>
> > >    As a separate change, the definition of a
> > > ReusablePolicyContainer was broadened, to allow it to
> > > contain any reusable policy elements.  In PCIM, a
> > > PolicyRepository was allowed to contain only policy
> > > conditions and policy actions.
> >
> > <js>
> > Huh? The definition of this class, from PCIM, is:
> >
> >   "A class representing an administratively defined
> >    container for reusable policy-related information."
> >
> > I've searched PCIM, and there is no text describing the
> > restriction you talk about above defined anywhere. This
> > *used* to be a restriction of QPIM, but that was removed a
> > long time ago.
> > </js>
>
>The only associations that were defined in PCIM were associations for
>conditions and actions.  The broadening that Bob referred to is that we're
>now explicitly extending the list in PCIMe rather than leaving it up to
>derived models to do so.  Again, nothing to debate here either.
>
>Cheers, Lee

---

From: John Strassner <[email-masked]>
Date: Thu, 08 Feb 2001 10:35:40 -0800

Hi Ed,

thanks for your note. I guess I've just been around this too long. I still 
don't see how referring to the class PolicyRepository conflicts with a data 
store, a.k.a., a policy repository. As such, I've presented my arguments as 
best I can. If others really think that this change is necessary, I'll stop 
clogging the mail lines. It just worries me that instead of extending PCIM, 
we seem to have sounded a "Hunting Season is Now Open" call instead.

regards,
John