Re: Questions on modified Extended Attribute format?

[Barney Wolff <[e-mail]>]

On Thu, Jan 10, 2008 at 02:52:16PM -0800, Glen Zorn wrote:
> 
> > 
> >   For a total of 10 bytes of header for one attribute.
> > 
> >   The "Diameter AVP in RADIUS" involves:
> > 
> >    new attribute header: 2 bytes
> >    Diamater header: 8 bytes (4 byte type + 4 byte length)
> 
> Pardon me: 4 byte type, 1 byte of flags (BTW, are those 8 bits of flags
> actually useful in RADIUS?) and a 3 byte length.  
> 
> > 
> >   For a total of 10 bytes.  Plus, conversion to Diameter in Diameter
> > to RADIUS gateways is easy.  We can get arbitrary grouping via the
> > Diameter method.  We can have attributes as long as we want.  
> 
> Really?  The "new attribute header" that you conveniently gloss over
> above contains a 1 octet total length for the attribute, giving the same
> length limit as old-style RADIUS; of course, you could always either a)
> just concatenate "Diameter AVPs" of the same AVP type together (but then
> you can only have one AVP of a given type in a message) or b) add an
> "awkward" continuation BIT to the Flags field of the AVP...

Well, no.  The proposal was that all the EA TLVs would be concatenated
before being decoded, so the Diameter length fields would delimit the
attributes.  No continuation bits, bytes or logic.  And of course, the
totality of EAs could/should be packed into as many full RADIUS TLVs as
necessary, with much less TL overhead.

Allow me to express some wry amusement that the pretext for rejecting
the Diameter-format proposal was that only attribute typespace exhaustion
was of interest, not attribute length or grouping.  Then, magically,
length and grouping came back.  Being retired, at least I won't have
to code whatever y'all eventually agree on.

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


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>