Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague

"Ralf Weber" <dns@fl1ger.de> Thu, 14 March 2019 14:46 UTC

Return-Path: <dns@fl1ger.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ECD130E58; Thu, 14 Mar 2019 07:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 viGMPQPaz7ju; Thu, 14 Mar 2019 07:46:45 -0700 (PDT)
Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEA8130E99; Thu, 14 Mar 2019 07:46:44 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 3CD955F421F8; Thu, 14 Mar 2019 15:46:42 +0100 (CET)
Received: from [172.19.42.125] (a72-246-0-22.deploy.static.akamaitechnologies.com [72.246.0.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 78C0F5F403AE; Thu, 14 Mar 2019 15:46:39 +0100 (CET)
From: Ralf Weber <dns@fl1ger.de>
To: Ted Lemon <mellon@fugue.com>
Cc: Paul Vixie <paul@redbarn.org>, dns-privacy@ietf.org, dnsop@ietf.org, doh@ietf.org, Vittorio Bertola <vittorio.bertola@open-xchange.com>, hrpc@irtf.org
Date: Thu, 14 Mar 2019 10:41:41 -0400
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <897EAAF7-0EF8-484A-B785-E4C46FCFA87F@fl1ger.de>
In-Reply-To: <D97261BB-1D62-400F-8EBD-886B5BA586BD@fugue.com>
References: <20190311170218.o5hitvysuefhjjxk@nic.fr> <1829067625.16839.1552327024048@appsuite.open-xchange.com> <20190312090142.s32hdimbozsrbovt@nic.fr> <2044747.4WdMZHU4Qz@linux-9daj> <D97261BB-1D62-400F-8EBD-886B5BA586BD@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mA4TgmwhriCUPiZxUPU665AoFEI>
Subject: Re: [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 14:46:47 -0000

Moin!

On 13 Mar 2019, at 20:48, Ted Lemon wrote:

> On Mar 12, 2019, at 2:52 PM, Paul Vixie <paul@redbarn.org> wrote:
>> please do not relegate discussions about the loss of operator control 
>> over the
>> RDNS control plane
>
> Although it’s certainly true that DNS is used as a control plane by 
> many operators, there is no standard “RDNS control plane.”   If 
> you think there should be, that’s something that the IETF could 
> conceivably work on, but it’s not something that the DoH working 
> group is obligated to treat as a standard use of DNS.   And I don’t 
> think it’s a topic on which there is consensus in the IETF.
Well as you said it is something that will not get consensus at the 
IETF, so why work on that? However as you said these RDNS control planes 
exist in real life and even if there is no IETF standard for it, the 
IETF should consider actual deployments when doing work and not just 
IETF standards IMHO and that is what the drafts out there trying to do, 
bring the view of people operating these services into the IETF.

> The problem with the discussion we’ve been having about DoH and how 
> it affects your “RDNS control plane” is that we’re talking past 
> each other, not that the discussion should be had elsewhere.   It’s 
> fine for there to be a discussion, but if there is going to be a 
> discussion, participants need to engage constructively, and not just 
> fling slogans at each other.
So you are ok with having this discussion in DoH, which is good, as the 
DoH protocol caused some application providers to experiment with 
switching resolution per default away from OS and the local network 
provider. A lot of the exhausting thread however was about moving the 
discussion away from DoH. I’ll personally have the discussion 
anywhere, but given that the drafts have been given time in doh and 
people might have planned there schedule around that it should be the 
place. I also think Paul and others have engaged constructive in the 
discussion about the topic.


So long
-Ralf
—--
Ralf Weber