[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf Comments on the draft-ietf-policy-terminology-00.txt document
Here are some comments on the recent draft. Sorry for the cross posting. I
know that some on the SNMPCONF WG list are not on the policy list.
On Page 3:
> - "M" identifies various mechanisms to create or convey policy-
> related information in a network. For example, COPS and an
> "Information Model" are two mechanisms for communicating and
> describing policy-related data.
Perhaps we need another term. Mechanism has come to be used in the context
of a technology used to realize a particular policy in a policy domain. An
example would be RED or WRED in DiffServ of BGP Policy in the Routing Policy
In addition, there are several places in the document (see also page 7) that
would benefit from a clearer expansion of the terms that are currently in
use in terms of levels of abstraction. At present 4 levels of abstraction
have been defined and are now in common use in the SNMPCONF documents. They
1. Domain Specific.
2. Mechanism Specific
3. Implementation Specific
4. Instance Specific
Rather than quote the entirety of these terms, here are the reference IDs:
Additional background information is found in:
I believe that community will be well served by a common set of terms as
they relate to these levels of abstraction.
On Page 4
> Common Open Policy System (COPS)
I have no issue with the inclusion of this specific mechanism and components
of its architecture such as PDPs and PEPs. To the extent that we choose to
define such technologies in this document, we should also define the
SNMP-based ones as well and it based documents - those references are pretty
well known. With regard to SNMPCONF specific items this document should
also include items such as:
Policy MIB Module
Mechanism and Implementation Specific MIB Modules
Policy Management Application
(see above references)
Also on Page 4
I found this paragraph a bit confusing. The telco industry uses
configuration to refer to parameters that 'are set at the factory' and are
not generally changeable by the customer. Provisioning refers to those
parameters that are customer changeable.
I think there is a useful concept in the paragraph which points to user or
provisioning system(s) setting of object values versus those that are
dynamic or run time. The best example I can give is in the routing are where
a set of BGP or OSPF configuration values are set by the user, but the
routing information is continuously changing while the system is running.
On Page 5.
> 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? 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.
On pages 7, 9, 11 and 12:
Terms such as policy condition, policy action, policy rule, role and role
combination. I assume this document will be revised to reflect discussions
that came out of the IETF meeting to resolve term conflicts that Andrea and
Steve Waldbusser and others have had. I have not seen documentation of these
discussions and look forward to those clarifications.
> Policy Information Base (PIB)
Same comment as before. No issue with definition, we just need to add the
> policy server
I do have an issue with this definition. It states:
> (P) A marketing term whose definition is imprecise. Originally,
> [R2753] referenced a "policy server." As the RFC evolved, this
> term became more precise and known as the Policy Decision Point
> (PDP). Today, the term is used in marketing and other
> literature to refer specifically to a PDP, or for any entity
> that uses/services policy.
In the SNMPCONF work we have been using policy application for some time
since PDP and PEP have a very specific and sometimes different set of
behaviors than SNMP.
Also on Page 10.
I feel this should be a generic term since many people will store the
information cited in systems and formats not common to PCIM or CIM.
These comments aside. The document is a good start and will be quite