[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new Service-Type
David B. Nelson wrote:
> One of the properties of a standard protocol is that the code-points are
> controlled and universally understood. If you want to have a private
> version of the foo-bar protocol, then it doesn't matter what code-points you
> use in your implementation, as they will not be encountered by
> standards-compliant implementations. In that case, however, you need not
> engage the IETF at all. The reason for standards is for plug-'n-play
> interoperability.
No argument there.
>> The alternative is to perform allocations for every little
>> variation of every little application, which will not scale.
>
> That depends, I suppose, on whether you think of RADIUS as a standardized,
> interoperable protocol or simply a convenient a transport for proprietary,
> boutique applications.
Realistically, all protocols are used in both scenarios. In some
cases, it's simpler, cheaper, and easier to deploy localized
non-standard and non-interoperable solutions... especially where those
solutions are intended to never inter-operate with other deployments.
The question for this document is whether or not it falls into the
first set, or the second.
If there is only one application that needs these values, I see no
point in standardizing them. If there is only one implementation, it
is, by definition, non-interopable with anything else,
Non-interoperable implementations have no requirements for
inter-operability. The vendor can use VSE's, or poach on the IANA
space. It's up to him. And since his implementation is already
non-interoperable, it won't affect anyone else.
And doesn't the IETF process generally require two inter-operable
implementations? If there is no second implementation that will support
this functionality, why can we not push off the discussion until there
is an inter-operable RADIUS client?
Alan DeKok.
--
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/>