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

Joe Abley <> Mon, 02 November 2020 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C70283A0EA7 for <>; Mon, 2 Nov 2020 09:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mgp6b6d7gHj9 for <>; Mon, 2 Nov 2020 09:56:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84A5C3A0C41 for <>; Mon, 2 Nov 2020 09:56:11 -0800 (PST)
Received: by with SMTP id o205so5458328qke.10 for <>; Mon, 02 Nov 2020 09:56:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5bG5jlgAK56tdiHT4f9tjR+VDrfDlefqRHzRzpWP7NY=; b=GKs+lOYjt42z6/wjYIycjEMxywuWIf0HZs3/pbRzUYdo8yOkKQvdJlwQmPoM6fs6IV AvR6r4KTjrkBAgR2Y7IJULtKg3AQvAZFtc4CtQ5/rIsDqZiHeZ6NOzHtN/PxuYQ+5qG4 FKoA8SbV+OV9abBwqTyusfL6yqUsHB6yJkweA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5bG5jlgAK56tdiHT4f9tjR+VDrfDlefqRHzRzpWP7NY=; b=nFfvJSlGE1QB+Aa9mQc+LZvPPq3bBAfXtMOuo0ksXTGY/mrX+1Jo7W9g1bUypqiu+1 guDjamtAOgv4aCJQKqyeqOi8OZoTiOYPbrcXzquHVe6AUb2Pqeq7WtKKeXje8SUOqU6i EnmI013zcS3MW+IdqH6RunRQlY53fHBsP144b3XFSCrlzINzpJZYjJ5EK6SPk8aBMIey d6GP1Sf/IZm6r6yVG+FhsqHmmMojZaXp4OL3Yi7mFsPVcLLl/HJfwvrqTHxIa62XSTFE wag7SdTUPeuZbpeGbuw+axsstgb41egyCZW13dasKY4dS6ItRnkU8N+wXwwmxLQAX/Ch 1YkA==
X-Gm-Message-State: AOAM530U0K9uTc8qKIYBOOCjpVtb7oB3HFSnQyAF8LQwY7fRsHpXRdDq nWFn9asl++S8duQtbbPHxu05jQ==
X-Google-Smtp-Source: ABdhPJyas0Ja7NlOvZRokjhTxYY2v7g5sWHdZEGsh3rgWUij+7HmP1hy8gpCl1xrDu0lS7aTWPW+tg==
X-Received: by 2002:a37:9e0b:: with SMTP id h11mr16223835qke.88.1604339770418; Mon, 02 Nov 2020 09:56:10 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e784:c7:94bb:c45d:9280:37ad? ([2607:f2c0:e784:c7:94bb:c45d:9280:37ad]) by with ESMTPSA id a200sm6282080qkg.95.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 09:56:09 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Joe Abley <>
In-Reply-To: <>
Date: Mon, 02 Nov 2020 12:56:07 -0500
Cc: Roy Arends <>, dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Paul Wouters <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [DNSOP] Going forward on draft-ietf-dnsop-private-use
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Nov 2020 17:56:13 -0000

Hi Paul,

On 2 Nov 2020, at 12:19, Paul Wouters <> wrote:

> 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.

We anticipated that there would be differences of opinion around this set of topics that might be difficult to resolve. This is the motivation of splitting the issues into different documents, really.

>> (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.

It seemed to us that the needle of consensus might be more consistently in that kind of green arc for this topic, too.

> 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.

I am confident that our chairs are listening and are aware of the lack of jurisdictional clarity on this point.