RE: new Service-Type

["David B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...
 
>   If there is not a strong demand for RADIUS allocations, 
> then the deployments using the new numbers are few and far 
> between.  In that case, it matters little to the rest of the
> world which numbers are used.

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.

If there is a chance that your "walled garden" will ever open up and
interact with the rest of the world, however, non-assigned code-points are a
very bad practice, indeed.

The fact that VSEs poach on high-valued regions of the code-point space,
that IANA is never likely to reach, does make them "work".  It does nothing
to promote interoperability, however.

>    In that case, I would recommend VSE's.

I, on the other hand, would never recommend VSEs.  In my opinion VSEs for
Service-Type violate the RADIUS IANA Considerations RFC.  

>   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.




--
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/>