Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

George Michaelson <> Tue, 04 February 2014 01:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F5741A02DE for <>; Mon, 3 Feb 2014 17:19:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z8UKanIiD3zO for <>; Mon, 3 Feb 2014 17:18:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8EF2C1A02D0 for <>; Mon, 3 Feb 2014 17:18:59 -0800 (PST)
Received: by with SMTP id ld10so7824568pab.38 for <>; Mon, 03 Feb 2014 17:18:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=37U7B3DDlN7MUm1p+DatlaQlvNbJ2SRkX1F7D0VEENI=; b=Oabv2cE3yCEw7YTCf5HF+qXKaoIYUI6zkiooQn4j2BSDbiWVO58e6LyytWz44gaP+d UxdwZpdMUPWKFH1okwsDO6ar7HPZ3xWZ1rGPITmmT3E3ybACQ8NxEqTqJlqxY5KxNQC9 ursHpA7V6kjprrPTCh1WVLNrOJIxljP2rXs3+58c9WZkQ/WSMbgF5ePeNSFpO4CVipP7 yGzpGYbNxwgPXE4z77BTeKw6CV7htc3cUbmVIhHXYW8xEyViKlBQAzbWsMLr0M9a2vvU aGd0/Y74bNzZSaX0esX8upNw4jqFl+Nb8FjDbC6lJDZ5P/+6sXUPKwH1jk8fvP6J7T8X BP7Q==
X-Gm-Message-State: ALoCoQkMYxiZRyJwVMJgnF3NHeKWpZ00aR9muIlksCMP9nM1VlI6X2Wqutn68/NHb8K/9Jxi4ri7
MIME-Version: 1.0
X-Received: by with SMTP id td3mr40352443pbc.137.1391476739450; Mon, 03 Feb 2014 17:18:59 -0800 (PST)
Received: by with HTTP; Mon, 3 Feb 2014 17:18:59 -0800 (PST)
X-Originating-IP: [2001:dc0:a000:4:302e:dba0:2280:4927]
In-Reply-To: <>
References: <20140129055438.2402.qmail@joyce.lan> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 4 Feb 2014 11:18:59 +1000
Message-ID: <>
From: George Michaelson <>
To: Ted Lemon <>
Content-Type: multipart/alternative; boundary=047d7b33d592c4c3a204f18a6cd4
Cc: dnsop WG <>
Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
X-Mailman-Version: 2.1.15
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 Feb 2014 01:19:08 -0000

ok. I see where you are. I can be there, somewhat. Thats not a bad position

So my sense of this is "you were advised not to do this, and you didn't
respect the process" for some value of "you"

What I don't like about that is a schoolmarm/punitive voice. But it has the
qualities. Tragedies of the commons don't just take one form, and having
s/w develop a dependency on name/locator properties with high visibility,
without considering the commons, is (in my opinion) a tragedy.

I'm not inherently arguing for ICANN process, or even the DNS. I think a
mature sense of the locator/id separation qualities of any endeavour, and
the arguments around naming, lead you to caution in seizing names in any

IETF is constantly advised by w3c people (mark nottingham?) to be mindful
of the URI/URL concept, and not to over-egg stipulations on what is
meaningful in that space. And I think by and large, thats right.

So is what the TOR people did usurping .onion respectful of process? What
do you do, when process isn't respected?


On Tue, Feb 4, 2014 at 11:08 AM, Ted Lemon <> wrote:

> On Feb 3, 2014, at 6:27 PM, George Michaelson <> wrote:
> > .onion is an eminently tractable problem. Arguing otherwise is to argue
> the current .onion codebase dependency cannot move, therefore any future
> CVE against TOR cannot be fixed, therefore further code development on TOR
> is fruitless, therefore lets all stop coding. Breathing even.\
> What I'm saying is that it's an obnoxious thing to do, and there's no good
> reason to do it.   We really ought to have a good reason to demand that an
> organization over which we exert no control at all make a significant and
> incompatible change to their deployed code purely on the basis that some of
> us don't like what they did.   We need a better reason than that, and thus
> far none has been stated.