Subject: Re: PolTerm - Re: PolicyRepository (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)

From: Yoram Ramberg <[email-masked]>
Date: Thu, 01 Mar 2001 09:34:23 +0200

Thanx Andrea. I believe your quotes from POLTERM just underscore and 
accentuate the weakness of the current terminology.
Shall we fix it while we still can?
*Yoram

  At 09:39 PM 2/28/2001 -0800, Andrea Westerinen wrote:
>The Policy Terminology I-D has begun to address this issue by at least
>acknowledging it ...
>
>$ policy repository
>(P) "Policy repository" can be defined from three perspectives:
>-       A specific data store that holds policy rules, their conditions and
>actions, and related policy data.  A database or directory would be an
>example of such a store.
>-       A logical container representing the administrative scope and 
>naming of
>policy rules, their conditions and actions, and related policy data. A "QoS
>policy" domain would be an example of such a container.
>-       In [RFC3060], a more restrictive definition than the prior one 
>exists. A
>PolicyRepository is a model abstraction representing an administratively
>defined, logical container for reusable policy-related elements.
>
>Andrea
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Yoram Ramberg
>Sent: Thursday, February 08, 2001 12:20 AM
>To: Lee Rafalow; [email-masked]
>Subject: PolTerm - 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: "Michael See" <[email-masked]>
Date: Thu, 01 Mar 2001 09:27:03 -0500

Documenting the multiple uses of the term Policy Repository an a Terminology
document seems like it should be sufficient.

While I don't have a major problem with the suggested changes.  It seems strange
that we are considering depricating classes in an RFC that was just published.

Mike