|
> 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 such > 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 means. 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. 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 specific". So not only would the "new" RADIUS not be backward compatible with the old one -- it wouldn't even have a public specification. |