Re: [Add] [Ext] antitrust implications of IETF resolver discovery protocol work

Jim Reid <jim@rfc1035.com> Tue, 24 March 2020 13:55 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8473A0943 for <add@ietfa.amsl.com>; Tue, 24 Mar 2020 06:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Level:
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 ct9cWx6kVOIm for <add@ietfa.amsl.com>; Tue, 24 Mar 2020 06:55:21 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18FD3A0BD1 for <Add@ietf.org>; Tue, 24 Mar 2020 06:55:20 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 08CA324205EA; Tue, 24 Mar 2020 13:55:14 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <4f1f615f-d711-2704-3306-9a3ebd01901c@gmail.com>
Date: Tue, 24 Mar 2020 13:55:12 +0000
Cc: Add@ietf.org, Robert Kahn <rkahn@cnri.reston.va.us>
Content-Transfer-Encoding: quoted-printable
Message-Id: <95EB4EE3-24ED-40AF-B1AB-098042D769C4@rfc1035.com>
References: <5c9880d8-d03c-d28f-08b8-5f704270ed56@gmail.com> <BD1F72F3-32F1-448E-AFC7-C38A2B6F33CA@rfc1035.com> <4f1f615f-d711-2704-3306-9a3ebd01901c@gmail.com>
To: Tony Rutkowski <rutkowski.tony@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/tQ-eKoKM8J_W8-6uPojpY3Iqtlw>
Subject: Re: [Add] [Ext] antitrust implications of IETF resolver discovery protocol work
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 13:55:36 -0000


> On 24 Mar 2020, at 12:34, Tony Rutkowski <rutkowski.tony@gmail.com> wrote:
> 
> This is a subject of active discussion among parties analyzing the resolver system marketplace - which will scale significantly in a 5G environment.

Who are these parties and where are those discussions taking place?

> The arena is in the process of becoming much more competitive and diverse.

Is it? Where? How?

> Your note itself raises some flags about it being focused on only DNS-based lookup technologies.  Why not a broader array of resolver technologies - especially when the ADD remit is "in a variety of networking environments, including public networks, private networks, and VPNs." 

Have you followed the long and tortuous process which lead to the formation of the ADD WG? The charter’s scope had to be carefully focused because (a) something diffuse was never going to result in useful output in a reasonable time-frame; (b) the IETF wouldn’t have been able to reach consensus on the creation of the new WG.

Asking for the WG to assimilate every flavour-of-the-month alternative to DNS at this stage is ill-judged and *very* premature. The WG hasn’t even met yet and you seem to want it rechartered. Hmmm.