Re: Request for Review: RADIUS Filter Attribute Document

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Tue, Oct 17, 2006 at 07:01:57PM -0700, Bernard Aboba wrote:

> The RADIUS Filter Attribute document has gone through another revision to 
> address the filter continuation issue.  Please review the current version 
> and send comments to the WG list:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-02.txt
> 
> Are the changes an improvement?

I still strongly feel the tag scheme is needlessly complex for what it
intends to achieve. 

Also, the requirement that even though the attribute has a tag, a strict
ordering of attribute instances must be maintained /disregarding the
tags/, meaning that you have to maintain the order in which the tagged
sets appear, including their interleaving, seems a little at odds with
the spirit of other uses of tags, such as eg. RFC2869. Of course it is
allowed because of the ordering requirements in RFC2865, but it creates
a new requirement from a tagged attribute viewpoint.

With 'normal' tagged attributes, there is no relative ordering between
tagged sets that must be maintained, i.e. for most purposes you can
consider an attribute with a different tag a wholly different attribute
type.

I think there is a simpler solution, /if/ you let go of the desire to
represent a single rule in a single attribute 'most of the time'. 

Once you do that, you can specify that in order to interpret
NAS-Filter-Rule, the values of /all/ instances must first be bluntly
concatenated based on their normal order of appearance (as also done for
EAP; it's perfectly OK to rely on relative ordering among attributes
having the same type and tag), and then split using a simple delimiting
to obtain the individual filtering rules.

Whether that splitting is done the same way as in DNS (a length byte (in
our case that would be 2 bytes) before every individual rule), or using
a real delimiter (\0, \n, whatever, anything that does not appear in an
individual filter rule), is mostly a matter of taste.

To my mind, such an approach to long attributes (concatenate first; then
resplit if necessary) is both more generic and simpler, and solves the
issue at hand.

Because of its layering, it's also more future proof, as the upper half
of the solution (splitting) may be preserved when other generic methods
of transporting longer values appear, and creates a useful de-facto
representation of a rule set as a single octet string as a byproduct;
the lower half of the solution -- the method of encoding a single long
attribute by plain concatenation of RADIUS attributes -- can also be
used for other attribute types and delimiting styles.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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