Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

John C Klensin <john-ietf@jck.com> Mon, 23 February 2015 15:52 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2551A1B6A for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 fBno98mLYusR for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:52:28 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231B81A1B65 for <ietf@ietf.org>; Mon, 23 Feb 2015 07:52:23 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YPvJ0-0004DF-7E for ietf@ietf.org; Mon, 23 Feb 2015 10:52:22 -0500
Date: Mon, 23 Feb 2015 10:52:17 -0500
From: John C Klensin <john-ietf@jck.com>
To: ietf@ietf.org
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <5E294F0151894214C57B4CD2@JcK-HP8200.jck.com>
In-Reply-To: <20150223153757.GI1260@mournblade.imrryr.org>
References: <20150127223859.28024.43756.idtracker@ietfa.amsl.com> <4257D8A3-0EFE-40E3-B0AD-8E23772B7693@mnot.net> <6F9BB11D-C224-4D7B-A06C-41EACBAAB4B2@netnod.se> <54C9DA42.5040901@cisco.com> <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se> <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com> <20150223153757.GI1260@mournblade.imrryr.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/bpjwbNDg_7PfpAAn_VOmLeuadWM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2015 15:52:29 -0000


--On Monday, February 23, 2015 15:37 +0000 Viktor Dukhovni
<ietf-dane@dukhovni.org> wrote:

> On Mon, Feb 23, 2015 at 10:05:15AM -0500, John C Klensin wrote:
> 
>> I do note that having "priority" and "weight" separated is not
>> well-motivated (or even explained) in either this document or
>> in the original application. 
> 
> This is simply carried over verbatim from SRV, where priorities
> yield strict ordering, while weights (for entries with the same
> priority) support weighted load-sharing.  This draft does not
> appear to differ from SRV except in replacing target+port with
> an URI.

But here, as distinct from SRV, a good deal is known about the
relationship (or, more accurately, association) among targets
because of what is in the owner field while, with SRV, there are
potentially different hosts and mechanisms for the same service.
One of the presumed attractions of this mechanism relative to
SRV (and NAPTR) is that one does not have to go fishing around
in, and parsing, RDATA fields to figure out what is going on.
In that regard, it appears to be more like the single-service MX
record, which has never needed a weight.

If "make this as much like SRV as possible" is a motivation,
then I'd expect that to be written a little more clearly and
might expect Weight to be specified as "reserved for future
extension; set to zero in all cases".  Or, if not, I expect its
use to be clearly explained.  Perhaps that explanation could be
just a reference to SRV, but I doubt it.

>...
> While I am here, a few quick (likely not comprehensive)
> spelling/wording fixes:
>...

I have nothing to add to/above your editorial suggestions.

     john