Re: [Dime] AD review of draft-ietf-dime-drmp-03
<lionel.morand@orange.com> Tue, 08 March 2016 15:42 UTC
Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644DB12D787 for <dime@ietfa.amsl.com>; Tue, 8 Mar 2016 07:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyj5misdRHbu for <dime@ietfa.amsl.com>; Tue, 8 Mar 2016 07:42:01 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA16F12D734 for <dime@ietf.org>; Tue, 8 Mar 2016 07:42:00 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 51F8A403F4; Tue, 8 Mar 2016 16:41:59 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 1EC951A0088; Tue, 8 Mar 2016 16:41:59 +0100 (CET)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%19]) with mapi id 14.03.0279.002; Tue, 8 Mar 2016 16:41:58 +0100
From: lionel.morand@orange.com
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] AD review of draft-ietf-dime-drmp-03
Thread-Index: AQHRdjg9yfCKL7NM0kO5Xz/k/mVR9J9PsI4Q
Date: Tue, 08 Mar 2016 15:41:58 +0000
Message-ID: <12590_1457451719_56DEF2C7_12590_1520_1_6B7134B31289DC4FAF731D844122B36E01DFA238@OPEXCLILM43.corporate.adroot.infra.ftgroup>
References: <56D9C0A0.9060804@cs.tcd.ie>
In-Reply-To: <56D9C0A0.9060804@cs.tcd.ie>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/xcBrEkshFel_u5j15REvmDhO4zo>
Subject: Re: [Dime] AD review of draft-ietf-dime-drmp-03
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2016 15:42:03 -0000
i will let Steve react but I can give my feeling :) The priority is set by the Diameter or Diameter server, not by agent. It is somehow describe in section 6 Theory of Operation 2. Agents handing the request - Agents use the priority information when making routing decisions. This can include determining which requests to route first, which requests to throttle and where the request is routed. For instance, requests with higher priority might have a lower probability of being throttled. The mechanism for how the agent determines which requests are throttled is implementation dependent and is outside the scope of this document. The agent also saves the transaction priority in the transaction state, either as locally managed state or using the Proxy-Info mechanism defined in [RFC6733]. This will be used when handling the associated answer message for the transaction. Agents are just using this information if present. They are not modify it or include it if absent. It is said in section 8. Normative Behavior Note: This guidance on the handling of messages without a priority does not result in a Diameter agent inserting a DRMP AVP into the message. Rather, it gives guidance on how that specific transaction should be treated when its priority is compared with other requests. When a Diameter agent relays the request it will not insert a DRMP AVP with a priority value of 10. It could be possible to clarify it as follow: in section 6, the end of the point 2 could be enhanced as follow: 2. Agents *handling* the request - Agents use the priority information when making routing decisions. This can include determining which requests to route first, which requests to throttle and where the request is routed. For instance, requests with higher priority might have a lower probability of being throttled. The mechanism for how the agent determines which requests are throttled is implementation dependent and is outside the scope of this document. The agent also saves the transaction priority in the transaction state, either as locally managed state or using the Proxy-Info mechanism defined in [RFC6733]. This will be used when handling the associated answer message for the transaction. *Agents are not supposed to modify or include priority information in in forwarded requests or answers.* The "not supposed" is used because it is difficult to use normative wording here. In section 8, a new requirement could be added, right after " Diameter agents MAY use routing priority information..." Diameter agents SHOULD NOT modify or include the DRMP AVP when relaying request and answer messages. Just a proposal, waiting for Steve and WG comments. Regards, Lionel > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Stephen Farrell > Envoyé : vendredi 4 mars 2016 18:07 > À : dime@ietf.org > Objet : [Dime] AD review of draft-ietf-dime-drmp-03 > > > Hiya, > > I just have one question I'd like to ask the wg about before I start IETF LC. > > You don't say if priorities are intended to be modified after they have been > set. In the security considerations you do say that this could be done > maliciously, and you do say that priorities need to be dropped if received > from a source not trusted for that, but you never say if it's considered ok or > not for e.g. an agent to change a priority for some local policy reason. Don't > you need to say that somewhere? (And apologies if you do say it somewhere > and I missed it:-) > > There are some nits below, you can handled these before or after IETF LC, > whichever is best. > > Cheers, > S. > > > - Section 5: URL and MME aren't expanded. Since you're just using it as an > example, I'd say expanding this will help any reader who's not a 3gpp > afficionado. > > - Section 8, "The priority marking scheme SHOULD NOT require the Diameter > Agents to understand application specific AVPs." > Isn't that a bogus use of 2119 language since we're not expressing > requirements here? s/SHOULD NOT/does not/ would seem better. > > - Section 8, People will ask "why default to 10?" I recall the WG discussed this > but iirc mostly didn't care too much but it might be nice to justify 10 if there's > a way to do it that doesn't amount to "just because" :-) > > - Section 8, The "When setting and using..." paragraphs are quite verbose. > It'd be no harm to make that shorter, e.g. by just saying: "For all integers x,y > in [0,15] treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x" > You could do something similar in 9.1. > > I-D nits: > > == Unused Reference: 'RFC5226' > == Unused Reference: 'RFC4412' _________________________________________________________________________________________________________________________ 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.
- [Dime] AD review of draft-ietf-dime-drmp-03 Stephen Farrell
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 lionel.morand
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Stephen Farrell
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 lionel.morand
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Stephen Farrell
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Steve Donovan
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Janet P Gunn
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 lionel.morand
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 lionel.morand
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Steve Donovan
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Steve Donovan
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Steve Donovan
- Re: [Dime] AD review of draft-ietf-dime-drmp-03 Stephen Farrell