Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

Warren Kumari <warren@kumari.net> Tue, 27 September 2016 20:12 UTC

Return-Path: <warren@kumari.net>
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 D01C412B39E for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 13:12:08 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 C5kFgLQPKdo0 for <dnsop@ietfa.amsl.com>; Tue, 27 Sep 2016 13:12:06 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 C097012B3F2 for <dnsop@ietf.org>; Tue, 27 Sep 2016 13:12:06 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id t7so28237750qkh.2 for <dnsop@ietf.org>; Tue, 27 Sep 2016 13:12:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YCw7A+nsbgqMCBdXGw9eeA0FUwiO9nX7oxR+JiT4XLg=; b=vli3bJyaBxaCJR6M2ceOhUPbD1ylX07qMotEBQrFMuAXSnKfqFu1DYVVzf7pPtNiU+ 5UR3wbkLm5MFy+SqmSvMUgBghrLPd1OkoktRQ6j18mb5dN6Fn/g4UB2TL+ak0UufWwte KCz6W/kL7Y6TSryqkKnZtjdjX4ThywMUlBvPoN3ZjV/TevyS2yLY82K8/tY1uryQ/KNh K2Xmb/J2U3VAXIaYezilTODPWDbpipfVnTMcpzfoSZ5mUxqMypi+hg0OeaZMuGHG9ccf q5+dZxWAnk13D2J0YMRaTWH7x8SXK8K3Y1eDl/2awMMVSXuiz+pOC6NrNrHphrSpinye Ly8g==
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:content-transfer-encoding; bh=YCw7A+nsbgqMCBdXGw9eeA0FUwiO9nX7oxR+JiT4XLg=; b=YbmWMAj5bK5VkoiBupyjfT+AHw2kDpn27I1XUs6qD9BPSY6HKKaH7VYtb2x57ovppl +9yqK0rT/CYLFZTBZCNzv6yJIzt296FCFc+EwiSMYIACGcFNGmW8YfKTfwCdYeNS8/CB hxxwdnotiot6EBwDgIRDe8c6POYIuYfqXegxacn93aN+Aw/Oy6TUU9gfrnizeb5wdxIM Y6tOYAwiMKkTMzL9gR+4QIidUCxYJ0WZ/n09seznJS/AHYVdN8fFcPXgA8bBBJpZFrr8 C4QZq/E9hxXBHdORgY7NUE5am8QJfWNZzvmqj5d9vVR9lQDNLWFtogkKyU2R+SDyvBDK GNYw==
X-Gm-Message-State: AA6/9RnwjokLEoaxpiTJ0715TZIFkiJ7+/Fo2w9K6fPPfRF1/VTkiStKsUXMmreLGUuoR30LTOo7mwe4JWv34+wb
X-Received: by 10.55.151.3 with SMTP id z3mr28069416qkd.321.1475007125276; Tue, 27 Sep 2016 13:12:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Tue, 27 Sep 2016 13:11:34 -0700 (PDT)
In-Reply-To: <8F7C438C-37EA-4C99-96D9-F4B59AFF40B7@rfc1035.com>
References: <147368142586.14471.16897934069436083953.idtracker@ietfa.amsl.com> <6ce7ea83-5ccc-aeda-d1e4-f5e5d1ccbf53@gnu.org> <CAHw9_iKtmVh8xvwVydWUs-g9t_JiKAF7Frdx_iieSEOvQFHJ1w@mail.gmail.com> <f33a6d06-2c17-04fd-d6a7-b73274705c37@gnu.org> <74610049-16f1-3210-7f79-8d38d596d641@bellis.me.uk> <05DF06B8-AB92-4DD9-B868-1D420FA33692@rfc1035.com> <CAHw9_iLGhDXsfPGNb0igLAdMHBbR+giFw067oEReD7Ww84Je-Q@mail.gmail.com> <8F7C438C-37EA-4C99-96D9-F4B59AFF40B7@rfc1035.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 27 Sep 2016 16:11:34 -0400
Message-ID: <CAHw9_i+ZVO6KxEOQcTi7d=_pJEhGLJ-9EeUmtZivN6ADOz=CdA@mail.gmail.com>
To: Jim Reid <jim@rfc1035.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fl2u_9w3RIZJvzH1Y6_JpnYDxKg>
Cc: IETF dnsop WG <dnsop@ietf.org>, Moronic MUA Header Mangling <draft-grothoff-iesg-special-use-p2p-names@tools.ietf.org>, Ray Bellis <ray@bellis.me.uk>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt
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: Tue, 27 Sep 2016 20:12:09 -0000

On Tue, Sep 27, 2016 at 2:38 PM, Jim Reid <jim@rfc1035.com> wrote:
>
>> On 27 Sep 2016, at 18:52, Warren Kumari <warren@kumari.net> wrote:
>>
>>> Meh. I wish the WG could stop the shed-painting on a frankly pointless detail and concentrate its efforts on producing a viable problem statement.
>>
>> .... we have two of them --
>
> Indeed Warren. That’s one too many.

Yup. Some would say that that is two too many :-). I think that the
CfA ended last Friday, so hopefully there will only be one RSN.


>
> They both come up short as problem statements IMO.

Yup. They are not perfect - but hopefully whichever is selected will
be good enough starting point.

>  I’m struggling to find words to succinctly describe what problem the WG is expected to solve - sorry about that -- since it appears to be a layer 9+ matter.
> Both drafts seem to be concerned with treating (some of?) the symptoms rather than the root cause(s). Excuse the pun.

Yup, much of this *is* policy / layer-9 issues -- unfortunately this
doesn't make it not a problem, it just makes it all more annoying (as
someone who spends much of his time doing ICANN stuff, I can attest to
this :-))

We listed the symptoms, but I think also the root issue -- IMO the
root of the root issue is that there is a *single* namespace and
multiple organizations can reserve / allocate from it, or simply use
strings without allocation if the process is too onerous. Oh, and
because one use became dominant, it is the (assumed) default, and
there is no clear switch. This is a wild simplification, and leaves
out much subtlety, but IMO boils the issue down to the bones...

>
>> ALT doesn't solve any of the major issues, but it *does* create a safe
>> place for those people who want to experiment and build alternate
>> resolution systems -- and takes some of the pressure off while we
>> discuss solutions....
>
> True. But that seems to be putting the cart before the horse. Where’s the demand from experimenters and why do they need a dedicated TLD for their alterate resolution systems? That’s a rhetorical question BTW. Answering it may well distract the WG from its quest for that one true problem statement to rule them all. So please don’t do that. :-)
>
> FWIW I’m sceptical about creating .alt as a playpen for experiments since it might undermine efforts to answer the question ICANN asked us, whatever that question might be, or be the start of a slippery slope.

Um, which question ICANN asked us?

>Maybe a TLD is needed for experiments. Maybe not. However that’s something to discuss once we’ve figured out what has to be done about special* TLDs in general. *For some as-yet-unclear definition of special.
>
> I think the WG should step back from both drafts, take a deep breath and agree a problem statement. Once that’s done, we’ll be in a better place to decide what to do with both drafts.
>
> Easier said than done I know...

Well, the CfA has finally concluded, so now we are just waiting on a decision.

W




-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf