Re: [Arcing] Fwd: New Version Notification for draft-stw-whatsinaname-00.txt

Mark Nottingham <> Tue, 12 July 2016 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7B2D12DA6F for <>; Tue, 12 Jul 2016 15:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hEVDRtdMbhHS for <>; Tue, 12 Jul 2016 15:33:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BADE12DA90 for <>; Tue, 12 Jul 2016 15:33:42 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 61C2B22E253; Tue, 12 Jul 2016 18:33:35 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <>
In-Reply-To: <20160712203057.33162.qmail@ary.lan>
Date: Wed, 13 Jul 2016 08:33:31 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20160712203057.33162.qmail@ary.lan>
To: John Levine <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [Arcing] Fwd: New Version Notification for draft-stw-whatsinaname-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2016 22:33:45 -0000

> On 13 Jul 2016, at 6:30 AM, John Levine <> wrote:
>> There seemed to be strong feeling in the ARCING BOF in BA that we needed a document that could serve as advice to
>> protocol designers and software implementers, although it's not entirely clear where such a document should live. It's
>> *not* intended for adoption by DNSOP; although it may ultimately include advice to DNS operators, that's not the
>> primary purpose.
> I read it, and it's all reasonable and informative, but I fear it'll
> just be preaching to the converted.  The unconverted will continue to
> say "yeah, ok, I know all that but I still need to reserve .BANANA"
> We have a severe perverse incentive.  On the one hand, we tell people
> that squatting on domain names is bad for all sorts of reasons, and
> we're not going to let people reserve desirable names for non-DNS use
> for other reasons.  Then anyone who's paying attention can see that
> what you actually do is pick the name you want and squat on it with
> extreme vigor, until we say, oh, all right, just this once.  Or maybe
> we don't, but unless there's some external situation like the one for
> .onion certificates, they hand out software that uses the name they
> want anyway and if the names leak, too bad.
> Until and unless we can de-perversify the situtation, I don't see much
> point in offering more advice.

I tend to agree. Inside the IETF, we have a documented procedure on how to add new names for standard purposes -- although we seem to have a healthy chunk of confusion about its use.

For people doing work outside the IETF, I somehow doubt they'll ever find RFC6761 before they ship a protocol, much less any additional documents published to help interpret it.

Those external people will have to accept that they're working "outside the system" and may not ever have their TLD blessed by registration (thereby risking collision and other problems). OTOH, if an external use sees broad enough adoption, we'll probably be in the position of considering it as a special-use domain name, just as happened with .onion.

As such, IMHO it seems like there are only a few useful things we can do:

1) Clarify within the IETF community what criteria we use for minting special-use domains in this situation (and I'd suggest that broad deployment is a key metric).
2) State, as simply as possible, that people minting their own TLDs run a variety of risks, and may never be recognised by registration (.onion notwithstanding). Basically, we want a short statement to point people at when they ask; an IESG statement would serve. 


Mark Nottingham