Re: [DNSOP] new DNS classes

william manning <chinese.apricot@gmail.com> Fri, 07 July 2017 18:27 UTC

Return-Path: <chinese.apricot@gmail.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 9387C13162F; Fri, 7 Jul 2017 11:27:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BKDZkK-TBt8T; Fri, 7 Jul 2017 11:27:46 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 941BD1275AB; Fri, 7 Jul 2017 11:27:46 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id m84so1432175ita.0; Fri, 07 Jul 2017 11:27:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/RfGFmSWwIV6Va3Gv2F7w4L60uerI1klCPmqZbtIFtg=; b=AM1/OLJLfzTWwXVCLXMisolAjG8r+iEKJXWAsCuvcit5zNBACc2JfU50PRNvScnCtw ab/I0yznMVUkKysULeLUUGv715E3iodz4jM+Pnye36XZ3WbO2P/UyudPQzVD2FtxMKBE 6h2erVh90k+nxWahjYiWpJ5Np3bwdz45lLl3KtU7CN/8AlccdO164vjfzhKZZ9nljDLD HvvAAqpbDJxOlAFdUIh+p6fCA7J22m0Ga2cdtrRU8ce7YAJybAMIwmqalgA8J6Trpqgz ePYTFdKmqScMwT90sr8X95akprtyvq41zkkUW228UBm2wxUeBtAmEALbebWVY63t/y+4 9gag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/RfGFmSWwIV6Va3Gv2F7w4L60uerI1klCPmqZbtIFtg=; b=k2JWHSQt9HlMJO4NL4jLcITUbmXjNQYnPaBfVnCuinBw1WV+bfyBgtMCpsmRGOzx6U B4cc549PuZAaslF8brPiTOKrgZZ0IOpOuOC3HlBULA1p+C+lxiJ3BzDNF1TK0DZKIJcY H0huRbuerwAJtYbMWT1hqZ6oi8C5ZPwLoIdNywxAkRDonq2pWCWYSJwiCXVBLfO01+r6 7h07Ayb+9xP2XqX1r6IFjsmuW9bo/W5Q90m6+MR4thYih9pQm9Zk2UTxBaHiFYeXWcyy Wfhlps8DRmEzzKmJE/gMZaHwCyuD1SWawVpce4bfQt6rfWDL0ypyyMkn5gcnfTxpSExl v8NA==
X-Gm-Message-State: AIVw113H/fA8qQrdcYdIzPd8E+DfrHhFMbbgh1RrBsrL8FIbt8oss8gj F3379SLy8wrtIGlVa9zPgWMkw4Emeg==
X-Received: by 10.36.248.4 with SMTP id a4mr249978ith.69.1499452065951; Fri, 07 Jul 2017 11:27:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.18.170 with HTTP; Fri, 7 Jul 2017 11:27:45 -0700 (PDT)
In-Reply-To: <20170707165513.GG3393@localhost>
References: <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <E739C1CB-E60E-4B4B-99CF-1E6C68CB6926@rfc1035.com> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <m2mv8jw9qq.wl-randy@psg.com> <33235E8D-147D-4178-BC45-DFC1E1C27B99@davecake.net> <20170707165513.GG3393@localhost>
From: william manning <chinese.apricot@gmail.com>
Date: Fri, 7 Jul 2017 11:27:45 -0700
Message-ID: <CACfw2hi8Grd+jeyXTR-Hfcx+Axeh8YjJzwO=QM3MndhhwvYZJw@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: David Cake <dave@davecake.net>, Randy Bush <randy@psg.com>, dnsop <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, IETF Rinse Repeat <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b1cb4bfb7fa0553be63aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4NLK_iMWZXxcVmvJlXWCl2BXxac>
Subject: Re: [DNSOP] new DNS classes
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Jul 2017 18:27:48 -0000

You need a better imagination then.   mDNS is a crippled DNS implementation
that was hobbled on purpose.   HS was/is an entirely different addressing
scheme that emerged from project Athena @ MIT.  To the extent that when all
you have been given is the IN class and it's associated rooted hierarchy,
you first,second,&third inclination is to treat EVERYTHING as being easily
integrated into that model.  And the ietf is going to go right along with
you.   After all, when all you have is a hammer, everything looks like a
nail.

On Saturday, July 8, 2017, Nico Williams <nico@cryptonector.com>; wrote:

> On Fri, Jul 07, 2017 at 03:32:21PM +0200, David Cake wrote:
> > > On 5 Jul 2017, at 10:47 am, Randy Bush <randy@psg.com <javascript:;>>
> wrote:
> > >
> > > i think avoiding icann is a red herring.  if the draft in question had
> > > done a decent job of exploring the taxa of needs for name resolution
> > > outside of the 'normal' topology, we would have the start of a base on
> > > which to discuss this.
> >
> > If you have a single centralised root for your new class, you will
> > probably either recreate the problems of ICANN, or create one or more
> > of the problems that ICANN has very consciously tried to avoid.  If
> > you have a system of name resolution that avoids the need for a
> > centralised root, you probably don’t need a new class to implement it.
> > The few marginal cases that need to interact with the one root but not
> > be ICANN controlled are why we have the RFC 6761 process.
> >
> > I agree a taxa of needs that do not fit within those three cases would
> > have been useful.
>
> Well, there's a) the rooted hierarchy of the public DNS (IN class),
> b) mDNS (which isn't really DNS, just a local discovery mechanism based
> on the DNS protocol), c) the HS class, which traditionally wasn't used
> in a federated manner (but maybe I'm wrong about that), so it doesn't
> need a rooted hierarchy, though it also could use one.  (b) and (c) are
> niches, with no real place on the open, public Internet.
>
> One could use something like HS as an alternative to LDAP, say, but
> recall that the vision of a world of federated and open directories
> never materialized NOT because of limitations of DAP/LDAP, but because
> of confidentiality/ privacy considerations.  Such a class would really
> need to use the same rooted hierarchy, and, really, the same root, as
> the public DNS IN class -- i.e., an IN RR type namespace extension
> class, so it's best to consider such a class in those terms rather than
> as a "directory class".
>
> I am having a very difficult time imagining, say, a peer-to-peer or
> web-of-trust DNS (other than mDNS).  Perhaps my imagination fails me.
>
> A rooted hierarchy is and has been incredibly useful, and the simplest
> method of providing a consisten Internet to all users.  It seems to me
> very unlikely that we'll ever move from that.  At most we may have
> alternative roots, but a mostly common set of TLDs (e.g., as happens in
> many private (corporate) networks).
>
> Nico
> --
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/dnsop
>