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

"Ben Campbell" <> Tue, 10 May 2016 16:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA57812D0CD; Tue, 10 May 2016 09:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vEV4pbgVfXsQ; Tue, 10 May 2016 09:49:45 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1810012D76F; Tue, 10 May 2016 09:49:29 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id u4AGnQL9086563 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 10 May 2016 11:49:28 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: "Ben Campbell" <>
To: "Steve Donovan" <>
Date: Tue, 10 May 2016 12:49:26 -0400
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <>
Cc:, "" <>,, The IESG <>
Subject: Re: [Dime] Ben Campbell'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 16:49:48 -0000

I'm going to clear the discuss at this point--I wanted discussion to 
happen and it is happening. More inline:

On 10 May 2016, at 9:38, Steve Donovan wrote:

> See inline.
> On 5/6/16 3:45 PM, Ben Campbell wrote:
>> On 6 May 2016, at 14:48, Steve Donovan wrote:


>>>> The potential "priority scheme" might help here. But why does a 
>>>> trusted environment matter? Lets say you have trusted clients from 
>>>> vender A and from vendor B, but they select priorities differently?
>>> SRD> They aren't trusted if they aren't using the defined standards.
>> What standard? The application specification? (See my question in 
>> Alissa's thread about whether DRMP can be applied to legacy 
>> applications that don't (yet) define it's use.)
> SRD> I mean application specification or operator policy.  DRMP can 
> apply to legacy applications in two ways.  First, the default priority 
> applies if no priority is explicitly included in the message.  Second, 
> operators can define their own priority scheme.

Okay. That seems to imply a need for configurability, but I'll leave it 
to you whether that should be a standard requirement, or a market 

>>> In addition, trusted environment generally means operated by a 
>>> single entity.  That operator has the job of ensuring that what you 
>>> are proposing would not happen.
>> I can accept if that is the case, but it's not a very satisfying 
>> answer. It leads to having profiles for each operator. (I realize 
>> that the primary users of Diameter have always had operator-specific 
>> profiles of standards, so maybe there's nothing to do here.) This 
>> might at least imply a requirement that priority definitions need to 
>> be configurable.
> SRD> I don't see that it means a profile per operator.  3GPP is likely 
> to create a profile that spans all of its applications and could be 
> used by all operators following the 3GPP standards.

Sure, but it still _might_ require per-operator profiles, right? Even 
3GPP networks tend to have operator specific "flavors" of protocols.

But I recognize this is not unusual for most (if not all) of the 
environments that Diameter is used in.


>> So this may be down to a nit--but the text as written says that the 
>> receiver of a _request_ "SHOULD" use the included priority, but the 
>> receiver of a response "MUST" use the priority. Now, maybe these are 
>> just different ways of encoding the idea that the node may not 
>> implement DRMP. But the former seems to allow the node to override 
>> the priority in the message if it has good reason, but the latter 
>> does not allow the same for a response.
>> As I mention in the discussion about my last discuss point, it seems 
>> odd that a client cannot choose it's own idea of priority over the 
>> servers if it thinks it has a good reason.
> SRD> Thanks for bearing with me on this one.  I see your point now and 
> agree it should be reworded to include allowing for local policy to 
> override what is carried in the message.
Thanks--I realize my first round of comments obscured the point a bit