Re: [DNSOP] draft-lewis-domain-names-00.txt

Edward Lewis <edward.lewis@icann.org> Fri, 18 September 2015 13:39 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0221B2BE1 for <dnsop@ietfa.amsl.com>; Fri, 18 Sep 2015 06:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level:
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 1tKPy78wxttT for <dnsop@ietfa.amsl.com>; Fri, 18 Sep 2015 06:39:52 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADD51B2BDE for <dnsop@ietf.org>; Fri, 18 Sep 2015 06:39:52 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 18 Sep 2015 06:39:50 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Fri, 18 Sep 2015 06:39:50 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] draft-lewis-domain-names-00.txt
Thread-Index: AQHQ8YNHdEo//bQ/vEaybYlWidLMPZ5CuraA///DgYA=
Date: Fri, 18 Sep 2015 13:39:49 +0000
Message-ID: <D22188DC.F26C%edward.lewis@icann.org>
References: <D2209363.F235%edward.lewis@icann.org> <CAKr6gn1aM0=Mi3343aaXKc=WtqGnJqoQm64+r4LDKzT0MyAF7A@mail.gmail.com>
In-Reply-To: <CAKr6gn1aM0=Mi3343aaXKc=WtqGnJqoQm64+r4LDKzT0MyAF7A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3525413983_3773481"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/FkKasW2HGrtPVurd1hKqXk3Xv8k>
Subject: Re: [DNSOP] draft-lewis-domain-names-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Sep 2015 13:39:53 -0000

On 9/18/15, 9:16, "George Michaelson" <ggm@algebras.org> wrote:

>My private comment bears repeating in public.

That's good...

>DOMAIN names is about the property of domains. Domains are encompassing,
>set-theory/venn-diagram style. A domain and a prefix are analogous
>concepts. One is expressed syntactically somehow, the other is a
>mathematical property of bounding in a number field
> but they have the same basic behaviour.
>
>the UK domain order in coloured book mails obeyed this property: it just
>used reverse semantics to the ARPA model.
>
>XXXXXXXX.onion is *not* a domain name inside the .onion part: as I
>understand it, the value is a hash, or other function which has no
>nesting properties expressed syntactically.
>
>This quality of domain names, the concepts of domains, is a distinct
>property which bears thinking about.
>
>HOST.TXT was not a domain system, it was a linear map. Honey Danber had
>some qualities of domain-ness. Usenet groups after the great mod.*
>reordering became more domain like.

So, it's true that the word "domain" has other meanings, it wasn't coined
for the use evident in RFCs (and other documents).

I went through a similar discussion early in the preparation of RFC 4594
"The Role of Wildcards in the Domain Name System".  Initially it was
"Clarifications on Wildcards" which ran into the question of "if you have
to redefine them, it's not a clarification."  Next the objection was that
I'd initially written that Wildcards was the way to do record synthesis in
the DNS.  The objection was well founded, Wildcards are *a* way to do
record synthesis, and the only possible means unless we ditch or seriously
alter AXFR.  (That discussion began my interest in that topic.)

There have been other things called domains before, and domain names.
It's clear from reading the old (pre-1000) RFCs that there was "science"
going on that was unrecorded in the RFC series.  This document is by no
means able to capture that - yet, until I get some reference material.

So - look at this document as trying to define "Domain Names" as they
appear in IETF, RFC-documented protocols.  With the document about the
interoperability of the IETF's use of "Domain Names."  Perhaps the title
should be "IETF(tm) Domain Names". ;)

In summary, your point is taken that there's a wider scope to the topic.
There has to be, I don't think anyone had a nightmare one night and the
DNS was born.  The goal here is to establish a basis for how we extend the
way Domain Names appear in Internet technologies - not just IETF, but
hopefully one in the same even if there's a lag.  From experience I won't
set as a goal a way to unify how all protocols use Domain Names - that has
long since passed, the protocols are working fine, there's no need to
restructure code for the sake of documentation.  But there's a need to
look at the forward path.

Ed

PS - My work is based, except where noted, on what is recorded in the
RFCs.  I know that the RFCs aren't all encompassing but I wasn't "in the
room" so have no other input to add.  (I know this from being "in the
room" and seeing the resulting RFC lacking some important detail.)  If
others were in the room and have other points of data to supply, please do
so - preferably with a citable reference.