[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)



Thank you Andrea.
Joel

At 12:00 AM 5/22/01 -0700, you wrote:
>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.
>
>
> >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."
>  $ Policy Management Information Base (MIB)
>       (T) Collections of policy-related managed objects, defined as
>         a module and accessed via an SNMP framework.
>
> >
> >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.
>
>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