Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use

Paul Wouters <paul@nohats.ca> Mon, 02 November 2020 17:19 UTC

Return-Path: <paul@nohats.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 333EA3A0D2E for <dnsop@ietfa.amsl.com>; Mon, 2 Nov 2020 09:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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=nohats.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 Lu2JdAkwpH_C for <dnsop@ietfa.amsl.com>; Mon, 2 Nov 2020 09:19:44 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D83B3A0D2F for <dnsop@ietf.org>; Mon, 2 Nov 2020 09:19:44 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CQ05p5nz0zFKP; Mon, 2 Nov 2020 18:19:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1604337582; bh=HBzYXEYy99nO+xl+dmxu4laCSsEXyApbbeYTPm81B9I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=q9rWQyqyAIm9tZSDdByIjQKsK7BqLUN6JOBWAZ0jU9QTFH7FPkTrenAZThvL8sAVX cpt3lX62G6pRSF+wzRjNX/uN+JgfCxmHx87nk654Dl/YMfNZVO9hJYo/Sg6n2csjur MuDSCZg2OVhNlNxyGEC7NY0RhcklGgzfugJ7abtc=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SGuKq2xtSiTH; Mon, 2 Nov 2020 18:19:41 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 2 Nov 2020 18:19:41 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id AE4CF60298AC; Mon, 2 Nov 2020 12:19:39 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A4AC4350721; Mon, 2 Nov 2020 12:19:39 -0500 (EST)
Date: Mon, 2 Nov 2020 12:19:39 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Roy Arends <roy@dnss.ec>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <8E19F8FE-D15D-4731-B8FB-EC1695819857@dnss.ec>
Message-ID: <alpine.LRH.2.23.451.2011021215330.2672107@bofh.nohats.ca>
References: <8E19F8FE-D15D-4731-B8FB-EC1695819857@dnss.ec>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I6vr-I4m0fAyPDcQOR47uO3iUwM>
Subject: Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use
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, 02 Nov 2020 17:19:47 -0000

On Mon, 2 Nov 2020, Roy Arends wrote:

> As for version -01, the authors propose to separate the document into two:
>
> (1) A document that discusses the motivation for private space top level domains, provides recommendations for people setting them up, etc.

The IETF / DNSOP should not recommend setting up private space TLDs by
instructing people how to do this.

> (2) A document to note that ISO policy supports using ISO3166 User Assigned code elements to anchor private namespaces, recognise that use and, finally, recommend against use of these code elements for any other purposes that cause operational or security problems (e.g. due to collisions with delegations in the root zone).

I still don't see the value in this, but there is also no harm done
describing this. So I am ambivalent on this.

In general, I'm mostly afraid that this/these document(s) will eat up a
lot of DNSOP resources/time, seeing more Special Domain discussions and
all, while naming things is really outside of IETF/DNSOPS area.

Paul