Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Suzanne Woolf <> Tue, 21 March 2017 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59DEE1241FC for <>; Tue, 21 Mar 2017 05:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uFKeBk0MqJSe for <>; Tue, 21 Mar 2017 05:50:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B68E51201FA for <>; Tue, 21 Mar 2017 05:50:56 -0700 (PDT)
Received: by with SMTP id y76so133681114qkb.0 for <>; Tue, 21 Mar 2017 05:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=1fzsXeN1Q2MDSDRtbadfn24DMfe85hQXBXD9vut5TXQ=; b=A65HSzwhU6KQZxC5m6pNCb0z9jhganQ859Aok72pLDAC+KysGOxAwyaB7Cg/WDr01l C773E1V0zofbgVLR5RekFDVD0MfGNWEDtEMyoEsuuhTbRUKFobc7iG2Z7/BeGWR3rTdm 6zTyx93LVByurQbSJtnZ/ayFWwUbJMT6gZI1ZXzFJmbjm4I2pg5u7EIW1cbI4V+QWMVP 756FX0ZuHZC4Qe/KouYm+nWTGYIh3JIB0/l7PFTm7bKEa1bEzpBkJrNqQ046HhIrTYL/ 8KWBu2kB5dT0Njx6XlssZgTOS5Cs8zYoDdCi2TOAIWcOYKA/iXXlK+8BsHT3vX0SwrP8 LBrw==
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=1fzsXeN1Q2MDSDRtbadfn24DMfe85hQXBXD9vut5TXQ=; b=VpH6J52pUDyXCSKaSXJDF9h40VHMmBu8CfpqjlEq5YcsFE6xhhjp9aM5p/kRL4oVNB na1kwJ3gd4FpLmZbfBDSfIpD71A/oc13F0bUr2ZTQlOM+7p9S/+puV46rVyzdZv8G3rJ 0XMUk5hNTs1HcEJMxKJpB6Dudqi6oZhdC6nL4C07+3En80gmup4T7G5sGm9hylU2paDO PZ6moCtv1fjDWhl5QXBD9sXx8xuRY6RstCZhieSm7Yk2CgCI1Q9Ws8NBWUGm2/eD5sOU aOLvQQtyhg00RySOlp94SxH9T3qrxlVfRhG7fyp6vLcxXsML5ALraDB/AmgxBVpzl4XM bG4Q==
X-Gm-Message-State: AFeK/H0s4ljAitR827kSpa07ElrEoWyxiSxWw8Qayvnfm1vNCV8nMO03KIzzw9eJ/IRsiQ==
X-Received: by with SMTP id r65mr32766728qke.239.1490100655825; Tue, 21 Mar 2017 05:50:55 -0700 (PDT)
Received: from ?IPv6:2601:181:c381:c20:6d62:e795:8539:614a? ([2601:181:c381:c20:6d62:e795:8539:614a]) by with ESMTPSA id 141sm11500432qkj.1.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Mar 2017 05:50:55 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_25725F1D-19B1-4710-8156-7006C99F2B65"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Suzanne Woolf <>
In-Reply-To: <>
Date: Tue, 21 Mar 2017 08:50:53 -0400
Cc: Ted Lemon <>, dnsop <>, Terry Manderson <>
Message-Id: <>
References: <> <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Mar 2017 12:50:59 -0000


No hats, except DNS/names geek who has spent a lot of time talking with policy people about why and how the root zone is (and isn’t) special.

> On Mar 20, 2017, at 3:38 PM, Russ Housley <> wrote:
> Ted:
>> There are other processes for adding names to the root zone.  In my opinion, using the special-use TLD registry as a means of putting a name, even one that has a different scope and use case, is an end run around that process.
>> So it seems to me that your position is not that it's inappropriate for a name to both be registered in the root zone and in the special-use names registry, but rather that two processes would have to be followed in order for this to happen.   Is that a reasonable interpretation of what you have said?
> No.  In my opinion, the special-use TLD registry is not appropriate for the assignment of any name that will appear in the root zone.  As I said in my first note, my view is that TLDs assigned through the special-use registry MUST NOT be published in the root zone.
> If you have a domain names that is to appear in the root zone, then the existing process ought to be used for that to happen.

I’d probably state my version of this argument slightly differently: I think Russ is interpreting draft-ietf-homenet-dot-03 as unilaterally imposing a requirement on another body, possibly in violation of that body's own policies and processes, or at least creating a need for them to respond outside of established process.

In this case, “the existing process” simply doesn’t cover what’s being asked for, and extending the existing process to cover what’s being asked for cannot unilaterally be done by the IETF as a body. This creates an external dependency and a need for the IETF to attempt to resolve it— an attempt that may well end in disappointment.

A “special use name” is NOT necessarily a single label name. There is *no* necessary connection between “special use name” and “TLD,” any more than there’s a necessary connection between “special use name” and “the string has the letters of my pony’s name in it". One hypothetical string may be better for a specific use than another, but the characteristics of the string required are protocol-specific (including the significance of the dot), not intrinsic to the registry or to domain names generally. 

To add some color to the problem being created here, I’ll suggest looking at the question we’d be asking if the request were not for “.homenet,” but for “” or “” (where “foo” is a TLD in the current DNS root zone).

If the request were for “,” we wouldn’t be having this conversation at all. The “.arpa” TLD is under the administrative control of the IAB, there’s existing process for asking the IAB to add a name to .arpa (signed or not, delegated or not), and there’s existing process within the IETF community for providing input to IAB decisions on the subject (see RFC 3172). Personally I’d be happy to advocate for the IAB to approve adding an unsigned delegation for to the .arpa zone; it seems to me it wouldn’t even require much change to the draft to satisfy RFC 3172, Sec. 3.

If the request were for “,” we’d be having a different conversation about the implications, but we still wouldn’t be creating a new external process dependency. Operationally speaking, there are literally hundreds of TLDs whose existing policies would allow for the registration of “homenet” as a second level name. In my view it would be unwise to use one when the .arpa alternative is available, because future changes to the rules for such domains are outside of the control of the IETF and the standards process, but at least we wouldn’t be asking for an entirely new process from an external actor under no obligation to give us one.

I see no justification in draft-ietf-homenet-dot for a single-label name, except an implicit suggestion in Sec. 2 para. 2 that the specific string was chosen to be memorable in cases where homenet names are exposed to users. 

I *strongly* suggest that if this document is to be used as justification to create an entirely new process for updating the root zone, coordinated between the IETF and the external body that controls the root zone, the justification should be *much* more explicit.