Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE



Hi Viqar, 

It seems that most folks in the group prefer a couple of parameters to be
moved into a separate document (and thereby removed from the current
document) because of the suddenly appeared dependency problem. We are
already late with this document and we need to get it out of the door. 

Related to your question: QoS priority vs. priority for an government
authorized call/session?

When referring to the parameter in the document then what was done is
essentially the following:

* There is a container (Diameter AVP)
* There is a registry (originally created by RFC 4412 and later extended to
represent the textual values in a numeric fashion with
http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-11.
* The syntax of the previously created values is simple; they are just
numbers.
* The semantic of the values is essentially unspecified in these documents
-- James Polk would say "this is policy".

The important issue seems to be how these AVPs that contain these values are
used inside Diameter. The answer is: It depends on the scenario and on the
context. So, getting back to your question: the same AVP can used in either
scenario. 

Does this answer your question in any way?  

Ciao
Hannes 

>-----Original Message-----
>From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On 
>Behalf Of Shaikh, Viqar A
>Sent: 10 March, 2009 15:04
>To: dime at ietf.org
>Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE
>
>
>Hello,
>
>Are these parameters to be removed (Priority AVP,
>> Admission-Priority AVP, and ALRP AVP) related to QoS 
>priority or priority for an government authorized call/session?
>
>Regards,
>Viqar
>________________________________________
>From: dime-bounces at ietf.org [dime-bounces at ietf.org] On Behalf 
>Of Elwyn Davies [elwynd at dial.pipex.com]
>Sent: Monday, March 09, 2009 7:05 PM
>To: dime at ietf.org
>Subject: Re: [Dime] Diameter QoS Parameter -- DECISION TO MAKE
>
>Hi.
>
>I support the decision to remove the parameters.
>
>Regards,
>Elwyn Davies
>
>> Hi all,
>>
>> we have a normative reference in the Diameter QoS parameter draft 
>> 
>http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-09.
>> txt pointing to 
>> http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-11
>>
>> Yesterday, Magnus posted a mail to the TSVWG list that 
>> draft-ietf-tsvwg-emergency-rsvp-11.txt is having a lot of problems 
>> getting through the IESG and the document bounced back to 
>the working 
>> group. The mail can be found here:
>> http://www.ietf.org/mail-archive/web/tsvwg/current/msg09070.html
>>
>> Now, there is the risk of considerable delay in publication of our 
>> Diameter QoS parameter document as it will be blocked (for 
>potentially a long time).
>> Since the Diameter QoS attribute and the Diameter QoS application 
>> document normatively depend on the QoS parameter document 
>they will be 
>> blocked as well.
>>
>> So, I have been thinking of what we could do to deal with this issue 
>> and here is a proposal to the group.
>>
>> ***************
>> My proposal is to move the priority parameters (Priority AVP, 
>> Admission-Priority AVP, and ALRP AVP) into a separate 
>document and to 
>> progress them independently to get the main part of the Diameter QoS 
>> parameters document finalized.
>> ***************
>>
>> Please let me know if you find this idea acceptable. Please 
>respond as 
>> quickly as possible!
>>
>> Ciao
>> Hannes
>>
>> PS: We would have to find an editor and authors for that the new 
>> document that contains the priority parameters but we can 
>worry about 
>> that part larter.
>>
>>
>_______________________________________________
>DiME mailing list
>DiME at ietf.org
>https://www.ietf.org/mailman/listinfo/dime
>_______________________________________________
>DiME mailing list
>DiME at ietf.org
>https://www.ietf.org/mailman/listinfo/dime
>


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.