Subject: Re: RE [Policy] Policy WG I-D Last Call draft-ietf-policy-core-schema-12.t

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 27 Oct 2001 14:27:07 -0700

John wrote:
>this is a summary of the changes made between the -11
>and the -12 versions of PCLS.
>
>1. Stability of the DMTF References
>This issue has been resolved. The DMTF web site has
>been updated, one reference has been correspondingly
>updated, and the other reference has been changed.

Though stability is an issue, I am concerned primarily with
the standard track maturity of the referenced DMTF specifications.
"DMTF LDAP Schema for the CIM v2.5 Core Information Model"
(May 21, 2001) [10] appears to suffer from many of the same
problems which you have recently attempted to address in this
I-D.  I note that reference has been updated since May 21, 2001
and, IMO, still needs significant more work.

Another concern I have regarding references, is that RFC 3060
depends on CIM Schema 2.4, yet this document depends on        
CIM Schema 2.5. Are there compatibility issues resulting from 
this difference?  If so, how are these to be resolved by the
implementor?

In particular, I note that the definition of orderedCimKeys
differs in substance (matching rules) between CIM Schema 2.4
and CIM Schema 2.5.

>2. Mismatched OIDs for Content Rules
>This version of the PCLS no longer has content rules,
>so this issue is moot.
>
>3. DIT Structure and Content Rules
>This version of the PCLS removes both DIT Structure
>Rules as well as DIT Content Rules. However, the PCLS
>text now includes, for the appropriate classes,
>descriptions of how to build both DIT Structure Rules
>and DIT Content Rules, as well as guidelines to ensure
>that both will be able to be implemented for X.500 as
>well as LDAP systems.
>
>4. Request to Add Ordering and Substring Matching Rules
>Ordering and Substring Matching Rules have been added
>for all appropriate classes in the PCLS.

I note that the I-D makes use of matching rules
(integerOrderingMatch, octetStringOrderingMatch,
octetStringSubstringsMatch) yet provides no specification
(itself or by reference) for them.

>5. DESC Field
>The PCLS has been changed in two regards. First,
>normative text has been added in front of the
>definition of every class and attribute in the PCLS
>to ensure that the PCLS is not dependent on information
>in the DESC field. Second, the DESC fields for classes
>and attributes have been shortened to conform with
>standard usage of a short description. Every effort
>has been made to ensure that the resulting DESC fields
>are still useful.
>
>6. Standard Prefixing
>The PCLS has been changed to use the prefix "pcim"
>consistently for both classes and attributes.
>Previously, it was a combination of no prefix and the
>prefixes "ptp" and "policy".
>
>7. Definition of "Policy"
>Text has been added in the PCLS to define the PCLS use
>of the term "policy", and to ensure that the reader
>does not confuse the use of "policy" in the PCLS with
>the use of "policy" in X.501.
>
>8. Schema Definitions
>This version of the PCLS has restructured the
>organization of the class and attribute definitions so
>that for each object class that is defined, its
>attributes are then defined next. If the class has
>subclasses that are grouped together (e.g., the Policy
>Group classes), then the definitions of these subclasses
>follow next. Each of the subclasses will have its
>attributes defined next to it.
>
>9. 2252 Syntax Conformance
>This version of the PCLS has moved the note that
>states that the RFC2252 syntax used has been line-
>wrapped for readability to a more prominent position
>in the document.

Have you verified that the syntaxes conformed to RFC 2252?
I would have done this myself, but my tool requires dependent
schema to be properly defined (and those in [10] are not).

>10. Abstract
>This version of the PCLS has shortened the abstract
>considerably, while ensuring that all pertinent
>information remains in the body of the memo.
>
>11. Potential Referential Integrity Concerns
>This version of the PCLS adds explicit text documenting
>possible referential integrity concerns if the developer
>uses some optional mechanisms in the draft. It also
>more clearly states the benefits of these optional
>mechanisms.
>
>12. Non-Normative Appendix.
>This version of the PCLS has added an explicit statement
>in the Appendix stating that the Appendix is not
>normative.

I am concerned by this statement:
        See the appendix of this document for a complete
        description of the algorithm.

as it makes it unclear where the normative description of
the algorithm can be located.

>13. Statement Concerning OIDs from IANA
>This version of the PCLS has moved the existing statement
>about OIDs being required from IANA to the beginning of
>the document, and has added a second statement to this
>effect as well as a more complete definition of the
>conventions used in the document to identify OIDs.
>
>14. Constraints
>This version of the PCLS specifies additional constraints
>on various data types (e.g., this integer has values that
>are valid from 1..10) and has added text to instruct
>servers and applications what to do if a value outside
>of this range is encountered.

I note that same needs to be done for all attributes.  In
particular, you missed attributes of bitString syntax,
pcimTPCTimeOfDayMask, and likely a few others.

And when you say "the policy rule SHOULD be disabled" do
you mean "the policy rule SHOULD be treated as being disable"
or is there some action required by an LDAP client detecting
such application constraint violation?

>15. The Policy Class Definition
>This version of the PCLS changed the definition of the
>attributes of this class from:
>    MAY ( cn $ policyKeywords )
>to
>    MAY ( cn $ dlmCaption $ dlmDescription $
>          orderedCimKeys $ pcimKeywords )
>
>16.  Reference to DMTF working group
>This version of the PCLS updated the name of the
>applicable DMTF working group from "Service Level
>Agreement WG" to "Policy WG".
>
>17. DMTF Reference Updates
>This version of the PCLS updates references [9] and
>[10] as appropriate.

[10] needs updating again.

>18. Consistent use of PCLS
>This version of the PCLS updates all references to this
>document as "PCLS".
>
>19. "DN Pointer"
>This version of the PCLS has replaced the use of this
>term with different sets of more explicit terminology
>throughout the draft.
>
>20. Correction of classes vs. instances
>This version of the PCLS corrects some inaccurate
>wording in various places in the document to clarify
>when classes vs. instances are being discussed.

I note that when you say "instances of the structural classes"
you actually mean "instances of the structural classes or their
subclasses".  Recall:   [X.501] 8.1.19 structural object class of an entry:
   With respect to a particular entry, the single structural
   object class used to determine the DIT Content Rule and
   DIT Structure Rule applying to the entry. This object class
   is indicated by the structuralObjectClass operational attribute.
   This object class is the most subordinate object class of the
   entry’s structural object class superclass chain.

And as this I-D provides auxiliary classes which can
be used to instanstiate policy objects, additional clarification
may be appropriate.

>21. Auxiliary classes
>This version of the PCLS adds additional clarification
>about auxiliary classes.
>
>22. SuperiorStructureRules
>This version of the PCLS discusses
>SuperiorStructureRules.
>
>23. Clarification on Aux Class Attachment
>This version of the PCLS clarifies that the
>pcimConditionAuxClass and pcimActionSuxClasses, and their
>subclasses, can be attached to three different structural
>classes.
>
>24. Typographical errors
>This version of the PCLS has fixed various typographical
>errors throughout the document.

I've attached my review notes which may aid the editor in
improving this work.

Kurt

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 31 Oct 2001 15:44:46 -0500

Kurt, In my capacity as a DMTF liaison, thanks very much for your input.
This is exactly why we have left the DMTF document at preliminary draft
standard so that we can factor in any IETF feedback before the document
reaches final standard.

The DMTF LDAP Mapping WG will be meeting shortly (hopefully next week) to
discuss your suggestions.

Lee
----- Original Message -----
From: "Kurt D. Zeilenga" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, October 27, 2001 4:27 PM
Subject: Re: RE [Policy] Policy WG I-D Last Call
draft-ietf-policy-core-schema-12.t

   entry's structural object class superclass chain.

Kurt

_______________________________________________
Policy mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/policy