Re: [DNSOP] [Ext] [rssac] draft-ietf-dnsop-private-use-tld

Fred Baker <fredbaker.ietf@gmail.com> Mon, 12 October 2020 18:33 UTC

Return-Path: <fredbaker.ietf@gmail.com>
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 036033A1383; Mon, 12 Oct 2020 11:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 DVM7DFZEGlUM; Mon, 12 Oct 2020 11:32:58 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 53B5C3A1338; Mon, 12 Oct 2020 11:32:58 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id b26so14328349pff.3; Mon, 12 Oct 2020 11:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:in-reply-to :date:cc:message-id:references:to; bh=TeyP8lsJXoRzmvyARRox25QYE9NJoHT/8Why118YckM=; b=ccYpEu0NaIGz4u08AoQK1o8Neuw4Fj5OMSTV+uQkN9S/8lFNT/4WzMnzvLgEdMBHw/ 8ZRAWbBkvEscdeFf5Ht2pqHKVOzb4Vy7a2sTdXvWZlS1z/o93Aj7igq5N5Yf2iko2GUX wy3KfAND7A9jGhLKEX6C6ce/DPpL1ckewgWrZ900WYdAnyk8Hpv7cq1g6dnYVIramq3J cZPq16/Zkrc97Ey0hE0Xri8KbRirmRDjVVV8YYklUkZCicHga+M6k4AJ4YAowWrLiLn2 krelXHYuoE7egFZZTaS/9BkXsX9aKC3xdutQHcfSLLMc+IPhtEnYcouGRBDRW4y92tpK jc9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:in-reply-to:date:cc:message-id:references:to; bh=TeyP8lsJXoRzmvyARRox25QYE9NJoHT/8Why118YckM=; b=ZKPcHCg6CpJi0/oAQKgvXLdpCugw7k/9ARG8+SaGiUqXg8+ori8UM1iQbn2M3iHfXu PsCNJir90pyNLxWwKS2a86/1pW4lXeZeNM/IRmEddAXguLL3f8/SDTuVuzkfQRqaBCjn 8eOZKnU6AXOXyb7qbF90f/UcgV9V4zTs54pBe9Sf6WP1/4HBKiMkU0mq/UmxrzC0vmjV qZyZZ7HS6LS2quYnZqvuqnAWegWfNZKYhyjhMP8FgtZA99BVmXmFHVerriciS+zROMka yJHnEwPkQqtmzYqXqKr5qzp7Is1pIVKKirCYViscMfBOWRQ2AzjipO+rxWWa95w1dsOe vdog==
X-Gm-Message-State: AOAM532zTkpOTO8aeq3bHf/WNnMwIFkvYVQf+Lx0fkXCX+GFQC5jVr7p EgTVVZcu0hc3WTnRVqV6iXg=
X-Google-Smtp-Source: ABdhPJy0WlMRsxFixEqLQItjvs7zIKlOSUByUJ1/vNGopNewtr83CaKrRWXqhS8/aLXbeSe4ckz3gg==
X-Received: by 2002:a63:380d:: with SMTP id f13mr4926690pga.105.1602527577741; Mon, 12 Oct 2020 11:32:57 -0700 (PDT)
Received: from ?IPv6:2600:8802:5800:16d0::127e? ([2600:8802:5800:16d0::127e]) by smtp.gmail.com with ESMTPSA id b185sm20253156pgc.68.2020.10.12.11.32.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 11:32:57 -0700 (PDT)
From: Fred Baker <fredbaker.ietf@gmail.com>
X-Google-Original-From: Fred Baker <FredBaker.IETF@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
In-Reply-To: <B8FEA811-F1B6-4059-9299-05CACC9FCB1D@icann.org>
Date: Mon, 12 Oct 2020 11:32:56 -0700
Cc: Daniel Migault <daniel.migault@ericsson.com>, draft-ietf-dnsop-private-use-tld@ietf.org, dnsop <dnsop@ietf.org>
Message-Id: <A0C0CA4F-39CC-4E51-B17C-2C8F1860F337@gmail.com>
References: <B8FEA811-F1B6-4059-9299-05CACC9FCB1D@icann.org>
To: Roy Arends <roy.arends@icann.org>
X-Mailer: iPhone Mail (18B5061e)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nuJGZHYhLPxKLc1WZuj7Z-73Zmc>
Subject: Re: [DNSOP] [Ext] [rssac] draft-ietf-dnsop-private-use-tld
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: Mon, 12 Oct 2020 18:33:00 -0000

Ok, thanks.

Sent using a machine that autocorrects in interesting ways...

> On Oct 12, 2020, at 6:38 AM, Roy Arends <roy.arends@icann.org> wrote:
> 
> 
>>> On 12 Oct 2020, at 08:44, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Oct 8, 2020, at 7:08 AM, Daniel Migault via RSSAC <rssac@icann.org> wrote:
>>> 
>>> Just to let you know that the draft for the private tld has been adopted as WG document. 
>>> 
>>> https://urldefense.com/v3/__https://www.ietf.org/id/draft-ietf-dnsop-private-use-tld-00.txt__;!!PtGJab4!qHw-_WPRJG1YyMoR9K-baj4pViqk2fJQzJDsZbPg0smvVfNrGkUePaUGZNI96GahZI69WNY$ 
>>> 
>>> Yours, 
>>> Daniel
>> 
>> Thanks, Daniel.
>> 
>> Joe and Roy, I'm trying to figure out how you intend these names to be managed and used. In your draft, you opine that having some form of private tld may be useful, and it may be.
> 
> Thank you for taking the time to read the document.
> 
>> You apparently don't intend them to be announced in the root zone
> 
> That is correct. 
> 
>> (or any other zone)
> 
> We make no assumptions on other zones. 
> 
>> , and note that there is nothing that precludes them being formally defined and published from the root in the future, invalidating all extant uses of any such name without warning or review.
> 
> This initial version of the draft details that it is highly unlikely that these two letter strings will ever be delegated, as it would violate principles that were set out in the past. You are quite right that nothing (in this draft) precludes them being formally defined. 
>> 
>> That seems a little precarious.
> 
> One possible avenue that we’re researching is to treat these two letter strings as code points that at one point were set by the ISO as user-assigned, and should therefor be reserved (in the tradition of reserving previously assigned code points so that they can not be re-assigned to mean other things) and designate them as “special use” (RFC6761, RFC8244).
> 
>> How do you plan to manage them?
> 
> It seems to me that using the Special-Use Domain Names is a potential avenue to make sure that these are indeed never delegated from the root zone. Naturally this should all be done in coordination with the various ICANN communities and liaisons. 
> 
> I hope this addresses your question. 
> 
> We will detail our progress at the IETF109 DNSOP WG and hopefully publish version -01 of this document.
> 
> Warm regards,
> 
> Roy
>