[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "Last Look" at the RADIUS Design Guidelines document
> Which is fine but I think you have to document this distinction.
> That is a problem with this BCP only people who read these long
> email threads will understand what is really going on. If the
> intent is to protect the existing radius base then we should be
> clear about that.
The primary intent is to promote *extension* of the RADIUS protocol rather
than *revision* of the RADIUS protocol. That is to say, to use
well-accepted mechanisms for forward-backward protocol extensions, rather
than simply revising the data model without any concern about compatibility
with existing deployments. This is the way that IETF-Standards track
protocols are "evolved", via extension, rather than via revision. Certainly
interoperability with a broad range of implementations, some of which may
qualify for the term "legacy", is an important factor. That's one reason
that vendors like to implement standards -- they don't expect them to change
in non-backward-compatible ways over time.
There are examples of protocol revision in the IETF, of course, such as IPv4
and IPv6, but that's not what we're about here. We already have RADIUS V2
and it's called Diameter.
I fail to understand the point of most of the arguments against this BCP,
unless it's to "protect" a "revised" dialect of RADIUS as implemented in
some "modern" RADIUS server implementations. If RADIUS has become
fragmented into non-interoperable dialects, I think that would be very sad
indeed. In that case, I don't see the advantage of legitimizing that
fragmentation by trying to "gut" the core recommendations of this BCP or to
narrow its scope to some "legacy" or "historic" segment of the RADIUS server
market. It seems to me that's where this discussion is ultimately leading
Have I missed an important point somewhere?
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.