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

[Mircea Pana <[e-mail]>]

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
> [e-mail] or [e-mail] 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/policy

--- Begin Message ---

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 <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]]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
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/policy
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: [e-mail]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus


_______________________________________________
Policy mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/policy

--- End Message ---