Deployment (Was: Re: NAI decoration: User Identity issues)

[Jari Arkko <jarkko@piuha.net>]

Barney Wolff wrote:

> So, to support a particular business model, namely fixed per-user billing,
> all the world's NAS's have to be upgraded?  The business model could be
> accomodated by a private agreement on the use of Class between the
> intermediary and its customers, with no impact on the NAS.
>
> If all NAS's are not forced to upgrade, how will the server know whether
> it can include User-Alias?

The primary problem is that RFC 2866 did not require that unrecognized
attributes be copied verbatim to the accounting request packets. (Or
am I missing some text somewhere?)

So I agree that the NAS support for a new attribute which would have
to be copied from Access-Accept to Accounting-Request is a problem.

There are proposals on the table (such as Radius capabilities
bit mask) which would enable the server to know what the NAS
can do.

The question is if this helps. What if the NAS does not support
this capability? Perhaps you could switch to sending a Class
attribute instead. But it isn't clear to me what value there
would be in doing the same thing in two ways. Why not do it
just in one way then, if that one way has to be done in certain
cases anyway? Or are we going to accept this because it
provides better functionality at least in those cases that the
NAS supports this new functionality?

There are also proposals on the table that would make it possible
to mark attributes as mandatory. Here too we have a question:
what to do if the NAS does not support the attribute? Obviously
we could fail the session, or fall back to an easier business
model. But the latter is hard to achieve in an Access-Accept that
gets rejected by the NAS; it seems that we have to make the
decision earlier, based on NAS capabilities.

In conclusion a new copied attribute is possible, but
it isn't clear what to _do_ in the case when the NAS does
not support it. I think this is a problem. (Unfortunately,
also the use of the Class attribute seems problematic
as has been pointed out in other e-mails.)

--Jari

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