Subject: [Dime] DIME Status Update, October 2007

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Oct 2007 09:43:39 +0200

I have compiled a short status update based on the work we did the last 
2 months:
http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate

In short, it seems that we are doing fine. Since we are about to finish 
a couple of documents in the next month we should think about rechartering.

Ciao
Hannes

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: ken carlberg <[email-masked]>
Date: Fri, 26 Oct 2007 10:43:29 -0400

Hannes,

What are your thoughts about defining a new AVP exclusively for  
priority?  I don't have concerns about the inclusion of priority in  
the QoS parameters draft.  However, I recently came across an email  
exchange related to IMS where one of the participants didn't want to  
consider using the QoS parameters draft for validating SIP R-P  
information because of the bundled QoS.

I'm sure there are work-arounds to mitigate the technical concerns of  
that individual.  However, at times its easier to provide an atomic  
solution to a topic than to a multi-faceted one that gets paired down  
with profiles of set values (eg, to only exericise Priority  
parameters in the QoS-parameters draft, set all other fields to X, Y,  
Z).

-ken

On Oct 23, 2007, at 3:43 AM, Hannes Tschofenig wrote:

> I have compiled a short status update based on the work we did the  
> last 2 months:
> In short, it seems that we are doing fine. Since we are about to  
> finish a couple of documents in the next month we should think  
> about rechartering.
>
> Ciao
> Hannes
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 26 Oct 2007 17:17:44 +0200

Hi Ken,

> information because of the bundled QoS.
Can you more specific on how the desired approach would look like?

> with profiles of set values (eg, to only exericise Priority parameters 
> in the QoS-parameters draft, set all other fields to X, Y, Z).
>
Ciao
Hannes

>> finish a couple of documents in the next month we should think about 
>> rechartering.
>>
>> Ciao
>> Hannes
>>
>>

---

From: ken carlberg <[email-masked]>
Date: Fri, 26 Oct 2007 11:55:11 -0400

On Oct 26, 2007, at 11:17 AM, Hannes Tschofenig wrote:

>> priority?  I don't have concerns about the inclusion of priority  
>> in the QoS parameters draft.  However, I recently came across an  
>> email exchange related to IMS where one of the participants didn't  
>> want to consider using the QoS parameters draft for validating SIP  
>> R-P information because of the bundled QoS.

at a very high level, an approach that strips out the QoS elements  
discussed in
draft-ietf-dime-diameter-qos-01.txt
draft-ietf-dime-qos-parameters-01.txt
and focuses on the application of AAA of Priority values we may see  
from protocols like SIP and its R-P header.  And yes, this probably  
equates to thinner documents :-)

-ken

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 28 Oct 2007 13:17:03 +0100

Hi Ken,

let me give you a concrete example.

Let's assume a SIP proxy receives a RPH and wants to ask the AAA server 
whether this user is authorized to use this specific RPH.
Here is how this could look like, assuming that Filter-Rules are not 
important in this specific case (they are optional anyway).

AAA client -> AAA server:
----------------------------

* QoS-ObjectType

with the information that the provided QoS information is of type 
"QoS-Desired". The semantic is
"Please authorize the indicated QoS"

* RPH Priority Parameter (from Section 4.11 of
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt) 
encapsulated
in the QoSBlob AVP (as the only QoS parameter in this example).

These two AVPs are encapsulated in the QoSBlob-Group and contained in 
the QoS-Resources AVP. This encapsulation is simply necessary when you 
use grouped AVPs. Without using grouped AVPs one would have to add 
additional fields to indicate how the individual AVPs relate to each other.

Note that the QoS-Profile AVP, which indicates the QoS profile, is not 
necessary in this example since the RPH Priority refers to a parameter 
from the base profile document. (This is not yet in the draft since we 
haven't published the updated draft based on the provided feedback yet).

AAA client <- AAA server:
----------------------------

Authorization successful or failed. No QoS information needs to be 
repeated here in our example.

Now you tell me what should be further removed. Is this really 
complicated or does the current document just look complicated?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 28 Oct 2007 19:48:41 +0100

I should also add that there is no problem with the fact that the 
draft-ietf-dime-qos-parameters-01.txt document defines a large number of 
parameters.
If only a subset of them are needed in a specific environment then a new 
QoS profile is defined that might include a subset of these parameters 
and potentially defines new parameters. The extensibility model provides 
other SDOs the ability to define their own parameters and also to 
register a new QoS model.

We specifically considered these aspects since other SDOs have already 
defined their own QoS parameters. These parameters can then easily be used.

Hope that this helps.

Ciao
Hannes

Hannes Tschofenig wrote:
> Let's assume a SIP proxy receives a RPH and wants to ask the AAA 
> server whether this user is authorized to use this specific RPH.
>>>> exchange related to IMS where one of the participants didn't want 
>>>> to consider using the QoS parameters draft for validating SIP R-P