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

Benoit Claise <bclaise@cisco.com> Sun, 08 May 2016 12:12 UTC

Return-Path: <bclaise@cisco.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 575F212B021; Sun, 8 May 2016 05:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 nnpY5AceBIrI; Sun, 8 May 2016 05:12:41 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAE512B039; Sun, 8 May 2016 05:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1462709560; x=1463919160; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wk2c6JqqCPhL221OcbLaQKsrqwlOdLRAMM5wN3ZOzF4=; b=BlmVmosuiajwPP0H4D0PaFQbCAUGdXMY/bCInWhHjuEdRzCIvJjs3BRq OuSTzHaCP0ymyar0PLCfOkHDY174Sj2uGhgTMpH4F7UwvSa4EAnkwqDMQ gKbJQWn8Vvymm7GoJSu9LmyQyE9vy9V4WnOHAhfIpo7xYx9ZVTfxDsbp2 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CpBACyKy9X/xbLJq1evAWEE4YQAoFnAQEBAQEBZieEQgEBBDhAARALGAkWDwkDAgECAUUGDQgBAYgnvXMBAQEBAQEBAwEBAQEBARqGIIRMhCmFbwEEmCKOHIk/hViPO2KDbTqIawEBAQ
X-IronPort-AV: E=Sophos;i="5.24,595,1454976000"; d="scan'208";a="635533670"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2016 12:12:38 +0000
Received: from [10.61.225.121] ([10.61.225.121]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u48CCHnd020931; Sun, 8 May 2016 12:12:20 GMT
To: Ben Campbell <ben@nostrum.com>
References: <20160504170252.8246.93112.idtracker@ietfa.amsl.com> <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <572F2C8F.9070300@cisco.com>
Date: Sun, 08 May 2016 14:09:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <1D4B3862-3423-4618-B0ED-103B99BBC79F@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/fhm0RG2p7cGM4CriPoNRPkARhsk>
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: Sun, 08 May 2016 12:12:42 -0000

Ben,
> 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. 
I believe so.
> IIRC, DOIC included some guidance about crossing trust boundaries; 
> perhaps DRMP should do the same.
Yes.
That makes me think. I wonder how the following two statements are 
interoperable?

    Diameter nodes MUST have a default priority to apply to transactions
    that do not have an explicit priority set in the DRMP AVP.

    Diameter nodes SHOULD use the PRIORITY_10 priority as this default
    value.


Shouldn't the last SHOULD be a MUST?

Let me explain: a Diameter node wants to send Diameter messages with 
priority above average, so PRIORITY = 12 (because his default is 10). 
Along the path (potentially crossing a boundary), a Diameter node 
doesn't support the DRMP AVP. The next node, which does, sets his 
default priority. The default priority on that node has been configured 
as 13. And now, my Diameter messages will be treated as below average.
Do I miss anything?

Regards, Benoit

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