Re: Last Call: RFC 6346 successful: moving to Proposed Standard

Ted Lemon <Ted.Lemon@nominum.com> Thu, 04 December 2014 17:25 UTC

Return-Path: <Ted.Lemon@nominum.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 BA40E1AD4B7 for <ietf@ietfa.amsl.com>; Thu, 4 Dec 2014 09:25:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eNkHP6a3ySRi for <ietf@ietfa.amsl.com>; Thu, 4 Dec 2014 09:25:06 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE211A3B9D for <ietf@ietf.org>; Thu, 4 Dec 2014 09:25:06 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id F023EDA0101 for <ietf@ietf.org>; Thu, 4 Dec 2014 17:24:52 +0000 (UTC)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4C0E553E076; Thu, 4 Dec 2014 09:24:36 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Dec 2014 09:24:36 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Last Call: RFC 6346 successful: moving to Proposed Standard
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <20141204171734.GK19718@mx1.yitter.info>
Date: Thu, 4 Dec 2014 12:24:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <3C28DC47-0F59-4481-9941-730C824BBA36@nominum.com>
References: <20141201223832.20448.34524.idtracker@ietfa.amsl.com> <20141204162800.GE19718@mx1.yitter.info> <DBB1C75E-96D9-4F3B-93A9-EE22C40D47A7@netapp.com> <29C2D286-E8D9-4D66-9F4D-A069EB0FFDC3@nominum.com> <20141204171734.GK19718@mx1.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/LnhRpVRZFHhpNpeyyhM03Y9pOe4
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: Thu, 04 Dec 2014 17:25:08 -0000

On Dec 4, 2014, at 12:17 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> Lots of servers do funny things depending on the transport over which
> the query came, so I don't think that's a viable argument.  

This is actually a really good argument for saying that servers _shouldn't_ do that.   But to dig into that a bit deeper, I think there are two cases where servers do different things.   First case, the server is trying to steer traffic for a CDN.   In that case, you want to steer the traffic to IPv6, so doing the query over IPv6 is always the right thing to do in this case.   If the service provider is only providing CDN over IPv4, and the client uses the less desired path because of this, that's a problem the service provider should fix, and not a problem we need to worry about.   That said, the SP can certainly give a CDN-tailored answer based on the IPv6 source address if this is desired.

Second case, the server only returns AAAAs if the query comes over IPv6.   In this case, we want the query to go over IPv6.   But this is likely a decision being made about the SP's caching nameserver, not about the client, so we should not actually see different behavior depending on whether the _client_ does the query using IPv4 or IPv6.

Is there another case I'm missing (wouldn't surprise me)?

>> So it's possible that this ought to be discussed further in the document.
> 
> That was my point: as I said, I do not oppose standardizing A+P, I
> just oppose taking the existing document, slapping new boilerplate and
> a new number on it, and publishing.  There are changes needed.

Yup, I think you are right, much as I generally prefer less work to more.