Issue 314: My Problem
Submitter name: Hannes Tschofenig
Submitter email address: Hannes.Tschofenig@gmx.net
Date first submitted: May 9, 2009
Reference:
http://ops.ietf.org/lists/radiusext/2009/msg00237.html
Document:
Design-Guidelines
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
The document assumes a certain implementation and processing model. This
model is not explicitly documented in the draft and unfortunately has
implications on the design of attributes particularly when it comes to data
types used by RADIUS attributes and for the claimed problems that arise from
adding new code to the RADIUS server.
In previous mail exchanges on the list I did not agree with certain aspects
of the implicitly assumed progressing model. I am, however, OK with
documenting the model and to thereby make it explicit to the reader. The
understanding of some of the claimed limitations might also be clearer.
PS: FYI, I stated my concerns previously on the RADEXT list.
[Alan DeKok] Do you have suggested text for the document?
[Hannes]
I can compile some text but this is not saying that I agree with the assumed
model, i.e. one where essentially no improvement in implementations was made
over the last 10 years.
[David Nelson]
Perhaps, but this seems to presume that data-dictionary-driven server
implementations are a liability which requires improvement. Like a network
management application for SNMP which has the ability to "enroll" a MIB
module without code changes, a RADIUS server that can simply add new
attributes to its dictionary is a boon to users.
We can split hairs about what types of user-added executable scripts are or
are not "coding". I still think that the data dictionary architecture is a
very powerful concept. Not to mention a very widely deployed one.
|