Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

Joel jaeggli <joelja@bogus.com> Mon, 13 February 2012 04:25 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B5921F865D; Sun, 12 Feb 2012 20:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.756
X-Spam-Level:
X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujn3mPPzfiCA; Sun, 12 Feb 2012 20:25:21 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 48E2321F862D; Sun, 12 Feb 2012 20:25:21 -0800 (PST)
Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1D4PCGD059614 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 13 Feb 2012 04:25:16 GMT (envelope-from joelja@bogus.com)
Message-ID: <4F3890A6.3090308@bogus.com>
Date: Sun, 12 Feb 2012 20:25:10 -0800
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <CAAedzxqXaPtNkyGt-P9xzdxvPkgLXcGOr-f3q7BuRq9555duaw@mail.gmail.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> <CAKD1Yr2xgkEeK7SaRjMZSbdJPs0u5FTozo0qa5MA4fda+SBcyw@mail.gmail.com> <4F329696.6000505@bogus.com> <CAKD1Yr2FpapZuz4fk1M1uqmG2Xgao_K=Houpnz0Jq2k56ZLMLg@mail.gmail.com>
In-Reply-To: <CAKD1Yr2FpapZuz4fk1M1uqmG2Xgao_K=Houpnz0Jq2k56ZLMLg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 13 Feb 2012 04:25:18 +0000 (UTC)
Cc: v6ops v6ops WG <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 04:25:21 -0000

On 2/9/12 01:25 , Lorenzo Colitti wrote:
> On Thu, Feb 9, 2012 at 00:36, Joel jaeggli <joelja@bogus.com
> <mailto:joelja@bogus.com>> wrote:
> 
>     Ops is not marketing.
> 
> 
> And if I were looking for a marketing venue, a standards body that
> produces ASCII text documents read by a handful of engineers would not
> be high on my list. This is not about marketing.
>

Sorry for being so droll, I found it hard to restrain myself.

> 
>     If you're saying some flag day makes the contents of the document no
>     longer operationally relevant after a given date, I'll take the point
>     but disagree.
> 
> 
> I think you're missing my point.
> 
> It seems to me that approximately 30% of the non-biolerplate text in
> this draft discusses DNS whitelisting. (And in fact, in its original
> form the draft entirely on DNS whitelisting - hence the filename. The
> rest was added later.)
> 
> Whitelisting is a practice relevant to a few large websites (since
> nobody else is using it). It so happens that the websites that employ
> this practice are going to stop using it, all together. Given the cost
> and implications, I'd say practice is unlikely to be resurrected.

I do not belive that the selective (inclusive) return of A or A + AAAA
records on the basis of source address is likely to end on a particular
day. It may well for you and some others, which is fine, or you may find
it necessary again, or it may become a list of exclusions rather than
inclusions. I belive you're on record indicating as much. In any event
others may find it necessary.

> So, you decide to tell the whole story, and talk about whitelisting
> *and* World IPv6 Launch. Or you can decide that whitelisting will soon
> be irrelevant, and not talk about either whitelisting or World IPv6
> Launch. But you can't talk about whitelisting without talking about
> World IPv6 Launch, because if you do, your document is missing the key
> piece "how do you remove the whitelist", and that's a disservice to its
> readers.
> 
> To be more specific, at least section 5.5 ("it is unclear
> how implementers will judge when the network conditions will have
> changed sufficiently to justify turning off DNS Resolver Whitelisting
> and/or what the process and timing will be for discontinuing this
> practice") is now incorrect. It *is* clear, and it's what those
> implementers are doing as part of World IPv6 Launch.

Invidual service operators like you and I are likely to make decisions
on the basis of our instrumentation, we may well alter their behavior on
a uni or multilateral basis, and some of us may do so for world ipv6
launch. ipv4/v6 Transition is not something with a flag day however, and
I do not believe that the concerns embedded in the draft will be
fundamentally altered on 6/6/12.

> Does that make more sense?

yes, that doesn't imply that we're in concert however.

> Cheers,
> Lorenzo