Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext

Joe Abley <jabley@hopcount.ca> Fri, 23 August 2019 21:39 UTC

Return-Path: <jabley@hopcount.ca>
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 57137120850 for <dnsop@ietfa.amsl.com>; Fri, 23 Aug 2019 14:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 H6riw4BsByTm for <dnsop@ietfa.amsl.com>; Fri, 23 Aug 2019 14:39:14 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DF5120853 for <dnsop@ietf.org>; Fri, 23 Aug 2019 14:39:14 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id z3so23448841iog.0 for <dnsop@ietf.org>; Fri, 23 Aug 2019 14:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lrut2q+PQ5Ii5mfmuEWVLa98E1q4w0f1pCAHGyZOd7E=; b=hM1jWeJmFlkl8sVKmsDot6u328k32pBbgFeUIGuDLJ/qE/sBmM81/B0ekm6P5Mjys6 v84RFgfYgs8gjD1qPz9oMd8uV+WX9RUSZQWNXLTe59rqvw/9IWecywav5mGX00ak1vTg XPpEEE07LZT3+l97/OkpWZxYva67/lSCLVGpQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lrut2q+PQ5Ii5mfmuEWVLa98E1q4w0f1pCAHGyZOd7E=; b=cSJVJvT8r1AndQhHD3BHsGtpMbK8hGrC2KAT/jigpbV1QnzT10wmsHQ45KE8Cj7MpT 4SyVp0m7wKZptnp6PSBtTp7O2h2MtM5iTA2Qo5b6eXu8qbpj4+liTkfZn+RMwnZ9yLJc Zz+1cgWYR8zPxFO3vF+ttYjyKLtOl7IzYA7NxgbHqpVsMqmxmCqR0RNNnZYOdV+XTjAl eAWgLdWbJTnb4wykrA0QPEjx5RyasDIJQF6sWHCWiZHS0JIeEVr9v5ws1i90qR23EwhC uLfaFOAYYOfFF6I9W/9sv8AfO+oNhoHnf04DkFP33rgSgydJOAbpx/XkI6SXNWY6GJqp XI8A==
X-Gm-Message-State: APjAAAVQBgu1+O6Asi3cnUqmAVjny2UZsFOUViY3vvM8cmPjuuvShUkH ufGjtv8bNSWZabtq7c7nHc/ewg==
X-Google-Smtp-Source: APXvYqz6udwnaDJg/V9RS1z9/sctmMLTMkUpWY5QDuBDoJOD9NiEgC6WNwerOLanlmoGeT8clieGjw==
X-Received: by 2002:a5d:8b52:: with SMTP id c18mr9377955iot.89.1566596353356; Fri, 23 Aug 2019 14:39:13 -0700 (PDT)
Received: from [192.168.1.50] (24-246-23-138.cable.teksavvy.com. [24.246.23.138]) by smtp.gmail.com with ESMTPSA id l26sm3886021ioj.24.2019.08.23.14.39.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 14:39:12 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <756FFFA3-6153-4490-8472-BD89EA85CF40@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_1180A90A-C1C0-4510-9965-8C4F6A0E5C7B"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 23 Aug 2019 17:39:11 -0400
In-Reply-To: <CAHw9_iK1aMZduMuyji0jYr96sLuun-yE3a8sccdmiQ85smr57A@mail.gmail.com>
Cc: John Levine <johnl@taugh.com>, dnsop <dnsop@ietf.org>, Suzanne Woolf <suzworldwide@gmail.com>
To: Warren Kumari <warren@kumari.net>
References: <119AA1A0-86AB-4757-8B15-E36822A3C6FF@gmail.com> <20190818182935.F172A87452C@ary.qy> <CAHw9_iK1aMZduMuyji0jYr96sLuun-yE3a8sccdmiQ85smr57A@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/n7LaUjUNy7xFzH6R1BDsVWKR6xE>
Subject: Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext
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: Fri, 23 Aug 2019 21:39:24 -0000

Hi Warren,

On 23 Aug 2019, at 17:18, Warren Kumari <warren@kumari.net> wrote:

> On Sun, Aug 18, 2019 at 2:29 PM John Levine <johnl@taugh.com> wrote:
>> 
>>> So it would be helpful to know if you think the recommendations are in fact reasonable.
>> 
>> I think they're reasonable but I would more clearly distinguish cases
>> by where the protocol switch is, where I think these are the
>> interesting ones:
>> 
>> 1. Names handled totally unlike the DNS with nothing like an IP address (.onion)
>> 
>> 2. Names handled through mutant DNS which can returns IP addresses (.local, .localhost, .homenet/.home.arpa)
>> 
>> 3. Names that have other problems such as conflicting prior use (.test, .example, .invalid, also .home, .belkin)
>> 
>> For 1, we can reserve if if there's a compelling argument and evidence
>> of clear use.  This leads to a catch 22 where the only way to get the
>> evidence is to squat on it, but I don't see any way around it.  I
>> particularly do not want to reserve names just because someone claims
>> to have a great plan.  I think this probably includes Warren's great
>> plan for .alt.
> 
> .... hey, that's my cue!

I have never been very excited about your ALT proposal. However, I don't think it will do any harm beyond thwarting any secret plans anybody might have to apply for a string in a future round of gTLD applications that is ALT or is confusingly similar to it.

I do have my doubts as to whether reservation of ALT as proposed will actually help with the problem it ostensibly seeks to solve.

People have always been able to anchor their non-DNS naming schemes to domain names they control in the DNS as a way to avoid collisions, and nobody has seemed to think that's a good idea. Is it more likely that someone would anchor their ARTICHOKE alternative naming scheme under ARTICHOKE.ALT than it was for them to use (say) ARTICHOKE.NZ or ARTICHOKE.GLOBAL or something? Even within the IETF we struggled slightly to convince people to use HOME.ARPA instead of HOME, right?

Q: has anybody ever indicated that they would use ALT to anchor a non-DNS but domain-like naming scheme?
A: not so far as we know.

However, I appreciate we can't tell whether it will solve any problem until we try it. I stand ready to eat some kind of at least passably-edible hat if called to do so five years from now.


Joe