[Policy] RE: PCELS draft

["Kurt D. Zeilenga" <[e-mail]>]

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


_______________________________________________
Policy mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/policy