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

Ralph Droms <> Mon, 06 February 2017 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E28581294E0 for <>; Mon, 6 Feb 2017 13:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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] 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 Qvp7sVTYfN2t for <>; Mon, 6 Feb 2017 13:04:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F09E91294DA for <>; Mon, 6 Feb 2017 13:04:07 -0800 (PST)
Received: by with SMTP id u25so68318506qki.2 for <>; Mon, 06 Feb 2017 13:04:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fm0mq/edlFMHBctdRkh4fOp+902CCUXV4ZiCW3PIj5k=; b=q2/2dYgblTHmOEYShH4eobjrgZ5wLElRjW3jpIdoDdEtabG73tfGJASecDpzXTR551 sYLUsgWW+ZMgP8xn6ElK4pAQhbN4Qo6sJWhwsRyrdlwmEGXkJX02VXWMkARs4bmQpW3J lCUqO02wz7WuIhMv2b5RopeTA59Kfyr1G0Mh5xiNV+jpYOQTE2teKJ42IfK+gttZnsKK Fkm/Ese8IBwsXKbht7Ci/HbAstmASDq6iXxpcHY9ttBMYfkV8Q6qTEV6Vs2gMFY/XFt+ dUzlE8mz3+tnjIcXIBL1Bd1xjvvrmQeE7XONj/nE08HMmTVvRHfZObGye28I0qKtRgNo tdZQ==
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=Fm0mq/edlFMHBctdRkh4fOp+902CCUXV4ZiCW3PIj5k=; b=IQhSaE4HCGycGq9IW4U+jyjYD5lywT3BzUhClPMsUVhOcP6sS7d60iOk9VvFvwReK6 Hyzzqlvlo4v6By3KnO+qiGbuqNzlrSAhuAO88HuRpc7V0pW6C8VZde7AygTe+/+o4mkJ Cqgf85Qe9H76rg6k4C0alY18i5bWzMn2T04K+5hXpvp9Zjk8MrX+E/SXGq8nsiPbUuEr R6RqRfKYqg6ilmLHFIBKnWh0zsxVNCNfiX4KmjhHdauBK+ZHGpNRcNXUgyErnMm2+eT/ vIaPpZXdI8kUD21oD9CWeNiRsOSiuS49sjA7Idq0VJ89HgBiSPOAEKpOj3EaOYpTvcVM OrbA==
X-Gm-Message-State: AMke39laQwTnalj6tXg4z/KdL32Vfv5cY/R26AItKxTRRd/UOo0vrEjEfrCiuLILhfJg7w==
X-Received: by with SMTP id t20mr10584792qkg.299.1486415047144; Mon, 06 Feb 2017 13:04:07 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:7074:fbd6:4df:cdf7? ([2601:18f:801:600:7074:fbd6:4df:cdf7]) by with ESMTPSA id 37sm1493294qto.43.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 13:04:06 -0800 (PST)
From: Ralph Droms <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3D72D99D-5B57-4AE1-B4B6-ACBB0632A1E6"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 06 Feb 2017 16:04:05 -0500
In-Reply-To: <>
To: Russ Housley <>
References: <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: Suzanne Woolf <>, dnsop <>
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: Mon, 06 Feb 2017 21:04:10 -0000

Thanks for your review and comments, Russ.  I've extracted the issues from your review and entered them in the GitHub issue tracker for the document.

- Ralph

> On Feb 6, 2017, at 2:21 PM, Russ Housley <> wrote:
>> This message opens a Working Group Last Call for:
>> "Special-Use Names Problem Statement"
>> <>
>> Proposed status: informational
>> Starts: 2 Feb. 2017
>> Ends: 23 Feb. 2017 (3 weeks)
>> Discussion should go to the mailing list. 
>> Is this draft ready to advance for publication as an Informational RFC, and as guidance for possible updates to RFC 6761? Does it describe the relevant issues clearly, and cover all the relevant ones that should be taken into account in future work in the IETF on the special use names registry or RFC 6761?
> I think the document should be published an Informational RFC once the comments are resolved.  I think it offers a good foundation for a future rfc6761bis document.
> I have several comments…
> I think the title should be Special-Use Domain Names Problem Statement.  The abstract talks about domain names, so the title should match.
> Will I-D.lewis-domain-names be published as an Informational RFC as well?  If not, then the Introduction needs to extract highlights from that document.
> These three bullets in Section 3 overlap:
>    o  Both ICANN and the IETF have the authority and formal processes to
>       assign names from the pool of unused names, but no formal
>       coordination process exists.  The lack of coordination complicates
>       the management of the root of the Domain Namespace and may lead to
>       conflicts in name assignments [SDO-ICANN-SAC090].
>    o  The IETF and ICANN each have administrative authority over the
>       Domain Namespace.  Not all developers of protocols on the internet
>       agree that this authority should reside with the IETF and ICANN.
>    o  Although IETF and ICANN nominally have authority over this
>       namespace, neither organization can enforce that authority over
>       any third party who wants to just start using a subset of the
>       namespace.
> I think there is one main point and two observations.  The main point is that both ICANN and the IETF have the authority and formal processes to assign previously unused names.  The first observation is that ICANN and the IETF need to coordinate to avoid conflicts.  The second observation is that some think that the authority is misplaced.  The second observation needs to be expanded to state the consequence, which I assume is squatting.  If I guessed correctly, the text should explain that squatting leads to conflicts.  The third observation is that neither ICANN nor the IETF has any technical means to prevent squatting.
> I think that the Section 3 bullet on .local should explain that the amount of time involved was excessive, but part of the reason was that the process for special-use assignments was being invented.  As a result, .onion took much less time.
> I think that theSection 3  bullet that references <> should be reworded.  The information in the Ed Note probably does not belong in the Informational RFC.
> I think that Section 4.2.5 should include a reference to the SSAC document.  I know it is also referenced elsewhere.
> And a few Nits…
> The “SUDN” and “SUTLDN” acronyms are defined, but they are not used very often.  I wonder is spelling it out in every case would be more clear.
> In Section 3, there is bad formatting and duplicate informations in the bullet about ICANN Reserved Names.  I suggest:
> s/(see [SDO-ICANN-DAG]Section, Reserved Names )/(seeSection [SDO-ICANN-DAG])
> In Section 4.1.1:
> s/TOR browser/Tor Browser [TP]/
> s/connecting over TOR/connecting over the Tor network/
> [TP] = <>
> In Section 4.1.3:
> s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding [RFC2860]/
> Russ
> _______________________________________________
> DNSOP mailing list
> <>
> <>