Subject: snmpconf Re: SNMPCONF WG Notice: Policy Terminology Draft, Extended WG Last Call (fwd)

From: Jon Saperia <[email-masked]>
Date: Fri, 18 May 2001 16:24:04 -0400

Joel sent my posting back to me the other day with the suggestion that I
reforward it to the Policy WG and that I add as much specific lanaguage
as possible.

At 06:21 PM 5/14/01 -0400, Jon Saperia wrote:
>Ed,
>
>Thanks for the additional poke. I have commented on previous versions of
>this document. One of my original concerns still stands in that the
>document often references the COPS protocols and not SNMP in the context
>of Policy information. Specifics:
>
>    1. There is no reference to SNMPCONF.:

From page 3:

       - "T" identifies various techniques to create or convey 
         policy-related information in a network.  For example, 
         COPS and an "Information Model" are two techniques for 
         communicating and describing policy-related data. 

Replace with:

       - "T" identifies various techniques to create or convey
       policy-related information in a network.  For example, COPS and
       an "Information Model" are two techniques for communicating and
       describing policy-related data. SNMP and MIBs are another.
.
>
>    2. There is an incorrect impression left by the definition of PIB and
>    MIB that MIBs do not/can not carry policy information.  In fact the
>    definition of a MIB points back to a PIB.
>
>An additional comment:
>
>    Policy Translation - This mixes access methods (such as CLI) with
>    level of abstraction. If you want to call translation the thing you
>    do when moving from one access method to another great. There is way
>    too much in the current policy translation definition to be helpful I
>    do not agree with the use of 'blurring' in this definition.

SNMP and SNMPCONF should be added to the terminology section.

>
>Thanks
>/jon
>
>
>
>
> > SNMPCONF WG:
> >
> > Our AD has asked us to inform your WG that this WG Last Call is
> > going on in the Policy Framework WG. This is to give you a
> > chance for review and comments, because the terminology is also
> > meant to be used by your WG.
> >
> > Extended WG Last Call:
> >
> > This last call is hereby extended to end at CoB on Fri, May 18, 2001.
> >
> > The latest revision of the Terminology Draft is in the I-D
> > repository.
> >
> > for your reference:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt
> >
> >
> > Please also note that the title is changing to be more
> > descriptive:
> >
> >       Terminology for Policy-Based Management
> >
> > This revision reflects all known issues and comments.
> > This note extends the current working group last call,
> > to two weeks from today, and is 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 publication as an informational RFC.
> >
> >
> > We are also strongly suggesting that the comments/discussion be done to/on
> > the
> > policy fw wg mailing list... so that we have one archive to check later if
> > needed.
> >
> > If you are not already subscribed to the policy framework mailing list:
> > General Discussion: [email-masked]
> > To Subscribe: [email-masked]
> > In Body: subscribe
> > Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy
> > Thank you, and we apologize if you receive more than one notice like this.
> >
> > Ed Ellesson,
> > with Joel Halpern
> >
> > Co-chairs, Policy Framework Working Group
> >
> >
> >
> >
>
>Thanks,
>/jon
>--
>
>Jon Saperia                  [email-masked]
>                              Phone: 617-744-1079
>                              Fax:   617-249-0874
>                              http://www.jdscons.com/

------- End of Forwarded Message

---

From: "Andrea Westerinen" <[email-masked]>
Date: Tue, 22 May 2001 00:00:18 -0700

Replies inline.
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Jon Saperia
Sent: Friday, May 18, 2001 1:24 PM
To: [email-masked]
Cc: [email-masked]
Subject: snmpconf Re: SNMPCONF WG Notice: Policy Terminology Draft,
Extended WG Last Call (fwd)

>    1. There is no reference to SNMPCONF.:

<arw> We have tried to clean up the references to WGs in the document - but
I see that AAA still talks about the WG.  I would rather move the sentences
around in the definition of AAA (as noted below), than to include the
existence of IETF WGs in an RFC.  Here is a new definition for AAA:
      (A) AAA deals with control, authentication, authorization and
        accounting of systems and environments based on policies
        set by the administrators and users of the systems. The use
        of policy may be implicit - as defined by RADIUS [R2138].
        In RADIUS, a network access server sends dial-user credentials
        to an AAA server, and receives authentication that the user is
        who he/she claims, along with a set of attribute-value
        pairs authorizing various service features.  Policy is implied
        in both the authentication, which can be restricted by time of
        day, number of sessions, calling number, etc., and the attribute-
        values authorized.

From page 3:

Replace with:

<arw> OK.

>    definition of a MIB points back to a PIB.

<arw> Could you elaborate on this comment (that MIBs point to a PIB)?  This
is what is in the draft ...
 $ MIB
      See "Policy Management Information Base."
 $ Policy Management Information Base (MIB)
      (T) Collections of policy-related managed objects, defined as
        a module and accessed via an SNMP framework.

>    do not agree with the use of 'blurring' in this definition.

<arw> We have spent much time arguing over levels of translation and
abstraction in the WG and within the policy terminology editors list.  This
issue has been raised at least twice before, with a decision to keep the
definition "as is".  Translation is not restricted to "moving from one
access method to another".  You could translate in a single tool from policy
goals and SLAs to specific device representations (with no access methods
involved at all).  The reality is that the industry and implementations have
blurred this term.  However, if you would like to propose a specific
rewrite, I would be happy to discuss this one more time.

<arw> I will add a description of SNMP as a "technique", but will be
removing all WG references.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 May 2001 09:06:20 -0400

Thank you Andrea.
Joel

---

From: Jon Saperia <[email-masked]>
Date: Tue, 22 May 2001 13:47:30 -0400

Andrea, thanks for the comments. I think we can get everything done with
this reply.

>         day, number of sessions, calling number, etc., and the attribute-

I understand your desire to reference technology as opposed working
groups. I propose the following as an SNMPCONF technology description:

        SNMPCONF is an approach for configuration and control of systems
        in a network environment. This approach includes policy-based
        configuration and control and is based the existing SNMP
        management framework. It includes a new MIB Module that is
        designed to execute policies on managed elements via scripts
        that have been installed on the managed elements. This module
        provides the facilities for the evaluation of the elements
        (instances) in a network device via a policy filter to which the
        policy will be applied, the policy action. The SNMPCONF approach
        also defines the methods by which MIB Objects can be used to
        express policy information a different levels of abstraction so
        that information can be more concisely conveyed between managers
        and the managed elements.

>       See "Policy Management Information Base."

A PIB is not a MIB and a MIB Is not a PIB.

>         a module and accessed via an SNMP framework.
The document has:

$ MIB 

The above definition, combined with the following for a Policy Management
Information Base  that follows are incorrect.
$ Policy Management Information Base (MIB)  
      (T) Collections of policy-related managed objects, defined as 
        a module and accessed via an SNMP framework.   

The MIB and MIB Modules have been well documented in various RFCs. I
recommend that you use that plus the text I wrote above for techniques
for describing Managed objects in MIB Modules at various levels of
abstraction. I think it would be helpful to use the pointer I will
provide below to the BCP for additional information.

I am sure you can find many people to offer definitions of a PIB.

> rewrite, I would be happy to discuss this one more time.

I am not sure that we want to codify a bad practice. In terms of offered
definitions. They have been in the SNMPCONF BCP for some time. The Most
recent version has definitions for levels of abstraction in:

        draft-ietf-snmpconf-bcp-05.txt

See pages 43 - 49.

If you find that these do not 'work' that is fine since we then will
have established at least that we have not created conflicting
terms. Levels of abstraction as they relate to an SNMP-based policy
system are defined in the pages referenced above.

Perhaps the most important point here is not so much consensus, though
that would be great, we want to be sure that we have not created
conflicting terms.

Thanks,
/jon
--