Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext

Ted Lemon <> Mon, 26 August 2019 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BD3B120130 for <>; Mon, 26 Aug 2019 05:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m2ma7rSq_ern for <>; Mon, 26 Aug 2019 05:44:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 946B012004C for <>; Mon, 26 Aug 2019 05:44:19 -0700 (PDT)
Received: by with SMTP id 44so17624617qtg.11 for <>; Mon, 26 Aug 2019 05:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=dnGzU/8pnrTxcXz1ltTcU4q8aV1anESWsqYG2ueyh5k=; b=QFn3hAn8xNrV5J0tpOLehAXU8nShnJluDkxJ2NrcTMdfSq1jrqk5BZ0gvY0/liueBh Atc+/DQoBr9iu6uQO/TsibPbFjGGI4/1BevgSlDAKPAkhLRUnNH85MQeZAtDgULBofmv BKjUGqMIKCd3s4uhg764XR+YVioLPT6I+sVVmqjRP/c1LfRAzZTDMI/qw/t2gWVYiomu AljOgjHx4p8OtQTcC72DAJbmBacFK8q8xhIc21PTM1h3flafuti7vhGUrNfGqOSl1Z/A cE4CeqZHy0Ql+KUlXTlHEU5QqQ8xYU0MWzZX6g/h6zyx+0+vKvYX/lpNs5ambN+NDseB TGjA==
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 :message-id:references:to; bh=dnGzU/8pnrTxcXz1ltTcU4q8aV1anESWsqYG2ueyh5k=; b=M575Q4ka9fbZo07UFsdnaHFNvsxenY7hn9HT9FMozH9AcxK+60n9mxhk0kVGaeIdo4 TBGqAgvw4Bxi9n1j2PQuwG1tpGjUbau9BNz5YzoggDuw9ztjKwN/KAU/p/9zhx2SD2o3 CQmINB9gB/u37/x3VqrRd6+PePrIiKrk+hGwgxpm2zwdeotzbZHSuaEMQrlINlwNkNIB dgdFGWuc0+dRJI5QGm3cTjgi98DN3Eba5n1tefoOrpwcibkJY1OKYHFI/c4IPzScXmqS By5fPYrx2OgAclCtWZ+CbIWSJh8BmYF+X4Gm4MI1zgb1h5pVU/b0ZdSm6jWl5zNByrIz mgMQ==
X-Gm-Message-State: APjAAAU7iYPxPCATbnM4gZQzqUGUiU6iKs1SmGmyBy7oew2utc8gULPK u1qASdHg37BOe0j04AiO7JXIaA==
X-Google-Smtp-Source: APXvYqwGT7xROhFwLm+98mduIUB9JbhgnAuW3RZPm1UUmyrGSkJGeysmkK2DMcuiwcSrC5s6hWkwoQ==
X-Received: by 2002:a05:6214:4cc:: with SMTP id ck12mr14680880qvb.194.1566823458394; Mon, 26 Aug 2019 05:44:18 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id i74sm6476478qke.133.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Aug 2019 05:44:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F0630292-B040-4EB0-8DB5-C99B02E7F614"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\))
From: Ted Lemon <>
X-Priority: 3
In-Reply-To: <>
Date: Mon, 26 Aug 2019 08:44:15 -0400
Cc: Warren Kumari <>, dnsop <>
Message-Id: <>
References: <> <20190818182935.F172A87452C@ary.qy> <> <> <> <>
To: Vittorio Bertola <>
X-Mailer: Apple Mail (2.3578.1)
Archived-At: <>
Subject: Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext
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, 26 Aug 2019 12:44:21 -0000

On Aug 26, 2019, at 6:03 AM, Vittorio Bertola <> wrote:
> This is also why not having a registry under .alt makes sense. Having one would make .alt second-level domains almost a functional duplicate of special use TLDs, raising the bar to get them and making special use TLDs only better in vanity/shortness, which would lead the IETF to have to deal mostly with vanity TLD applications.

This isn’t really true.   The main problem with special-use top-level names is that it’s not clear what the process is for assigning them.   The IETF can’t just unilaterally assign them, because we don’t own the namespace.   We sort of have a right to allocate them, but if we do, we have to liaise with ICANN, and we don’t have a process for that.  So every time we do it, it’s a special case.  This makes the IETF leadership understandably reluctant to do it, which means that anybody who wants one can expect it to be a long process with no guarantee of a positive outcome.   This is discussed at length in RFC 8244.

So a TLD that is especially intended for non-DNS special-use names and that is entirely owned by the IETF would in fact be quite a bit easier to use, and we could have an allocation process that did not discourage casual use.

If we want both types of special-use TLD, we could easily have .arc and .adhoc to cover both use cases.   .arc would have a registry; .adhoc would not.