Subject: Policy Framework Documents

From: [email-masked]
Date: Tue, 24 Nov 1998 15:51:49 -0500

The following is being forwarded to the policy mailing list.
Message originally sent by Ed Ellesson <[email-masked]>
---------------------------------------------------------------------------

Greetings, Policy Enthusiasists:

Two new drafts are now posted to the IETF Internet Drafts Repository, which
we plan to discuss at our meeting in Orlando (15:45 - 18:00 on Tuesday,
Dec. 8):  

1. Policy Framework Core Information Model,
draft-ietf-policy-core-schema-00.txt

    http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-00.txt

2. Policy Framework Definition Language,
draft-ietf-policy-framework-pfdl-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-policy-framework-pfdl-00.txt

Both of these documents are working group drafts, and, as such, will be
changed and will be added to, as a result of consensus reached in this
working group.  It is expected that multiple contributors will be involved
in authoring both documents, and these contributions will be recognized in
the drafts, as they continue through the consensus building and editing
process.   

With regard to the first document, the Policy Framework Core Information
Model,  we would like to take this opportunity to recognize the significant
contributions of the authors of the QOS Schema draft
(draft-rajan-policy-qosschema-00.txt) and the IPSEC Schema draft (
draft-ietf-ipsec-policy-ldapschema-00.txt), both of which are referenced in
the draft, and from which much of the core policy schema draft content was
drawn.  

The core policy schema draft also reflects work of the DMTF Service Level
Agreement Working Group, the DMTF Networks Working Group, as well as work
of the DEN Ad Hoc Committee.  

Please comment on this mailing list, so that we have the issues clearly
identified that we need to discuss in Orlando.  

Thanks, 

Ed Ellesson and John Strassner, Co-Chairs
Policy Framework Working Group

Regards, 

Ed Ellesson
Sr. Engineer, TCP/IP Technology Management
IBM Networking Software Products
Research Triangle Park, NC 
[email-masked]
919-254-4115

---

From: [email-masked]
Date: Sat, 28 Nov 1998 18:22:38 -0500

The following is being forwarded to the policy mailing list.
Message originally sent by "David L. Black" <[email-masked]>
---------------------------------------------------------------------------

A couple of high level comments from an initial read:

(1) Condition ordering.  There seems to be an underlying
assumption that condition evaluation is a sequential process
(i.e., some computation engine chews through each policy
rule evaluating one condition at a time).  If one
considers QoS policies based on things like source and
destination IP addresses, port number, etc., one possible
implementation is a hardware classifier that is able to
evaluate the header field match conditions from all of
the policy rules in parallel in order to classify the inbound
traffic into the categories that receive different treatment
(policy actions).  IMHO, the current wording on ordering in
the schema (and to a lesser extent, the framework) is too strong,
and could cause unnecessary complications for such devices.
Under the assumption that policy condition evaluation has no
side effects (something that should be true to avoid misuse
of the policy language), the order of condition evaluation
does not affect the final result, but rather is a hint about
how to get there with the least amount of work.  Hence, I'd
like to see everything ordering discussed in terms of hints
or pragmas that an implementation is free to ignore if it knows
better (e.g., early C compilers paid strict attention to
"register" declarations, but later ones with good register usage
optimizers tended to ignore them).

(2) Roles.  While the concept that roles are intended to address
is important, I am concerned that the usage of this term does not
seem to match usage in the security community.  In that arena,
specifically authorization, a role is usually a subject (user/person)
attribute rather than an object (e.g., piece of equipment) attribute
as used here.  In the context that I have seen the term used, "role"
is roughly synonymous with "Dynamic Group specified by characterization"
although the notion of role is often restricted to a single attribute
characterization.  Can you pick a different term, such as Target Group?

--David

---

From: [email-masked]
Date: Mon, 30 Nov 1998 09:20:54 -0500

The following is being forwarded to the policy mailing list.
Message originally sent by "Chris Martin" <[email-masked]>
---------------------------------------------------------------------------

Policy List:

Initial comments on draft-ietf-policy-framework-pfdl-00.txt

Section: BNF of the PFDL

I'm starting from the back, working forward;-) I realize that section 4 and 5 of
the document "will be finalized shortly", so some of these comments may be
covered within these sections.  I hope to have more comments shortly....

1. There are a number of productions that are not defined, including the
following list:

<role_identifier>
<user_name>
<user_group_name>
<organizational_unit_name>
<organization_name>
<application_name>
<application_port_number>
<device_name>
<address_spec>
<protocol_name>
<protocol_number>
<protocol_options>
<ingress_DSV>
<ingress_ToS_byte_value>
<ingress_802.1_value>
<ingress_ATM_QoS>
<ingress_FR_QoS>
<SLA_name_options>
<relative_time_category_value>
<valid_time_period>
<time_period_mask>
<permit_deny_category>
<remark_spec>
<service_policy>

Some of these, like the 'name' productions, may be easily defined:

<role_identifier> ::= <octet_string>
<user_name> ::= <octet_string>

etc.  But most of the others aren't obvious to me.

2. Similar to 1, some of the productions need more semantic detail.  For
example, <Table Definition>.

3. <rel_op> should be <relational_operator>

4. In  the grammar, terminal symbols should be represented in a consistent way.
Most of them are represented as an uppercase string in single quotes, like
'IF'.  With this convention, change the ..._CATEGORY_REFERENCE to
'..._CATEGORY_REFERENCE' and <Table Definition> to <TABLE DEFINITION>.

5. I can't tell what SLA_VALUE is supposed to be from the draft text.

6. I have concerns about how the <policy_action_category> is defined. As
defined, details of the PFDL will be burdened by future policy additions.  For
instance, 'REMARK PACKET' is a diff-serv specific category.  Will it be
necessary to add a 'AUTHENTICATE' category, etc?  I would suggest moving the
'REMARK PACKET' to an element of the <service policy>, which would be a
diff-serv specific service policy.  This may be true also for Table Definition?
A similar case may hold for <traffic_category_value>, which (in the future?) may
want to categorize RSVP requests based on received POLICY_DATA fields.

7. For implementation convenience, I guess there is motivation to keep this a
simple (LALR(1), I believe) grammar?

chm

---

From: [email-masked]
Date: Mon, 30 Nov 1998 09:07:55 -0500

The following is being forwarded to the policy mailing list.
Message originally sent by Michael Richardson <[email-masked]>
---------------------------------------------------------------------------

>>>>> "policy" == policy  <[email-masked]> writes:
    policy> (1) Condition ordering.  There seems to be an underlying
    policy> assumption that condition evaluation is a sequential process
    policy> (i.e., some computation engine chews through each policy rule
    policy> evaluating one condition at a time).  If one considers QoS
    policy> policies based on things like source and destination IP
    policy> addresses, port number, etc., one possible implementation is a
    policy> hardware classifier that is able to evaluate the header field
    policy> match conditions from all of the policy rules in parallel in
    policy> order to classify the inbound traffic into the categories that
    policy> receive different treatment (policy actions).  IMHO, the current
    policy> wording on ordering in the schema (and to a lesser extent, the
    policy> framework) is too strong, and could cause unnecessary
    policy> complications for such devices.  Under the assumption that policy
    policy> condition evaluation has no side effects (something that should
    policy> be true to avoid misuse of the policy language), the order of
    policy> condition evaluation does not affect the final result, but rather
    policy> is a hint about how to get there with the least amount of work.

  Just to make it clear that this isn't a non-issue, we build hardware
that does exactly this, and does it in parallel, at wire speed, *before* DMA
starts. Our language is defined draft-nossik-pax-pdl-00.txt, and is
completely declarative in nature. As such, actions are currently not defined
within the language.

  I am still trying to understand how much of the PFDL lives in the PDP
and how much must be translated into something the PEP must understand.

    policy> Hence, I'd like to see everything ordering discussed in terms of
    policy> hints or pragmas that an implementation is free to ignore if it
    policy> knows better (e.g., early C compilers paid strict attention to
    policy> "register" declarations, but later ones with good register usage
    policy> optimizers tended to ignore them).

  Better yet: just make it declarative rather than proceedure. NetBoost
people have expressed the same issue to me after the Policy BOF.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="mailto:[email-masked]">[email-masked]</A>.

---

From: [email-masked]
Date: Mon, 30 Nov 1998 17:11:42 -0500

Policy List:

More comments on draft-ietf-policy-framework-pfdl-00.txt

1. Concerning the following in the Abstract:

"The PFDL is the common 'currency' that is exchanged between these heterogeneous
components to enable them all to perform their function in providing, securing,
distributing, and administering policy. The PFDL becomes the way to ensure that
multiple vendors interpret the policy the same way while enabling vendors to
provide value-added services."

I understand that the charter specifically excludes (new?) protocol definition,
but shouldn't the policy framework provide a hint as to how the above will be
accomplished?  As part of the framework, I'd like to see what PFDL distribution
methods are applicable, to allow vendor-independent application of policy.  From
what I see, it isn't accessed via LDAP or COPS, and isn't even directory server
related.  The distribution method may be as a text file (access via ftp) or
encoded somehow (as PFDL tokens?) between policy servers.  Some description in
the framework text would be helpful.

2. References

There seems to be overlap between the Policy Framework Definition Language and
the Policy Framework Core Information Model, but neither document references the
other.   Does the PFDL depend on the Policy Framework Core Information Model?

3. Groups

Section 3.4.2 defines groups.  I find the wording of "A Dynamic Group is only
used as a value part of a condition of a policy." confusing. I would suggest the
similar alternative: "The value part of a condition of a policy defines the
characteristics of a Dynamic Group."

Also, I don't see how the dynamic group example (LucasEngineers) can be
represented in the PFDL.  Specifically, the condition I refer to is:

"...A group, LucasEngineers, might be characterized as follows:

  Group over <user_category> named LucasEngineers:
     Job Title = "engineer",
     Supervisor = "Luca".

Then, a condition might be written as follows:

        <user_category> IN LucasEngineers
..."

Is the <user_category_value> part (LucasEngineers) in this case the DN of a
(well-known?) <user_group_name>?

4. Relationship to other work

Is this PFDL intended in any way to support related functionality found in the
DEN initiative?  Specifically, as the name implies, the DEN "specification"
extends CIM classes and attributes that can be used to model a directory enabled
network.  I think I may have answered myself in #1 above.

chm