From nobody Mon Oct 2 08:16:47 2017 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 C7A47134695; Mon, 2 Oct 2017 08:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qPXTjympEzLx; Mon, 2 Oct 2017 08:16:33 -0700 (PDT) Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 086B2134698; Mon, 2 Oct 2017 08:16:33 -0700 (PDT) X-Virus-Scanned: by SpamTitan at corp.cira.ca Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-01.CORP.CIRA.CA (10.2.36.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 2 Oct 2017 11:16:32 -0400 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7%13]) with mapi id 15.01.0669.032; Mon, 2 Oct 2017 11:16:32 -0400 From: Jacques Latour To: Brian E Carpenter , "ietf@ietf.org" CC: "sunset4-chairs@ietf.org" , "draft-ietf-sunset4-ipv6-ietf@ietf.org" , "sunset4@ietf.org" , "terry.manderson@icann.org" Thread-Topic: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard Thread-Index: AQHTOF1pn5qyxftS8UmTkR4t+24ZWKLM7q2AgAO/tDA= Date: Mon, 2 Oct 2017 15:16:32 +0000 Message-ID: <7a3da040aff04fd4a11126e9cc70c6d6@cira.ca> References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.4.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 15:16:35 -0000 I think we need to be very specific to mention where the focus is applied, = either in on the global Internet or on the Network {internal, home, corpora= te}. Saying we're shutting down IPv4 scares a lot of people but that's not in sc= ope because on the Network (internally) come to mind right away. The focus = is on the Internet. Abstract =20 The IETF has stopped working on IPv4 protocol only solutions that are spe= cific to global Internet. The IETF has stopped working on IPv4 protocol solutions except where need= ed to mitigate documented security issues. The IETF has not stopped working on IPv4 protocol solutions to facilitate= the transition to IPv6, or to enable IPv4 decommissioning on the global In= ternet. The IETF has no 'plans' to decommission the IPv4 protocol on the Network = {internal, home, corporate}. From nobody Wed Oct 4 05:38:52 2017 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 6BAC21323B8; Wed, 4 Oct 2017 05:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 gW7j4DVEHR4e; Wed, 4 Oct 2017 05:38:49 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 83126126BF0; Wed, 4 Oct 2017 05:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=O1mWDqtXBm2H5XELed1Kli2+Z4w9tWha0VlVYdx74zU=; b=fW1PsMT+Hmw+vY5Fjdn9wGPTs BGsbn847hnZnOjSWBo385EWKT2XM0R8sDg6CSjSRyyJEYcdAeXcRKKfd64k0wgJqa2AFxCs2WnkAS JyTHCAYdbgc/u+jrXdTG0Ec3IENtRLxTHj78gtcCFLP7SCYWCCjWpX4esvD1fmJ9uudyMMmGA+fAK tBJDHLmfLUytOlT0QNdBoQ+YEVwV/X0VB5wZnSZBmRghC02Bd3EVufur2J7nBkYLxKUk3j+kn0hz+ mEXPyVgx/bcrhOgqscprjwxY+lyWIy8UiCCBEE2EgBDGj4lL3uSot9v+cegcjSd52pLvMFdhJxJDb CoUdDk6lQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50961 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dziwq-002oHl-9w; Wed, 04 Oct 2017 08:38:49 -0400 To: Brian E Carpenter , ietf@ietf.org Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> From: Joe Touch Message-ID: <0766e92f-9b1d-d59e-5395-8c05c745f3b1@strayalpha.com> Date: Wed, 4 Oct 2017 05:38:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E37E4A2353D21693C84991CF" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 12:38:50 -0000 This is a multi-part message in MIME format. --------------E37E4A2353D21693C84991CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/29/2017 6:48 PM, Brian E Carpenter wrote: > First of all, I agree with those who have said this should be > a BCP, if published. BCPs are the way we publish IETF process > rules. A BCP with the right tone and focus might be useful. > Secondly, I think many of the comments about the tone and slant > are correct. What we want to stop is work on solutions that > are *specific* to IPv4, and to chase down and elminate any > cases where successful IPv6 operation depends on the presence > of IPv4. I disagree. We need to consider IPv4 work as "maintenance mode", which can easily include solo IPv4 adjustments and/or include IPv4 support in new protocols that also support IPv6. Neither necessarily need involve transition or deprecation. "no new work" or "no IPv4-specific work" both assume that IPv6 is a superset of IPv4, which it is not. We're still wrangling with aspects of IPv6 that actually are evolving back into IPv4-like approaches, e.g., limits to the length of the header chain and problems supporting fragment traversal of routers. Joe --------------E37E4A2353D21693C84991CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 9/29/2017 6:48 PM, Brian E Carpenter wrote:
First of all, I agree with those who have said this should be
a BCP, if published. BCPs are the way we publish IETF process
rules.
A BCP with the right tone and focus might be useful.

Secondly, I think many of the comments about the tone and slant
are correct. What we want to stop is work on solutions that
are *specific* to IPv4, and to chase down and elminate any
cases where successful IPv6 operation depends on the presence
of IPv4.

I disagree.

We need to consider IPv4 work as "maintenance mode", which can easily include solo IPv4 adjustments and/or include IPv4 support in new protocols that also support IPv6. Neither necessarily need involve transition or deprecation.

"no new work" or "no IPv4-specific work" both assume that IPv6 is a superset of IPv4, which it is not. We're still wrangling with aspects of IPv6 that actually are evolving back into IPv4-like approaches, e.g., limits to the length of the header chain and problems supporting fragment traversal of routers.

Joe

--------------E37E4A2353D21693C84991CF-- From nobody Wed Oct 4 15:18:04 2017 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 68782132F3F; Wed, 4 Oct 2017 15:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YljS36evm9f7; Wed, 4 Oct 2017 15:18:01 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E57F120724; Wed, 4 Oct 2017 15:18:01 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id m63so6961251pfk.7; Wed, 04 Oct 2017 15:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YV1Pq15Zzv8DIN9D+OYssBH9PX6ZqgcJ5JdgQ/Eix7k=; b=ebHFl3Gm56iHCeimmAJUbhmYd29/o0hx2MkFgxySHyNilysMRgMsTgavZW2TXi1i5F wa1lHoKvyEq1YXy34Cyfvq3DszJVJZgLuhVU507muQ4I0cHm5+6DMjrkFSYrvp/Oa9Ml WdTg3pYmrkl9vfVL5jPRKDS4lzSqJtjPz6p4/ahLdScrhB+xkcMdPo3wj4nyM4qgiT+6 zcN7QLyMgiHl2U+AKHz3Ej7xxo46LSlLWI8ia4gjDgLzk+qnMyO88ZXk0EHODCzVEfUZ XGnJ8ftnt1Xa3dDm7KewtT6LkZVzmAFh1wFtH0a+fRWvQq5basFndMA/AFqIDNJru4vM X2sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YV1Pq15Zzv8DIN9D+OYssBH9PX6ZqgcJ5JdgQ/Eix7k=; b=XXIA/0p9OQVclWmmrdNR6L6dtAvWLavXGyWUUQFTPMLmiWGp/uXXyNct+mqlrzE2nY txstN/mb8gOLIxO1tQAun4WCJhcLgghr0yMzJXubeCY0PLk/oGRb2OJWy8oXb42TYSM3 +maI/3NifhNfVpbQcMZe9DOj5hZ4AIwc4FjlvTfZ1G2G7I1a/EHW3NIqeFcyjlJVC9DM jRQVgyg1vsl3QNni7lGZ5qR+f+zhS6hvvlhuY2fcxG990KnmV0q1lV69JfbdWWlMvVFD lmcQawLrtmhKs8PuqIOxfVd8lOCDHxqMsRstG2CHz4J9muvzRJz51KrRVYstIc0FeYlo mIxQ== X-Gm-Message-State: AHPjjUiCrKUiICaxmfPeQT7ceENRB8/GebTxxo8Ti3amM/F6/8FTMRr9 Yzq9ae3xo8hh6nK/PoGVvmpnUg== X-Google-Smtp-Source: AOwi7QCTqMXfxS8pXMwYwgnwOcK9JImhbtWFntXyXs5GVZ3zhg2R82vLqxo+lFe2on7A2frEkH/CMQ== X-Received: by 10.84.129.106 with SMTP id 97mr20787277plb.268.1507155480775; Wed, 04 Oct 2017 15:18:00 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j67sm18033616pfj.1.2017.10.04.15.17.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 15:17:59 -0700 (PDT) To: Joe Touch , ietf@ietf.org Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> <0766e92f-9b1d-d59e-5395-8c05c745f3b1@strayalpha.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 5 Oct 2017 11:18:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0766e92f-9b1d-d59e-5395-8c05c745f3b1@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:18:03 -0000 On 05/10/2017 01:38, Joe Touch wrote: > > > On 9/29/2017 6:48 PM, Brian E Carpenter wrote: >> First of all, I agree with those who have said this should be >> a BCP, if published. BCPs are the way we publish IETF process >> rules. > A BCP with the right tone and focus might be useful. > >> Secondly, I think many of the comments about the tone and slant >> are correct. What we want to stop is work on solutions that >> are *specific* to IPv4, and to chase down and elminate any >> cases where successful IPv6 operation depends on the presence >> of IPv4. > > I disagree. > > We need to consider IPv4 work as "maintenance mode", which can easily > include solo IPv4 adjustments and/or include IPv4 support in new > protocols that also support IPv6. Neither necessarily need involve > transition or deprecation. I'm not sure that we disagree modulo wordsmithing. Saying that IPv4 is in maintenance mode is fine. Security and bug fixes are clearly maintenance. > "no new work" or "no IPv4-specific work" both assume that IPv6 is a > superset of IPv4, which it is not. I don't see that assumption either stated or implied. If there are features missing in IPv6, that's a completely separate topic. > We're still wrangling with aspects of > IPv6 that actually are evolving back into IPv4-like approaches, e.g., > limits to the length of the header chain and problems supporting > fragment traversal of routers. I don't see what that has to do with the draft under discussion. Regards Brian From nobody Thu Oct 5 05:32:03 2017 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 A569B13454B; Thu, 5 Oct 2017 05:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 B_AjJ1V7lkQM; Thu, 5 Oct 2017 05:31:43 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DEC8E134561; Thu, 5 Oct 2017 05:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aE+uJpLyGTn+46oh07QNE+Q/4W+vS5dKeXN5/1Gkw4Y=; b=caJ8T83mYGuZ81XP18ODBmORE SWRZPkA86PPEhULK1isskjRa4lFFO10WaPvxSfHc/ik6FAfx6yJ4tBXAyB5RuQWiV4WK+thGoiI1I YfCOpZIYYvh34HGgVTuTCFklvD8PPexk1Aj/vqCQyNEUT8ZiqSkMPj8sK01ctI7braA5HSk1gD0SK NNnSJLoOvQXVbTsUzBlD663w9tx+M6B46vdTIU+RnKdbfRgTSobwfdiu5YqSrlpQd/or9QhboYxUn M2Zqul/x6kcVYUabaZikF7fd/eSCqSaZpzbgt/brAyEYetT0/tALG0LSlHZ4+g6VAS1Gj/s0a+GYn lhARgC6iQ==; Received: from rrcs-173-197-223-73.west.biz.rr.com ([173.197.223.73]:50651 helo=[172.20.0.242]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e05I9-002UFv-NE; Thu, 05 Oct 2017 08:30:23 -0400 To: Brian E Carpenter , ietf@ietf.org Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> <0766e92f-9b1d-d59e-5395-8c05c745f3b1@strayalpha.com> From: Joe Touch Message-ID: <38d1a91a-a303-d7fd-1a4a-7e7106d4fa3e@strayalpha.com> Date: Thu, 5 Oct 2017 05:30:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7F54FA1D0B9387FA2A3E4630" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 12:31:48 -0000 This is a multi-part message in MIME format. --------------7F54FA1D0B9387FA2A3E4630 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/4/2017 3:18 PM, Brian E Carpenter wrote: >> "no new work" or "no IPv4-specific work" both assume that IPv6 is a >> superset of IPv4, which it is not. > I don't see that assumption either stated or implied. If there are > features missing in IPv6, that's a completely separate topic. I was arguing against new wording that might use the quotes above. IMO, the current doc is even more restrictive. > >> We're still wrangling with aspects of >> IPv6 that actually are evolving back into IPv4-like approaches, e.g., >> limits to the length of the header chain and problems supporting >> fragment traversal of routers. > I don't see what that has to do with the draft under discussion. It was intended as an example of how IPv6 is not a superset of IPv4. Joe --------------7F54FA1D0B9387FA2A3E4630 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 10/4/2017 3:18 PM, Brian E Carpenter wrote:
"no new work" or "no IPv4-specific work" both assume that IPv6 is a
superset of IPv4, which it is not.

I don't see that assumption either stated or implied. If there are
features missing in IPv6, that's a completely separate topic.
I was arguing against new wording that might use the quotes above. IMO, the current doc is even more restrictive.


We're still wrangling with aspects of
IPv6 that actually are evolving back into IPv4-like approaches, e.g.,
limits to the length of the header chain and problems supporting
fragment traversal of routers.

I don't see what that has to do with the draft under discussion.

It was intended as an example of how IPv6 is not a superset of IPv4.

Joe
--------------7F54FA1D0B9387FA2A3E4630-- From nobody Sun Oct 8 08:52:02 2017 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 575411346B8; Sun, 8 Oct 2017 08:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=Evcy5nBq; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=znC+/fR4 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 WKn1TYaYC4hW; Sun, 8 Oct 2017 08:51:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7228C1346C5; Sun, 8 Oct 2017 08:51:58 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.227.87.111]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v98FpdEJ000890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Oct 2017 08:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1507477911; x=1507564311; bh=BDNZe9ivW9pdPLI4FE7Mp+dEENu3WFHLjIlues72NVk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Evcy5nBqTPkVywkbLzam2ZB2R09hqhtBkdHS0QBPNTL2cHqmWxEjLz7JneJYWQTSg qzEsQKniBFZiygw305w/oYebxGi0lGXTLF5UNb1qAcdpcJVLDmxVNrAg1BZFjMbpYb e6MPVfREJe7wAqHcgLOn4X/OaTbCS5IKQWvs7Oes= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1507477911; x=1507564311; i=@elandsys.com; bh=BDNZe9ivW9pdPLI4FE7Mp+dEENu3WFHLjIlues72NVk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=znC+/fR4J5uXdK+nBN6EZm1oA2DeHsetiencptabiEo0Z8CLzf2VH0UVBstjLE7Iv oHQoh2w4y7OcoozMr/jOuq+3+yPpXF+/gPTud5BhWkHKJ2lRZPKoMUiQlczVdg2I/N VALfW/zbD+gJRv7EywmNT+gUBChijiz+hEae/5pw= Message-Id: <6.2.5.6.2.20171008080321.0f8ded68@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Oct 2017 08:43:11 -0700 To: ietf@ietf.org From: S Moonesamy Cc: sunset4@ietf.org, Lee Howard In-Reply-To: <150660518277.13796.5801483741214576151.idtracker@ietfa.ams l.com> References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 15:52:00 -0000 Hello, I'll disclose that there is a potential conflict of interest and I am involved in a RIR [1]. At 06:26 AM 28-09-2017, The IESG wrote: >The IESG has received a request from the Sunsetting IPv4 WG (sunset4) to >consider the following document: - 'IETF: End Work on IPv4' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits final >comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2017-10-12. Exceptionally, comments may be I read this short draft and the document shepherd write-up. The explanation about why the document should be published as a "Proposed Standard" is that "it creates key implications on all future standards track documents". Is that what the "Proposed Standard" label is about? There is the following in Section 1: "Until the time when IPv4 is no longer inwide use and/or declared historic ..." It is unrealistic to envision a near future where the IETF would "declare" IPv4 as "Historic". I'll commend the author for not overloading the "must" in this draft. Is this document about the IETF not doing any more work on IPv4-related technologies unless there is a security issue to fix and there is consensus [2] to do that? Regards, S. Moonesamy 1. Please do not read the disclosure as a statement from the RIR. My interest predates the RIR involvement. 2. Please see Section 2 of the draft.