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

"Ben Campbell" <ben@nostrum.com> Wed, 04 May 2016 17:45 UTC

Return-Path: <ben@nostrum.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 F13AC12D5C2; Wed, 4 May 2016 10:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX6D2l4uuMvS; Wed, 4 May 2016 10:45:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E496412D598; Wed, 4 May 2016 10:45:02 -0700 (PDT)
Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (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 ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18]
From: "Ben Campbell" <ben@nostrum.com>
To: "Benoit Claise" <bclaise@cisco.com>
Date: Wed, 04 May 2016 12:44:57 -0500
Message-ID: <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com>
In-Reply-To: <20160504170252.8246.93112.idtracker@ietfa.amsl.com>
References: <20160504170252.8246.93112.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/VMCX3Mb9d_wPocXWuBBKD6FVqZQ>
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-drmp-05: (with COMMENT)
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, 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 
values:

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 ;-)  )

Ben.