[DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)
Spencer Dawkins <spencerdawkins.ietf@gmail.com> Wed, 05 July 2017 02:22 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DC612708C; Tue, 4 Jul 2017 19:22:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-sutld-ps@ietf.org, Suzanne Woolf <suzworldwide@gmail.com>, dnsop-chairs@ietf.org, suzworldwide@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149922136362.3281.8137557234349761847.idtracker@ietfa.amsl.com>
Date: Tue, 04 Jul 2017 19:22:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qeUIXtL2jkwTYaiq_5Vu4mNHjss>
Subject: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 02:22:44 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-dnsop-sutld-ps-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have loads of editorial comments, but I'm a Yes, thank you folks for writing this, and Just Do The Right Thing ... This text 5. If there is an IETF process through which a TLD can be assigned at zero cost other than time, this process will be used as an alternative to the more costly process of getting the name registered through ICANN. seems extremely certain ("will be used"). Is that what you meant to say? I'm assuming that the intended audience for this document is "people who know less than the authors about the lurid history of DNS". If so, in this text, 11. In some cases where the IETF has made assignments through the RFC 6761 process, technical mistakes have been made due to misunderstandings as to the actual process that RFC 6761 specifies (e.g., treating the list of suggested considerations for assigning a name as a set of requirements all of which must be met). In other cases, the IETF has made de facto assignments of Special-Use Domain Names without following the RFC 6761 process. citations of at least one de facto assignment would likely be helpful. Again, I'm assuming your intention is to give people something to think about. Given that, I wonder how badly you need the last sentence in 4.1. Primary Special-Use Domain Name Documents The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice. Only one of these documents is an IETF consensus document. You're pretty careful about pointing out whether each of the RFCs are consensus documents in the following subsections, and you provide enough explanation for the reader to know why the reader cares about each document. With the last sentence of 4.1 as lead-in, and no background because that comes later, document by document, I wouldn't take that section seriously. I know that text is in Section 4.1, but "these documents" invited me to assume the same thing about the documents in Section 4.2 as well. If you need to keep the last sentence, you might consider Only one of the documents described in Section 4.1 is an IETF consensus document. I know we publish a lot of passive voice text around here, but in 4.1.4. Liaison Statement on Technical Use of Domain Names As a result of processing requests to add names to the Special-Use Domain Name registry, as documented in [I-D.chapin-additional-reserved-tlds] and [I-D.grothoff-iesg-special-use-p2p-names], a review was chartered of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of the review, affirmed that the discussion would be "open and transparent to participation by interested parties" and explicitly invited members of the ICANN community to participate. I am guessing who is requesting what, and who is performing the review, and who sent the liaison statement. Is this saying When the IETF received processing requests to add names to the Special-Use Domain Name registry, as documented in [I-D.chapin-additional-reserved-tlds] and [I-D.grothoff-iesg-special-use-p2p-names], the IETF chartered a review of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The IETF sent a Liaison Statement [SDO-IAB-ICANN-LS] to ICANN to notify ICANN of the review, affirm that the discussion would be "open and transparent to participation by interested parties" and explicitly invite members of the ICANN community to participate. ? But, as I said, I'm guessing. I'm also not sure whether you want the reader to know the IETF sent a liaison to ICANN, and why, or whether you want the reader to look at the liaison statement text itself. If you want readers to look at the text, you might say what you hope readers find when they look. I'm wondering how .onion was "affected" in this text, Second, for some time, the CA/Browser Forum [SDO-CABF] had been issuing certificates for what they referred to as "internal names." Internal names are names allocated unilaterally for use in site-specific contexts. Issuing certificates for such names came to be considered problematic, since no formal process for testing the validity of such names existed. Consequently, CA/ Browser Forum decided to phase out the use of such names in certificates [SDO-CABF-INT], and set a deadline after which no new certificates for such names would be issued [SDO-CABF-DEADLINE]. Because the .onion name had been allocated unilaterally, it was affected by this policy. Is this saying that existing certificates for .onion could not be renewed? Or that the nice .onion people planned to get certificates, and now they couldn't? Or something else? I'm guessing The IETF's designation of .onion as a Special-Use Top-Level Domain Name was needed to facilitate the development of a certificate issuance process specific to .onion domain names [SDO-CABF-BALLOT144]. is describing how .onion was affected, but I don't know if that's what was meant by "was affected", or something else. This text Newcomers to the problem of resolving Domain Names may be under the mistaken impression that the DNS sprang, as in the Greek legend of Athena, directly from Paul Mockapetris' forehead. is the best thing I've seen reviewing documents since IETF 98. Thank you for that moment. If I'm tracking what I'm reading, The Sun Microsystems model of having private domains within a corporate site, while supporting the global Domain Name system for off-site, persisted even after the NIS protocol fell into disuse. Microsoft used to recommend that site administrators use a "private" TLD for internal use, and this practice was very much a part of the zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at the root of the widespread practice of simply picking an unused TLD and using it for experimental purposes, which persists even at the time of writing of this memo. it might be more accurate to say "simply picking an apparently-unused TLD". How often has Ralph started out as an innocent bystander, but been an accurate qualifier? :D
- [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-… Spencer Dawkins
- Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dn… Ted Lemon
- Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dn… Spencer Dawkins at IETF
- Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dn… Benoit Claise
- Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dn… Spencer Dawkins at IETF