[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: My problem with draft-ietf-radext-design



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. 

>-----Original Message-----
>From: Alan T DeKok [mailto:aland@freeradius.org] 
>Sent: 11 May, 2009 16:15
>To: Hannes Tschofenig
>Cc: 'Glen Zorn'; 'Dave Nelson'; 'Jari Arkko'; 
>gdweber@gmail.com; draft-ietf-radext-design@tools.ietf.org; 
>iesg@ietf.org; radext-chairs@tools.ietf.org; 'radext mailing list'
>Subject: Re: My problem with draft-ietf-radext-design
>
>Hannes Tschofenig wrote:
>> The document assumes a certain implementation and processing model.
>
>  Yes.  This model goes back to the original Livingston 
>server, and is at least consistent with all existing RADIUS 
>servers.  i.e. the use of static dictionary files.
>
>  Some RADIUS servers offer *additional* functionality, but 
>this practice is not ubiquitous.
>
>> 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.
>
>  The goal of the document is to describe recommended 
>practices that will result in wide adoption of any proposal.  
>Using the lowest common denominator for RADIUS dictionary 
>capabilities gives the wides possible adoption.
>
>  Other capabilities can be added with new code such as 
>scripting languages (Perl, Python), C / C++, or Java.  Many 
>implementations also support simple programmatic capabilities 
>to describe new data types.
>
>  But these capabilities are not *ubiquitous*.
>
>> 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.
>
>  Do you have suggested text for the document?
>
>  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/>