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. >>>>> >>>>
- [Dime] Alissa Cooper's Discuss on draft-ietf-dime… Alissa Cooper
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… lionel.morand
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Alexey Melnikov
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Trottin, Jean-Jacques (Nokia - FR)
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Steve Donovan
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Stephen Farrell
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Steve Donovan
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Stephen Farrell
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Alissa Cooper
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Stephen Farrell
- [Dime] RE : Re: Alissa Cooper's Discuss on draft-… lionel.morand
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Steve Donovan
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Stephen Farrell
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Gunn, Janet P
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Steve Donovan
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Ben Campbell
- Re: [Dime] Alissa Cooper's Discuss on draft-ietf-… Steve Donovan