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

From: "John Strassner" <[email-masked]>
Date: Fri, 2 Nov 2001 14:29:41 -0700

Hi Kurt,

thanks for a thorough review. I'm going to concentrate solely on the technical matters, and leave the other matters up to other people to answer. Please see inline, look for <js>..</js>. I am eliding parts of the message that you didn't have questions on.

I will be posting a -13 that addresses your concerns. In some cases, I need clarification of the problem, so it would be very helpful and greatly appreciated if you can reply to this message asap so that -13 fully addresses all of your concerns.

regards,
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Kurt D. Zeilenga
Sent: Saturday, October 27, 2001 3:27 PM
To: [email-masked]
Subject: Re: RE [Policy] Policy WG I-D Last Call
draft-ietf-policy-core-schema-12.t

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.

<js>
My only comment here is that why is it relevant that the referenced CIM schema suffers from problems that we fixed in this specification? We're not reviewing the CIM spec, we're reviewing this I-D, and if it did solve problems, then hopefully this I-D (when published as an RFC) will help the DMTF improve their spec.
</js>

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.

<js>
First, the easy question - the CIM schema doesn't define orderedCimKeys. This is defined in the Mapping document. And imho, the definition of orderedCimKeys in the Mapping document has been improved in its latest incarnation.

Second, that answer is crucial to answering your first question. Yes, RFC3060 depends on CIM 2.4, while this I-D depends on CIM 2.5. However, the elements in CIM 2.5 are backwards compatible with the elements in CIM 2.4.
</js>

... text elided...

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

<js>
I'm not sure what you're asking for here. If you are asking for a reference to the definitions of these matching rules, I'll be happy to add them in -13. Please tell me if this addresses your concerns.
</js>

... text elided ...

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

<js>
I personally have not, but one of my developers has successfully implemented this version on two different servers.
</js>

... text elided...

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

<js>
While the appendix references [10], I would be happy to add an explicit statement in -13 defining that [10] is the location for the normative description of the algorithm, both at the start of the appendix and in the above statement. Please tell me if this addresses your concerns.
</js>

... text elided...

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

<js>
Good catch - I'll rework this and send out a new version to the list for approval as -13. I'll also note explicitly any additonal constraint directives that I added to simplify checking by you and others.
</js>

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?

<js>
Yes, I meant that the policy rule SHOULD be disabled. I'll be happy to add additional clarification of this to the -13 version.
</js>

... text elided...

>17. DMTF Reference Updates
>This version of the PCLS updates references [9] and
>[10] as appropriate.

[10] needs updating again.

<js>
I don't understand this comment. [10] is controlled by the DMTF. They haven't updated it, and I don't have the power to update it. And this address is the address of the latest version of the DMTF spec. What am I missing?
</js>

...text elided...

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

<js>
Good catch, I'll add this clarification in the -13 version.
</js>

...text elided...

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

<js>
Thanks, much appreciated
</js>

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 Nov 2001 19:04:32 -0800

>My only comment here is that why is it relevant that the referenced CIM schema suffers from problems that we fixed in this specification? We're not reviewing the CIM spec, we're reviewing this I-D,…

I am primarily reviewing a technical specification consisting of this
I-D and relevant portions of its normative references for technical
errors and omissions.  I noted the concerns and/or issues I found
in my brief review of the reference as I believe they are relevant
to the actions under consideration.

>First, the easy question - the CIM schema doesn't define orderedCimKeys. This is defined in the Mapping document.  And imho, the definition of orderedCimKeys in the Mapping document has been improve…

Please update the I-D such that you reference the appropriate technical
specification for orderedCimKeys and other elements of schema which the
I-D depends upon.

>I'm not sure what you're asking for here.  If you are asking for a reference to the definitions of these matching rules, I'll be happy to add them in -13. Please tell me if this addresses your conce…

If the reference has appropriate technical maturity and otherwise meets
RFC 2026 requirements, yes.

>I personally have not, but one of my developers has successfully implemented this version on two different servers.

Was this developer able to use the 2252 descriptions without modification
(other than to remove the line wrapping)?

Until the DMTF fixes the dependent schema descriptions, this document's
schema descriptions will not pass validation tests by my tool.

>While the appendix references [10], I would be happy to add an explicit statement in -13 defining that [10] is the location for the normative description of the algorithm, both at the start of the a…

Yes.

>Yes, I meant that the policy rule SHOULD be disabled. I'll be happy to add additional clarification of this to the -13 version.

Please do clarify as I'm not sure what "the policy rule SHOULD be disabled" means
(though I think I understand what "the policy rule SHOULD be treated as being disable"
means).

>I don't understand this comment. [10] is controlled by the DMTF. They haven't updated it, and I don't have the power to update it. And this address is the address of the latest version of the DMTF s…

See Bob's note.

>I've attached my review notes which may aid the editor in

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

---

From: "John Strassner" <[email-masked]>
Date: Thu, 8 Nov 2001 16:08:59 -0700

please see inline, look for <js2>..</js2>

regards,
John

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Monday, November 05, 2001 8:05 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: RE [Policy] Policy WG I-D Last Call

At 01:29 PM 2001-11-02, John Strassner wrote:
>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.
>
><js>
>My only comment here is that why is it relevant that the referenced CIM
schema suffers from problems that we fixed in this specification? We're
not reviewing the CIM spec, we're reviewing this I-D, and if it did solve
problems, then hopefully this I-D (when published as an RFC) will help the
DMTF improve their spec.
></js>

I am primarily reviewing a technical specification consisting of this I-D
and relevant portions of its normative references for technical errors and
omissions.  I noted the concerns and/or issues I found in my brief review
of the reference as I believe they are relevant to the actions under
consideration.

<js2>
This I-D has as its root the DMTF spec, but as you note, this I-D corrects
some problems found in the DMTF spec. I would expect the changes in this
I-D to be reflected in a future version of the DMTF spec. That being said,
I don't see how this affects this I-D.
</js2>

>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.
>
><js>
>First, the easy question - the CIM schema doesn't define orderedCimKeys.
This is defined in the Mapping document.  And imho, the definition of
orderedCimKeys in the Mapping document has been improved in its latest
incarnation.

<js2>
The URL was right, the date in the reference was wrong and will be fixed.
</js2>

>Second, that answer is crucial to answering your first question. Yes,
RFC3060 depends on CIM 2.4, while this I-D depends on CIM 2.5. However,
the elements in CIM 2.5 are backwards compatible with the elements in CIM
2.4.

>I'm not sure what you're asking for here.  If you are asking for a
reference to the definitions of these matching rules, I'll be happy to add
them in -13. Please tell me if this addresses your concerns.

<js2>
Yes they do and yes they will be added
</js2>

>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).
>
><js>
>I personally have not, but one of my developers has successfully
implemented this version on two different servers.

<js2>
The delay in responding to you was caused by this question. The answer is
yes, for this I-D, and no, for the DMTF spec. However, the developers were
able to build a running impementation.
</js2>

>While the appendix references [10], I would be happy to add an explicit
statement in -13 defining that [10] is the location for the normative
description of the algorithm, both at the start of the appendix and in the
above statement. Please tell me if this addresses your concerns.

Yes.

>Good catch - I'll rework this and send out a new version to the list for
approval as -13. I'll also note explicitly any additonal constraint
directives that I added to simplify checking by you and others.
>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?
>
><js>
>Yes, I meant that the policy rule SHOULD be disabled. I'll be happy to
add additional clarification of this to the -13 version.
></js>

Please do clarify as I'm not sure what "the policy rule SHOULD be
disabled" means (though I think I understand what "the policy rule SHOULD
be treated as being disable" means).

<js2>
OK
<.js2>

>I don't understand this comment. [10] is controlled by the DMTF. They
haven't updated it, and I don't have the power to update it. And this
address is the address of the latest version of the DMTF spec. What am I
missing?

See Bob's note.

<js2>
Got it...
</js2>

>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 entrys
structural object class superclass chain.