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

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

Jon, I realized that I never replied to this list of comments.  As the
polterm editors are about to rev the draft for the next meeting, it would be
good to close on some of these issues.

Replies are inline.

-----Original Message-----
From: policy-owner@raleigh.ibm.com
[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Jon Saperia
Sent: Monday, August 28, 2000 7:24 AM
To: policy@raleigh.ibm.com; snmpconf
Subject: 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

This use of "mechanism" really seems more of a convention than a definition.
However, for clarity, an alternative might be "(T) Technique".

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

Although these abstractions may work within the context of SNMPConf, they do
not translate to the extended scope of general policy - moving from SLAs
down to specific device abstractions. In previous versions of the
terminology and policy framework documents, the number of levels of
abstraction was debated at length.  The decision was that you could not say
that there were only 3, 4 or 6 levels - since a particular implementation
may require more or less.  (SNMPConf does indeed assume a specific context
and implementation.)  Your terms certainly fit within the definition of
"abstraction", and could be referenced as examples.  Here is some new text:
$ policy abstraction
   (P) 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
   [for example, DiffPolicy].  However, these do not necessarily
   correspond to distinct processing entities or the complete set
   of levels in all environments.  (See also "configuration" and
   "policy translation.")

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)

What new terms are you defining?  I agree that we should add another
"(T)technique" that says that policy can be defined via MIBs and reference
the SNMPConf work.  Here is the new text...
$ 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.

As regards, a "policy management application" - this does not appear to be a
"term" in any of the SNMPConf documents, but is discussed in
draft-saperia-policysnmp-00.txt.  In the latter, it is tied strictly to SNMP
and RFC2571.  This does not seem to be a general/generic term or even
require definition since there does not seem to be any ambiguity related to
it. IMHO, I believe that ultimately all "management applications" will deal
with policy in one form or another, whether they are SNMP-based or not.

Also on Page 4

> configuration

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.

The position articulated by John Schnizlein seems very relevant here:
> The Internet industry seems to use "configuration" to mean
> changable parameters, as in the Dynamic Host Configuration Protocol
> [RFC 2131]. The BOF announced with Policy Terminology was called
> Configuration Management (excerpt below). The WG you co-chair is
> called Configuration Management with SNMP (snmpconf).
> My impression is that there is a rough consensus that we would be
> better served using this word as in the Internet context rather than
> in the "telco industry" you cite.
However, this is not meant to slight the telco industry.  So, we can add an
alternate definition and clarify that it is not the "Internet industry"s
usage.  We have done this in other parts of the document.

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?

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.

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.

Agreed.  However, there is also no reason to slight other relevant work
since our customers hear these terms and could be confused.

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.

We did resolve the definitions of Role and Role Combination.  No other
terminology issues were raised.  Here are the new definitions for roles ...
$ role
   An administratively specified characteristic of a managed
   element (for example, an interface). It is a selector for
   policy rules, to determine the applicability of the rule
   to a particular managed element. [SNMPCONF, PCIM, PIB]
$ role combination
   (P) An unordered set of roles that characterize managed
   elements and indicate the applicability of policy rules.
   A policy system uses the set of roles reported by the managed
   element to determine the correct policy rules to be sent for
   enforcement.  That determination may examine all applicable
   policy rules identified by the role combination, its sub-
   combinations and the individual roles in the combination
   [PCIM], or may require that rules explicitly match the role
   combination specified for the managed element [PIB].  The
   final set of rules for enforcement are defined by the
   policy system, as appropriate for the specified role
   combination of the managed element.

Page 9

> Policy Information Base (PIB)

Same comment as before. No issue with definition, we just need to add the
SNMP counterparts.

Policy MIB is added as documented above.

Page 10

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

The goal of the definition was not to establish "policy server" as a real
term, but to say that it is an "imprecise"/"marketing" term. The whole goal
of "policy server" was to give the history of the term, which has caused
confusion in the past. Since SNMPConf's documents do not reference this
term, there is no ambiguity.  Also, you are justified in not using the term,
since it is "imprecise." BTW, I am very reluctant to add "policy
application" as a formal term - since it is just a "policy" adjective in
front of a general term.  Even SNMPConf's I-Ds do not formally define it.

Also on Page 10.

> PolicyRepository

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.

We actually have the generic and specific terms defined in the document.
Here is the generic ...
$ policy repository
   (P) "Policy repository" can be defined from three perspectives:
   - A specific data store that holds policy rules, their
     conditions and actions, and related policy data.  A directory
     would be an example of such a store.
   - A logical container representing the administrative scope and
     naming of policy rules, their conditions and actions, and
     related policy data. A QoS policy domain would be an example
     of such a container. [QoSModel]
   - In [PCIM], a more restrictive definition than the prior one
     exists. PolicyRepository is a model abstraction representing an
     administratively defined, logical container for reusable policy
     conditions and policy actions.

These comments aside. The document is a good start and will be quite

<arw> Thanks. </arw>