David
Nelson said:
> In seeking to debunk some of these data model additions, you are
apparently
> attempting to build a case for the precedence of using the RADIUS String
> data type to contain non-self-describing data structures. This has been a
> point of debate in the RADEXT WG for several years. The WG consensus is
> captured in the Design Guidelines draft. The String data type should be
> used for actual strings, or for opaque blobs of binary data, for use in
some
> other protocol component, e.g. EAP. There are specific exemptions to this
> recommendation that are spelled out in the draft.
In many ways, this argument has long been Overtaken By Events (OBE).
RADIUS
is what it is, and very widely deployed protocol. The Design Guidelines
only
attempts to describe RADIUS as it is, not what it should become.
OK, so now I’m completely confused. If the purpose
of the document isn’t to give guidance regarding the design of future
attributes, what is it? Aside from that, even as a description of RADIUS “as
it is” the document fails, since it denigrates without justification
(aside from the spurious “code change” argument) the so-called “complex”
attributes that have been part of RADIUS for almost a decade.
…