This proposal breaks that completely. It will be perfectly legal for
> implementations of your proposal to put ALL RADIUS attributes as
> grouped, inside of an "extended attribute". Any NAS that receives
> a response will get a packet containing *nothing* but VSA's. It will
> then decide that there is nothing in the packet that it recognizes, and
> will fail.
> i.e. your proposal creates a new protocol that is incompatible with
> legacy RADIUS.
Presumbably new attributes using the extended format will define
whether they can be grouped or not, and if so, what the grouping
But what about legacy attributes? For example, what would it mean for a
NAS-Identifier attribute to be grouped with say, a Tunnel-Password
attribute? Presumably, this document would not define the semantics
of grouping for legacy attributes, which begs the question of where,
if anywhere, that semantic would be specified.
Presumably, the implementors would be interested in
actually accomplishing something & not merely playing word games &
landing red herrings. They also might not ignore the second word in the phrase
"group related attributes" which occurs at least 6 times in the
draft. Are NAS-Identifier & Tunnel-Password related
attributes? If so, and someone wanted to group them together, that could
Unless that semantic is specified somewhere (and I doubt it would be
specified anywhere for a substantial period of time), then the semantics
of grouping of legacy attributes is likely to be "implementation
Why is it necessary to specify the semantics of every possible
combination of RADIUS attributes? Obviously, it's not; all that is
required is to define those groups that are useful, which in any reasonable
process could be done as the utility of those groupings became apparent.
So not only would the "new" RADIUS not be backward compatible with
the old one -- it wouldn't even have a public specification.