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

From: "John C. Strassner" <[email-masked]>
Date: Sun, 30 Jan 2000 23:21:59 -0800

Comments inline.

regards,
John

At 08:42 AM 1/28/00 -0500, John Schnizlein wrote:
>At 03:58 PM 01/20/2000 -0500, [email-masked] wrote:
> >
> >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.
>
>One problem is that this draft references an expired draft:
>draft-strassner-policy-terms-02.txt according to an IETF.org query.

<jcs> That's a goof, we'll remove it. </jcs>

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

<jcs>
Please see my response to Ken and Walter. Since the state machine analogy 
caused confusion, I removed it in the proposed text.

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

<jcs>
I don't think it should. That terminology was negotiated specifically for 
DiffServ, and will undoubtedly be modified for IPSP and other groups that 
want to use the PFCIM. The PFCIM is, after all, supposed to be general and 
not tied directly to DiffServ.

So what I think is needed here is to keep these general definitions and 
then show how they can be related to the more specific usage by DiffServ 
and other groups.

Specifically, this document does not use the term SLS, it instead uses the 
term SLO. So the only conflict is between the definition of SLA. In 
DiffServ, SLA is defined as "...service contract... that specifies the 
forwarding service a customer should receive". The only difference is that 
this definition of SLA says "...usually be written in high-level business 
terminology." This does not conflict with the DiffServ definition. Thus, 
all we need to do is to reference the DiffServ definition and tie it into 
the above.
</jcs>

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

<jcs>
This is a valid concern, but one that is not applicable to the PFCIM. This 
is because the purpose of the PFCIM is to define a general framework of 
classes that can be used to generically express the structure of a policy 
rule. The translation into specific device configurations is not the goal 
of the PFCIM, nor can it be expressed in the PFCIM, since this is by 
definition specific to a particular type of domain (e.g., DiffServ vs. 
DHCP). This is instead the goal of other drafts (e.g., the QoS drafts). 
Therefore, this concern should be addressed when (for example) the QoS 
drafts go to Last Call. In fact, it should be addressed any time the PFCIM 
is used in conjunction with other drafts to express policy for a particular 
domain.
</jcs>

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

<jcs>
The "if <condition> then <action> form of rules has been accepted now for 
over a year, and it troubles me that we now seek a need to rethink this. 
That being said, what is important in the PFCIM is the set of building 
blocks, in the form of classes, attributes and relationships, that can be 
used to define the structure of a policy. Steve's examples can be 
represented by the constructs defined by the PFCIM. So perhaps what is 
called for is NOT to rewrite the PFCIM in terms of Steve's or another 
person's alternative representation, but rather to show how different 
representations are equivalent. This way everyone wins.
</jcs>

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

<jcs>
I respectfully submit that this statement is being taken out of context. 
Earlier, the text says:

   It is important to understand that the difference between a rule-
   specific condition or action and a reusable one is based on the intent
   of the policy administrator for the condition or action, rather than
   on the current associations in which the condition or action
   participates.

The statement that you are referencing was intended to underscore the fact 
that a condition or action that is initially defined as reusable may be 
turned into a rule-specific condition or action, and vice-versa. The 
difference is not one of functionality, but how the rule is stored. This is 
why text was devoted to explaining this and other differences in using 
rule-specific vs. reusable conditions and actions.

So as a compromise, how about adding text to the problem statement 
identified above that states this? Would your concern be satisfied by doing 
this?
</jcs>

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

<jcs>
Roles can be associated with either, and the PFCIM is designed to handle 
either. I'm sorry, but I'm missing your point here.
</jcs>

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

<jcs>
Please see my earlier note in reply to Walter and Ken. Roles should not be 
viewed as "just attributes", but rather as a selector. Therefore, their 
purpose is not to hide or abstract anything. Rather, their purpose is to 
select a subset of applicable policies from a larger set of available 
policies. So in this sense, it very much facilitates 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?

<jcs>
I can only assume that you are referring to Figure 4, which everyone has 
agreed to already. However, we could insert words emphasizing that this is 
an example only, and is not meant as a standard architecture. Would that 
satisfy your concerns?
</jcs>

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

<jcs>
Granted, we rushed ahead on the role term. But what other terms does this 
document define that are controversial?

We did have agreement on the policy use cases; the cry was for more, and to 
separate the requirements from the use cases. No requirements were set 
against the PFCIM (I'm not sure how any specific requirements COULD be set 
against it, except to try to ensure its generality). So I'm not sure that 
we violated anything here...

Furthermore, it is the opinion of the co-chairs that we need to progress 
the core information model in order to put a stake in the ground. Having no 
stakes in any ground has been one of the reasons that has made it hard to 
nail things down. So I think that progressing this document is a Good Thing.
</jcs>

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

<jcs>
I honestly don't know how to respond to a rhetorical question like this. 
CIM represents a general object-oriented information model, and many people 
from many different standards bodies have spent a lot of time working on 
it. There are deployed systems using it.

If you look at the CIM models, you will see that CIM attributes reference 
IETF MIB variables when appropriate. It has a special qualifier that is 
used explicitly for this. CIM is not trying to provide an alternative 
standard, set of syntaxes, or any other "nefarious" contrivance. It is 
simply trying to describe a managed domain in an object-oriented way. When 
appropriate, it will reuse IETF and possibly other standard information to 
achieve this goal.

With respect to your question about 2445, this document uses RFC 2591 as a 
way to represent some of its data. We thought that that RFC was well suited 
to expressing what we wanted.

Finally, imho, the only way to develop mutual support of policy 
configuration efforts across different areas of the IETF is to put a stake 
in the ground and encourage people to use it. The PFWG has been trying to 
do this for over a year, and imho it's a little late to question the 
foundation of the class design after we've been working for over a year on it.
</jcs>

>John