[Policy] RE: PCELS draft

[[e-mail]]

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:[e-mail]]
> Sent: Tuesday, February 10, 2004 6:57 PM
> To: [e-mail]
> Cc: [e-mail]
> 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, [e-mail] wrote:
> >Kurt, 
> >
> >> -----Original Message----- 
> >> From: Kurt D. Zeilenga 
> [<mailto:[e-mail]>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 
> >> 
>