Subject: WG Last Call: draft-ietf-policy-core-info-model-03.txt

From: [email-masked]
Date: Thu, 20 Jan 2000 12:58:04 -0500

PURPOSE:

The purpose of this message is to initiate the Policy Framework WG
last call on the "Policy Framework Core Information Model --
Version 1 Specification" document:

 draft-ietf-policy-core-info-model-03.txt

LAST CALL:

Unless there are strong objections, we would like to consider
this draft of the document to be the final one, before moving it
forward for proposed standard status.  Please send any such
objections, as well as statements of support, to the mailing list,
during the last call period.

SCHEDULE:

The last call starts today (Thursday, January 20, 2000) and
will last approximately two weeks. It will end on
Thursday, February 03, 2000.

Thank you,

John Strassner and Ed Ellesson, your humble co-chairs

---

From: John Schnizlein <[email-masked]>
Date: Fri, 28 Jan 2000 08:42:25 -0500

At 03:58 PM 01/20/2000 -0500, [email-masked] wrote:
>forward for proposed standard status.

One problem is that this draft references an expired draft:
draft-strassner-policy-terms-02.txt according to an IETF.org query.

Page 4:
   One way to think of a policy-controlled network is to first model the
   network as a state machine and then use policy to control which state
   a policy-controlled device should be in or is allowed to be in at any
   given time.  Given this approach, policy is applied using a set of
   policy rules. 
The state-machine model was repudiated when questions were asked
as to how the information model relates to the state transition 
table. What is the relationship between the "policy rules" and
the states and transitions of a state machine?

Pages 6 & 7:
   Policies represent business goals and objectives.  A translation must
   be made between these goals and objectives and their realization in
   the network. An example of this could be a Service Level Agreement
   (SLA), and its objectives and metrics (Service Level Objectives, or
   SLOs), that are used to specify services that the network will provide
   for a given client [8].  The SLA will usually be written in high-level
   business terminology. SLOs address more specific metrics in support of
   the SLA. These high-level descriptions of network services and metrics
   must be translated into lower-level, but also vendor- and device-
   independent specifications. The Policy Core Information Model classes
   are intended to serve as the foundation for these vendor- and device-
   independent specifications.
This terminology does not reflect the distinction between SLA
and SLS negotiated in the diffserv WG draft-ietf-diffserv-new-terms-01.txt.
More significantly, it is still not clear how policy specifications are
translated into device configuration specifications or how the nature of
the network devices or their interconnection interacts with policy in this
translation.

While the distinction between procedural and declarative forms are explored,
compelling justification is not given for the "if (condition) then <action>"
form of rules. Might we be better served by extending the style of rule
already used in Steven Bellovin's Distributed Firewalls paper?
http://www.research.att.com/%7Esmb/papers/distfw.html
Rules like this might ease coordination with the Security Policy WG.
Instead of either procudural or declarative program statements, a form more
analogous to "invariant" statements would reflect the situation that the
policy is intended to maintain. The tradition of invariant statements in
program verification suggests that this form might help with the difficult
task of verifying that a set of rules specifies what is intended.

Page 13:
Why is over a page devoted to the distinction between "rule specific" 
and "reusable" policy conditions and actions despite the assertion that
  "There is no inherent difference between a rule-specific condition or
   action and a reusable one. "

Page 15: Roles
   The concept of role is central to the design of the entire Policy
   Framework. 
But, as was pointed out in the Policy Terms BOF in Washington, roles
are associated with principals rather than with resources in much of
the security policy discussion.

The isolation (indirect reference) of "roles" as arbitrary strings
associated with resources (interfaces in many discussions) is presented
as a virtue. But it seems that hiding the particular abilities of policy
enforcement points makes it harder to determine if policy is in effect.
Does this "role" really facilitate building a policy system?

An architectural diagram diagram is included in this draft proposed for
standards track despite the controversy that has delayed progress on a
framework document. Would passing "last call" on this document imply
approval of the archicture we have not agreed on in the framework?
As a related question, what happened to the apparent consensus of the
room that we should agree on terms, policy use cases, and requirements
before progressing a model that supposedly addresses them?

Pages 20 - 59: CIM Data Types
No justification is provided for the host of decisions made in CIM, and
reflected in the detailed specification of its classes and attributes.
In particular, why is a different representation of time periods used
than in (standards track) RFC 2445?
This begs the question if (which of) the attribute syntaxes correspond
to syntax already specified as standard in the IETF.

This line of questions leads to the more general concern that a lot of
detailed specification is proposed for IETF standards track on little
more than the indication that the CIM group of the DMTF developed it.
It is still not clear if this facilitates or hinders mutual support
policy configuration efforts across areas of IETF interest.

John