Subject: [midcom] Fwd: concern over the use of terms in the midcom framework document

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Feb 2002 09:23:34 -0500

By way of an update:

1) I've heard informally that the requirements document has been
   approved by the IESG
2) I've appended IESG feedback on the framework document - there
   are some concerns about terminology.  As you'll recall we originally
   had some difficulty coming to agreement on items 2, 3, and 4, but I 
   don't think that the recommended changes are out of keeping with the 
   spirit of the decisions we finally arrived at.

Melinda

>I reviewed the MIDCOM document and have the following concerns:
>(Luckily the draft uses the terms consistently - perhaps wholesale
>find/replace operations can be performed.)
>
>1.  Policy Server - Mentioned at the end of the Intro (Section 1), defined
>in Section 2.9 and further discussed throughout the document.  The MIDCOM
>draft defines a Policy Server as "a management entity that acts in advisory
>capacity and interfaces with a middlebox to communicate policies concerning
>authorization of MIDCOM agents gaining access to middlebox resources. ...
>the middlebox will consult the Policy Server and obtain the agent profile to
>validate session setup and authorization of the agent ..."
>
>The policy terminology RFC defines a Policy Server as "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."
>
>I would recommend changing the MIDCOM terminology - a MIDCOM "policy server"
>is primarily a Policy Decision Point and also acts as a policy repository,
>holding MIDCOM related policy information/profiles/etc in order to make the
>authorization decisions.  Specifically from the terminology RFC, a PDP is
>defined as "a logical entity that makes policy decisions for itself or for
>other network elements that request such decisions"; and a policy repository
>is "a specific data store that holds policy rules, their conditions and
>actions, and related policy data".
>
>
>2. Filter spec - Defined in Section 2.13 and used in subsequent sections of
>the document.  The MIDCOM draft defines a Filter Spec as "Packet matching
>information that identifies a set of packets to be treated a certain way by
>a middlebox."  (BTW, there is a typo in the definition in that it says
>"filter spec is a Packet matching information ..." - the "a" should not be
>there.)
>
>The policy terminology RFC defines this simply as a "filter" ("A set of
>terms and/or criteria used for the purpose of separating or categorizing.
>This is accomplished via single- or multi-field matching of traffic header
>and/or payload data.").
>
>I would recommend using the simpler term, "filter", and not defining another
>variant of it.
>
>
>3. Action spec - Defined in Section 2.14 and used in subsequent
>sections/text.  The MIDCOM draft defines an Action Spec as "a description of
>the middlebox treatment/service to be applied to a set of packets."  This is
>consistent with the definition of a "policy action" in the terminology RFC
>("Definition of what is to be done to enforce a policy rule, when the
>conditions of the rule are met.  Policy actions may result in the execution
>of one or more operations to affect and/or configure network traffic and
>network resources.").
>
>I would recommend using the term, "action" or "policy action", and not
>defining another variant of it.
>
>
>4. Ruleset - Defined in Section 2.15 and used in subsequent sections/text.
>The MIDCOM draft defines a Ruleset as "The combination of one or more filter
>Specs and one or more action Specs. Packets matching the filter Spec(s) are
>to be treated as specified by the associated action Spec(s)."  This is the
>essence of a "policy rule" in the terminology RFC and PCIM - "the binding of
>a set of actions to a set of conditions - where the conditions are evaluated
>to determine whether the actions are performed."
>
>I would recommend changing the MIDCOM terminology - a MIDCOM "ruleset" is a
>"policy rule" where the "filters" are the conditions and the "actions" are
>as defined above. 

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Feb 2002 11:39:10 -0500

On Tue, Feb 19, 2002 09:23:34AM -0500, Melinda Shore wrote:
>    As you'll recall we originally

I think there's a fine difference.

Policy Server -> PDP is okay with me.

The rest, though ... 

First, we were referring to what is communicated, in the protocol.  That
is, the specification of the {filter, action, rule}, not its meaning.
The appended "spec" was significant, and is not incompatible with the
use of "filter" suggested in that message.

Second, a ruleset was exactly that.  A set of one *or more* rules, not
just a single rule as in the offered definition.  The rules might be
independent, not just a single set of actions bound to a single set of
conditions.

..Scott

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Feb 2002 12:09:32 -0500

> independent, not just a single set of actions bound to a single set of

OK, having done a bit more investigation ... it wouldn't hurt to have
another definition, "rule", which was in accord with the policy
terminology rfc, but I like keeping "ruleset" around.  We had to work to
get that flexibility.