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

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

Sanchez, Mauricio (ProCurve) <mailto:mauricio.sanchez@hp.com> allegedly
scribbled on Monday, March 19, 2007 8:51 AM:

> Glen proclaimed...

Proclaimed? ;-)

> 
>> -----Original Message-----
>>> 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'.
> 
> [MS1] Well, even if consuming type is no longer an issue, wouldn't
> you agree that it would be cleaner to modify the same attribute than
> defining an entirely new attribute every time a rule syntax update
> was necessary?   

Absolutely; I think that a "grouped AVP" type of thing might make that
even easier...

> 
> 
>>> 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.
> 
> [MS1] Can you described the pain point(s) you're experiencing with
> Diameter's current syntax approach?  I guess I question whether
> Diameter's chosen approach is truly broken enough to merit a complete
> re-write.   

Basically the same thing you mentioned above: using a string means you
have to create a new AVP every time you need to filter something else.  

> 
> Cheers,
> MS

--
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/>