Subject: re: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt

From: "Robert Moore" <[email-masked]>
Date: Wed, 2 May 2001 15:52:23 -0400

OK, I've made these changes in the draft.
In updating sections 5.7 and 5.10, I found
that I also needed to make the second
paragraph in each section a little more
"subclassy".

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

[email-masked]@raleigh.ibm.com on 04/27/2001 07:22:53 PM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   "Mircea Pana" <[email-masked]>, [email-masked]
cc:   Ed Ellesson <[email-masked]>, "Joel M. Halpern"
      <[email-masked]>
Subject:  re: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt

Mircea-

What we are trying to capture is that you can attach subclasses of
policyConditionAuxClass and policyActionAuxClass.  Attaching those classes
is (in my view) a null action, because they don't define anything.  We are
bound by the LDAP syntax rules because if we
mark them as ABSTRACT, then we cannot use them in any content rules and the
content
rules should be as general as possible so that future updates don't require
an update of
this document.

This (I think) is clarified by the following changes:

Add the following sentence to the second paragraph of Section 5:

   If your implementation does not support auxiliary class inheritance and
supports content
   rules, you will have to list auxiliary classes in content rules
explicitly.

Replace the first paragraph of 5.7 with

   The purpose of a policy condition is to determine whether or not the
   set of actions (contained in the policyRule that the condition applies
   to) should be executed or not.  Subclasses of this auxiliary class can
be attached
   to instances of three other classes in the Core Policy Schema.  When
   a subclass of this class is attached to an instance of
policyRuleConditionAssociation, or to
   an instance of policyRule, it represents a rule-specific policy
   condition.  When a subclass of this class is attached to an instance of
policyInstance, it
   represents a reusable policy condition.

and replace the first paragraph of 5.10 with

   The purpose of a policy action is to execute one or more operations
   that will affect network traffic and/or systems, devices, etc. in
   order to achieve a desired policy state.  Subclasses of this auxiliary
class can be
   attached to instances of three other classes in the Core Policy
   Schema.  When a subclass of this class is attached to an instance of
   policyRuleActionAssociation, or to an instance of policyRule, it
   represents a rule-specific policy action.  When a subclass of this class
is attached to an
   instance of policyInstance, it represents a reusable policy action.

Ryan

> ** Original Subject: Re: WG Last Call on
draft-ietf-policy-core-schema-10.txt
> ** Original Sender: "Mircea Pana" <[email-masked]>
> ** Original Date: Fri, 27 Apr 2001 09:22:16 -0500

> ** Original Message follows...

>
> I would greatly appreciate if the authors could address this issue
> before the end of the "last call" (CoB Mon., April 30).
>
> Thanks,
> Mircea.
>
>
> "Pana, Mircea (M.) [EXCHANGE:CAR:5E20]" wrote:
> >
> > The policyCondition and policyAction are modeled as auxiliary object
> > classes. Therefore it seems to be valid to attach them without
> > specialization to entries of various structural classes. Should this be
> > allowed? For example: LDAP allows the attachment of a
> > policyConditionAuxClass class to a policyInstance entry without
> > attaching any of the policyConditionAuxClass subclasses.
> >
> > IMO: If this is acceptable then a clarification should be added to PCLS
> > to describe the evaluation / execution semantics? If this is not
> > acceptable then additional constraints should be added as text or the
> > class types should be changed from AUXILIARY to ABSTRACT.
> >
> > Regards,
> > Mircea.
>
> Ed Ellesson wrote:
> >
> > The latest revision of the Policy Framework LDAP Core Schema is in the
I-D
> > repository.  This revision reflects all known issues and comments.
> > This note commences a two week working group last call, intended to
bring
> > forth any last issues.  After such issues are resolved according to the
> > working group consensus, we will be submitting this document to the
IESG
> > for approval as a proposed standard.
> >
> > This last call ends  at CoB on Mon, April 30.
> >
> > Thank you,
> > Joel M. Halpern
> > w/ Ed Ellesson

>** --------- End Original Message ----------- **