Re: Request for Review: RADIUS Filter Attribute Document

[Barney Wolff <barney@databus.com>]

On Wed, Oct 18, 2006 at 06:12:40AM -0700, Bernard Aboba wrote:
> >I am increasingly convinced that the attempt to re-use the tag mechanism
> >for segmentation and concatenation is misguided and will lead implementers
> >into trouble.
> 
> Question:  what do you think of Emile's proposal to just use a \0 as a 
> delimiter?  It would appear that this approach doesn't require any tags at 
> all.

I have mixed feelings.  On the one hand, there is precedent for glomming
all instances of an attribute together, for EAP.  On the other, EAP is
different in that the RADIUS code does not parse the result.  What will
happen with the next attribute, where a byte value of 0x00 may be valid?

I wish the WG would support solving the problems of attribute type
exhaustion, grouping and length limitation once rather than re-invent
polygonal wheels endlessly.  Ok, if the Diameter attribute header is too
big, ugly and NIH to be accepted, RADIUS can have its own extended
attribute header.  But if we're going to bite that bullet, we SHOULD first
agree on requirements and how competing proposals will be evaluated,
before making proposals.  To repeat approximately a slide from last March,
here is my view:

Criteria for evaluating extended attribute format
    This is Transfer syntax, must support desired power & flexibility
      available to definers of new RADIUS features
    Top priorities
        remove 255 limit on attribute type number
        remove 253 limit on attribute value length
        support rich set of standard attribute value types
        support grouping
        easy transition of attributes from vsa to standard
    Mid priorities
        ease of gatewaying <-> Diameter
        support multi-level (nested) grouping
        M-bit
        build on / re-use existing work
    Low priorities
        minimal attribute header size
        elegance, alas

Alternatively, we could with little loss of realistic function simply
declare that no filter rule can exceed 253 bytes.

-- 
Barney Wolff         I never met a computer I didn't like.

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