Re: [Dime] AD review of draft-ietf-dime-drmp-03
Steve Donovan <srdonovan@usdonovans.com> Wed, 09 March 2016 19:04 UTC
Return-Path: <srdonovan@usdonovans.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 13E8B12D91F; Wed, 9 Mar 2016 11:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 5jplST_55itc; Wed, 9 Mar 2016 11:04:42 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350AB12D62C; Wed, 9 Mar 2016 11:04:41 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:65494 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1adjPP-00157a-I2; Wed, 09 Mar 2016 11:04:40 -0800
To: lionel.morand@orange.com, Janet P Gunn <Janet.Gunn@csra.com>
References: <56D9C0A0.9060804@cs.tcd.ie> <12590_1457451719_56DEF2C7_12590_1520_1_6B7134B31289DC4FAF731D844122B36E01DFA238@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56E03A3F.4090005@usdonovans.com> <OF5715A466.26651C6B-ON85257F71.00546DED-85257F71.005474C6@csgov.com> <13333_1457539506_56E049B2_13333_1226_1_6B7134B31289DC4FAF731D844122B36E01DFC197@OPEXCLILM43.corporate.adroot.infra.ftgroup>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <56E073C2.1000200@usdonovans.com>
Date: Wed, 09 Mar 2016 13:04:34 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <13333_1457539506_56E049B2_13333_1226_1_6B7134B31289DC4FAF731D844122B36E01DFC197@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------090501080001080105000401"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/XqiJKLlQveVJSSeRzC_P-2yMTrw>
Cc: DiME <dime-bounces@ietf.org>, "dime@ietf.org" <dime@ietf.org>
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: Wed, 09 Mar 2016 19:04:45 -0000
Lionel, I'll work the suggested ordering and wording below into the next draft. On the requirements I went with SHOULD NOT because it really should be very rare that an agent changes or adds priority information. The note is there to explain why the SHOULD NOT isn't a MUST NOT. I think it is better to have a requirement, be it as it currently exists or with a MAY, to be explicit. Steve On 3/9/16 10:05 AM, lionel.morand@orange.com wrote: > > Hi Steve, > > It is true that some scenarios will require action of agents on the > DRMP AVP. > > in that case, I would be more explicit and change a little bit the > order as "save the transaction priority" is valid in any case: > > è Note that the title of the bullet 2 should be " Agents handing the > request " and not "Agents handling the request" > > 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. Before forwarding request messages, agents > generally do not > > modify the priority information present in the received request > > message nor include the priority information when absent in the > received request message. > > However, in some scenarios, agents > > can modifythe priority information e.g. edge agents modifying the > > priority values set by an adjacent operator. There might be other > > scenarios where a Diameter endpoint does not support the DRMP > > mechanism and agents insert the priority information in the > request messages for that non > > supporting endpoint. When forwarding the request messages, the > agent saves > > the transaction priority in the transaction state, either as > > locally managed state or using the Proxy-Info mechanism defined > > in [RFC6733 <https://tools.ietf.org/html/rfc6733>]. This will > be used when handling the associated > > answer message for the transaction. > > The same kind of change should be done in bullet 5 that is about > handling of answers: > > 5. Agent handling the answer - By default, agents handling answer > > messages use the priority information stored with the transaction > > state to determine the priority of relaying the answer message. > > However, priority information included in the answer message, > > when present, is used in place of the stored priority > > information. The use of priority information implies that > > answers for higher priority transactions are given preferential > > treatment to lower priority transactions. When forwarding the > answer messages, agents generally do not > > modify the priority information present in the received answer > messages > > nor include the priority information when absent in the > received answer messages. > > However, in some scenarios, agents > > can modifythe priority information e.g. edge agents modifying the > > priority values set by an adjacent operator. There might be other > > scenarios where a Diameter endpoint does not support the DRMP > > mechanism and agents insert the priority information for that non > > supporting endpoint. > > If it is agreed that agents can modify/include the DRMP AVP, I think > that the "SHOULD NOT" is not correct as it is a "MAY", even if not often. > > I think the proposed added requirements can be safely removed. > > Regards, > > Lionel > > *De :*Janet P Gunn [mailto:Janet.Gunn@csra.com] > *Envoyé :* mercredi 9 mars 2016 16:23 > *À :* Steve Donovan > *Cc :* dime@ietf.org; DiME; MORAND Lionel IMT/OLN; Stephen Farrell > *Objet :* Re: [Dime] AD review of draft-ietf-dime-drmp-03 > > Sounds good to me. > > Janet > > This electronic message transmission contains information from CSRA > that may be attorney-client privileged, proprietary or confidential. > The information in this message is intended only for use by the > individual(s) to whom it is addressed. If you believe you have > received this message in error, please contact me immediately and be > aware that any use, disclosure, copying or distribution of the > contents of this message is strictly prohibited. NOTE: Regardless of > content, this email shall not operate to bind CSRA to any order or > other contract unless pursuant to explicit written agreement or > government initiative expressly permitting the use of email for such > purpose. > > > > From: Steve Donovan <srdonovan@usdonovans.com > <mailto:srdonovan@usdonovans.com>> > To: lionel.morand@orange.com <mailto:lionel.morand@orange.com>, > Stephen Farrell <stephen.farrell@cs.tcd.ie > <mailto:stephen.farrell@cs.tcd.ie>>, "dime@ietf.org > <mailto:dime@ietf.org>" <dime@ietf.org <mailto:dime@ietf.org>> > Date: 03/09/2016 10:15 AM > Subject: Re: [Dime] AD review of draft-ietf-dime-drmp-03 > Sent by: "DiME" <dime-bounces@ietf.org <mailto:dime-bounces@ietf.org>> > > ------------------------------------------------------------------------ > > > > > All, > > I've commented on Stephen's and Lionel's suggested changes below. > > If there is agreement to my proposed changes outlined below then I > will submit a new version of the document. > > Regards, > > Steve > > On 3/8/16 9:41 AM, lionel.morand@orange.com > <mailto:lionel.morand@orange.com> wrote: > 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.* > SRD> I propose the following reworded last sentence: "Agents generally > do no modify priority > information and agents generally do not add new priority information > in forwarded requests or answers." > > SRD> There is one scenario where I can see an agent does add add > priority information, in a > transition period when not all endpoints support the DRMP mechanism > and the agent > is used to insert priority information for the non supporting endpoint. > > SRD> I also see one scenario where an agent might modify priority > values. This would > be an edge agent case where the priority values included by another > operator's Diameter > network aren't trusted and new values are needed. > > SRD> I propose that notes that address these scenarios be added to the > new normative requirements proposed below. > > > 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. > SRD> I propose the following: > Diameter agents SHOULD NOT modify priority information when relaying > request and answer messages. > > There might be scenarios where a Diameter agent does modify > priority information. For instance, an edge agent might need to > modify the priority values set by an adjacent operator. > > Diameter agents SHOULD NOT add priority information when relaying > request and answer messages. > > There might be scenarios where a Diameter endpoint does not > support the DRMP mechanism and agents insert priority information > for that non supporting endpoint. > > > 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 <mailto: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. > SRD> Change made. > > > - 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. > SRD> Agreed, change made. > > > - 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" :-) > SRD> I'm open to wording suggestions here but the only real reason is > that we needed a default and some thought it might be better to have > the default allow for a few more higher-than-default values than > lower-than-default values. I'm not sure saying this adds much value. > > > - 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. > SRD> The existing language was put in when we had 5 priority values. > The above is certainly a more elegant way of specifying it. Changed > to the following: > > When setting and using priorities, for all integers x,y in [0,15] > treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x. > > Note: As a result PRIORITY_0 is the highest priority. > SRD> I'm not sure this can be done in section 9.1, as this is listing > the enumerated values for the AVP. > > > > > I-D nits: > > == Unused Reference: 'RFC5226' > == Unused Reference: 'RFC4412' > SRD> These references removed. > > > > > _________________________________________________________________________________________________________________________ > > 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 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.
- [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