From wesley.george@twcable.com Thu Nov 1 05:04:47 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABB221F8628 for ; Thu, 1 Nov 2012 05:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTWFkAaJugpF for ; Thu, 1 Nov 2012 05:04:46 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8A21F8674 for ; Thu, 1 Nov 2012 05:04:45 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,692,1344225600"; d="scan'208";a="444132568" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 01 Nov 2012 08:04:25 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 1 Nov 2012 08:04:44 -0400 From: "George, Wes" To: Marc Blanchet , "sunset4@ietf.org" Date: Thu, 1 Nov 2012 08:04:53 -0400 Thread-Topic: [sunset4] new charter draft version Thread-Index: Ac2wh8btwfi9lM2JRB695g8pgy4cpAHoD0JA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230336D65F09@PRVPEXVS15.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sunset4] new charter draft version X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 12:04:47 -0000 The lack of any response to this is a bit disconcerting. I realize we have = both IETF prep and storms taking people away from normal list traffic, but = does anyone have comments? It's much easier to wordsmith a charter via emai= l than in a room full of people. Please voice an opinion one way or the oth= er. Thanks Wes George > -----Original Message----- > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Marc Blanchet > Sent: Monday, October 22, 2012 3:02 PM > To: sunset4@ietf.org > Subject: [sunset4] new charter draft version > > Hello, > a few individuals worked on a new version of the sunset4 charter after > the last IETF. It has been wordsmitted many times and hopefully would > get support from the working group. > > It would be useful for us to see if you support this charter. If you > disagree, it would be useful to get modified text. > > Marc and Wes. > > PS. Current charter is still at the normal place: > https://datatracker.ietf.org/doc/charter-ietf-sunset4/ > PS2. this new charter has not got through IESG review yet. > > =3D=3D=3D=3D=3D=3D=3D > New sunset4 proposed charter > 2012-10-22 > > Global IPv4 addresses, once freely available, are an increasingly scarce > resource for many who wish to connect to the Internet today. IPv6 > provides an abundance of freely available addresses, and while > deployment alongside IPv4 has begun in earnest, much work remains. > > In order to fully transition the Internet to IPv6, individual > applications, hosts, and networks that have enabled IPv6 must also be > able to operate fully in the absence of IPv4. The Working Group will > point out specific areas of concern, provide recommendations, and > standardize protocols that facilitate the graceful "sunsetting" of the > IPv4 Internet in areas where IPv6 has been deployed. This includes the > act of shutting down IPv4 itself, as well as the ability of IPv6-only > portions of the Internet to continue to connect with portions of the > Internet that remain IPv4-only. > > While this work obviously spans multiple IETF areas including Internet, > Operations, Transport, Applications, and Routing, this working group > provides a single venue for the consideration of IPv4 sunsetting. Work > in this group shall never impede the deployment of IPv6, will not > duplicate functions and capabilities already available in existing > technologies, and should demonstrate widespread operational need. Cross- > area coordination and support is essential. > > Disabling IPv4 in applications, hosts, and networks is new territory for > much of the Internet today, and it is expected that problems will be > uncovered including those related to basic IPv4 functionality, > interoperability, as well as potential security concerns. The working > group will report on common issues, provide recommendations, and, when > necessary, protocol extensions in order to facilitate disabling IPv4 in > networks where IPv6 has been deployed. > > As a rule, deployment scenarios considered by the working group shall > include IPv6-only nodes and networks. Work on technologies that involve > increased sharing of global IPv4 addresses should be limited to what is > necessary for communicating with endpoints or over networks that are > IPv6-only. > > The initial work items are: > * NAT64 port allocation and address sharing methods involving scenarios > where an IPv6-only node is present (and NAT44, as it overlaps NAT64 > address sharing and port > use). > * Gap analysis of IPv4 features to facilitate IPv4 sunsetting > * Provisioning methods to signal a dual-stack host to disable or > depreference the use of IPv4 > > > Goals and Milestones: > Mar 2013 - Submit gap analysis on IPv4 sunsetting to IESG for > consideration as an Informational RFC > Jun 2013 - Submit NAT64 port allocation and address sharing methods to > IESG for consideration as an Informational RFC > Sep 2013 - Submit provisioning methods to signal a dual-stack host to > disable the use of IPv4 to IESG for consideration as Proposed Standard > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From simon.perreault@viagenie.ca Thu Nov 1 06:02:40 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D00721F9082 for ; Thu, 1 Nov 2012 06:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmgVWWQ3WsMs for ; Thu, 1 Nov 2012 06:02:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9314221F8FC6 for ; Thu, 1 Nov 2012 06:02:26 -0700 (PDT) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 96079467A1 for ; Thu, 1 Nov 2012 09:02:25 -0400 (EDT) Message-ID: <509272E0.2040109@viagenie.ca> Date: Thu, 01 Nov 2012 14:02:24 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: sunset4@ietf.org References: <2671C6CDFBB59E47B64C10B3E0BD59230336D65F09@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230336D65F09@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sunset4] new charter draft version X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:02:40 -0000 Le 2012-11-01 13:04, George, Wes a écrit : > The lack of any response to this is a bit disconcerting. I realize we > have both IETF prep and storms taking people away from normal list > traffic, but does anyone have comments? It's much easier to wordsmith > a charter via email than in a room full of people. Please voice an > opinion one way or the other. One question I have is where will the CGN stuff go? One instance of "CGN stuff": In BEHAVE we had to split off the CGN part of the NAT MIB. We were told that it would go in sunset4. It's not clear to me just by reading the charter that this advice is still valid. There's a ton of other CGN-related drafts floating around. Is the plan just to let them die? If so, I fear they'll keep coming back to haunt us... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From marc.blanchet@viagenie.ca Fri Nov 2 06:51:40 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA9021F8881 for ; Fri, 2 Nov 2012 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1asKPAc5qRrk for ; Fri, 2 Nov 2012 06:51:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE9521F887C for ; Fri, 2 Nov 2012 06:51:39 -0700 (PDT) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AE728412FB for ; Fri, 2 Nov 2012 09:51:38 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Nov 2012 09:51:38 -0400 Message-Id: To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [sunset4] presenters slides X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 13:51:40 -0000 To presenters, please send your slides to the chairs = (sunset4-chairs@tools.ietf.org) before sunday noon. Regards, Marc.= From wesley.george@twcable.com Fri Nov 2 07:44:49 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682571F0C3A for ; Fri, 2 Nov 2012 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhwvDFhjnAIc for ; Fri, 2 Nov 2012 07:44:48 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 869D621F8AC0 for ; Fri, 2 Nov 2012 07:44:48 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,699,1344225600"; d="scan'208";a="444936928" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 Nov 2012 10:44:24 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 2 Nov 2012 10:44:47 -0400 From: "George, Wes" To: "sunset4@ietf.org" Date: Fri, 2 Nov 2012 10:44:45 -0400 Thread-Topic: Meetecho support at IETF85 Thread-Index: Ac25CEo33fKtQna1QLy4/UB46yUWEwAACbbg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230336E528E7@PRVPEXVS15.corp.twcable.com> References: <5093D54C.40205@meetecho.com> In-Reply-To: <5093D54C.40205@meetecho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sunset4] FW: Meetecho support at IETF85 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:44:49 -0000 There will be Meetecho support at our session. This is at least partially f= or my benefit, since I am attending this IETF remotely, but wanted to make = sure that other potential remote participants were also aware. Thanks, Wes -----Original Message----- From: info@meetecho.com [mailto:info@meetecho.com] Sent: Friday, November 02, 2012 10:15 AM To: sunset4-chairs@tools.ietf.org Subject: Meetecho support at IETF85 Dear chair(s), we confirm Meetecho remote participation support for your WG meeting sessio= n @ IETF85. If you plan to have remote presenters, please let us know in proper advance= so we can configure the audio feed accordingly. Further information and instructions on how to join can be found at http://= ietf85.conf.meetecho.com. We kindly ask you to upload all slide decks on the meeting materials page A= SAP, since we need to upload them on Meetecho as well. Thanks, the Meetecho team -- Meetecho s.r.l. www.meetecho.com This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From marc.blanchet@viagenie.ca Sat Nov 3 16:23:02 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C271321F9C3E for ; Sat, 3 Nov 2012 16:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.613 X-Spam-Level: X-Spam-Status: No, score=-101.613 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UnhcQixvaO9 for ; Sat, 3 Nov 2012 16:23:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A05A21F9C7D for ; Sat, 3 Nov 2012 16:23:02 -0700 (PDT) Received: from [IPv6:2001:df8::64:e05e:a88d:5ad3:608b] (unknown [IPv6:2001:df8:0:64:e05e:a88d:5ad3:608b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ECD87467B6 for ; Sat, 3 Nov 2012 19:23:01 -0400 (EDT) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Nov 2012 18:37:36 -0400 Message-Id: <8CFB464E-6EA3-45A2-A752-7E2E18751845@viagenie.ca> To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [sunset4] minute taking volunteers X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 23:23:02 -0000 Hello, we would need a few volunteers to do minute taking. Again, this time = hopefully through the normal wg site, we will use the Etherpad so = everyone can edit real-time and provide minute taking. This way, no one = has a burden to write minutes, and everyone can chip in and help a bit. Would some of you volunteer? Please send to the chairs = (sunset4-chairs@tools.ietf.org). Greatly appreciated. Regards, Wes and Marc. From marc.blanchet@viagenie.ca Mon Nov 5 05:19:57 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB50F21F8458 for ; Mon, 5 Nov 2012 05:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93+kdCCa4Q1S for ; Mon, 5 Nov 2012 05:19:57 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB4821F84CC for ; Mon, 5 Nov 2012 05:19:57 -0800 (PST) Received: from dhcp-5059.meeting.ietf.org (dhcp-5059.meeting.ietf.org [130.129.80.89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 12FE5415DF for ; Mon, 5 Nov 2012 08:19:56 -0500 (EST) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Nov 2012 08:19:54 -0500 Message-Id: <28507CE8-B003-44C3-A5FB-7F0E2489E0C2@viagenie.ca> To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [sunset4] sunset4 session minute taking X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:19:57 -0000 Hello, we will be using the wg etherpad for the session minute taking: = http://tools.ietf.org/wg/sunset4/minutes. I started it with the current = agenda. Regards, Marc.= From marc.blanchet@viagenie.ca Tue Nov 6 06:02:00 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F234221F8955 for ; Tue, 6 Nov 2012 06:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIEseeEb6g3m for ; Tue, 6 Nov 2012 06:01:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9239821F8914 for ; Tue, 6 Nov 2012 06:01:59 -0800 (PST) Received: from dhcp-5059.meeting.ietf.org (dhcp-5059.meeting.ietf.org [130.129.80.89]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 90E00400D5 for ; Tue, 6 Nov 2012 09:01:56 -0500 (EST) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Nov 2012 09:01:55 -0500 Message-Id: <35B7C037-7514-411A-9F21-9791E39B78B5@viagenie.ca> To: sunset4@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [sunset4] meeting minutes posted X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:02:00 -0000 Thanks to Christopher for taking minutes and all others who contributed = to the ether pad. Minutes of our meeting has been posted: = http://www.ietf.org/proceedings/85/minutes/minutes-85-sunset4 Please send comments/changes to the chairs = (sunset4-chairs@tools.ietf.org) Marc.= From tore.anderson@redpill-linpro.com Thu Nov 8 23:53:35 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8C021F8B6D; Thu, 8 Nov 2012 23:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyHgLGTY8hDl; Thu, 8 Nov 2012 23:53:34 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDBE21F8B31; Thu, 8 Nov 2012 23:53:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id B750B182001F; Fri, 9 Nov 2012 08:53:32 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3TpWbLjRIPl; Fri, 9 Nov 2012 08:53:28 +0100 (CET) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id B1E1E1820019; Fri, 9 Nov 2012 08:53:28 +0100 (CET) Message-ID: <509CB678.9090402@redpill-linpro.com> Date: Fri, 09 Nov 2012 08:53:28 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: "v6ops@ietf.org" , sunset4@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sunset4] draft-anderson-siit-dc-00 X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 07:53:35 -0000 Good morning, I've just uploaded a new draft: Filename: draft-anderson-siit-dc Revision: 00 Title: Stateless IP/ICMP Translation in IPv6 Data Centre Environments Creation date: 2012-11-09 WG ID: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-anderson-siit-dc-00.txt Status: http://datatracker.ietf.org/doc/draft-anderson-siit-dc Htmlized: http://tools.ietf.org/html/draft-anderson-siit-dc-00 Abstract: This document describes the use of Stateless IP/ICMP Translation (SIIT) in data centre environments in order to simultaneously facilitate IPv6 deployment and IPv4 address conservation. It describes the overall architecture, and provides guidelines for both operators and implementers. It's my first ever draft, so go easy on me. Note that this draft may be relevant to the discussion of draft-lopez-v6ops-dc-ipv6, as it documents in more technical detail a way to implement the "Next Generation Stage" briefly described in section 2.3. I do not know whether the discussion of this draft fits the best in v6ops or sunset4, so this message is cross-posted to both WGs. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From ietf@meetecho.com Fri Nov 9 09:06:19 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C0221F8BBC for ; Fri, 9 Nov 2012 09:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bORKytz9cVQ0 for ; Fri, 9 Nov 2012 09:06:19 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2982821F8ACD for ; Fri, 9 Nov 2012 09:06:18 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV6G1k01L0ELJoa01V6HSR; Fri, 09 Nov 2012 18:06:18 +0100 Message-ID: <509D3807.70004@meetecho.com> Date: Fri, 09 Nov 2012 18:06:15 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sunset4@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [sunset4] Meetecho session recording X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:06:19 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From lee@asgard.org Mon Nov 12 08:47:55 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3139821F8626 for ; Mon, 12 Nov 2012 08:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUKsZEdz+ATt for ; Mon, 12 Nov 2012 08:47:54 -0800 (PST) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id A7D9521F847C for ; Mon, 12 Nov 2012 08:47:51 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qACGloYa013989 for ; Mon, 12 Nov 2012 11:47:50 -0500 Received: (qmail 27625 invoked by uid 0); 12 Nov 2012 16:47:50 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.167) by 0 with ESMTPA; 12 Nov 2012 16:47:50 -0000 From: "Lee Howard" To: Date: Mon, 12 Nov 2012 11:47:50 -0500 Message-ID: <000001cdc0f5$73d21240$5b7636c0$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3A7//bAx8CKuJsTLKbbgC/GNLg2w== Content-Language: en-us Subject: [sunset4] review of sunset4-gap-analysis X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:47:55 -0000 I promised to review the document. I have not included proofreading notes (spelling, grammar, etc.) but I would be happy to do so. Abstract: "and identifies the gaps resulting in additional work" /resulting in/requiring Related work: the RFCs in this list are lists of RFCs requiring IPv4. Have the authors reviewed them to see whether any protocol work is required? The documents often point to works-in-progress as of 2004; has all of that work been completed? I am delighted to see that RFC1149 has no IPv4-specific requirements, and thus does not require updating. PROBLEM 1. I could argue that failure to find a DHCP server is a failure condition. It may not be a fatal error, but more specificity is needed here. What happens that's bad? How do you tell the difference between "The DHCP (IPv4) server is down" and "IPv4 is gone forever"? PROBLEM 2. Which DHCP messages do you mean? Do you mean in Advertise messages? Does a server send an Offer if it has no addresses? What about when there's no IPv4 on the WAN, but IPv4 is still needed for internal communication? PROBLEM 3. Separate problem descriptions are needed for home networks and enterprise networks. This document either needs to include a section on "How to know you IPv4 isn't needed any more" or needs to say explicitly, "The decision about when to turn off IPv4 is out of scope." Lee From wesley.george@twcable.com Mon Nov 12 11:19:23 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886E321F878B for ; Mon, 12 Nov 2012 11:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0jNc7JcvKM0 for ; Mon, 12 Nov 2012 11:19:23 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D434621F8788 for ; Mon, 12 Nov 2012 11:19:22 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="469319073" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2012 14:14:14 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 12 Nov 2012 14:14:22 -0500 From: "George, Wes" To: Lee Howard , "sunset4@ietf.org" Date: Mon, 12 Nov 2012 14:14:24 -0500 Thread-Topic: [sunset4] review of sunset4-gap-analysis Thread-Index: Ac3A7//bAx8CKuJsTLKbbgC/GNLg2wADNdKg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230337252B98@PRVPEXVS15.corp.twcable.com> References: <000001cdc0f5$73d21240$5b7636c0$@asgard.org> In-Reply-To: <000001cdc0f5$73d21240$5b7636c0$@asgard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sunset4] review of sunset4-gap-analysis X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:19:23 -0000 > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.org] On > Behalf Of Lee Howard > > Related work: the RFCs in this list are lists of RFCs requiring IPv4. > Have the authors reviewed them to see whether any protocol work is > required? [WEG] good point. However, I think the precursor would be to determine as a= WG how we decide whether protocol work is required beyond that which is ne= eded to trigger an IPv4 shutdown. Speaking as an individual, if I had to de= fine it, I'd say this is a question about feature parity between IPv4 and I= Pv6 - Identify IETF work (if any) where the standard is still relevant and = necessary in IPv6-only networks but is not suitably defined for IPv6-only o= peration and does not have an IPv6 equivalent. If there isn't any work that= fits into this category, it's useful to confirm that this analysis has bee= n performed as a part of our gap analysis. This would in essence confirm th= at there aren't outstanding IPv4/IPv6 feature parity issues at the protocol= or IETF level that would delay a move to IPv6-only. Related to this, I think it might be helpful to document IPv4-only features= and standards that have no IPv6 equivalent but are a non-issue due to the = fact that they are no longer in use or are obsoleted by different functiona= lity inherent to IPv6. That is, features that are not at parity in IPv6, bu= t no one cares. It would make for a more complete parity analysis. Looking at this from a WG chair's perspective, this is a different gap anal= ysis than the one focused on the mechanics of signaling to hosts, networks = and stacks that you're turning IPv4 off, and might be better off in a separ= ate document focused on answering the question of "can you actually turn IP= v4 off?" > > > This document either needs to include a section on "How to know you IPv4 > isn't needed any more" or needs to say explicitly, "The decision about > when to turn off IPv4 is out of scope." > [WEG] as an individual, my vote would be for the latter. Part of that same = discussion about how and when it's appropriate to shut off IPv4 came up in = my review of draft-lopez-v6ops-dc-v6, and it was quickly evident that one m= ust take great care to avoid being in a situation where your draft has to d= iscuss a very large number of different permutations to provide useful advi= ce at a specific enough level, but there may be a possibility to pick some = high-level categories such that you can provide more generically useful adv= ice in a few situations. I could see that being a follow-on draft, or perha= ps part of the protocol gap analysis you seem to be suggesting above. Thanks for the prompt response on your volunteered review! Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From lee@asgard.org Mon Nov 12 12:00:13 2012 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC93421F877F for ; Mon, 12 Nov 2012 12:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-5Y6QVBLL5t for ; Mon, 12 Nov 2012 12:00:07 -0800 (PST) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id BCB9521F841E for ; Mon, 12 Nov 2012 12:00:05 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qACK01Ku018813 for ; Mon, 12 Nov 2012 15:00:01 -0500 Received: (qmail 2449 invoked by uid 0); 12 Nov 2012 20:00:00 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.167) by 0 with ESMTPA; 12 Nov 2012 20:00:00 -0000 From: "Lee Howard" To: "George, Wes" , References: <000001cdc0f5$73d21240$5b7636c0$@asgard.org> <2671C6CDFBB59E47B64C10B3E0BD59230337252B98@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230337252B98@PRVPEXVS15.corp.twcable.com> Date: Mon, 12 Nov 2012 14:59:59 -0500 Message-ID: <000101cdc110$4c5dddf0$e51999d0$@asgard.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01CDC0E6.63962DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQILGla+lgpfZmbBr+PQew4UxxQesQNuF9/dl1B4I4A= Content-Language: en-us Subject: Re: [sunset4] review of sunset4-gap-analysis X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:00:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0002_01CDC0E6.63962DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: George, Wes [mailto:wesley.george@twcable.com] > Sent: Monday, November 12, 2012 2:14 PM > To: Lee Howard; sunset4@ietf.org > Subject: RE: [sunset4] review of sunset4-gap-analysis > > > > From: sunset4-bounces@ietf.org [ mailto:sunset4-bounces@ietf.org] On > > Behalf Of Lee Howard > > > > Related work: the RFCs in this list are lists of RFCs requiring IPv4. > > Have the authors reviewed them to see whether any protocol work is > > required? > [WEG] good point. However, I think the precursor would be to determine as a WG how we > decide whether protocol work is required beyond that which is needed to trigger an IPv4 > shutdown. Speaking as an individual, if I had to define it, I'd say this is a question about > feature parity between IPv4 and IPv6 - Identify IETF work (if any) where the standard is > still relevant and necessary in IPv6-only networks but is not suitably defined for IPv6-only > operation and does not have an IPv6 equivalent. If there isn't any work that fits into this > category, it's useful to confirm that this analysis has been performed as a part of our gap > analysis. This would in essence confirm that there aren't outstanding IPv4/IPv6 feature parity > issues at the protocol or IETF level that would delay a move to IPv6-only. > Related to this, I think it might be helpful to document IPv4-only features and standards that > have no IPv6 equivalent but are a non-issue due to the fact that they are no longer in use or > are obsoleted by different functionality inherent to IPv6. That is, features that are not at > parity in IPv6, but no one cares. It would make for a more complete parity analysis. The RFCs listed as Section 2 of -gapanalysis do most of this: [RFC3789 ], [RFC3790 ],[RFC3791 ], [RFC3792 ], [RFC3793 ], [RFC3794 ], [RFC3795 ] and [RFC3796 ] RFC3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents RFC3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents RFC3791 . IETF Routing Area Standards Track and Experimental Documents RFC3792 . IETF Security Area Standards Track and Experimental Documents RFC3793 . IETF Sub-IP Area Standards Track and Experimental Documents RFC3794 . IETF Transport Area Standards Track and Experimental Documents RFC3795 . IETF Application Area Standards Track and Experimental Documents RFC3796 . IETF Operations & Management Area Standards Track and Experimental Documents The summary section of each of these documents says, "Nobody cares about these specs anymore" or "There is an active draft [name] to fix this." We should follow up to make sure all of the then-active drafts were published. We may also need to undertake a similar review of documents published since these RFCs. > > Looking at this from a WG chair's perspective, this is a different gap analysis than the one > focused on the mechanics of signaling to hosts, networks and stacks that you're turning IPv4 > off, and might be better off in a separate document focused on answering the question of > "can you actually turn IPv4 off?" Gaps is gaps. I would not like to call gap analysis complete until we know about required protocol updates. > > This document either needs to include a section on "How to know you > > IPv4 isn't needed any more" or needs to say explicitly, "The decision > > about when to turn off IPv4 is out of scope." > > > [WEG] as an individual, my vote would be for the latter. Part of that same discussion about > how and when it's appropriate to shut off IPv4 came up in my review of draft-lopez-v6ops- > dc-v6, and it was quickly evident that one must take great care to avoid being in a situation > where your draft has to discuss a very large number of different permutations to provide > useful advice at a specific enough level, but there may be a possibility to pick some high- > level categories such that you can provide more generically useful advice in a few situations. > I could see that being a follow-on draft, or perhaps part of the protocol gap analysis you > seem to be suggesting above. Reasonable. > > Thanks for the prompt response on your volunteered review! I get to check it off my list now. J Lee ------=_NextPart_000_0002_01CDC0E6.63962DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

> -----Original Message-----

> From: George, Wes = [mailto:wesley.george@twcable.com]

> Sent: = Monday, November 12, 2012 2:14 PM

> To: = Lee Howard; sunset4@ietf.org

> Subject: = RE: [sunset4] review of sunset4-gap-analysis

>

>

> > From: sunset4-bounces@ietf.org [mailto:sunset4-bounces@ietf.or= g] On

> > Behalf Of Lee = Howard

> >

> > Related work: the RFCs in this list are = lists of RFCs requiring IPv4.

> > Have = the authors reviewed them to see whether any protocol work is

> > required?

> = [WEG] good point. However, I think the precursor would be to determine = as a WG how we

> decide whether protocol = work is required beyond that which is needed to trigger an IPv4

> shutdown. Speaking as an individual, if I had = to define it, I'd say this is a question about

> feature parity between IPv4 and IPv6 - = Identify IETF work (if any) where the standard is

> still relevant and necessary in IPv6-only = networks but is not suitably defined for IPv6-only

> operation and does not have an IPv6 = equivalent. If there isn't any work that fits into this

> category, it's useful to confirm that this = analysis has been performed as a part of our gap

> analysis. This would in essence confirm that = there aren't outstanding IPv4/IPv6 feature parity

> issues at the protocol or IETF level that = would delay a move to IPv6-only.

> Related = to this, I think it might be helpful to document IPv4-only features and = standards that

> have no IPv6 equivalent = but are a non-issue due to the fact that they are no longer in use = or

> are obsoleted by different = functionality inherent to IPv6. That is, features that are not at

> parity in IPv6, but no one cares. It would = make for a more complete parity analysis.

 

The RFCs listed as = Section 2 of -gapanalysis do most of = this:

   [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794],
   [RFC3795] and [RFC3796]

 

 

RFC3789 =   Introduction to the Survey of IPv4 Addresses in Currently = Deployed IETF Standards Track and Experimental = Documents

RFC3790  Survey of IPv4 Addresses in = Currently Deployed IETF Internet Area Standards Track and Experimental = Documents

RFC3791 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;      … IETF Routing Area Standards = Track and Experimental Documents

RFC3792  =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;     … IETF Security Area Standards Track and = Experimental Documents

RFC3793 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;      … IETF Sub-IP Area Standards Track = and Experimental Documents

RFC3794 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;      … IETF Transport Area Standards = Track and Experimental Documents

RFC3795 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;      … IETF Application Area Standards = Track and Experimental Documents

RFC3796 =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;      … IETF Operations & Management = Area Standards Track and Experimental Documents

 

The summary section of = each of these documents says, “Nobody cares about these specs = anymore” or “There is an active draft [name] to fix = this.”

We should follow up to make sure all of the = then-active drafts were published.

We may also need to = undertake a similar review of documents published since these = RFCs.

 

>

> Looking at = this from a WG chair's perspective, this is a different gap analysis = than the one

> focused on the mechanics of = signaling to hosts, networks and stacks that you're turning IPv4

> off, and might be better off in a separate = document focused on answering the question of

> "can you actually turn IPv4 = off?"

 

Gaps is = gaps.

I would not like to call gap analysis complete = until we know about required protocol updates.

 

> > This document either needs to include a = section on "How to know you

> > = IPv4 isn't needed any more" or needs to say explicitly, "The = decision

> > about when to turn off = IPv4 is out of scope."

> >

> [WEG] as an individual, my vote would be for = the latter. Part of that same discussion about

> how and when it's appropriate to shut off IPv4 = came up in my review of draft-lopez-v6ops-

> dc-v6, and it was quickly evident that one = must take great care to avoid being in a situation

> where your draft has to discuss a very large = number of different permutations to provide

> useful advice at a specific enough level, but = there may be a possibility to pick some high-

> level categories such that you can provide = more generically useful advice in a few situations.

> I could see that being a follow-on draft, or = perhaps part of the protocol gap analysis you

> seem to be suggesting above.

 

Reasonable.

 

>

> Thanks for = the prompt response on your volunteered review!

 

I get to check it off my list now.  = J

 

 

Lee

 

------=_NextPart_000_0002_01CDC0E6.63962DD0--