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 15:38 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 827BE1A1B30 for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:38:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_64=0.6] autolearn=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 6sKrIkPlnrjS for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:37:59 -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 46D551A1B24 for <ietf@ietf.org>; Mon, 23 Feb 2015 07:37:59 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 067BB282F52; Mon, 23 Feb 2015 15:37:58 +0000 (UTC)
Date: Mon, 23 Feb 2015 15:37:57 +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: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/zEztzLmT1RIutF6OIbtv6KuGVUM>
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 15:38:00 -0000

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.

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

I see nothing new added here, it just carries over priority/weight
from SRV, and priority (which takes precedence over weight) is the
same as SRV and MX in as far as lowest number wins.  Clearly with
load-sharing relative weights, highest weight gets the most traffic,
but only statistically, some fraction of the time lower-weight URIs
are (to be) used.

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

	Section 1:

		s/For resolution the application need to/For resolution the application needs to/

		s/number of implications/number of limitations/

		s/is not replacing/is not intended to replace/

	Section 2:

		s/repetitive queries/repeated queries/

	End of Section 3:

	    s/stake holders/stakeholders/	

	Section 4.1:

		s/DNS labels that occur in nature/regular DNS labels/

-- 
	Viktor.