Subject: Re: Proposed resolution to Issue 325

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 19 Jan 2010 09:15:40 -0800

Do the changes made below address your issue?
http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, January 19, 2010 9:12 AM
To: Bernard Aboba
Cc: 'radext mailing list'
Subject: Re: Proposed resolution to guidelines document

Bernard Aboba wrote:
> Do these changes address Issue #325?  

  Comments:

  (A) addressed by updated text on "new" data types, rather than
"complex" types

  (B) addressed by moving the text to the security section, and
replacing discussion of "application" with "other systems".  Also
addressed security issues of complex types by noting more clearly that
*change* has security implications.

  (C) previously fixed

  (D) Not addressed.  We seem to disagree on the utility of the
recommendations.

  (E) previously answered && acknowledged as closed on-list.

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 19 Jan 2010 10:41:20 -0800

For the most part the revision looks OK.  I'm OK with recommending to
try to use existing types and resort to complex/new types if there is a
compelling reason not to use the basic types. 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.  I'm not sure this is
easily resolved.  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.  

Cheers,

Joe

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Bernard Aboba
> Sent: Tuesday, January 19, 2010 9:16 AM
> To: Joseph Salowey (jsalowey)
> Subject: Re: Proposed resolution to Issue 325
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 19:55:04 +0100

Joseph Salowey (jsalowey) wrote:
 After seeing all the
> 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

  I welcome *any* text that makes simple && clear recommendations.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 19 Jan 2010 13:25:30 -0800

WARNING: contains banned part

Subject: RE: Proposed resolution to Issue 325
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Joseph Salowey \(jsalowey\)'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Date: Tue, 19 Jan 2010 13:25:30 -0800
List-Id: <radiusext.ops.ietf.org>

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: [email-masked] [mailto:[email-masked]] 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

  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.

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Jan 2010 08:30:45 +0100

> to improve the convenience with which the new data types can be entered.  

  I think that's partially covered by saying "changes CAN be required".

  Do we need specific text saying how new types can be entered as strings?

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 20 Jan 2010 07:53:22 -0800

Alan said:

"  I think that's partially covered by saying "changes CAN be required".

  Do we need specific text saying how new types can be entered as strings?"

That was one of the points made in Issue #325 -- that it is possible to
enter 
any attribute type as a string on the server, without a dictionary change.  
Of course, code changes can be necessary for receiving a new type,
both with respect to the dictionary as well as policy languages.