Subject: Issue 314: My Problem

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Sep 2009 17:30:27 -0700

Issue 314: My Problem

Submitter name: Hannes Tschofenig  

Submitter email address: [email-masked]

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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Sep 2009 15:15:24 +0200

> The document assumes a certain implementation and processing model.

  Maybe the document isn't clear.  It assumes a certain *data* model for
RADIUS.  It assumes that maintaining that data model is a good idea.  It
explicitly states that a *typical* RADIUS server uses a data dictionary:

  Section 2.1.3 says:

   ... RADIUS server implementations
   typically provide support for basic data types, and define attributes
   in a data dictionary.  ...

  Maybe this should be "MANY RADIUS server implementations..."

  Or "RADIUS server implementations have traditionally provided support..."

> This

  Even if an implementation can easily handle complex attributes defined
in a "dictionary", is there any *reason* to use complex attributes where
the standard data types would be sufficient?

  If not, then the existing text would seem to be sufficient.

> understanding of some of the claimed limitations might also be clearer.

  The draft explicitly mentions a *typical* data model implemented by a
RADIUS server.

  As for making the limitations clear, the document already does that.
It states that the data dictionary approach means that it allows:

   ... RADIUS servers to be configured to support new attributes
   without requiring server code changes.  ...

  Should we add some text here saying:

  "Some implementations can support more complex attributes defined in a
more complex dictionary than is traditional.  However, this document
does not recommend defining complex attributes for all of the reasons
outlined in Section 2.1.3"

  I fail to see how that will help.

  The text allows more complex implementations of dictionaries.  Nothing
in the text *forbids* more complex implementations of dictionaries.
Nothing in the text suggests that it is a good idea to use complex types
where standard types would suffice.  The document already discusses the
typical model, along with its limitations.

  So... why do we need to say any more?

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>