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

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

Andrea Westerinen wrote:
> 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.

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

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

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.

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

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

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

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.

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

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

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