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

From: Jon Saperia <[email-masked]>
Date: Mon, 28 Aug 2000 10:24:29 -0400

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

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
are:

  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:

    draft-ietf-snmpconf-diffpolicy-02.txt
    draft-ietf-snmpconf-bcp-02.txt

Additional background information is found in:

    draft-saperia-policysnmp-00.txt

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

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

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.

Page 9

> Policy Information Base (PIB)

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

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.

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.

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

/jon

---

From: John Schnizlein <[email-masked]>
Date: Thu, 31 Aug 2000 09:53:48 -0400

At 10:24 AM 08/28/2000 -0400, Jon Saperia wrote:
>... 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.

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.

My dictionary (American Heritage) defines provisioning as supplying
with provisions, and a provision as that which is supplied.
It defines configuration as the arrangement of the parts or elements
of something. This distinction does not reflect 'set at the factory'.

John 

At 11:24 PM 10/27/1999 +0000, Bert Wijnen wrote:
>There will be two BOFs that may be of interest to readers of this
>mailing list.
>
>   Configuration Management Bof
>   Policy Terminology BOF
>

---

From: Jon Saperia <[email-masked]>
Date: Thu, 31 Aug 2000 10:09:03 -0400

> called Configuration Management with SNMP (snmpconf).

Yes, thank you I am aware of that.
> in the "telco industry" you cite.

The reason I suggested it is that as we are all aware, the IETF has not
published much yet in this area. I have learned that the telco folks have a
lot to contribute to this discussion - though I am not a telco person. The
IETF does from time to time use terms and definitions from other
organizations (CIM comes to mind). I believe the distinction is a useful
one.

/jon