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

Suzanne Woolf <> Mon, 12 August 2019 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A19B21214CD for <>; Mon, 12 Aug 2019 15:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NinGTG4vuhtJ for <>; Mon, 12 Aug 2019 15:42:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65436120FBB for <>; Mon, 12 Aug 2019 09:25:21 -0700 (PDT)
Received: by with SMTP id u34so4100699qte.2 for <>; Mon, 12 Aug 2019 09:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MeXOqJIno3yZ6AjTp1AGvery2/sf0mwybXvQMa8nSyU=; b=K8TmwywvLPRwMdNBoKgZcz/hX6fYXAZrRTaltP8pn1NihTK6/VDbj3b561uoc18loT atxjqAxkZfCRPchg+eT8SX3TVFMiDp9Xgx/62HrpcgN4J7Ss3O2KkElhfaGOxx5UpsaP Y86sOMwIkonF/pkn9hA5GACE8jRBPLKpMDiNq6fPxVOjVHzbr89fw62DeNOqOr1KPujS WKPmKY0oFaCmlLV/eQRAKUMUJFr/MZYSyJj2R6uG3mjOBB12Y0cGQU9UewQXrld6G5Ka TmrRsn1uB8mmM5f1rl+QYySwU4Qnf6FNyq0Wlf677AW0F6Wkgeu9XRPWehZaqguLqPN/ Cjcg==
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=MeXOqJIno3yZ6AjTp1AGvery2/sf0mwybXvQMa8nSyU=; b=MKi4yUaIVP/XRwA29kYz++NHu47eEf0QEQ2bLimDVkCqfKtB342lOwaK2Ml1sqR/hd xCz64znsusAggSuhZhRGhc4dXzzkdXc3tYxAcG+MLDYtF5R3ZhfYqctFKWYTr4YnJJdK WXbr7aG3nqkgGlH1KgCQwwD7msCf7B5cw9Bu+vpbu4Vg/Ll4pQ7bOCuyzUK3PhnsWRog DjgHBhu3W13Hc2UedEZb/urVPIqHAoOubuXAsFX2av9Qe+yGYLVKxI8/W1gHxsy0vlwA UjQv4P+mqpKMhhRmnM3MeNJlNz5a1kKQ3Sx8ihwRGtNq4gecmKAUzw/ifTtcHM4aUrz/ lp8Q==
X-Gm-Message-State: APjAAAVXGJI+C7HdX7dU9xdDf3eT4zKxtv8OZMR1/gL31DulibaCMfjD uJLILNGncdres/rDFENtSnQ+OZXaOtQ=
X-Google-Smtp-Source: APXvYqzVwnzgXn3fkKGFnB/E/W2YRbqVoEyMxT/UUHSSIWm2MTN4JVJuWsCFrVPAHHc/m7u/heH99g==
X-Received: by 2002:ac8:2bd4:: with SMTP id n20mr31390629qtn.131.1565627120034; Mon, 12 Aug 2019 09:25:20 -0700 (PDT)
Received: from ?IPv6:2601:181:c381:29fe:4985:c1f9:6689:2c24? ([2601:181:c381:29fe:4985:c1f9:6689:2c24]) by with ESMTPSA id g207sm8006137qke.11.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 09:25:18 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Suzanne Woolf <>
In-Reply-To: <20190810153605.0CF2E7DEB29@ary.local>
Date: Mon, 12 Aug 2019 12:25:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20190810153605.0CF2E7DEB29@ary.local>
To: John Levine <>
X-Mailer: Apple Mail (2.3445.104.11)
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, 12 Aug 2019 22:42:47 -0000

(Draft author hat here, not WG chair)

> On Aug 10, 2019, at 11:36 AM, John Levine <> wrote:
> In article <> you write:
>> Thank you Paul.
>> As an incentive to everyone else  -- there is an Easter Egg hidden in
>> this document: if you judiciously choose letters from the text (and
>> reorder them) you can create a very rude word.
> I think that like everyone else I've read it, but I'm not sure what to say.

Well, the document is intended as guidance to the IETF community and to the  current/future IESG on what it’s reasonable for people to do with reservations for special use domain names, particularly in IETF protocols. This is only a piece of the larger space around the general idea of the special use names registry, but it seemed like a useful place to start.

So it would be helpful to know if you think the recommendations are in fact reasonable. 

In particular, there’s a couple of distinctions the draft makes in order to carve out what looks (to me, anyway) like a manageable piece of the larger issue of administration of domain names as a superset of DNS names: between TLDs and names elsewhere in the namespace, and between IETF protocols and other possible uses for SUDNs.

First, special use “TLDs” (single label domain names) present a hard case for the IETF because of the nexus with another body (ICANN) that has actual authority over what DNS names are delegated as TLDs in the public DNS. A failure to coordinate in such cases could result in poor outcomes for anyone who assumes that the reservation of a special use name under RFC 6761 comes with any assurances about the public DNS.

IMO the IETF has three choices here: refuse to reserve single label names as special use; agree to reserve such names, at least as a possibility, and assume coordination is unnecessary; or ask ICANN, through the established liaison relationship, to discuss a process for coordination on reservation of special use single label names outside of the public DNS.

No matter which course is chosen, however, a special use name under a TLD that’s already in existence and already under the policy control of the IETF presents a simpler path to approval with fewer risks, so the draft encourages IETF WGs to use such names in their protocols where possible, and the IESG to approve them. (This is the “” case.)

Second, the other line the draft tries to draw is between IETF protocols, and requests for special use name registrations for use in protocols or code bases not developed in the IETF. 

This isn’t about excluding anyone else from access to some magical potion, and in fact I’d be happy to propose a more detailed set of guidelines for non-IETF protocols that it might be reasonable to approve special use names for. (The draft suggests “stable specification required,” but I’m not attached to it.) The rationale here is that an IETF registry should have clear policy around its administration, and this one doesn’t: approval of the next .onion is likely to be just as ad hoc as the previous one, because “standards track” has a clear meaning inside the IETF, but there’s no equivalent set of guidelines for requests not based in IETF process. This doesn’t scale in, for example, the case that a sponsor of a closed, non-IETF protocol wants to reserve a set of names: is there any limit to how many names the IETF is willing to reserve? Should there be a stable reference to their use? Is there any presumption that if an existing codebase that uses a reserved name is forked, the new codebase should be able to get a new special use name? RFC 6761 is silent on these questions, which are implicitly resolved for a protocol that’s on the standards track in the IETF, but not for anything else.

If a new organization of the contents would be less baffling, I’m definitely open to that, too.