IETF Logo Mail Archive

(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:05 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 1A0221A1AD0 for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.39
X-Spam-Level:
X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, 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 gJN_G1YR3QN7 for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:05:21 -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 B44441A1AB5 for <ietf@ietf.org>; Mon, 23 Feb 2015 07:05:21 -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 1YPuZU-00045e-6j; Mon, 23 Feb 2015 10:05:20 -0500
Date: Mon, 23 Feb 2015 10:05:15 -0500
From: John C Klensin <john-ietf@jck.com>
To: Patrik Fältström <paf@netnod.se>
Subject: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com>
In-Reply-To: <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se>
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>
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/vbshDAYk81-ryBYuSwKQTGrx3H4>
Cc: ietf@ietf.org
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:05:28 -0000

Hi.

Since the Last Call ends tomorrow and much of what I have to say
about this draft is really more general observations about
architecture and IETF procedures about which the draft is either
the beneficiary or the victim, this is a short and focused note
for the Last Call and those who are not interested in my
(inevitably longer) musings and/or explanations of concerns.

We have dug ourselves into a bit of a hole (or more than one)
wrt mechanisms for resolving references and DNS entries that
reference other DNS entries, some of them with the potential for
triggering multiple trips to the DNS with intermediate
processing.  Independent of that problem (see other note), I
believe this I-D should be approved, and approved as a Proposed
Standard, on the grounds that we (and the Internet) are better
off with it than we are with only the NAPTR record and its
S-NAPTR refinement.

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.  Certainly we have had sufficient
experience with confusion about MX and SRV priorities to be
cautious about adding another ranking field, especially one
whose values are interpreted as "largest integer has the highest
preference" while the more traditional priority is interpreted
as "smallest integer is highest preference".   Because IANA
registered this RR four years ago, it is too late to change that
(see the forthcoming longer note) but somewhat more explanation
in this document would, IMO, be helpful and might even above
confusion-related problems in configuration and implementations.
Noting that none of the examples in -11 use Weight in a
substantive way, I would hope that explanation would include a
discussion of when one would use "Weight" as distinct from
finer-grained Priorities and what benefits would be associated
with using it.

    john

v2.23.0 | Report a Bug | By Email