One thing I noticed in Section 2.1.3 was the following sentence: " For data types not supported by current RADIUS server dictionaries, changes to the dictionary code can be required in order to allow the new type to be supported by and configured on the RADIUS server. " In Issue #325, it was pointed out that new data types can initially be sent by a RADIUS server by configuring them as Strings. So code changes are required only to enable RADIUS server to receive and parse the new data types, not to send them. Of course, changes to the dictionary are necessary to improve the convenience with which the new data types can be entered. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Tuesday, January 19, 2010 10:55 AM To: Joseph Salowey (jsalowey) Cc: Bernard Aboba; radext mailing list Subject: Re: Proposed resolution to Issue 325 Joseph Salowey (jsalowey) wrote: After seeing all the > discussion on the list, I think there still is some question over when > to use complex/new data types and when not to. There are few "hard and fast" rules. > I'm not sure this is easily resolved. I agree. > The document favors reducing complexity in certain aspects of server > implementation. This may be appropriate for some cases, but in others > it may be appropriate to reduce complexity in another area, such as on > the NAS. The document doesn't seem to be very clear on this, but > perhaps it doesn't intend to or need to be. I welcome *any* text that makes simple && clear recommendations. 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/>
<<attachment: winmail.dat>>