Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

Steve Donovan <> Tue, 10 May 2016 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3469712B077; Tue, 10 May 2016 06:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MIe0rbZnpnI9; Tue, 10 May 2016 06:26:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BB7F12B00D; Tue, 10 May 2016 06:26:54 -0700 (PDT)
Received: from ([]:54683 helo=Steves-MacBook-Air.local) by with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <>) id 1b07gX-001RTU-4j; Tue, 10 May 2016 06:26:53 -0700
To: Ben Campbell <>
References: <> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <> <> <> <> <> <> <> <> <> <> <>
From: Steve Donovan <>
Message-ID: <>
Date: Tue, 10 May 2016 08:26:48 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Cc:, Alissa Cooper <>,,, IESG <>
Subject: Re: [Dime] Alissa Cooper's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 May 2016 13:26:55 -0000

See inline.

On 5/6/16 3:03 PM, Ben Campbell wrote:
> I'm jumping in here because part of it also relates to some of my 
> DISCUSS points:
> On 6 May 2016, at 11:03, Steve Donovan wrote:
>> All,
>> I was on jury duty yesterday so I wasn't able to fully engage.
>> I agree that we are close to resolving issues and I will produce an 
>> updated draft that addresses IESG review comments, along with one 
>> change requested by IANA.
>> I also need to respond to Ben's last email.
>> My proposal, modulo Ben's comments, is to add the following to the 
>> draft:
>> - Emphasizing that the mechanism only works when one of the following 
>> is true:
>>   - Agents only handle a single DRMP application.
> What does that mean from a standards perspective? A "relay agent" is 
> assumed to be application-agnostic. So in some ways, it supports all 
> applications. Even ones that don't exist yet. A proxy, OTOH, is 
> assumed to know application semantics--but I don't think that is what 
> we are talking about, is it?
> Or do this just mean that the operator makes sure that messages from 
> only one application traverse the agent? (There's risk that they will 
> forget that part when adding a 2nd application down the road.)  (But 
> see next comment...)
SRD> It means that the network is set up so the relay, be it an agent or 
a proxy, only handles a single application.
>>   - All Diameter applications that support DRMP used in a Diameter 
>> network must have consistent and synchronized priority definitions. 
>> I'll add some words around what is meant by consistent and synchronized.
> Those would help, but I don't think handling a single DRMP application 
> necessarily removes the need for consistent priority definitions.
> As with DOIC, you may see cases where vendors and or operators wish to 
> apply DRMP to applications even though the specifications for that 
> application do not define its use. (or perhaps before the owners of 
> the standard for legacy applications get around to doing so.) I'm not 
> sure if the intent is to allow that, but if it is, then you need 
> consistent policies across nodes.
SRD> The consistency mentioned above is across applications.  A nodes 
adherence to standards or operator policy addresses consistency across 
> If the expectation is that DRMP can only be used when documented in 
> the "standard" for the application, then it would be good to include 
> some high-level detail about what we expect to be documented.
SRD> This is reasonable.  Although its not going to be much more than 
documenting what priority to use in which situations.
>> - Strengthening wording indicating that this mechanism is designed to 
>> work in trusted environments.  This includes recommending stripping 
>> or modifying priority settings for requests received from untrusted 
>> sources.  The determination of what is a trusted and untrusted source 
>> would be out of the scope of the DRMP draft.
>> - Adding the other updates that have been agreed to as part of this 
>> review cycle.
>> This leaves as future work, should there be a need, the handling 
>> multiple "priority schemes" within a single network.  This is a very 
>> hard problem and not a use case that is currently needed by existing 
>> users of Diameter.
>> I'll wait for feedback, especially from the Dime working group, 
>> before I start updating the document.
>> Regards,
>> Steve
>> On 5/5/16 9:39 AM, Stephen Farrell wrote:
>>> Great. I think we're maybe at the point where pushing out a
>>> revised I-D that has the fixes we now know we want would be a
>>> good plan and then we can go back around the discuss holders
>>> and see where we're at.
>>> Make sense? If not, then please continue the discussion to
>>> get us there.
>>> Cheers,
>>> S.
>>> On 05/05/16 15:25, Steve Donovan wrote:
>>>> I'm okay with this addition.
>>>> Steve
>>>> On May 5, 2016 8:21:22 AM Stephen Farrell <>
>>>> wrote:
>>>>> On 05/05/16 14:19, Alissa Cooper wrote:
>>>>>> I think the gap is in Section 5, where it should be noted that in
>>>>>> order for priority information to be reliably usable in the way that
>>>>>> use cases 5.1 and 5.2 call for, the Diameter nodes sending and
>>>>>> consuming it must have pre-established trust relationships of the
>>>>>> sort described in Section 11.
>>>>> Sounds reasonable to me. Authors?
>>>>> S.