From exim@www1.ietf.org Mon Feb 2 09:11:39 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13776 for ; Mon, 2 Feb 2004 09:11:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anen7-0003gw-CI for policy-archive@odin.ietf.org; Mon, 02 Feb 2004 09:11:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12EB9iI014178 for policy-archive@odin.ietf.org; Mon, 2 Feb 2004 09:11:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anen1-0003dV-64; Mon, 02 Feb 2004 09:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anemb-0003bp-32 for policy@optimus.ietf.org; Mon, 02 Feb 2004 09:10:37 -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 JAA13737 for ; Mon, 2 Feb 2004 09:10:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnemZ-0004Z9-00 for policy@ietf.org; Mon, 02 Feb 2004 09:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnelZ-0004Uw-00 for policy@ietf.org; Mon, 02 Feb 2004 09:09:34 -0500 Received: from mx-relay2.treas.gov ([199.196.144.6] helo=mxrelay3.treas.gov) by ietf-mx with esmtp (Exim 4.12) id 1AnelP-0004Qx-00 for policy@ietf.org; Mon, 02 Feb 2004 09:09:23 -0500 Received: from localhost (localhost [127.0.0.1]) by mxrelay3.treas.gov (Postfix) with ESMTP id E898E5D6; Mon, 2 Feb 2004 09:09:22 -0500 (EST) Received: from mxrelay3.treas.gov ([127.0.0.1]) by localhost (mx-relay2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15148-01-87; Mon, 2 Feb 2004 09:09:22 -0500 (EST) Received: from tias5.treas.gov (tias-gw5.treas.gov [199.196.144.15]) by mxrelay3.treas.gov (Postfix) with SMTP id EB432314; Mon, 2 Feb 2004 09:09:21 -0500 (EST) Received: from no.name.available by tias5.treas.gov via smtpd (for mx-relay2.treas.gov [199.196.144.6]) with SMTP; 2 Feb 2004 14:09:21 UT Received: from big-al.indy.cr.irs.gov (localhost [127.0.0.1]) by mailhub-2.net.treas.gov (8.12.10/8.12.10) with ESMTP id i12E9Khh004298; Mon, 2 Feb 2004 09:09:21 -0500 (EST) Received: from parnelli.indy.cr.irs.gov (localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.12.8/8.12.8) with ESMTP id i12E9KFS024559; Mon, 2 Feb 2004 09:09:20 -0500 Message-ID: <401E5A10.4050508@parnelli.indy.cr.irs.gov> Date: Mon, 02 Feb 2004 09:09:20 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpana@metasolv.com Cc: policy@ietf.org Subject: Re: [Policy] PCELS and PCLS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit mpana@metasolv.com wrote, On 01/28/04 12:27: > PCLS implementers, The main issue that was expressed relative to the > previous revision (-03) of PCELS was its "unfriendly" position relative > to PCLS. PCELS has been changed (-04) to address this issue and a new > section was specifically added to the document for discussing the > [non]impact of PCELS on PCLS implementations. > > Has anybody had the chance to read the -04 revision? Do you find the new > approach acceptable? In particular, are there any comments regarding the > provisions of section "4.3 Impact on existing implementations of the > Policy Core LDAP Schema"? > > Thank You, > Mircea Pana. > Mircea, I thank and congratulate you and your co-authors for your careful and thorough consideration of the PCLS compatibility issues. Your draft achieves the goal of doing no harm to PCLS. Your draft's section 4.3 is especially welcome. It assures the PCLS implementer of compatibility, while carefully pointing out the few minor areas of potential but minimal conflict. In addition, your draft's ASCII object diagrams are first rate. You have done good work to illustrate a complex model. Thanks again, -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz # # voice (317) 226-7060 # FAX (317) 226-6378 #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Feb 6 23:07:47 2004 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 ; 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 ; 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" 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: , List-Id: Policy Framework List-Post: List-Help: List-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 From exim@www1.ietf.org Mon Feb 9 08:28:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17855 for ; Mon, 9 Feb 2004 08:28:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBSJ-0006K6-PA for policy-archive@odin.ietf.org; Mon, 09 Feb 2004 08:28:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19DS7lk024276 for policy-archive@odin.ietf.org; Mon, 9 Feb 2004 08:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBSD-0006Iw-4P; Mon, 09 Feb 2004 08:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBRH-0006Gv-FB for policy@optimus.ietf.org; Mon, 09 Feb 2004 08:27:03 -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 IAA17827 for ; Mon, 9 Feb 2004 08:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBRG-00053n-00 for policy@ietf.org; Mon, 09 Feb 2004 08:27:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBQM-0004zu-00 for policy@ietf.org; Mon, 09 Feb 2004 08:26:07 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AqBPi-0004qM-00 for policy@ietf.org; Mon, 09 Feb 2004 08:25:26 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i19DOqZY056466 for ; Mon, 9 Feb 2004 14:24:55 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i19DOo5H056464 for ; Mon, 9 Feb 2004 14:24:50 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i19DOnZU056461; Mon, 09 Feb 2004 14:24:50 +0100 (CET) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BBFA125064; Mon, 9 Feb 2004 14:24:48 +0100 (CET) Date: Mon, 09 Feb 2004 14:24:48 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Kurt D. Zeilenga" , mpana@metasolv.com Cc: policy@ietf.org Subject: Re: [Policy] PCELS draft Message-ID: <2918566.1076336688@[10.1.1.130]> In-Reply-To: <6.0.1.1.0.20040206185214.0483d688@127.0.0.1> References: <6.0.1.1.0.20040206185214.0483d688@127.0.0.1> X-Mailer: Mulberry/3.1.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kurt, > 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. > The lack of prose at various elements is due to the fact that the prose is written down in the Information Model (RFC 3460). We don't feel like duplicating all of it. Marcus _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Feb 9 16:16:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12883 for ; Mon, 9 Feb 2004 16:16:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIlD-0002Ai-LL for policy-archive@odin.ietf.org; Mon, 09 Feb 2004 16:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LG77W008342 for policy-archive@odin.ietf.org; Mon, 9 Feb 2004 16:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIl8-00029u-4I; Mon, 09 Feb 2004 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIkY-00028G-Bn for policy@optimus.ietf.org; Mon, 09 Feb 2004 16:15:26 -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 QAA12670 for ; Mon, 9 Feb 2004 16:15:23 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIkW-0002Nv-00 for policy@ietf.org; Mon, 09 Feb 2004 16:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIjX-0002Gr-00 for policy@ietf.org; Mon, 09 Feb 2004 16:14:25 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1AqIil-00027h-00 for policy@ietf.org; Mon, 09 Feb 2004 16:13:35 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id <1JJRMPFM>; Mon, 9 Feb 2004 15:11:50 -0600 Message-ID: To: Kurt@OpenLDAP.org Cc: policy@ietf.org Date: Mon, 9 Feb 2004 15:07:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF50.C27D92DC" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] RE: 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EF50.C27D92DC Content-Type: text/plain; charset="iso-8859-1" Kurt, > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] [...] > > 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 > ------_=_NextPart_001_01C3EF50.C27D92DC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PCELS draft

Kurt,

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
[...]
>
> 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
>

------_=_NextPart_001_01C3EF50.C27D92DC-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Feb 9 19:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05265 for ; Mon, 9 Feb 2004 19:32:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLot-0006g8-37 for policy-archive@odin.ietf.org; Mon, 09 Feb 2004 19:32:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0W7gF025668 for policy-archive@odin.ietf.org; Mon, 9 Feb 2004 19:32:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLoo-0006fh-0G; Mon, 09 Feb 2004 19:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqLoI-0006fH-Rz for policy@optimus.ietf.org; Mon, 09 Feb 2004 19:31:31 -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 TAA05225 for ; Mon, 9 Feb 2004 19:31:27 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqLoH-00010M-00 for policy@ietf.org; Mon, 09 Feb 2004 19:31:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqLnY-0000vt-00 for policy@ietf.org; Mon, 09 Feb 2004 19:30:45 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1AqLmz-0000je-00 for policy@ietf.org; Mon, 09 Feb 2004 19:30:09 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id <1JJRMVLC>; Mon, 9 Feb 2004 18:28:29 -0600 Message-ID: To: Kurt@OpenLDAP.org Cc: policy@ietf.org Date: Mon, 9 Feb 2004 18:24:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF6C.3B7C1580" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] RE: 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EF6C.3B7C1580 Content-Type: text/plain; charset="iso-8859-1" Kurt, > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] [...] > > 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? Does the text below address the issues 2) and 3) (from your list)? (candidate text for replacing Note 5 in section 5 of PCELS-04) " Note 5: Some of the following attribute definitions MUST conform to additional constraints on various data types (e.g. "Policy priority. Valid values: any non-negative integer."). Just like the attribute semantics, the definition of the value structures, valid ranges, etc. is covered by [PCIM_EXT] for the corresponding properties while in this document such constraints are only briefly mentioned. In all cases, if a constraint is violated, the entry SHOULD be treated as invalid and the policy rules or groups that refer to it SHOULD be treated as being disabled, meaning that the execution of such policy rules or groups SHOULD be stopped." Thanks, Mircea ------_=_NextPart_001_01C3EF6C.3B7C1580 Content-Type: text/html; charset="iso-8859-1" RE: PCELS draft

Kurt,

> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
[...]
> > 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?

Does the text below address the issues 2) and 3) (from your list)?
(candidate text for replacing Note 5 in section 5 of PCELS-04)

"   Note 5: Some of the following attribute definitions MUST conform
   to additional constraints on various data types (e.g. "Policy
   priority. Valid values: any non-negative integer."). Just like
   the attribute semantics, the definition of the value structures,
   valid ranges, etc. is covered by [PCIM_EXT] for the corresponding
   properties while in this document such constraints are only briefly
   mentioned. In all cases, if a constraint is violated, the entry
   SHOULD be treated as invalid and the policy rules or groups that
   refer to it SHOULD be treated as being disabled, meaning that the
   execution of such policy rules or groups SHOULD be stopped."

Thanks,
Mircea

------_=_NextPart_001_01C3EF6C.3B7C1580-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Feb 11 13:38:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12950 for ; Wed, 11 Feb 2004 13:38:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzFR-0007QX-G8 for policy-archive@odin.ietf.org; Wed, 11 Feb 2004 13:38:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BIc8wO028512 for policy-archive@odin.ietf.org; Wed, 11 Feb 2004 13:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzFJ-0007PA-V7; Wed, 11 Feb 2004 13:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqzF9-0007Lm-Mt for policy@optimus.ietf.org; Wed, 11 Feb 2004 13:37:51 -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 NAA12927 for ; Wed, 11 Feb 2004 13:37:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqzF7-0004Q8-00 for policy@ietf.org; Wed, 11 Feb 2004 13:37:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqzEC-0004JV-00 for policy@ietf.org; Wed, 11 Feb 2004 13:36:53 -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 1AqzDH-0004Bh-00 for policy@ietf.org; Wed, 11 Feb 2004 13:35:55 -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 i1BIZr7s002624; Wed, 11 Feb 2004 18:35:54 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040210151516.049545d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 10 Feb 2004 15:57:02 -0800 To: mpana@metasolv.com From: "Kurt D. Zeilenga" Cc: policy@ietf.org In-Reply-To: References: 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.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Subject: [Policy] RE: 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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, mpana@metasolv.com wrote: >Kurt, > >> -----Original Message----- >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >[...] >> >> 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 Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Feb 13 21:35:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21202 for ; Fri, 13 Feb 2004 21:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arpe9-0002rt-ML for policy-archive@odin.ietf.org; Fri, 13 Feb 2004 21:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1E2Z9Z6011026 for policy-archive@odin.ietf.org; Fri, 13 Feb 2004 21:35:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arpe3-0002rV-E1; Fri, 13 Feb 2004 21:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArpdN-0002V8-Ts for policy@optimus.ietf.org; Fri, 13 Feb 2004 21:34:22 -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 VAA21183 for ; Fri, 13 Feb 2004 21:34:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArpdL-00066p-00 for policy@ietf.org; Fri, 13 Feb 2004 21:34:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArpcO-00063U-00 for policy@ietf.org; Fri, 13 Feb 2004 21:33:22 -0500 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1ArpbU-0005wb-00 for policy@ietf.org; Fri, 13 Feb 2004 21:32:24 -0500 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id <159C8BYH>; Fri, 13 Feb 2004 19:31:49 -0700 Message-ID: From: John Strassner To: "'mpana@metasolv.com'" , "'policy@ietf.org'" Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt Date: Fri, 13 Feb 2004 19:31:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F2A2.B26EDEA0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F2A2.B26EDEA0 Content-Type: text/plain First, I support Kurt's comments on LDAP, and will reply to those in a separate email. Second, I list below a set of additional comments on this draft. Third, the lack of an overall diagram makes it very difficult to evaluate the correctness of this model. This draft is not complete enough to construct such a model. Fourth, a cursory scan revealed that there is no pcelsPolicyGroup class. This is strange, since PolicyGroup is listed as a subclass of PolicySet in RFC 3460. Why is this? Fifth, why is there a pcelsRule and a pcimRule class? Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, I started to go through the document in detail with my developers to try and implement it. We couldn't. We give you inconsistencies that we noticed (grammatical and otherwise) through page 31). Finally, I was surprised to see a lack of an Acknowledgments section, especially given the amount of feedback that several people on this list gave the authors. That's in poor form. Comments are as follows: - s/RFC zzzz/RFC 3703 - page 3. You write: "...the combined class hierarchy for the LDAP object classes defined in [PCLS] and in this document". You should include concepts from 3460 that you mapped into new classes, and add that you defined new classes not in 3460 or 3703. - page 4-7, class diagram - this diagram has no caption. Please add one. In addition, I find the diagram inpenetrable, in that the reader has no idea where these classes came from. I think you need a simpler introduction saying 3060 provided this, 3460 did this, and thus we came up with this. Take this key and show, for any class that isn't new in this document, where it came from. - page 4 - why is your class named pcelsFilerEntry, when 3460 names its class FilterEntryBase? - page 4 - why is your class named pcelsIPHeaders, when 3460 names its class IPHeadersFilter? The Filter part is important! - page 4 - why is your class named pcels8021Headers, when 3460 names its class 8021Filter? The Filter part is important! - page 4 - why is your class named pcelsCompoundFilterAuxClass, when a more consistent name would be pcelsCompoundFilterConditionAuxClass? The Condition part is important! - general reflections on the class diagram: part of the problem is that you are building a schema from three different sources: (1) RFC 3703, (2) RFC 3460, and (3) your own additions. I see no discussion on how these relate to each other, which would have been helpful. - page 7 - you didn't state whether this is for all associations. This is exacerbated by you saying: "...might need to implement the association..." - which implies a single association. In addition, this is a terse description - the naive reader won't understand why aux classes are being used - you need a reference or a couple of sentences explaining this. - page 7 - you state: "The LDAP object classes defined in this document are a direct mapping from the corresponding classes and, in some cases, the associations defined in [PCIM_EXT] ". Not strictly true, as you are also seeking to update RFC 3703 (e.g., where is pcimSubtreesPtrAuxClass defined in RFC 3460?). - pages 8-11: your table has no caption - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They aren't listed in this table, and better be, if you are "updating" RFC 3703. - once again, I see lots of irksome naming issues. The LDAP schema shouldn't change the name of a class defined in another RFC. Why have you done this? - page 8, 4th row. How can you give two different mappings to a single object class? And how can a RULE (i.e., pcelsRule) map to a GROUP? - page 10, 1st row. How can a single info model association map to two different associations? And do you mean "and" in this row? This would mean that I would have to instantiate both pcelsPolicySet and pcelsPolicySetAssociation, which is clearly wrong. This comment also applies for the other rows on this page where you have "and". - page 10 - it is of no help to say "see PolicySetInSystem" in this table for the 3rd and 4th rows - that only confuses the reader. Please spell out what you mean here. - Page 11 - the reader will wonder why ReusablePolicy and PolicyRoleCollectionInSystem are only implementable via DIT containment, when every other association has an association defined (independent of whether DIT containment could be used). - Section 4.2, line 3, you write: "The concept of an ordered set of policies...". LDAP doesn't have ordered sets. How are you going to implement this? - Page 13, Section 4.3, second paragraph - s/deprecates/deprecate - Page 13, Note - actually, PCLS does NOT have anything to do with PCIMe, so this note needs to be reworded - Page 14, Section 4.5 - s/an other/another (and other places) - s/"rule /group"/"rule/group" (5 places) (and other places) - Page 16, section 4.6, - s/CompoundPolicyActionclasses/CompoundPolicyAction classes - conditions /actions/"conditions/actions" (and other places) - Page 22. How are you going to enforce an "ordered set of rules /groups"? That is, how can you guarantee that the DSA stores your rules/groups [sic] in the order that you want, and where is that order specified? What if a DSA doesn't have ordering controls? - Same section as above - you say that the "association entries enable relative ordering of the aggregated pcelsPolicySet instances within the scope of the aggregating pcelsPolicySet" - how is this accomplished with a plain, vanilla LDAP server with no controls? - Page 23 - the DESC for pcelsPolicySetList should say that it contains an UNORDERED list of DN references. - Page 23, note above Section 5.2, is slightly incorrect. Only those implementations that WANT TO BE COMPATIBLE WITH PCELS should use this aggregation mechanism instead of those defined by PCLS. Not every implementation mechanism is going to want to change. - Page 23, Section 5.2, says "The pcelsPolicySetAssociation class is used to aggregate instances of pcelsPolicySet into other entries." This is incorrect, as pcelsPolicySet is abstract and thus cannot be instantiated. - Same section, you write: "...realizes a (subclass of) PolicySetComponent aggregation [sic]. When subordinated to (subclass of) dlm1System...realizes a PolicySetInSystem association [sic]". How can the same element realize an aggregation in one usage and an association in another usage? This is semantically inconsistent. - Next paragraph says: "A non-reusable instance of (subclass of) pcelsPolicySet is attached as auxiliary class directly to the pcelsPolicySetAssociation entry." Subclasses of pcelsPolicySet that are not abstract are pcelsRuleAuxClass and pcelsRuleInstance. The above sentence only makes sense for pcelsRuleAuxClass. - Next paragraph doesn't make sense. First, you clearly mean a non- abstract subclass of pcelsPolicySet. Second, you are recommending that an ERROR be ignored? Why don't you stop operation? - Page 24, DESC of pcelsPriority is insufficient, as "0" has special semantics that you haven't mentioned. This should, of course, also be present in accompanying prose, as Kurt points out. - Page 24, DESC of pcelsPolicySetDN should state that this is an UNORDERED list of DNs. - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule Class and Its Subclasses - Page 24, Section 5.3, you say: "The pcelsRule is the base class representing policy rules." Does this mean that an implementation can NOT use the subclasses of pcimRule anymore? - Page 24, next paragraph, you say: "This class shares the Condition/Action aggregation methods with the pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass object classes.". Why does it also not share the pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass object classes as well? - Page 25, top paragraph, again says that the implementer should ignore an error condition. This isn't a good idea. - Page 25, next paragraph has the same problem. - Page 26, the pcelsConditionListType attribute has a constraint. No text is provided that instructs the implementer what to do, aside from Note 5 on page 21, which says: "Text has been added to instruct servers and applications what to do if a value outside of this range is encountered" - which is exactly the problem - no text is here. Note that this is a systemic problem with any constrained attribute defined in this draft. Thus, I will only mention this once. - Page 27, WHY isn't a PolicyGroup class implemented? You give no reason for not doing this. Note also that Note 2 talks about ORDERED policy rules - I don't see how you can construct those. - Page 27, section 5.4, again you say "pcelsRule" instead of "non- abstract subclasses of pcelsRule". - Page 28, top paragraph, another error that you are recommending should be ignored - Page 28, DESC for pcelsConditionAssociation is wrong; you say that it can be used for a pcelsRule instead of a non-abstract subclass of pcelsRule - Page 28, section 5.5, again you say "pcelsRule" instead of "non- abstract subclasses of pcelsRule". - Page 28, last paragraph, another error that you are recommending should be ignored. - Page 29, DESC for pcelsActionAssociation is wrong; you say that it can be used for a pcelsRule instead of a non-abstract subclass of pcelsRule - Page 29, last paragraph above Section 5.6, another error that you are recommending should be ignored. - Page 29, Section 5.6, last two paragraphs are errors that you are recommending should be ignored. - Page 29, last paragraph above Section 5.6, another error that you are recommending should be ignored. - Page 30, the DESC for pcelsVariableDN is wrong. You say that it is a "DN reference to a pcelsVariable entry", when it should be a DN reference to a subclass of either pcelsExplicitVariableAuxClass or pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass - Page 30, the DESC for pcelsValueDN is wrong - it should be a subclass of pcelsValueDN. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com ------_=_NextPart_001_01C3F2A2.B26EDEA0 Content-Type: text/html Message
First, I support Kurt's comments on LDAP, and will reply to those in a separate email.
 
Second, I list below a set of additional comments on this draft.
 
Third, the lack of an overall diagram makes it very difficult to evaluate the correctness of this model. This draft is not complete enough to construct such a model.
 
Fourth, a cursory scan revealed that there is no pcelsPolicyGroup class. This is strange, since PolicyGroup is listed as a subclass of PolicySet in RFC 3460. Why is this?
 
Fifth, why is there a pcelsRule and a pcimRule class?
 
Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, I started to go through the document in detail with my developers to try and implement it. We couldn't. We give you inconsistencies that we noticed (grammatical and otherwise) through page 31).
 
Finally, I was surprised to see a lack of an Acknowledgments section, especially given the amount of feedback that several people on this list gave the authors. That's in poor form.
 
Comments are as follows:
 
  - s/RFC zzzz/RFC 3703
  - page 3. You write: "...the combined class hierarchy for the LDAP
    object classes defined in [PCLS] and in this document". You should
    include concepts from 3460 that you mapped into new classes, and
    add that you defined new classes not in 3460 or 3703.
  - page 4-7, class diagram - this diagram has no caption. Please add
    one. In addition, I find the diagram inpenetrable, in that the
    reader has no idea where these classes came from. I think you need
    a simpler introduction saying 3060 provided this, 3460 did this, and
    thus we came up with this. Take this key and show, for any class
    that isn't new in this document, where it came from.
  - page 4 - why is your class named pcelsFilerEntry, when 3460 names
    its class FilterEntryBase?
  - page 4 - why is your class named pcelsIPHeaders, when 3460 names
    its class IPHeadersFilter? The Filter part is important!
  - page 4 - why is your class named pcels8021Headers, when 3460 names
    its class 8021Filter? The Filter part is important!
  - page 4 - why is your class named pcelsCompoundFilterAuxClass, when 
    a more consistent name would be pcelsCompoundFilterConditionAuxClass?
    The Condition part is important!
  - general reflections on the class diagram: part of the problem is that
    you are building a schema from three different sources: (1) RFC 3703,
    (2) RFC 3460, and (3) your own additions. I see no discussion on how
    these relate to each other, which would have been helpful.
  - page 7 - you didn't state whether this is for all associations. This
    is exacerbated by you saying: "...might need to implement the
    association..." - which implies a single association. In addition,
    this is a terse description - the naive reader won't understand why
    aux classes are being used - you need a reference or a couple of
    sentences explaining this.
  - page 7 - you state: "The LDAP object classes defined in this document
    are a direct mapping from the corresponding classes and, in some
    cases, the associations defined in [PCIM_EXT] ". Not strictly true,
    as you are also seeking to update RFC 3703 (e.g., where is
    pcimSubtreesPtrAuxClass defined in RFC 3460?).
  - pages 8-11: your table has no caption
  - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They
    aren't listed in this table, and better be, if you are "updating"
    RFC 3703.
  - once again, I see lots of irksome naming issues. The LDAP schema
    shouldn't change the name of a class defined in another RFC. Why
    have you done this?
  - page 8, 4th row. How can you give two different mappings to a single
    object class? And how can a RULE (i.e., pcelsRule) map to a GROUP?
  - page 10, 1st row. How can a single info model association map to
    two different associations? And do you mean "and" in this row? This
    would mean that I would have to instantiate both pcelsPolicySet
    and pcelsPolicySetAssociation, which is clearly wrong. This comment
    also applies for the other rows on this page where you have "and".
  - page 10 - it is of no help to say "see PolicySetInSystem" in this
    table for the 3rd and 4th rows - that only confuses the reader.
    Please spell out what you mean here.
  - Page 11 - the reader will wonder why ReusablePolicy and
    PolicyRoleCollectionInSystem are only implementable via DIT
    containment, when every other association has an association defined
    (independent of whether DIT containment could be used).
  - Section 4.2, line 3, you write: "The concept of an ordered set of
    policies...". LDAP doesn't have ordered sets. How are you going to
    implement this?
  - Page 13, Section 4.3, second paragraph - s/deprecates/deprecate
  - Page 13, Note - actually, PCLS does NOT have anything to do with
    PCIMe, so this note needs to be reworded
  - Page 14, Section 4.5
    - s/an other/another (and other places)
    - s/"rule /group"/"rule/group" (5 places) (and other places)
  - Page 16, section 4.6,
    - s/CompoundPolicyActionclasses/CompoundPolicyAction classes
    - conditions /actions/"conditions/actions" (and other places)
  - Page 22. How are you going to enforce an "ordered set of
    rules /groups"? That is, how can you guarantee that the DSA stores
    your rules/groups [sic] in the order that you want, and where is
    that order specified? What if a DSA doesn't have ordering controls?
  - Same section as above - you say that the "association entries enable
    relative ordering of the aggregated pcelsPolicySet instances within
    the scope of the aggregating pcelsPolicySet" - how is this
    accomplished with a plain, vanilla LDAP server with no controls?
  - Page 23 - the DESC for pcelsPolicySetList should say that it
    contains an UNORDERED list of DN references.
  - Page 23, note above Section 5.2, is slightly incorrect. Only those
    implementations that WANT TO BE COMPATIBLE WITH PCELS should use
    this aggregation mechanism instead of those defined by PCLS. Not
    every implementation mechanism is going to want to change.
  - Page 23, Section 5.2, says "The pcelsPolicySetAssociation class is
    used to aggregate instances of pcelsPolicySet into other entries."
    This is incorrect, as pcelsPolicySet is abstract and thus cannot be
    instantiated.
  - Same section, you write: "...realizes a (subclass of)
    PolicySetComponent aggregation [sic]. When subordinated to (subclass
    of) dlm1System...realizes a PolicySetInSystem association [sic]".
    How can the same element realize an aggregation in one usage and an
    association in another usage? This is semantically inconsistent.
  - Next paragraph says: "A non-reusable instance of (subclass of)
    pcelsPolicySet is attached as auxiliary class directly to the
    pcelsPolicySetAssociation entry." Subclasses of pcelsPolicySet that
    are not abstract are pcelsRuleAuxClass and pcelsRuleInstance. The
    above sentence only makes sense for pcelsRuleAuxClass.
  - Next paragraph doesn't make sense. First, you clearly mean a non-
    abstract subclass of pcelsPolicySet. Second, you are recommending
    that an ERROR be ignored? Why don't you stop operation?
  - Page 24, DESC of pcelsPriority is insufficient, as "0" has special
    semantics that you haven't mentioned. This should, of course, also
    be present in accompanying prose, as Kurt points out.
  - Page 24, DESC of pcelsPolicySetDN should state that this is an
    UNORDERED list of DNs.
  - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule
    Class and Its Subclasses
<note: at this point I'm not going to correct any remaining grammar
 errors, such as the next line ("The pcelsRule is...") because there
 are too many of them.>
  - Page 24, Section 5.3, you say: "The pcelsRule is the base class
    representing policy rules." Does this mean that an implementation
    can NOT use the subclasses of pcimRule anymore?
  - Page 24, next paragraph, you say: "This class shares the
    Condition/Action aggregation methods with the
    pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass
    object classes.". Why does it also not share the
    pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass
    object classes as well?
  - Page 25, top paragraph, again says that the implementer should ignore
    an error condition. This isn't a good idea.
  - Page 25, next paragraph has the same problem.
  - Page 26, the pcelsConditionListType attribute has a constraint. No
    text is provided that instructs the implementer what to do, aside
    from Note 5 on page 21, which says: "Text has been added to instruct
    servers and applications what to do if a value outside of this range
    is encountered" - which is exactly the problem - no text is here.
Note that this is a systemic problem with any constrained attribute
defined in this draft. Thus, I will only mention this once.
  - Page 27, WHY isn't a PolicyGroup class implemented? You give no
    reason for not doing this. Note also that Note 2 talks about ORDERED
    policy rules - I don't see how you can construct those.
  - Page 27, section 5.4, again you say "pcelsRule" instead of "non-
    abstract subclasses of pcelsRule".
  - Page 28, top paragraph, another error that you are recommending
    should be ignored
  - Page 28, DESC for pcelsConditionAssociation is wrong; you say that
    it can be used for a pcelsRule instead of a non-abstract subclass of
    pcelsRule
  - Page 28, section 5.5, again you say "pcelsRule" instead of "non-
    abstract subclasses of pcelsRule".
  - Page 28, last paragraph, another error that you are recommending
    should be ignored.
  - Page 29, DESC for pcelsActionAssociation is wrong; you say that
    it can be used for a pcelsRule instead of a non-abstract subclass of
    pcelsRule
  - Page 29, last paragraph above Section 5.6, another error that you are
    recommending should be ignored.
  - Page 29, Section 5.6, last two paragraphs are errors that you are
    recommending should be ignored.
<At this point, I'm going to stop listing these, as it is a systemic problem that should be fixed in the next release>
  - Page 29, last paragraph above Section 5.6, another error that you are
    recommending should be ignored.
  - Page 30, the DESC for pcelsVariableDN is wrong. You say that it is a
    "DN reference to a pcelsVariable entry", when it should be a DN
    reference to a subclass of either pcelsExplicitVariableAuxClass or
    pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass
  - Page 30, the DESC for pcelsValueDN is wrong - it should be a subclass
    of pcelsValueDN.
 
 

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.719.785.0648
  fax:     +1.719.785.0644
email:    john.strassner@intelliden.com

------_=_NextPart_001_01C3F2A2.B26EDEA0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sun Feb 15 19:59:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05760 for ; Sun, 15 Feb 2004 19:59:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsX6M-0003KD-Cu for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 19:59:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G0xAQF012777 for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 19:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsX6E-0003Jb-4D; Sun, 15 Feb 2004 19:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsX68-0003J8-0s for policy@optimus.ietf.org; Sun, 15 Feb 2004 19:58:56 -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 TAA05756 for ; Sun, 15 Feb 2004 19:58:54 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsX66-0004s7-00 for policy@ietf.org; Sun, 15 Feb 2004 19:58:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsX5A-0004ow-00 for policy@ietf.org; Sun, 15 Feb 2004 19:57:59 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1AsX4r-0004lS-00 for policy@ietf.org; Sun, 15 Feb 2004 19:57:37 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id <1JJRTW5Q>; Sun, 15 Feb 2004 18:55:48 -0600 Message-ID: To: Kurt@OpenLDAP.org Cc: policy@ietf.org Date: Sun, 15 Feb 2004 18:51:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F427.0808936C" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] RE: 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F427.0808936C Content-Type: text/plain; charset="iso-8859-1" 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:Kurt@OpenLDAP.org] > Sent: Tuesday, February 10, 2004 6:57 PM > To: mpana@metasolv.com > Cc: policy@ietf.org > 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, mpana@metasolv.com wrote: > >Kurt, > > > >> -----Original Message----- > >> From: Kurt D. Zeilenga > [mailto:Kurt@OpenLDAP.org] > >[...] > >> > >> 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 > >> > ------_=_NextPart_001_01C3F427.0808936C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PCELS draft

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:Kurt@OpenLDAP.org]
> Sent: Tuesday, February 10, 2004 6:57 PM
> To: mpana@metasolv.com
> Cc: policy@ietf.org
> 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, mpana@metasolv.com = wrote:
> >Kurt,
> >
> >> -----Original Message-----
> >> From: Kurt D. Zeilenga
> [<mailto:Kurt@OpenLDAP.org>mailto:Kurt@OpenLDAP.org]
> >[...]
> >>
> >> 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
> >>
>

------_=_NextPart_001_01C3F427.0808936C-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sun Feb 15 21:13:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09149 for ; Sun, 15 Feb 2004 21:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYFr-0000Jq-Nz for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 21:13:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G2D3kX001222 for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 21:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYFp-0000JB-PZ; Sun, 15 Feb 2004 21:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYF1-0000Hr-C3 for policy@optimus.ietf.org; Sun, 15 Feb 2004 21:12:11 -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 VAA09117 for ; Sun, 15 Feb 2004 21:12:08 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsYEy-0002Xr-00 for policy@ietf.org; Sun, 15 Feb 2004 21:12:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsYE5-0002T2-00 for policy@ietf.org; Sun, 15 Feb 2004 21:11:14 -0500 Received: from passwd.metasolv.com ([216.30.145.17] helo=srvplemail2.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1AsYDf-0002NW-00 for policy@ietf.org; Sun, 15 Feb 2004 21:10:47 -0500 Received: by passwd.metasolv.com with Internet Mail Service (5.5.2653.19) id <13XDZ3R5>; Sun, 15 Feb 2004 20:10:26 -0600 Message-ID: To: policy@ietf.org Date: Sun, 15 Feb 2004 20:04:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F431.3E973E60" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] pcimRepository and pcelsReusableContainer 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F431.3E973E60 Content-Type: text/plain; charset="ISO-8859-1" The open issue #4 listed in Appendix B) in PCELS-04 refers to the proposed implementation for the ReusablePolicyContainer class. The authors have reached an impasse and would appreciate input from the WG wrt. the options presented below. Option 1 (current proposal): ...+---dlm1AdminDomain (abstract) | +---pcimRepository (abstract) | +---pcelsReusableContainer (abstract new) | +---pcelsReusableContainerAuxClass | (auxiliary new) | +---pcelsReusableContainerInstance (structural new) (pcimRepositoryInstance and pcimRepositoryAuxClass classes omitted here as irrelevant) Pro: Virtually seamless compatibility with PCLS. Con: Through class inheritance a pcelsReusableContainer instance is also a pcimRepository (PCLS) but the class pcimRepository implements PolicyRepository (PCIM) which has been deprecated (PCIM_EXT). Option 2: +---dlm1AdminDomain (abstract) | +---pcelsReusableContainer (abstract new) | +---pcelsReusableContainerAuxClass | (auxiliary new) | +---pcelsReusableContainerInstance (structural new) (pcimRepository classes omitted here as irrelevant) Pro: PCELS implementations/deployments may be free of references to pcimRepository (strict compatibility with PCIM_EXT). Con: Compatibility with PCLS requires PCELS implementations to perform additional and explicit actions. Thank You, Mircea. ------_=_NextPart_001_01C3F431.3E973E60 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable pcimRepository and pcelsReusableContainer

The open issue #4 listed in Appendix B) in PCELS-04 = refers to the proposed implementation for the ReusablePolicyContainer = class. The authors have reached an impasse and would appreciate input = from the WG wrt. the options presented below.

Option 1 (current proposal):

      ...+---dlm1AdminDomain = (abstract)
          &nb= sp;  |
          &nb= sp;  +---pcimRepository (abstract)
          &nb= sp;      |
          &nb= sp;      +---pcelsReusableContainer (abstract = new)
          &nb= sp;          |
          &nb= sp;          = +---pcelsReusableContainerAuxClass
          &nb= sp;          |   = (auxiliary new)
          &nb= sp;          |
          &nb= sp;          = +---pcelsReusableContainerInstance
          &nb= sp;           &nb= sp;  (structural new)

(pcimRepositoryInstance and pcimRepositoryAuxClass = classes omitted here as irrelevant)

Pro: Virtually seamless compatibility with = PCLS.
Con: Through class inheritance a = pcelsReusableContainer instance is also a pcimRepository (PCLS) but the = class pcimRepository implements PolicyRepository (PCIM) which has been = deprecated (PCIM_EXT).

Option 2:

           = +---dlm1AdminDomain (abstract)
          &nb= sp;    |
          &nb= sp;    +---pcelsReusableContainer (abstract new)
          &nb= sp;        |
          &nb= sp;        = +---pcelsReusableContainerAuxClass
          &nb= sp;        |   (auxiliary = new)
          &nb= sp;        |
          &nb= sp;        = +---pcelsReusableContainerInstance
          &nb= sp;            = (structural new)

(pcimRepository classes omitted here as = irrelevant)

Pro: PCELS implementations/deployments may be free of = references to pcimRepository (strict compatibility with = PCIM_EXT).

Con: Compatibility with PCLS requires PCELS = implementations to perform additional and explicit actions.


Thank You,
Mircea.

------_=_NextPart_001_01C3F431.3E973E60-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sun Feb 15 21:42:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10200 for ; Sun, 15 Feb 2004 21:42:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYhu-0001vV-5S for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 21:42:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G2g2pM007376 for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 21:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYht-0001uf-Gw; Sun, 15 Feb 2004 21:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYgx-0001mX-Od for policy@optimus.ietf.org; Sun, 15 Feb 2004 21:41:03 -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 VAA10144 for ; Sun, 15 Feb 2004 21:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsYgu-0004MJ-00 for policy@ietf.org; Sun, 15 Feb 2004 21:41:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsYg6-0004Ik-00 for policy@ietf.org; Sun, 15 Feb 2004 21:40:10 -0500 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 1AsYfk-0004EA-00 for policy@ietf.org; Sun, 15 Feb 2004 21:39:48 -0500 Received: by tconl91223.tconl.com (Postfix, from userid 500) id 5EC5B24086; Sun, 15 Feb 2004 20:39:18 -0600 (CST) From: Ryan Moats Organization: Lemur Networks, Inc. To: mpana@metasolv.com, policy@ietf.org Subject: Re: [Policy] pcimRepository and pcelsReusableContainer Date: Sun, 15 Feb 2004 20:39:16 -0600 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402152039.17639.rmoats@lemurnetworks.net> 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Sunday 15 February 2004 08:04 pm, mpana@metasolv.com wrote: > The open issue #4 listed in Appendix B) in PCELS-04 refers to the proposed > implementation for the ReusablePolicyContainer class. The authors have > reached an impasse and would appreciate input from the WG wrt. the options > presented below. I'll admit to not being an implementer of PCELS (either currently or planned). Having said that, if I were going to implement PCELS on top of my PCLS implementation, I don't really see the difference between the two approaches. The same entry could be designated both pcimRepository and pcelsReusableContainer independent of the two options. Color me confused because this really looks like a nit. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sun Feb 15 21:47:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10323 for ; Sun, 15 Feb 2004 21:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYmj-0002GC-AU for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 21:47:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G2l15Q008671 for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 21:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYmi-0002FH-Qu; Sun, 15 Feb 2004 21:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYmb-0002CR-C9 for policy@optimus.ietf.org; Sun, 15 Feb 2004 21:46:53 -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 VAA10314 for ; Sun, 15 Feb 2004 21:46:50 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsYmY-0004gk-00 for policy@ietf.org; Sun, 15 Feb 2004 21:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsYla-0004dn-00 for policy@ietf.org; Sun, 15 Feb 2004 21:45:51 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1AsYkg-0004ZM-00 for policy@ietf.org; Sun, 15 Feb 2004 21:44:54 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id <1JJRTZKZ>; Sun, 15 Feb 2004 20:43:10 -0600 Message-ID: To: policy@ietf.org Date: Sun, 15 Feb 2004 20:38:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F436.048AD6C8" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] pcelsGroup in PCELS 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F436.048AD6C8 Content-Type: text/plain; charset="iso-8859-1" We are considering the closure of the open issue regarding PolicyGroup (listed as #3) by implementing pcelsGroup as subclass of pcelsPolicySet. In your comments related to PCELS -04 please ignore the current recommendation regarding the mapping for PolicyGroup. The intent for the next revision is to recommend a mapping for PolicyGroup as follows: ...+---pcimPolicy (abstract) | | | +---pcelsPolicySet (abstract new) | | | | | +---pcelsGroup (abstract new) | | | | | | | +---pcelsGroupAuxClass (auxiliary new) | | | | | | | +---pcelsGroupInstance (structural new) | | | | | +---pcelsRule ... ... Regards, Mircea. ------_=_NextPart_001_01C3F436.048AD6C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable pcelsGroup in PCELS

We are considering the closure of the open issue = regarding PolicyGroup (listed as #3) by implementing pcelsGroup as = subclass of pcelsPolicySet. In your comments related to PCELS -04 = please ignore the current recommendation regarding the mapping for = PolicyGroup.

The intent for the next revision is to recommend a = mapping for PolicyGroup as follows:

...+---pcimPolicy (abstract)
   |   |
   |   +---pcelsPolicySet = (abstract new)
   |   |   |
   |   |   = +---pcelsGroup (abstract new)
   |   |   = |   |
   |   |   = |   +---pcelsGroupAuxClass (auxiliary new)
   |   |   = |   |
   |   |   = |   +---pcelsGroupInstance (structural new)
   |   |   = |  
   |   |   = +---pcelsRule ...
...

Regards,
Mircea.

------_=_NextPart_001_01C3F436.048AD6C8-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sun Feb 15 22:19:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11252 for ; Sun, 15 Feb 2004 22:19:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsZHo-0003rG-C0 for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 22:19:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G3J8TE014801 for policy-archive@odin.ietf.org; Sun, 15 Feb 2004 22:19:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsZHh-0003qO-M4; Sun, 15 Feb 2004 22:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsZGl-0003nb-0X for policy@optimus.ietf.org; Sun, 15 Feb 2004 22:18:03 -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 WAA11247 for ; Sun, 15 Feb 2004 22:17:59 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsZGh-0006dW-00 for policy@ietf.org; Sun, 15 Feb 2004 22:17:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsZFs-0006ae-00 for policy@ietf.org; Sun, 15 Feb 2004 22:17:08 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1AsZFV-0006WR-00 for policy@ietf.org; Sun, 15 Feb 2004 22:16:45 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id <1JJRT5BQ>; Sun, 15 Feb 2004 21:15:00 -0600 Message-ID: To: rmoats@lemurnetworks.net, mpana@metasolv.com, policy@ietf.org Subject: RE: [Policy] pcimRepository and pcelsReusableContainer Date: Sun, 15 Feb 2004 21:10:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F43A.7690099C" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F43A.7690099C Content-Type: text/plain; charset="iso-8859-1" Ryan, When it is desired for a PCELS implementation to create reusable policy definitions that can be shared with PCLS implementations, the pcelsReusableContainer instances it creates must also be pcimRepository instances. This is achieved through inheritance (option 1) or through an explicit action (option 2). Mircea. > -----Original Message----- > From: Ryan Moats [mailto:rmoats@lemurnetworks.net] > Sent: Sunday, February 15, 2004 9:39 PM > To: mpana@metasolv.com; policy@ietf.org > Subject: Re: [Policy] pcimRepository and pcelsReusableContainer > > > On Sunday 15 February 2004 08:04 pm, mpana@metasolv.com wrote: > > The open issue #4 listed in Appendix B) in PCELS-04 refers > to the proposed > > implementation for the ReusablePolicyContainer class. The > authors have > > reached an impasse and would appreciate input from the WG > wrt. the options > > presented below. > > I'll admit to not being an implementer of PCELS (either > currently or planned). > Having said that, if I were going to implement PCELS on top > of my PCLS > implementation, I don't really see the difference between the > two approaches. > The same entry could be designated both pcimRepository and > pcelsReusableContainer independent of the two options. > > Color me confused because this really looks like a nit. > > Ryan > ------_=_NextPart_001_01C3F43A.7690099C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] pcimRepository and pcelsReusableContainer

Ryan,

When it is desired for a PCELS implementation to = create reusable policy definitions that can be shared with PCLS = implementations, the pcelsReusableContainer instances it creates must = also be pcimRepository instances. This is achieved through inheritance = (option 1) or through an explicit action (option 2).

Mircea.


> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> Sent: Sunday, February 15, 2004 9:39 PM
> To: mpana@metasolv.com; policy@ietf.org
> Subject: Re: [Policy] pcimRepository and = pcelsReusableContainer
>
>
> On Sunday 15 February 2004 08:04 pm, = mpana@metasolv.com wrote:
> > The open issue #4 listed in Appendix B) in = PCELS-04 refers
> to the proposed
> > implementation for the = ReusablePolicyContainer class. The
> authors have
> > reached an impasse and would appreciate = input from the WG
> wrt. the options
> > presented below.
>
> I'll admit to not being an implementer of PCELS = (either
> currently or planned). 
> Having said that, if I were going to implement = PCELS on top
> of my PCLS
> implementation, I don't really see the = difference between the
> two approaches. 
> The same entry could be designated both = pcimRepository and
> pcelsReusableContainer independent of the two = options.
>
> Color me confused because this really looks = like a nit.
>
> Ryan
>

------_=_NextPart_001_01C3F43A.7690099C-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Feb 26 21:30:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24110 for ; Thu, 26 Feb 2004 21:30:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXlQ-0007WW-CC for policy-archive@odin.ietf.org; Thu, 26 Feb 2004 21:30:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R2U8VG028890 for policy-archive@odin.ietf.org; Thu, 26 Feb 2004 21:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXlL-0007VM-Ah; Thu, 26 Feb 2004 21:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXlG-0007UT-J6 for policy@optimus.ietf.org; Thu, 26 Feb 2004 21:29:58 -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 VAA24065 for ; Thu, 26 Feb 2004 21:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwXlD-0007ck-00 for policy@ietf.org; Thu, 26 Feb 2004 21:29:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwXkI-0007VO-00 for policy@ietf.org; Thu, 26 Feb 2004 21:28:58 -0500 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1AwXjM-0007Iq-00 for policy@ietf.org; Thu, 26 Feb 2004 21:28:00 -0500 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6649030 for policy@ietf.org; Thu, 26 Feb 2004 21:27:52 -0500 Message-Id: <5.1.0.14.0.20040226212351.019422a0@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Feb 2004 21:27:50 -0500 To: policy@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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=none autolearn=no version=2.60 Subject: [Policy] Working Group direction 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: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Congratulations to the authors of PCLS. It is now RFC 3703. With that completed, all of the pending items that are going to get done in our charter are complete. In the near future Ed and I will be asking Bert to close the working group. (We will give the Policy Extensions LDAP Schema folks a little while to get out one more revision.) Yours, Joel M. Halpern _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy