[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PolTerm] Re: snmpconf Re: SNMPCONF WG Notice: Policy Terminology Draft, Extended WG Last Call (fwd)



In the next version of the Terminology draft, to be submitted tomorrow, the
following changes have been made:

1.  AAA was revised as documented below.

2.  Revised the definition of MIB and Management Information Base.  Here is
the new MIB definition:
$ Management Information Base (MIB)
(T) A definition of management information. A MIB Module is a collection of
related managed objects, encoded using SMI and accessed via an SNMP
framework.  Quoting from RFC 2570 [R2570], "MIB modules define the
management information maintained by the instrumentation in managed nodes,
made remotely accessible by management agents, conveyed by the management
protocol, and manipulated by management applications." In a MIB module,
managed objects are organized hierarchically in an object identifier tree.
Nodes in the tree may identify objects and their variables, conceptual
tables, rows of conceptual tables, groups of objects and/or notifications,
compliance statements, or other information.  MIBs can be used to convey
policy information. (See also "Simple Network Management Protocol.")

3.  Removed the term "Policy Management Information Base" due to the
possibility for confusion

4.  Added a description for SNMP that included a shortened form of the text
from the SNMPCONF definition below.  Here is the definition:
$ Simple Network Management Protocol (SNMP)
(T) SNMP is a framework (including a protocol) for managing systems in a
network environment. [R2570]  It can be used for policy-based configuration
and control using a specific MIB Module designed to execute policies on
managed elements via scripts.  The elements (instances) in a network device
are evaluated using a policy filter, to determine where policy will be
applied.

5.  Added the recommended sentence to the description for techniques (T).

The decision was made not to reopen the definitions of policy translation
and abstraction.  In the version 3 draft, words were added to support the
SNMPCONF BCP.  Here is the previous/current definition of policy abstraction
(your draft does not use the term, policy translation).

   Policy can be represented at different levels, ranging from business
   goals to device-specific configuration parameters. Translation between
   different levels of "abstraction" may require information other than
   policy, such as network and host parameter configuration and
   capabilities. Various documents and implementations may specify
   explicit levels of abstraction. ...

I do not believe that there are any conflicts between your document and the
terminology.

Andrea

-----Original Message-----
From: owner-snmpconf@snmp.com [mailto:owner-snmpconf@snmp.com]On Behalf
Of Jon Saperia
Sent: Tuesday, May 22, 2001 10:48 AM
To: snmpconf@snmp.com
Cc: policy@raleigh.ibm.com
Subject: [PolTerm] Re: snmpconf Re: SNMPCONF WG Notice: Policy
Terminology Draft, Extended WG Last Call (fwd)


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

> Replies inline.
> Andrea
>
> -----Original Message-----
> From: owner-snmpconf@snmp.com [mailto:owner-snmpconf@snmp.com]On Behalf
> Of Jon Saperia
> Sent: Friday, May 18, 2001 1:24 PM
> To: policy@raleigh.ibm.com
> Cc: snmpconf@snmp.com
> Subject: snmpconf Re: SNMPCONF WG Notice: Policy Terminology Draft,
> Extended WG Last Call (fwd)
>
>
> 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.:
>
> <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.
>

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.

>
> >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.
>
> <arw> OK.
>
> >
> >    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.
>
> <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."

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

>  $ Policy Management Information Base (MIB)
>       (T) Collections of policy-related managed objects, defined as
>         a module and accessed via an SNMP framework.
>
The document has:

$ MIB
      See "Policy Management Information Base."

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.

> >
> >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.
>
> <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.

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.


>
> SNMP and SNMPCONF should be added to the terminology section.
>
> <arw> I will add a description of SNMP as a "technique", but will be
> removing all WG references.
>
> >
> >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: policy@raleigh.ibm.com
> > > To Subscribe: policy-request@raleigh.ibm.com
> > > 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                  saperia@jdscons.com
> >                              Phone: 617-744-1079
> >                              Fax:   617-249-0874
> >                              http://www.jdscons.com/
>
>
>
> ------- End of Forwarded Message
>
>
>

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/