Re: Comments on "RADIUS Design Guidelines" document

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
...
> This document includes quotes from pre-5738 RFCs.  Should we be using
> the new "pre-5738" boilerplate?

  Likely, yes.

> This would seem to suggest that support for new authentication mechanisms
> can be standardized outside the IETF, as long as the guidelines are
> followed.

  If it's SDO specific...

> Also, the use of SHOULD NOT implies that there are circumstances in which
> protocol changes or new commands can be standardized outside the IETF. Is
> this what was intended?

  No.  We can change this to a MUST NOT.

> Since [EXTEN] defines extensions to the standard RADIUS attribute
> space and this section is talking about VSAs, the reference is a bit
> confusing.  Is the intent to suggest that VSAs other than type 0
> can also use the [EXTEN] format?

  Yes.

> s/discovery/discover/

  Fixed, thanks.

>    Even though the type is Text, the rest of the description indicates
>    that it is a complex attribute:
> 
> Since accounting data is typically only written to stable storage without
> examination, does the reasoning against complex attributes really apply
> here?

  RFC 2869, Section 5.19 (Table of Attributes) indicates that
Connect-Info is permitted in Access-Request packets.  Admins would like
to use this information to perform policy checks.

  e.g. Customer X has service Y, which doesn't permit them access to the
"high bandwidth" connection.

  Right now, they have to write regular expressions to parse the
Connect-Info attribute into multiple fields, and then apply the
bandwidth checks.

  This text was added as a direct result of seeing this problem occur in
the field.

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