[Policy] PCELS draft
"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Sat, 07 February 2004 04:07 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07540 for <policy-archive@odin.ietf.org>; Fri, 6 Feb 2004 23:07:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApJkW-0007gO-CC for policy-archive@odin.ietf.org; Fri, 06 Feb 2004 23:07:20 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1747K8u029521 for policy-archive@odin.ietf.org; Fri, 6 Feb 2004 23:07:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApJkF-0007eV-Hb; Fri, 06 Feb 2004 23:07:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApJjR-0007dF-J9 for policy@optimus.ietf.org; Fri, 06 Feb 2004 23:06:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07512 for <policy@ietf.org>; Fri, 6 Feb 2004 23:06:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApJjN-000636-00 for policy@ietf.org; Fri, 06 Feb 2004 23:06:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApJiS-000603-00 for policy@ietf.org; Fri, 06 Feb 2004 23:05:13 -0500
Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ApJhp-0005wv-00 for policy@ietf.org; Fri, 06 Feb 2004 23:04:34 -0500
Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i1744S7s020171; Sat, 7 Feb 2004 04:04:28 GMT (envelope-from Kurt@OpenLDAP.org)
Message-Id: <6.0.1.1.0.20040206185214.0483d688@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
Date: Fri, 06 Feb 2004 20:04:17 -0800
To: mpana@metasolv.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: policy@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Policy] PCELS draft
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-BeenThere: policy@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=subscribe>
Mircea, I took a quick look at draft-reyes-policy-core-ext-schema-04 and found a few things which should be addressed prior to its progression. Note that my review is limited to just general LDAP technical specifications issues. I did not concern myself with whether this is the right (or wrong) way to represent policy information in the directory. Or with general nits. Or with .... 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. 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. 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? 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? 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. 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. 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. 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. -- Kurt _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy
- [Policy] PCELS draft Kurt D. Zeilenga
- Re: [Policy] PCELS draft Marcus Brunner
- [Policy] RE: PCELS draft mpana
- [Policy] RE: PCELS draft mpana
- [Policy] RE: PCELS draft Kurt D. Zeilenga
- [Policy] RE: PCELS draft mpana