RE: AW: backwards compatible introduction of NEW attribute such as CU I

[Bernard Aboba <aboba@internaut.com>]

> server that implements RFC 3579 and "Privacy" as defined in RFC 2486bis
> will be upgraded to also support CUI.  CUI support therefore becomes
> part of the "Privacy" functionality package.
>
> That sounds like a reasonable approach.  How would we effectively
> document this scope of applicability and interdependencies?

First off, we have to define what "privacy means".  The logical place to
do this is in RFC 2486bis.  I've failed an issue relating to the perceived
vagueness of the definition.

Assuming we can define what a RADIUS client and server need to do in order
to support "privacy" then we can write an applicability statement for CUI
that requires RFC 3579 and "privacy" support as a precondition for CUI
support.

> The other part of the question is when and how to require that the
> RADIUS Clients (i.e. NASes), and Proxies support CUI?   Do we make a
> similar assertion around NAS support for RFC 3579 and RFC 2486bis?

The way I think of it, NASes can already claim compliance to RFC 3579 if
they support EAP.  But we are talking about something above and beyond
that -- RFC 3579 plus RFC 2486bis plus CUI.  So we can state that the CUI
assumes support for RFC 2486bis and RFC 3579, and then place requirements
on RADIUS servers that support all of that.

This way we're not trying to upgrade every RADIUS server and NAS in the
world, just the ones that already have enough functionality to make CUI
worthwhile.

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