[Policy] RE: PCELS draft

[[e-mail]]

Kurt,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[e-mail]]
[...]
> 
> 1) I noticed a number of RFC 2252 schema definitions
> (e.g., pcelsIsMirrored) not accompanied by prose which detailed
> the schema element.  While an RFC 2252 schema definition should
> be provided for each schema element, providing such should not
> be viewed by itself to provide a complete technical
> specification of the schema element.  The prose needs to detail
> all aspects of the schema element, such as application syntax
> and semantics, not covered in the RFC 2252 schema definition.
> It is also good to echo aspects of the RFC 2252 schema definition
> in the prose.

In the opening remarks for Section 5. we indicate that:
"   The semantics for the policy information classes that are to be
   mapped directly from the information model to an LDAP representation
   are detailed in [PCIM_EXT]. Consequently, this document presents only
   a brief reference to those semantics."
In your opinion, is this not sufficient? Are you suggesting that the we
should duplicate some of the text from rfc3460?

> 
> 2) I noticed a number of places where the only description
> of an application restriction upon the element (e.g.,
> pcelsIPHdrVersion) was in a comment field (e.g., DESC) in the
> formal language (RFC2252) description of the element.  These
> restrictions should be stated in prose.

The restrictions are fully documented by the information model (rfc3460).
Are you suggesting that we should re-state their applicability to the LDAP
Schema?

> 
> 3) As application restrictions upon values are not enforced
> by the directory, the specification should state how
> applications are to behave if they find values in the
> directory which, per the application restrictions, are
> invalid.  For instance, how are applications to deal with
> negative pcelsPriority values?

The last of the opening remarks for Section 5. (Note 5) indicates that:
" if a constraint is violated, then the
   policy rule(s) /group(s) SHOULD be treated as being disabled, meaning
   that execution of the policy rule(s) /group(s) SHOULD be stopped."
Do you find this insufficient?

> 
> 4) I don't understand the meaning of pcelsPriority
> DESC note that says: "Default value: 0".  Does this mean that
> if pcelsPriority is not present in the entry, then the
> application is to assume a 0 priority?   Also, since
> pcelsPolicySetAssociation MUSTs pcelsPriority, when would
> pcelsPriority need a default value?

Indeed, we have overlooked this detail. In the next revision we will remove
"Default value: 0" from the DESC if the pcelsPriority attribute definition.

>  I suggest you remove
> these defaults from the DESC field and instead detail how
> applications are to behave when an optional (MAY) attribute
> is not present in the object.

All the default values defined in PCELS for LDAP attributes, they are
directly mapped from information model (rfc3460) property defaults. I'm
thinking of adding a general note on default values for optional attributes
to the opening remarks in Section 5. Would that be acceptable?

> 
> 5) I note that a number of attribute types are described as
> holding "lists" while some are described as "unordered sets".
> The term list implies an ordering of its members.  And, in
> LDAP, all sets are unordered.  I suggest you always use the
> term "set" or always use the term "unordered set" when
> referring to values of a attribute type.

This was indeed poorly worded. The intention was to refer to *sets* of
values. (Unordered obviously.) We will fix this in the next revision.
However, PCELS defines several items with "List" in the name. This is
because of the names of the corresponding information model items. I don't
think that we can change the names without creating confusion.

> 
> 6) I note that a number of attributes of syntaxes/matching
> rules which behave properly (ensure same value (in different
> representations) is not stored twice, ensure matching of
> different representations match) for the kinds of
> application-restricted values placed in them.  For instance,
> it seems a bit odd to use case ignore directory string
> matching for IPv6 addresses. 

I am not sure I understand what this issue is. For instance the attribute
pcelsIPv6AddrList is a DirectoryString and it is mapped from a property
defined by rfc3460 in section 6.14.2. Among other things, this property can
be a hostname hence case insensitive. Is there anything wrong with that?

> 
> 7) The I-D should detail delegations it makes under the OID
> to be assigned by IANA.  That is, the x in IANA-ASSIGNED-OID.2.x
> should be specified so that the RFC-Editor can simply replace
> IANA-ASSIGNED-OID with the assigned OID throughout the I-D
> to produce the RFC-to-be.

Since we might still see some minor changes to the set of classes and
attributes, the plan was to fill-in the numbers after locking down the
content but before advancing the document to the next stage. 

And last but not least, thanks a lot for revising this document

Thank you,
Mircea.


> 
> -- Kurt
>