[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Policy] RE: response to comments on PCELS-05/May 06
Please reread my reasoning. If you have questions, reply to me offline, as I'm sure the rest of the readership is tired of this circular debate
regards,
John
> -----Original Message-----
> From: policy-bounces at ietf.org [mailto:policy-bounces at ietf.org]
> Sent: Thursday, June 10, 2004 10:14 AM
> To: policy at ietf.org
> Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
>
>
> Hi,
>
> We thing that creating a pcimRuleValidityAssociation subclass
> we can extend its capabilities in order to associate
> pcelsRule and pcimTPCAuxClass. If the
> pcelsRuleConditionAssociation and pcelsRuleActionAssociation
> subclasses are accepted as they are defined, then the
> pcimRuleValidityAssociation should be correctly
> defined as well because the changes that were made to the
> these classes are the same that now have been proposed to define
> pcelsRuleActionAssociation.
>
> Technically there is no problem creating the PCELS model in a
> LDAP using a pcelsRuleActionAssociation as a
> pcimRuleValidityAssociation
> subclass:
>
>
> DN reference +---------------------+
> +------------| pcelsRule Subclass |
> | +---------------------+
> | |
> | +---------+ DIT Containment
> v |
> +-------------------------------+
> | pcelsRuleValidityAssociation |
> +-------------------------------+
>
> At Technical University of Catalonia, we have implemented the
> last draft version (PCELS-05) (+ the last proposed change) in
> a distributed
> openLDAP server and the storaged policies are retrieved, and
> prodessed by the PDP with no problems.
>
> As an alternative, the pcelsRuleValidityAssociation could be defined
> on the same level than pcimRuleValidityAssociation and
> reusing its atributes:
>
> ( OID NAME 'pcelsRuleValidityAssociation'
> DESC 'This defines the scheduled activation or deactivation
> of a policy rule.'
> SUP pcimPolicy
> STRUCTURAL
> MAY ( pcimValidityConditionName $
> pcimTimePeriodConditionDN )
> )
>
> Opinions?
>
> Best regards,
>
> David Morón
> Antoni Barba
> Technical University of Catalonia
>
>
> ----------------------------------------------------------------------
> Fine. Since it is technically incorrect, please be advised
> that I will object in any Last Call.
>
> regards,
> John Strassner
> TeleManagement Forum Advisory Director
>
>
> John Strassner
> Chief Strategy Officer
> Intelliden Inc.
> 90 South Cascade Avenue
> Colorado Springs, CO 80906 USA
> phone: +1.719.785.0648
> fax: +1.719.785.0644
> email: john.strassner at intelliden.com
>
>
>
> >> -----Original Message-----
> >> From: Pana, Mircea [mailto:mpana at metasolv.com]
> >> Sent: Wednesday, June 09, 2004 6:13 PM
> >> To: John Strassner; joel at stevecrocker.com
> >> Cc: bwijnen at lucent.com; policy at ietf.org
> >> Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
> >>
> >>
> >> John, Although very interesting, your arguments have failed
> >> to convince me that your suggestion would be a better option.
> >> We have to agree that we disagree
> >>
> >> 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 violate current LDAP
> >> recommendations 3. it is a practical approach (simplifies
> >> implementations)
> >>
> >> Thank you,
> >> Mircea.
> >>
> >>
> >
> >
> >>> > -----Original Message-----
> >>> > From: John Strassner [mailto:John.Strassner at intelliden.com]
> >>> > Sent: Tuesday, June 08, 2004 5:05 PM
> >>> > To: Pana, Mircea
> >>> > Cc: joel at stevecrocker.com; bwijnen at lucent.com; policy at ietf.org
> >>> > Subject: [Policy] RE: response to comments on PCELS-05/May 06
> >>> >
> >>> >
> >>> > 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.
> >>> >
> >>> > One last time: you can't subclass the existing association
> >>
> >>
> >> because it
> >
> >
> >>> > was defined between classes that do not include pcelsRule.
> >>> >
> >>> > I have nothing else to say, as I don't know how to make this any
> >>> > clearer.
> >>> >
> >>> >
> >>> > regards,
> >>> > John Strassner
> >>> > TeleManagement Forum Advisory Director
> >>> >
> >>> >
> >>> > John Strassner
> >>> > Chief Strategy Officer
> >>> > Intelliden Inc.
> >>> > 90 South Cascade Avenue
> >>> > Colorado Springs, CO 80906 USA
> >>> > phone: +1.719.785.0648
> >>> > fax: +1.719.785.0644
> >>> > email: john.strassner at intelliden.com
> >>> >
> >>> >
> >>> >
> >>
> >>
> >>>> > > -----Original Message-----
> >>>> > > From: Pana, Mircea [mailto:mpana at metasolv.com]
> >>>> > > Sent: Monday, June 07, 2004 1:02 PM
> >>>> > > To: John Strassner
> >>>> > > Cc: policy at ietf.org; bwijnen at lucent.com;
> joel at stevecrocker.com
> >>>> > > Subject: RE: response to comments on PCELS-05/May 06
> >>>> > >
> >>>> > >
> >>>> > > John,
> >>>> > >
> >>>> > > You have started this thread by asking: "why is there no
> >>>> > > 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."
> >>>> > >
> >>>> > > Besides, PCELS defines the pcelsConditionAssociation and
> >>>> > > 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.
> >>>> > >
> >>>> > > 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.
> >
> >
> >>>> > >
> >>>> > > Thank you,
> >>>> > > Mircea.
> >>>> > >
> >>>> > >
> >>>
> >>>
> >>>>> > > > -----Original Message-----
> >>>>> > > > From: John Strassner
> [mailto:John.Strassner at intelliden.com]
> >>>>> > > > Sent: Friday, June 04, 2004 5:45 PM
> >>>>> > > > To: Pana, Mircea; policy at ietf.org
> >>>>> > > > Cc: bwijnen at lucent.com; joel at stevecrocker.com
> >>>>> > > > Subject: RE: response to comments on PCELS-05/May 06
> >>>>> > > >
> >>>>> > > >
> >>>>> > > > Hmm.
> >>>>> > > >
> >>>>> > > > 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.
> >>>>> > > >
> >>>>> > > > Second, rather than pcelsValidityAssociation, could I
> >>>>> > > > suggest pcelsRuleValidityAssociation?
> >>>>> > > >
> >>>>> > > > regards,
> >>>>> > > > John Strassner
> >>>>> > > > TeleManagement Forum Advisory Director
> >>>>> > > >
> >>>>> > > >
> >>>>> > > > John Strassner
> >>>>> > > > Chief Strategy Officer
> >>>>> > > > Intelliden Inc.
> >>>>> > > > 90 South Cascade Avenue
> >>>>> > > > Colorado Springs, CO 80906 USA
> >>>>> > > > phone: +1.719.785.0648
> >>>>> > > > fax: +1.719.785.0644
> >>>>> > > > email: john.strassner at intelliden.com
> >>>>> > > >
> >>>>> > > >
> >>>>> > > >
> >>>>
> >>>>
> >>>>>> > > > > -----Original Message-----
> >>>>>> > > > > From: Pana, Mircea [mailto:mpana at metasolv.com]
> >>>>>> > > > > Sent: Friday, June 04, 2004 2:48 PM
> >>>>>> > > > > To: policy at ietf.org; John Strassner
> >>>>>> > > > > Cc: bwijnen at lucent.com; joel at stevecrocker.com
> >>>>>> > > > > Subject: RE: response to comments on PCELS-05/May 06
> >>>>>> > > > >
> >>>>>> > > > >
> >>>>>> > > > > To accomodate the change requested by Joel, I'm making
> >>>>>> > > > > the
> >>>>>> > > > > proposal below. Please review it and let me
> know as soon as
> >>>>>> > > > > possible whether you like or not.
> >>>>>> > > > >
> >>>>>> > > > > Instead of re-using pcimRuleValidityAssociation, PCELS
> >>>>>> > > > > would
> >>>>>> > > > > introduce a new class: 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.
> >>>>>> > > > >
> >>>>>> > > > > In addition, Note 1 in section 5.4 would be removed.
> >>>>>> > > > >
> >>>>>> > > > > Regards,
> >>>>>> > > > > Mircea.
> >>>>>> > > > >
> >>>>>> > > > >
> >>>>>> > > > > -----Original Message-----
> >>>>>> > > > > From: Joel M. Halpern [mailto:joel at stevecrocker.com]
> >>>>>> > > > > Sent: Friday, June 04, 2004 9:37 AM
> >>>>>> > > > > To: policy at ietf.org
> >>>>>> > > > > Cc: bwijnen at lucent.com; John Strassner; Pana, Mircea
> >>>>>> > > > > Subject: RE: response to comments on PCELS-05/May 06
> >>>>>> > > > >
> >>>>>> > > > >
> >>>>>> > > > > I have looked this over again, and I think I
> understand
> >>>>>> > > > > the
> >>>>>
> >>>>>
> >>>>> > > > question.
> >>>>
> >>>>
> >>>>>> > > > >
> >>>>>> > > > > From an object mapping and class definition
> perspective,
> >>>>>> > > > > it
> >>>>>> > > > > appears to me that extending the definition of
> >>>>>> > > > > pcimRuleValidityAssociation to point to a pcelsRule
> >>>>>
> >>>>>
> >> is probably
> >
> >
> >>>>>> > > > > not appropriate.
> >>>>>> > > > >
> >>>>>> > > > > It seems to me thinking about this that adding a
> >>>>>> > > > > different
> >>>>>> > > > > 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.
> >>>>>> > > > >
> >>>>>> > > > > 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.
> >
> >
> >>>>>> > > > >
> >>>>>> > > > > 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.
> >>>
> >>>
> >>>>>> > > > >
> >>>>>> > > > > And then we will officially close the working group!
> >>>>>> > > > >
> >>>>>> > > > > Yours,
> >>>>>> > > > > Joel M. Halpern
> >>>>>> > > > >
> >>>>>> > > > > At 07:55 PM 6/3/2004 -0600, John Strassner wrote:
> >>>>>> > > > >
> >>>>>> > > > > Subject: RE: response to comments on PCELS-05/May 06
> >>>>>> > > > > To: "Pana, Mircea" <mpana at metasolv.com>
> >>>>>> > > > > Cc: <joel at stevecrocker.com>,
> >>>>>> > > > > <bwijnen at lucent.com>,
> >>>>>> > > > > <policy at ietf.org>
> >>>>>> > > > >
> >>>>>> > > > > Hi Mircea,
> >>>>>> > > > >
> >>>>>> > > > > thanks for your thoughtful response.
> >>>>>> > > > >
> >>>>>> > > > > 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.
> >>>>>> > > > >
> >>>>>> > > > > Regarding changing the note in section 5.4, I
> agree with
> >>>>>
> >>>>>
> >>>> > > the change.
> >>>
> >>>
> >>>>>> > > > >
> >>>>>> > > > > Regarding the DIT containment issue, I'm happy
> with your
> >>>>>
> >>>>>
> >>>> > > suggestion.
> >>>
> >>>
> >>>>>> > > > >
> >>>>>> > > > >
> >>>>>> > > > > regards,
> >>>>>> > > > > John Strassner
> >>>>>> > > > > -----Original Message-----
> >>>>>> > > > > From: Pana, Mircea [mailto:mpana at metasolv.com]
> >>>>>> > > > > Sent: Friday, May 28, 2004 8:16 AM
> >>>>>> > > > > To: John Strassner
> >>>>>> > > > > Cc: joel at stevecrocker.com; bwijnen at lucent.com;
> >>>>>
> >>>>>
> >> policy at ietf.org
> >
> >
> >>>>>> > > > > Subject: RE: response to comments on PCELS-05/May 06
> >>>>>> > > > >
> >>>>>> > > > >
> >>>>>> > > > > Look for my responses in <mircea4></mircea4>. Sorry,
> >>>>>
> >>>>>
> >> I'm slow to
> >
> >
> >>>>>> > > > > respond as well. Regards,
> >>>>>> > > > > Mircea.
> >>>>>
> >>>>>
> >>>>> > > >
> >>>>
> >>>>
> >>>> > >
> >>>
> >>>
> >>> >
> >>> > _______________________________________________
> >>> > Policy mailing list
> >>> > Policy at ietf.org https://www1.ietf.org/mailman/listinfo/policy
> >>> >
> >>
> >>
> >>
> >
> >
>
> _______________________________________________
> Policy mailing list
> Policy at ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>
>
> _______________________________________________
> Policy mailing list
> Policy at ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>
_______________________________________________
Policy mailing list
Policy at ietf.org
https://www1.ietf.org/mailman/listinfo/policy