Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66

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

Hi,

On Mon, Jul 10, 2006 at 06:10:12PM -0400, Alan DeKok wrote:

>   I support extending the RADIUS attribute space.
> 
>   I also think that the *format* (i.e. encoding) of the extended
> attribute space is a separate issue to extending RADIUS with Diameter
> features.  i.e. TTLS uses the Diameter AVP format, but few to none of
> the features.  A few hundred lines of code are sufficient to implement
> Diameter AVP encoding, which mitigates concerns over parsing &
> dictionary support.
> 
>   To put it another way, we should standardize on the extended format
> first, and explicitely reject any attempt to mingle the work on
> extended attribute space with additional work like grouping and new
> data types.  Once we have a larger attribute space standardized, later
> documents can add features for those applications that need them.

Hear, hear. 

I very much like such a layered approach. 

Incidentally, my earlier suggestion for the extended header format [1]
doesn't necessarily concern itself with data types or grouping; other
than extending the 1 octet attribute type to a 32 bit space/vendor field
and 32 bit type field, it just reserved two byte fields for a tag and
child tag in its header. That's it, it doesn't care about the type or
syntax of the value field at all. That's entirely attribute dependent.

The tag field is there to create compatibility with RFC 2868 sensible
way; the combination of tag and child tag also allows you to put
grouping/nesting on top of any attribute, whenever desireable, by
allowing any tagged or non-tagged attribute to refer to any tagged set
as its children. So the nested tree structure containing A/V pairs is
separate from the contents of the value fields.

A nice effect of creating the grouping tree using two columns is that
you can represent the tree using a flat table, which makes conversion
from and to databases and log files both trivial and lossless. You don't
have to think long and hard about the external representations of
requests or replies containing physically grouped types as is the case
with DIAMETER.

At any rate, no proposed format contains an attribute header field
referring to a data type ID (which is a very good thing, IMHO), so the
data type remains wholly attribute dependent, thus that issue is also on
a layer above the extended format itself.

Cheers,


Emile.

[1] http://www.xs4all.nl/~evbergen/ietf/draft-evbergen-radext-extended-attribute-02.txt

    Note that it should be rewritten; it contains too many ideas and
    solutions in too few sections, but I didn't take the draft further
    so far due to lack of time and apparent lack of interest from the
    group.

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