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.