[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