[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