Re: 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
[email protected]



                                                                                                                                       
                      Mircea Pana                                                                                                      
                      <mpana@metasolv.         To:       [email protected]                                                                 
                      com>                     cc:       [email protected], [email protected], [email protected]                      
                      Sent by: policy-         Subject:  Re: [Policy] Last Call: Policy Core Information Model Extensions  toProposed  
                      [email protected]            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
> [email protected] or [email protected] 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/policy

----- Message from Mircea Pana <[email protected]> on Wed, 03 Apr 2002 11:
57:46 -0500 -----
                                                                                                                        
      To: [email protected]                                                                                          
                                                                                                                        
      cc: Andrea Westerinen <[email protected]>, IETF Policy <[email protected]>, "Wg-Policy@Dmtf. Org" <wg-policy@dmtf.  
          org>, "Wg-Network@Dmtf. Org" <[email protected]>                                                            
                                                                                                                        
 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: [email protected] [mailto:[email protected]]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
> >> [email protected]
> >> https://www1.ietf.org/mailman/listinfo/policy
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: [email protected]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus


_______________________________________________
Policy mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/policy