Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 19 July 2011 19:46 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDECF21F8784 for <apps-discuss@ietfa.amsl.com>; Tue, 19 Jul 2011 12:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.639
X-Spam-Level:
X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwZlXvG4a+JL for <apps-discuss@ietfa.amsl.com>; Tue, 19 Jul 2011 12:46:42 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C3A6521F8786 for <apps-discuss@ietf.org>; Tue, 19 Jul 2011 12:46:41 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6JJkMup038651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jul 2011 12:46:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <2E21B740FDAB4C150B4BB2FE@PST.JCK.COM>
Date: Tue, 19 Jul 2011 12:46:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2A7DAF9-83D7-46C4-8F24-AACF7F5C62DF@vpnc.org>
References: <B464B2C6607E04FD0572AA74@192.168.1.128> <CANp6Ttw4MaAJy2VRvZ8929oBju9jL3b69PkSyFLi-SC4YaNTnw@mail.gmail.com> <5AC1318B-A219-4056-BD14-C90BEE85669E@frobbit.se> <8159C20D-BF2B-42CB-9529-C870A2AD1572@vpnc.org> <2E21B740FDAB4C150B4BB2FE@PST.JCK.COM>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] CONTEXTJ in TLD DNS-Labels (draft-liman-tld-names-05)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2011 19:46:43 -0000

On Jul 19, 2011, at 10:53 AM, John C Klensin wrote:

> --On Tuesday, July 19, 2011 07:55 -0700 Paul Hoffman
> <paul.hoffman@vpnc.org> wrote:
>> I am going to push back here, hard. The draft is about names
>> used in exactly one zone, and that zone has exactly one
>> administrator. Your statement about "_any_ context" is
>> inappropriate for this draft.
> 
> That zone is also the root.   While asking narrow questions
> about the "can you put something in and get it back out"
> performance of the DNS produces a different answer, any
> considerations of actually being able to use the DNS to navigate
> the Internet do make the root particularly important and
> different.  

True, and completely irrelevant to *this* discussion.  We are discussing restricting some characters from an encoded form. How does that affect "actually being able to use the DNS"?

> In particular, while one can imagine blacklisting an
> entire TLD because of bad policies or bad behavior, the only way
> to do that to the root is to find, organize, or configure an
> alternate root.

And, as you say below, you truly don't like the way ICANN makes and enforces policies. The rest of live with them, usually with less complaining.

> 
>> As a zone administrator considers what it can safely put in
>> its zone, it follows policies. Most zone administrators in the
>> world have no policies whatsoever, and thus the IETF should
>> make it less likely that they will do something dangerous.
>> However, that is not a concern for this zone administrator.
>> They have policies up the wazoo and literally hundreds
>> (probably thousands) of people helping make those policies and
>> being sure they are implemented.
> 
> Hmm.  I don't know if you have been following the activities of
> that particular zone administrator, but, its policies are
> rarely, if ever, enforced.  

Stating a policy and not enforcing it is making another policy. Again, it is irrelevant to this discussion.

> In particular, top-level domains
> (root entries) that have been created with restrictions on use
> who have then decided to eliminate those restrictions have, as
> far as I know without exception, been permitted to make those
> changes.   The problem is especially severe with any TLD that
> can claim linkage to a government because claims are made of
> national sovereignty and the impossibility of applying or
> enforcing any policy the zone administration doesn't like.

That can't be your whole list of things that have nothing to do with this draft that you dislike about ICANN. Please go on. :-(

>> So, for this draft, restrictions that are being made because
>> that one administrator might make an unnoticed mistake are
>> harmful. It is fine to give advice about security and
>> stability; in fact, Patrik is already doing this in his role
>> on SSAC. This draft, however, is exactly the wrong place to
>> make statements that apply to any zone other than the one in
>> the title.
> 
> Just to keep this in context, note that these restrictions are
> not new or unique to the current zone adminstrator.  They are
> relaxations of restrictions that go back well over 20 years.

Hogwash. Those restrictions have *never* been part of the DNS protocol. Nothing in those two restrictions affect the DNS at all, only the way that some people interpret some DNS strings in applications. The design of both IDNA2003 and IDNA2008 insulate the DNS from this.

To be more blunt, the restrictions in this draft imply that the protocol of which you are co-author sucks badly: you either left out of the protocol "these characters are unsafe" or you left out "there are special rules that apply to the root zone".

I don't believe either is true. The protocol we all worked on is just fine. You, and we, didn't leave anything out. Trying to jam this into the DNS after the fact is just wrong. It's fine if ICANN wants to make its own policy on this; it is wrong for the IETF to pretend that this is our policy that we forgot to put in IDNA2008.

--Paul Hoffman