Re: [DNSOP] moving forward on special use names

Ted Lemon <mellon@fugue.com> Sun, 18 September 2016 22:31 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ACD127078 for <dnsop@ietfa.amsl.com>; Sun, 18 Sep 2016 15:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziPOXlAjHFHH for <dnsop@ietfa.amsl.com>; Sun, 18 Sep 2016 15:31:47 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70942127077 for <dnsop@ietf.org>; Sun, 18 Sep 2016 15:31:47 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id h127so98633231lfh.0 for <dnsop@ietf.org>; Sun, 18 Sep 2016 15:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RRENkAEAWVnRtAUUWGJ175uCSepsKOvndypaRmRlE+M=; b=ih/Yet8goSKVNl/CvunPgi2A58aIsrK8YjCLxq4he5SFZPzQjigj5R7HcsIZyxEMjG 05kVPX2mRx1bpEZPRBMn8fPJakecNFvT2/7PnK6bA3QCPylc3YpSCBNEu5wJoVATSB0h AQFPM2UAD0ZKNkMOpf44LVO+FSqJjX8ylnC0eTzrlWAiNUzDFbYz+ETv+tbiFtx4chxo IsuDbKOEklMS8/p4M23oPr7k6DbzZclXg9Yy4xFQcLScUkSxDAebTdJLFadGfrwFut6u 74PjhtKt06ZrdQBlo+If99+NBcCJ4EtZX/myNT+Gcigc2mbWH63HtkrHBtXNl6CDf42H lsYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RRENkAEAWVnRtAUUWGJ175uCSepsKOvndypaRmRlE+M=; b=Tt1QC2bQRar0PVyYXGFaSjVpAeQqFpdRyl4kPiQ6iFwy3v2eRCSZVWxIhLRB3viYxs BRRVVZrTfOEK23qqn+iThLhsLP0UoK64kc8AIr6fCAagipPsSRkDfxg+PzTczJrT9I8M mUCAUfdjJyaKWenZQimkeMp0rXB39YUiGwo5cX2w6UpensocwLw3YQz62EKQG1eXwVBI bplCKNDdgStME+u5zm9GrnZVBM6Kxc/lTNMdJ+KFHNunwUl9fQ1wGNG0WS92mLD1/5if +qyT2SPJbXt1AaoEgK4+aDD7meNyDZNYB+cx75/JRWFOBmLaUfTKqpzNp+pdzuDjaUhf vDUA==
X-Gm-Message-State: AE9vXwM3wxk3KE/38lBAXh31yGEisyefKHV3Wv0Gc2oOnViv6Wf3TAGbLuIwet/OogaLoQUkHed3GcAAcHSNqg==
X-Received: by 10.25.133.8 with SMTP id h8mr8732972lfd.152.1474237905410; Sun, 18 Sep 2016 15:31:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.217.93 with HTTP; Sun, 18 Sep 2016 15:31:04 -0700 (PDT)
In-Reply-To: <20160918211028.78666.qmail@ary.lan>
References: <8f5eb481-c8e9-cdbe-a9d1-3390053c5c13@acm.org> <20160918211028.78666.qmail@ary.lan>
From: Ted Lemon <mellon@fugue.com>
Date: Sun, 18 Sep 2016 18:31:04 -0400
Message-ID: <CAPt1N1=xNaHpO-ZxusWK9_UBzOpKa0zk0y0h7iGvRS2P=Og-3g@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="001a113fba9eaaafcd053ccfc2dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7sucdvr7gzJp5PLGVlxZqXw0nmM>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] moving forward on special use names
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Sun, 18 Sep 2016 22:31:50 -0000

Avri, thanks for the markups--I will take care of the ones that are
actionable, and respond in a separate message, because I want to address
the question of merging explicitly, along with John's comment about brevity.

Why not merge the two documents?  This sounds reasonable on the surface,
but please understand how we got here.   The chairs asked the design team
to write a document.   Certain members of the design team wrote a document,
the initial version of which was published prior to the Yokohama IETF.   A
second version was published prior to Buenos Aires, and I decided that I
should really read it and send comments.

I read the document, wrote about four pages of comments, realized that my
comments were going to be longer than the document, and decided to talk to
people in the community before continuing.  I went out and talked to
various people in the community in Buenos Aires, including someone from
ICANN, members of the IAB, working group participants, the author of RFC
6761, members of the adpkja design team, and various others, and concluded,
based on those conversations, that we needed a new document.   Based on
that, I wrote a document that _does not reflect my personal opinion_, and
then bounced it off Ralph, one of the adpkja design team members, to see if
I'd done okay.   He had some suggestions, which were incorporated.

So the document as it stands is an attempt, which I believe was successful,
to enumerate a comprehensive set of problems relating to the problem 6761
attempted to address, as expressed by the various people I consulted.
These people are mentioned by name in the acknowledgments section.   I
didn't consult everybody, but I think most of the people whom I didn't
consult agree with what's in adpkja, which I read thoroughly, so I believe
I captured their positions as well.  Importantly, the people I consulted do
not all agree on what the scope of the problem is; that's why it was so
important to collect all of their input.

Both sets of authors have already incorporated into their respective
documents what they think is good about the other document.   Either
document, effectively, contains what that set of authors thinks a merge
should look like.   So suggesting a merge at this point doesn't make sense.
  What we really need to know is which document the working group thinks is
a better starting place.   If there's something missing from that document
that the working group wants to add, they can do so after it is adopted.

To John's point, short isn't actually good, because it's important to
document the context--this is a fairly important discussion, and it doesn't
make sense to lose the history of it.   But we tried to keep the actual
problem statement short and pithy; if you really think it's too long,
perhaps you could suggest shorter wordings that still capture the actual
problems.