Re: [DNSOP] Alternative Special-Use TLD problem statement draft

Philip Homburg <pch-dnsop@u-1.phicoh.com> Wed, 06 April 2016 11:17 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.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 9A52B12D711 for <dnsop@ietfa.amsl.com>; Wed, 6 Apr 2016 04:17:07 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 mT73HIY94XWL for <dnsop@ietfa.amsl.com>; Wed, 6 Apr 2016 04:17:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id ED41E12D0C9 for <dnsop@ietf.org>; Wed, 6 Apr 2016 04:17:04 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1anlSH-0000IqC; Wed, 6 Apr 2016 13:17:01 +0200
Message-Id: <m1anlSH-0000IqC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
In-reply-to: Your message of "Tue, 5 Apr 2016 19:35:19 +0000 ." <8D23D4052ABE7A4490E77B1A012B630797A44227@mbx-03.WIN.NOMINUM.COM>
Date: Wed, 06 Apr 2016 13:17:00 +0200
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Uevz95lNTM6Zr_fWESRT-rNPHcA>
Cc: Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
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, 06 Apr 2016 11:17:07 -0000

>I've included the submission announcement below.   I realize that this is a woef
>ully late submission for discussion at IETF 95, since I mostly wrote it yesterda
>y, _at_ IETF 95.   However, I think it may serve as a better starting point for 
>the discussion than the current problem statement draft, so if you have time to 
>read it, I would genuinely appreciate it if you could give it a look.

One thing I sort of missed in your draft is a clear distinction between
standards track protocols and other protocols.

I think that for standards track protocols, the normal IETF consensus process
is likely to produce something reasonable. Nothing is perfect, but the 
examples you gave (.local and .ipv4only.arpa are both quite reasonable
uses for the name space). 

If the IETF feels a need for more non-DNS naming protocols, then probably
there will be a discussion in the relevant working group on how to be co-exist
with DNS.

The problem starts with non-standards track protocols. For just about all
protocol parameters (from IP versions to port numbers to MIME types, whatever)
the IETF is the only organization that can create a registry.

Names (and also addresses and ASNs) are different. There exist organizations
outside the IETF that deal with those.

In fact, there is quite a bit of history already in some programming
languages (for example java) to just register a DNS domain to get a private
part of the global name space.

So anybody who wants to play with an experimental naming service can just
register my-naming-service.net. And use that string in any name switch code.
If so desired, additional DNS types can be registered to mark a delegation to
the new protocol.

This does not require any involvement of the IETF in the registration of the
name. Of course, having to maintain a DNS registration is way less convenient
than having a entry in some special registry. But why should the IETF be
concerned with that.