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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 23 February 2015 16:24 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 4B7FA1A1B85 for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 08:24:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 waCLW-xSfEj7 for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 08:24:31 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089311A1AAA for <ietf@ietf.org>; Mon, 23 Feb 2015 08:24:31 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 23E3A282F52; Mon, 23 Feb 2015 16:24:30 +0000 (UTC)
Date: Mon, 23 Feb 2015 16:24:30 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
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: <20150223162429.GK1260@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> <5E294F0151894214C57B4CD2@JcK-HP8200.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5E294F0151894214C57B4CD2@JcK-HP8200.jck.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/TV9AEyYlXVCMJIIobrFpgcFoQxw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
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 16:24:36 -0000

On Mon, Feb 23, 2015 at 10:52:17AM -0500, John C Klensin wrote:

> 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.

A couple of years back I wrote (for my employer) a Python LDAP
iterator that fully implements the SRV record priority and weight
specification.  I found that others looking over the code later
were surprised by the attention to detail.  It seems that many
implementations don't even pay attention to SRV priorities, let
alone weights.

So perhaps you're right, in that the SRV priority+weight design is
likely over-engineered in general, and for this use-case in
particular.  It seems likely that many implementations simply ignore
the full semantics.

-- 
	Viktor.