Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

[Barney Wolff <barney@databus.com>]

On Wed, Mar 15, 2006 at 06:31:07PM -0500, Avi Lior wrote:
> 
> So whether or not the attribute is compound or not, if the server needs
> to "interact" with that attribute then it needs to have new code added.
> This applies to any server or client that needs to "interact" with that
> attribute.
> 
> So the notion of dictionary driven code and using existing radius types
> really speaks only about not adding any code to the RADIUS packet
> encoder/decoder. 

RADIUS entities do more than just "interact" with attributes.  They
also display them to humans, transfer them to other applications,
store them, validate them, and so on.  For many of these "peripheral"
purposes, something like a dictionary is helpful.

Of course, a sufficiently fancy dictionary can cope with packed data.
But why should it have to?  What is gained - a few bytes in a UDP
packet?  I am unable to imagine a scenario where the bandwidth sent
or received by a RADIUS entity is a significant issue, even for very
high volume applications.

In my ideal world, there would be an abstract data language akin
to ASN.1 (or ABNF) in which the set of attributes for some feature
could be represented, and there would be automated means to generate
code to handle encoding and decoding.  The abstract data type
definition would be included in the RFC defining the feature.  Why
in the name of Turing do we agree to do this for managing our RADIUS
entities but cannot or will not for the protocol itself?  That goes
double for Diameter.

Barney

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