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

"Ben Campbell" <ben@nostrum.com> Tue, 10 May 2016 16:49 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 EA57812D0CD; Tue, 10 May 2016 09:49:47 -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 vEV4pbgVfXsQ; Tue, 10 May 2016 09:49:45 -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 1810012D76F; Tue, 10 May 2016 09:49:29 -0700 (PDT)
Received: from [10.10.1.3] ([162.216.46.125]) (authenticated bits=0) by nostrum.com (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 ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.125] claimed to be [10.10.1.3]
From: Ben Campbell <ben@nostrum.com>
To: Steve Donovan <srdonovan@usdonovans.com>
Date: Tue, 10 May 2016 12:49:26 -0400
Message-ID: <9F7709AD-2BFF-4D1A-9734-251318B90F82@nostrum.com>
In-Reply-To: <5731E463.9070700@usdonovans.com>
References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com> <572A227D.1040203@usdonovans.com> <45E2E5D4-091E-4311-9FDF-271B04D59D05@nostrum.com> <572CF510.20202@usdonovans.com> <7EB67D8A-B1DE-4456-B89A-6E049A6BADE5@nostrum.com> <5731E463.9070700@usdonovans.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/1S-cgLi5ZtCtg9gdNX3Gm4iDYOQ>
Cc: draft-ietf-dime-drmp@ietf.org, "dime-chairs@ietf.org" <dime-chairs@ietf.org>, dime@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and 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: 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 
requirement.

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