Re: [DNSOP] moving forward on toxic and/or special use names

"John R Levine" <johnl@taugh.com> Sat, 17 September 2016 15:09 UTC

Return-Path: <johnl@taugh.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 1B28412B23D for <dnsop@ietfa.amsl.com>; Sat, 17 Sep 2016 08:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FnMFKqb8; dkim=pass (1536-bit key) header.d=taugh.com header.b=jSWmd44T
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 UGu2eTP2egeK for <dnsop@ietfa.amsl.com>; Sat, 17 Sep 2016 08:09:53 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0934112B09C for <dnsop@ietf.org>; Sat, 17 Sep 2016 08:09:52 -0700 (PDT)
Received: (qmail 39235 invoked from network); 17 Sep 2016 15:09:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9942.57dd5cbe.k1609; bh=w6ilaVXS+3eyG+amNR5XcSxu/mPR5sh48qxLL0xpjuE=; b=FnMFKqb8Rmgj6FtZ8p35/9m2MmUyGXG3a4k9NMCyJxX4XR756hXE2HJymZ1Ur3rjq3fWYUvqBE8wAM1oVbUKOACv31MWvrS7Mt8MchzaUVBeFGOiiZBAkqnHmZqrTpmjajoZp+UNGvxNdiQv6A10AcROtwjr302C58+U9JjLTv3U9VJxKQeu7Ux46Eqx6YahJktPoP+CQ6nlIZif4boekG/Z6jPPK9PL7Lo70xgPYp5qkHFIeGEnYns09tubBV1C
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9942.57dd5cbe.k1609; bh=w6ilaVXS+3eyG+amNR5XcSxu/mPR5sh48qxLL0xpjuE=; b=jSWmd44TsibNqOsa4To9w+U0DwUmWlYz9cm/lVGGe0WGV+YXg3tpbG7oQJR1HBbbbW0EoobhnjyH/yh0zxB+3CKfSeLO2Bm3Q7/05bbUNtK9r4ITdrF0mOoN1Z7rJg/haPEIMBFbM//tJ8SPtQcr0NAZ9zhdJyVvS1P+/v06FmL8++S1e6tg1nSi/X/jHWNs+f98ua6hTxh1FrsG6NOqN1eW7HIM2ZOIqNu+EguERta53jl5SPGFHBh4od5K6Rkt
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 17 Sep 2016 15:09:50 -0000
Date: 17 Sep 2016 11:09:51 -0400
Message-ID: <alpine.OSX.2.11.1609171106280.97287@ary.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Alain Durand" <alain.durand@icann.org>
In-Reply-To: <789E92DE-7B0A-477C-BC37-C56D380B5AF3@icann.org>
References: <20160917001036.71292.qmail@ary.lan> <789E92DE-7B0A-477C-BC37-C56D380B5AF3@icann.org>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1645344095-1474124991=:97287"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/O1mGErsfYGfbQri_X4_95wbRY7Q>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] moving forward on toxic and/or 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: Sat, 17 Sep 2016 15:09:55 -0000

> What would really help here would be standardize a way to measure toxicity. We could then track a specific string toxicity over time, and maybe then define a threshold where it is OK or not OK to delegate that particular string.

Yes, and that gets back to the question of whose job that is.  As you 
know, ICANN has done a lot of work on name collisions.  Some of it is 
pretty good like this report by JAS:

https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf

Some of it, like a wildcard that returns 127.0.53.53 for a few months, is 
clever but strikes me as wishful thinking.

The IETF has technical expertise, but no way to do studies.

R's,
John



>
> I would personally agree with your assessment that maintaining this list in 6761 is problematic, for the reason mentioned in section 3.f of darft-adpkja:
>
> "f.  [RFC6761] does not have provision for subsequent management of
>       the registry, such as updates, deletions of entries, etc…”
>
>
> Alain.
>
>
>> On Sep 16, 2016, at 8:10 PM, John Levine <johnl@taugh.com> wrote:
>>
>> This is the toxic waste bit.  The names don't make sense in the 6761
>> special use registry, since they're not being used in any way that is
>> or can be standardized, but they also aren't suitable for delegation
>> due to widespread de facto use.  I also expect that if we redid last
>> year's debate in anything like the same way, we'd have the same
>> result, one or two highly motivated people who work for TLD applicants
>> would sabotage it.
>>
>> As I hardly need tell you, it is utterly unclear whether it makes more
>> sense to have the IETF reserve them or, to switch hats and encourage
>> ICANN to put them on a list of names that aren't in use but can't be
>> delegated as SAC045 suggests.
>>
>> One reason that the latter makes slightly more sense is that it's
>> likely that some of those names will eventually become less polluted,
>> so the list needs to be reconsidered every once in a while (years.)
>> For example, I gather that it's been a decade since Belkin stopped
>> making routers that leak .belkin traffic, and at some point most of
>> them will be gone.
>
>

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly