[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Review: RADIUS Filter Attribute Document
I still strongly feel the tag scheme is needlessly complex for what it
intends to achieve.
Simple is better, of course.
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.
Right.
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.
Since in practice the rules are only expressed in ASCII, \0 would work.
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.
It should be easy to implement, either in a NAS or in a RADIUS/Diameter
gateway. Do we even need a tag at all if we adopt this proposal?
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.
--
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/>