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

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/