Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

"John Levine" <> Fri, 03 February 2017 02:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EF9D129ADF for <>; Thu, 2 Feb 2017 18:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ynIa_Soj29vc for <>; Thu, 2 Feb 2017 18:42:33 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3A5C129AD6 for <>; Thu, 2 Feb 2017 18:42:32 -0800 (PST)
Received: (qmail 85527 invoked from network); 3 Feb 2017 02:42:31 -0000
Received: from unknown ( by with QMQP; 3 Feb 2017 02:42:31 -0000
Date: Fri, 03 Feb 2017 02:42:09 -0000
Message-ID: <20170203024209.3584.qmail@ary.lan>
From: John Levine <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Feb 2017 02:42:34 -0000

>If not, can you suggest changes that would get your support for advancing it? (“Send text” if possible!)

It's closer than I had remembered.

In the problem paragraph that starts at the bottom of page 6, on
domain names that have been commandeered, I'd like it to say that
there is no agreement on how to decide that a name has been
comandeered, nor if or how to revisit a name to decide that it's been

(For that last, I'm thinking about .BELKIN, where the routers that
leak the name will eventually all fail, or .CORP where people may use
it less now that CAs don't sign certs any more.)

I'd also like a mention of DNSSEC.  DNSSEC is intended to provide a
signature chain from the root to any leaf, but there is no way to
chain to a SUTLD.  There's also no agreement what to do with DNSSEC
and existing SUTLDs, whether to have DNSSEC say they don't exist, or
to create some sort of unsigned pseudo-delegation, or something else.