Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hello all,

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

Having 15 rather than 16 would be useful from an interworking point of view on Diameter interfaces connecting to the EPS.

Also, my understanding has been that the default value is per local policy.

My 2 cents....
Viqar
________________________________
From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

I think that the case "no Priority indication in request" is the default situation today.
So if we agree that it should be possible to explicitly indicate a request with a lower priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 17 values: [0-7][8][9-16].
If any operator can freely fix the default value, there would be no way to ensure the sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority indication.

Therefore, for a deterministic handling mechanism, I think that it is then more relevant to define a standard value for the default value.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoyé : mercredi 30 septembre 2015 22:53
À : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

Same here.  The "default priority" should be a matter of local policy.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

From:        "DOLLY, MARTIN C" <md3135@att.com<mailto:md3135@att.com>>
To:        Steve Donovan <srdonovan@usdonovans.com<mailto:srdonovan@usdonovans.com>>, "dime@ietf.org<mailto:dime@ietf.org>" <dime@ietf.org<mailto:dime@ietf.org>>
Date:        09/30/2015 04:40 PM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <dime-bounces@ietf.org<mailto:dime-bounces@ietf.org>>
________________________________

Me as well

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

I'm okay with Jay's proposal on not specifying a default value.

Steve
On 9/30/15 3:27 PM, Lee, Jay wrote:
Hi Steve and all,

For the first proposal, as I indicated, I support increasing the number of priority levels up to 16.

I am also fine with the second proposal. My question is: do we need to mandate this feature, as individual operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic’ without a particular high or low priority. Then each operator can map this default to a value (e.g., 8 or something else) that they feel appropriate.

Thanks,

Jay

_______________________________________________
DiME mailing list
DiME@ietf.org<mailto:DiME@ietf.org>
https://www.ietf.org/mailman/listinfo/dime
 _______________________________________________
DiME mailing list
DiME@ietf.org<mailto:DiME@ietf.org>
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.