RE: QoS attributes

[Avi Lior <avi@bridgewatersystems.com>]

John,


> > But I don't belive that those are the only use cases.  What
> > about when the  QoS classes are not configured such in 
> cases when we cross 
> > administrative domains where we don't have the QoS class configured 
> > or completely configured.  You would then need to actually 
> transport 
> > the actual parameters.  After all, isnt the QoS class an 
> alias for QoS 
> > parameters?
> 
> One would hope that if parties have agreements in place for 
> roaming, then they would also have some agreements on service 
> classes as well.  They would still 
> have to have some agreement on policy, for example, to know 
> if the roaming 
> user was authorized for certain types of service, I would guess.

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.

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.

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

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