Re: [Dime] AD review of draft-ietf-dime-drmp-03

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 10 March 2016 19:03 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 CBD9D12DBD6 for <dime@ietfa.amsl.com>; Thu, 10 Mar 2016 11:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGhZIxX1np_f for <dime@ietfa.amsl.com>; Thu, 10 Mar 2016 11:03:38 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7135E12DB8D for <dime@ietf.org>; Thu, 10 Mar 2016 11:03:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37642BE39; Thu, 10 Mar 2016 19:03:37 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM7HenhMMMmy; Thu, 10 Mar 2016 19:03:34 +0000 (GMT)
Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D4E36BE3F; Thu, 10 Mar 2016 19:03:33 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457636614; bh=gEhSXdbHaIRIs4xL35wPH90C9yZ7nOycFSBxKfYLYps=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OlopmsrZCiLh1MaTXbZICUwr2P/a/muJJv9jUICD2+Ye64+wXYC5Y6S/0tgBDd8Kh GnPvaiG/YAjSKVUKDAT3AGJ7Jcf873gN/LD1tyynApXhisyg1tB/MxsZFQE0dEXS0v N/oXPy+tCZtQUsU8+SnRArGi/YXs6A0iTV0ZW8qw=
To: Steve Donovan <srdonovan@usdonovans.com>, dime@ietf.org
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> <56E073C2.1000200@usdonovans.com> <56E1A68F.5040606@usdonovans.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56E1C505.1040106@cs.tcd.ie>
Date: Thu, 10 Mar 2016 19:03:33 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56E1A68F.5040606@usdonovans.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020901090406010004000902"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/g8SgQpJ9EGX1nqepmVSy0bv2fLs>
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: Thu, 10 Mar 2016 19:03:42 -0000

Thanks all. I've requested IETF LC. If there're any more changes
those can be handled during/after that.

Cheers,
S

On 10/03/16 16:53, Steve Donovan wrote:
> All,
> 
> I modifying the new requirement statements, making them MAY instead of
> SHOULD NOT, with the following wording:
> 
>    While done only in exceptional circumstances, Diameter agents MAY
>    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.
> 
>    While done only in exceptional circumstances, Diameter agents MAY 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.
> 
> If there is not concensus on the wording of these requirement statements
> then we can update them as the review process progresses. Regards, Steve
> On 3/9/16 1:04 PM, Steve Donovan wrote:
>> 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, 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 FarrellEnvoyé : 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 mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> 
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>