RE: Issue 298

["Bernard Aboba" <Bernard_Aboba@hotmail.com>]

David Nelson said:

"I think we want to be very careful here.  The correct behavior for
implementations that have not included the Extended Attribute functionality
is to treat them as unrecognized / unknown VSAs, and to ignore them.  They
may be logged in some fashion, of course.  Whether they should be included
in RADIUS Accounting or Dynamic RADIUS packets as "unknown attributes" is
open to debate.

What I think should not happen is for Extended Attributes to be
"selectively" understood.  The implementation either "groks" the Extended
Attribute format, in which case the rules for standard attributes (or SDO
Specific Attributes) apply, or it simply sees them as unrecognized / unknown
VSAs, in which case the rules for unknown attributes apply.  We should not
encourage implementations to treat them as unknown for one purpose but known
for another."

[BA] Very well put.  Care to take a shot at providing text to resolve the
issue?

> So one question is whether this implies that a NAS should signal its
> support for Extended Attributes in the Access-Request in some way -- 
> so as to make it clear to the RADIUS server how those attributes would
> be interpreted.  

I think we should make that feature a MUST.

[BA] That seems sensible to me.  The question is how to do it.  Maybe
include
an Extended Attribute of Type 1 with a NUL in it within an Access-Request?


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