Subject: [Policy] FilterList and EntriesInFilterList in PCIMe

From: Mircea Pana <[email-masked]>
Date: Mon, 04 Mar 2002 11:28:00 -0500

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

---

From: "Andrea Westerinen" <[email-masked]>
Date: Mon, 4 Mar 2002 23:57:40 -0800

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Mircea Pana
Sent: Monday, March 04, 2002 8:28 AM
To: IETF Policy
Subject: [Policy] FilterList and EntriesInFilterList in PCIMe

Regards,
Mircea.

---

From: Mircea Pana <[email-masked]>
Date: Tue, 05 Mar 2002 17:48:17 -0500

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.

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.

Regards,
Mircea.

---

From: Mircea Pana <[email-masked]>
Date: Tue, 26 Mar 2002 10:38:17 -0500

I haven't received any response to these issues and I'm not quite sure what would
be the reason:

1. They don't make any sense at all. Please excuse me!
2. They are still discussed among the authors and a common opinion hasn't been
reached yet.
3. They are low priority waiting to be addressed, while other issues are getting
the authors attention.
4. They have been missed due to the high quantities of spam mail we are all
getting from public mailing lists.

Regards,
Mircea.