RE: Proposed Resolution of Issue #318: REJECT

["Glen Zorn" <glenzorn@comcast.net>]

Dave Nelson [mailto://d.b.nelson@comcast.net] writes:



> Glen Zorn writes...
> 
> > My assertion is that correctly implemented code changes (maybe
> > that's asking too much?) do not effect interoperability, nor
> > does requiring such cause harm.
> 
> Your assertion is that correctly implemented code changes at both the
> client
> and server ends of a client-server protocol implementation would not
> affect
> interoperability.  True, as far as it goes.  The point that is being
> addressed in the RADIUS Design Guidelines is that *requiring* code
> changes
> on the sever side, when a data dictionary change alone would suffice,
> is
> harmful to interoperability, or at least forces maintainers of server
> implementations to make code changes they would not otherwise have to
> make.

This claim is valid only for some (primitive) implementations.  I am
currently running a RADIUS server (w/a nice GUI, no less) that will handle
any length of integer, signed or unsigned, (not to mention arbitrary
"complex" attributes) with only a dictionary change or two.  It's hardly
rocket science to build a flexible, data-driven parser and I'm actually
personally offended by the attempt to standardize this kind of weak design.

> The guidelines discourage attribute design choices that would force a
> code
> change on RADIUS servers when no such change would be required with a
> more
> "traditional" choice of attribute design.
> 
> I suspect you don't attach much value (or even credence) to this data-
> driven
> model on the server side, but many in the RADIUS community do.

In fact I hold the idea in great esteem; what I disvalue is the idea that
data-driven models have to be implementable by below-average high-school
kids.  


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