Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT)

"Ben Campbell" <> Wed, 04 May 2016 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F13AC12D5C2; Wed, 4 May 2016 10:45:04 -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 kX6D2l4uuMvS; Wed, 4 May 2016 10:45:03 -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 E496412D598; Wed, 4 May 2016 10:45:02 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id u44HiwS5018595 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 12:44:58 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: Benoit Claise <>
Date: Wed, 04 May 2016 12:44:57 -0500
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] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with 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: Wed, 04 May 2016 17:45:05 -0000

I will jump in on one point, since this is related to the discussion on 
whether nodes need a common approach to selecting/interpreting priority 

On 4 May 2016, at 12:02, Benoit Claise wrote:

> -
>  1.  Request sender - The sender of a request, be it a Diameter Client
>        or a Diameter Server, determines the relative priority of the
>        request and includes that priority information in the request.
> Question: what is the risk of DMRP ending up as the DSCP, i.e.
> Every end point changes the value to best service, and in the end, 
> it's
> useless, and uniquely set by the operator.

I think there's a trusted network assumption here, which would include 
an assumption that trusted clients do not intentionally game the system. 
(in contrast with _accidentally_ gaming the system by using a different 
scheme to set priority values.)

However, I think that this sort of assumption should be explicitly 
mentioned. IIRC, DOIC included some guidance about crossing trust 
boundaries; perhaps DRMP should do the same.

(And I guess that does make it a bit like DSCP ;-)  )