Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

Ted Lemon <mellon@fugue.com> Wed, 08 February 2017 14:59 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 54729129B6A for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 06:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ywAqBSUoQGqE for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 06:59:30 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 377EC129570 for <dnsop@ietf.org>; Wed, 8 Feb 2017 06:59:30 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id k15so167633742qtg.3 for <dnsop@ietf.org>; Wed, 08 Feb 2017 06:59:30 -0800 (PST)
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=HaUNS5miawaht9K+J3VNu+16nLj0kpVGZM54sgWu7XY=; b=2CZa9umrUldCK4w33RCXusxs3TW14NIUUTOCHUqRamSZ74jUGWs95lpVd1yPHLC+pb /+vBvn7MEFt/IpQQvYjknaM6qRbqRuEK9Bv6GXHG+p4HqKyoI/S01otuX9YZcRBos9ed H3esMFg6Dhn86OF0TQW6lk8ag4RQ2nIrJxBp/IlAtiu4ZH9Lwkl+S8GN5XrtjAfEQKn+ yaZCuX9n0Lqejyhprmoakg6WFVSSzdYLIqt0Fs7FWkcTFvBWgA+qcpXi7aka4uFDClaO J5t4rSvQo1JgpUhsxca5VK5XJ7hBORqg6HKfGZ50hE1bpRXWashone7VMCdoK97mlOWs A+PA==
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=HaUNS5miawaht9K+J3VNu+16nLj0kpVGZM54sgWu7XY=; b=Ifp//AZk5SNS42uj5rUS4VKHOLSX//xxLehOv3fs8+cOAwpvz9hPOMo90aOcNeNpde vkND419yTAXJpCubcLN5cCQbVnXaamqCrKOO6mrTTGBg127fE8tHE6fA1sAmOrf+08sz Z5Pe7IwrRe9SA5OKra7jw4qEkfjWD85W3LK5tIZmy8aEcV2y+q0lmg8Q6cW7GJMvmW0K 6AkKlPaUBr82SB4BbsWrcelHmvLnrLi6hKFTMPJYOefylE/sHA7QW/kERoSSROnoBeut +ieSq9mpF5lNJAD1eEkTVjS0QuXqM6zmkciHIGIuH6yA5KexIFwE1McnS5StYgkqSgoj qMJw==
X-Gm-Message-State: AMke39mC0DabaoX0tLWxeJHj3pNMW5vbYqRkns4tcwezYIiPdBqswqF2Ln3iwvwt4aMDFA==
X-Received: by 10.237.42.164 with SMTP id t33mr21537975qtd.27.1486565969274; Wed, 08 Feb 2017 06:59:29 -0800 (PST)
Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u5sm6381665qkd.46.2017.02.08.06.59.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 06:59:28 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <20170208091536.vqwftrhpole33opl@nic.fr>
Date: Wed, 08 Feb 2017 09:59:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5399746-711E-49E6-ABE3-3B18061DB097@fugue.com>
References: <6545B2F1-15C6-41F6-ABF0-2D3E6983F4AB@gmail.com> <20170208091536.vqwftrhpole33opl@nic.fr>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TQtYD586Bb4BRWimuEIXNam3bqc>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps
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: Wed, 08 Feb 2017 14:59:36 -0000

I think you have read the draft as if it were about "the problems with special-use names."   This is not the intended reading.   It is intended to be read as "the set of problems that motivated RFC 6761, plus the set of problems that would motivate an update to RFC 6761."

Solutions are out of scope.   It would be helpful if you could read the document again assuming the motivation I just described, and tell me where you think it deviates from that motivation: that is, whether you just mis-read it, and now that I point it out, it's obvious, or whether you think the document doesn't actually do what it sets out to do.

It would be ideal if you could avoid using phrases like "the only problem with RFC 6761."   What you mean, of course, is "the only problem I see with RFC 6761."   Other people see other problems; the point of the document is to list all of those problems, not for everybody to agree that those problems need to be solved.

> On Feb 8, 2017, at 4:15 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
> On Thu, Feb 02, 2017 at 06:04:05PM -0500,
> Suzanne Woolf <suzworldwide@gmail.com> wrote 
> a message of 82 lines which said:
> 
>> This message opens a Working Group Last Call for:
>> 
>> "Special-Use Names Problem Statement"
> 
> I've read draft-ietf-dnsop-sutld-ps-02
> 
> I'm not convinced that there really is a "problem" with special-use
> domain names and I would like to see some sort of applicability
> statement saying (I send text...) "The issues listed here should not
> be interpreted as indicating that special-use domain names should not
> be reserved and used. While we may see one day a RFC 6761bis, in the
> mean time, the process it describes should continue to be open and
> available."
> 
> Biggest problem with the draft: it fails to mention the only real
> technical problem with RFC 6761, the lack of a formal language for the
> registry, thus preventing the programmers of resolving software to
> compile automatically the code for the various cases.
> 
> I send text: after the paragraph "When a special-use Domain Name is
> added to the special-use Domain Names registry, not all software that
> processes such names will understand the special use of that name.", add:
> 
>  o This problem is made more difficult by the fact that there is no
>  formal language for the registry. The list of SUDN with their
>  specific requirments is not machine-readable. As a result, software
>  developers who write resolving code have to translate the registry
>  by hand into their code, a process which is painful, brittle, and
>  unlikely to be repeated often (thus making software obsolete with
>  respect to the registry).
> 
> Now, the details:
> 
>> Both ICANN and the IETF have the authority and formal processes to
>> assign names from the pool of unused names, but no formal
>> coordination process exists.
> 
> As I said several times, this is not true
> <https://www.ietf.org/liaison/managers.html> Was this mechanism used
> once for special-use domain names? What was the result?
> 
>> Organizations do in fact sometimes commandeer subsets of the
>> namespace. Reasons a third party might do this include:
> 
> There are others:
> 
> * Intended use is covered by gTLD process, don't recognize ICANN's
> right to block these TLD
> 
> * Intended use is covered by some IETF process, but the process is too
> long, too bureaucratice and too incertain [before you jump on this
> one, remember IETF never replied to requests to reserve names like
> .bit or .zkey]
> 
>> the fact of its unilateral use by the TOR project without following
>> the RFC 6761 process
> 
> This is ridiculous, .onion was used since 2004
> <https://www.usenix.org/legacy/events/sec04/tech/dingledine.html> and
> RFC 6761 was published in 2013.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop