Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

Ted Lemon <mellon@fugue.com> Tue, 04 July 2017 14:01 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 2FE6C129459 for <dnsop@ietfa.amsl.com>; Tue, 4 Jul 2017 07:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 N5DPhKS-XFRA for <dnsop@ietfa.amsl.com>; Tue, 4 Jul 2017 07:01:25 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 F0A8913155F for <dnsop@ietf.org>; Tue, 4 Jul 2017 07:01:24 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id r30so165923782qtc.0 for <dnsop@ietf.org>; Tue, 04 Jul 2017 07:01:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qqDIJrAAbRttRwWVLjKPD1QDEqnQh818CMDMsLr+Gfk=; b=xd21q5juZyMUWYfs3J+eyvvOo2Y0WfZG4Q4ujCC2voJPJ46ir7g8IOjh6AfTRcqTQh hpdmR44kbXBpCMHckDU6NDTEoU47u9tr2ILzbedSuY+/eMpWa1GPCofdFoph9w353x+5 7mBn1LJZbz+Il5XyLEreTCyY1zpGOkUsQpeZ6LQOCAIyCSuiDe9GDoaxdW+VHutBZQBD 60pIovL58crfICwToujpmnOnAfLm5n4npuK4yfMtNuiG7h8rDZEXSGoZ3UBrjwq1wTMa ziL3lvCDGBCt2DbG6lCdh+wqcrCuy2BthPW7/2RBq2cgHdxr8FpyR1TtL+F/QLtSkg7z oOZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qqDIJrAAbRttRwWVLjKPD1QDEqnQh818CMDMsLr+Gfk=; b=aGK+hF1XZBKvUeueJwj5/1SQSjC6oE1fisxfIe3UfI5gxYAKJule5a6DEd/vykJiF+ yGr3K/V9uTIO8u9X6NxE4MZznrPvHO/dNY9hH9YbFvXmGmOKB+RQRQo1bRXIfDA8puCp 5QxbvSA3RGaWvJfhF4DLebRKBGEr7+kR1Juj63qdMgXWZynUx/bHBr27kACoJJ5TD+tv LATjggs2yU/scY+g12Ly8MjM9GhXqwMPbOoz0rvTBNM+eXe0y4+QNrFKogBrtgvFRoXK ygOdmk5yPkBjeYnThB+85zwnvYypodknRBArLvG8uzGUeLa2jQ3M//SypLHUmIY/0doQ D8HQ==
X-Gm-Message-State: AKS2vOwzI6mSQ3wCcmuiHSbn5znVEEx1GAa+Br1b53H+KzJCRHnai10K 1eQB2qwc7miBuIqQ
X-Received: by 10.200.53.11 with SMTP id y11mr46176003qtb.98.1499176883861; Tue, 04 Jul 2017 07:01:23 -0700 (PDT)
Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id a6sm14737541qtc.54.2017.07.04.07.01.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 07:01:23 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Ted Lemon <mellon@fugue.com>
X-Mailer: iPad Mail (15A5304i)
In-Reply-To: <m2podgxq97.wl-randy@psg.com>
Date: Tue, 04 Jul 2017 10:01:21 -0400
Cc: Warren Kumari <warren@kumari.net>, dnsop@ietf.org, IETF Rinse Repeat <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <m2podgxq97.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QzDWJKEAeYF9R5vmLQjvbY3PmYk>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 04 Jul 2017 14:01:27 -0000

On Jul 4, 2017, at 9:53 AM, Randy Bush <randy@psg.com> wrote:
> i would offer to put my keyboard where my mouth is.  but i fear that, at
> the bottom, i would have the unreasonable desire for dns classes to
> support these kinds of things.  i.e. i don't think we have a clean fix.
> but it would be nice to document the good with the bad.

That sounds like a solution, not a motivation. That is, you care about the problem hypothetically, and have a hypothetical solution. In practice when we’ve talked about using dns classes to solve problems that have motivated rfc6761 allocations, it hasn’t really helped, because the infrastructure required to use them this way is not present, and this isn’t how they were originally intended to be used.

For example, is ICANN.org with a different class not a subdomain of the .org TLD? Would ICANN not object to us designating it for use by someone else?  I suspect yes, and I wouldn’t blame them.