Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

Matthew Kerwin <matthew@kerwin.net.au> Wed, 05 July 2017 02:23 UTC

Return-Path: <phluid61@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 3846C12708C; Tue, 4 Jul 2017 19:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 Hk-p8NQhb6x9; Tue, 4 Jul 2017 19:23:55 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 D525E1243FE; Tue, 4 Jul 2017 19:23:54 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id r36so78695520ioi.1; Tue, 04 Jul 2017 19:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jYQ2QOn8eQPLD8Esu0GIsS3u7rsB8jx+JvW66/nMLlw=; b=L64ZRiwlyuBrtaXh8qSY67jQJT8uVDyodeRF4wTEDpIXEJlVFXI0016NtNceQcLckH 23s4nJa1HWZmOxYlUVJTVODPHuYI/+Doy5a+UAa3NiZ6Y7LYEAlZsmsRpSQ5JLqr7R1P OnayLlqlU6AA2fa+uMbH0XCraETrVHQsMZEaGDbky/U9s+EZ26/hTeiArhqh/8QmdCJH w/6SX35cVlofBHbmu4IOPYPr7uV0eFY3bjiCLUVcdeZHSWkkA4jabrGsbc3A0lhGB2MJ EvAFFMmIoql/IB8fQ8KIEUdp3n8tNyxw1iMvmEGIxkZv2BtFhCFKTGOlvepK2hIEx4HL X9WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jYQ2QOn8eQPLD8Esu0GIsS3u7rsB8jx+JvW66/nMLlw=; b=q4P4RTAYnoVLVSckZEqQju4AlTQKw4fFcddUTHJQICrZPong5hBllkSo+XNmxkEAJy SB2i1nYuxYLbnHC43bRJay/4SReCS+a9w23BJNfWrnOHtf0nq/o9wVrCKndZLGxrwJdS 4FeGipRv6gEZkxD+3ohp98k9bwsizSweenrkStLvFcuJn5LNubPuulq9nt/U5NOsDZae gODRJq2oqw53VPwlS/lufiXc7XbBNGEsTCiI3YCSauvUqMPxem+awRew0G6ArIdKhEol f1Qk4OaPH4GqCC/MtmVQP7dP6/vDMOQ2Tu4o4lFI7xOvZll3xFjeQ6c1ROuI1TCUunZ8 jQwg==
X-Gm-Message-State: AIVw111Z9SWYEXmqI1EvAIM0nGpN8pIinTwIvT0uy1g1jQwhe3mu0mhe fKGNYy+sG6NW4sNa8afFXhc9yGqSoA==
X-Received: by 10.107.46.165 with SMTP id u37mr1215217iou.217.1499221434235; Tue, 04 Jul 2017 19:23:54 -0700 (PDT)
MIME-Version: 1.0
Sender: phluid61@gmail.com
Received: by 10.107.18.7 with HTTP; Tue, 4 Jul 2017 19:23:53 -0700 (PDT)
In-Reply-To: <20170705000229.5918D7D8457F@rock.dv.isc.org>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <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> <20170705000229.5918D7D8457F@rock.dv.isc.org>
From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Wed, 5 Jul 2017 12:23:53 +1000
X-Google-Sender-Auth: OfnhEjXWfv0h7gZn8xsuBP5SQGc
Message-ID: <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ekt53z8dXuvsLR-rIFh5c6Cszas>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
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: Wed, 05 Jul 2017 02:23:57 -0000

On 5 July 2017 at 10:02, Mark Andrews <marka@isc.org>; wrote:
>
> Who owns a name is a different question to what machines serve the
> <name,type,class> tuple and how do you reach those machines.  There
> is absolutely no reason why the zones <name,IN> and <name,CLASS56>
> need to be served by the same machines.  There is a argument for
> them both being under control of the same people.
>
> Mark
>

Hi, I'm jumping in at a random time with a possibly dumb question, but
the talk of <name,type> and <name,type,class> tuples got me wondering
about representation in general, and URLs in particular.

RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks
like a DNS name is a DNS name, and that they have to be resolved to IP
addresses if you want to fetch them, but they don't talk meaningfully
about how to do that resolution. Given that we always assume class=IN
(not to mention type=A|AAAA via happy eyeballs), how would we go about
practically presenting an alternative class in things like URLs?
(Registering a new "alt-http" URL scheme doesn't strike me as a great
idea.)

Because it's all well and good setting up your own .org hierarchy
under class=FOO or whatever, but there's not much point if you can't
send people to www.not-icann.org using it. Unless you don't want to
expose your new hierarchy to the web ...?

Cheers


[*] https://tools.ietf.org/html/rfc3986#section-3.2.2 :

   """A registered name intended for lookup in the DNS uses the syntax
   defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]."""

I read that as: "if it matches RFC1034 (and isn't overridden by the
specific URI scheme's rules) it's a DNS name."  It could be read the
other way, but that just adds more assumptions.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/