Re: [Policy] Last Call: Policy Core Information Model Extensions toProposed Standard

Mircea,

Sorry - we have been very slow responding to you here.  I talked this over
with Lee and Andrea, and we, at least, have no problem with aligning both
PCIMe and the DMTF model on your proposed text:

" 5.21. The Class FilterList

   This is a concrete class that aggregates instances of (subclasses of)
   FilterEntryBase via the aggregation EntriesInFilterList.  It is possible
   to aggregate different types of filters into a single FilterList - for
   example, packet header filters (represented by the IpHeadersFilter
class)
   and security filters (represented by subclasses of FilterEntryBase
   defined by IPsec).

   The aggregation property EntriesInFilterList.EntrySequence is always
   set to 0, to indicate that the aggregated filter entries are ANDed
together
   to form a selector for a class of traffic."

Unless somebody else objects, I'll make this update to PCIMe after it exits
IETF Last Call.  (I want to wait until then in case there are other changes
that come out of Last Call - we should be able to make do with just one
more revision.)

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

                      Mircea Pana                                                                                                      
                      <mpana@metasolv.         To:       iesg@ietf.org                                                                 
                      com>                     cc:       policy@ietf.org, brunner@ccrle.nec.de, andreaw@cisco.com                      
                      Sent by: policy-         Subject:  Re: [Policy] Last Call: Policy Core Information Model Extensions  toProposed  
                      admin@ietf.org            Standard                                                                               

                      05/06/02 09:42 AM                                                                                                
                      Please respond to                                                                                                
                      mpana                                                                                                            

The "FilterList and EntriesInFilterList" issue, discussed in the attached
message, has not been closed yet. I would appreciate if the authors of
PCIMe could address it.

Thanks,
Mircea Pana.

The IESG wrote:

> The IESG has received a request from the Policy Framework Working Group
> to consider Policy Core Information Model Extensions
> <draft-ietf-policy-pcim-ext-07.txt> as a Proposed Standard.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by May 17, 2002.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-07.txt
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

----- Message from Mircea Pana <mpana@metasolv.com> on Wed, 03 Apr 2002 11:
57:46 -0500 -----

      To: brunner@ccrle.nec.de                                                                                          

      cc: Andrea Westerinen <andreaw@cisco.com>, IETF Policy <policy@ietf.org>, "Wg-Policy@Dmtf. Org" <wg-policy@dmtf.  
          org>, "Wg-Network@Dmtf. Org" <wg-network@dmtf.org>                                                            

 Subject: Re: [Policy] FilterList and EntriesInFilterList in PCIMe                                                      

Marcus,

I agree that this restriction should be generally applicable through PCIMe
to
submodels. Andrea's mail seemed to suggest that the restriction would only
apply to DiffServ/QoS. This is where my first issue came from.

In the second issue, I compare "FilterList" with "CompoundContition".
Either
can be used to aggregate a Set of traffic selection criteria. IMO either
both
or none of them should allow component ordering. My preference is for no
ordering.

So, the text in PCIMe would read:

" 5.21. The Class FilterList

   This is a concrete class that aggregates instances of (subclasses of)
   FilterEntryBase via the aggregation EntriesInFilterList.  It is possible
   to aggregate different types of filters into a single FilterList - for
   example, packet header filters (represented by the IpHeadersFilter
class)
   and security filters (represented by subclasses of FilterEntryBase
   defined by IPsec).

   The aggregation property EntriesInFilterList.EntrySequence is always
   set to 0, to indicate that the aggregated filter entries are ANDed
together
   to form a selector for a class of traffic."

Regards,
Mircea.

Marcus Brunner wrote:

> Mircea,
>
> --On Tuesday, March 05, 2002 5:48 PM -0500 Mircea Pana <mpana@metasolv.
com>
> wrote:
>
> > Andrea,
> >
> >
> > I have two issues that are somewhat related to each other:
> >
> > 1. If the restriction only applies to DiffServ then why is it defined
in
> > PCIMe? If, as you explain, this restriction is there to align with the
> > DiffServ model then (IMO) QPIM would be a better place for it. PCIMe
> > would simply indicate that if sequencing is not intended then the value
> > "0" is to be used and as result the aggregated filters are ANDed.
> >
>
> It is defined in PCIMe because we want to use it in other models (e.g.
> MPLS), and has been regarded very general.
>
> Does your mail mean that the text proposal from Andrea is not what you
want
> to see?
>
> > 2. However, if PCIMe allows sequencing for device-level filters (a
> > FilterList of FilterEntries), then why doesn't it have the same
> > functionality for the domain-level equivalent (a CompoundCondition of
> > CompoundFilters)? I understand that the consensus is against component
> > sequencing in the PCIMe CompoundCondition. Maybe the sequencing should
> > be removed from the FilterList on the same premise that devices, due to
> > their implementation, may not be able to honor it.
>
> I am sorry, but do not understand what you mean.
>
> Marcus
>
> > Regards,
> > Mircea.
> >
> >
> >
> >
> >
> > Andrea Westerinen wrote:
> >>
> >> Mircea, When the restriction was originally discussed, it was put in
> >> place to align the model with the DiffServ Informal Model.  IE, to put
a
> >> default value in place such that the property COULD be used but may
also
> >> be ignored (and the default taken).  So, this was specifically about
QoS
> >> and not about the general model.  I am not sure where it got
generalized
> >> - or that it even should be generalized.  I would recommend that we
> >> remove the word "always" in the phrase "always takes its default
value"
> >> (Section 4.9.2).  "Typically" or "usually" seems safer.
> >>
> >> The original thinking was to include all the model properties and
align
> >> the IETF and DMTF work, but also specify the "expected" defaults.
> >>
> >> Andrea
> >>
> >> -----Original Message-----
> >> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of
> >> Mircea Pana
> >> Sent: Monday, March 04, 2002 8:28 AM
> >> To: IETF Policy
> >> Subject: [Policy] FilterList and EntriesInFilterList in PCIMe
> >>
> >> The "FilterList" class imported from CIM, is redefined by PCIMe with
an
> >> additional restriction relative to the "EntriesInFilterList"
> >> aggregation. This restriction is described in both Sections 4.9.2 and
> >> 5.21.
> >>
> >> The two descriptions seem to be somewhat contradictory. Thus, while
> >> 4.9.2 indicates the applicability of this restriction to *all* the
> >> submodels:
> >>
> >> "For PCIMe and its submodels, the EntrySequence property in this
> >>  aggregation always takes its default value '0', indicating that
> >>  the aggregated filter entries are ANDed together."
> >>
> >> in section 5.21 the scope seems to be reduced to QoS submodel(s)
*only*:
> >>
> >> "In modeling QoS classifiers, however, this property is always
> >>  set to 0, to indicate that the aggregated filter entries are
> >>  ANDed together to form a selector for a class of traffic."
> >>
> >> In section 5.21, was the reference to QoS intended as a scope
limitation
> >> or was that used as example? IMO clarification is necessary.
> >>
> >> Regards,
> >> Mircea.
> >>
> >> _______________________________________________
> >> Policy mailing list
> >> Policy@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/policy
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus

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

Re: [Policy] Last Call: Policy Core Information Model Extensions toProposed Standard

Attachment: graycol.gif

Attachment: ecblank.gif