RE: QoS attributes

[<john.loughney@nokia.com>]

Hi Avi,

> There are two problems with this approach is certain conditions:
> 
> Dealing with a QoS Class Id only only addresses static arrangements where
> both parties agree apriori on the contents of that are represented by a
> particular instance of the QoS Class Id.  This is useful but its not the
> only model.

> In some cases the QoS maybe more dynamic, we therefore need the flexibility
> to transfer the QoS Class Id and/or QoS parameters.

Agreed, however the more dynamic model is something that is probably
beyond RADext to standardize.

> Something that I understand is Bandwidth.  Two parties can agree on how to
> bill for bandwidth without having to agree on descrete bundles of bandwidth.
> We bill bandwidth on bits/second.

So, why are we not discussing Bandwidth?  If I understand, you want
to support a bandwidth attribute.  If so, I think that a more
comprehensive proposal would be good, one which discusses the
trade-offs, etc.  QoS is probably a swamp if we start at supporting
multiple attributes.

> Also I am very surprised about the resistance to do this.  If we justify
> doing Credit Control over AAA why is this a problem? 

I don't see the comparison, actually.  The Credit Control is trying
to standardized a token based approach for doing AAA authorization.
It is not standardizing (or at least trying to carefully work
with) billing models, etc.  

John

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