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

Jim Reid <jim@rfc1035.com> Tue, 24 March 2020 12:09 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 565F63A0942 for <add@ietfa.amsl.com>; Tue, 24 Mar 2020 05:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 gZVFhMCm7C8K for <add@ietfa.amsl.com>; Tue, 24 Mar 2020 05:09:46 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39A03A0900 for <Add@ietf.org>; Tue, 24 Mar 2020 05:09:45 -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 F002E24205EA; Tue, 24 Mar 2020 12:09:42 +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: <5c9880d8-d03c-d28f-08b8-5f704270ed56@gmail.com>
Date: Tue, 24 Mar 2020 12:09:41 +0000
Cc: Add@ietf.org, Robert Kahn <rkahn@cnri.reston.va.us>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD1F72F3-32F1-448E-AFC7-C38A2B6F33CA@rfc1035.com>
References: <5c9880d8-d03c-d28f-08b8-5f704270ed56@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/w_pBLvwDMsdinC1ctNSFIX9UHco>
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 12:09:47 -0000

On 24 Mar 2020, at 01:21, Tony Rutkowski <rutkowski.tony@gmail.com> wrote:
> 
> Bob can speak as to the similarities and why The Handle System might be better here, or a competitive alternative.

IMO it’s incumbent on you to do this since you raised this issue. Please explain. Though that’s probably off-topic for this list and WG.

The ADD WG is looking at discovery for services using DNS-based lookup technologies, not those using The Handle System (tm). Those two lookup mechanisms are orthogonal to each other and may well be mutually exclusive.

The WG’s charter -- ADD is an acronym for Adaptive DNS Discovery BTW -- actually says "This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments”. There’s no mention of X.1255 or The Handle System at all.

I’m puzzled why you have raised what seems to be a couple of non-sequiturs.