Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

Matt Larson <matt@kahlerlarson.org> Fri, 19 August 2016 14:00 UTC

Return-Path: <matt@kahlerlarson.org>
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 DDF4212D99F for <dnsop@ietfa.amsl.com>; Fri, 19 Aug 2016 07:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 QbAtoVqWy0u3 for <dnsop@ietfa.amsl.com>; Fri, 19 Aug 2016 07:00:10 -0700 (PDT)
Received: from mail.kahlerlarson.org (tornado.kahlerlarson.org [64.22.125.99]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F87212D8ED for <dnsop@ietf.org>; Fri, 19 Aug 2016 07:00:09 -0700 (PDT)
Received: from [10.96.9.31] (44-2.dc.icann.org [192.0.44.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kahlerlarson.org (Postfix) with ESMTP id 395B038529; Fri, 19 Aug 2016 10:01:24 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Matt Larson <matt@kahlerlarson.org>
In-Reply-To: <BA70D535-2C5E-4E68-B54E-2B4A37FB4CE4@frobbit.se>
Date: Fri, 19 Aug 2016 10:00:08 -0400
X-Mao-Original-Outgoing-Id: 493308007.594101-f281da6a4ebd88f3d5d9a7d5ba8e0a18
Content-Transfer-Encoding: quoted-printable
Message-Id: <98C3D647-92A6-4353-8008-6202B4C2CC28@kahlerlarson.org>
References: <20160804015840.60405.qmail@ary.lan> <dd070788-bf7a-e7de-b07b-b81151f101db@dcrocker.net> <alpine.OSX.2.11.1608032350220.10321@ary.lan> <f42e91bb-19fd-99d6-bd64-e2ec5b8ebf2f@bellis.me.uk> <ae82cc80-fdfe-8876-7459-db61c7abc52d@dcrocker.net> <BA70D535-2C5E-4E68-B54E-2B4A37FB4CE4@frobbit.se>
To: Patrik Fältström <paf@frobbit.se>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uYGbNpjmdSutindIobIQcf7aVeQ>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf
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: Fri, 19 Aug 2016 14:00:15 -0000

Patrik,

> On Aug 9, 2016, at 12:06 PM, Patrik Fältström <paf@frobbit.se> wrote:
> 
> On 4 Aug 2016, at 18:55, Dave Crocker wrote:
> 
>>>> For URI records RFC 7553 says they're either named the same as SRV
>>>> records, or they use enumservice names from the Enumservice
>>> 
>>> Declaring a namespace as the union of two, independently-maintained
>>> registries is a very efficient way to encourage -- actually in
>>> theoretical terms, it guarantees -- collisions.
>>> 
>> 
>> I see this as a fundamental problem with the URI spec, for the reason cited.  I also think the current spec should be careful not to promote that problem.
>> 
>> Suggestions?
> 
> Add text that say that to resolve conflicts (what prefixes to use for URI or SRV for "the web"?), it is encouraged to write explicit documents that say what is to be used.
> 
> I just submitted draft-faltstrom-httpbis-dns-00.txt is an example of what I am thinking of, for URI and "the web", which explicitly say what to enter into the registry that is defined by this document. My envision is to add more text on the recommended way to use DNS in the case of "the web".
> 
> TL;DR: draft-faltstrom-httpbis-dns-00.txt recommends _web._http for "the web". Regardless of the registration of both ENUM services HTTP and HTTPS, regardless of the various "names" used for port number 80 (etc) and regardless of whether TCP or UDP (and other things being part of the HTTP evolution...).
> 
> It is "just" used for rewrite of the URI before the HTTP protocol takes over.

I read draft-faltstrom-httpbis-dns-01 and have some comments and questions.

There's text in Section 5.4 of RFC7553 that indicates the precedence of URI over SRV for HTTP and I suggest similar text somewhere in the draft to make it clear that SRV is not involved and URI is an alternative to the (hypothetical) use of SRV for HTTP.

I found the text hard to parse because "URI" is overloaded in the context of the draft.  It can refer to (at least) the URI causing the processing, the URI RRset looked up as a result of processing, and the URI in the RDATA of a URI RR.   In particular, I think the URI causing the processing and the URI in the RDATA should be referenced explicitly with different names: how about "input URI" and "target URI", respectively?  The specific names don't matter as long as they're clearly defined.

I think the specific algorithm should be made a bit clearer, in particular noting that multiple iterations could be required and being more explicit about the termination condition. An example would help a lot.

Speaking of examples, is this how it works?

- User types "example.com"

- "http://example.com" is the "input URI"

- Look up _web._http.example.com/URI, result is URI RR with RDATA "http://www.example.com"

- "http://www.example.com" is the "target URI", but becomes the new input URI in the next iteration.

- Look up _web._http.www.example.com/URI, result is URI RR with RDATA "http://example.cloud-o-matic.com"

- "http://example.cloud-o-matic.com" is the target URI, but becomes the new input URI in the next iteration.

- Look up _web._http.example.cloud-o-matic.com/URI, result is NXDOMAIN

- Look up example.cloud-o-matic.com/A and example.cloud-o-matic.com/AAAA, result is A and AAAA RRs

- Connect via HTTP to IPv4/IPv6 per local preference, Happy Eyeballs, etc.


A final question: where do you intend discussion of this draft to happen?  Here in dnsop?

Matt