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

[Jari Arkko <jari.arkko@piuha.net>]

Bernard Aboba wrote:

> It's only a problem if the RADIUS server requires this behavior.  But
> we've already said that from the RADIUS server point of view, there is no
> distinction between Billable Identity and Class.  They provide the same
> functionality.  So a RADIUS server can send *both* Class and
> Billable-Identity and be ensured that at least one of these will be
> understood.

This is OK, but one may wonder whether Class alone would suffice
all the time, if it suffices for some cases. I do see the problems
in using Class -- there are many. But if you are saying its
OK for some subset of the cases... what's the difference that
the new attribute would give in the rest of the cases? And
presuming that there is a difference, how is it that the
service providers are going to live with the restrictions of
the Class attribute _and_ keep their fixed price business
model?

Perhaps the answer lies in the definition of the
business model. Is it

  (a) Access provider MUST present a fixed cost bill
      per user per month, and MUST ensure that a given
      user is logged on at most once at any given time.

or

  (b) Access provider SHOULD present a fixed cost bill
      per user per month, and SHOULD ensure that a
      given is logged on at most once at any given time.
      However, if the peer equipment indicates that it
      does not support this feature, then a per-session
      bill MAY also be presented, and session limits
      MAY be ignored.

Note that if the answer is "a", then we have two ways
of achieving it: we can either try to achieve it at
the protocol level or through some sort of roamaing
agreements (e.g., GSMA).

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