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

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

Bernard Aboba writes...

> The problem with requiring that the RADIUS server *always* send CUI is
> that no existing RADIUS servers do this.  However, if we restrict the
> applicability of CUI, then it may be reasonable to expect that a
RADIUS
> 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?  Perhaps
using something akin to the IEEE's Protocol Implementation Compliance
Statement (PICS)?  

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?


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