[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: pcelsRule and PolicyRule /was: RE: [Policy] RE: response to comments on PCELS-05/May 06



This is absurd.

You copied back another diagram that clearly shows that PolicyRule USED
to be defined under PolicySet, but now you've changed that.

IT IS YOUR CHANGE THAT I AM ARGUING WITH, AS I HAVE AN EXISTING
IMPLEMENTATION THAT YOU HAVE NO BROKEN!!!

You cannot say that it is OK, and don't blame pcels, when you break my
implementation. My implementation was there before yours. You built a
mapping that was incompatible with it. 

I'm done with this conversation. The pictures don't lie, and you can't
simply say that you can change the original semantics of the aggregation
just so that it is convenient for you.


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 11, 2004 2:19 PM
> To: John Strassner
> Cc: David Kessens (E-mail); Wijnen, Bert (Bert); IETF Policy 
> (E-mail); joel at stevecrocker.com
> Subject: pcelsRule and PolicyRule /was: RE: [Policy] RE: 
> response to comments on PCELS-05/May 06
> 
> 
> 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:John.Strassner at intelliden.com]
> > Sent: Friday, June 11, 2004 10:28 AM
> > To: Pana, Mircea; joel at stevecrocker.com; John Strassner
> > Cc: David Kessens (E-mail); Wijnen, Bert (Bert)
> > Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
> > 
> > 
> > HUH???
> > 
> > From pages 4-5 of your draft:
> > 
> >   |   |   +---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)
> > 
> > Clearly, this diagram shows pcelsRule having a DIFFERENT 
> PARENT than 
> > pcimRule. Or, from page 30:
> > 
> >    The pcelsRule class is defined as follows:
> > 
> >    ( IANA-ASSIGNED-OID.1.6
> >      NAME 'pcelsRule'
> >      DESC 'Base class for representing a policy rule'
> >      SUP pcelsPolicySet
> > ...
> > 
> > Clearly, it derives from pcelsPolicySet, which pcimRule
> > doesn't, because
> > there isn't a pcelsPolicySet!
> > 
> > And NO, pcelsRule is NOT the LDAP implementation of
> > PolicyRule, because
> > there are existing implementations that use pcimRule.
> > 
> > Thus, my argument stands.
> > 
> > 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: Thursday, June 10, 2004 6:57 PM
> > > To: John Strassner; joel at stevecrocker.com
> > > Cc: David Kessens (E-mail); Wijnen, Bert (Bert)
> > > Subject: RE: [Policy] RE: response to comments on PCELS-05/May 06
> > > 
> > > 
> > > John,
> > > 
> > > pcelsRule [PCELS] is NOT a sibling of PolicyRule [PCIM].
> > > 
> > > pcelsRule [PCELS] is the LDAP implementation of 
> PolicyRule [PCIMe].
> > > 
> > > pcimRuleValidityAssociation [PCLS] is the LDAP implementation
> > > of PolicyRuleValidityPeriod[PCIM].
> > > 
> > > PolicyRuleValidityPeriod [PCIM] is reused AS IS by PCIMe (not
> > > redefined, not changed, not extended).
> > > 
> > > Therefore, PCELS (that implements PCIMe) reuses
> > > pcimRuleValidityAssociation [PCLS] as is. This accurately 
> > > maps the intent of PCIMe (isn't this a technical argument?) 
> > > and does not conflict (as you also admitted) with LDAP 
> > > recommendations.
> > > 
> > > BTW: The OO design has been done when the PCIMe
> > > recommendation was elaborated. PCELS is focused merely on the 
> > > LDAP mapping. So, your OO remarks may be more appropriate in 
> > > the context of a revision of PCIMe but that is outside the 
> > > scope of this discussion. You can not hold PCELS responsible 
> > > for things you don't like in PCIMe.
> > > 
> > > Regards,
> > > Mircea.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: John Strassner [mailto:John.Strassner at intelliden.com]
> > > > Sent: Thursday, June 10, 2004 6:03 PM
> > > > To: Wijnen, Bert (Bert); Pana, Mircea;
> > joel at stevecrocker.com; John
> > > > Strassner
> > > > Cc: David Kessens (E-mail)
> > > > Subject: RE: [Policy] RE: response to comments on 
> PCELS-05/May 06
> > > > 
> > > > 
> > > > I thought I have, but I'm happy to do so again.
> > > > 
> > > > First, it is not an LDAP problem, so I don't see how the LDAP
> > > > Directorate can help. It is a simple Object-Oriented 
> design issue.
> > > > 
> > > > PCIM defined an aggregation, called
> > > PolicyRuleValidityPeriod (which is
> > > > subclassed from PolicyComponent), between
> > PolicyTimePeriodCondition
> > > > and PolicyRule.
> > > > 
> > > > PcelsRule is a SIBLING of PolicyRule, not a SUBCLASS.
> > > Therefore, under
> > > > any definition of object-orientation, the existing
> > > > PolicyRuleValidityPeriod does NOT apply to PcelsRule.
> > > > 
> > > > In order for PolicyRuleValidityPeriod to apply to
> > > PcelsRule, you would
> > > > have to change the definition of the aggregation to be between
> > > > PolicyTimePeriodCondition and the superclass of {PcelsRule and 
> > > > PolicyRule}, which is Policy.
> > > > 
> > > > That is a horrible thing to do, because Policy is the
> > root of many
> > > > things that have nothing to do with this aggregation.
> > > > 
> > > > Which is why I originally said, why not create another
> > subclass of
> > > > PolicyComponent?
> > > > 
> > > > 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.
> > > > 
> > > > In summary, this design is just plain wrong. It has nothing
> > > to do with
> > > > LDAP - it has everything to do with proper OO design.
> > > > 
> > > > 
> > > > 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: Wijnen, Bert (Bert) [mailto:bwijnen at lucent.com]
> > > > > Sent: Thursday, June 10, 2004 3:35 AM
> > > > > To: John Strassner; Pana, Mircea; joel at stevecrocker.com
> > > > > Cc: bwijnen at lucent.com; David Kessens (E-mail)
> > > > > Subject: RE: [Policy] RE: response to comments on
> > PCELS-05/May 06
> > > > > 
> > > > > 
> > > > > Could someone summarize the "technically incorrect" in a
> > > form that
> > > > > WG chair Joel can hand the question to the LDAP 
> directorate for
> > > > > (hopefully) a decisive answer on that?
> > > > > 
> > > > >   http://www.apps.ietf.org/ldap-directorate.html
> > > > > 
> > > > > I think that may be a better approach to try and get some more
> > > > > opinions.
> > > > > 
> > > > > Thanks,
> > > > > Bert
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: John Strassner [mailto:John.Strassner at intelliden.com]
> > > > > > Sent: donderdag 10 juni 2004 03:22
> > > > > > To: Pana, Mircea; 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
> > > > > > 
> > > > > > 
> > > > > > 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