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

"Livingood, Jason" <Jason_Livingood@cable.comcast.com> Wed, 15 February 2012 15:52 UTC

Return-Path: <jason_livingood@cable.comcast.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 E47FF21F8537; Wed, 15 Feb 2012 07:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.099
X-Spam-Level:
X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=3.364, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Jy0Gg8ubGhws; Wed, 15 Feb 2012 07:52:49 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5D21F8533; Wed, 15 Feb 2012 07:52:49 -0800 (PST)
Received: from ([24.40.56.114]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.151544428; Wed, 15 Feb 2012 10:52:17 -0500
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Wed, 15 Feb 2012 10:52:17 -0500
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: v6ops v6ops WG <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>
Thread-Topic: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
Thread-Index: AQHM6/nKbjYam0no7UGRxd2Rv+MjlA==
Date: Wed, 15 Feb 2012 15:52:16 +0000
Message-ID: <CB61222C.50472%jason_livingood@cable.comcast.com>
In-Reply-To: <CB5F3DFE.4FFE3%jason_livingood@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [24.40.55.72]
Content-Type: multipart/alternative; boundary="_000_CB61222C50472jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
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: Wed, 15 Feb 2012 15:52:51 -0000

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.

Does that make more sense?

As the author, if it helps I plan to make the following change to Section 5.5 following the conclusion of IETF Last Call. I ran this by a few folks already and it seems broadly acceptable (have not heard from Lorenzo yet though).

Jason

CURRENT 5.5:
5.5.  Turning Off DNS Resolver Whitelisting

Domains that choose to implement DNS Resolver Whitelisting generally consider it to be a temporary measure. 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, though the extent of IPv6 deployment to end users in networks, the state of IPv6-related impairment, and the maturity of IPv6 operations are all clearly factors. However, implementers may wish to take into consideration that, as a practical matter, it will be impossible to get to a point where there are no longer any IPv6-related impairments; some reasonably small number of hosts will inevitably be left behind as end users elect not to upgrade them or as some hosts are incapable of being upgraded.

PROPOSED 5.5 (NEW TEXT IN ALL CAPS):
5.5.  Turning Off DNS Resolver Whitelisting

Domains that choose to implement DNS Resolver Whitelisting generally consider it to be a temporary measure. 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, though the extent of IPv6 deployment to end users in networks, the state of IPv6-related impairment, and the maturity of IPv6 operations are all clearly factors. However, SOME IMPLEMENTERS HAVE ANNOUNCED THAT THEY PLAN TO PERMANENTLY TURN OFF WHITELISTING BEGINNING ON WORLD IPV6 DAY IN JUNE 2012 [REFERENCE]. IN ANY CASE, implementers may wish to take into consideration that, as a practical matter, it will be impossible to get to a point where there are no longer any IPv6-related impairments; some reasonably small number of hosts will inevitably be left behind as end users elect not to upgrade them or as some hosts are incapable of being upgraded.

<eom>