Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Joe Abley <> Thu, 30 April 2020 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB83F3A0DBB for <>; Thu, 30 Apr 2020 15:17:42 -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 QF1fpAW1BheM for <>; Thu, 30 Apr 2020 15:17:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18EE23A0BB2 for <>; Thu, 30 Apr 2020 15:17:38 -0700 (PDT)
Received: by with SMTP id e17so6494105qtp.7 for <>; Thu, 30 Apr 2020 15:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=px0wf0p7RiwuOwYVNH6C7o4LRv2oXTQ4BZsORIIHDtk=; b=YbGuHAWqxDD3AV01s00hV6FrXAw7TP+CnpWFADMZC7IJ3Fo2d+vB37Cwv2wBG0nJqB r/CuTIhXqzQU/WvQ5VYNWYfvlgyXj71DjAE8iPBfWt71CbSDVHA7/Few09ADlIY487Uh 7/v8bVtYpEjuDtKnY76YXcD6wFWv8DpIXQe/M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=px0wf0p7RiwuOwYVNH6C7o4LRv2oXTQ4BZsORIIHDtk=; b=dI1orMzcM7P6MBZExi41nP8ZUlxLN4BdwoaYKJdIlN7H0L4xbFMuDuPt0H3sBodMnL i7GTG2YH+6fjoXQlBg9GrDO5GPivGkFTwCLq1xnNx2hWkeOWAJniy4ZX81saXsIfSisp 0LMKruAE37Ylmfbmzaoxu56CwQB/goSLaI6tIVOKAmxPs7WdTGiCF3QI+Wi7XErYl36M VTaZsqJndVs91CnsCxwrxzJRETB6vmt4UPZy405KzJeta8fo6V9qgj8Ydqh/3PpUNL8/ 3jJykSWPt7WIp3gzXltQbyix5pdM/8w7xJRFjAuPq3lduvhwhkO2iTLaA/Oh/ThOm7WF qGCQ==
X-Gm-Message-State: AGi0PuY4dy4FPKcOcF0IHY7dmwor8Kf+4RIaA3xCVtfcBpvgbvqsaPhj vylo+PJee7juA+WP1cDSXg4zvg==
X-Google-Smtp-Source: APiQypK7EFdirTlltnE1jbE4cr6yw+qvZhkVlvJux1ujlq3yHCMr6U/9CbCVp0hSoo3ED0eICOUxFg==
X-Received: by 2002:ac8:71c7:: with SMTP id i7mr783631qtp.159.1588285056685; Thu, 30 Apr 2020 15:17:36 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:c7:8838:194f:518f:74ce? ([2607:f2c0:e784:c7:8838:194f:518f:74ce]) by with ESMTPSA id p25sm1192357qkk.18.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 15:17:35 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_BF8ABD48-9095-45D2-BF3C-0D1092B16060"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 30 Apr 2020 18:17:33 -0400
In-Reply-To: <>
Cc: Tim Wicinski <>, dnsop <>, dnsop-chairs <>
To: Wes Hardaker <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind
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: Thu, 30 Apr 2020 22:17:43 -0000

Hi Wes.

On 30 Apr 2020, at 17:41, Wes Hardaker <> wrote:

> I've just pushed the -04 version of the draft that has a fairly major
> overhaul of the problem statement.  I'd appreciate if it helps clarify
> the technical reasons why deployment of the bit would be beneficial in
> ways that are unrelated to contractual type controls.  I'll include the
> first three sections below, which are the parts that really changed.

Thanks! It's on the list :-)

>> Perhaps more substantially, but with more rapid oscillation of hands,
>> I am concerned that this draft, if adopted, will gain legitimacy in
>> policy circles where it might actually do damage.
> I can't speculate whether zones would be under increased market pressure
> for a DNS feature you clearly indicate might be desired.  I find this
> statement that "this looks too helpful to some people; let's not do it"
> fascinating :-)

Well, no. I was really concerned that it would be of no help at all whilst simultaneously sounding tremendously necessary ("transparency!"), and that it might have collateral damage.

>> An example might be where there is contractual or market pressure to
>> require it for TLDs where its effect might be to cause suppressed
>> orphan glue to break otherwise functional delegations.
> I'd love to see some registration point cases where this technique would
> cause harm.

Well, for example there are some 28,000 examples of orphan glue in the ORG zone. There are about 93,000 across all gTLDs. I haven't analysed these orphan glue records in any useful detail (that's on the list, too :-) but I'm wary of assuming that they could all be safely suppressed without harming any other delegation.

Anyway, thanks for the edits; I will send comments back to the list when I've had a chance to read them thoroughly.