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

Randy Bush <> Tue, 04 July 2017 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80E5912EB21; Tue, 4 Jul 2017 07:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g6yEsN2BvBSD; Tue, 4 Jul 2017 07:03:38 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A5A0129459; Tue, 4 Jul 2017 07:03:38 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.86_2) (envelope-from <>) id 1dSOQS-0000mg-Ib; Tue, 04 Jul 2017 14:03:36 +0000
Date: Tue, 04 Jul 2017 16:03:35 +0200
Message-ID: <>
From: Randy Bush <>
To: Ted Lemon <>
Cc: Warren Kumari <>,, IETF Rinse Repeat <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jul 2017 14:03:39 -0000

>> 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 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.

sorry.  maybe it would have helped if i had put UNREASONABLE DESIRE in
upper case.