[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CUI - issues addressed in version 3
On Mon, Dec 13, 2004 at 12:48:39PM -0800, Adrangi, Farid wrote:
>
> Issues addressed in Version 3
> =============================
> Issue 21 (Owner: Barney Wolff)
> Issue 22 (Owner: Barney Wolff)
>
> The description of these issues can be found in in
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014.
Let me preface these remarks by saying that if I'm the only one
resisting CUI the wg should go ahead anyway; consensus does not
require unanimity.
I will ignore my continuing doubt of the need for CUI.
The core of my Issue 21 is that the draft obsoletes a piece of
RFC 2865 by saying that servers that do not understand CUI SHOULD
silently discard the attribute. Since an implementation that does
not understand CUI will not know that it's CUI that it's ignoring,
the draft effectively says that servers SHOULD silently discard all
unknown attributes. 2865 says MAY. If we are going to make existing
implementations retroactively non-compliant with RADIUS, we need
to rev 2865.
Issue 22 is about which party requires that CUI be present. Given
the business case claimed, it appears to be the NAS owner or proxy,
not the server owner. If that's so, the draft's suggestions on how
to indicate support for CUI seem backwards. If the NAS or a proxy
*requires* CUI, rather than simply supporting it, that's the case
where putting a null CUI in the Request makes sense, and an Accept
that comes back without CUI can then be treated as a Reject.
Finally, the draft's advice on the lifetime of a CUI seems a bit vague.
Would an implementation that assigned consecutive integers to each
Accept as the CUI be compliant, provided it kept a database of the
correspondence to the user's "true" identity?
Barney
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
--
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/>