From exim@www1.ietf.org  Wed May  5 15:55:36 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08406
	for <policy-archive@odin.ietf.org>; Wed, 5 May 2004 15:55:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLSPc-0006UZ-9r
	for policy-archive@odin.ietf.org; Wed, 05 May 2004 15:50:37 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Joaqp024952
	for policy-archive@odin.ietf.org; Wed, 5 May 2004 15:50:36 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLSEP-0001oy-3t; Wed, 05 May 2004 15:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BHzCR-0005hH-DS
	for policy@optimus.ietf.org; Mon, 26 Apr 2004 02:02:39 -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 CAA13339
	for <policy@ietf.org>; Mon, 26 Apr 2004 02:02:36 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BHzCN-0004bP-QG
	for policy@ietf.org; Mon, 26 Apr 2004 02:02:35 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BHzBN-0004Oy-00
	for policy@ietf.org; Mon, 26 Apr 2004 02:01:39 -0400
Received: from cosium03.intelliden.net ([12.41.186.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BHzAQ-00041V-00
	for policy@ietf.org; Mon, 26 Apr 2004 02:00:34 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C42B53.AE30CC10"
Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Date: Sun, 25 Apr 2004 23:59:47 -0600
Message-ID: <AE723009E85E224CB00132C7FF0B34E1F33DFE@cosium02.intelliden.net>
Thread-Topic: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt
Thread-Index: AcQUKc5Rt4ZRSr0JSji/8NQ2XLWjZQXDwBCA
From: "John Strassner" <John.Strassner@intelliden.com>
To: <mpana@metasolv.com>, <policy@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_20_30,
	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: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C42B53.AE30CC10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Mircea,
=20
thanks for addressing these issues, and apologies for the delay in
response. Please see inline (<js>..</js>) for clarifications.
=20

regards,
John

-----Original Message-----
From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]=20
Sent: Thursday, March 25, 2004 7:59 PM
To: John Strassner; policy@ietf.org
Subject: RE: [Policy] FW: I-D
ACTION:draft-reyes-policy-core-ext-schema-04 .txt



John,=20

I have reviewed your comments in detail and made several changes to the
PCELS text (to be submitted in a few days) to address these issues.
While for the most part I understand your concerns, there are a few
items that I would like to discuss in more detail. See my comments below
marked <mircea></mircea>.

Thank You,=20
Mircea.=20

-----Original Message-----=20
From: John Strassner [mailto:John.Strassner@intelliden.com]=20
Sent: Friday, February 13, 2004 9:32 PM=20
To: 'mpana@metasolv.com'; 'policy@ietf.org'=20
Subject: RE: [Policy] FW: I-D
ACTION:draft-reyes-policy-core-ext-schema-04 .txt=20


First, I support Kurt's comments on LDAP, and will reply to those in a
separate email.=20
<mircea>Kurt's recommendations will be addressed in the next revision.=20
</mircea>=20

Second, I list below a set of additional comments on this draft.=20

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?=20
</mircea> =20

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

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?

<mircea>pcelsGroup will be added in the new revision.=20
</mircea>=20

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

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

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> =20

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

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.

<mircea>Acknowledgments will be added in the new revision.=20
</mircea>=20

Comments are as follows:=20

  - s/RFC zzzz/RFC 3703=20
<mircea>Fixed.=20
</mircea>=20
 =20
  - page 3. You write: "...the combined class hierarchy for the LDAP=20
    object classes defined in [PCLS] and in this document". You should=20
    include concepts from 3460 that you mapped into new classes, and=20
    add that you defined new classes not in 3460 or 3703.=20
<mircea>Fixed.=20
</mircea>=20

  - page 4-7, class diagram - this diagram has no caption. Please add=20
    one. In addition, I find the diagram inpenetrable, in that the=20
    reader has no idea where these classes came from. I think you need=20
    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=20
    that isn't new in this document, where it came from.=20
<mircea>Fixed.=20
</mircea>=20

  - page 4 - why is your class named pcelsFilerEntry, when 3460 names=20
    its class FilterEntryBase?=20
  - page 4 - why is your class named pcelsIPHeaders, when 3460 names=20
    its class IPHeadersFilter? The Filter part is important!=20
  - page 4 - why is your class named pcels8021Headers, when 3460 names=20
    its class 8021Filter? The Filter part is important!=20
  - page 4 - why is your class named pcelsCompoundFilterAuxClass, when=20
    a more consistent name would be
pcelsCompoundFilterConditionAuxClass?=20
    The Condition part is important!=20
<mircea>All renamed.=20
</mircea>=20

   - general reflections on the class diagram: part of the problem is
that=20
    you are building a schema from three different sources: (1) RFC
3703,=20
    (2) RFC 3460, and (3) your own additions. I see no discussion on how

    these relate to each other, which would have been helpful.=20
<mircea>The new revision will indicate all these sources explicitly.=20
</mircea>=20

   - page 7 - you didn't state whether this is for all associations.
This=20
    is exacerbated by you saying: "...might need to implement the=20
    association..." - which implies a single association. In addition,=20
    this is a terse description - the naive reader won't understand why=20
    aux classes are being used - you need a reference or a couple of=20
    sentences explaining this.=20
<mircea>Added example in support of the generic text. Please note that
the reader is not going to be that naive. Section 2. ("Relationship to
other Policy Framework Documents") will also indicate that "These three
documents ([PCIM], [PCIM_EXT] and [PCLS]) are a prerequisite for reading
and understanding this document."

</mircea>=20

  - page 7 - you state: "The LDAP object classes defined in this
document=20
    are a direct mapping from the corresponding classes and, in some=20
    cases, the associations defined in [PCIM_EXT] ". Not strictly true,=20
    as you are also seeking to update RFC 3703 (e.g., where is=20
    pcimSubtreesPtrAuxClass defined in RFC 3460?).=20
<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=20

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

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

  - pages 8-11: your table has no caption=20
<mircea>Fixed.=20
</mircea>=20

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

<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> =20

  - once again, I see lots of irksome naming issues. The LDAP schema=20
    shouldn't change the name of a class defined in another RFC. Why=20
    have you done this?=20
<mircea>All are going to be renamed to follow the *exact* PCIM_EXT
names, but I fail to see where is the problem with the old names.

</mircea> =20

<js> It's all about implementation ease. If an earlier RFC exists, the
naming in that RFC should be respected and not changed. </js>=20

  - 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?=20
<mircea>pcelsGroup will be added in the new revision.=20
</mircea>=20

  - page 10, 1st row. How can a single info model association map to=20
    two different associations? And do you mean "and" in this row? This=20
    would mean that I would have to instantiate both pcelsPolicySet=20
    and pcelsPolicySetAssociation, which is clearly wrong. This comment=20
    also applies for the other rows on this page where you have "and".=20
<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> =20

<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>=20

  - page 10 - it is of no help to say "see PolicySetInSystem" in this=20
    table for the 3rd and 4th rows - that only confuses the reader.=20
    Please spell out what you mean here.=20
<mircea>Fixed. Details are in section 5.=20
</mircea>=20

  - Page 11 - the reader will wonder why ReusablePolicy and=20
    PolicyRoleCollectionInSystem are only implementable via DIT=20
    containment, when every other association has an association defined

    (independent of whether DIT containment could be used).=20
<mircea>I fail to see the issue.=20
</mircea> =20

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

  - Section 4.2, line 3, you write: "The concept of an ordered set of=20
    policies...". LDAP doesn't have ordered sets. How are you going to=20
    implement this?=20
<mircea>replaced "ordered" with "coherent" (from PCIM_EXT)=20
</mircea> =20

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

  - Page 13, Section 4.3, second paragraph - s/deprecates/deprecate=20
<mircea>Fixed.=20
</mircea>=20

  - Page 13, Note - actually, PCLS does NOT have anything to do with=20
    PCIMe, so this note needs to be reworded=20
<mircea>Fixed.=20
</mircea>=20

  - Page 14, Section 4.5=20
    - s/an other/another (and other places)=20
    - s/"rule /group"/"rule/group" (5 places) (and other places)=20
<mircea>Fixed.=20
</mircea>=20

  - Page 16, section 4.6,=20
    - s/CompoundPolicyActionclasses/CompoundPolicyAction classes=20
    - conditions /actions/"conditions/actions" (and other places)=20
<mircea>Fixed.=20
</mircea>=20

  - Page 22. How are you going to enforce an "ordered set of=20
    rules /groups"? That is, how can you guarantee that the DSA stores=20
    your rules/groups [sic] in the order that you want, and where is=20
    that order specified? What if a DSA doesn't have ordering controls?=20
  - Same section as above - you say that the "association entries enable

    relative ordering of the aggregated pcelsPolicySet instances within=20
    the scope of the aggregating pcelsPolicySet" - how is this=20
    accomplished with a plain, vanilla LDAP server with no controls?=20
<mircea>Text revised and note added to indicate that applications must
not expect the LDAP data store to implement sorting and ordering.

</mircea>=20

  - Page 23 - the DESC for pcelsPolicySetList should say that it=20
    contains an UNORDERED list of DN references.=20
<mircea>Fixed.=20
</mircea>=20

  - Page 23, note above Section 5.2, is slightly incorrect. Only those=20
    implementations that WANT TO BE COMPATIBLE WITH PCELS should use=20
    this aggregation mechanism instead of those defined by PCLS. Not=20
    every implementation mechanism is going to want to change.=20
<mircea>Revised. The section defining pcelsRule for example will include
the following compatibility note:=20

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

</mircea> =20

<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>=20

  - Page 23, Section 5.2, says "The pcelsPolicySetAssociation class is=20
    used to aggregate instances of pcelsPolicySet into other entries."=20
    This is incorrect, as pcelsPolicySet is abstract and thus cannot be=20
    instantiated.=20
<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> =20

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

  - Same section, you write: "...realizes a (subclass of)=20
    PolicySetComponent aggregation [sic]. When subordinated to (subclass

    of) dlm1System...realizes a PolicySetInSystem association [sic]".=20
    How can the same element realize an aggregation in one usage and an=20
    association in another usage? This is semantically inconsistent.=20
<mircea>I fail to see the issue. The semantics of
pcelsPolicySetAssociation are context sensitive.=20
</mircea> =20

<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>=20

  - Next paragraph says: "A non-reusable instance of (subclass of)=20
    pcelsPolicySet is attached as auxiliary class directly to the=20
    pcelsPolicySetAssociation entry." Subclasses of pcelsPolicySet that=20
    are not abstract are pcelsRuleAuxClass and pcelsRuleInstance. The=20
    above sentence only makes sense for pcelsRuleAuxClass.=20
<mircea>The new specification will include pcelsGroup as well. As
result, the current text will make more sense.=20
</mircea>=20

  - Next paragraph doesn't make sense. First, you clearly mean a non-=20
    abstract subclass of pcelsPolicySet. Second, you are recommending=20
    that an ERROR be ignored? Why don't you stop operation?=20
<mircea>Revised text:=20

   "When reading a pcelsPolicySetAssociation instance that has a=20
   pcelsPolicySet attached, the attribute pcelsPolicySetDN MUST=20
   be ignored. Applications SHOULD remove the pcelsPolicySetDN value=20
   from a pcelsPolicySetAssociation upon attachment of a pcelsPolicySet=20
   to the entry."=20

This gives applications some flexibility.=20
</mircea> =20

<js> That's much better </js>=20

  - Page 24, DESC of pcelsPriority is insufficient, as "0" has special=20
    semantics that you haven't mentioned. This should, of course, also=20
    be present in accompanying prose, as Kurt points out.=20
<mircea>The PCIM_EXT property and the attribute value restrictions going
to be described in more detail (in prose). However I fail to find the
meaning of "0" in PCIM_EXT. Can you help me locate the text?

</mircea> =20

<js> My mistake, the RFC states that this is simply the default value.
</js>=20

  - Page 24, DESC of pcelsPolicySetDN should state that this is an=20
    UNORDERED list of DNs.=20
<mircea>Fixed.=20
</mircea>=20

  - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule=20
    Class and Its Subclasses=20
<mircea>Fixed.=20
</mircea>=20

<note: at this point I'm not going to correct any remaining grammar=20
 errors, such as the next line ("The pcelsRule is...") because there=20
 are too many of them.>=20
  - Page 24, Section 5.3, you say: "The pcelsRule is the base class=20
    representing policy rules." Does this mean that an implementation=20
    can NOT use the subclasses of pcimRule anymore?=20
<mircea>I fail to see the issue.=20
</mircea>=20

  - Page 24, next paragraph, you say: "This class shares the=20
    Condition/Action aggregation methods with the=20
    pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass=20
    object classes.". Why does it also not share the=20
    pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass=20
    object classes as well?=20
<mircea>Revised text. It was actually trying to say that:=20

"   Like pcelsRule, instances of pcelsCompoundConditionAuxClass use=20
   pcelsConditionList values and subordinated pcelsConditionAssociation=20
   entries to aggregate policy conditions."=20
and=20
"   Like pcelsRule, instances of pcelsCompoundActionAuxClass use=20
   pcelsActionList values and subordinated pcelsActionAssociation=20
   entries to aggregate policy actions."=20
</mircea>=20

  - Page 25, top paragraph, again says that the implementer should
ignore=20
    an error condition. This isn't a good idea.=20
  - Page 25, next paragraph has the same problem.=20
<mircea>Already discussed=20
</mircea>=20

  - Page 26, the pcelsConditionListType attribute has a constraint. No=20
    text is provided that instructs the implementer what to do, aside=20
    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.=20
Note that this is a systemic problem with any constrained attribute=20
defined in this draft. Thus, I will only mention this once.=20
<mircea>All Fixed.=20
</mircea>=20

  - Page 27, WHY isn't a PolicyGroup class implemented? You give no=20
    reason for not doing this. Note also that Note 2 talks about ORDERED

    policy rules - I don't see how you can construct those.=20
<mircea>Already discussed=20
</mircea>=20

  - Page 27, section 5.4, again you say "pcelsRule" instead of "non-=20
    abstract subclasses of pcelsRule".=20
<mircea>Already discussed=20
</mircea>=20

  - Page 28, top paragraph, another error that you are recommending=20
    should be ignored=20
<mircea>Already discussed=20
</mircea>=20

  - Page 28, DESC for pcelsConditionAssociation is wrong; you say that=20
    it can be used for a pcelsRule instead of a non-abstract subclass of

    pcelsRule=20
<mircea>Already discussed=20
</mircea>=20

  - Page 28, section 5.5, again you say "pcelsRule" instead of "non-=20
    abstract subclasses of pcelsRule".=20
<mircea>Already discussed=20
</mircea>=20

   - Page 28, last paragraph, another error that you are recommending=20
    should be ignored.=20
<mircea>Already discussed=20
</mircea>=20

   - Page 29, DESC for pcelsActionAssociation is wrong; you say that=20
    it can be used for a pcelsRule instead of a non-abstract subclass of

    pcelsRule=20
<mircea>Already discussed=20
</mircea>=20

   - Page 29, last paragraph above Section 5.6, another error that you
are=20
    recommending should be ignored.=20
<mircea>Already discussed=20
</mircea>=20

   - Page 29, Section 5.6, last two paragraphs are errors that you are=20
    recommending should be ignored.=20
<At this point, I'm going to stop listing these, as it is a systemic
problem that should be fixed in the next release>=20
<mircea>Already discussed=20
</mircea>=20

   - Page 29, last paragraph above Section 5.6, another error that you
are=20
    recommending should be ignored.=20
<mircea>Already discussed=20
</mircea>=20

   - Page 30, the DESC for pcelsVariableDN is wrong. You say that it is
a=20
    "DN reference to a pcelsVariable entry", when it should be a DN=20
    reference to a subclass of either pcelsExplicitVariableAuxClass or=20
    pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass=20
<mircea>Already discussed=20
</mircea>=20

   - Page 30, the DESC for pcelsValueDN is wrong - it should be a
subclass=20
    of pcelsValueDN.=20
<mircea>Already discussed=20
</mircea>=20



regards,=20
John=20



------_=_NextPart_001_01C42B53.AE30CC10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>Hi Mircea,</FONT></SPAN></DIV>
<DIV><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>thanks for addressing these issues, and apologies for the delay =
in=20
response. Please see inline (&lt;js&gt;..&lt;/js&gt;) for=20
clarifications.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
<P dir=3Dltr align=3Dleft><FONT face=3D"Times New Roman"><FONT=20
size=3D3>regards,<BR>John</FONT></FONT></P>
<P dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2>-----Original=20
Message-----<BR><B>From:</B> policy-admin@ietf.org=20
[mailto:policy-admin@ietf.org] <BR><B>Sent:</B> Thursday, March 25, 2004 =
7:59=20
PM<BR><B>To:</B> John Strassner; policy@ietf.org<BR><B>Subject:</B> RE: =
[Policy]=20
FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04=20
.txt<BR><BR></P></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>John,</FONT> </P>
  <P><FONT size=3D2>I have reviewed your comments in detail and made =
several=20
  changes to the PCELS text (to be submitted in a few days) to address =
these=20
  issues. While for the most part I understand your concerns, there are =
a few=20
  items that I would like to discuss in more detail. See my comments =
below=20
  marked &lt;mircea&gt;&lt;/mircea&gt;.</FONT></P>
  <P><FONT size=3D2>Thank You,</FONT> <BR><FONT size=3D2>Mircea.</FONT> =
</P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: John=20
  Strassner [<A=20
  =
href=3D"mailto:John.Strassner@intelliden.com">mailto:John.Strassner@intel=
liden.com</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Friday, February 13, 2004 9:32 PM</FONT> =
<BR><FONT=20
  size=3D2>To: 'mpana@metasolv.com'; 'policy@ietf.org'</FONT> <BR><FONT=20
  size=3D2>Subject: RE: [Policy] FW: I-D=20
  ACTION:draft-reyes-policy-core-ext-schema-04 .txt</FONT> </P><BR>
  <P><FONT size=3D2>First, I support Kurt's comments on LDAP, and will =
reply to=20
  those in a separate email. </FONT><BR><FONT =
size=3D2>&lt;mircea&gt;Kurt's=20
  recommendations will be addressed in the next revision.</FONT> =
<BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>Second, I list below a set of additional comments on =
this=20
  draft.</FONT> </P>
  <P><FONT size=3D2>Third, the lack of an overall diagram makes it very =
difficult=20
  to evaluate the correctness of this model. This draft is not complete =
enough=20
  to construct such a model.</FONT></P>
  <P><FONT size=3D2>&lt;mircea&gt;Can you be more specific. The document =
includes=20
  several diagrams and tables. What is it missing?</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;&nbsp;<SPAN class=3D745254702-26042004><FONT=20
  face=3D"Courier New" color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT =
face=3D"Courier New"=20
  color=3D#0000ff>&lt;js&gt; True, there are several diagrams and =
tables. However,=20
  the draft lacks an overall conceptual model. For example, if you look =
at=20
  RFC3060,&nbsp;Figure 1 shows an overview of&nbsp;all of the classes =
and their=20
  relationships.</FONT>&nbsp;<FONT face=3D"Courier New" color=3D#0000ff> =
Note that=20
  there is no need to show attributes in such a picture - I'm just =
looking for a=20
  **visual** overview of how the different classes fit together.=20
  &lt;/js&gt;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2>Fourth, a cursory scan revealed that there is no=20
  pcelsPolicyGroup class. This is strange, since PolicyGroup is listed =
as a=20
  subclass of PolicySet in RFC 3460. Why is this?</FONT></P>
  <P><FONT size=3D2>&lt;mircea&gt;pcelsGroup will be added in the new=20
  revision.</FONT> <BR><FONT size=3D2>&lt;/mircea&gt; </FONT></P>
  <P><FONT size=3D2>Fifth, why is there a pcelsRule and a pcimRule =
class?</FONT>=20
  <BR><FONT size=3D2>&lt;mircea&gt;I do not understand the issue.</FONT> =
<BR><FONT=20
  size=3D2>&lt;/mircea&gt;&nbsp;<SPAN class=3D745254702-26042004><FONT=20
  face=3D"Courier New" color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT =
face=3D"Courier New"=20
  color=3D#0000ff>&lt;js&gt; Sorry for not being clearer. I understand =
that you=20
  wanted to create your own class (pcelsRule) because the semantics of =
RFC3460=20
  were different&nbsp;(for PolicyRules) than those of RFC3460. I support =
your=20
  mentioning both in the draft, since there was feedback (e.g., from =
Ryan) that=20
  some implementations were still using pcimRule. However, I think that =
given=20
  this feedback, this draft needs some&nbsp;guidelines as to when one =
would use=20
  pcelsRule and one would use pcimRule, and what the implications of =
doing this=20
  are (e.g., how priority is implemented). =
&lt;/js&gt;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2>Sixth, why is there no pcelsRuleValidityAssociation =
subclass?=20
  At this point, &lt;mircea&gt;I do not understand the issue. PCELS =
reuses=20
  pcimRuleValidityAssociation that is defined in PCLS</FONT></P>
  <P><FONT size=3D2>&lt;/mircea&gt;&nbsp;<SPAN =
class=3D745254702-26042004><FONT=20
  face=3D"Courier New" color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT =
face=3D"Courier New"=20
  color=3D#0000ff>&lt;js&gt; True, this is addressed in Note 1 in page =
27 of the=20
  draft. Looking at your class structure, since you subclassed other=20
  associations, I&nbsp;was surprised that you didn't subclass this one =
as well.=20
  This is because pcelsRule and </FONT>&nbsp;<FONT face=3D"Courier New"=20
  color=3D#0000ff>pcimRule are siblings, and pcimRuleValidityPeriod (in =
PCIM) is=20
  defined to exist between pcimRule and policyConditionTimePeriod only. =
So, how=20
  do pcelsRule instances use a policyConditionTimePeriod?=20
  &lt;/js&gt;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2>I started to go through the document in detail with =
my=20
  developers to try and implement it. We couldn't. We give you =
inconsistencies=20
  that we noticed (grammatical and otherwise) through page =
31).</FONT></P>
  <P><FONT size=3D2>Finally, I was surprised to see a lack of an =
Acknowledgments=20
  section, especially given the amount of feedback that several people =
on this=20
  list gave the authors. That's in poor form.</FONT></P>
  <P><FONT size=3D2>&lt;mircea&gt;Acknowledgments will be added in the =
new=20
  revision.</FONT> <BR><FONT size=3D2>&lt;/mircea&gt; </FONT></P>
  <P><FONT size=3D2>Comments are as follows:</FONT> </P>
  <P><FONT size=3D2>&nbsp; - s/RFC zzzz/RFC 3703</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Fixed.</FONT> <BR><FONT =
size=3D2>&lt;/mircea&gt;</FONT>=20
  <BR><FONT size=3D2>&nbsp;</FONT> <BR><FONT size=3D2>&nbsp; - page 3. =
You write:=20
  "...the combined class hierarchy for the LDAP </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; object classes defined in [PCLS] and in =
this=20
  document". You should</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
include=20
  concepts from 3460 that you mapped into new classes, and</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; add that you defined new classes not in =
3460 or=20
  3703.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Fixed.</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - page 4-7, class diagram - this diagram has =
no=20
  caption. Please add</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; one. =
In=20
  addition, I find the diagram inpenetrable, in that the</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; reader has no idea where these classes =
came from. I=20
  think you need</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; a simpler=20
  introduction saying 3060 provided this, 3460 did this, and</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; thus we came up with this. Take this key =
and show,=20
  for any class </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; that isn't =
new in=20
  this document, where it came from.</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Fixed.</FONT> <BR><FONT =
size=3D2>&lt;/mircea&gt;</FONT>=20
</P>
  <P><FONT size=3D2>&nbsp; - page 4 - why is your class named =
pcelsFilerEntry,=20
  when 3460 names</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; its class =

  FilterEntryBase?</FONT> <BR><FONT size=3D2>&nbsp; - page 4 - why is =
your class=20
  named pcelsIPHeaders, when 3460 names</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; its class IPHeadersFilter? The Filter part =
is=20
  important! </FONT><BR><FONT size=3D2>&nbsp; - page 4 - why is your =
class named=20
  pcels8021Headers, when 3460 names</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  its class 8021Filter? The Filter part is important!</FONT> <BR><FONT=20
  size=3D2>&nbsp; - page 4 - why is your class named =
pcelsCompoundFilterAuxClass,=20
  when </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; a more consistent =
name would=20
  be pcelsCompoundFilterConditionAuxClass?</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; The Condition part is important!</FONT> =
<BR><FONT=20
  size=3D2>&lt;mircea&gt;All renamed.</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - general reflections on the class =
diagram: part=20
  of the problem is that</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
you are=20
  building a schema from three different sources: (1) RFC 3703,</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; (2) RFC 3460, and (3) your own additions. =
I see no=20
  discussion on how</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; these =
relate to=20
  each other, which would have been helpful.</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;The new revision will indicate all these =
sources=20
  explicitly.</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - page 7 - you didn't state whether =
this is for=20
  all associations. This</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; is =

  exacerbated by you saying: "...might need to implement the =
</FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; association..." - which implies a single=20
  association. In addition,</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
this is a=20
  terse description - the naive reader won't understand why</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; aux classes are being used - you need a =
reference or=20
  a couple of</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; sentences =
explaining=20
  this.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Added example in support =
of the=20
  generic text. Please note that the reader is not going to be that =
naive.=20
  Section 2. ("Relationship to other Policy Framework Documents") will =
also=20
  indicate that "These three documents ([PCIM], [PCIM_EXT] and [PCLS]) =
are a=20
  prerequisite for reading and understanding this document."</FONT></P>
  <P><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - page 7 - you state: "The LDAP object =
classes defined=20
  in this document</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; are a =
direct=20
  mapping from the corresponding classes and, in some </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; cases, the associations defined in =
[PCIM_EXT] ". Not=20
  strictly true, </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; as you are =
also=20
  seeking to update RFC 3703 (e.g., where is </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; pcimSubtreesPtrAuxClass defined in RFC=20
  3460?).</FONT> <BR><FONT size=3D2>&lt;mircea&gt;The text in section =
4.1 will be=20
  revised for a better description of the mapping techniques utilised by =
PCELS.=20
  However, I do not understand </FONT></P>
  <P><FONT size=3D2>your reference to pcimSubtreesPtrAuxClass. That =
class is not=20
  defined in PCELS.</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; If you look at RFC3703, we defined two aux classes =

  (pcimElementAuxClass and pcimSubtreesPtrAuxClass) to simplify =
navigation=20
  through the DIT, as well as retrieval of entries found more efficient. =
I think=20
  that you should take another look at the rationale behind these =
classes, and=20
  consider again whether they should be included in this draft.=20
  &lt;/js&gt;</FONT></SPAN></P>
  <P><FONT size=3D2>&nbsp; - pages 8-11: your table has no =
caption</FONT>=20
  <BR><FONT size=3D2>&lt;mircea&gt;Fixed.</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - pages 8-11: Where are classes like=20
  pcimSubtreesPtrAuxClass? They</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  aren't listed in this table, and better be, if you are =
"updating"</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; RFC 3703.</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;The two tables list PCIM_EXT classes mapped by =
PCELS. Why=20
  should the tables include PCLS classes?</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;<SPAN class=3D745254702-26042004><FONT =
face=3D"Courier New"=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT =
face=3D"Courier New"=20
  color=3D#0000ff>&lt;js&gt; Because this draft is supposed to be=20
  updating&nbsp;RFC3703, which means that you need to deal with classes =
defined=20
  in that&nbsp;RFC&nbsp;(such as pcimSubtreesPtrAuxClass) as well as =
your own=20
  classes. Or, at the very least, state why these classes do not need to =
be=20
  defined. &lt;/js&gt;</FONT>&nbsp;</SPAN></FONT><SPAN=20
  class=3D745254702-26042004>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - once again, I see lots of irksome naming =
issues. The=20
  LDAP schema</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; shouldn't =
change the=20
  name of a class defined in another RFC. Why</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; have you done this?</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;All are going to be renamed to follow the =
*exact*=20
  PCIM_EXT names, but I fail to see where is the problem with the old=20
  names.</FONT></P>
  <P><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; It's all about implementation ease.&nbsp;If an =
earlier RFC=20
  exists, the naming in that RFC should be respected and not changed.=20
  &lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - page 8, 4th row. How can you give two =
different=20
  mappings to a single</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
object class?=20
  And how can a RULE (i.e., pcelsRule) map to a GROUP?</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;pcelsGroup will be added in the new =
revision.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt; </FONT></P>
  <P><FONT size=3D2>&nbsp; - page 10, 1st row. How can a single info =
model=20
  association map to</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; two =
different=20
  associations? And do you mean "and" in this row? This</FONT> <BR><FONT =

  size=3D2>&nbsp;&nbsp;&nbsp; would mean that I would have to =
instantiate both=20
  pcelsPolicySet</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; and=20
  pcelsPolicySetAssociation, which is clearly wrong. This comment</FONT> =

  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; also applies for the other rows =
on this=20
  page where you have "and".</FONT> <BR><FONT size=3D2>&lt;mircea&gt; =
...means=20
  that the PolicySetComponent aggregation is realised by a=20
  pcelsPolicySetComponentList value in the aggregating pcelsPolicySet. =
This=20
  attribute value is a DN reference to a pcelsPolicySetAsociation entry. =
The=20
  pcelsPolicySetAsociation entry includes a pcelsPolicySetDN attribute =
value=20
  that is a reference to the aggregated pcelsPolicySet. The details are =
in=20
  section 5. The table only gives an overview of the mapping.</FONT></P>
  <P><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; OK, that makes sense, but I suggest you add a note =
saying=20
  "See&nbsp;section 5.x" so the impatient reader won't get frustrated. =
;-)=20
  &lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - page 10 - it is of no help to say "see=20
  PolicySetInSystem" in this</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp; table=20
  for the 3rd and 4th rows - that only confuses the reader.</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; Please spell out what you mean =
here.</FONT>=20
  <BR><FONT size=3D2>&lt;mircea&gt;Fixed. Details are in section =
5.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 11 - the reader will wonder why =
ReusablePolicy=20
  and </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
PolicyRoleCollectionInSystem=20
  are only implementable via DIT </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  containment, when every other association has an association =
defined</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; (independent of whether DIT =
containment=20
  could be used).</FONT> <BR><FONT size=3D2>&lt;mircea&gt;I fail to see =
the=20
  issue.</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; Good schemata are consistent.&nbsp;Why are these =
two=20
  associations&nbsp;only implementable via DIT containment?=20
  &lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - Section 4.2, line 3, you write: "The =
concept of an=20
  ordered set of</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
policies...". LDAP=20
  doesn't have ordered sets. How are you going to</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; implement this?</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;replaced "ordered" with "coherent" (from =
PCIM_EXT)</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; That's certainly better than incoherent ;-) but I =
don't see=20
  how this solves the problem, as the two aren't synonymous.=20
  &lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - Page 13, Section 4.3, second paragraph -=20
  s/deprecates/deprecate</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Fixed.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 13, Note - actually, PCLS does NOT =
have anything=20
  to do with</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; PCIMe, so this =
note=20
  needs to be reworded</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Fixed.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 14, Section 4.5</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; - s/an other/another (and other =
places)</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; - s/"rule /group"/"rule/group" =
(5 places)=20
  (and other places)</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Fixed.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 16, section 4.6, </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; - =
s/CompoundPolicyActionclasses/CompoundPolicyAction=20
  classes </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; - conditions=20
  /actions/"conditions/actions" (and other places)</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Fixed.</FONT> <BR><FONT =
size=3D2>&lt;/mircea&gt;</FONT>=20
</P>
  <P><FONT size=3D2>&nbsp; - Page 22. How are you going to enforce an =
"ordered set=20
  of </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; rules /groups"? That =
is, how can=20
  you guarantee that the DSA stores</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  your rules/groups [sic] in the order that you want, and where =
is</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; that order specified? What if a =
DSA=20
  doesn't have ordering controls?</FONT> <BR><FONT size=3D2>&nbsp; - =
Same section=20
  as above - you say that the "association entries enable =
</FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; relative ordering of the aggregated =
pcelsPolicySet=20
  instances within </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; the =
scope of the=20
  aggregating pcelsPolicySet" - how is this </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; accomplished with a plain, vanilla LDAP =
server with=20
  no controls?</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Text revised and =
note added=20
  to indicate that applications must not expect the LDAP data store to =
implement=20
  sorting and ordering.</FONT></P>
  <P><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 23 - the DESC for pcelsPolicySetList =
should say=20
  that it</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; contains an =
UNORDERED list=20
  of DN references.</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Fixed.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 23, note above Section 5.2, is =
slightly=20
  incorrect. Only those</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
  implementations that WANT TO BE COMPATIBLE WITH PCELS should =
use</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; this aggregation mechanism =
instead of=20
  those defined by PCLS. Not</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp; every=20
  implementation mechanism is going to want to change.</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Revised. The section defining pcelsRule for =
example will=20
  include the following compatibility note:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; "Note 2: PCELS implementations SHOULD =
support=20
  pcelsRule and its two</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; =
subclasses and MAY=20
  also support pcimRule and its two subclasses</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; [PCLS]. Applications that choose to support =
pcelsRule and=20
  its two</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; subclasses MUST use the =

  aggregation mechanism provided by</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  pcelsPolicySetAssociation for aggregating policy groups or =
policy</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp; rules in policy rules represented as =
instances=20
  of pcelsRule.</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; Applications that =
intend to=20
  be compatible with [PCIM_EXT] MUST</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  support pcelsRule and its two subclasses."</FONT> </P>
  <P><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; The last MUST&nbsp;contradicts the first SHOULD in =
the above=20
  statement; please change it to SHOULD. The first MUSt in the above =
statement=20
  is OK. &lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - Page 23, Section 5.2, says "The=20
  pcelsPolicySetAssociation class is </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  used to aggregate instances of pcelsPolicySet into other =
entries."</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; This is incorrect, as =
pcelsPolicySet is=20
  abstract and thus cannot be</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  instantiated.</FONT> <BR><FONT size=3D2>&lt;mircea&gt; I fail to see a =
problem=20
  with "instance of &lt;abstract_class&gt;". It is obvious that it means =

  "instance of non-abstract subclass of &lt;abstract_class&gt;". The=20
  "non-abstract subclass of" is superfluous and has been omitted in =
order to=20
  improve the text readabilitiy. PCLS, for instance, uses such =
expressions on=20
  several occasions. E.g.: (PCLS page 50 first paragraph) "instances of=20
  pcimRules". Note that "pcimRules" is not a class name.</FONT></P>
  <P><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; I still disagree (and with PCLS page 50 as well) - =
it is=20
  imprecise. &lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - Same section, you write: "...realizes a =
(subclass=20
  of)</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; PolicySetComponent =
aggregation=20
  [sic]. When subordinated to (subclass </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; of) dlm1System...realizes a =
PolicySetInSystem=20
  association [sic]".</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; How =
can the=20
  same element realize an aggregation in one usage and an</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; association in another usage? This is =
semantically=20
  inconsistent.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;I fail to see =
the issue.=20
  The semantics of pcelsPolicySetAssociation are context =
sensitive.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; The point is that there is a pronounced difference =
between=20
  an aggregation and an association. Although it is sadly commonplace to =
call=20
  everything an association.&nbsp;;-(&nbsp;I would suggest&nbsp;changing =
your=20
  text to either only use "association" or only use =
"aggregation"&nbsp;in the=20
  same paragraph.&nbsp;&lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - Next paragraph says: "A non-reusable =
instance of=20
  (subclass of)</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
pcelsPolicySet is=20
  attached as auxiliary class directly to the </FONT><BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; pcelsPolicySetAssociation entry." =
Subclasses of=20
  pcelsPolicySet that</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; are =
not=20
  abstract are pcelsRuleAuxClass and pcelsRuleInstance. The</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; above sentence only makes sense for=20
  pcelsRuleAuxClass.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;The new =
specification=20
  will include pcelsGroup as well. As result, the current text will make =
more=20
  sense.</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Next paragraph doesn't make sense. First, =
you clearly=20
  mean a non-</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; abstract =
subclass of=20
  pcelsPolicySet. Second, you are recommending</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; that an ERROR be ignored? Why don't you =
stop=20
  operation?</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Revised =
text:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; "When reading a =
pcelsPolicySetAssociation=20
  instance that has a</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; =
pcelsPolicySet=20
  attached, the attribute pcelsPolicySetDN MUST</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; be ignored. Applications SHOULD remove the=20
  pcelsPolicySetDN value</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; from a=20
  pcelsPolicySetAssociation upon attachment of a pcelsPolicySet</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp; to the entry."</FONT> </P>
  <P><FONT size=3D2>This gives applications some flexibility.</FONT> =
<BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN =
class=3D745254702-26042004><FONT=20
  face=3D"Courier New" color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; That's much better =
&lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - Page 24, DESC of pcelsPriority is =
insufficient, as=20
  "0" has special</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; semantics =
that you=20
  haven't mentioned. This should, of course, also</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; be present in accompanying prose, as Kurt =
points=20
  out.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;The PCIM_EXT property and =
the=20
  attribute value restrictions going to be described in more detail (in =
prose).=20
  However I fail to find the meaning of "0" in PCIM_EXT. Can you help me =
locate=20
  the text?</FONT></P>
  <P><FONT size=3D2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN=20
  class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>&lt;js&gt; My&nbsp;mistake,&nbsp;the RFC states that this is =
simply the=20
  default value. &lt;/js&gt;</FONT>&nbsp;</SPAN></P>
  <P><FONT size=3D2>&nbsp; - Page 24, DESC of pcelsPolicySetDN should =
state that=20
  this is an</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; UNORDERED list =
of=20
  DNs.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Fixed.</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 24, Section 5.3, s/The Three Classes=20
  pcelsRule/The pcelsRule</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
Class and=20
  Its Subclasses</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Fixed.</FONT> =
<BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&lt;note: at this point I'm not going to correct any =
remaining=20
  grammar</FONT> <BR><FONT size=3D2>&nbsp;errors, such as the next line =
("The=20
  pcelsRule is...") because there</FONT> <BR><FONT size=3D2>&nbsp;are =
too many of=20
  them.&gt;</FONT> <BR><FONT size=3D2>&nbsp; - Page 24, Section 5.3, you =
say: "The=20
  pcelsRule is the base class</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  representing policy rules." Does this mean that an =
implementation</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; can NOT use the subclasses of =
pcimRule=20
  anymore?</FONT> <BR><FONT size=3D2>&lt;mircea&gt;I fail to see the =
issue.</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 24, next paragraph, you say: "This =
class shares=20
  the </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; Condition/Action =
aggregation=20
  methods with the</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
  pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; object classes.". Why does it =
also not=20
  share the</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
  pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; object classes as well?</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Revised text. It was actually trying to say =
that:</FONT>=20
  </P>
  <P><FONT size=3D2>"&nbsp;&nbsp; Like pcelsRule, instances of=20
  pcelsCompoundConditionAuxClass use</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  pcelsConditionList values and subordinated =
pcelsConditionAssociation</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp; entries to aggregate policy =
conditions."</FONT>=20
  <BR><FONT size=3D2>and</FONT> <BR><FONT size=3D2>"&nbsp;&nbsp; Like =
pcelsRule,=20
  instances of pcelsCompoundActionAuxClass use</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; pcelsActionList values and subordinated=20
  pcelsActionAssociation</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; entries =
to=20
  aggregate policy actions."</FONT> <BR><FONT =
size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 25, top paragraph, again says that the =

  implementer should ignore</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
an error=20
  condition. This isn't a good idea.</FONT> <BR><FONT size=3D2>&nbsp; - =
Page 25,=20
  next paragraph has the same problem.</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Already discussed</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 26, the pcelsConditionListType =
attribute has a=20
  constraint. No</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; text is =
provided=20
  that instructs the implementer what to do, aside</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; from Note 5 on page 21, which says: "Text =
has been=20
  added to instruct</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; servers =
and=20
  applications what to do if a value outside of this range</FONT> =
<BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; is encountered" - which is exactly the =
problem - no=20
  text is here.</FONT> <BR><FONT size=3D2>Note that this is a systemic =
problem=20
  with any constrained attribute</FONT> <BR><FONT size=3D2>defined in =
this draft.=20
  Thus, I will only mention this once.</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;All=20
  Fixed.</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 27, WHY isn't a PolicyGroup class =
implemented?=20
  You give no</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; reason for =
not doing=20
  this. Note also that Note 2 talks about ORDERED</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; policy rules - I don't see how you can =
construct=20
  those.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Already =
discussed</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 27, section 5.4, again you say =
"pcelsRule"=20
  instead of "non-</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; abstract =

  subclasses of pcelsRule".</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Already=20
  discussed</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 28, top paragraph, another error that =
you are=20
  recommending </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; should be=20
  ignored</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Already =
discussed</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 28, DESC for pcelsConditionAssociation =
is wrong;=20
  you say that</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; it can be =
used for a=20
  pcelsRule instead of a non-abstract subclass of</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; pcelsRule</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Already discussed</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp; - Page 28, section 5.5, again you say =
"pcelsRule"=20
  instead of "non-</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; abstract =

  subclasses of pcelsRule".</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Already=20
  discussed</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - Page 28, last paragraph, another =
error that you=20
  are recommending</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; should =
be=20
  ignored.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Already =
discussed</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - Page 29, DESC for =
pcelsActionAssociation is=20
  wrong; you say that </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; it =
can be used=20
  for a pcelsRule instead of a non-abstract subclass of</FONT> <BR><FONT =

  size=3D2>&nbsp;&nbsp;&nbsp; pcelsRule</FONT> <BR><FONT=20
  size=3D2>&lt;mircea&gt;Already discussed</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - Page 29, last paragraph above Section =
5.6,=20
  another error that you are</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  recommending should be ignored.</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Already=20
  discussed</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - Page 29, Section 5.6, last two =
paragraphs are=20
  errors that you are</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
recommending=20
  should be ignored.</FONT> <BR><FONT size=3D2>&lt;At this point, I'm =
going to=20
  stop listing these, as it is a systemic problem that should be fixed =
in the=20
  next release&gt;</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Already=20
  discussed</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - Page 29, last paragraph above Section =
5.6,=20
  another error that you are</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  recommending should be ignored.</FONT> <BR><FONT =
size=3D2>&lt;mircea&gt;Already=20
  discussed</FONT> <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - Page 30, the DESC for pcelsVariableDN =
is wrong.=20
  You say that it is a</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; "DN =
reference=20
  to a pcelsVariable entry", when it should be a DN</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp; reference to a subclass of either=20
  pcelsExplicitVariableAuxClass or</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass</FONT> =
<BR><FONT=20
  size=3D2>&lt;mircea&gt;Already discussed</FONT> <BR><FONT=20
  size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; - Page 30, the DESC for pcelsValueDN is =
wrong -=20
  it should be a subclass</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
of=20
  pcelsValueDN.</FONT> <BR><FONT size=3D2>&lt;mircea&gt;Already =
discussed</FONT>=20
  <BR><FONT size=3D2>&lt;/mircea&gt;</FONT> </P>
  <P><FONT size=3D2></FONT> </P>
  <P><FONT size=3D2>regards,</FONT> <BR><FONT size=3D2>John=20
</FONT><BR></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C42B53.AE30CC10--

_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy



From exim@www1.ietf.org  Wed May  5 15:56:07 2004
Received: from optimus.ietf.org (www.iesg.org [132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08457
	for <policy-archive@odin.ietf.org>; Wed, 5 May 2004 15:56:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLSQM-0006ue-9B
	for policy-archive@odin.ietf.org; Wed, 05 May 2004 15:51:30 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i45JpM7U026567
	for policy-archive@odin.ietf.org; Wed, 5 May 2004 15:51:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLSEP-0001p7-Km; Wed, 05 May 2004 15:39:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLMeZ-0001vH-96
	for policy@optimus.ietf.org; Wed, 05 May 2004 09:41:39 -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 JAA12938
	for <policy@ietf.org>; Wed, 5 May 2004 09:41:36 -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 1BLMeX-0004Hg-9x
	for policy@ietf.org; Wed, 05 May 2004 09:41:37 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLMdi-00043w-00
	for policy@ietf.org; Wed, 05 May 2004 09:40:49 -0400
Received: from passwd.metasolv.com ([216.30.145.17] helo=srvplemail2.metasolv.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLMci-0003bu-00
	for policy@ietf.org; Wed, 05 May 2004 09:39:44 -0400
Received: by passwd.metasolv.com with Internet Mail Service (5.5.2653.19)
	id <KG70YTT7>; Wed, 5 May 2004 08:40:39 -0500
Message-ID: <A33EE5A81E634B488B099FD31F65196101241D55@srvotemail.metasolv.com>
To: John.Strassner@intelliden.com, policy@ietf.org
Cc: bwijnen@lucent.com, joel@stevecrocker.com
Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04
	 .txt
Date: Wed, 5 May 2004 08:30:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C432A5.285D1CC0"
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: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=subscribe>

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_01C432A5.285D1CC0
Content-Type: text/plain;
	charset="ISO-8859-1"

John,
 
Is there going to be a follow-up on this message thread? If not, we will
issue one more (minor) revision of PCELS  to address the "MUST contradicts
the first SHOULD" issue as discussed below. Then, we would ask for Joel's
recommendation wrt. advancing the draft to the next stage.
 
Thanks,
Mircea.

-----Original Message-----
From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of
mpana@metasolv.com
Sent: Tuesday, April 27, 2004 10:05 PM
To: John.Strassner@intelliden.com; policy@ietf.org
Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04
.txt


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_01C432A5.285D1CC0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=290062513-05052004>John,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=290062513-05052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=290062513-05052004>Is 
there going to be a follow-up on this message thread? If not,&nbsp;we will issue 
one more (minor) revision of PCELS&nbsp; to address the "<FONT 
face="Courier New">MUST&nbsp;contradicts the first SHOULD</FONT>" issue as 
discussed below. Then, we would&nbsp;ask for Joel's recommendation wrt. 
advancing the draft to the next stage.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=290062513-05052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=290062513-05052004>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=290062513-05052004>Mircea.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> policy-admin@ietf.org 
  [mailto:policy-admin@ietf.org]<B>On Behalf Of 
  </B>mpana@metasolv.com<BR><B>Sent:</B> Tuesday, April 27, 2004 10:05 
  PM<BR><B>To:</B> John.Strassner@intelliden.com; 
  policy@ietf.org<BR><B>Subject:</B> RE: [Policy] FW: I-D 
  ACTION:draft-reyes-policy-core-ext-schema-04 .txt<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=879044212-27042004>John,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=879044212-27042004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=879044212-27042004>Thank you for your comments and clarifications. I've 
  added&nbsp;my responses inline embedded in 
  &lt;mircea2&gt;&lt;/mircea2&gt;.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=879044212-27042004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=879044212-27042004>Regards,</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=879044212-27042004>Mircea.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=879044212-27042004></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT size=2><FONT 
    face=Tahoma>-----Original Message-----<BR><B>From:</B> John Strassner 
    [mailto:John.Strassner@intelliden.com]<BR><SPAN 
    class=879044212-27042004><FONT face=Arial color=#0000ff>&nbsp;<FONT 
    face=Tahoma color=#000000>[...]</FONT></FONT></SPAN></FONT></FONT></DIV>
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT size=2><FONT 
    face=Tahoma><SPAN class=879044212-27042004>&nbsp;</SPAN></FONT>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.</FONT></DIV>
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <P><FONT size=2>&lt;mircea&gt;Can you be more specific. The document 
      includes several diagrams and tables. What is it missing?</FONT> <BR><FONT 
      size=2>&lt;/mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
      face="Courier New" color=#0000ff>&nbsp;</FONT></SPAN></FONT></P>
      <P><FONT size=2><SPAN class=745254702-26042004><FONT face="Courier New" 
      color=#0000ff>&lt;js&gt; True, there are several diagrams and tables. 
      However, the draft lacks an overall conceptual model. For example, if you 
      look at RFC3060,&nbsp;Figure 1 shows an overview of&nbsp;all of the 
      classes and their relationships.</FONT>&nbsp;<FONT face="Courier New" 
      color=#0000ff> 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. &lt;/js&gt;</FONT></SPAN></FONT></P>
      <P><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff>&lt;mircea2&gt;</FONT></SPAN></FONT><FONT face=Arial 
      color=#0000ff size=2><SPAN class=879044212-27042004>A 
      more&nbsp;appropriate place for&nbsp;an&nbsp;overall conceptual 
      model&nbsp;diagram would have been RFC3460. Such diagram is somewhat out 
      of scope for&nbsp;PCELS.&nbsp;Wrt. the LDAP mapping of PCIMe concepts, the 
      case studies&nbsp;in section 4.x include several&nbsp;instance diagrams 
      that illustrate&nbsp;the implementation options. There are many variations 
      and they could hardly fit in a single diagram.</SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=879044212-27042004>This being said, I am certainly not 
      against&nbsp;the inclusion of an overall&nbsp;class diagram. 
      So,&nbsp;</SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
      class=879044212-27042004>should someone out there volunteer to make such a 
      contribution to the document, I would&nbsp;gladly include it in a new 
      revision of PCELS.</SPAN></FONT><FONT size=2><SPAN 
      class=879044212-27042004><FONT face=Arial 
      color=#0000ff>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=879044212-27042004></SPAN></FONT>&nbsp;</P>
      <P><FONT size=2><SPAN class=879044212-27042004>[...]</SPAN></FONT></P>
      <P><FONT size=2><SPAN class=879044212-27042004></SPAN></FONT><FONT 
      size=2>Fifth, why is there a pcelsRule and a pcimRule class?</FONT> 
      <BR><FONT size=2>&lt;mircea&gt;I do not understand the issue.</FONT> 
      <BR><FONT size=2>&lt;/mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
      face="Courier New" color=#0000ff>&nbsp;</FONT></SPAN></FONT></P>
      <P><FONT size=2><SPAN class=745254702-26042004><FONT face="Courier New" 
      color=#0000ff>&lt;js&gt; Sorry for not being clearer. I understand that 
      you wanted to create your own class (pcelsRule) because the semantics of 
      RFC3460 were different&nbsp;(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&nbsp;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). 
      &lt;/js&gt;</FONT></SPAN></FONT></P>
      <P><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff>&lt;mircea2&gt;</FONT></SPAN></FONT><FONT face=Arial 
      color=#0000ff size=2><SPAN class=879044212-27042004>PCELS recommends the 
      use of pcelsRule. While the use of pcimRule is not prevented by 
      </SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
      class=879044212-27042004>PCELS, I do not see why this 
      document&nbsp;would&nbsp;state any reasons&nbsp;in favour of this class. 
      It is outside the scope&nbsp;of PCELS to&nbsp;make recommendations in this 
      matter. Should&nbsp;RFC3460 be revised, this is where such issue should be 
      addressed.</SPAN></FONT><FONT size=2><SPAN class=879044212-27042004><FONT 
      face=Arial color=#0000ff>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></FONT></P>
      <P><FONT size=2><SPAN class=879044212-27042004>&nbsp;</SPAN>Sixth, why is 
      there no pcelsRuleValidityAssociation subclass? At this point, 
      &lt;mircea&gt;I do not understand the issue. PCELS reuses 
      pcimRuleValidityAssociation that is defined in PCLS</FONT></P>
      <P><FONT size=2>&lt;/mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
      face="Courier New" color=#0000ff>&nbsp;</FONT></SPAN></FONT></P>
      <P><SPAN class=745254702-26042004><FONT size=2><FONT face="Courier New" 
      color=#0000ff>&lt;js&gt; True, this is addressed in Note 1 in page 27 of 
      the draft. Looking at your class structure, since you subclassed other 
      associations, I&nbsp;was surprised that you didn't subclass this one as 
      well. This is because pcelsRule and </FONT>&nbsp;<FONT 
      face="Courier New"><FONT color=#0000ff>pcimRule are siblings, and 
      pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and 
      policyConditionTimePeriod only. So, how do pcelsRule instances use a 
      policyConditionTimePeriod? &lt;/js&gt;<SPAN class=879044212-27042004><FONT 
      face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT size=2><FONT 
      face="Courier New"><FONT color=#0000ff><SPAN 
      class=879044212-27042004><FONT 
      face=Arial>&lt;mircea2&gt;</FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN 
      class=745254702-26042004><FONT face=Arial color=#0000ff size=2><SPAN 
      class=879044212-27042004>PCELS adopts 
      pcimRuleValidityAssociation&nbsp;extending its applicability to 
      pcelsRule.&nbsp;I.e. PCELS recommends the use 
      of&nbsp;pcimRuleValidityAssociation&nbsp;instances&nbsp;subordinated to 
      pcelsRule entries for associating&nbsp;pcimTPCAuxClass instances to a 
      Rule.&nbsp;Note that PCELS also recommends that:&nbsp;"As result, the 
      class pcimRuleValidityAssociation SHOULD be expected (and allowed) to have 
      instances of pcelsRule as superior entries."</SPAN></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face=Arial color=#0000ff 
      size=2><SPAN class=879044212-27042004>This isn't&nbsp;a change of 
      semantics for the pcimRuleValidityAssociation class.&nbsp;In a PCELS 
      implementation, this class continues to represent the 
      PolicyRuleValidityPeriod aggregation.&nbsp;Other association classes 
      defined in PCIM are subclassed in PCELS for the purpose of extending their 
      semantics (and for changing their names ;-)</SPAN></FONT></SPAN><SPAN 
      class=745254702-26042004><FONT size=2><FONT face="Courier New"><FONT 
      color=#0000ff><SPAN class=879044212-27042004><FONT 
      face=Arial>&lt;/mircea2&gt;</FONT></SPAN></FONT></FONT></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT size=2><FONT 
      face="Courier New"><FONT face=Arial color=#0000ff><SPAN 
      class=879044212-27042004></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</P>
      <P><FONT size=2><FONT face=Arial color=#0000ff><SPAN 
      class=879044212-27042004>&nbsp;[...]</SPAN></FONT></FONT></P>
      <P><FONT size=2><FONT face=Arial color=#0000ff><SPAN 
      class=879044212-27042004>&nbsp;</SPAN></FONT>&nbsp; - page 7 - you state: 
      "The LDAP object classes defined in this document</FONT> <BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; are a direct mapping from the corresponding 
      classes and, in some </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; cases, the 
      associations defined in [PCIM_EXT] ". Not strictly true, </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; as you are also seeking to update RFC 3703 
      (e.g., where is </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
      pcimSubtreesPtrAuxClass defined in RFC 3460?).</FONT> <BR><FONT 
      size=2>&lt;mircea&gt;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 </FONT></P>
      <P><FONT size=2>your reference to pcimSubtreesPtrAuxClass. That class is 
      not defined in PCELS.</FONT> <BR><FONT 
      size=2>&lt;mircea&gt;</FONT>&nbsp;<SPAN class=745254702-26042004><FONT 
      face="Courier New" color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT 
      color=#0000ff><FONT size=2>&lt;js&gt; 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. &lt;/js&gt;<SPAN class=879044212-27042004><FONT 
      face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT 
      color=#0000ff><FONT size=2><SPAN class=879044212-27042004><FONT 
      face=Arial>&lt;mircea2&gt;</FONT></SPAN></FONT></FONT></FONT></SPAN><SPAN 
      class=745254702-26042004><FONT size=+0><FONT color=#0000ff><FONT 
      face=Arial size=2><SPAN class=879044212-27042004>The fact that PCELS does 
      not explicitly discuss these classes does not mean that implementations 
      should not use them. Actually, PCELS&nbsp;application will 
      likely&nbsp;implement them as well as pcimPolicyInstance, 
      &nbsp;pcimConditionVendorAuxClass and many other PCLS classes. Are you 
      suggesting that all these classes&nbsp;should be explicitly listed? 
      IMO&nbsp;sections 2 and 3 of PCELS already address this 
      issue.</SPAN></FONT></FONT></FONT></SPAN><SPAN 
      class=745254702-26042004><FONT face="Courier New"><FONT 
      color=#0000ff><FONT size=2><SPAN class=879044212-27042004><FONT 
      face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT 
      color=#0000ff><FONT face=Arial size=2><SPAN 
      class=879044212-27042004></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT 
      color=#0000ff><FONT face=Arial size=2><SPAN 
      class=879044212-27042004>[...]</SPAN></FONT></FONT></FONT></SPAN></P>
      <P><FONT size=2>&nbsp; - pages 8-11: Where are classes like 
      pcimSubtreesPtrAuxClass? They</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
      aren't listed in this table, and better be, if you are "updating"</FONT> 
      <BR><FONT size=2>&nbsp;&nbsp;&nbsp; RFC 3703.</FONT> <BR><FONT 
      size=2>&lt;mircea&gt;The two tables list PCIM_EXT classes mapped by PCELS. 
      Why should the tables include PCLS classes?</FONT> <BR><FONT 
      size=2>&lt;/mircea&gt;<SPAN class=745254702-26042004><FONT 
      face="Courier New" color=#0000ff>&nbsp;</FONT></SPAN></FONT></P>
      <P><FONT color=#0000ff><FONT size=2><SPAN class=745254702-26042004><FONT 
      face="Courier New">&lt;js&gt; Because this draft is supposed to be 
      updating&nbsp;RFC3703, which means that you need to deal with classes 
      defined in that&nbsp;RFC&nbsp;(such as pcimSubtreesPtrAuxClass) as well as 
      your own classes. Or, at the very least, state why these classes do not 
      need to be defined. &lt;/js&gt;</FONT>&nbsp;</SPAN></FONT><SPAN 
      class=745254702-26042004>&nbsp;<SPAN class=879044212-27042004><FONT 
      face=Arial size=2>&nbsp;&nbsp;</FONT></SPAN></SPAN></FONT></P>
      <P><FONT size=2><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff>&lt;mircea2&gt;</FONT></SPAN></FONT><FONT face=Arial 
      color=#0000ff size=2><SPAN class=879044212-27042004>Do we understand 
      different things by "updates"? By "updates"&nbsp;we mean that PCELS 
      makes&nbsp;incremental changes and additions to PCLS. So, 
      </SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
      class=879044212-27042004>I fail to see why PCELS should re-define classes 
      that do not change.</SPAN></FONT><FONT size=2><SPAN 
      class=879044212-27042004><FONT color=#0000ff><FONT 
      face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</FONT></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=879044212-27042004></SPAN></FONT>&nbsp;</P>
      <P><FONT size=2><SPAN class=879044212-27042004>[...]</SPAN></FONT></P>
      <P><FONT size=2><SPAN class=879044212-27042004></SPAN></FONT><FONT 
      size=2>&lt;mircea&gt; ...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.</FONT></P>
      <P><FONT size=2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN 
      class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&lt;js&gt; OK, that makes sense, but I suggest you add a note 
      saying "See&nbsp;section 5.x" so the impatient reader won't get 
      frustrated. ;-) &lt;/js&gt;</FONT>&nbsp;<SPAN 
      class=879044212-27042004><FONT face=Arial 
      size=2>&nbsp;</FONT></SPAN></SPAN></P>
      <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
      face=Arial color=#0000ff size=2>&lt;mircea2&gt;</FONT></SPAN></SPAN><FONT 
      color=#0000ff><SPAN class=745254702-26042004><SPAN 
      class=879044212-27042004><FONT face=Arial 
      size=2>"</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN 
      class=879044212-27042004><FONT face=Arial size=2>4.1 Summary of Class and 
      Association Mappings</FONT></SPAN></SPAN></FONT></P>
      <P><FONT color=#0000ff><SPAN class=745254702-26042004><SPAN 
      class=879044212-27042004><FONT face=Arial 
      size=2>[...]</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN 
      class=879044212-27042004><FONT face=Arial size=2>&nbsp;&nbsp; The details 
      of this mapping are discussed case by case in section 
      5."</FONT></SPAN></SPAN></FONT><SPAN class=745254702-26042004><SPAN 
      class=879044212-27042004><FONT color=#0000ff><FONT face=Arial 
      size=2>&lt;/mircea2&gt;</FONT>&nbsp;</FONT></SPAN></SPAN></P>
      <P><FONT size=2><FONT face=Arial><SPAN 
      class=879044212-27042004>&nbsp;[...]</SPAN></FONT></FONT></P>
      <P><FONT size=2><FONT face=Arial><SPAN 
      class=879044212-27042004>&nbsp;</SPAN></FONT>&nbsp; - Page 11 - the reader 
      will wonder why ReusablePolicy and </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; PolicyRoleCollectionInSystem are only 
      implementable via DIT </FONT><BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
      containment, when every other association has an association 
      defined</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; (independent of whether 
      DIT containment could be used).</FONT> <BR><FONT size=2>&lt;mircea&gt;I 
      fail to see the issue.</FONT> <BR><FONT 
      size=2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN class=745254702-26042004><FONT 
      face="Courier New" color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&lt;js&gt; Good schemata are consistent.&nbsp;Why are these two 
      associations&nbsp;only implementable via DIT containment? 
      &lt;/js&gt;</FONT>&nbsp;<SPAN class=879044212-27042004><FONT face=Arial 
      size=2>&nbsp;</FONT></SPAN></SPAN></P>
      <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
      face=Arial color=#0000ff size=2>&lt;mircea2&gt;</FONT></SPAN></SPAN><SPAN 
      class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff size=2>For ReusablePolicy,&nbsp;DIT containment has the best 
      scalability (btw, PCLS does the same thing).</FONT></SPAN></SPAN></P>
      <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
      face=Arial color=#0000ff size=2>PolicyRoleCollectionInSystem,&nbsp;is 
      still open for suggestions&nbsp;;-) </FONT></SPAN></SPAN><SPAN 
      class=745254702-26042004><SPAN class=879044212-27042004><FONT 
      color=#0000ff><FONT face=Arial 
      size=2>&lt;/mircea2&gt;</FONT>&nbsp;</FONT></SPAN></SPAN></P>
      <P><FONT size=2>&nbsp; - Section 4.2, line 3, you write: "The concept of 
      an ordered set of</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; policies...". 
      LDAP doesn't have ordered sets. How are you going to</FONT> <BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; implement this?</FONT> <BR><FONT 
      size=2>&lt;mircea&gt;replaced "ordered" with "coherent" (from 
      PCIM_EXT)</FONT> <BR><FONT size=2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN 
      class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New" 
      color=#0000ff><FONT size=2>&lt;js&gt; That's certainly better than 
      incoherent ;-) but I don't see how this solves the problem, as the two 
      aren't synonymous. &lt;/js&gt;<SPAN class=879044212-27042004><FONT 
      face=Arial color=#000000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT 
      size=2><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff>&lt;mircea2&gt; </FONT></SPAN></FONT></FONT></SPAN><SPAN 
      class=745254702-26042004><FONT face="Courier New"><FONT face=Arial 
      color=#0000ff size=2><SPAN class=879044212-27042004>See note at the end of 
      section 5.1&nbsp;(page 26).</SPAN></FONT></FONT></SPAN><FONT 
      color=#0000ff><SPAN class=745254702-26042004><FONT 
      face="Courier New"><FONT size=2><SPAN class=879044212-27042004><FONT 
      face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></FONT></FONT>&nbsp;<SPAN 
      class=879044212-27042004><FONT face=Arial 
      size=2>&nbsp;</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN 
      class=879044212-27042004>&nbsp;</SPAN></SPAN></FONT></P>
      <P><FONT face=Arial color=#0000ff size=2><SPAN 
      class=745254702-26042004><SPAN 
      class=879044212-27042004></SPAN></SPAN></FONT>&nbsp;</P>
      <P><FONT size=2><FONT face=Arial><SPAN 
      class=879044212-27042004>&nbsp;[...]</SPAN></FONT></FONT></P>
      <P><FONT size=2><FONT face=Arial><SPAN 
      class=879044212-27042004>&nbsp;</SPAN></FONT>&nbsp; - Page 23, note above 
      Section 5.2, is slightly incorrect. Only those</FONT> <BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; implementations that WANT TO BE COMPATIBLE WITH 
      PCELS should use</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; this 
      aggregation mechanism instead of those defined by PCLS. Not</FONT> 
      <BR><FONT size=2>&nbsp;&nbsp;&nbsp; every implementation mechanism is 
      going to want to change.</FONT> <BR><FONT size=2>&lt;mircea&gt;Revised. 
      The section defining pcelsRule for example will include the following 
      compatibility note:</FONT> </P>
      <P><FONT size=2>&nbsp;&nbsp; "Note 2: PCELS implementations SHOULD support 
      pcelsRule and its two</FONT> <BR><FONT size=2>&nbsp;&nbsp; subclasses and 
      MAY also support pcimRule and its two subclasses</FONT> <BR><FONT 
      size=2>&nbsp;&nbsp; [PCLS]. Applications that choose to support pcelsRule 
      and its two</FONT> <BR><FONT size=2>&nbsp;&nbsp; subclasses MUST use the 
      aggregation mechanism provided by</FONT> <BR><FONT size=2>&nbsp;&nbsp; 
      pcelsPolicySetAssociation for aggregating policy groups or policy</FONT> 
      <BR><FONT size=2>&nbsp;&nbsp; rules in policy rules represented as 
      instances of pcelsRule.</FONT> <BR><FONT size=2>&nbsp;&nbsp; Applications 
      that intend to be compatible with [PCIM_EXT] MUST</FONT> <BR><FONT 
      size=2>&nbsp;&nbsp; support pcelsRule and its two subclasses."</FONT> </P>
      <P><FONT size=2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN 
      class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New" 
      color=#0000ff><FONT size=2>&lt;js&gt; The last MUST&nbsp;contradicts the 
      first SHOULD in the above statement; please change it to SHOULD. The first 
      MUSt in the above statement is OK. &lt;/js&gt;<SPAN 
      class=879044212-27042004><FONT face=Arial 
      color=#000000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT 
      size=2><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff>&lt;mircea2&gt; </FONT></SPAN></FONT></FONT></SPAN><SPAN 
      class=745254702-26042004><FONT size=+0><FONT face=Arial color=#0000ff 
      size=2><SPAN class=879044212-27042004>How about replacing the last 
      statement with: "Note that pcelsRule and its subclasses&nbsp;are 
      compatible with [PCIM_EXT] while pcimRule and its subclasses are 
      not.</SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT 
      face="Courier New"><FONT size=2><SPAN class=879044212-27042004><FONT 
      face=Arial 
      color=#0000ff>&lt;/mircea2&gt;</FONT></SPAN></FONT></FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New" 
      color=#0000ff><FONT size=2><SPAN 
      class=879044212-27042004>&nbsp;</SPAN></FONT></FONT>&nbsp;</SPAN></P>
      <P><FONT size=2>&nbsp; - Page 23, Section 5.2, says "The 
      pcelsPolicySetAssociation class is </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; used to aggregate instances of pcelsPolicySet 
      into other entries."</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; This is 
      incorrect, as pcelsPolicySet is abstract and thus cannot be</FONT> 
      <BR><FONT size=2>&nbsp;&nbsp;&nbsp; instantiated.</FONT> <BR><FONT 
      size=2>&lt;mircea&gt; I fail to see a problem with "instance of 
      &lt;abstract_class&gt;". It is obvious that it means "instance of 
      non-abstract subclass of &lt;abstract_class&gt;". 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.</FONT></P>
      <P><FONT size=2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN 
      class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&lt;js&gt; I still disagree (and with PCLS page 50 as well) - it is 
      imprecise. &lt;/js&gt;</FONT>&nbsp;<SPAN class=879044212-27042004><FONT 
      face=Arial size=2>&nbsp;</FONT></SPAN></SPAN></P>
      <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
      face=Arial color=#0000ff size=2>&lt;mircea2&gt; </FONT></SPAN></SPAN><SPAN 
      class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff size=2>Note 6 in section 5 warns the reader about the 
      imprecise language. (page 23)</FONT></SPAN></SPAN><SPAN 
      class=745254702-26042004><SPAN class=879044212-27042004><FONT 
      color=#0000ff><FONT face=Arial 
      size=2>&lt;/mircea2&gt;</FONT>&nbsp;</FONT></SPAN></SPAN></P>
      <P><FONT size=2>&nbsp; - Same section, you write: "...realizes a (subclass 
      of)</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; PolicySetComponent 
      aggregation [sic]. When subordinated to (subclass </FONT><BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; of) dlm1System...realizes a PolicySetInSystem 
      association [sic]".</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; How can the 
      same element realize an aggregation in one usage and an</FONT> <BR><FONT 
      size=2>&nbsp;&nbsp;&nbsp; association in another usage? This is 
      semantically inconsistent.</FONT> <BR><FONT size=2>&lt;mircea&gt;I fail to 
      see the issue. The semantics of pcelsPolicySetAssociation are context 
      sensitive.</FONT> <BR><FONT size=2>&lt;/mircea&gt;</FONT>&nbsp;<SPAN 
      class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&nbsp;</FONT></SPAN></P>
      <P><SPAN class=745254702-26042004><FONT face="Courier New" color=#0000ff 
      size=2>&lt;js&gt; 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.&nbsp;;-(&nbsp;I would 
      suggest&nbsp;changing your text to either only use "association" or only 
      use "aggregation"&nbsp;in the same 
      paragraph.&nbsp;&lt;/js&gt;</FONT>&nbsp;<SPAN 
      class=879044212-27042004><FONT face=Arial 
      size=2>&nbsp;</FONT></SPAN></SPAN></P>
      <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
      face=Arial color=#0000ff size=2>&lt;mircea2&gt;</FONT></SPAN></SPAN><SPAN 
      class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial 
      color=#0000ff size=2>...So, would it be acceptable to call 
      PolicySetComponent an association, when PCIMe&nbsp;defines it as 
      aggregation?</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN 
      class=879044212-27042004><FONT color=#0000ff><FONT face=Arial 
      size=2>&lt;/mircea2&gt;</FONT>&nbsp;</FONT></SPAN></SPAN></P>
      <P><FONT face=Arial size=2><SPAN 
      class=879044212-27042004>[...]</SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C432A5.285D1CC0--

_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy



From exim@www1.ietf.org  Wed May  5 20:06:59 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 UAA21476
	for <policy-archive@odin.ietf.org>; Wed, 5 May 2004 20:06:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLWM1-0007vN-4D
	for policy-archive@odin.ietf.org; Wed, 05 May 2004 20:03:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i46039Kh030462
	for policy-archive@odin.ietf.org; Wed, 5 May 2004 20:03:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLWIz-0006jb-GB; Wed, 05 May 2004 20:00:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BLWHR-0005yk-2A
	for policy@optimus.ietf.org; Wed, 05 May 2004 19:58:25 -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 TAA21086
	for <policy@ietf.org>; Wed, 5 May 2004 19:58:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.32)
	id 1BLWHP-0006yi-8w
	for policy@ietf.org; Wed, 05 May 2004 19:58:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BLWGS-0006eI-00
	for policy@ietf.org; Wed, 05 May 2004 19:57:25 -0400
Received: from cosium03.intelliden.net ([12.41.186.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1BLWFn-0006Jf-00
	for policy@ietf.org; Wed, 05 May 2004 19:56:43 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C432FC.8567DB60"
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt
Date: Wed, 5 May 2004 17:56:02 -0600
Message-ID: <AE723009E85E224CB00132C7FF0B34E1010E8657@cosium02.intelliden.net>
Thread-Topic: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt
Thread-Index: AcQyplwe3ZKQUfbaQR6ZZj+Le1T/XgAJ/MPgAAuG1oA=
From: "John Strassner" <John.Strassner@intelliden.com>
To: "John Strassner" <John.Strassner@intelliden.com>, <mpana@metasolv.com>,
        <policy@ietf.org>, "John Strassner" <John.Strassner@intelliden.com>
Cc: <bwijnen@lucent.com>, <joel@stevecrocker.com>
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_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: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C432FC.8567DB60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Resending, since original email was too long...
=20

-----Original Message-----
From: John Strassner=20
Sent: Wednesday, May 05, 2004 12:26 PM
To: mpana@metasolv.com; policy@ietf.org; 'John Strassner'
Cc: bwijnen@lucent.com; joel@stevecrocker.com
Subject: RE: [Policy] FW: I-D
ACTION:draft-reyes-policy-core-ext-schema-04 .txt



Sorry, I've been swamped. I'll reply to this thread later today, and try
and review your draft again this weekend.
=20
=20

-----Original Message-----
From: mpana@metasolv.com [mailto:mpana@metasolv.com]=20
Sent: Wednesday, May 05, 2004 7:31 AM
To: John Strassner; policy@ietf.org
Cc: bwijnen@lucent.com; joel@stevecrocker.com
Subject: RE: [Policy] FW: I-D
ACTION:draft-reyes-policy-core-ext-schema-04 .txt



John,
=20
Is there going to be a follow-up on this message thread? If not, we will
issue one more (minor) revision of PCELS  to address the "MUST
contradicts the first SHOULD" issue as discussed below. Then, we would
ask for Joel's recommendation wrt. advancing the draft to the next
stage.
=20
Thanks,
Mircea.


------_=_NextPart_001_01C432FC.8567DB60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D369175523-05052004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>Resending, since original email was too =
long...</FONT></SPAN></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
<P dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2>-----Original=20
Message-----<BR><B>From:</B> John Strassner <BR><B>Sent:</B> Wednesday, =
May 05,=20
2004 12:26 PM<BR><B>To:</B> mpana@metasolv.com; policy@ietf.org; 'John=20
Strassner'<BR><B>Cc:</B> bwijnen@lucent.com;=20
joel@stevecrocker.com<BR><B>Subject:</B> RE: [Policy] FW: I-D=20
ACTION:draft-reyes-policy-core-ext-schema-04 =
.txt<BR><BR></FONT></P></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D665142518-05052004><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>Sorry, I've been swamped. I'll reply to this thread later =
today, and=20
  try and review your draft again this weekend.</FONT></SPAN></DIV>
  <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft>
  <P dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2>-----Original=20
  Message-----<BR><B>From:</B> mpana@metasolv.com =
[mailto:mpana@metasolv.com]=20
  <BR><B>Sent:</B> Wednesday, May 05, 2004 7:31 AM<BR><B>To:</B> John =
Strassner;=20
  policy@ietf.org<BR><B>Cc:</B> bwijnen@lucent.com;=20
  joel@stevecrocker.com<BR><B>Subject:</B> RE: [Policy] FW: I-D=20
  ACTION:draft-reyes-policy-core-ext-schema-04 =
.txt<BR><BR></FONT></P></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D290062513-05052004>John,</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D290062513-05052004></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D290062513-05052004>Is=20
    there going to be a follow-up on this message thread? If =
not,&nbsp;we will=20
    issue one more (minor) revision of PCELS&nbsp; to address the "<FONT =

    face=3D"Courier New">MUST&nbsp;contradicts the first SHOULD</FONT>" =
issue as=20
    discussed below. Then, we would&nbsp;ask for Joel's recommendation =
wrt.=20
    advancing the draft to the next stage.</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D290062513-05052004></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D290062513-05052004>Thanks,</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    =
class=3D290062513-05052004>Mircea.</SPAN></FONT></DIV></BLOCKQUOTE></BLOC=
KQUOTE></BODY></HTML>

------_=_NextPart_001_01C432FC.8567DB60--

_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy



From exim@www1.ietf.org  Wed May 12 20:47:46 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 UAA22601
	for <policy-archive@odin.ietf.org>; Wed, 12 May 2004 20:47:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO4GB-0005NS-82
	for policy-archive@odin.ietf.org; Wed, 12 May 2004 20:39:54 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i4D0dd5q020671
	for policy-archive@odin.ietf.org; Wed, 12 May 2004 20:39:39 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO44I-0001sH-9F; Wed, 12 May 2004 20:27:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1BO2jN-0002J1-12
	for policy@optimus.ietf.org; Wed, 12 May 2004 19:01:41 -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 TAA17751
	for <policy@ietf.org>; Wed, 12 May 2004 19:01:36 -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 1BO2jJ-0001fu-OL
	for policy@ietf.org; Wed, 12 May 2004 19:01:37 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1BO2i1-00014Z-00
	for policy@ietf.org; Wed, 12 May 2004 19:00:20 -0400
Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1BO2hB-0000Sh-00
	for policy@ietf.org; Wed, 12 May 2004 18:59:25 -0400
Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19)
	id <J50KZS47>; Wed, 12 May 2004 17:57:02 -0500
Message-ID: <A33EE5A81E634B488B099FD31F65196101241D6E@srvotemail.metasolv.com>
To: John.Strassner@intelliden.com
Cc: joel@stevecrocker.com, bwijnen@lucent.com, policy@ietf.org
Date: Wed, 12 May 2004 18:02:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C43875.296E0225"
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
Subject: [Policy] response to comments on PCELS-05/May 06
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-BeenThere: policy@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>,
	<mailto:policy-request@ietf.org?subject=subscribe>

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_01C43875.296E0225
Content-Type: text/plain;
	charset="iso-8859-1"

John, See my comments tagged <mircea3></mircea3>.
 
Thank You,
Mircea

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Thursday, May 06, 2004 3:44 AM
To: mpana@metasolv.com; John Strassner
Cc: joel@stevecrocker.com; bwijnen@lucent.com
Subject: RE: your comments on PCELS-05 / April 26


I've just pulled up the remaining problems to make it easier to deal with.
I'm copying Joel and Bert so that they know that I am responding, albeit
slowly...look for <js2/>
 
 
[...]
 
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>

<js2> The above logic is incorrect. Look at how pcimRuleValidityPeriod is
defined in RFC3060. It is NOT a representation of a
PolicyRuleValidityPeriod, it is a representation of the *association*
between a PolicyRuleValidityPeriod and a PolicyRule. So, the problem is that
you have defined a pcelsPolicySet to be a sibling of pcimRule (to which
pcimRuleValidityPeriod applies). Therefore, pcimRuleValidityPeriod does NOT
apply to pcelsPolicySet (and thus not to pcelsRule). Therefore, you have to
either redefine this association, or create a new one. You did neither.
</js2> 

<mircea3>I must be missing something... You say that pcimRuleValidityPeriod
is defined in RFC3060 but in PCIM I can not find any reference to
pcimRuleValidityPeriod. PCLS (RFC3703) does not define such class either.
You also mention the association between a PolicyRuleValidityPeriod and a
PolicyRule but I can not find anything in either PCIM or PCLS that
implements such association.

However, in PCIM I read that PolicyRuleValidityPeriod is defined as "A class
representing the aggregation of PolicyTimePeriodConditions by a PolicyRule".
In PCLS I read that "The policyRuleValidityPeriod aggregation is mapped to
the PCLS pcimRuleValidityAssociation class." So, I conclude that
pcimRuleValidityAssociation is used to associate TimePeriodConditions to a
Rule. For PCLS this means associating instances of pcimTPCAuxClass to a
pcimRule. For PCELS this would mean associating instances of pcimTPCAuxClass
to a pcelsRule. I really don't see the problem. </mircea3> 

 

 [...]

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

<js2> It wasn't apparent to me or my developers that you were including
these classes. A few sentences here couldn't hurt! </js2> 

<mircea3>We will add a subsection 4.x or an appendix that lists the PCLS
classes that should be used by PCELS implementations.</mircea3> 

 

[...]

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

<js2> Perhaps this is a semantic difference. I think that an "update" should
address all issues, and explicitly state whether something is good as is, or
needs to be updated and why. Bert and Joel, your views? </js2> 

<mircea3>We will add a subsection 4.x that lists the PCLS classes that
should be used by PCELS implementations.</mircea3> 

 

[...]

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

<js2> But, my issue of consistency still holds. You are preventing the
developer from having a choice here. I would suggest defining both and then
stating, editorially, that DIT containment is preferred here. </js2> 

<mircea3>I have reviewed the PCIMe definitions for these two associations
and I think that mapping them to LDAP classes/attributes is unnecessary (or
even wrong). A PolicyRoleCollection if it exists, it only exists in the
context of a System, therefore the obvious LDAP implementation for
PolicyRoleCollectionInSystem is DIT containment. ReusablePolicy places a
policy element in a *container*. Once again, the obvious choice is DIT
containment. In addition, one could also argue that mapping ReusablePolicy
only to DIT containment is consistent with PCLS (see
Policy*InPolicyRepository association mappings in PCLS).</mircea3> 

 

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

<js2> I'm still not satisfied. Joel and Bert? </js2> 

<mircea3>We will make the change suggested by Joel: "[...] (pcelsPolicySet)
provides a set of policies with additional information that allow the
application to apply appropriate ordering to the information."</mircea3> 

 

 [...]

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

<js2> How about deleting it entirely? This statement doesn't really help,
it's stating the obvious. </js2> 

<mircea3>OK.</mircea3> 

 

[...]



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

<js2> No, of course not, in a perfect world. I'm suggesting 1 of 2 courses:
  - easiest: replace "aggregation" with "association" everywhere - this has
the advantage of being imprecise, or
  - go through the document and call things aggregations when they are
aggregations.

The problem is that you call the same object both an association and an
aggregation, which is confusing to some people. </js2> 

<mircea3>OK. We'll call them all "associations".</mircea3> 

[...]

regards,
John Strassner


------_=_NextPart_001_01C43875.296E0225
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=034421723-10052004>John, 
See my comments&nbsp;tagged &lt;mircea3&gt;&lt;/mircea3&gt;.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=034421723-10052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=034421723-10052004>Thank 
You,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=034421723-10052004>Mircea</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> John Strassner 
  [mailto:John.Strassner@intelliden.com]<BR><B>Sent:</B> Thursday, May 06, 2004 
  3:44 AM<BR><B>To:</B> mpana@metasolv.com; John Strassner<BR><B>Cc:</B> 
  joel@stevecrocker.com; bwijnen@lucent.com<BR><B>Subject:</B> RE: your comments 
  on PCELS-05 / April 26<BR><BR></FONT></DIV>
  <DIV><FONT face="Courier New" color=#0000ff size=2><SPAN 
  class=365492107-06052004>I've just pulled up the remaining problems to make it 
  easier to deal with. I'm copying Joel and Bert so that they know that I am 
  responding, albeit slowly...look for &lt;js2/&gt;</SPAN></FONT></DIV>
  <DIV><FONT face="Courier New" color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face="Courier New" color=#0000ff size=2><FONT 
  face="Times New Roman" color=#000000></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face="Courier New" size=2><FONT size=+0><FONT 
  face="Times New Roman" color=#0000ff><SPAN 
  class=365492107-06052004>[...]</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face="Courier New" size=2><FONT size=+0><FONT 
  face="Times New Roman" color=#0000ff><SPAN 
  class=365492107-06052004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face="Courier New" color=#0000ff size=2><FONT size=+0><FONT 
  face="Times New Roman"><SPAN class=365492107-06052004></SPAN>Sixth, why is 
  there no pcelsRuleValidityAssociation subclass? At this point, &lt;mircea&gt;I 
  do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is 
  defined in PCLS</FONT></FONT></DIV>
  <P>&lt;/mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
  face="Courier New">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New">&lt;js&gt; True, 
  this is addressed in Note 1 in page 27 of the draft. Looking at your class 
  structure, since you subclassed other associations, I&nbsp;was surprised that 
  you didn't subclass this one as well. This is because pcelsRule and 
  </FONT>&nbsp;<FONT face="Courier New">pcimRule are siblings, and 
  pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and 
  policyConditionTimePeriod only. So, how do pcelsRule instances use a 
  policyConditionTimePeriod? &lt;/js&gt;<SPAN class=879044212-27042004><FONT 
  face=Arial>&nbsp;</FONT></SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN 
  class=879044212-27042004><FONT 
  face=Arial>&lt;mircea2&gt;</FONT></SPAN></FONT></SPAN><SPAN 
  class=745254702-26042004><FONT face=Arial><SPAN class=879044212-27042004>PCELS 
  adopts pcimRuleValidityAssociation&nbsp;extending its applicability to 
  pcelsRule.&nbsp;I.e. PCELS recommends the use 
  of&nbsp;pcimRuleValidityAssociation&nbsp;instances&nbsp;subordinated to 
  pcelsRule entries for associating&nbsp;pcimTPCAuxClass instances to a 
  Rule.&nbsp;Note that PCELS also recommends that:&nbsp;"As result, the class 
  pcimRuleValidityAssociation SHOULD be expected (and allowed) to have instances 
  of pcelsRule as superior entries."</SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face=Arial><SPAN 
  class=879044212-27042004>This isn't&nbsp;a change of semantics for the 
  pcimRuleValidityAssociation class.&nbsp;In a PCELS implementation, this class 
  continues to represent the PolicyRuleValidityPeriod aggregation.&nbsp;Other 
  association classes defined in PCIM are subclassed in PCELS for the purpose of 
  extending their semantics (and for changing their names 
  ;-)</SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT 
  face="Courier New"><SPAN class=879044212-27042004><FONT 
  face=Arial>&lt;/mircea2&gt;</FONT></SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial>&lt;js2&gt; The above logic is 
  incorrect. Look at how pcimRuleValidityPeriod is defined in RFC3060. It is NOT 
  a representation of a PolicyRuleValidityPeriod, it is a representation of the 
  *association* between a PolicyRuleValidityPeriod and a PolicyRule. So, the 
  problem is that you have defined a pcelsPolicySet to be a sibling of pcimRule 
  (to which pcimRuleValidityPeriod applies). Therefore, pcimRuleValidityPeriod 
  does NOT apply to pcelsPolicySet (and thus not to pcelsRule). Therefore, you 
  have to either redefine this association, or create a new one. You did 
  neither. &lt;/js2&gt;<SPAN 
  class=034421723-10052004>&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004>&lt;mircea3&gt;I must be missing something... You say 
  that pcimRuleValidityPeriod is defined in RFC3060 but in PCIM I can not find 
  any reference to pcimRuleValidityPeriod. PCLS (RFC3703) does not&nbsp;define 
  such class either.&nbsp;You also mention&nbsp;the association between a 
  PolicyRuleValidityPeriod and a PolicyRule but I can not find anything in 
  either PCIM or PCLS that implements such 
  association.</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004>However,&nbsp;in PCIM I read 
  that&nbsp;PolicyRuleValidityPeriod is defined as "A class representing the 
  aggregation of PolicyTimePeriodConditions by a PolicyRule". 
  In</SPAN></FONT></SPAN></SPAN></SPAN><SPAN class=745254702-26042004><SPAN 
  class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004> PCLS I read that&nbsp;"The policyRuleValidityPeriod 
  aggregation is mapped to the PCLS pcimRuleValidityAssociation class."&nbsp;So, 
  I conclude that pcimRuleValidityAssociation&nbsp;is used to 
  associate&nbsp;TimePeriodConditions to a Rule. For PCLS this&nbsp;means 
  associating instances of pcimTPCAuxClass to a pcimRule. For PCELS this would 
  mean associating instances of pcimTPCAuxClass to&nbsp;a pcelsRule. I really 
  don't see the problem. 
  &lt;/mircea3&gt;&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</P>
  <P><FONT face=Arial><SPAN 
  class=879044212-27042004>&nbsp;[...]</SPAN></FONT></P>
  <P><FONT face=Arial><SPAN class=879044212-27042004>&nbsp;</SPAN></FONT>&nbsp; 
  - page 7 - you state: "The LDAP object classes defined in this document 
  <BR>&nbsp;&nbsp;&nbsp; are a direct mapping from the corresponding classes 
  and, in some <BR>&nbsp;&nbsp;&nbsp; cases, the associations defined in 
  [PCIM_EXT] ". Not strictly true, <BR>&nbsp;&nbsp;&nbsp; as you are also 
  seeking to update RFC 3703 (e.g., where is <BR>&nbsp;&nbsp;&nbsp; 
  pcimSubtreesPtrAuxClass defined in RFC 3460?). <BR>&lt;mircea&gt;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 </P>
  <P>your reference to pcimSubtreesPtrAuxClass. That class is not defined in 
  PCELS. <BR>&lt;mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
  face="Courier New">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New">&lt;js&gt; 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. &lt;/js&gt;<SPAN 
  class=879044212-27042004><FONT 
  face=Arial>&nbsp;</FONT></SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN 
  class=879044212-27042004><FONT 
  face=Arial>&lt;mircea2&gt;</FONT></SPAN></FONT></SPAN><SPAN 
  class=745254702-26042004><FONT size=+0><FONT face=Arial size=2><SPAN 
  class=879044212-27042004>The fact that PCELS does not explicitly discuss these 
  classes does not mean that implementations should not use them. Actually, 
  PCELS&nbsp;application will likely&nbsp;implement them as well as 
  pcimPolicyInstance, &nbsp;pcimConditionVendorAuxClass and many other PCLS 
  classes. Are you suggesting that all these classes&nbsp;should be explicitly 
  listed? IMO&nbsp;sections 2 and 3 of PCELS already address this 
  issue.</SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT 
  face="Courier New"><SPAN class=879044212-27042004><FONT 
  face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial>&lt;js2&gt; It wasn't apparent to me 
  or my developers that you were including these classes. A few sentences here 
  couldn't hurt! &lt;/js2&gt;<SPAN 
  class=034421723-10052004>&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004>&lt;mircea3&gt;We will add a subsection 4.x or an 
  appendix that lists the PCLS classes that should be used by PCELS 
  implementations.&lt;/mircea3&gt;&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New"><FONT 
  face=Arial><SPAN 
class=879044212-27042004>[...]</SPAN></FONT></FONT></SPAN></P>
  <P>&nbsp; - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They 
  <BR>&nbsp;&nbsp;&nbsp; aren't listed in this table, and better be, if you are 
  "updating" <BR>&nbsp;&nbsp;&nbsp; RFC 3703. <BR>&lt;mircea&gt;The two tables 
  list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS 
  classes? <BR>&lt;/mircea&gt;<SPAN class=745254702-26042004><FONT 
  face="Courier New">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New">&lt;js&gt; Because 
  this draft is supposed to be updating&nbsp;RFC3703, which means that you need 
  to deal with classes defined in that&nbsp;RFC&nbsp;(such as 
  pcimSubtreesPtrAuxClass) as well as your own classes. Or, at the very least, 
  state why these classes do not need to be defined. 
  &lt;/js&gt;</FONT>&nbsp;</SPAN><SPAN class=745254702-26042004>&nbsp;<SPAN 
  class=879044212-27042004><FONT 
face=Arial>&nbsp;&nbsp;</FONT></SPAN></SPAN></P>
  <P><SPAN class=879044212-27042004><FONT 
  face=Arial>&lt;mircea2&gt;</FONT></SPAN><FONT face=Arial><SPAN 
  class=879044212-27042004>Do we understand different things by "updates"? By 
  "updates"&nbsp;we mean that PCELS makes&nbsp;incremental changes and additions 
  to PCLS. So, </SPAN></FONT><FONT face=Arial><SPAN class=879044212-27042004>I 
  fail to see why PCELS should re-define classes that do not 
  change.</SPAN></FONT><SPAN class=879044212-27042004><FONT 
  face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></P>
  <P><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT 
  face=Arial>&lt;js2&gt; Perhaps this is a semantic difference. I think that an 
  "update" should address all issues, and explicitly state whether something is 
  good as is, or needs to be updated and why. Bert and Joel, your views? 
  &lt;/js2&gt;<SPAN 
  class=034421723-10052004>&nbsp;</SPAN></FONT></SPAN></SPAN></P>
  <P><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT 
  face=Arial><SPAN class=034421723-10052004><SPAN class=745254702-26042004><SPAN 
  class=879044212-27042004><SPAN class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004>&lt;mircea3&gt;We will add a subsection 4.x that 
  lists the PCLS classes that should be used by PCELS 
  implementations.&lt;/mircea3&gt;</SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</SPAN></FONT></SPAN></SPAN></P>
  <P><SPAN class=879044212-27042004><SPAN class=365492107-06052004><FONT 
  face=Arial><SPAN 
  class=034421723-10052004></SPAN></FONT></SPAN></SPAN>&nbsp;</P>
  <P><SPAN class=879044212-27042004>[...]</SPAN></P>
  <P><FONT face=Arial><SPAN class=879044212-27042004>&nbsp;</SPAN></FONT>&nbsp; 
  - Page 11 - the reader will wonder why ReusablePolicy and 
  <BR>&nbsp;&nbsp;&nbsp; PolicyRoleCollectionInSystem are only implementable via 
  DIT <BR>&nbsp;&nbsp;&nbsp; containment, when every other association has an 
  association defined <BR>&nbsp;&nbsp;&nbsp; (independent of whether DIT 
  containment could be used). <BR>&lt;mircea&gt;I fail to see the issue. 
  <BR>&lt;/mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
  face="Courier New">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New">&lt;js&gt; Good 
  schemata are consistent.&nbsp;Why are these two associations&nbsp;only 
  implementable via DIT containment? &lt;/js&gt;</FONT>&nbsp;<SPAN 
  class=879044212-27042004><FONT face=Arial>&nbsp;</FONT></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
  face=Arial>&lt;mircea2&gt;</FONT></SPAN></SPAN><SPAN 
  class=745254702-26042004><SPAN class=879044212-27042004><FONT face=Arial>For 
  ReusablePolicy,&nbsp;DIT containment has the best scalability (btw, PCLS does 
  the same thing).</FONT></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
  face=Arial>PolicyRoleCollectionInSystem,&nbsp;is still open for 
  suggestions&nbsp;;-) </FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN 
  class=879044212-27042004><FONT 
  face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial>&lt;js2&gt; But, my issue of 
  consistency still holds. You are preventing the developer from having a choice 
  here. I would suggest defining both and then stating, editorially, that DIT 
  containment is preferred here. &lt;/js2&gt;<SPAN 
  class=034421723-10052004>&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004>&lt;mircea3&gt;I have reviewed the PCIMe definitions 
  for these two associations and I think that&nbsp;mapping them to&nbsp;LDAP 
  classes/attributes is&nbsp;unnecessary (or even&nbsp;wrong). A <SPAN 
  class=745254702-26042004><SPAN class=879044212-27042004><FONT 
  face=Arial>PolicyRoleCollection if it exists, it only exists in the context 
  of&nbsp;a System, therefore the obvious LDAP&nbsp;implementation for <SPAN 
  class=745254702-26042004><SPAN class=879044212-27042004><FONT 
  face=Arial>PolicyRoleCollectionInSystem </FONT></SPAN></SPAN>is DIT 
  containment. ReusablePolicy places a policy element in a *container*. Once 
  again, the obvious choice is DIT containment. In addition, one could also 
  argue that&nbsp;mapping ReusablePolicy only to DIT containment 
  is&nbsp;consistent with PCLS (see Policy*InPolicyRepository association 
  mappings in 
  PCLS).</FONT></SPAN></SPAN>&lt;/mircea3&gt;&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</P>
  <P>&nbsp; - Section 4.2, line 3, you write: "The concept of an ordered set of 
  <BR>&nbsp;&nbsp;&nbsp; policies...". LDAP doesn't have ordered sets. How are 
  you going to <BR>&nbsp;&nbsp;&nbsp; implement this? <BR>&lt;mircea&gt;replaced 
  "ordered" with "coherent" (from PCIM_EXT) <BR>&lt;/mircea&gt;&nbsp;<SPAN 
  class=745254702-26042004><FONT face="Courier New">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New" 
  color=#0000ff>&lt;js&gt; That's certainly better than incoherent ;-) but I 
  don't see how this solves the problem, as the two aren't synonymous. 
  &lt;/js&gt;<SPAN class=879044212-27042004><FONT face=Arial 
  color=#000000>&nbsp;</FONT></SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN 
  class=879044212-27042004><FONT face=Arial>&lt;mircea2&gt; 
  </FONT></SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT 
  face="Courier New"><FONT face=Arial><SPAN class=879044212-27042004>See note at 
  the end of section 5.1&nbsp;(page 26).</SPAN></FONT></FONT></SPAN><SPAN 
  class=745254702-26042004><FONT face="Courier New"><SPAN 
  class=879044212-27042004><FONT 
  face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></FONT>&nbsp;<SPAN 
  class=879044212-27042004><FONT face=Arial>&nbsp;</FONT></SPAN></SPAN><SPAN 
  class=745254702-26042004><SPAN 
  class=879044212-27042004>&nbsp;</SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial>&lt;js2&gt; I'm still not satisfied. 
  Joel and Bert? &lt;/js2&gt;<SPAN 
  class=034421723-10052004>&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004>&lt;mircea3&gt;We will make the change suggested by 
  Joel: "[...]&nbsp;(pcelsPolicySet) provides a set of policies with additional 
  information that allow the application to apply appropriate ordering to the 
  information."&lt;/mircea3&gt;&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</P>
  <P><FONT face=Arial><SPAN 
  class=879044212-27042004>&nbsp;[...]</SPAN></FONT></P>
  <P><FONT face=Arial><SPAN class=879044212-27042004>&nbsp;</SPAN></FONT>&nbsp; 
  - Page 23, note above Section 5.2, is slightly incorrect. Only those 
  <BR>&nbsp;&nbsp;&nbsp; implementations that WANT TO BE COMPATIBLE WITH PCELS 
  should use <BR>&nbsp;&nbsp;&nbsp; this aggregation mechanism instead of those 
  defined by PCLS. Not <BR>&nbsp;&nbsp;&nbsp; every implementation mechanism is 
  going to want to change. <BR>&lt;mircea&gt;Revised. The section defining 
  pcelsRule for example will include the following compatibility note: </P>
  <P>&nbsp;&nbsp; "Note 2: PCELS implementations SHOULD support pcelsRule and 
  its two <BR>&nbsp;&nbsp; subclasses and MAY also support pcimRule and its two 
  subclasses <BR>&nbsp;&nbsp; [PCLS]. Applications that choose to support 
  pcelsRule and its two <BR>&nbsp;&nbsp; subclasses MUST use the aggregation 
  mechanism provided by <BR>&nbsp;&nbsp; pcelsPolicySetAssociation for 
  aggregating policy groups or policy <BR>&nbsp;&nbsp; rules in policy rules 
  represented as instances of pcelsRule. <BR>&nbsp;&nbsp; Applications that 
  intend to be compatible with [PCIM_EXT] MUST <BR>&nbsp;&nbsp; support 
  pcelsRule and its two subclasses." </P>
  <P>&lt;/mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
  face="Courier New">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New" 
  color=#0000ff>&lt;js&gt; The last MUST&nbsp;contradicts the first SHOULD in 
  the above statement; please change it to SHOULD. The first MUSt in the above 
  statement is OK. &lt;/js&gt;<SPAN class=879044212-27042004><FONT face=Arial 
  color=#000000>&nbsp;</FONT></SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN 
  class=879044212-27042004><FONT face=Arial>&lt;mircea2&gt; 
  </FONT></SPAN></FONT></SPAN><SPAN class=745254702-26042004><FONT size=+0><FONT 
  face=Arial size=2><SPAN class=879044212-27042004>How about replacing the last 
  statement with: "Note that pcelsRule and its subclasses&nbsp;are compatible 
  with [PCIM_EXT] while pcimRule and its subclasses are 
  not.</SPAN></FONT></FONT></SPAN><SPAN class=745254702-26042004><FONT 
  face="Courier New"><SPAN class=879044212-27042004><FONT 
  face=Arial>&lt;/mircea2&gt;</FONT></SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial>&lt;js2&gt; How about deleting it 
  entirely? This statement doesn't really help, it's stating the obvious. 
  &lt;/js2&gt;<SPAN 
  class=034421723-10052004>&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004>&lt;mircea3&gt;OK.&lt;/mircea3&gt;&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial><SPAN 
  class=034421723-10052004></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</P>
  <P><SPAN class=745254702-26042004><FONT face=Arial><SPAN 
  class=879044212-27042004><SPAN 
  class=365492107-06052004>[...]</SPAN></SPAN></FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New"><SPAN 
  class=879044212-27042004></SPAN></FONT></SPAN></P>
  <P>&nbsp; - Same section, you write: "...realizes a (subclass of) 
  <BR>&nbsp;&nbsp;&nbsp; PolicySetComponent aggregation [sic]. When subordinated 
  to (subclass <BR>&nbsp;&nbsp;&nbsp; of) dlm1System...realizes a 
  PolicySetInSystem association [sic]". <BR>&nbsp;&nbsp;&nbsp; How can the same 
  element realize an aggregation in one usage and an <BR>&nbsp;&nbsp;&nbsp; 
  association in another usage? This is semantically inconsistent. 
  <BR>&lt;mircea&gt;I fail to see the issue. The semantics of 
  pcelsPolicySetAssociation are context sensitive. 
  <BR>&lt;/mircea&gt;&nbsp;<SPAN class=745254702-26042004><FONT 
  face="Courier New">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=745254702-26042004><FONT face="Courier New">&lt;js&gt; 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.&nbsp;;-(&nbsp;I would suggest&nbsp;changing your text to either 
  only use "association" or only use "aggregation"&nbsp;in the same 
  paragraph.&nbsp;&lt;/js&gt;</FONT>&nbsp;<SPAN class=879044212-27042004><FONT 
  face=Arial>&nbsp;</FONT></SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><FONT 
  face=Arial>&lt;mircea2&gt;</FONT></SPAN></SPAN><SPAN 
  class=745254702-26042004><SPAN class=879044212-27042004><FONT 
  face=Arial>...So, would it be acceptable to call PolicySetComponent an 
  association, when PCIMe&nbsp;defines it as 
  aggregation?</FONT></SPAN></SPAN><SPAN class=745254702-26042004><SPAN 
  class=879044212-27042004><FONT 
  face=Arial>&lt;/mircea2&gt;</FONT>&nbsp;</SPAN></SPAN></P>
  <P><SPAN class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT face=Arial>&lt;js2&gt; No, of course not, in a 
  perfect world. I'm suggesting 1 of 2 courses:<BR>&nbsp; - easiest: replace 
  "aggregation" with "association" everywhere - this has the advantage of being 
  imprecise, or<BR>&nbsp; - go through the document and call things aggregations 
  when they are aggregations.</FONT></SPAN></SPAN></SPAN></P>
  <P><FONT face=Arial><SPAN class=745254702-26042004><SPAN 
  class=879044212-27042004><SPAN class=365492107-06052004>The problem is that 
  you call the same object both an association and an aggregation, which is 
  confusing to some people. </SPAN></SPAN></SPAN><SPAN 
  class=745254702-26042004><SPAN class=879044212-27042004><SPAN 
  class=365492107-06052004><FONT size=+0>&lt;/js2&gt;</FONT><FONT size=2><SPAN 
  class=034421723-10052004>&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></FONT></P>
  <P><FONT face=Arial><SPAN class=745254702-26042004><SPAN 
  class=879044212-27042004><SPAN class=365492107-06052004><FONT size=2><SPAN 
  class=034421723-10052004><FONT size=3>&lt;mircea3&gt;OK. We'll call them all 
  "associations".&lt;/mircea3&gt;</FONT>&nbsp;</SPAN></FONT></SPAN></SPAN></SPAN></FONT></P>
  <P><FONT face=Arial><SPAN 
  class=879044212-27042004>[...]</SPAN></FONT></P></FONT>
  <DIV dir=ltr align=left>
  <P dir=ltr align=left><FONT face="Times New Roman"><FONT 
  size=3>regards,<BR>John<SPAN class=050114416-03022004> 
  Strassner</SPAN></FONT></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C43875.296E0225--

_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy