RE: FilterList in IPSP context

["Andrea Westerinen" <andreaw@xxxxxxxxx>]

Actually, the CR is on the docket for discussion on next week's Network
call.  It just adds a default value of 0 to the property in the aggregation.
This CR is part of the realignment of the QoS work between DMTF and IETF.
It will be released as part of CIM V2.7 Networks.

In the end, documenting either PCIMe or CIM Networks will be the same :-).
However, it will not be a mandatory value in CIM Networks - since it has no
reason to exist if all that we do is AND together FilterEntryBases.

Andrea

-----Original Message-----
From: Lee Rafalow [mailto:rafalow@xxxxxxxxxxxxxx]
Sent: Monday, March 04, 2002 9:09 AM
To: mpana@xxxxxxxxxxxx; ipsec-policy@xxxxxxxx
Cc: wg-network@xxxxxxxx
Subject: Re: FilterList in IPSP context


Another good catch Mircea.

If I remember correctly, our intent was to change CIM as well but I don't
see a Change Request anywhere.  For simplicity for now, we should make
another edit to the IPsec Configuration Policy Model so that it points to
PCIMe rather than CIM.

Thanks, Lee
----- Original Message -----
From: "Mircea Pana" <mpana@xxxxxxxxxxxx>
To: <ipsec-policy@xxxxxxxx>
Sent: Monday, March 04, 2002 10:58 AM
Subject: FilterList in IPSP context


>
> The IPSec Policy model uses "FilterList" and indicates that it is
> defined in "[CIMNETWORK]".
> On the other hand, the IPSec Policy model is based upon the core policy
> classes defined in PCIM and PCIMe. The later redefines the "FilterList"
> class with an additional restriction relative to the redefined
> "EntriesInFilterList" aggregation. See PCIMe Section 4.9.2 second
> paragraph and Section 5.21 second paragraph.
>
> Does the restriction defined by PCIMe apply in the context of IPSP
> submodel? Or does IPSP override the PCIMe "FilterList" semantics with
> the original CIMNETWORK ones?
>
> Regards,
> Mircea.
>