[Policy] PCELS draft

["Kurt D. Zeilenga" <Kurt at OpenLDAP.org>]

Mircea,

I took a quick look at draft-reyes-policy-core-ext-schema-04 and
found a few things which should be addressed prior to its
progression.  Note that my review is limited to just general
LDAP technical specifications issues.  I did not concern
myself with whether this is the right (or wrong) way to represent
policy information in the directory.  Or with general nits.
Or with ....

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.

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.

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?

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

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.

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. 

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.

-- Kurt


_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy