Subject: time period syntax: draft-ietf-policy-core-info-model-03.txt

From: John Schnizlein <[email-masked]>
Date: Mon, 31 Jan 2000 17:10:51 -0500

Agreement, as requested, prior to argument regarding time period:

At , John Strassner wrote:
>At 08:42 AM 1/28/00 -0500, John Schnizlein wrote:

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

Yes.

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

Yes.

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

The bit-mask concept in the PCIM (sections 6.5.2, 6.5.3, 6.5.4, 6.5.5)
seems like the bit-mask in RFC 2591, but that RFC contains nothing like
the time period (section 6.5.1), which is defined in RFC 2445.

Excerpts from these three documents (following) suggest that the general
application-level exchange format of RFC 2445 might suit generic policy
syntax better than the particular MIB item settings of RFC 2591.
The bit-mask concept is valuable, but does not interfere with using the
aleady existing (standards track) syntax for period of time.

draft-ietf-policy-core-info-model-03.txt
 6.5.1. The Property "TimePeriod"

   This property identifies an overall range of calendar dates and times
   over which a policy rule is valid.  It is formatted as a string
   consisting of a start date and time, then a colon (':'), and followed
   by an end date and time.  The first date indicates the beginning of
   the range, while the second date indicates the end.  Thus, the second
   date and time must be later than the first.  Dates are expressed as
   substrings of the form "yyyymmddhhmmss".  For example:
     19990101080000:19990131120000
         January 1, 1999, 0800 through January 31, 1999, noon

RFC 2445:
   The iCalendar format is suitable as an exchange format between
   applications or systems. The format is defined in terms of a MIME
   content type. This will enable the object to be exchanged using
   several transports, including but not limited to SMTP, HTTP, ...

4.3.4 Date
   Example: The following represents July 14, 1997:
     19970714
4.3.5 Date-Time
   For example, the following represents January 19, 1998, at 0700 UTC:
     DTSTART:19980119T070000Z
4.3.9 Period of Time
   Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
   ending at 07:00:00 UTC on January 2, 1997 would be:
     19970101T180000Z/19970102T070000Z

RFC 2591
   The MIB defined in this memo provides scheduling of actions
   periodically or at specified dates and times. The actions can be used
   to realize on-duty / off-duty schedules or to trigger management
   functions in a distributed management application.

   Schedules can be enabled or disabled by modifying a control object.
   This allows pre-configured schedules which are activated or de-
   activated by some other management functions.

5.  Usage Examples
5.2.  Starting a script at the next Friday the 13th

   It is assumed that the schedule entry is owned by schedOwner = "joe"
   and its name is schedName = "13th". The instance identifier for the
   scheduling entry is therefore 3.106.111.101.4.49.51.116.104.

   It is further assumed that the smLaunchTable entry is owned by
   smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The
   complete object identifier for the smLaunchStart object is therefore
   smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives
   in the context identified by the string "engine1".

   The configuration of the scheduler entry which launches the script on
   every Friday 13th at midnight would look as follows:

      schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday }
      schedMonth.3.106.111.101.4.49.51.116.104 = {
            january, february, march, april, may, june,
            july, august, september, october, november, december
      }
      schedDay.3.106.111.101.4.49.51.116.104 = { d13 }
      schedHour.3.106.111.101.4.49.51.116.104 = { h0 }
      schedMinute.3.106.111.101.4.49.51.116.104 = { m0 }

      schedValue.3.106.111.101.4.49.51.116.104 = 0
      schedContextName.3.106.111.101.4.49.51.116.104 = "engine1"
      schedVariable.3.106.111.101.4.49.51.116.104 =
        smLaunchStart.3.106.111.101.5.103.104.111.115.116

      schedType.3.106.111.101.4.49.51.116.104 = oneshot(3)
      schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2)
      schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3)
      schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1)

   All the remaining columns in the schedTable represent status
   information and are not shown here.

---

From: John Strassner <[email-masked]>
Date: Mon Jan 31 19:26:34 GMT 2000

Comments inline. Sorry about the weird email address, please reply to
[email-masked].

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:

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

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.

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

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.

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

_________________________________________________________
fsmail - get your free web-based email at: www.fsmail.net