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

Steve Donovan <srdonovan@usdonovans.com> Tue, 10 May 2016 13:26 UTC

Return-Path: <srdonovan@usdonovans.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 3469712B077; Tue, 10 May 2016 06:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 MIe0rbZnpnI9; Tue, 10 May 2016 06:26:54 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB7F12B00D; Tue, 10 May 2016 06:26:54 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:54683 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1b07gX-001RTU-4j; Tue, 10 May 2016 06:26:53 -0700
To: Ben Campbell <ben@nostrum.com>
References: <20160503213139.8362.8871.idtracker@ietfa.amsl.com> <8354_1462318968_57293778_8354_15408_1_6B7134B31289DC4FAF731D844122B36E01E4C8AE@OPEXCLILM43.corporate.adroot.infra.ftgroup> <572A1C14.5020907@usdonovans.com> <74A5239A-329E-4F82-9FBF-497C9D906E89@cooperw.in> <572A4520.5090101@cs.tcd.ie> <90C95598-F68D-4F94-8AE3-FAFF403F560E@cooperw.in> <572AFD9D.7010909@cs.tcd.ie> <CF2919CA-DE13-44C1-8430-DD5B8D8DB252@cooperw.in> <572B48D2.6090801@cs.tcd.ie> <154814f98f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> <572B5B0D.9010001@cs.tcd.ie> <572CC06E.7090405@usdonovans.com> <2609D587-563B-4C0E-B769-FB8DC0A9D10F@nostrum.com>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <5731E198.6060408@usdonovans.com>
Date: Tue, 10 May 2016 08:26:48 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <2609D587-563B-4C0E-B769-FB8DC0A9D10F@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/mpUo47L10RHO8et2yVFdIMPya9s>
Cc: draft-ietf-dime-drmp@ietf.org, Alissa Cooper <alissa@cooperw.in>, dime-chairs@ietf.org, dime@ietf.org, IESG <iesg@ietf.org>
Subject: Re: [Dime] Alissa Cooper'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 13:26:55 -0000

See inline.

On 5/6/16 3:03 PM, Ben Campbell wrote:
> I'm jumping in here because part of it also relates to some of my 
> DISCUSS points:
>
> On 6 May 2016, at 11:03, Steve Donovan wrote:
>
>> All,
>>
>> I was on jury duty yesterday so I wasn't able to fully engage.
>>
>> I agree that we are close to resolving issues and I will produce an 
>> updated draft that addresses IESG review comments, along with one 
>> change requested by IANA.
>>
>> I also need to respond to Ben's last email.
>>
>> My proposal, modulo Ben's comments, is to add the following to the 
>> draft:
>>
>> - Emphasizing that the mechanism only works when one of the following 
>> is true:
>>
>>   - Agents only handle a single DRMP application.
>
> What does that mean from a standards perspective? A "relay agent" is 
> assumed to be application-agnostic. So in some ways, it supports all 
> applications. Even ones that don't exist yet. A proxy, OTOH, is 
> assumed to know application semantics--but I don't think that is what 
> we are talking about, is it?
>
> Or do this just mean that the operator makes sure that messages from 
> only one application traverse the agent? (There's risk that they will 
> forget that part when adding a 2nd application down the road.)  (But 
> see next comment...)
SRD> It means that the network is set up so the relay, be it an agent or 
a proxy, only handles a single application.
>
>>   - All Diameter applications that support DRMP used in a Diameter 
>> network must have consistent and synchronized priority definitions. 
>> I'll add some words around what is meant by consistent and synchronized.
>
> Those would help, but I don't think handling a single DRMP application 
> necessarily removes the need for consistent priority definitions.
>
> As with DOIC, you may see cases where vendors and or operators wish to 
> apply DRMP to applications even though the specifications for that 
> application do not define its use. (or perhaps before the owners of 
> the standard for legacy applications get around to doing so.) I'm not 
> sure if the intent is to allow that, but if it is, then you need 
> consistent policies across nodes.
SRD> The consistency mentioned above is across applications.  A nodes 
adherence to standards or operator policy addresses consistency across 
nodes.
>
> If the expectation is that DRMP can only be used when documented in 
> the "standard" for the application, then it would be good to include 
> some high-level detail about what we expect to be documented.
SRD> This is reasonable.  Although its not going to be much more than 
documenting what priority to use in which situations.
>
>>
>> - Strengthening wording indicating that this mechanism is designed to 
>> work in trusted environments.  This includes recommending stripping 
>> or modifying priority settings for requests received from untrusted 
>> sources.  The determination of what is a trusted and untrusted source 
>> would be out of the scope of the DRMP draft.
>>
>> - Adding the other updates that have been agreed to as part of this 
>> review cycle.
>>
>> This leaves as future work, should there be a need, the handling 
>> multiple "priority schemes" within a single network.  This is a very 
>> hard problem and not a use case that is currently needed by existing 
>> users of Diameter.
>>
>> I'll wait for feedback, especially from the Dime working group, 
>> before I start updating the document.
>>
>> Regards,
>>
>> Steve
>>
>> On 5/5/16 9:39 AM, Stephen Farrell wrote:
>>> Great. I think we're maybe at the point where pushing out a
>>> revised I-D that has the fixes we now know we want would be a
>>> good plan and then we can go back around the discuss holders
>>> and see where we're at.
>>>
>>> Make sense? If not, then please continue the discussion to
>>> get us there.
>>>
>>> Cheers,
>>> S.
>>>
>>> On 05/05/16 15:25, Steve Donovan wrote:
>>>> I'm okay with this addition.
>>>>
>>>> Steve
>>>>
>>>>
>>>> On May 5, 2016 8:21:22 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
>>>> wrote:
>>>>
>>>>>
>>>>> On 05/05/16 14:19, Alissa Cooper wrote:
>>>>>> I think the gap is in Section 5, where it should be noted that in
>>>>>> order for priority information to be reliably usable in the way that
>>>>>> use cases 5.1 and 5.2 call for, the Diameter nodes sending and
>>>>>> consuming it must have pre-established trust relationships of the
>>>>>> sort described in Section 11.
>>>>> Sounds reasonable to me. Authors?
>>>>>
>>>>> S.
>>>>>
>>>>