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

Re: snmpconf Re: Comments on the draft-ietf-policy-terminology-00.txt document



It was in our attempt to include both terms from both the COPS and the 
SNMP-CONF efforts that we included Policy MIB along with PEP and PDP.
Please send replacement (corrected) text for this definition.

In general, the Policy Terms draft has been around long enough that
the preferred form of comments is replacement (or edited) text rather
than general questions.

This preference also applies to the comments regarding other database
technologies. We would gladly include any policy terms that reference
databases other than directories or MIBs.

It is worth noting that this terminology draft is not intended to imply
any particular architecture for policy management.

John

At 03:14 PM 11/20/2000 -0500, Jon Saperia wrote:
>Andrea Westerinen wrote:
>>..
>When you reference COPS as in the case above and PDPs and PEPs, they are
>protocol specific concepts. A policy management application and/or agent
>would be the comparable items in a Policy-enabled SNMP environment. 
>
>> $ Policy Management Information Base (MIB)
>>    (T) Collections of policy-related managed objects, defined as
>>    a module and accessed via an SNMP framework.  [PolicyMIB]
>> This definition is consistent with the PIB one.  Other than this new
>> technique (T), I do not know of any other new terms that should be defined.
>> 
>Not sure the SNMPCONF talks much about Policy Management Information
>Base unless you mean the Policy Module that controls the behavior of the
>managed system. We have Implementation, Mechanism, and Instance specific
>MIB Modules. All of which could contain 'policy' data.
>
>If a policy Management Application is tied to SNMP, a PDP and PEP and
>COPs are all also specific technology terms and should not be
>referenced. Either we equally reference both or we should purge
>technology specifics. I do not feel strongly one way or the other.
>
>> 
>> > Directory Enabled Networks (DEN)
>> 
>> My issue is not the inclusion or definition. I would like for us to have
>> generic terms that are not dependent on the DMTF as well. For example 
>> what shall we call the general data model that is not LDAP specific?
>> 
>> <arw>
>> There can only be an "information model" that is not
>> protocol/repository-specific - which we describe in PCIM.  There 
>> cannot be a "data model" one.  By definition, "data models" are 
>> repository/protocol specific.  The reason that DEN is mentioned is 
>> that it was designed to use a directory as a policy repository.  
>> It is directly tied to policy.
>> </arw>
>> 
>I would feel much more comfortable with the effort if we could include
>an example that used a database model as well. 
>
>> Since this is an IETF document, I think we should not only reference 
>> the work that the document is based on, but the technology over 
>> which we have change control and will use, perhaps in addition 
>> to other technologies.
>> 
>> <arw>
>> Agreed.  However, there is also no reason to slight other relevant 
>> work since our customers hear these terms and could be confused.
>> </arw>
>> 
>good then we can include some words about databases as well.
...
>> 
>> > Policy Information Base (PIB)
>> 
>> Same comment as before. No issue with definition, we just need to add the
>> SNMP counterparts.
>> 
>> <arw>
>> Policy MIB is added as documented above.
>> </arw>
>
>Please see my comments above.
...
>> 
>I have not issue with these except to the extent that people think they
>are only realized in LDAP implementations. LDAP can be used to store
>policy data as well as relational and other technologies.