Kurt,
Agreed. The next revision of PCELS will include changes to address all the issues that you have identified. Thank you for taking the time to explain these issues in detail.
Mircea.
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Tuesday, February 10, 2004 6:57 PM
> To: mpana@metasolv.com
> Cc: policy@ietf.org
> Subject: RE: PCELS draft
>
>
> My point with 1) is that the I-D seems to be overly reliant on
> formal language (RFC2252) description of the LDAP semantics.
> That is, for an attribute type such as 'pcelsIsMirrored',
> you should, in addition to providing the formal language
> description, you should describe the LDAP semantics. For
> instance:
> The 'pcelsIsMirrored' attribute type is of syntax
> BOOLEAN [X.680] and has an equality matching rule
> of booleanMatch [ref]. Attributes of this type can
> only have a single value.
>
> That is, you should include supporting prose.
>
> My point with 2) is that, it appears to me, that you were relying
> on comments within the formal language description to detail
> an implementation requirement. I suggest you replace all DESC
> comments with something descriptive of the element (as oppose
> to describing a restriction upon the element).
> For instance, for pcelsIPHdrVersion,
> DESC 'HdrIpVersion property'
> With 3), I think your suggested (in your second follow-up) is
> better than the current text.
>
> With 4), note that 'pcelsPriority' is only one of many attribute
> types which are described as having defaults. The issue (and
> resolution) is applicable to each. I think a general statement,
> combined with removing any mention of defaults in DESC fields
> (or replacing the field as suggested in 2), likely can adequately
> resolve this issue.
>
> With 5), I think you may also need to consider (if you haven't
> so already) whether the set/list is represented in a single value
> of the attribute or in multiple, if the latter, how implementations
> are to compose/decompose the PCIM_EXT value from/to its LDAP
> representation.
>
> With 6, I am particular concerned that LDAP's matching semantics
> may not be compatible with the application needs. For instance,
> pcelsIntegerList could contain multiple values each containing
> different representations of the same integer (because these 3
> and 03 are different directory strings). Also, I'm concerned
> that the LDAP ordering matching rule may not meet the applications
> needs (as the ordering will be applied to their representations,
> not their abstract value). As I am PCIM ignorant, I leave it
> you and others to determine if the application needs are met
> or not. However, you might want to make a general note to
> deployers of this that they cannot rely on LDAP syntaxes and
> rules being consistent with PCIM syntaxes and rules.
>
> With 7, okay.
>
>
>
> At 01:07 PM 2/9/2004, mpana@metasolv.com wrote:
> >Kurt,
> >
> >> -----Original Message-----
> >> From: Kurt D. Zeilenga
> [<mailto:Kurt@OpenLDAP.org>mailto:Kurt@OpenLDAP.org]
> >[...]
> >>
> >> 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
> >>
>