RE: Extended Filter attribute: Change summary from -01 to 02; Issues score card review

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Sanchez, Mauricio (ProCurve) <> allegedly scribbled on Monday, March 19,
2007 3:18 AM:

> For those keeping track, the extended filter draft
> (draft-ietf-radext-filter-rules-02.txt ) has been an active working
> group item for over two years in one form or another.  At the rate
> it's going, we may all retire before it's complete. ;) Anyway.  
> 
> Substantive changes from version -01 to -02
> -------------------------------------------
> 1. Removed requirement that rule types appear in a specific order by
> removing text: "Furthermore, if the list contains different types of
> rules, they MUST appear in the following order: flush rules, base
> encapsulation tunnel rules, base encapsulation filter rules, IP
> tunnel rules, HTTP redirect rules, IP filter rules, and HTTP filter
> rules."  (Section 2.5)     
> 
> The above change address should address part of Issue 170 (Precedence
> and order for NAS-filter-rule). 
> 
> 2. Updated attribute behavior in presence of NAS-filter-rule:
> "Filter-ID (11), NAS-Filter-Rule [Filter] and NAS-Traffic-Rule
> attributes define how filters are to be applied in the NAS. These
> attributes are not  
> intended to be used concurrently and          SHOULD NOT appear in
> the same 
> RADIUS message. Only one type of filtering attribute must be
> processed. If a Filter-ID (11) is present, then the NAS-Traffic-Rule
> MUST be ignored, if present." (Section 2.5)  
> 
> 3. Added a version label prefix to rule syntax.  Each rule now
> includes a "v1" prefix designating the rule as conforming to version
> 1 of traffic-rule syntax.  The idea here is to allow future
> updates/changes to the rule syntax without having to define another
> attribute and burn another type number.    

I was under the impression that we had decided to use the new extended
attribute format for this, thus obviating the concern about 'burning
another type number'.

> 
> 4. Re-did the Diameter Considerations section [5].  Now are using the
> same approach employed by rfc4675 (RADIUS attributes for virtual LAN
> and priority support).  The approach eliminates the need to re-create
> a diameter-specific version of nas-traffic-rule and rather relies on
> the general radius<->diameter interoperability mechanisms.  I do have
> a question as to whether the diameter value type specified
> (OctetString) is the right one or not.  I'm no diameter value type
> expert, so feedback welcome.   

A far better idea would be to get rid of the OS-specific Diameter stuff
& define an extensible grouped AVP for filters.  
    
...

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>