pcelsRule and PolicyRule /was: RE: RE: response to comments on PCELS-05/May 06
"Pana, Mircea" <[email protected]> Fri, 11 Jun 2004 16:18:32 -0400
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
John,
pcelsRule [PCELS] is the LDAP implementation of PolicyRule [PCIMe]. If =
you compare the class hierarchy of RFC3460 (below) and the LDAP class =
hierarchy in the PCELS draft you will see the similarity. Your arguments =
are based on PCIM, so I'll say it again: PCELS is focused merely on the =
LDAP mapping of PCIMe (i.e. RFC3460 that updates RFC3060). You can not =
hold PCELS responsible for things you don't like in PCIMe.
extract from RFC3460:
"
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicySet (abstract -- new - 5.3)
| | |
| | +---PolicyGroup (moved - 5.3)
| | |
| | +---PolicyRule (moved - 5.3)
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
[unrooted]
|
+---PolicyComponent (abstract)
| |
[...]
| +---PolicyRuleValidityPeriod
"
Regards,
Mircea.
> -----Original Message-----
> From: John Strassner [mailto:[email protected]]
> Sent: Friday, June 11, 2004 10:28 AM
> To: Pana, Mircea; [email protected]; John Strassner
> Cc: David Kessens (E-mail); Wijnen, Bert (Bert)
> Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
>=20
>=20
> HUH???
>=20
> From pages 4-5 of your draft:
>=20
> | | +---pcelsPolicySet (abstract new)
> | | | |
> | | | +---pcelsGroup (abstract new)
> | | | | |
> | | | | +---pcelsGroupAuxClass (auxiliary new)
> | | | | |
> | | | | +---pcelsGroupInstance (structural new)
> | | | |
> | | | +---pcelsRule (abstract new)
> | | | |
> | | | +---pcelsRuleAuxClass (auxiliary new)
> | | | |
> | | | +---pcelsRuleInstance (structural new)
> | | |
> | | +---pcimRule (abstract)
> | | | |
> | | | +---pcimRuleAuxClass (auxiliary)
> | | | |
> | | | +---pcimRuleInstance (structural)
>=20
> Clearly, this diagram shows pcelsRule having a DIFFERENT PARENT than
> pcimRule. Or, from page 30:
>=20
> The pcelsRule class is defined as follows:
>=20
> ( IANA-ASSIGNED-OID.1.6
> NAME 'pcelsRule'
> DESC 'Base class for representing a policy rule'
> SUP pcelsPolicySet
> ...
>=20
> Clearly, it derives from pcelsPolicySet, which pcimRule=20
> doesn't, because
> there isn't a pcelsPolicySet!
>=20
> And NO, pcelsRule is NOT the LDAP implementation of=20
> PolicyRule, because
> there are existing implementations that use pcimRule.
>=20
> Thus, my argument stands.
>=20
> regards,
> John Strassner
> TeleManagement Forum Advisory Director
>=20
>=20
> John Strassner=20
> Chief Strategy Officer=20
> Intelliden Inc.=20
> 90 South Cascade Avenue=20
> Colorado Springs, CO 80906 USA=20
> phone: +1.719.785.0648=20
> fax: +1.719.785.0644=20
> email: [email protected]
>=20
>=20
>=20
> > -----Original Message-----
> > From: Pana, Mircea [mailto:[email protected]]=20
> > Sent: Thursday, June 10, 2004 6:57 PM
> > To: John Strassner; [email protected]
> > Cc: David Kessens (E-mail); Wijnen, Bert (Bert)
> > Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
> >=20
> >=20
> > John,
> >=20
> > pcelsRule [PCELS] is NOT a sibling of PolicyRule [PCIM].
> >=20
> > pcelsRule [PCELS] is the LDAP implementation of PolicyRule [PCIMe].
> >=20
> > pcimRuleValidityAssociation [PCLS] is the LDAP implementation=20
> > of PolicyRuleValidityPeriod[PCIM].
> >=20
> > PolicyRuleValidityPeriod [PCIM] is reused AS IS by PCIMe (not=20
> > redefined, not changed, not extended).
> >=20
> > Therefore, PCELS (that implements PCIMe) reuses=20
> > pcimRuleValidityAssociation [PCLS] as is. This accurately=20
> > maps the intent of PCIMe (isn't this a technical argument?)=20
> > and does not conflict (as you also admitted) with LDAP=20
> > recommendations.
> >=20
> > BTW: The OO design has been done when the PCIMe=20
> > recommendation was elaborated. PCELS is focused merely on the=20
> > LDAP mapping. So, your OO remarks may be more appropriate in=20
> > the context of a revision of PCIMe but that is outside the=20
> > scope of this discussion. You can not hold PCELS responsible=20
> > for things you don't like in PCIMe.
> >=20
> > Regards,
> > Mircea.
> >=20
> >=20
> > > -----Original Message-----
> > > From: John Strassner [mailto:[email protected]]
> > > Sent: Thursday, June 10, 2004 6:03 PM
> > > To: Wijnen, Bert (Bert); Pana, Mircea;=20
> [email protected]; John=20
> > > Strassner
> > > Cc: David Kessens (E-mail)
> > > Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
> > >=20
> > >=20
> > > I thought I have, but I'm happy to do so again.
> > >=20
> > > First, it is not an LDAP problem, so I don't see how the LDAP=20
> > > Directorate can help. It is a simple Object-Oriented design issue.
> > >=20
> > > PCIM defined an aggregation, called=20
> > PolicyRuleValidityPeriod (which is=20
> > > subclassed from PolicyComponent), between=20
> PolicyTimePeriodCondition=20
> > > and PolicyRule.
> > >=20
> > > PcelsRule is a SIBLING of PolicyRule, not a SUBCLASS.=20
> > Therefore, under=20
> > > any definition of object-orientation, the existing=20
> > > PolicyRuleValidityPeriod does NOT apply to PcelsRule.
> > >=20
> > > In order for PolicyRuleValidityPeriod to apply to=20
> > PcelsRule, you would=20
> > > have to change the definition of the aggregation to be between=20
> > > PolicyTimePeriodCondition and the superclass of {PcelsRule and=20
> > > PolicyRule}, which is Policy.
> > >=20
> > > That is a horrible thing to do, because Policy is the=20
> root of many=20
> > > things that have nothing to do with this aggregation.
> > >=20
> > > Which is why I originally said, why not create another=20
> subclass of=20
> > > PolicyComponent?
> > >=20
> > > I also note that no technical arguments have been provided to
> > > refute the
> > > above. In fact, the only arguments were "reduce churn" and "it's
> > > easier". That is not acceptable for a standards track document.
> > >=20
> > > In summary, this design is just plain wrong. It has nothing=20
> > to do with=20
> > > LDAP - it has everything to do with proper OO design.
> > >=20
> > >=20
> > > regards,
> > > John Strassner
> > > TeleManagement Forum Advisory Director
> > >=20
> > >=20
> > > John Strassner
> > > Chief Strategy Officer=20
> > > Intelliden Inc.=20
> > > 90 South Cascade Avenue=20
> > > Colorado Springs, CO 80906 USA=20
> > > phone: +1.719.785.0648=20
> > > fax: +1.719.785.0644=20
> > > email: [email protected]
> > >=20
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:[email protected]]
> > > > Sent: Thursday, June 10, 2004 3:35 AM
> > > > To: John Strassner; Pana, Mircea; [email protected]
> > > > Cc: [email protected]; David Kessens (E-mail)
> > > > Subject: RE: [Policy] RE: response to comments on=20
> PCELS-05/May 06
> > > >=20
> > > >=20
> > > > Could someone summarize the "technically incorrect" in a=20
> > form that=20
> > > > WG chair Joel can hand the question to the LDAP directorate for=20
> > > > (hopefully) a decisive answer on that?
> > > >=20
> > > > http://www.apps.ietf.org/ldap-directorate.html
> > > >=20
> > > > I think that may be a better approach to try and get some more=20
> > > > opinions.
> > > >=20
> > > > Thanks,
> > > > Bert
> > > >=20
> > > > > -----Original Message-----
> > > > > From: John Strassner [mailto:[email protected]]
> > > > > Sent: donderdag 10 juni 2004 03:22
> > > > > To: Pana, Mircea; [email protected]
> > > > > Cc: [email protected]; [email protected]
> > > > > Subject: RE: [Policy] RE: response to comments on=20
> > PCELS-05/May 06
> > > > >=20
> > > > >=20
> > > > > Fine. Since it is technically incorrect, please be advised
> > > > that I will
> > > > > object in any Last Call.
> > > > >=20
> > > > > regards,
> > > > > John Strassner
> > > > > TeleManagement Forum Advisory Director
> > > > >=20
> > > > >=20
> > > > > John Strassner
> > > > > Chief Strategy Officer
> > > > > Intelliden Inc.
> > > > > 90 South Cascade Avenue=20
> > > > > Colorado Springs, CO 80906 USA=20
> > > > > phone: +1.719.785.0648=20
> > > > > fax: +1.719.785.0644=20
> > > > > email: [email protected]
> > > > >=20
> > > > >=20
> > > > >=20
> > > > > > -----Original Message-----
> > > > > > From: Pana, Mircea [mailto:[email protected]]
> > > > > > Sent: Wednesday, June 09, 2004 6:13 PM
> > > > > > To: John Strassner; [email protected]
> > > > > > Cc: [email protected]; [email protected]
> > > > > > Subject: RE: [Policy] RE: response to comments on
> > > PCELS-05/May 06
> > > > > >=20
> > > > > >=20
> > > > > > John, Although very interesting, your arguments=20
> have failed to
> > > > > > convince me that your suggestion would be a better=20
> > > option. We have
> > >=20
> > > > > > to agree that we disagree ;-)
> > > > > >=20
> > > > > > Joel, Unless somebody produces arguments to prove the
> > > contrary, I
> > > > > > would like to ask you to accept the version currently
> > > included in
> > > > > > the I-D (i.e. reuse of pcimRuleValidityAssociation for
> > > pcelsRule)
> > > > > > with the revised Note 1 in section 5.4 on the premise
> > > that: 1. it
> > > > > > accurately maps the PCIMe model 2. it does not=20
> violate current
> > > > > > LDAP recommendations 3. it is a practical approach=20
> (simplifies
> > > > > > implementations)
> > > > > >=20
> > > > > > Thank you,
> > > > > > Mircea.
> > > > > >=20
> > > > > >=20
> > > > > > > -----Original Message-----
> > > > > > > From: John Strassner=20
> [mailto:[email protected]]
> > > > > > > Sent: Tuesday, June 08, 2004 5:05 PM
> > > > > > > To: Pana, Mircea
> > > > > > > Cc: [email protected]; [email protected];=20
> > [email protected]
> > > > > > > Subject: [Policy] RE: response to comments on=20
> > PCELS-05/May 06
> > > > > > >=20
> > > > > > >=20
> > > > > > > I don't think we're making progress anymore. Regardless of
> > > > > > what I may
> > > > > > > have said, or what you think I may have said in the
> > > > > beginning, I've
> > > > > > > given you very clear rationale as to what should be done.
> > > > > > >=20
> > > > > > > One last time: you can't subclass the existing association
> > > > > > because it
> > > > > > > was defined between classes that do not include pcelsRule.
> > > > > > >=20
> > > > > > > I have nothing else to say, as I don't know how to
> > > make this any
> > >=20
> > > > > > > clearer.
> > > > > > >=20
> > > > > > >=20
> > > > > > > regards,
> > > > > > > John Strassner
> > > > > > > TeleManagement Forum Advisory Director
> > > > > > >=20
> > > > > > >=20
> > > > > > > John Strassner
> > > > > > > Chief Strategy Officer
> > > > > > > Intelliden Inc.
> > > > > > > 90 South Cascade Avenue
> > > > > > > Colorado Springs, CO 80906 USA=20
> > > > > > > phone: +1.719.785.0648=20
> > > > > > > fax: +1.719.785.0644=20
> > > > > > > email: [email protected]
> > > > > > >=20
> > > > > > >=20
> > > > > > >=20
> > > > > > > > -----Original Message-----
> > > > > > > > From: Pana, Mircea [mailto:[email protected]]
> > > > > > > > Sent: Monday, June 07, 2004 1:02 PM
> > > > > > > > To: John Strassner
> > > > > > > > Cc: [email protected]; [email protected];
> > > [email protected]
> > > > > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > > > > >=20
> > > > > > > >=20
> > > > > > > > John,
> > > > > > > >=20
> > > > > > > > You have started this thread by asking: "why is=20
> there no=20
> > > > > > > > pcelsRuleValidityAssociation subclass?" In a
> > > > subsequent message,
> > > > > > > > you have further detailed the issue by saying:
> > > > "Looking at your
> > > > > > > > class structure, since you subclassed other
> > > > associations, I was
> > > > > > > > surprised that you didn't subclass this one as well."
> > > > > > > >=20
> > > > > > > > Besides, PCELS defines the=20
> pcelsConditionAssociation and=20
> > > > > > > > pcelsActionAssociation classes by subclassing PCLS
> > > > classes for
> > > > > > > > the purpose of extending their semantics. Neither
> > > you nor any
> > > > > > > > other reviewer of the I-D has expressed any issue
> > > with those
> > > > > > > > definitions.
> > > > > > > >=20
> > > > > > > > The latest proposal *does* accommodate your original
> > > > request but
> > > > > > > > I see you bringing up a different issue now. So, if
> > > you think
> > > > > > > > that it is wrong to subclass the PCLS association
> > > class(es),
> > > > > > > > please help me out by pointing to the LDAP (or
> > > > > > > > other) specification that would be violated. I am not
> > > > > > aware of any.
> > > > > > > >=20
> > > > > > > > Thank you,
> > > > > > > > Mircea.
> > > > > > > >=20
> > > > > > > >=20
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: John Strassner
> > > [mailto:[email protected]]
> > > > > > > > > Sent: Friday, June 04, 2004 5:45 PM
> > > > > > > > > To: Pana, Mircea; [email protected]
> > > > > > > > > Cc: [email protected]; [email protected]
> > > > > > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > > > > > >=20
> > > > > > > > >=20
> > > > > > > > > Hmm.
> > > > > > > > >=20
> > > > > > > > > First, I don't think subclassing helps, because the
> > > > > > root problem
> > > > > > > > > is that pcimRuleValidityAssociation doesn't apply to
> > > > > a pcelsRule
> > > > > > > > > (pcelsRule is a
> > > > > > > > > sibling of pcimRule. Thus, I believe that you need a
> > > > > new class.
> > > > > > > > >=20
> > > > > > > > > Second, rather than pcelsValidityAssociation, could
> > > > I suggest
> > > > > > > > > pcelsRuleValidityAssociation?
> > > > > > > > >=20
> > > > > > > > > regards,
> > > > > > > > > John Strassner
> > > > > > > > > TeleManagement Forum Advisory Director
> > > > > > > > >=20
> > > > > > > > >=20
> > > > > > > > > John Strassner
> > > > > > > > > Chief Strategy Officer
> > > > > > > > > Intelliden Inc.
> > > > > > > > > 90 South Cascade Avenue
> > > > > > > > > Colorado Springs, CO 80906 USA
> > > > > > > > > phone: +1.719.785.0648=20
> > > > > > > > > fax: +1.719.785.0644=20
> > > > > > > > > email: [email protected]
> > > > > > > > >=20
> > > > > > > > >=20
> > > > > > > > >=20
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Pana, Mircea [mailto:[email protected]]
> > > > > > > > > > Sent: Friday, June 04, 2004 2:48 PM
> > > > > > > > > > To: [email protected]; John Strassner
> > > > > > > > > > Cc: [email protected]; [email protected]
> > > > > > > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > > > > > > >=20
> > > > > > > > > >=20
> > > > > > > > > > To accomodate the change requested by Joel, I'm
> > > making the
> > >=20
> > > > > > > > > > proposal below. Please review it and let me know
> > > > as soon as
> > > > > > > > > > possible whether you like or not.
> > > > > > > > > >=20
> > > > > > > > > > Instead of re-using pcimRuleValidityAssociation,
> > > > > PCELS would
> > > > > > > > > > introduce a new class:=20
> pcelsValidityAssociation. This
> > > > > > new class
> > > > > > > > > > would be a subclass of pcimRuleValidityAssociation
> > > > > > and it would
> > > > > > > > > > not introduce any new attributes. Its instances
> > > would be
> > > > > > > > > > subordinated to pcelsRule instances. (Much like
> > > > > > > > > > pcelsConditionAssociation etc.) The pcelsRule class,
> > > > > > instead of
> > > > > > > > > > reusing the pcimRuleValidityPeriodList attribute,
> > > > > would use a
> > > > > > > > > > new attribute (pcelsValidityPeriodList) as
> > > > reference to its
> > > > > > > > > > pcelsValidityAssociation instances.
> > > > > > > > > >=20
> > > > > > > > > > In addition, Note 1 in section 5.4 would be removed.
> > > > > > > > > >=20
> > > > > > > > > > Regards,
> > > > > > > > > > Mircea.
> > > > > > > > > >=20
> > > > > > > > > >=20
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Joel M. Halpern [mailto:[email protected]]
> > > > > > > > > > Sent: Friday, June 04, 2004 9:37 AM
> > > > > > > > > > To: [email protected]
> > > > > > > > > > Cc: [email protected]; John Strassner; Pana, Mircea
> > > > > > > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > > > > > > >=20
> > > > > > > > > >=20
> > > > > > > > > > I have looked this over again, and I think I
> > > > understand the
> > > > > > > > > question.
> > > > > > > > > >=20
> > > > > > > > > > From an object mapping and class definition
> > > > perspective, it
> > > > > > > > > > appears to me that extending the definition of=20
> > > > > > > > > > pcimRuleValidityAssociation to point to a pcelsRule
> > > > > > is probably
> > > > > > > > > > not appropriate.
> > > > > > > > > >=20
> > > > > > > > > > It seems to me thinking about this that adding
> > > a different
> > >=20
> > > > > > > > > > association class for the pcelsRule - time-period
> > > > > > relationship
> > > > > > > > > > will not adversely affect either existim PCLS
> > > > > implementors or
> > > > > > > > > > future PCELS implementors. Ruding churn in an
> > > I-D before
> > > > > > > > > > publication is not a good reason to avoid making a
> > > > > > technically
> > > > > > > > > > correct change.
> > > > > > > > > >=20
> > > > > > > > > > However, I could easily have missed multiple aspects
> > > > > > of this. If
> > > > > > > > > > there are folks looking at implementing PCELS
> > > who have an
> > > > > > > > > > opinion on the complexity of either the current
> > > > > > "extension" or
> > > > > > > > > > the proposed additional class, please speak up. If
> > > > > there are
> > > > > > > > > > LDAP folks (other than John, who has been very
> > > > > > helpful) who can
> > > > > > > > > > shed light or opinions on this, I would love to hear
> > > > > > from them.
> > > > > > > > > >=20
> > > > > > > > > > Given how many times we have been around the block
> > > > > on this, I
> > > > > > > > > > would like to ask folks to respond within one week.
> > > > > > If we hear
> > > > > > > > > > nothing, I will ask Mircea and company if they can
> > > > > > make this one
> > > > > > > > > > last change, and hand the document to Bert for
> > > > > > > > publication.
> > > > > > > > > >=20
> > > > > > > > > > And then we will officially close the working group!
> > > > > > > > > >=20
> > > > > > > > > > Yours,
> > > > > > > > > > Joel M. Halpern
> > > > > > > > > >=20
> > > > > > > > > > At 07:55 PM 6/3/2004 -0600, John Strassner wrote:
> > > > > > > > > >=20
> > > > > > > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > > > > > > > To: "Pana, Mircea" <[email protected]>
> > > > > > > > > > Cc: <[email protected]>,
> > > > > > > > > > <[email protected]>,
> > > > > > > > > > <[email protected]>
> > > > > > > > > >=20
> > > > > > > > > > Hi Mircea,
> > > > > > > > > > =20
> > > > > > > > > > thanks for your thoughtful response.
> > > > > > > > > > =20
> > > > > > > > > > Regarding the first issue, I still disagree. The
> > > > > > definition of
> > > > > > > > > > the class doesn't allow this, even though the
> > > > > > semantics remain
> > > > > > > > > > unchanged. Since we are at an impasse, I'm happy to
> > > > > let Joel
> > > > > > > > > > rule one way or the other.
> > > > > > > > > > =20
> > > > > > > > > > Regarding changing the note in section 5.4, I=20
> > agree with
> > > > > > > > the change.
> > > > > > > > > > =20
> > > > > > > > > > Regarding the DIT containment issue, I'm=20
> > happy with your
> > > > > > > > suggestion.
> > > > > > > > > > =20
> > > > > > > > > >=20
> > > > > > > > > > regards,
> > > > > > > > > > John Strassner
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Pana, Mircea [mailto:[email protected]]
> > > > > > > > > > Sent: Friday, May 28, 2004 8:16 AM
> > > > > > > > > > To: John Strassner
> > > > > > > > > > Cc: [email protected]; [email protected];=20
> > > > > > [email protected]
> > > > > > > > > > Subject: RE: response to comments on PCELS-05/May 06
> > > > > > > > > >=20
> > > > > > > > > >=20
> > > > > > > > > > Look for my responses in <mircea4></mircea4>. Sorry,
> > > > > > I'm slow to
> > > > > > > > > > respond as well. Regards,
> > > > > > > > > > Mircea.
> > > > > > > > >=20
> > > > > > > >=20
> > > > > > >=20
> > > > > > > _______________________________________________
> > > > > > > Policy mailing list
> > > > > > > [email protected]=20
> > https://www1.ietf.org/mailman/listinfo/policy
> > > > > > >=20
> > > >=20
> > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
>=20