RE: Questions on RADIUS Extended attributes

["Nelson, David" <dnelson@enterasys.com>]

Alan DeKok writes...

> The requirement to not add or delete the attributes is limited
> to only those proxies that are unaware of the new attribute 
> format.  Those proxies might remove an Extended-Type attribute 
> from the *middle* of a list of such attributes, which would be 
> bad.

By "list of such attributes", do you mean a sequence comprising an
initial attribute and continuation (concatenation) attributes?  I was
thinking that removing one or more continuation attributes from the
middle of a sequence would be very bad.

>   2) policy-limiting forwarders.  These servers act as forwarders
> that authenticate remotely, but enforce local policy.  In that case,
> the Extended-Type attributes will either be understood locally (and
> thus not mangled), or not understood (in which case mangling won't 
> be noticed).

Mangling by whom?  Noticed by whom?  It would certainly seem to me that
the NAS or the Server would notice!

> The main problem with this proposal is that it doesn't easily
> support nested grouping.  For that to work would require defining 
> yet another attribute packing format.  Or, Emile's tag suggestion 
> would seem to work.

Tagging would support grouping, but not nested grouping.  Do we think
that single-level grouping is sufficient to solve the "80% problem"?

> My only requirement for a tagged format is that as Glen pointed 
> out, the tags MUST ALWAYS exist.  Optional tags are a nightmare.

I absolutely agree.


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