From exim@www1.ietf.org Thu Apr 1 21:15:23 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 VAA23631 for ; Thu, 1 Apr 2004 21:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Cu7-00062O-Qa for policy-archive@odin.ietf.org; Thu, 01 Apr 2004 19:51:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i320pRUX023204 for policy-archive@odin.ietf.org; Thu, 1 Apr 2004 19:51:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9AAj-0007Xs-SU; Thu, 01 Apr 2004 16:56:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95d9-0001Q4-Ra for policy@optimus.ietf.org; Thu, 01 Apr 2004 12:05:27 -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 MAA22040 for ; Thu, 1 Apr 2004 12:05:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B95cy-0001S6-00 for policy@ietf.org; Thu, 01 Apr 2004 12:05:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B95c1-0001ND-00 for policy@ietf.org; Thu, 01 Apr 2004 12:04:18 -0500 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1B95bR-0001IX-00 for policy@ietf.org; Thu, 01 Apr 2004 12:03:41 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 6802045 for policy@ietf.org; Thu, 01 Apr 2004 12:03:39 -0500 Message-Id: <5.1.0.14.0.20040401115500.023322b8@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 01 Apr 2004 12:03:22 -0500 To: Policy WG 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=AWL autolearn=no version=2.60 Subject: [Policy] Fwd: I-D ACTION:draft-reyes-policy-core-ext-schema-05.txt 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: , Below is the I-D announcement for the revision of the LDAP schema for the Policy Core Extensions model. The authors believe that they have addressed the many issues that were found by reviewiers in this working group. The Policy Framework chairs would like to thank the authors for their efforts on this individual contribution. We would also like to be able to tell the AD that this document, while being an individual contribution, has received working group review and the working group has no concerns about it. In order to say that, I have to bug you, the list members. Please take a look at this document. Please let the list know if you think there are problems with this. Also let the list know if you think this work accurately maps the model to LDAP. I believe that this will be the last significant revision. Of this work. This call for comments will last 2 weeks, ending 15 April, 2004. Yours, Joel M. Halpern PS: With luck, the working group will be officially closed shortly after this call completes. The mailing list will likely remain available, but Ed and I will no longer be considered chairs after that time. >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-reyes-policy-core-ext-schema-05.txt >Date: Thu, 01 Apr 2004 08:13:37 -0500 >Sender: i-d-announce-admin@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Policy Core Extension Lightweight Directory > Access Protocol Schema > Author(s) : A. Reyes, et al. > Filename : draft-reyes-policy-core-ext-schema-05.txt > Pages : 86 > Date : 2004-3-31 > >This document defines a number of changes and extensions to the > Policy Core Lightweight Directory Access Protocol (LDAP) Schema > (RFC 3703) based on the model extensions defined by the Policy Core > Information Model (PCIM) Extensions (RFC 3460). These changes and > extensions consist of new LDAP object classes and attribute types. > Some of the schema items defined in this document re-implement > existing concepts in accordance with their new semantics introduced > by RFC 3460. The other schema items implement new concepts, not > covered by RFC 3703. This document updates RFC 3703. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ext-schema-05.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-reyes-policy-core-ext-schema-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-reyes-policy-core-ext-schema-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2004-4-1081808.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-reyes-policy-core-ext-schema-05.txt > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Apr 26 02:12:16 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 CAA23103 for ; Mon, 26 Apr 2004 02:12:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzIS-0001oj-2O for policy-archive@odin.ietf.org; Mon, 26 Apr 2004 02:08:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q68qSF006972 for policy-archive@odin.ietf.org; Mon, 26 Apr 2004 02:08:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzEk-0007UO-7k; Mon, 26 Apr 2004 02:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzCS-0005jQ-JB for policy@optimus.ietf.org; Mon, 26 Apr 2004 02:02:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13359 for ; Mon, 26 Apr 2004 02:02:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHzCP-0004bd-4N for policy@ietf.org; Mon, 26 Apr 2004 02:02:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHzBT-0004P8-00 for policy@ietf.org; Mon, 26 Apr 2004 02:01:40 -0400 Received: from cosium03.intelliden.net ([12.41.186.100]) by ietf-mx with esmtp (Exim 4.12) id 1BHzAQ-00041V-01 for policy@ietf.org; Mon, 26 Apr 2004 02:00:35 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42B53.AEA0CBF0" Subject: RE: [Policy] For the record: Open Issues in PCELS-04 (all closed now) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Sun, 25 Apr 2004 23:59:48 -0600 Message-ID: Thread-Topic: [Policy] For the record: Open Issues in PCELS-04 (all closed now) Thread-Index: AcQXL96GRw8/qR+gTl+1Qt9hTOri7QUG8jXw From: "John Strassner" To: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NEW_DOMAIN_EXTENSIONS 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C42B53.AEA0CBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And for the record, I think that notes like this that document issues and their resolutions are very helpful. ;-) =20 regards, John -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]=20 Sent: Wednesday, March 31, 2004 7:43 AM To: policy@ietf.org Subject: [Policy] For the record: Open Issues in PCELS-04 (all closed now) The following section was included in the previous revision of PCELS but it has been removed in the current (-05) revision. For the record, these are the PCELS-04 Open Issues (now all closed): Appendix B: Open Issues=20 1. Should RFC 2119 be cited as normative reference? PCIM_EXT, PCLS=20 and other documents refer to RFC 2119 as an informative reference.=20 RESOLUTION: RFC2119 is cited as normative reference.=20 2. The object classes pcelsVendorVariable and pcelsVendorValue=20 defined in this document are not mapped from PCIM_EXT.=20 Pro: It is estimated that non-standard submodels and their LDAP=20 schema implementations will need to define a considerable number of=20 new PolicyVariable and PolicyValue subtypes. In order to avoid an=20 explosion of LDAP class definitions, the pcelsVendorVariable and=20 pcelsVendorValue classes introduce a value based extension mechanism=20 for handling new data types. These classes do not introduce a new=20 concept but rather a new extension mechanism for an existing concept. A similar mechanism is defined by PCIM and implemented by PCLS for=20 creating vendor specific PolicyCondition and PolicyAction entries.=20 Con: Since PCIM_EXT does not define such classes this document should not do it either. The purpose of this document this document is to=20 map the PCIM_EXT model to an LDAP schema, therefore such=20 functionality is outside its scope.=20 RESOLUTION: classes preserved=20 =20 3. PolicyGroup is not explicitly mapped to an LDAP object class.=20 Pro: Since the PolicyRule has now the capability to aggregate other=20 PolicyRule instances, this class includes the functionality of the=20 PolicyGroup. Therefore, an explicitly implementation of the=20 PolicyGroup class is unnecessary.=20 Con: The PolicyRule and the PolicyGroup have different semantics so=20 they should be defined using different classes.=20 RESOLUTION: PolicyGroup is explicitly mapped to pcelsGroup.=20 4. pcelsReusableContainer is defined as a subclass of pcimRepository. Therefore the new class is an extension to the old one, not an=20 alternative to it.=20 Pro: As a subclass of pcimRepository, pcelsReusableContainer=20 is compatible with older implementations that expect containers of=20 reusable policy elements to be implemented as pcimRepository=20 entries. The new class extends the functionality of the=20 pcimRepository class by implementing the ContainedDomain aggregation. Con: pcelsReusableContainer as subclass of pcimRepository has=20 potentially detrimental implications on Object Oriented models.=20 RESOLUTION: inheritance from pcimRepository preserved=20 5. pcelsConditionAssociation is defined as a subclass of=20 pcimRuleConditionAssociation. It extends the applicability of=20 the old class to the aggregation of PolicyContition instances as=20 components of CompoundPolicyContitions.=20 Pro: The Condition aggregation mechanism can be reused in both Rule=20 and CompoundCondition, therefore making it possible to optimize=20 their implementation.=20 Con: Mapping of the PCIM_EXT aggregations is implicit therefore more=20 difficult for some implementations to detect.=20 RESOLUTION: current implementation preserved=20 =20 ------_=_NextPart_001_01C42B53.AEA0CBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
And for the record, I think that notes like this that document = issues and=20 their resolutions are very helpful. ;-)
 

regards,
John

-----Original=20 Message-----
From: policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]
Sent: Wednesday, March 31, = 2004 7:43=20 AM
To: policy@ietf.org
Subject: [Policy] For the = record:=20 Open Issues in PCELS-04 (all closed now)

The following section was included in the previous = revision of=20 PCELS but it has been removed in the current (-05) revision. For the = record,=20 these are the PCELS-04 Open Issues (now all closed):

Appendix B: Open Issues

   1. Should RFC 2119 be cited as = normative=20 reference? PCIM_EXT, PCLS
   and = other=20 documents refer to RFC 2119 as an informative reference. =
   RESOLUTION: RFC2119 is cited as normative=20 reference.

   2. The object classes = pcelsVendorVariable and=20 pcelsVendorValue
   defined in = this document=20 are not mapped from PCIM_EXT.
   = Pro: It is=20 estimated that non-standard submodels and their LDAP
   schema implementations will need to define a = considerable=20 number of
   new PolicyVariable = and=20 PolicyValue subtypes. In order to avoid an
   explosion of LDAP class definitions, the=20 pcelsVendorVariable and
   = pcelsVendorValue=20 classes introduce a value based extension mechanism
   for handling new data types. These classes do = not=20 introduce a new
   concept but = rather a new=20 extension mechanism for an existing concept.
   A similar mechanism is defined by PCIM and = implemented by=20 PCLS for
   creating vendor = specific=20 PolicyCondition and PolicyAction entries.
  =20 Con: Since PCIM_EXT does not define such classes this document = should=20
   not do it either. The purpose of this = document=20 this document is to
   map the = PCIM_EXT=20 model to an LDAP schema, therefore such
  =20 functionality is outside its scope.
  =20 RESOLUTION: classes preserved
  =20
   3. PolicyGroup is not = explicitly mapped=20 to an LDAP object class.
   Pro: = Since the=20 PolicyRule has now the capability to aggregate other
   PolicyRule instances, this class includes the=20 functionality of the
   = PolicyGroup.=20 Therefore, an explicitly implementation of the
   PolicyGroup class is unnecessary. =
   Con: The PolicyRule and the PolicyGroup have = different=20 semantics so
   they should be = defined using=20 different classes.
   RESOLUTION:=20 PolicyGroup is explicitly mapped to pcelsGroup.

   4. pcelsReusableContainer is defined as = a=20 subclass of pcimRepository.
   = Therefore the=20 new class is an extension to the old one, not an
   alternative to it.
  =20 Pro: As a subclass of pcimRepository, pcelsReusableContainer =
   is compatible with older implementations that = expect=20 containers of
   reusable policy = elements to=20 be implemented as pcimRepository
   entries.=20 The new class extends the functionality of the
   pcimRepository class by implementing the = ContainedDomain=20 aggregation.
   Con: = pcelsReusableContainer=20 as subclass of pcimRepository has
  =20 potentially detrimental implications on Object Oriented models. =
   RESOLUTION: inheritance from = pcimRepository=20 preserved

   5. pcelsConditionAssociation is defined = as a=20 subclass of
   = pcimRuleConditionAssociation.=20 It extends the applicability of
   = the old=20 class to the aggregation of PolicyContition instances as =
   components of CompoundPolicyContitions. =
   Pro: The Condition aggregation mechanism can be = reused in=20 both Rule
   and = CompoundCondition,=20 therefore making it possible to optimize
  =20 their implementation.
   Con: = Mapping of the=20 PCIM_EXT aggregations is implicit therefore more
   difficult for some implementations to = detect.=20
   RESOLUTION: current implementation=20 preserved
  =20

------_=_NextPart_001_01C42B53.AEA0CBF0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Apr 27 22:26:06 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 WAA18012 for ; Tue, 27 Apr 2004 22:26:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIehJ-0003tq-Dd for policy-archive@odin.ietf.org; Tue, 27 Apr 2004 22:21:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3S2LHHH014990 for policy-archive@odin.ietf.org; Tue, 27 Apr 2004 22:21:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIee9-0003Tt-B2; Tue, 27 Apr 2004 22:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIecY-0003Ne-Vq for policy@optimus.ietf.org; Tue, 27 Apr 2004 22:16:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17358 for ; Tue, 27 Apr 2004 22:16:18 -0400 (EDT) From: mpana@metasolv.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIecT-0000ek-Og for policy@ietf.org; Tue, 27 Apr 2004 22:16:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIebU-0000XQ-00 for policy@ietf.org; Tue, 27 Apr 2004 22:15:19 -0400 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1BIeaW-0000KG-00 for policy@ietf.org; Tue, 27 Apr 2004 22:14:16 -0400 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Apr 2004 21:12:16 -0500 Message-ID: To: John.Strassner@intelliden.com, policy@ietf.org Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt Date: Tue, 27 Apr 2004 21:05:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42CC5.4250095C" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,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_01C42CC5.4250095C Content-Type: text/plain; charset="iso-8859-1" John, Thank you for your comments and clarifications. I've added my responses inline embedded in . Regards, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] [...] 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. Can you be more specific. The document includes several diagrams and tables. What is it missing? True, there are several diagrams and tables. However, the draft lacks an overall conceptual model. For example, if you look at RFC3060, Figure 1 shows an overview of all of the classes and their relationships. Note that there is no need to show attributes in such a picture - I'm just looking for a **visual** overview of how the different classes fit together. A more appropriate place for an overall conceptual model diagram would have been RFC3460. Such diagram is somewhat out of scope for PCELS. Wrt. the LDAP mapping of PCIMe concepts, the case studies in section 4.x include several instance diagrams that illustrate the implementation options. There are many variations and they could hardly fit in a single diagram. This being said, I am certainly not against the inclusion of an overall class diagram. So, should someone out there volunteer to make such a contribution to the document, I would gladly include it in a new revision of PCELS. [...] Fifth, why is there a pcelsRule and a pcimRule class? I do not understand the issue. Sorry for not being clearer. I understand that you wanted to create your own class (pcelsRule) because the semantics of RFC3460 were different (for PolicyRules) than those of RFC3460. I support your mentioning both in the draft, since there was feedback (e.g., from Ryan) that some implementations were still using pcimRule. However, I think that given this feedback, this draft needs some guidelines as to when one would use pcelsRule and one would use pcimRule, and what the implications of doing this are (e.g., how priority is implemented). PCELS recommends the use of pcelsRule. While the use of pcimRule is not prevented by PCELS, I do not see why this document would state any reasons in favour of this class. It is outside the scope of PCELS to make recommendations in this matter. Should RFC3460 be revised, this is where such issue should be addressed. Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, I do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is defined in PCLS True, this is addressed in Note 1 in page 27 of the draft. Looking at your class structure, since you subclassed other associations, I was surprised that you didn't subclass this one as well. This is because pcelsRule and pcimRule are siblings, and pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and policyConditionTimePeriod only. So, how do pcelsRule instances use a policyConditionTimePeriod? PCELS adopts pcimRuleValidityAssociation extending its applicability to pcelsRule. I.e. PCELS recommends the use of pcimRuleValidityAssociation instances subordinated to pcelsRule entries for associating pcimTPCAuxClass instances to a Rule. Note that PCELS also recommends that: "As result, the class pcimRuleValidityAssociation SHOULD be expected (and allowed) to have instances of pcelsRule as superior entries." This isn't a change of semantics for the pcimRuleValidityAssociation class. In a PCELS implementation, this class continues to represent the PolicyRuleValidityPeriod aggregation. Other association classes defined in PCIM are subclassed in PCELS for the purpose of extending their semantics (and for changing their names ;-) [...] - 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?). The text in section 4.1 will be revised for a better description of the mapping techniques utilised by PCELS. However, I do not understand your reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS. If you look at RFC3703, we defined two aux classes (pcimElementAuxClass and pcimSubtreesPtrAuxClass) to simplify navigation through the DIT, as well as retrieval of entries found more efficient. I think that you should take another look at the rationale behind these classes, and consider again whether they should be included in this draft. The fact that PCELS does not explicitly discuss these classes does not mean that implementations should not use them. Actually, PCELS application will likely implement them as well as pcimPolicyInstance, pcimConditionVendorAuxClass and many other PCLS classes. Are you suggesting that all these classes should be explicitly listed? IMO sections 2 and 3 of PCELS already address this issue. [...] - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They aren't listed in this table, and better be, if you are "updating" RFC 3703. The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes? Because this draft is supposed to be updating RFC3703, which means that you need to deal with classes defined in that RFC (such as pcimSubtreesPtrAuxClass) as well as your own classes. Or, at the very least, state why these classes do not need to be defined. Do we understand different things by "updates"? By "updates" we mean that PCELS makes incremental changes and additions to PCLS. So, I fail to see why PCELS should re-define classes that do not change. [...] ...means that the PolicySetComponent aggregation is realised by a pcelsPolicySetComponentList value in the aggregating pcelsPolicySet. This attribute value is a DN reference to a pcelsPolicySetAsociation entry. The pcelsPolicySetAsociation entry includes a pcelsPolicySetDN attribute value that is a reference to the aggregated pcelsPolicySet. The details are in section 5. The table only gives an overview of the mapping. OK, that makes sense, but I suggest you add a note saying "See section 5.x" so the impatient reader won't get frustrated. ;-) "4.1 Summary of Class and Association Mappings [...] The details of this mapping are discussed case by case in section 5." [...] - 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). I fail to see the issue. Good schemata are consistent. Why are these two associations only implementable via DIT containment? For ReusablePolicy, DIT containment has the best scalability (btw, PCLS does the same thing). PolicyRoleCollectionInSystem, is still open for suggestions ;-) - 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? replaced "ordered" with "coherent" (from PCIM_EXT) That's certainly better than incoherent ;-) but I don't see how this solves the problem, as the two aren't synonymous. See note at the end of section 5.1 (page 26). [...] - 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. Revised. The section defining pcelsRule for example will include the following compatibility note: "Note 2: PCELS implementations SHOULD support pcelsRule and its two subclasses and MAY also support pcimRule and its two subclasses [PCLS]. Applications that choose to support pcelsRule and its two subclasses MUST use the aggregation mechanism provided by pcelsPolicySetAssociation for aggregating policy groups or policy rules in policy rules represented as instances of pcelsRule. Applications that intend to be compatible with [PCIM_EXT] MUST support pcelsRule and its two subclasses." The last MUST contradicts the first SHOULD in the above statement; please change it to SHOULD. The first MUSt in the above statement is OK. How about replacing the last statement with: "Note that pcelsRule and its subclasses are compatible with [PCIM_EXT] while pcimRule and its subclasses are not. - 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. I fail to see a problem with "instance of ". It is obvious that it means "instance of non-abstract subclass of ". The "non-abstract subclass of" is superfluous and has been omitted in order to improve the text readabilitiy. PCLS, for instance, uses such expressions on several occasions. E.g.: (PCLS page 50 first paragraph) "instances of pcimRules". Note that "pcimRules" is not a class name. I still disagree (and with PCLS page 50 as well) - it is imprecise. Note 6 in section 5 warns the reader about the imprecise language. (page 23) - 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. I fail to see the issue. The semantics of pcelsPolicySetAssociation are context sensitive. The point is that there is a pronounced difference between an aggregation and an association. Although it is sadly commonplace to call everything an association. ;-( I would suggest changing your text to either only use "association" or only use "aggregation" in the same paragraph. ...So, would it be acceptable to call PolicySetComponent an association, when PCIMe defines it as aggregation? [...] ------_=_NextPart_001_01C42CC5.4250095C Content-Type: text/html; charset="iso-8859-1" Message
John,
 
Thank you for your comments and clarifications. I've added my responses inline embedded in <mircea2></mircea2>.
 
Regards,
Mircea.
 
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
 [...]
 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.

<mircea>Can you be more specific. The document includes several diagrams and tables. What is it missing?
</mircea>  

<js> True, there are several diagrams and tables. However, the draft lacks an overall conceptual model. For example, if you look at RFC3060, Figure 1 shows an overview of all of the classes and their relationships.  Note that there is no need to show attributes in such a picture - I'm just looking for a **visual** overview of how the different classes fit together. </js>

<mircea2>A more appropriate place for an overall conceptual model diagram would have been RFC3460. Such diagram is somewhat out of scope for PCELS. Wrt. the LDAP mapping of PCIMe concepts, the case studies in section 4.x include several instance diagrams that illustrate the implementation options. There are many variations and they could hardly fit in a single diagram.

This being said, I am certainly not against the inclusion of an overall class diagram. So, should someone out there volunteer to make such a contribution to the document, I would gladly include it in a new revision of PCELS.</mircea2> 

 

[...]

Fifth, why is there a pcelsRule and a pcimRule class?
<mircea>I do not understand the issue.
</mircea>  

<js> Sorry for not being clearer. I understand that you wanted to create your own class (pcelsRule) because the semantics of RFC3460 were different (for PolicyRules) than those of RFC3460. I support your mentioning both in the draft, since there was feedback (e.g., from Ryan) that some implementations were still using pcimRule. However, I think that given this feedback, this draft needs some guidelines as to when one would use pcelsRule and one would use pcimRule, and what the implications of doing this are (e.g., how priority is implemented). </js>

<mircea2>PCELS recommends the use of pcelsRule. While the use of pcimRule is not prevented by PCELS, I do not see why this document would state any reasons in favour of this class. It is outside the scope of PCELS to make recommendations in this matter. Should RFC3460 be revised, this is where such issue should be addressed.</mircea2> 

 Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, <mircea>I do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is defined in PCLS

</mircea>  

<js> True, this is addressed in Note 1 in page 27 of the draft. Looking at your class structure, since you subclassed other associations, I was surprised that you didn't subclass this one as well. This is because pcelsRule and  pcimRule are siblings, and pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and policyConditionTimePeriod only. So, how do pcelsRule instances use a policyConditionTimePeriod? </js> 

<mircea2>PCELS adopts pcimRuleValidityAssociation extending its applicability to pcelsRule. I.e. PCELS recommends the use of pcimRuleValidityAssociation instances subordinated to pcelsRule entries for associating pcimTPCAuxClass instances to a Rule. Note that PCELS also recommends that: "As result, the class pcimRuleValidityAssociation SHOULD be expected (and allowed) to have instances of pcelsRule as superior entries."

This isn't a change of semantics for the pcimRuleValidityAssociation class. In a PCELS implementation, this class continues to represent the PolicyRuleValidityPeriod aggregation. Other association classes defined in PCIM are subclassed in PCELS for the purpose of extending their semantics (and for changing their names ;-)</mircea2>

 

 [...]

   - 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?).
<mircea>The text in section 4.1 will be revised for a better description of the mapping techniques utilised by PCELS. However, I do not understand

your reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS.
<mircea>  

<js> If you look at RFC3703, we defined two aux classes (pcimElementAuxClass and pcimSubtreesPtrAuxClass) to simplify navigation through the DIT, as well as retrieval of entries found more efficient. I think that you should take another look at the rationale behind these classes, and consider again whether they should be included in this draft. </js> 

<mircea2>The fact that PCELS does not explicitly discuss these classes does not mean that implementations should not use them. Actually, PCELS application will likely implement them as well as pcimPolicyInstance,  pcimConditionVendorAuxClass and many other PCLS classes. Are you suggesting that all these classes should be explicitly listed? IMO sections 2 and 3 of PCELS already address this issue.</mircea2> 

 

[...]

  - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They
    aren't listed in this table, and better be, if you are "updating"
    RFC 3703.
<mircea>The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes?
</mircea> 

<js> Because this draft is supposed to be updating RFC3703, which means that you need to deal with classes defined in that RFC (such as pcimSubtreesPtrAuxClass) as well as your own classes. Or, at the very least, state why these classes do not need to be defined. </js>    

<mircea2>Do we understand different things by "updates"? By "updates" we mean that PCELS makes incremental changes and additions to PCLS. So, I fail to see why PCELS should re-define classes that do not change.</mircea2> 

 

[...]

<mircea> ...means that the PolicySetComponent aggregation is realised by a pcelsPolicySetComponentList value in the aggregating pcelsPolicySet. This attribute value is a DN reference to a pcelsPolicySetAsociation entry. The pcelsPolicySetAsociation entry includes a pcelsPolicySetDN attribute value that is a reference to the aggregated pcelsPolicySet. The details are in section 5. The table only gives an overview of the mapping.

</mircea>  

<js> OK, that makes sense, but I suggest you add a note saying "See section 5.x" so the impatient reader won't get frustrated. ;-) </js>  

<mircea2>"4.1 Summary of Class and Association Mappings

[...]   The details of this mapping are discussed case by case in section 5."</mircea2> 

 [...]

   - 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).
<mircea>I fail to see the issue.
</mircea>  

<js> Good schemata are consistent. Why are these two associations only implementable via DIT containment? </js>  

<mircea2>For ReusablePolicy, DIT containment has the best scalability (btw, PCLS does the same thing).

PolicyRoleCollectionInSystem, is still open for suggestions ;-) </mircea2> 

  - 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?
<mircea>replaced "ordered" with "coherent" (from PCIM_EXT)
</mircea>  

<js> That's certainly better than incoherent ;-) but I don't see how this solves the problem, as the two aren't synonymous. </js> 

<mircea2> See note at the end of section 5.1 (page 26).</mircea2>    

 

 [...]

   - 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.
<mircea>Revised. The section defining pcelsRule for example will include the following compatibility note:

   "Note 2: PCELS implementations SHOULD support pcelsRule and its two
   subclasses and MAY also support pcimRule and its two subclasses
   [PCLS]. Applications that choose to support pcelsRule and its two
   subclasses MUST use the aggregation mechanism provided by
   pcelsPolicySetAssociation for aggregating policy groups or policy
   rules in policy rules represented as instances of pcelsRule.
   Applications that intend to be compatible with [PCIM_EXT] MUST
   support pcelsRule and its two subclasses."

</mircea>  

<js> The last MUST contradicts the first SHOULD in the above statement; please change it to SHOULD. The first MUSt in the above statement is OK. </js> 

<mircea2> How about replacing the last statement with: "Note that pcelsRule and its subclasses are compatible with [PCIM_EXT] while pcimRule and its subclasses are not.</mircea2>

  

  - 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.
<mircea> I fail to see a problem with "instance of <abstract_class>". It is obvious that it means "instance of non-abstract subclass of <abstract_class>". The "non-abstract subclass of" is superfluous and has been omitted in order to improve the text readabilitiy. PCLS, for instance, uses such expressions on several occasions. E.g.: (PCLS page 50 first paragraph) "instances of pcimRules". Note that "pcimRules" is not a class name.

</mircea>  

<js> I still disagree (and with PCLS page 50 as well) - it is imprecise. </js>  

<mircea2> Note 6 in section 5 warns the reader about the imprecise language. (page 23)</mircea2> 

  - 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.
<mircea>I fail to see the issue. The semantics of pcelsPolicySetAssociation are context sensitive.
</mircea>  

<js> The point is that there is a pronounced difference between an aggregation and an association. Although it is sadly commonplace to call everything an association. ;-( I would suggest changing your text to either only use "association" or only use "aggregation" in the same paragraph. </js>  

<mircea2>...So, would it be acceptable to call PolicySetComponent an association, when PCIMe defines it as aggregation?</mircea2> 

[...]

------_=_NextPart_001_01C42CC5.4250095C-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy