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

[Bernard Aboba <aboba@internaut.com>]

> This document is not addressing the needs of the home network.
> Business Requirements in the proxy and visited network are driving the need
> for the CUI attribute.

That makes sense to me (and to quite a few others as well) it seems.
Perhaps we should ask the WG for consensus on this point?  It certainly
would make things a lot easier if there was agreement on this (see below).

> CUI in an Access Accept.  This is no different then when the home network
> delivers a CISCO VSA when it knows that its partner is using a CISCO NAS and
> requires the functionality provided by the VSA.

With a VSA, if the NAS doesn't understand it, it can ignore it.  Is that
true of CUI as well?  If this really is about the NAS, then I think the
answer is yes.  The RADIUS Server can send CUI along with Class, and if
the NAS doesn't support it, it can ignore it and the home server will get
all the billing info it needs from the Class attribute.  This is backward
compatible on the NAS (since it doesn't need to be upgraded to support
CUI) as well as on the RADIUS server (who doesn't see a CUI attribute it
didn't ask for).

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