Subject: comments on draft-ietf-policy-core-schema-00.txt

From: [email-masked]
Date: Fri, 04 Dec 1998 09:32:27 -0500

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

Policy List:

Initial (minor) comments on draft-ietf-policy-core-schema-00.txt

1. wording:

In section 2.0, the sentence: "A specific design goal of this language
is to support simple and complex policies." applies to the PFDL.  I
think a sentence preceding this one to define the "language" would help;
or just removing the above sentence… since it's covered in the PFDL
document.

2. multi-valued PVP

Concerning section 3.4, fifth bullet: "A condition of a policy rule may
specify one or more policy validity periods."  I think the PVP should be
single valued, or " A condition of a policy rule may specify a policy
validity period."  This will be consistent with section 5.4.4, which
states "This attribute points to an object representing the policy
validity period for this policy rule."  Section 5.4.4 talks in the
singular.  Note, though, that a policy rule can aggregate multiple
policy conditions, each condition associated with a PVP.

3. typo in 5.4.5

"Order is used to indicate which the conditions MUST be evaluated…"
should be " Order is used to indicate which conditions MUST be
evaluated…"

4. Instantiating policyRule with the attribute policyErrorCode

I don't understand how the attribute policyErrorCode (with
policyErrorDescription) is used.  Perhaps an example would help me.  Is
it intended that "an indication of an error in executing a policy" will
come from a PEP-enabled device?

5. policyType values

In section 5.4.12, the integer valued policyType categorizes policies.
Do we need to define or reserve well-known values?  There are currently
several policy types (QoS (diff-serv, int-serv), security, etc.) defined
in other I-Ds. It seems like the framework should identify methods of
defining (registering?) future I-Ds, as well as vendor specific, values
for policyType.

6. section 5.6.3

I take it that OIDs are IANA registered, which should cover proprietary
and future "standard" constraints.  Are there any plans to have "common"
policyConstraintEncoding OIDs, for instance, for the PFDL?

chm