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

From: "Andrea Westerinen" <[email-masked]>
Date: Sun, 19 Nov 2000 18:09:01 -0800

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jon Saperia
Sent: Monday, August 28, 2000 7:24 AM
To: [email-masked]; 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
domain.

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

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

<arw>
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.")
<\arw>

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)

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

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.

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

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?

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

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>

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.

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

Page 9

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

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.

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

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.

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

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

<arw> Thanks. </arw>

/jon

---

From: Jon Saperia <[email-masked]>
Date: Mon, 20 Nov 2000 15:14:44 -0500

> good to close on some of these issues.

Thanks for the reply. In the interest of brevity. I have cut out some of
the extraneous material.

> However, for clarity, an alternative might be "(T) Technique".

I am happy with technique. It does sound like COPS or SNMP are both
being used as transport and data definition tools. I understand in an
absolute sense that the protocol(s) for transport and the languages for
data definition, are not really the concern of policy. To the extent
that they are used to transport and define that information, it might be
helpful to identify terms that reference the functions of policy
transport and data definition.

>    of levels in all environments.  (See also "configuration" and

This is a good start. You should reference the current documents on the
web site. The terms are in the documents cited below.

> the SNMPConf work.  Here is the new text...

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. 

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

> with policy in one form or another, whether they are SNMP-based or not.
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.

> usage.  We have done this in other parts of the document.
Fine.
> directory as a policy repository.  It is directly tied to policy.
I would feel much more comfortable with the effort if we could include
an example that used a database model as well. 

> since our customers hear these terms and could be confused.
good then we can include some words about databases as well.
> Policy MIB is added as documented above.

Please see my comments above.
>      conditions and policy actions.
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.

Thanks
/jon

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 20 Nov 2000 14:09:06 -0800 (PST)

> would be the comparable items in a Policy-enabled SNMP environment. 
 
Jon,

I think you have it round the wrong way.  The PDP and PEP terminology
was coined by the RAP WG for the purpose of describing "A Framework for
Policy-based Admission Control" (RFC 2753), which is specified
independently of the COPS-protocol.

Keith.

---

From: John Schnizlein <[email-masked]>
Date: Mon, 20 Nov 2000 16:50:33 -0500

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:
>>..
>> 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>
>> 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>
>> 
>> 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>
>> 
...
>Please see my comments above.
...

---

From: Jon Saperia <[email-masked]>
Date: Tue, 21 Nov 2000 05:01:45 -0500

Thanks for all the comments. I look forward to the next draft.

/jon