Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

Roy Arends <> Sun, 01 August 2021 21:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4BDC3A1333 for <>; Sun, 1 Aug 2021 14:45:36 -0700 (PDT)
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 He1_ImB2l2t3 for <>; Sun, 1 Aug 2021 14:45:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E53A3A136C for <>; Sun, 1 Aug 2021 14:45:31 -0700 (PDT)
Received: by with SMTP id n1-20020a4ac7010000b0290262f3c22a63so3951199ooq.9 for <>; Sun, 01 Aug 2021 14:45:31 -0700 (PDT)
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=GeFdst/4q5RsAHbY9SNP4DkQOlL8s6QKRteFnFkMgF0=; b=TMx1weYEVKcj/k/CdmQtzOR13xkh4SuNnJbRQOjQH/AuvLvCUHYsW9cGFdqZIM0brr 6RWK1vkUWcDKeOKVDH3UNMLQSqEamkQPfLYEcqNXv6KtwUOQ9+ev64vJNLpg+zHnsH0l zVqahW4zXMCKvlEH1zJu6MtIDVwij/fz99Who=
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=GeFdst/4q5RsAHbY9SNP4DkQOlL8s6QKRteFnFkMgF0=; b=gNq+DvIS60q2Zx0rvnfInQJDuVYmyjJLA7ai0zdP1TFJBspeDV63IGeKuh37lW3QZZ 2vLVgNF/tSdZygOuDxIeb+dW6a5ImkEC9ILq0u6xIqEvt2bmVM+/f+FpU8OlcOqzd8fB p3VOjkKvMxIWiP4mbFeGJpsrtyrAJ/cOIi1F5dA/cUC6cmT/ynO0164TZDsh8iwQ65QW dlfEkOn2dgOfZ4A7z1VS+bOKJIVczUO1Ys9NZtisatpMKSWkO1SZ7R3z08aQPZ9vvF2x QnWvlH8XmirYCCLgshVUI9cBqB7fuEML/o91Ia5OEUZCf31UhDAXjU1KUsI9ePkc1GPU kkyg==
X-Gm-Message-State: AOAM530nlKbpuxKs9MWFsFb5cUoyPIkLkGcLJB9kQMqPGaBiY1julMmO 2rW+Yq3ob/9rrqfwPgH7rhOLIA==
X-Google-Smtp-Source: ABdhPJyb6l8VQ6xF0OwO7W/rW+MNwvR8UMFpv0wamrLu22V0PH+1L/I+LNhIvxxdTqo6FINp8G9J+g==
X-Received: by 2002:a4a:c387:: with SMTP id u7mr8514386oop.59.1627854329623; Sun, 01 Aug 2021 14:45:29 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id s19sm1411513ooj.7.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Aug 2021 14:45:29 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Roy Arends <>
In-Reply-To: <>
Date: Sun, 1 Aug 2021 22:45:23 +0100
Cc: dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Rob Wilton (rwilton)" <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld
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: Sun, 01 Aug 2021 21:45:37 -0000

> On 30 Jul 2021, at 23:03, Rob Wilton (rwilton) <> wrote:
> Hi Roy, WG,

Hi Rob,

> Roy, just for clarity, am I right to presume that the status of the document that you propose would purely be informational?


> It is, of course, up to the WG to decide what to do with this document, but I would like to make a couple of comments that may help the WG.
> I would like to somewhat echo a point that was made in DNSOP yesterday when this draft was being discussed, in that I don't believe that IETF should publish a document that either directly or indirectly undermines ISO TC46's ownership or authority over the ISO3166 code points.  I believe that this concern is likely shared by other ADs.

That was never the intent. When you read the document, it actually underwrites ISO TC46’s ownership or authority over the ISO3166 code points. Especially the part that the User Assigned code points are assigned to the user of the standard…. 

> Hence, if the WG decides to progress this document with the proposed structure below, then I'm not convinced that just documenting that these code points exist and that some people use them would be sufficient.

Even though these code points exist and folks are (rightly, IMHO) using, for instance, .QY and the likes.

>  Given the informal liaison feedback that was received,

I think the liaison feedback is not on par with the questions asked by the chairs of the IETF and IAB. IMHO it has actively undermined it.

> I think that the IETF would likely need to adopt stronger wording that proactively recommends that these country codes are not used for private networks, and highlights the potential problems with doing so.

How is that not asserting ownership or authority over the ISO code points? 


> Regards,
> Rob
> // Ops AD
> -----Original Message-----
> From: DNSOP <> On Behalf Of Roy Arends
> Sent: 30 July 2021 19:21
> To: dnsop <>
> Subject: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld
> Dear WG
> About 40 years ago, give or take, when Jon Postel planned to use the ISO3166 two character code elements as top level domains representing country names, ISO's TC46 secretariat was contacted (as was requested to users of the ISO3166 standard at the time) and he was told that the standard should not be used for DNS, as the future was in X.500. (Postel wasn’t swayed by the argument, and did what we now refer to as permission-less innovation).
> Recently, the ISO was contacted again, and subsequently the WG was again told that the standard wasn’t to be used in this way. It seems that a handful of folks are swayed by the argument and want to use this as guidance for the future of draft-ietf-dnsop-private-tld.
> Early on, Joe Abley proposed a way forward that I held off initially: Recognise that User Assigned 3166 code elements are used in various ways, including private networks, that these elements have not been delegated and are known to be used to anchor private namespaces. Do not recommend, promote or reserve anything, no registries. Document potential future pitfalls for using these codes for private namespaces and empower readers to make their own decisions.
> I now see that with the current status quo, this might a way forward that both sides of the argument might come together on. Essentially, instead of making the pond safe, we’ll have a warning sign that using the pond is at their own risk.
> I hope the WG can come together on this as a way forward. 
> Warmly,
> Roy
> _______________________________________________
> DNSOP mailing list