RE: QoS attributes

[Avi Lior <avi@bridgewatersystems.com>]

David Nelson writes:

> I have not participated in the Credit Control over AAA 
> discussions, but what I have learned of it from speaking with 
> you, I suspect I would categorize it as a Bad Idea (tm).  It 
> sounds way more complicated than is really necessary.  Yes, 
> you can contrive a business model that requires that much 
> complexity.  However, not all business models make sense or 
> will be successful in the market.  Therefore, Credit Control 
> may not be the best precedent to cite.

The good news is David, that the business model for prepaid and credit
control is viable.  There is demand we and other companies are delivering
products today.  So Credit Control is the *best* precedent to cite.


> If the partners in a roaming consortium can't agree on a few, 
> simple classes of service for QoS that will be comprehensible 
> to the customer as he/she roams, and will be amenable to 
> straightforward billing and reconciliation at the end of the 
> month, then the business model is profoundly broken, and no 
> protocol in the world is going to fix it.

In a simple world the only relationships you have are bilateral
relationships.  In the real-world there are other relationships. Often the
home network has a relationships with intermediaries and the service is
actually provided by other parites. You can expect everyone in these cases
to know what a Gold User looks like. Or what Filter-Id "foobar" means.  

>  At least that's my 
> view of the situation.  Sometimes too much flexibility is a 
> severe impediment to scalability, especially across multiple 
> organizations.  I think maybe the KISS model applies here.

I am a big beliver in the KISS model.  Keep in mind that things that seem
simple at the surface may actually be broken.

Filter ID concept seems simple enough but we know that it is broken today in
that it doesn't scale.

> Authorizing a user to obtain or negotiate for a "class of 
> service" seems within the scope of AAA.  Provisioning the 
> detailed parameters of those "service classes", both at the 
> NAS and on end-to-end basis, seems out of scope for AAA.

Similar arguments were made about filers and filter-ids.  What you propose
is not always a viable solution - its broken.  And in the case of the
filter-id, Diameter fixed that.


Avi

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