From nobody Tue Sep 12 10:18:57 2017 Return-Path: X-Original-To: sunset4@ietf.org Delivered-To: sunset4@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D051330AD; Tue, 12 Sep 2017 10:18:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, sunset4@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150523673628.17987.7033238355130325081@ietfa.amsl.com> Date: Tue, 12 Sep 2017 10:18:56 -0700 Archived-At: Subject: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 17:18:56 -0000 Dear Will (Shucheng) LIU, Weiping Xu, Cathy Zhou, Tina Tsou, Simon Perreault, Peng Fan, Rong Gu, Chongfeng Xie, Ying Cheng: An IPR disclosure that pertains to your Internet-Draft entitled "Gap Analysis for IPv4 Sunset" (draft-ietf-sunset4-gapanalysis) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3064/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis" Thank you IETF Secretariat From nobody Tue Sep 12 12:12: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 E87AC1330BA for ; Tue, 12 Sep 2017 12:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 u5FXuvW4oWvi for ; Tue, 12 Sep 2017 12:12:49 -0700 (PDT) Received: from atl4mhob16.registeredsite.com (atl4mhob16.registeredsite.com [209.17.115.109]) (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 781721330B8 for ; Tue, 12 Sep 2017 12:12:49 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8CJCkw0038309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Sep 2017 15:12:46 -0400 Received: (qmail 10535 invoked by uid 0); 12 Sep 2017 19:12:46 -0000 X-TCPREMOTEIP: 72.221.14.181 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.181) by 0 with ESMTPA; 12 Sep 2017 19:12:46 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Tue, 12 Sep 2017 15:12:42 -0400 From: Lee Howard To: , CC: , Message-ID: Thread-Topic: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis References: <150523673628.17987.7033238355130325081@ietfa.amsl.com> In-Reply-To: <150523673628.17987.7033238355130325081@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis 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: Tue, 12 Sep 2017 19:12:51 -0000 I appreciate this disclosure being filed. Can anyone tell me how to find out more about the disclosed IPR, such as its title, or what it=E2=80=99s about? Thanks, Lee On 9/12/17, 1:18 PM, "sunset4 on behalf of IETF Secretariat" wrote: >Dear Will (Shucheng) LIU, Weiping Xu, Cathy Zhou, Tina Tsou, Simon >Perreault, Peng Fan, Rong Gu, Chongfeng Xie, Ying Cheng: > > >An IPR disclosure that pertains to your Internet-Draft entitled "Gap >Analysis for IPv4 Sunset" (draft-ietf-sunset4-gapanalysis) was submitted >to the IETF Secretariat on and has been posted on the "IETF Page of >Intellectual Property Rights Disclosures" >(https://datatracker.ietf.org/ipr/3064/). The title of the IPR disclosure >is >"Huawei Technologies Co.,Ltd's Statement about IPR related to >draft-ietf-sunset4-gapanalysis" > > >Thank you > >IETF Secretariat > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 > From nobody Tue Sep 12 12:21:40 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 19C37132EBE for ; Tue, 12 Sep 2017 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 GppqfdHaS918 for ; Tue, 12 Sep 2017 12:21:36 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 59E02132D91 for ; Tue, 12 Sep 2017 12:21:36 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id t46so4064824qtj.2 for ; Tue, 12 Sep 2017 12:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Zbwtxr2M2KZU7rEkeL8Hys4FgHxzS38swHTSjIlV9ao=; b=QMf0+8gtAs7MvVMb2NtcpD5d73ybmxItwn+3HLfub+kNGM+voPaevxuayGiW+s3Hc5 p5GAHziTiHs1e845a5WHv6KfeAgXfIZZ9tYEOTWg/T4rI4DigyH/1mwxf7wHEJD4uerH 43fUkXO9DqjufKzC5IHZ06y9DGgQ8u36d4z/p5pbi3h5uULUjleK56cnl3sqU5ba5dJK q+AxbYptQyMbfEleRDYHphdJLZyn541qcKbdU1o2ZWxygzNH7dh/05TvE39gkRQ4i/PP Q3jez7Bn72TxUQcnNCWNzY1Yeho4DcynO+rHkpInihgAW3H3b55dxAWvYJHl1LpuT04Z Grig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Zbwtxr2M2KZU7rEkeL8Hys4FgHxzS38swHTSjIlV9ao=; b=gFDIVWHrEvhNU+Nr/LvuhpJOFmtZTuDElyFgqc+u6J+cXX12gFM19Q7H9b50tw/A8e 74fB21I0lPs6rGnA2EUZxpLZd3vTvpAqEHe8W2IUQYqVueaAIq9aaqEXqD0oESKAsL9k vXnSHiMHPpLfMnl8vEcbChWcjaTHyrVwlIBSRy4EfVaUuhOTOJhKNcDGTKjqIVG15CwN gqx/BCdhbQwwo9PqLa5TojbeZUnMXwMyHliEbU70FqNbVsvXkQy+W4Ktzag91QuNPPYU 47VgvDg4S9pH2hNgVriOt2NQAFJDVnl9Bpy5lGciJ63O6Oc77foU/iZfcybl54M2kipn 31+A== X-Gm-Message-State: AHPjjUinRiHLyWZKI3zV08BOFeqSdZjb7AnnmnUKR0E8rzrhNrUzeMZZ htjHOIRlvmmUAJ9A X-Google-Smtp-Source: AOwi7QDRp8tr9c8ciU1VVRiltkX8v0PDhyrgWj6vESd9nrGShNOxgQgSHV4RW5YfbalzG4qZoPEDQg== X-Received: by 10.200.18.70 with SMTP id g6mr23337248qtj.87.1505244095532; Tue, 12 Sep 2017 12:21:35 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id s7sm7982032qkf.4.2017.09.12.12.21.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 12:21:34 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_41DA23DE-6232-478B-A3E4-E2D27E7A9396" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 12 Sep 2017 15:21:32 -0400 In-Reply-To: Cc: draft-ietf-sunset4-gapanalysis@ietf.org, licensing@huawei.com, ipr-announce@ietf.org, sunset4@ietf.org To: Lee Howard References: <150523673628.17987.7033238355130325081@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis 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: Tue, 12 Sep 2017 19:21:39 -0000 --Apple-Mail=_41DA23DE-6232-478B-A3E4-E2D27E7A9396 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 12, 2017, at 3:12 PM, Lee Howard wrote: > I appreciate this disclosure being filed. Can anyone tell me how to = find > out more about the disclosed IPR, such as its title, or what it=E2=80=99= s about? They appear to have patented anything that does roughly what a DHCP = server does. If you google the patent number, you can read the patent, = but good luck figuring out what it means. --Apple-Mail=_41DA23DE-6232-478B-A3E4-E2D27E7A9396 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 12, 2017, at 3:12 PM, Lee Howard <lee@asgard.org> = wrote:
I appreciate this = disclosure being filed. Can anyone tell me how to find
out more about the disclosed IPR, such as its = title, or what it=E2=80=99s about?

They = appear to have patented anything that does roughly what a DHCP server = does.   If you google the patent number, you can read the patent, = but good luck figuring out what it means.

= --Apple-Mail=_41DA23DE-6232-478B-A3E4-E2D27E7A9396-- From nobody Tue Sep 12 13:08:09 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 F341E1330C9 for ; Tue, 12 Sep 2017 13:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 hx_bSheTOMuE for ; Tue, 12 Sep 2017 13:08:05 -0700 (PDT) Received: from atl4mhob19.registeredsite.com (atl4mhob19.registeredsite.com [209.17.115.112]) (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 50EE0132F2F for ; Tue, 12 Sep 2017 13:08:05 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8CK814E013083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Sep 2017 16:08:02 -0400 Received: (qmail 28463 invoked by uid 0); 12 Sep 2017 20:08:01 -0000 X-TCPREMOTEIP: 72.221.14.181 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.181) by 0 with ESMTPA; 12 Sep 2017 20:08:01 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Tue, 12 Sep 2017 16:07:56 -0400 From: Lee Howard To: Ted Lemon CC: , Message-ID: Thread-Topic: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis References: <150523673628.17987.7033238355130325081@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3588077281_13329810" Archived-At: Subject: Re: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis 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: Tue, 12 Sep 2017 20:08:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3588077281_13329810 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Ah, after clicking an unpromising link, I now discover that "CN 201510697563=E2=80=9D (as listed in the IPR disclosure) is the application number= , and "CN106612196 A=E2=80=9D is the publication number, also published as WO2017067464 A1. And now I find that translation is available, https://encrypted.google.com/patents/CN106612196A?cl=3Den Which suggests that a client may request resources. So I wonder if this is related to on-demand IP provisioning? Lee From: sunset4 on behalf of Ted Lemon Date: Tuesday, September 12, 2017 at 3:21 PM To: Lee Howard Cc: , , , Subject: Re: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis > On Sep 12, 2017, at 3:12 PM, Lee Howard wrote: >> I appreciate this disclosure being filed. Can anyone tell me how to find >> out more about the disclosed IPR, such as its title, or what it=E2=80=99s abou= t? >=20 > They appear to have patented anything that does roughly what a DHCP serve= r > does. If you google the patent number, you can read the patent, but goo= d > luck figuring out what it means. >=20 > _______________________________________________ sunset4 mailing list > sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 --B_3588077281_13329810 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Ah, after clicking an unpromising link= , I now discover that "CN 201510697563” (as listed in the IPR disclosu= re) is the application number, and "CN106612196 A” is the publication = number, also published as WO2017067464 A1.

And now = I find that translation is available, https://encrypted.google.com/patents/CN1066= 12196A?cl=3Den
Which suggests that a client may request resource= s. So I wonder if this is related to on-demand IP provisioning?
Lee



From: sunset4 <sunset4-bounces@ietf.org> on behalf of Ted Lemon <mellon@fugue.com>
Date: Tuesday, September 12, 2017 at 3:21 PM
To: Lee Howard <lee@asgard.org>
Cc: &= lt;sunset4@ietf.org>, <draft-ietf-sunset4-gapanalys= is@ietf.org>, <licensing@hua= wei.com>, <ipr-announce@iet= f.org>
Subject: Re: [sunset= 4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related= to draft-ietf-sunset4-gapanalysis

On Sep 12, 2017, = at 3:12 PM, Lee Howard <lee@asga= rd.org> wrote:
I appreciate this disclosure being filed. Can anyon= e tell me how to find
out more about the disclosed IPR, s= uch as its title, or what it’s about?

They appear to have patented anything that does roughly what a DH= CP server does.   If you google the patent number, you can read the pat= ent, but good luck figuring out what it means.

_______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.or= g/mailman/listinfo/sunset4
--B_3588077281_13329810-- From nobody Tue Sep 12 21:24:00 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 C92D3133A69 for ; Tue, 12 Sep 2017 21:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 lS_5zMlJ-ZfB for ; Tue, 12 Sep 2017 21:23:53 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 5AE06132964 for ; Tue, 12 Sep 2017 21:23:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 05CDCB2; Wed, 13 Sep 2017 06:23:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1505276629; bh=0z75h1Le1pVWTzBFLFChUuUdkVrwzhN4BjTCjRunHiY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WVCBwZhXHlUMmTsWo/tnogF93QaYQnG3TT8yRZ+zTlALW1gWK0joc6dw4R9ZTN2p4 l2E7kcRWim7wSAY/4oZtSwitB9C4tyxDRx06dBpkmjvx65kYY03O+si4eJQqjR8pPN soWfUgKfmKBbpChxGuNSLQ2iGEubqRAkcAqmhwW0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 00C48B1; Wed, 13 Sep 2017 06:23:48 +0200 (CEST) Date: Wed, 13 Sep 2017 06:23:48 +0200 (CEST) From: Mikael Abrahamsson To: Lee Howard cc: Ted Lemon , sunset4@ietf.org In-Reply-To: Message-ID: References: <150523673628.17987.7033238355130325081@ietfa.amsl.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [sunset4] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-sunset4-gapanalysis 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, 13 Sep 2017 04:23:56 -0000 On Tue, 12 Sep 2017, Lee Howard wrote: > And now I find that translation is available, > https://encrypted.google.com/patents/CN106612196A?cl=en Which suggests > that a client may request resources. So I wonder if this is related to > on-demand IP provisioning? A quick read through (I hate "patent code") seems to indicate that this patents basically "DHCP but over NETCONF/RESTCONF", where one use-case is NFV provisioning (over NETCONF) based on this interaction to provision the needed resource. "NETCONF protocol is the Internet Engineering Task Force (Internet Engineering Task Force, IETF) NETCONF working group launched a new network configuration protocol (Network Configuration Protocol), NETC0NF in the role of network management similar to the simple network management protocol (Simple Network Management Protocol, SNMP) for network interface and data transmission between devices. In a network environment, the resource manager is used to centrally manage multiple resources of network devices, such as Internet Protocol (IP) address pools and forwarding entries. The NETCONF protocol is used between the resource manager and the network device. The resource manager can allocate resources to the network device based on the NETCONF protocol. The current allocation of resources there is a waste of resources." -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 18 08:17:25 2017 Return-Path: X-Original-To: sunset4@ietf.org Delivered-To: sunset4@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB691342A7; Mon, 18 Sep 2017 08:17:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sunset4@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150574783875.15628.14503467692827714207@ietfa.amsl.com> Date: Mon, 18 Sep 2017 08:17:18 -0700 Archived-At: Subject: [sunset4] I-D Action: draft-ietf-sunset4-ipv6-ietf-01.txt X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 15:17:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sunsetting IPv4 WG of the IETF. Title : IETF: End Work on IPv4 Author : Lee Howard Filename : draft-ietf-sunset4-ipv6-ietf-01.txt Pages : 3 Date : 2017-09-18 Abstract: The IETF will stop working on IPv4, except where needed to mitigate documented security issues, to facilitate the transition to IPv6, or to enable IPv4 decommissioning. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01 https://datatracker.ietf.org/doc/html/draft-ietf-sunset4-ipv6-ietf-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sunset4-ipv6-ietf-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 19 05:06:33 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 BF4681321C7 for ; Tue, 19 Sep 2017 05:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hJW48wYjSCy7 for ; Tue, 19 Sep 2017 05:06:31 -0700 (PDT) Received: from cheri.viagenie.ca (cheri.viagenie.ca [IPv6:2620:0:230:8000::48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AAF913421C for ; Tue, 19 Sep 2017 05:06:28 -0700 (PDT) Received: by cheri.viagenie.ca (Postfix, from userid 2010) id 97CDD10AC12; Tue, 19 Sep 2017 08:06:27 -0400 (EDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by cheri.viagenie.ca (Postfix) with ESMTP id 5404E10ABE1 for ; Tue, 19 Sep 2017 08:06:27 -0400 (EDT) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2DDF840213 for ; Tue, 19 Sep 2017 08:06:27 -0400 (EDT) From: "Marc Blanchet" To: sunset4@ietf.org Date: Tue, 19 Sep 2017 08:06:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5412) Archived-At: Subject: [sunset4] draft-ietf-sunset4-ipv6-ietf next steps 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: Tue, 19 Sep 2017 12:06:33 -0000 Hello, given the wg LC has ended and no significant issues have been raised (however, very low number of comments), with the advice of AD, I’m writing the document writeup to submit the document to IESG. Marc. From nobody Tue Sep 19 05:08:14 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 EBC70134212; Tue, 19 Sep 2017 05:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rzXATDt9_yIs; Tue, 19 Sep 2017 05:08:10 -0700 (PDT) Received: from cheri.viagenie.ca (h48.viagenie.ca [206.123.31.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE7E1320CF; Tue, 19 Sep 2017 05:08:10 -0700 (PDT) Received: by cheri.viagenie.ca (Postfix, from userid 2010) id F393012880B; Tue, 19 Sep 2017 08:08:09 -0400 (EDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by cheri.viagenie.ca (Postfix) with ESMTP id C0E82128801; Tue, 19 Sep 2017 08:08:09 -0400 (EDT) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8FCD140213; Tue, 19 Sep 2017 08:08:09 -0400 (EDT) From: "Marc Blanchet" To: draft-ietf-sunset4-ipv6-ietf@ietf.org Cc: sunset4@ietf.org Date: Tue, 19 Sep 2017 08:08:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.7r5412) Archived-At: Subject: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf 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: Tue, 19 Sep 2017 12:08:13 -0000 Dear author, please state if you have direct, personal knowledge of any IPR related to this document (draft-ietf-sunset4-ipv6-ietf), and if yes, was it disclosed, in conformance with BCPs 78 and 79. Regards, Marc, document shepherd From nobody Tue Sep 19 06:36: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 5FF6613431A for ; Tue, 19 Sep 2017 06:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 wNI8rK5A7hew for ; Tue, 19 Sep 2017 06:36:48 -0700 (PDT) Received: from atl4mhob02.registeredsite.com (atl4mhob02.registeredsite.com [209.17.115.40]) (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 1EB3C134225 for ; Tue, 19 Sep 2017 06:36:47 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob02.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8JDajgO029795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Sep 2017 09:36:45 -0400 Received: (qmail 23880 invoked by uid 0); 19 Sep 2017 13:36:45 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.167?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 19 Sep 2017 13:36:45 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Lee Howard X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Tue, 19 Sep 2017 09:36:44 -0400 Cc: draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <379DC2F9-4553-472B-88EC-56A1AE47D214@asgard.org> References: To: Marc Blanchet Archived-At: Subject: Re: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf 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: Tue, 19 Sep 2017 13:36:50 -0000 Lol=20 I know of no IPR related to this draft.=20 Lee Sent from my iPhone > On Sep 19, 2017, at 8:08 AM, Marc Blanchet wro= te: >=20 > Dear author, > please state if you have direct, personal knowledge of any IPR related to t= his document (draft-ietf-sunset4-ipv6-ietf), and if yes, was it disclosed, i= n conformance with BCPs 78 and 79. >=20 > Regards, Marc, document shepherd >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 >=20 From nobody Tue Sep 19 06:54:33 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 C079C134328; Tue, 19 Sep 2017 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 IeixRRrQYLdX; Tue, 19 Sep 2017 06:54:31 -0700 (PDT) Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 576C4134322; Tue, 19 Sep 2017 06:54:28 -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; Tue, 19 Sep 2017 09:54:27 -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; Tue, 19 Sep 2017 09:54:27 -0400 From: Jacques Latour To: Lee Howard , MarcBlanchet CC: "draft-ietf-sunset4-ipv6-ietf@ietf.org" , "sunset4@ietf.org" Thread-Topic: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf Thread-Index: AQHTMT/5ik1Bx/Ti2UafREeRRrI6X6K8eTgA//+/8uA= Date: Tue, 19 Sep 2017 13:54:27 +0000 Message-ID: References: <379DC2F9-4553-472B-88EC-56A1AE47D214@asgard.org> In-Reply-To: <379DC2F9-4553-472B-88EC-56A1AE47D214@asgard.org> 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] IP on draft-ietf-sunset4-ipv6-ietf 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: Tue, 19 Sep 2017 13:54:33 -0000 Hi, I know I'm late on the reviewing part, but just wondering how the policing = part will work, who will ensure the "IETF work will explicitly support IPv6= " activities? Second, as an example, when this come in effect, would this draft "https://= tools.ietf.org/html/draft-ietf-nvo3-mcast-framework-09" specifically exclud= e IPv4 specifications, meaning this new framework work should only be appli= ed to IPv6, and ideally make IPv6 feature rich vs. IPv4. Jacques -----Original Message----- From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Lee Howard Sent: September 19, 2017 9:37 AM To: MarcBlanchet Cc: draft-ietf-sunset4-ipv6-ietf@ietf.org; sunset4@ietf.org Subject: Re: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf Lol=20 I know of no IPR related to this draft.=20 Lee Sent from my iPhone > On Sep 19, 2017, at 8:08 AM, Marc Blanchet wr= ote: >=20 > Dear author, > please state if you have direct, personal knowledge of any IPR related to= this document (draft-ietf-sunset4-ipv6-ietf), and if yes, was it disclosed= , in conformance with BCPs 78 and 79. >=20 > Regards, Marc, document shepherd >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 >=20 _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4 From nobody Tue Sep 19 07:12:17 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 3A41C13432B; Tue, 19 Sep 2017 07:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 eGZ1uHjgrK7G; Tue, 19 Sep 2017 07:12:13 -0700 (PDT) Received: from cheri.viagenie.ca (h48.viagenie.ca [206.123.31.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3AA13219B; Tue, 19 Sep 2017 07:12:13 -0700 (PDT) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by cheri.viagenie.ca (Postfix) with ESMTPSA id DF1C512C735; Tue, 19 Sep 2017 10:12:12 -0400 (EDT) From: "Marc Blanchet" To: "Jacques Latour" Cc: "Lee Howard" , "draft-ietf-sunset4-ipv6-ietf@ietf.org" , "sunset4@ietf.org" Date: Tue, 19 Sep 2017 10:12:11 -0400 Message-ID: In-Reply-To: References: <379DC2F9-4553-472B-88EC-56A1AE47D214@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5412) Archived-At: Subject: Re: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf 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: Tue, 19 Sep 2017 14:12:16 -0000 On 19 Sep 2017, at 9:54, Jacques Latour wrote: > Hi, > > I know I'm late on the reviewing part, but just wondering how the > policing part will work, who will ensure the "IETF work will > explicitly support IPv6" activities? I think that this is out of the wg remit and shall be handled by IESG. My guess is there will be many implications that the IESG will have to deal with. Marc. > > Second, as an example, when this come in effect, would this draft > "https://tools.ietf.org/html/draft-ietf-nvo3-mcast-framework-09" > specifically exclude IPv4 specifications, meaning this new framework > work should only be applied to IPv6, and ideally make IPv6 feature > rich vs. IPv4. > > Jacques > > > -----Original Message----- > From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Lee > Howard > Sent: September 19, 2017 9:37 AM > To: MarcBlanchet > Cc: draft-ietf-sunset4-ipv6-ietf@ietf.org; sunset4@ietf.org > Subject: Re: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf > > Lol > I know of no IPR related to this draft. > > Lee > > Sent from my iPhone > >> On Sep 19, 2017, at 8:08 AM, Marc Blanchet >> wrote: >> >> Dear author, >> please state if you have direct, personal knowledge of any IPR >> related to this document (draft-ietf-sunset4-ipv6-ietf), and if yes, >> was it disclosed, in conformance with BCPs 78 and 79. >> >> Regards, Marc, document shepherd >> >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >> > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From nobody Tue Sep 19 08:30:26 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 C0C9D132D18 for ; Tue, 19 Sep 2017 08:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=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 1GvFMUH0IkAI for ; Tue, 19 Sep 2017 08:30:18 -0700 (PDT) Received: from atl4mhob06.registeredsite.com (atl4mhob06.registeredsite.com [209.17.115.44]) (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 658351321C9 for ; Tue, 19 Sep 2017 08:30:18 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8JFUBFP005863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Sep 2017 11:30:14 -0400 Received: (qmail 25268 invoked by uid 0); 19 Sep 2017 15:30:11 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 19 Sep 2017 15:30:10 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Tue, 19 Sep 2017 11:30:09 -0400 From: Lee Howard To: Jacques Latour , MarcBlanchet CC: "sunset4@ietf.org" Message-ID: Thread-Topic: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf References: <379DC2F9-4553-472B-88EC-56A1AE47D214@asgard.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf 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: Tue, 19 Sep 2017 15:30:25 -0000 On 9/19/17, 9:54 AM, "sunset4 on behalf of Jacques Latour" wrote: >Hi, > >I know I'm late on the reviewing part, but just wondering how the >policing part will work, who will ensure the "IETF work will explicitly >support IPv6" activities? Policing requires a policy to be in effect, and this document creates that policy. It gives the IESG a consensus-based document to use in their work. > >Second, as an example, when this come in effect, would this draft >"https://tools.ietf.org/html/draft-ietf-nvo3-mcast-framework-09" >specifically exclude IPv4 specifications, meaning this new framework work >should only be applied to IPv6, and ideally make IPv6 feature rich vs. >IPv4. While I look forward to that day, this document doesn=E2=80=99t do that. I think the NVO multicast document would be covered by "No IPv4-only feature will be added unless there's an equivalent feature added in the IPv6 version.=E2=80=9D > >Jacques Lee > > >-----Original Message----- >From: sunset4 [mailto:sunset4-bounces@ietf.org] On Behalf Of Lee Howard >Sent: September 19, 2017 9:37 AM >To: MarcBlanchet >Cc: draft-ietf-sunset4-ipv6-ietf@ietf.org; sunset4@ietf.org >Subject: Re: [sunset4] IP on draft-ietf-sunset4-ipv6-ietf > >Lol=20 >I know of no IPR related to this draft. > >Lee > >Sent from my iPhone > >> On Sep 19, 2017, at 8:08 AM, Marc Blanchet >>wrote: >>=20 >> Dear author, >> please state if you have direct, personal knowledge of any IPR related >>to this document (draft-ietf-sunset4-ipv6-ietf), and if yes, was it >>disclosed, in conformance with BCPs 78 and 79. >>=20 >> Regards, Marc, document shepherd >>=20 >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >>=20 > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 > >_______________________________________________ >sunset4 mailing list >sunset4@ietf.org >https://www.ietf.org/mailman/listinfo/sunset4 > From nobody Thu Sep 28 06:26:29 2017 Return-Path: X-Original-To: sunset4@ietf.org Delivered-To: sunset4@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E7A134752; Thu, 28 Sep 2017 06:26:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk CC: Marc Blanchet , Marc.Blanchet@viagenie.ca, sunset4-chairs@ietf.org, sunset4@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, terry.manderson@icann.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 06:26:22 -0700 Archived-At: Subject: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.22 List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 13:26:23 -0000 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 sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF will stop working on IPv4, except where needed to mitigate documented security issues, to facilitate the transition to IPv6, or to enable IPv4 decommissioning. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-george-ipv6-support: IPv6 Support Within IETF work (None - ) From nobody Thu Sep 28 07:35:00 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 F15321331E7; Thu, 28 Sep 2017 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 UBaBlACStOVC; Thu, 28 Sep 2017 07:34:56 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 9F91E13301B; Thu, 28 Sep 2017 07:34:56 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id p187so2568961oif.4; Thu, 28 Sep 2017 07:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QZps5lyIFBInj1NURPVcJPrJebNhBHtiLQxmW4fCYiM=; b=H5806Bjt3Ilb/sAeI/7hmtEHcbdbL8oF7QvxUjFsBTsFaV1K1AfkWt0ef6D8pbY2jf RucAY+R4UNj1MwmdfkVUOtwgLMEmXi5AutRNqdlMVTAPnf1IDpE4WJOw0E8WyWtsAoKP 7jIktkByFbN3KXBhcztFREuaX9dxG120lLi2WzE1SvG7hgdcbrqpc3NzBjrQeSAeKjAA cYpUXet4l491CITVAVX+tIwIpkFPgQWxgCvCwkETqX69hLJopKJ8tqe5OIcmydp2Bgq9 Kn4hzvnlg70mJ+SaLCM6N22+5ExBw9baxk94T8FSbllFuJSniC5KwKML8zfF9L/lbqTm k0QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QZps5lyIFBInj1NURPVcJPrJebNhBHtiLQxmW4fCYiM=; b=Ru10VslFCQYK296vMTs/1tuTVnvTybMxUfs9475+AycCJGT4h//KPdm8Y16TaJo97v 1wqo3O2MewNVVE5ODP5MdVn/XhHeg5dvNw2Ey0KoAqsCpRqYk+pIw+Ck3Kkmohy45Cyx pgc/rLE/f64gV2aSsE+bevkg20zt/OCtRy9UhPJgzifaQqM6bdHAtZzuhDESqhvms2OA pEmciqCL5za66hfjNY2LeSraZTUwmiaUChUDdkSvDVaxf4hXJgKbJIAnVIJdPR9q8/Jw beNNc3JQJ+KNaJjkpWXKe2ZqvsvzS+amePuCymku7+63kYU5qGf9Cu2fdFz/GQ8EbjtM 6T3g== X-Gm-Message-State: AMCzsaWQE/A6fZrb9lcYCbUDrB8cZGD+6foKAnMvEuJL/4Mheoi4v+0Z NuMhx0KqcvkNtv7wOWMA7fBpeH9IQTWvBVIwgUQ= X-Google-Smtp-Source: AOwi7QBpZrUwvjeZwOEHjKd1HbI0rHmjC/y0uHQvoi56cWh4haQAE7BvtyqC9iQfEe7Vx+Uco7y3vTnoqYFpsQ4umtA= X-Received: by 10.202.75.20 with SMTP id y20mr494803oia.432.1506609295752; Thu, 28 Sep 2017 07:34:55 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Thu, 28 Sep 2017 07:34:55 -0700 (PDT) In-Reply-To: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> From: Phillip Hallam-Baker Date: Thu, 28 Sep 2017 10:34:55 -0400 X-Google-Sender-Auth: 7FpqJyRJ4Y3sfwiW7_UMZOPt2ng Message-ID: To: IETF Discussion Mailing List Cc: IETF-Announce , sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org, terry.manderson@icann.org Content-Type: multipart/alternative; boundary="001a11c1702ae38410055a40cfc7" 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, 28 Sep 2017 14:34:58 -0000 --001a11c1702ae38410055a40cfc7 Content-Type: text/plain; charset="UTF-8" I remain opposed for the reason I gave last time this was proposed: The IETF should retain control of IPv4 and any statement to the effect that the IETF will no longer work on IPv4 will inevitably lead to formation of an IPv4 legacy standards group in competition with IETF. Like it or not, FORTRAN and COBOL are still in common use a full 40 years after they were functionally obsolete. I see no reason to believe that anyone will need more than 32 bits of addressing for their home network. There being no compelling reason for my coffee pot to be able to talk to the entire Internet, I have a compelling reason to prevent it doing so. Rather than sunset IPv4, I would sunset IPv4 as an Internet protocol and relegate it to use as a network protocol only. As a network protocol, IPv4 remains far superior to many other protocols that the IETF continues to support and should begin supporting. I do not believe in a model where every device connects directly to the Internet. There is a proper role for the local loop and RS485, SPI, IC2 etc. devices in IoT and there is a role for IPv4. --001a11c1702ae38410055a40cfc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I r= emain opposed for the reason I gave last time this was proposed: The IETF s= hould retain control of IPv4 and any statement to the effect that the IETF = will no longer work on IPv4 will inevitably lead to formation of an IPv4 le= gacy standards group in competition with IETF.

Like it or not, FORTRAN and COBOL are still in common= use a full 40 years after they were functionally obsolete. I see no reason= to believe that anyone will need more than 32 bits of addressing for their= home network. There being no compelling reason for my coffee pot to be abl= e to talk to the entire Internet, I have a compelling reason to prevent it = doing so.

<= /div>
Rather than sun= set IPv4, I would sunset IPv4 as an Internet protocol and relegate it to us= e as a network protocol only.

As a network protocol, IPv4 remains far superior to many other protoco= ls that the IETF continues to support and should begin supporting. I do not= believe in a model where every device connects directly to the Internet. T= here is a proper role for the local loop and RS485, SPI, IC2 etc. devices i= n IoT and there is a role for IPv4.=C2=A0


--001a11c1702ae38410055a40cfc7-- From nobody Thu Sep 28 09:18: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 574B8134228 for ; Thu, 28 Sep 2017 09:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0yjuqYWuCAZb for ; Thu, 28 Sep 2017 09:18:45 -0700 (PDT) Received: from atl4mhob05.registeredsite.com (atl4mhob05.registeredsite.com [209.17.115.43]) (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 6A0E0134292 for ; Thu, 28 Sep 2017 09:18:41 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob05.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8SGIbnF024588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Sep 2017 12:18:38 -0400 Received: (qmail 12678 invoked by uid 0); 28 Sep 2017 16:18:37 -0000 X-TCPREMOTEIP: 66.160.130.14 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?66.160.130.123?) (lee@asgard.org@66.160.130.14) by 0 with ESMTPA; 28 Sep 2017 16:18:37 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 28 Sep 2017 12:18:31 -0400 From: Lee Howard To: Phillip Hallam-Baker , IETF Discussion Mailing List CC: , , , IETF-Announce , Message-ID: Thread-Topic: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3589445918_10711579" 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, 28 Sep 2017 16:18:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3589445918_10711579 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: sunset4 on behalf of Phillip Hallam-Baker Date: Thursday, September 28, 2017 at 10:34 AM To: IETF Discussion Mailing List Cc: , , , IETF-Announce , Subject: Re: [sunset4] Last Call: (IETF: End Work on IPv4) to Proposed Standard > I remain opposed for the reason I gave last time this was proposed: The I= ETF > should retain control of IPv4 and any statement to the effect that the IE= TF > will no longer work on IPv4 will inevitably lead to formation of an IPv4 > legacy standards group in competition with IETF. That would be an interesting development. But the document is hard to interpret as =E2=80=9CThe IETF has abdicated responsibility for IPv4.=E2=80=9D For inst= ance, the third sentence: Until the time when IPv4 is no longer in wide use and/or declared historic, the IETF needs to continue to update IPv4-only protocols and features for vital operational or security issues. Similarly: Some changes may be necessary in IPv4 protocols to facilitate decommissioning IPv4 in a way that does not create unacceptable impact to applications or users. And also: The IESG will review proposed working group charters to ensure that work will be capable of operating without IPv4, except in cases of IPv4 security, transition, and decommissioning work. Finally, looking at the number of times we have actually Updated RFC791 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION=E2=80=9D (four times, if I recall correctly) suggests to me that a competing standards bod= y created for the purpose of updating IPv4 would find itself with little to do. >=20 > Like it or not, FORTRAN and COBOL are still in common use a full 40 years > after they were functionally obsolete. I see no reason to believe that an= yone > will need more than 32 bits of addressing for their home network. There b= eing > no compelling reason for my coffee pot to be able to talk to the entire > Internet, I have a compelling reason to prevent it doing so. >=20 > Rather than sunset IPv4, I would sunset IPv4 as an Internet protocol and > relegate it to use as a network protocol only. Then change the name to NPv4? Do we care what people do on their private networks? Is it any of our business? Lee --B_3589445918_10711579 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


<= span id=3D"OLK_SRC_BODY_SECTION" style=3D"color: rgb(0, 0, 0); font-size: 14px; = font-family: Calibri, sans-serif;">
= From: sunset4 <sunset4-bounces@ietf.org> on behalf of Phillip= Hallam-Baker <phill@hallambaker.c= om>
Date: Thursday, Septemb= er 28, 2017 at 10:34 AM
To: IETF D= iscussion Mailing List <ietf@ietf.org&= gt;
Cc: <sunset4@ietf.org>, <sunset4-chairs@ietf.org>, <draft-ietf-sunset4-ipv6-ietf@ietf.org>, IETF-A= nnounce <ietf-announce@ietf.org>, <terry.manderson@icann= .org>
Subject: Re: [sunset4= ] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on = IPv4) to Proposed Standard

I remain opposed for the reason I gave last time this was propos= ed: The IETF should retain control of IPv4 and any statement to the effect t= hat the IETF will no longer work on IPv4 will inevitably lead to formation o= f an IPv4 legacy standards group in competition with IETF.

That would be an interesting devel= opment. But the document is hard to interpret as “The IETF has abdicat= ed responsibility for IPv4.” For instance, the third sentence:
Until the time when IPv4 is no longer in
   wide use and/or declared historic, the IETF needs to continue to
   update IPv4-only protocols and features for vital operational or
   security issues.
Similarly:
Some =
changes may be necessary in IPv4 protocols to
   facilitate decommissioning IPv4 in a way that does not create
   unacceptable impact to applications or users.

<= pre style=3D"color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-= serif;">And also:
   The IESG will review proposed working group charters t=
o ensure
      that work will be capable of operating without IPv4, except in
      cases of IPv4 security, transition, and decommissioning work.<=
/pre>

Finally, looking at the number o=
f times we have actually Updated RFC791 "INTERNET PROTOCOL DARPA INTERNET PR=
OGRAM PROTOCOL SPECIFICATION” (four times, if I recall correctly) sugg=
ests to me that a competing standards body created for the purpose of updati=
ng IPv4 would find itself with little to do.


Like it or not, FORTRAN and COBOL are still in= common use a full 40 years after they were functionally obsolete. I see no = reason to believe that anyone will need more than 32 bits of addressing for = their home network. There being no compelling reason for my coffee pot to be= able to talk to the entire Internet, I have a compelling reason to prevent = it doing so.

Rather than sunset IPv= 4, I would sunset IPv4 as an Internet protocol and relegate it to use as a n= etwork protocol only.

The= n change the name to NPv4?

Do we care what people d= o on their private networks? Is it any of our business?

=
Lee
 --B_3589445918_10711579-- From nobody Thu Sep 28 10:08:24 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 2F5E2134776; Thu, 28 Sep 2017 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 lysNuMUPda8O; Thu, 28 Sep 2017 10:08:07 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 7006F13476F; Thu, 28 Sep 2017 10:08:05 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id n82so3349863oib.8; Thu, 28 Sep 2017 10:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hs3yOVWhCGsulu8IoW6uoEnJdWqLh21XSxh1jluKKeo=; b=aHz+Diru9lDizKXiPo3SqWtdJQPYV/GN2p9CDceI+ALnEhAj8gprux7+kVtFMikGOJ 6LheYRqJ5GGoHsZRXnC48Cm/0AMobEc8UfvcS0FCLCHrNu5Di951vs3WSV/fJEjk3Jwz pJy48fhSrO/XIpyI2zZfyMFrIHPPSRC0ncbIeqqxipNG5moBUrSguosdZAsS/i8F4V/5 YxpVe5b2jTIeS9nD2e2BwbXU9i6Nq3/ybUBxpq/8fLJr4smNqVJx7Y6/5kLuZLb3lDPh LDLi/xD5dm3T0nthEnCg0deqpARwdVfzt0jv5zVm/bzAxUSM4Aqc0PzSbg2OhCrTHn9u 4chA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hs3yOVWhCGsulu8IoW6uoEnJdWqLh21XSxh1jluKKeo=; b=YiF4UrrMEaPivLydlNMXiqMGD3ZEdj0ufDaE1udzb3pc2c0xj2VtBGBXCe07Z0pniW 1fo1pUj4usPQg/74c7upZ4fDJl4GLs8SjjepJaHonx2qrGx3Nap4FpShsN4BuHjKS1/9 TehFMCaexVan9tY0xyufqzTTyNdpstJ1gOdJ06ZUU2vJE2OvdB0E/c6nEJ86FUkQfg7I m6ZLLHl3lC+dG/CNTALf1/98rN4ZXmYO5SamPSHQa5Akq0nDfzcAkNvsZQxCuMrQ9cfV PABIvmQrauRT1uak2OEEFP8+Mb2kvlwL9BvAJ8B0dGti19uoUtWDdU81yQY7DGOLIOBa nbsA== X-Gm-Message-State: AMCzsaVy66K3dwY9n3DM3frMMBdvvyV/yuJhxH5GrTYI5fvmp2dFPWzp Z5IpGnsoJf9PFRiUPazIljTNZDgj4otHkSUOLKM= X-Google-Smtp-Source: AOwi7QDV8/sdurWBhuNbaftWrXTTk1Mv+MJncfr1gn9KZcSBEKWl9xNRUqYQ9cgQcOYLMz/N0cCORc48EcsDu5W5evU= X-Received: by 10.157.46.23 with SMTP id q23mr1588597otb.133.1506618484629; Thu, 28 Sep 2017 10:08:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.84.21 with HTTP; Thu, 28 Sep 2017 10:07:44 -0700 (PDT) In-Reply-To: References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 28 Sep 2017 13:07:44 -0400 Message-ID: To: Lee Howard Cc: Phillip Hallam-Baker , IETF Discussion Mailing List , IETF-Announce , sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org Content-Type: multipart/alternative; boundary="001a113cd4dc96abf1055a42f3b8" 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, 28 Sep 2017 17:08:13 -0000 --001a113cd4dc96abf1055a42f3b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lee, Thanks, you=E2=80=99re right, BCP is much more appropriate than Information= al, it=E2=80=99s what I should have said in the first place. But PS still isn=E2=80=99t appr= opriate. To your last question about private networks - I think we do care, to the extent that the same protocols, equipment, and code paths are used both for private networks and the public Internet. But as you pointed out, the draft doesn=E2=80=99t say that we abandon IPv4. Cheers, Andy On Thu, Sep 28, 2017 at 12:18 PM, Lee Howard wrote: > > > From: sunset4 on behalf of Phillip > Hallam-Baker > Date: Thursday, September 28, 2017 at 10:34 AM > To: IETF Discussion Mailing List > Cc: , , < > draft-ietf-sunset4-ipv6-ietf@ietf.org>, IETF-Announce < > ietf-announce@ietf.org>, > Subject: Re: [sunset4] Last Call: > (IETF: End Work on IPv4) to Proposed Standard > > I remain opposed for the reason I gave last time this was proposed: The > IETF should retain control of IPv4 and any statement to the effect that t= he > IETF will no longer work on IPv4 will inevitably lead to formation of an > IPv4 legacy standards group in competition with IETF. > > > That would be an interesting development. But the document is hard to > interpret as =E2=80=9CThe IETF has abdicated responsibility for IPv4.=E2= =80=9D For > instance, the third sentence: > > Until the time when IPv4 is no longer in > wide use and/or declared historic, the IETF needs to continue to > update IPv4-only protocols and features for vital operational or > security issues. > > Similarly: > > Some changes may be necessary in IPv4 protocols to > facilitate decommissioning IPv4 in a way that does not create > unacceptable impact to applications or users. > > > And also: > > The IESG will review proposed working group charters to ensure > that work will be capable of operating without IPv4, except in > cases of IPv4 security, transition, and decommissioning work. > > > Finally, looking at the number of times we have actually Updated RFC791 "= INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION=E2=80=9D (f= our times, if I recall correctly) suggests to me that a competing standards= body created for the purpose of updating IPv4 would find itself with littl= e to do. > > > > Like it or not, FORTRAN and COBOL are still in common use a full 40 years > after they were functionally obsolete. I see no reason to believe that > anyone will need more than 32 bits of addressing for their home network. > There being no compelling reason for my coffee pot to be able to talk to > the entire Internet, I have a compelling reason to prevent it doing so. > > Rather than sunset IPv4, I would sunset IPv4 as an Internet protocol and > relegate it to use as a network protocol only. > > > Then change the name to NPv4? > > Do we care what people do on their private networks? Is it any of our > business? > > Lee > > --001a113cd4dc96abf1055a42f3b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lee,

Thanks, you=E2=80=99re right, BCP = is much more appropriate than Informational, it=E2=80=99s what I should hav= e said in the first place. But PS still isn=E2=80=99t appropriate.

To your last question about private networks - I think we = do care, to the extent that the same protocols, equipment, and code paths a= re used both for private networks and the public Internet. But as you point= ed out, the draft doesn=E2=80=99t say that we abandon IPv4.

<= /div>
Cheers,
Andy


On Thu, Sep 28, 2017 at 12:18 PM,= Lee Howard <lee@asgard.org> wrote:


= From: sunset4 <sunset4-bounces@ietf.org&= gt; on behalf of Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thursday, September 28, 2017 at 10:34 AM
= To: IETF Discussion Mailing List &= lt;ietf@ietf.org>=
Cc: <sunset4@ietf.org>, <sunset4-chairs@ietf.org= >, <draft-ietf-sunset4-ipv6-ietf@ietf.org>, IETF-Announ= ce <ietf-ann= ounce@ietf.org>, <terry.manderson@icann.org>
Subject: Re: [sunset4] Last Call: <draft-ietf-sunset4= -ipv6-ietf-01.txt> (IETF: End Work on IPv4) to Proposed Standard

I remain opposed for the reason I gave last t= ime this was proposed: The IETF should retain control of IPv4 and any state= ment to the effect that the IETF will no longer work on IPv4 will inevitabl= y lead to formation of an IPv4 legacy standards group in competition with I= ETF.

That would be an= interesting development. But the document is hard to interpret as =E2=80= =9CThe IETF has abdicated responsibility for IPv4.=E2=80=9D For instance, t= he third sentence:
Until the time when IPv4 is no longer in
   wide use and/or declared historic, the IETF needs to continue to
   update IPv4-only protocols and features for vital operational or
   security issues.
Similarly:
Some changes may =
be necessary in IPv4 protocols to
   facilitate decommissioning IPv4 in a way that does not create
   unacceptable impact to applications or users. 

And =
also:
   The IESG will review proposed working group charters to ensure
      that work will be capable of operating without IPv4, except in
      cases of IPv4 security, transition, and decommissioning work.<=
/pre>
=

Finally, looking at the number=
 of times we have actually Updated RFC791 "INTERNET PROTOCOL DARPA INT=
ERNET PROGRAM PROTOCOL SPECIFICATION=E2=80=9D (four times, if I recall corr=
ectly) suggests to me that a competing standards body created for the purpo=
se of updating IPv4 would find itself with little to do.

<= span id=3D"m_5614458275030325110OLK_SRC_BODY_SECTION" style=3D"color:rgb(0,= 0,0);font-size:14px;font-family:Calibri,sans-serif">

Like it or not, FORTRAN and COBOL are st= ill in common use a full 40 years after they were functionally obsolete. I = see no reason to believe that anyone will need more than 32 bits of address= ing for their home network. There being no compelling reason for my coffee = pot to be able to talk to the entire Internet, I have a compelling reason t= o prevent it doing so.

Ra= ther than sunset IPv4, I would sunset IPv4 as an Internet protocol and rele= gate it to use as a network protocol only.
<= div>
Then change the name to NPv4?

Do we care what people do on their private networks? Is it any of our= business?

Lee
=


--001a113cd4dc96abf1055a42f3b8-- From nobody Thu Sep 28 10:17: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 10E51134779; Thu, 28 Sep 2017 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 KgLC7zYaXjBq; Thu, 28 Sep 2017 10:17:44 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 769041342D4; Thu, 28 Sep 2017 10:17:32 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u138so3654878wmu.5; Thu, 28 Sep 2017 10:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=sbEjVuxHLWdcWayvUJpplVsPdrqV/g+y8QO5R6/9xuc=; b=QvziCnNA/BZ90i4QUgHkDmwb/Ht91XLU3vTbWihd3t8ld6zkkCdJssyx1uEWVfrsy7 TT3gL2I0iQQtDbMHy1KCMTzWZK72osJ44w77s7RMUYq2NsIz9Dun1PMVPuSM+lVYu5b3 g1qOc4uEeu0FNvKqiJql7pVBM/VzZ+QTmStly/ngn1VvcpyjcmMnYY70ofuhvLwanrjm iyYe3oDiOB5VWXg3mK7dRO2n6SxcFpvXn6BemExoTz3Rk/zCh5ntA6ho7fW7t7ocWura M4uEfVy8nZiSjS8Sy8zrBIVXojGNIz3mN7A4syCqz0HRrGerO76nqB8AHKhk1AQbUMDI PAMQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=sbEjVuxHLWdcWayvUJpplVsPdrqV/g+y8QO5R6/9xuc=; b=qnFlj+6c14Zj6rxuOtIOHqYmXGk9c36XOTNdbZRY19LD67qoEwf9BXIRGSkqPygemL p3M2lWI0XCija4kJj6MOzUlxwFvlisFUCuayQb36NtXLnFA5br4PhsrGsP2XGKRXhznd 0u+bBxbALS58Gg0M8Cy38yCZhCcLg1AmGFsRzclFsH/XY4qZ7vtFx49U+H1XKac/OxGw F725K/xqKQk2MVwjfY2beMR4USm2DZ1xx5/7jygJfi2xonlYl411qqbK7zmH9+wN0jEm zKwzDXp8cKD84lY+PFGLQtnp75Wc/G3AXEdNiqSmzU2BSw5YPjok4CQWd7cHVNHTo2sO AneQ== X-Gm-Message-State: AMCzsaVtmBliYiJgahJfZ8fl6bYiqGYQgVy3ud1/lvaPLbMcp4BqomL4 k4VqQQ48XJ1rWHwoheV58Hg= X-Google-Smtp-Source: AOwi7QA9pjjWitnXBQv/KZHDmjauiof20XYme2ioqcUtA7ToM0mgNEGP09+GAZcLCKLEJRQPahd7yA== X-Received: by 10.28.70.133 with SMTP id t127mr1961792wma.42.1506619047417; Thu, 28 Sep 2017 10:17:27 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 10sm1018879wmy.35.2017.09.28.10.17.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 10:17:26 -0700 (PDT) To: ietf@ietf.org Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org, terry.manderson@icann.org References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <1c9d4fae-cae8-5669-ec4b-f8029ee6ede4@gmail.com> Date: Thu, 28 Sep 2017 18:17:24 +0100 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: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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, 28 Sep 2017 17:17:46 -0000 As I have said before, I think that it would be a mistake to make this declaration. A lot of the world still relies heavily on IPv4, and many countries would rightly regard IPv4 as critical national infrastructure. If the IETF announces that it is no longer supporting IPv4, then those countries would have every right to demand that the ITU-T took over responsibility for IPv4 development and maintenance of the protocol. If that happened you would naturally expect them to extend its life, perhaps even creating a viable competitor to IPv6 with all of the difficulty and confusion that would then result. Whilst I think the elements of the ID that talk about ensuring that every protocol can run in an IPv6 only network are useful, although much stated in the past, I think that it would be a serious mistake to give any appearance of abandoning IPv4. - Stewart On 28/09/2017 14:26, 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 > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > The IETF will stop working on IPv4, except where needed to mitigate > documented security issues, to facilitate the transition to IPv6, or > to enable IPv4 decommissioning. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > draft-george-ipv6-support: IPv6 Support Within IETF work (None - ) > > > From nobody Thu Sep 28 10:27:31 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 258B613476B; Thu, 28 Sep 2017 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Jie48fKpUw69; Thu, 28 Sep 2017 10:27:17 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 98B74134769; Thu, 28 Sep 2017 10:27:16 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u138so3703666wmu.5; Thu, 28 Sep 2017 10:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=LkLJevFwk6LV0zSZpHiU/9ykgRf5MdGqTOWsRdKA1zY=; b=OK0JdWsCJ54brjKXfTjkYPeEGyWvn7RaAt4JfNbb3W6+F3Bdb+y2Syda3biAjBdNnO hEBwX4EmPLheQ9y3RvlhuABKNCg8hTIDY0C+A8WFJKnKXx97DCE4fDP41+ncy+wjypJC M4cGzjGF1ehVhx4Hn0vM9R0XE7lM8lFuVJigITvdsx5KQ0X/PzeZRHsHr/jf20TNtFsD iZoL6bBd6BYYsDgPZeakrRBPvLeCw8CFMasTtf6I96YfWk5RVoXgTU9ogUlPlglLRl7Y aGDDjDuAsdaP/oM4DsW8+rmCO+Ux9A/pbI8dAYHDzpJO7v2+I5DgUeb/iwx2Ok7tAnSw K7Ng== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=LkLJevFwk6LV0zSZpHiU/9ykgRf5MdGqTOWsRdKA1zY=; b=SL33HDMt/+aYzbjrO7TKI43BlYAJjkIXcNmnk11KaVTY0QHYV8nrKTZWXEbSLir+q/ xDa4QP7NTf98XOQDPeOE8eR8r9rb2brjCRgR5gK+dSjlvmgGD6zfUxilDha1zxcwZ3ni r317sUjPUbFMtoYG7E9XW2M4M08KKewAW2hrznfkQEHu8awvSTWQhQWTfp+rfWDG4es8 IwRtgM5H9hZqsjlls5gRfrYUrPzgtAvlQV61kj1+s9YUVhDnnF0HqycDyOXcztDw7hA0 doaQqVA1czz9a2NVEhnpMGP/Qr/8wiq8z9r1QTRj4wi+7SsbNP8WCIL/kUCHpAQMK7AE AQNw== X-Gm-Message-State: AHPjjUiys4fZM2Y2JgcHwc0wqYNCXpWe6wR2yfMa8nVP3MTOMCn3r8w9 PGqRo+4/8d6nPI0Oqd7qasucJNok X-Google-Smtp-Source: AOwi7QAl4ekas1fXKbSMs4541rdovYXU/acBUhwO6vE4TDobuX+6AeIaswcha+C3gkycqu88K/6znA== X-Received: by 10.80.149.219 with SMTP id x27mr6590357eda.146.1506619634773; Thu, 28 Sep 2017 10:27:14 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 6sm1751041ede.81.2017.09.28.10.27.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 10:27:14 -0700 (PDT) To: Lee Howard , Phillip Hallam-Baker , IETF Discussion Mailing List Cc: IETF-Announce , sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <9637bbf6-82a2-c94d-0b3d-238501e7679a@gmail.com> Date: Thu, 28 Sep 2017 18:27:11 +0100 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="------------B39CE4A22FB8BEFD14B2C360" Content-Language: en-GB 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, 28 Sep 2017 17:27:25 -0000 This is a multi-part message in MIME format. --------------B39CE4A22FB8BEFD14B2C360 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Set aside that we will develop IPv6 as necessary. I am sure we will do that. I can see lots of down side in making this declaration, which may be interpreted as we intend, but more likely as others with political or commercial ambition spin it. Making this statement has the potential to develop into a huge inter-SDO fight. I am not at all clear on the upside. We should make declarations about IPv6, but remain silent on IPv4. - Stewart On 28/09/2017 17:18, Lee Howard wrote: > > > From: sunset4 > on behalf of Phillip Hallam-Baker > > > Date: Thursday, September 28, 2017 at 10:34 AM > To: IETF Discussion Mailing List > > Cc: >, > >, > >, IETF-Announce > >, > > > Subject: Re: [sunset4] Last Call: > (IETF: End Work on IPv4) to > Proposed Standard > > I remain opposed for the reason I gave last time this was > proposed: The IETF should retain control of IPv4 and any statement > to the effect that the IETF will no longer work on IPv4 will > inevitably lead to formation of an IPv4 legacy standards group in > competition with IETF. > > > That would be an interesting development. But the document is hard to > interpret as “The IETF has abdicated responsibility for IPv4.” For > instance, the third sentence: > Until the time when IPv4 is no longer in > wide use and/or declared historic, the IETF needs to continue to > update IPv4-only protocols and features for vital operational or > security issues. > Similarly: > Some changes may be necessary in IPv4 protocols to > facilitate decommissioning IPv4 in a way that does not create > unacceptable impact to applications or users. > And also: > The IESG will review proposed working group charters to ensure that > work will be capable of operating without IPv4, except in cases of > IPv4 security, transition, and decommissioning work. > Finally, looking at the number of times we have actually Updated > RFC791 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL > SPECIFICATION” (four times, if I recall correctly) suggests to me that > a competing standards body created for the purpose of updating IPv4 > would find itself with little to do. > > > Like it or not, FORTRAN and COBOL are still in common use a full > 40 years after they were functionally obsolete. I see no reason to > believe that anyone will need more than 32 bits of addressing for > their home network. There being no compelling reason for my coffee > pot to be able to talk to the entire Internet, I have a compelling > reason to prevent it doing so. > > Rather than sunset IPv4, I would sunset IPv4 as an Internet > protocol and relegate it to use as a network protocol only. > > > Then change the name to NPv4? > > Do we care what people do on their private networks? Is it any of our > business? > > Lee > --------------B39CE4A22FB8BEFD14B2C360 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Set aside that we will develop IPv6 as necessary. I am sure we will do that.

I can see lots of down side in making this declaration, which may be interpreted as we intend, but more likely as others with political or commercial ambition spin it. 

Making this statement has the potential to develop into a huge inter-SDO fight.

I am not at all clear on the upside.

We should make declarations about IPv6, but remain silent on IPv4.

- Stewart

On 28/09/2017 17:18, Lee Howard wrote:


From: sunset4 <sunset4-bounces@ietf.org> on behalf of Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thursday, September 28, 2017 at 10:34 AM
To: IETF Discussion Mailing List <ietf@ietf.org>
Cc: <sunset4@ietf.org>, <sunset4-chairs@ietf.org>, <draft-ietf-sunset4-ipv6-ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, <terry.manderson@icann.org>
Subject: Re: [sunset4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4) to Proposed Standard

I remain opposed for the reason I gave last time this was proposed: The IETF should retain control of IPv4 and any statement to the effect that the IETF will no longer work on IPv4 will inevitably lead to formation of an IPv4 legacy standards group in competition with IETF.

That would be an interesting development. But the document is hard to interpret as “The IETF has abdicated responsibility for IPv4.” For instance, the third sentence:
Until the time when IPv4 is no longer in
   wide use and/or declared historic, the IETF needs to continue to
   update IPv4-only protocols and features for vital operational or
   security issues.
Similarly:
Some changes may be necessary in IPv4 protocols to
   facilitate decommissioning IPv4 in a way that does not create
   unacceptable impact to applications or users. 

        
And also:

        
   The IESG will review proposed working group charters to ensure
      that work will be capable of operating without IPv4, except in
      cases of IPv4 security, transition, and decommissioning work.

        



        
Finally, looking at the number of times we have actually Updated RFC791 "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION” (four times, if I recall correctly) suggests to me that a competing standards body created for the purpose of updating IPv4 would find itself with little to do.

        

      

      
        

          

            


            

            
Like it
              or not, FORTRAN and COBOL are still in common use a full
              40 years after they were functionally obsolete. I see no
              reason to believe that anyone will need more than 32 bits
              of addressing for their home network. There being no
              compelling reason for my coffee pot to be able to talk to
              the entire Internet, I have a compelling reason to prevent
              it doing so.

            


            

            
Rather
              than sunset IPv4, I would sunset IPv4 as an Internet
              protocol and relegate it to use as a network protocol
              only.

          

        

      
      


      

      
Then change the name to NPv4?

      


      

      
Do we care what people do on their private networks? Is it
        any of our business?

      


      

      
        

          
Lee

        

      
        

          


          

        

      
    

    

  


--------------B39CE4A22FB8BEFD14B2C360--


From nobody Thu Sep 28 11:29:58 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 7403E133065; Thu, 28 Sep 2017 11:29:56 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 1q_1JF0bPk6K; Thu, 28 Sep 2017 11:29:55 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4041342F2; Thu, 28 Sep 2017 11:29:54 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8SITUra010947; Thu, 28 Sep 2017 19:29:30 +0100
Received: from 950129200 (218.122.115.87.dyn.plus.net [87.115.122.218]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v8SITTlk010931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Sep 2017 19:29:29 +0100
Reply-To: 
From: "Adrian Farrel" 
To: , "'IETF-Announce'" 
Cc: , , , 
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>
In-Reply-To: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>
Date: Thu, 28 Sep 2017 19:29:28 +0100
Message-ID: <01ce01d33887$b8c3b390$2a4b1ab0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHdif5JqEElt4UjNKcy0PHQPYOvL6K18zjQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23358.001
X-TM-AS-Result: No--21.123-10.0-31-10
X-imss-scan-details: No--21.123-10.0-31-10
X-TMASE-MatchedRID: IDdx3MBO6EBfsB4HYR80ZggKAWhuC2ojb6bRSg4rpzu638ZUY6gSd2jF IcV+Yem07d24Mhckf+8R+cfIs71qUnnYsjCinlm92DrYMLc1SE86En2bnefhoOGkTiRMqa/cSRm n6zbztNaewSHLSiS0TVegFqdOfnuNpjLap8Pn2LuHZXNSWjgdU0yQ5fRSh265IbxYwbCxGTQP/F bH9DutnaOCHC/35LkNCHEY5+6pmM6MLrybB70fruG5dRZCgxC377AMeyyT87zaqqH/oHw+kbmdM 1aLrFCB2/r7EXSFx8rAC7+rw+mMJaUfuKsxxI0H3eD1qo3klpo1G/3YRqERwUURqPq2IVdwujw9 BXXmuOAfrqxpcAmdjAieALpUfW4ZQKbqzl//zc2RGzV8Bxg0ceWNJG9IamrcNOnYXKcDRxAh9Vq lLDyFJ4PZ2QRnk4s66yhlFTj/MvesT6Dr98/byS2416nc3bQlBGvINcfHqheRXvk9upP+EN+XQ+ +q8wX3nu2jApQVQcLCR4lJDv6fyNQGo5fD0u9j5gCHftmwEMLjAcZeNJgY9y62hjZS0WoYS9U7s RxCp1te9N8X0ShXYLElmVtHhdr27QyV3KLI3eOTEgTE0DYkgBSRa9qpSosfHMKI0y89bBLlnbBf Oj9S76YY48rM/FzUJ1NZMNkS1JXI2RqSAXh33ilrosmS0SOArAT+Zr+w7msok+CLr2yyHFzOi44 jsMbd585VzGMOFzABi3kqJOK62QtuKBGekqUpPjKoPgsq7cA=
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, 28 Sep 2017 18:29:56 -0000

The underlying intent of this document may be well intentioned, but the =
execution is lacking. As currently presented I strongly oppose it's =
publication as an IETF RFC.

1. The document title is (wilfully?) melodramatic and is in conflict =
with the content of the document. This document specifically lists =
circumstances under which the authors think that the IETF should =
continue to work on IPv4. Using this document title will do nothing more =
than cause confusion, panic, and result in the kind of "land grab" that =
others have worried about. Can the title please be changed to reflect =
the actual content of the document.

2. The Abstract is at odds with the content of the document. The =
Abstract says:
>   The IETF will stop working on IPv4, except where needed to mitigate
>   documented security issues, to facilitate the transition to IPv6, or
>   to enable IPv4 decommissioning.
...but Section 1 adds to this list the very important point that=20
>  Until the time when IPv4 is no longer in
>  wide use and/or declared historic, the IETF needs to continue to
>  update IPv4-only protocols and features for vital operational or
>  security issues.  "Vital" means "necessary for successfully operating
>  IPv4 networks." =20
...The Abstract must give an accurate account of what the document says. =
This could be achieved by saying less ("This document describes the =
IETF's approach to new work on IPv4 and IPv4-only protocols") or more =
(by setting out the full list of cases as described in Section 1).

3. The bullet list in Section 1 concludes with:
>    New IETF work must function completely on IPv6-only nodes and
>    networks.
...This is ambiguous after the previous bullets. I believe that either =
there is some special meaning of "New" intended here (different from in =
previous bullets) or this is meant to read something like:
|  All new IETF work must be capable of functioning in IPv6-only =
networks.

4. The IANA Considerations section attempts a commentary that is =
probably unhelpful. It might be helpful to replace this with a =
"standard" Null IANA section as that will be clearer and is entirely =
consistent with the ask (which is null).

5. You might consider adding some statement about documentation of =
examples in new RFCs (idnits already drops a strong hint, but most =
authors chose to ignore it). It might be too strong to require =
non-documentation of IPv4 examples, but inclusion of IPv6 examples =
whenever there is an IPv4 example sounds like a good idea "unless there =
is a good and documented reason why not."

And lastly, just to check...
Suppose I have a protocol that runs in a private network using a private =
address space, and suppose that that network currently uses IPv4. Take =
as an example a network that uses management or control protocol running =
between the routers and separate from the traffic carried over the =
network.=20
My reading of this I-D is that those protocols can be enhanced and =
features added provided that those additions are also made such that the =
protocols would work perfectly in an IPv6-only network.
If it is not the intention that I should be able to make this reading, =
then words should be changed.

Thanks,
Adrian




> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf =
Of The
> IESG
> Sent: 28 September 2017 14:26
> To: IETF-Announce
> Cc: sunset4-chairs@ietf.org; draft-ietf-sunset4-ipv6-ietf@ietf.org;
> sunset4@ietf.org; terry.manderson@icann.org
> Subject: Last Call:  (IETF: End =
Work on IPv4)
> to Proposed Standard
>=20
>=20
> 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
>=20
> 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
> sent to iesg@ietf.org instead. In either case, please retain the =
beginning of
> the Subject line to allow automated sorting.
>=20
> Abstract
>=20
>=20
>    The IETF will stop working on IPv4, except where needed to mitigate
>    documented security issues, to facilitate the transition to IPv6, =
or
>    to enable IPv4 decommissioning.
>=20
>=20
>=20
>=20
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/
>=20
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ballot/
>=20
>=20
> No IPR declarations have been submitted directly on this I-D.
>=20
>=20
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     draft-george-ipv6-support: IPv6 Support Within IETF work (None - )
>=20



From nobody Thu Sep 28 14:08:33 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 8593B1349A7; Thu, 28 Sep 2017 14:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 xzExVeq34QfU; Thu, 28 Sep 2017 14:08:24 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079221349B1; Thu, 28 Sep 2017 14:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16588; q=dns/txt; s=iport; t=1506632902; x=1507842502; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=iCVXeuavOQLDjLchplr9MC8GsZ5hkss5QLoqcgFtgpk=; b=XuJ4urCx4J3blzwBXCSlqDTJ0MXlZPT99ne2HbJBYdftkyvaEf8SGDJJ UE/BCgbbJZ/l6h+TiSN6h2wK3zjPL6sOSpbYdXUUeWfQQxs8fiMeGOePx Q/xax59NbCmrffasH6Nxw1lIU5th3RP5HPOJDY+m34hNR7LQEiiXt5P4+ 4=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAADEY81Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy+BEW4ng3iKH3SQPyKQbYU+DoIEBwMjhRgChGQYAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEDI0QHCwwECxEEAQEBFRIDAgJGCQgGAQwGAgEBii0QpnqCJyeLH?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4KBYMrhT0rC4JyhD+BBIJUgmAFkTyPbIQ?= =?us-ascii?q?8giGBAY0CghOFboNaJIcHihCLPYE5HziBDjIhCB0VHyqFT4FQPjaJBAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,451,1500940800";  d="asc'?scan'208,217";a="697622489"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 21:08:18 +0000
Received: from [10.61.107.34] (dhcp-10-61-107-34.cisco.com [10.61.107.34]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8SL8Iak001899; Thu, 28 Sep 2017 21:08:18 GMT
To: adrian@olddog.co.uk, ietf@ietf.org, "'IETF-Announce'" 
Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> <01ce01d33887$b8c3b390$2a4b1ab0$@olddog.co.uk>
From: Eliot Lear 
Message-ID: <66239ec4-8fb0-15a5-6433-bb8decea96f2@cisco.com>
Date: Thu, 28 Sep 2017 23:08:19 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <01ce01d33887$b8c3b390$2a4b1ab0$@olddog.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xfhCbKgEVONDNI5WbsAdcvV8mLtV5BDVG"
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, 28 Sep 2017 21:08:27 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--xfhCbKgEVONDNI5WbsAdcvV8mLtV5BDVG
Content-Type: multipart/mixed; boundary="B3GU8RICaR2T7pd2hBBRiX4reAlL0FgWS";
 protected-headers="v1"
From: Eliot Lear 
To: adrian@olddog.co.uk, ietf@ietf.org,
 'IETF-Announce' 
Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org,
 sunset4@ietf.org
Message-ID: <66239ec4-8fb0-15a5-6433-bb8decea96f2@cisco.com>
Subject: Re: Last Call:  (IETF: End Work
 on IPv4) to Proposed Standard
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>
 <01ce01d33887$b8c3b390$2a4b1ab0$@olddog.co.uk>
In-Reply-To: <01ce01d33887$b8c3b390$2a4b1ab0$@olddog.co.uk>

--B3GU8RICaR2T7pd2hBBRiX4reAlL0FgWS
Content-Type: multipart/alternative;
 boundary="------------4224035E20603AE054D2E1F1"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------4224035E20603AE054D2E1F1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Lee and others,

I agree with Adrian and would go a bit further.=C2=A0 The abstract seems =
to
contradict the content.=C2=A0 That needs correcting, one way or the other=
=2E=C2=A0
This reader in particular is confused as to the document's intent.=C2=A0 =
And
so, I have these questions:

 1. If I wish to add a new DHCPv4 option as well as a similar DHCPv6
    iption, would that contravene the intent of this document?
 2. If I wish to add a field that would permit IPv4 addresses and IPv6
    addresses, would that contravene the intent of this document?

Let us presume for purposes of answering these questions that we are
talking about non-security and non-transitional work.

I also have a comment about the charter of sunset4 with regard to this
document.=C2=A0 I was expecting to see a gap analysis first, and I wasn't=

particularly expecting a policy statement from this WG.

I share the sentiment of the abstract, but I also share the concerns
that Stewart raised.=C2=A0 If there is a demand for IPv4 improvements, an=
d
the IETF won't satisfy it, others will fill that vacuum.=C2=A0 That sort =
of
problem has posed a substantial amount of work for the IAB, the IESG,
ISOC, and the IETF Trust in the past.

Thanks,

Eliot


On 9/28/17 8:29 PM, Adrian Farrel wrote:
> The underlying intent of this document may be well intentioned, but the=
 execution is lacking. As currently presented I strongly oppose it's publ=
ication as an IETF RFC.
>
> 1. The document title is (wilfully?) melodramatic and is in conflict wi=
th the content of the document. This document specifically lists circumst=
ances under which the authors think that the IETF should continue to work=
 on IPv4. Using this document title will do nothing more than cause confu=
sion, panic, and result in the kind of "land grab" that others have worri=
ed about. Can the title please be changed to reflect the actual content o=
f the document.
>
> 2. The Abstract is at odds with the content of the document. The Abstra=
ct says:
>>   The IETF will stop working on IPv4, except where needed to mitigate
>>   documented security issues, to facilitate the transition to IPv6, or=

>>   to enable IPv4 decommissioning.
> ...but Section 1 adds to this list the very important point that=20
>>  Until the time when IPv4 is no longer in
>>  wide use and/or declared historic, the IETF needs to continue to
>>  update IPv4-only protocols and features for vital operational or
>>  security issues.  "Vital" means "necessary for successfully operating=

>>  IPv4 networks." =20
> ...The Abstract must give an accurate account of what the document says=
=2E This could be achieved by saying less ("This document describes the I=
ETF's approach to new work on IPv4 and IPv4-only protocols") or more (by =
setting out the full list of cases as described in Section 1).
>
> 3. The bullet list in Section 1 concludes with:
>>    New IETF work must function completely on IPv6-only nodes and
>>    networks.
> ...This is ambiguous after the previous bullets. I believe that either =
there is some special meaning of "New" intended here (different from in p=
revious bullets) or this is meant to read something like:
> |  All new IETF work must be capable of functioning in IPv6-only networ=
ks.
>
> 4. The IANA Considerations section attempts a commentary that is probab=
ly unhelpful. It might be helpful to replace this with a "standard" Null =
IANA section as that will be clearer and is entirely consistent with the =
ask (which is null).
>
> 5. You might consider adding some statement about documentation of exam=
ples in new RFCs (idnits already drops a strong hint, but most authors ch=
ose to ignore it). It might be too strong to require non-documentation of=
 IPv4 examples, but inclusion of IPv6 examples whenever there is an IPv4 =
example sounds like a good idea "unless there is a good and documented re=
ason why not."
>
> And lastly, just to check...
> Suppose I have a protocol that runs in a private network using a privat=
e address space, and suppose that that network currently uses IPv4. Take =
as an example a network that uses management or control protocol running =
between the routers and separate from the traffic carried over the networ=
k.=20
> My reading of this I-D is that those protocols can be enhanced and feat=
ures added provided that those additions are also made such that the prot=
ocols would work perfectly in an IPv6-only network.
> If it is not the intention that I should be able to make this reading, =
then words should be changed.
>
> Thanks,
> Adrian
>
>
>
>
>> -----Original Message-----
>> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf =
Of The
>> IESG
>> Sent: 28 September 2017 14:26
>> To: IETF-Announce
>> Cc: sunset4-chairs@ietf.org; draft-ietf-sunset4-ipv6-ietf@ietf.org;
>> sunset4@ietf.org; terry.manderson@icann.org
>> Subject: Last Call:  (IETF: End W=
ork on IPv4)
>> to Proposed Standard
>>
>>
>> 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
>> sent to iesg@ietf.org instead. In either case, please retain the begin=
ning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    The IETF will stop working on IPv4, except where needed to mitigate=

>>    documented security issues, to facilitate the transition to IPv6, o=
r
>>    to enable IPv4 decommissioning.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> The document contains these normative downward references.
>> See RFC 3967 for additional information:
>>     draft-george-ipv6-support: IPv6 Support Within IETF work (None - )=

>>
>
>


--------------4224035E20603AE054D2E1F1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Lee and others,

    
I agree with Adrian and would go a bit further.=C2=A0 The abstract=

      seems to contradict the content.=C2=A0 That needs correcting, one w=
ay
      or the other.=C2=A0 This reader in particular is confused as to the=

      document's intent.=C2=A0 And so, I have these questions:

    
    
      
  1. If I wish to add a new DHCPv4 option as well as a similar
        DHCPv6 iption, would that contravene the intent of this
        document?
    2. 
      
  2. If I wish to add a field that would permit IPv4 addresses and
        IPv6 addresses, would that contravene the intent of this
        document?
    3. 
    

    
Let us presume for purposes of answering these questions that we
      are talking about non-security and non-transitional work.

    
I also have a comment about the charter of sunset4 with regard to
      this document.=C2=A0 I was expecting to see a gap analysis first, a=
nd I
      wasn't particularly expecting a policy statement from this WG.

    
I share the sentiment of the abstract, but I also share the
      concerns that Stewart raised.=C2=A0 If there is a demand for IPv4
      improvements, and the IETF won't satisfy it, others will fill that
      vacuum.=C2=A0 That sort of problem has posed a substantial amount o=
f
      work for the IAB, the IESG, ISOC, and the IETF Trust in the past.
    

    
Thanks,

    
Eliot

    

    
On 9/28/17 8:29 PM, Adrian Farrel
      wrote:

    

    

      
The underlying intent of this document may be well i=
ntentioned, but the execution is lacking. As currently presented I strong=
ly oppose it's publication as an IETF RFC.

1. The document title is (wilfully?) melodramatic and is in conflict with=
 the content of the document. This document specifically lists circumstan=
ces under which the authors think that the IETF should continue to work o=
n IPv4. Using this document title will do nothing more than cause confusi=
on, panic, and result in the kind of "land grab" that others have worried=
 about. Can the title please be changed to reflect the actual content of =
the document.

2. The Abstract is at odds with the content of the document. The Abstract=
 says:


      

        
  The IETF will stop working on IPv4, except where=
 needed to mitigate
  documented security issues, to facilitate the transition to IPv6, or
  to enable IPv4 decommissioning.


      

      
...but Section 1 adds to this list the very importan=
t point that=20


      

        
 Until the time when IPv4 is no longer in
 wide use and/or declared historic, the IETF needs to continue to
 update IPv4-only protocols and features for vital operational or
 security issues.  "Vital" means "necessary for successfully operating
 IPv4 networks." =20


      

      
...The Abstract must give an accurate account of wha=
t the document says. This could be achieved by saying less ("This documen=
t describes the IETF's approach to new work on IPv4 and IPv4-only protoco=
ls") or more (by setting out the full list of cases as described in Secti=
on 1).

3. The bullet list in Section 1 concludes with:


      

        
   New IETF work must function completely on IPv6-=
only nodes and
   networks.


      

      
...This is ambiguous after the previous bullets. I b=
elieve that either there is some special meaning of "New" intended here (=
different from in previous bullets) or this is meant to read something li=
ke:
|  All new IETF work must be capable of functioning in IPv6-only networks=
=2E

4. The IANA Considerations section attempts a commentary that is probably=
 unhelpful. It might be helpful to replace this with a "standard" Null IA=
NA section as that will be clearer and is entirely consistent with the as=
k (which is null).

5. You might consider adding some statement about documentation of exampl=
es in new RFCs (idnits already drops a strong hint, but most authors chos=
e to ignore it). It might be too strong to require non-documentation of I=
Pv4 examples, but inclusion of IPv6 examples whenever there is an IPv4 ex=
ample sounds like a good idea "unless there is a good and documented reas=
on why not."

And lastly, just to check...
Suppose I have a protocol that runs in a private network using a private =
address space, and suppose that that network currently uses IPv4. Take as=
 an example a network that uses management or control protocol running be=
tween the routers and separate from the traffic carried over the network.=
=20
My reading of this I-D is that those protocols can be enhanced and featur=
es added provided that those additions are also made such that the protoc=
ols would work perfectly in an IPv6-only network.
If it is not the intention that I should be able to make this reading, th=
en words should be changed.

Thanks,
Adrian






      

        
-----Original Message-----
From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] =
On Behalf Of The
IESG
Sent: 28 September 2017 14:26
To: IETF-Announce
Cc: sunset4-chairs@ietf.org; draft-ietf-sunse=
t4-ipv6-ietf@ietf.org;
su=
nset4@ietf.org; terry.manderson@icann.org
Subject: Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: En=
d Work on IPv4)
to Proposed Standard


The IESG has received a request from the Sunsetting IPv4 WG (sunset4) to
consider the following document: - 'IETF: End Work on IPv4'
  <draft-ietf-sunset4-ipv6-ietf-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits fin=
al
comments on this action. Please send substantive comments to the
ietf@=
ietf.org mailing lists by 2017-10-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning=
 of
the Subject line to allow automated sorting.

Abstract


   The IETF will stop working on IPv4, except where needed to mitigate
   documented security issues, to facilitate the transition to IPv6, or
   to enable IPv4 decommissioning.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-=
ietf-sunset4-ipv6-ietf/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc=
/draft-ietf-sunset4-ipv6-ietf/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-george-ipv6-support: IPv6 Support Within IETF work (None - )



      

      




    

    

  


--------------4224035E20603AE054D2E1F1--

--B3GU8RICaR2T7pd2hBBRiX4reAlL0FgWS--

--xfhCbKgEVONDNI5WbsAdcvV8mLtV5BDVG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZzWTDAAoJEIe2a0bZ0nozbzQH/2G7A+FZvOFSdC6/fanV19/Y
/Wq1/pHHqJHgAZYLMNC1hMDpWql1hlD9NyHlKKxOlDTFDHaK8HUKBwQfde8aBXZe
gnJcOFuBAPahg0RlSRmyAUloenz21y5TfpzxiGsn5dcvtI9zwDWQ3FRgbVVkl4WV
DHtomOzawhrZbvhIeOvNnK6CsaAIPW2gcZdmsI4xFcz9ivkzWZHNst6Klmx+ZWYC
hnWvEiuAWXWBBsiys/8UyzbmMwRhf/Y3HwdJigUKhZnVaKqYSxeJhWp9r+AQuQRQ
q04hW3M1EF9NWrrwMvjSgJQ3KHWA356/pQrc+l2SRBOMKYg0zTuuoCl+HHwa2gk=
=fkDI
-----END PGP SIGNATURE-----

--xfhCbKgEVONDNI5WbsAdcvV8mLtV5BDVG--


From nobody Thu Sep 28 15:40:48 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 2F895134479 for ; Thu, 28 Sep 2017 15:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.799
X-Spam-Level: 
X-Spam-Status: No, score=-3.799 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 2_dMOXvFCxdo for ; Thu, 28 Sep 2017 15:40:40 -0700 (PDT)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 ABED713447E for ; Thu, 28 Sep 2017 15:40:38 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 4583FB3C for ; Thu, 28 Sep 2017 22:40:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9fLLSCvZ0MK for ; Thu, 28 Sep 2017 17:40:38 -0500 (CDT)
Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id BF2CFB2D for ; Thu, 28 Sep 2017 17:40:37 -0500 (CDT)
Received: by mail-wm0-f70.google.com with SMTP id u138so84079wmu.2 for ; Thu, 28 Sep 2017 15:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IXGeIIdRbV2mCHMUv4YHrm89k+HXqkhSr/4uIg+aHz4=; b=H+fPco8ejUxPmDa7DD0yXsDhSgFdeKD2KeUck3YrsI536cpUdZpcODwMmC+eEzbRJ2 GbG0Isr67koMHLsyfQZjhh6+31/XEbp2vMRC3XpQEoQlptMLWiaCOItu6bPcEzJqqClj R/kpUztUi8NTqMsmPlOvb3qKXNDzWFVbdIlOhuc0p2gOxER4Do/VTt4832l/QfzRFUM3 kgLGSFi+EEOgTPeFN1QeVCqEZXwzf7DBB6WrGWIvznGpDTIEb0+dU9YCQn7jkmRQiXqc KtbKGec0anM/+VAe4vpeAijXONLXLjk7QL+sL9jZRqqYLF7nYhSo6GREAzYHgp12oeWA 9baA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IXGeIIdRbV2mCHMUv4YHrm89k+HXqkhSr/4uIg+aHz4=; b=Jbk9o+u9NGGm9QTDLMbeS3YsqPHq6HvM8o49Gv5wwaya/rkf0/sv9A1Ok+AntvbQER vE2t5LJIBak7Brdmtmc3nT4mrV52LcLjY6okPYR+FtmeUoJtX2fE4kbN++vF2M0eZ4nG ikE0zcZyNyyI1uteV2NxTrnQwZSnQx/4SqnCkjFhWEyAZwSCzRMRMApdMgU0bHRkccIs GMAaZ6RVzigxJFk8/45rWCpodxdFgDEah+8RqFLeSROMKsxchBFKlybhyLLSH1x2gqAq cp7AGQeueGB3kuOM3eREZGV1a2/mAIfh7reNfo6t4C/fAqJo34MkYNwrpjRu99wvX939 AV0g==
X-Gm-Message-State: AHPjjUgtSNoXQFOJSANBbPdgdvVpGnHhMhff2RceEzGGmAD73O2m/irc Slym2xmBdv90tqmDGoCfOX66WYlkPTq9icC/pO0AYPNBwdOCTev1fpkeTZ/ix+kx2FXUuhUl3Od f9Fd7UJarAjdLvAymjp/MOs1iKTzN
X-Received: by 10.46.18.71 with SMTP id t68mr2552950lje.132.1506638436115; Thu, 28 Sep 2017 15:40:36 -0700 (PDT)
X-Google-Smtp-Source: AOwi7QDBZHMK+Tfnj/+wr3OsVOt1j4gDZld3oKsAVu9eeu0cfuEk+3rB5q11fUZegyUDoVYAnPk7tCjrobnYewDHqFs=
X-Received: by 10.46.18.71 with SMTP id t68mr2552945lje.132.1506638435907; Thu, 28 Sep 2017 15:40:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.25.212 with HTTP; Thu, 28 Sep 2017 15:40:35 -0700 (PDT)
In-Reply-To: 
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>  
From: David Farmer 
Date: Thu, 28 Sep 2017 17:40:35 -0500
Message-ID: 
To: Lee Howard 
Cc: Phillip Hallam-Baker , IETF Discussion Mailing List ,  IETF-Announce , sunset4-chairs@ietf.org,  draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org
Content-Type: multipart/alternative; boundary="001a114cf2d6c70fc1055a479857"
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, 28 Sep 2017 22:40:42 -0000

--001a114cf2d6c70fc1055a479857
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 28, 2017 at 11:18 AM, Lee Howard  wrote:

>
>
> From: sunset4  on behalf of Phillip
> Hallam-Baker 
> Date: Thursday, September 28, 2017 at 10:34 AM
> To: IETF Discussion Mailing List 
> Cc: , , <
> draft-ietf-sunset4-ipv6-ietf@ietf.org>, IETF-Announce <
> ietf-announce@ietf.org>, 
> Subject: Re: [sunset4] Last Call: 
> (IETF: End Work on IPv4) to Proposed Standard
>
> I remain opposed for the reason I gave last time this was proposed: The
> IETF should retain control of IPv4 and any statement to the effect that t=
he
> IETF will no longer work on IPv4 will inevitably lead to formation of an
> IPv4 legacy standards group in competition with IETF.
>
>
> That would be an interesting development. But the document is hard to
> interpret as =E2=80=9CThe IETF has abdicated responsibility for IPv4.=E2=
=80=9D For
> instance, the third sentence:
>
> Until the time when IPv4 is no longer in
>    wide use and/or declared historic, the IETF needs to continue to
>    update IPv4-only protocols and features for vital operational or
>    security issues.
>
> Similarly:
>
> Some changes may be necessary in IPv4 protocols to
>    facilitate decommissioning IPv4 in a way that does not create
>    unacceptable impact to applications or users.
>
>
> And also:
>
>    The IESG will review proposed working group charters to ensure
>       that work will be capable of operating without IPv4, except in
>       cases of IPv4 security, transition, and decommissioning work.
>
> However the document title does say "IETF: End Work on IPv4", and the
abstract starts with "The IETF will stop working on IPv4".  Many people
might never get past the title and abstract, they easily will be left with
the wrong impression. I seriously doubt most politicians would get much
past the title and abstract.

I have to say, the current title sure makes it sound like work is going to
stop cold-turkey on IPv4. Maybe the title and abstract need a little more
nuance like the body of the text has.

How about something more like this;

Title

   IETF: Limiting New Work on IPv4

Abstract

   The IETF will limit new work on IPv4, except where needed to mitigate
   documented security issues, to facilitate the transition to IPv6, or
   to enable the eventual decommissioning of IPv4 on some networks.

Thanks.

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--001a114cf2d6c70fc1055a479857
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Sep 28, 2017 at 11:18 AM, Lee Howard <lee@asgard.org> wrote:


From=
:  sunset4 <sunset4-bounces@ietf.org> on behalf of Phillip Hallam-Baker=
 <phill@halla=
mbaker.com>
Date:  Thursd=
ay, September 28, 2017 at 10:34 AM
To: =
 IETF Discussion Mailing List <ietf@ietf.org>
=
Cc:  <sunse=
t4@ietf.org>, <sunset4-chairs@ietf.org>, <draft-ietf-sunset4-ipv6-ie=
tf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, <terry.manderson@icann.=
org>
Subject:  Re: [sunse=
t4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End =
Work on IPv4) to Proposed Standard

I remai=
n opposed for the reason I gave last time this was proposed: The IETF shoul=
d retain control of IPv4 and any statement to the effect that the IETF will=
 no longer work on IPv4 will inevitably lead to formation of an IPv4 legacy=
 standards group in competition with IETF.
<=
div style=3D"color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif=
">
That would be an interesting development. But the document i=
s hard to interpret as =E2=80=9CThe IETF has abdicated responsibility for I=
Pv4.=E2=80=9D For instance, the third sentence:
Until the time=
 when IPv4 is no longer in
   wide use and/or declared historic, the IETF needs to continue to
   update IPv4-only protocols and features for vital operational or
   security issues.
Similarly:
Some changes may =
be necessary in IPv4 protocols to
   facilitate decommissioning IPv4 in a way that does not create
   unacceptable impact to applications or users. 

And =
also:
   The IESG will review proposed working group charters to ensure
      that work will be capable of operating without IPv4, except in
      cases of IPv4 security, transition, and decommissioning work.<=
/pre>
However the document title does say "IET=
F: End Work on IPv4", and the abstract starts with "The IETF will=
 stop working on IPv4".=C2=A0 Many people might never get past the tit=
le and abstract, they easily will be left with the wrong impression. I seri=
ously doubt most politicians would get much past the title and abstract.
I have to say, the current title sure makes it sound like work is goin=
g to stop cold-turkey on IPv4. Maybe the title and abstract need a little m=
ore nuance like the body of the text has.

How about something more l=
ike this;

Title

=C2=A0 =C2=A0IETF: Limiting New Work on IPv4<=
br>
Abstract

=C2=A0 =C2=A0The IETF will limit new work on IPv4, e=
xcept where needed to mitigate
=C2=A0 =C2=A0documented security issues, =
to facilitate the transition to IPv6, or
=C2=A0 =C2=A0to enable the even=
tual decommissioning of IPv4 on some networks.

Thanks.

-- 
=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &a=
mp; Telecommunication Services
Office of Information Technology
Unive=
rsity of Minnesota=C2=A0=C2=A0 
2218 University Ave SE=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0=
 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D 


--001a114cf2d6c70fc1055a479857--


From nobody Fri Sep 29 07:59:41 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 21EB4132EA7; Fri, 29 Sep 2017 07:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6vLWlRiD-cfH; Fri, 29 Sep 2017 07:59:33 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 803AA132396; Fri, 29 Sep 2017 07:59:33 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id j126so2413461oia.10; Fri, 29 Sep 2017 07:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ie/QMx9q7RTTFkBJur5HHA4pLr/5eXxSLNvQILF1Dio=; b=bXk1yNwAUpZnoyBf1+Zkfmq27KoRfxg5R/onaZccKD6uRoQOMQ1G7rB4doEbFb5Rcj jioK+8W7n5mfmwYr8reBWGJbW3zYkO3NtvqnmVe4YtpQYTtn71IJkufZmYqTWgHGiPRq pRSWKqiK3pdrDV1jZKamdxymLXxpgGwOMAi46+P+Trxo6rPvzSsQBTBvuKcZAQY3Gtu2 0WqGKiuViz4c3ZnxrdnH/NdG1B/1YAn2nWOobXyEy3N8SpRzU/0WSWbv5YsRAF9dC2fP fNk6uZlvZKbB/sha7Qgq2msq0iy5CqBVQTsvjON+qSdQBEovmdJpGM4Wm6cenf0iO/ML 5hlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ie/QMx9q7RTTFkBJur5HHA4pLr/5eXxSLNvQILF1Dio=; b=sWPBQcniBF2t9Ty6h3FAF3Afdzhzwc/OWjaRlKDg1hTsKav5E/nTsGaZADTVW3aHrU 8XZQZ3hUxW6ZyVEonkK+grKbSKne+cj0YsIBtBpztbhlE4Vg9mjb39NxGhNIm+kypdya p63NuWfPwxe7LzP690AlrWB1SrXf8DuDcllxjnld0yLE+hQ3zzmDSBTXB/1h0xK23uMs xU8xjtTibx8YVdqLUlyBuI+jUhK8m0vJAixKtUrzVQkMlIHbwnE1QSrhpfG4PZQOmE4u /6S6tWVCsbI6xt67M5Y0+ja4jXSy6a7FNi2YnQ/zeojETnJZS79epycc9Eqn8Y+eU4x2 zy7A==
X-Gm-Message-State: AMCzsaXZO6vKeRfcP5hX2wmoqcGCXve6r7Ffq8y9jZxqLpq9zmTF/TUV dzkFIxW17Vq8DsKoLmhgv0oJnHlcBCmgbhGOdvhv1A==
X-Google-Smtp-Source: AOwi7QDaoqjJK7GxCv4sk6//Gu1bsIdWRvEsi/2svJmr1OvNTjYLdRCmhdTMBf+LfgcuigKLMe5noLbZMzRGw2q3B4o=
X-Received: by 10.202.197.130 with SMTP id v124mr2314745oif.265.1506697172885;  Fri, 29 Sep 2017 07:59:32 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.95.12 with HTTP; Fri, 29 Sep 2017 07:59:32 -0700 (PDT)
In-Reply-To: 
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>  
From: Phillip Hallam-Baker 
Date: Fri, 29 Sep 2017 10:59:32 -0400
X-Google-Sender-Auth: hLdsDlyzqoNoCzQavU6jZyoXufY
Message-ID: 
To: Lee Howard 
Cc: IETF Discussion Mailing List , sunset4@ietf.org, sunset4-chairs@ietf.org,  draft-ietf-sunset4-ipv6-ietf@ietf.org, IETF-Announce ,  terry.manderson@icann.org
Content-Type: multipart/alternative; boundary="001a1134fac0c6328a055a5545c5"
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: Fri, 29 Sep 2017 14:59:35 -0000

--001a1134fac0c6328a055a5545c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 28, 2017 at 12:18 PM, Lee Howard  wrote:
>
> Then change the name to NPv4?
>
> Do we care what people do on their private networks? Is it any of our
> business?
>
> Lee
>
>
=E2=80=8BSince network use of IETF protocols is at least as important as In=
ternet,
yes it is very much IETF business if it wants to remain relevant.

As for what the IPv4 consortium would do, I wrote out a draft list:

* Determine IPR policy.
* Chose venues for upcoming meetings.=E2=80=8B
* Form advisory committees.
* Hold elections to advisory committees.
* Set a schedule of membership fees.

And that is just for starters.

--001a1134fac0c6328a055a5545c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Thu, Se=
p 28, 2017 at 12:18 PM, Lee Howard <lee@asgard.org> wrote:
Then change the name to NPv4?

Do we car=
e what people do on their private networks? Is it any of our business?

Lee


=E2=80=8BSince ne=
twork use of IETF protocols is at least as important as Internet, yes it is=
 very much IETF business if it wants to remain relevant.

As for what the IPv4 consortium would do, I=
 wrote out a draft list:

=
* Determine IPR policy.
* Chose venues for upcoming meetings.=E2=80=8B
* Form advisory committees.
<=
div class=3D"gmail_default" style=3D"font-size:small">* Hold elections to a=
dvisory committees.
* Set a schedule of membership fees.

And that is just for starters.


--001a1134fac0c6328a055a5545c5--


From nobody Fri Sep 29 08:14:22 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 F33FC133055; Fri, 29 Sep 2017 08:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 B1QNo3xbV_q8; Fri, 29 Sep 2017 08:14:12 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 DE7C6132396; Fri, 29 Sep 2017 08:14:11 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id t69so157911wmt.2; Fri, 29 Sep 2017 08:14:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=wjt6TsIHDiL9M52l+e+kh7AJy4s+6OAms62WNnTm6j4=; b=a/Dnh35wRrFmnO2uwhFkfphcFWr/oKj8q4X60SA44WpV4GccxJ0QVj4cZ+xFKmIwcB fJ1reRkMXfUX0F6673ozLM+IBp4QRA8n9lPcogjWiuFkBq2UKoXtsbWLEVMHlRFbKtB8 RP25+FtF1sSwp3Tv80rMgQJoXBZBVHgqeOX3ZGypQsbzHXQba4wJqk7gc+iwStYb7E9g 9DIrrZF8//3qcexSo/EpeVTDwQXpMAZAIkRtkSsFKyIKxR8H2gFefpFy3A8XIgE2dfJ4 99EfLmjuneysCJ4TR8XGdTMf12dOLEAuqpuZ2IH1SDaAfnSSX0v4BmlQ3D8J60g4NWi/ Xf2A==
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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=wjt6TsIHDiL9M52l+e+kh7AJy4s+6OAms62WNnTm6j4=; b=dUvERgk5jr2ZPOt/Q7bK9bpC/0YD3TuVhRT9UxLJp8BeEC0WFvhw6gqsnl3mQreq5M hxwJRom8/AL76liypDI5eLtmHAZ3hH5Sz78MPuOOUuv8F0fsWyR0JgW7pKk6FA+AFddY RiLJiwzlq8XS6o/JPmX7oKL9VgBtvb2AVX1FptJqlMsav6sebKTOtJKaBSC6va/Xw2BA HotS5GV+PmNW1ZwDX/+flOrW0TRE8TARNXrcr9U/HwgQGZksy0HJPhUtuRm23dTnmQWD J+vqbzwoFO6KmUFeaqIFMnXGRfJbUX3YX8TuUmeQZzPlNo6CDxbIx+tIkyn3zhOi1hJG KxuQ==
X-Gm-Message-State: AHPjjUgz9O1ONEdr5wD8l+dq8o76f3hJUq1UmN+TF+dE2K/iXI0Cy94P QIhKHEyV1mPtQDVzSFL8QTWC+EPy
X-Google-Smtp-Source: AOwi7QAOi4o4eJxyVjXP6beXk9Qv7e1HKBRZ2VAvpf88f+ujLaf4/tzWhdiI9CSB2RmGPLX7tEzvUg==
X-Received: by 10.80.221.11 with SMTP id t11mr10196230edk.84.1506698050206; Fri, 29 Sep 2017 08:14:10 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id a99sm4044522edf.54.2017.09.29.08.14.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 08:14:09 -0700 (PDT)
To: Phillip Hallam-Baker , Lee Howard 
Cc: IETF Discussion Mailing List , sunset4-chairs@ietf.org, sunset4@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, IETF-Announce 
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>   
From: Stewart Bryant 
Message-ID: <0b0b3277-e8b6-697d-f886-d332ca68185d@gmail.com>
Date: Fri, 29 Sep 2017 16:14:06 +0100
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="------------6F490A024B52116D29AB3088"
Content-Language: en-GB
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: Fri, 29 Sep 2017 15:14:14 -0000

This is a multi-part message in MIME format.
--------------6F490A024B52116D29AB3088
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 29/09/2017 15:59, Phillip Hallam-Baker wrote:
>
>
> On Thu, Sep 28, 2017 at 12:18 PM, Lee Howard  > wrote:
>
>     Then change the name to NPv4?
>
>     Do we care what people do on their private networks? Is it any of
>     our business?
>
>     Lee
>
>
> ​Since network use of IETF protocols is at least as important as 
> Internet, yes it is very much IETF business if it wants to remain 
> relevant.
>
> As for what the IPv4 consortium would do, I wrote out a draft list:
>
> * Determine IPR policy.
> * Chose venues for upcoming meetings.​
> * Form advisory committees.
> * Hold elections to advisory committees.
> * Set a schedule of membership fees.
>
> And that is just for starters.

... and they might perhaps figure out some technology wheeze that we did 
not notice, or which was less pure than we would accept, but none the 
less acceptable to most users, and thereby find a way to extend the 
service life of IPv4.

- Stewart



--------------6F490A024B52116D29AB3088
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 29/09/2017 15:59, Phillip
      Hallam-Baker wrote:

    

    

      

        


        

        


          
On Thu, Sep 28, 2017 at 12:18 PM, Lee
            Howard <lee@asgard.org>
            wrote:
            

              

                
Then change the name to NPv4?

                


                

                
Do we care what people do on their private
                  networks? Is it any of our business?

                
                    


                    

                    
                      

                        
Lee

                      

                    
                      

                        


                        

                      

                    

            

            


            

            
​Since
              network use of IETF protocols is at least as important as
              Internet, yes it is very much IETF business if it wants to
              remain relevant.

            


            

            
As for
              what the IPv4 consortium would do, I wrote out a draft
              list:

            


            

            
*
              Determine IPR policy.

            
* Chose
              venues for upcoming meetings.​

            
* Form
              advisory committees.

            
* Hold
              elections to advisory committees.

            
* Set a
              schedule of membership fees.

            

            


            

            
And that
              is just for starters.

          

        

      

    

    

    ... and they might perhaps figure out some technology wheeze that we
    did not notice, or which was less pure than we would accept, but
    none the less acceptable to most users, and thereby find a way to
    extend the service life of IPv4. 

    

    - Stewart

    

    

  


--------------6F490A024B52116D29AB3088--


From nobody Fri Sep 29 08:25:27 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 057DD13214D; Fri, 29 Sep 2017 08:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NuHMRcgd4WrS; Fri, 29 Sep 2017 08:25:18 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 69DEF12EC30; Fri, 29 Sep 2017 08:25:18 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id x85so2535926oix.12; Fri, 29 Sep 2017 08:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=V1ZhOoO53Wh6w6CTZyh7HFDIz4CHtb9tCI2KY5N5ocQ=; b=Qj/riG3aqUPlVEkFuX5hBT2Ca6kbOzzZZfjQcztRjVsn9d3TDBn1wvhnsI5xzAccPS lFH9j0iHdYzk1rwxDHhp2JCAHiHFft+/Dq7J08Qdva9R8QKDJfY+yDLlSNk6ECcJpFEW ntGVV/R5xuUWDBUBFJl+NjJzfp+uj6E8oteS+GVVXNVSHUHUOmDYCIyz+jEO5EtyE3RX Vkj7N5BOjbRZsgQM9g7Xrrpl23o1IRV3qIEG8zXYs/GnCl+sp2bemXaAk66tcmd6JCjP KF7kT6Uz+y8P0lX5f2+xaWNxGL9HuwSqqRx0qPiSlzYcI7DJk++Ip9bsYRJDCZVrS8o6 nA3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=V1ZhOoO53Wh6w6CTZyh7HFDIz4CHtb9tCI2KY5N5ocQ=; b=UPArUQP0UXfycBXmah+KlOO8Sk3Y7nTzNeUnQCQwUr7apJPs4K96GjxgXM5d7K7QX1 RMmkGZ20KIAK4aFUPo2HGS6NVRpRO93wDbrLTG7+OppyMwy3wqIU/tLGYgkGcfpc2aHj ds4en7f+EkgQZb+QsubyQHf59RQGbnXtCYM1gOzUq1CV7tmtHKYvfzFwBXjmyFbPVIro FIsmyaKk3xC3szCbCcVSg0G4Xv5akMOncAItHhO1uuxhwr1JLYZE1rGGqeIpXejoNWM/ /moWA+GaOKbV1jLPmBOuN3IeJAo3ylHBqn/vexH1EZJt81HMtuJ/WhUF2jgULxOuvLjh WOBw==
X-Gm-Message-State: AMCzsaXfkd7sPckmnCYtSfkp7X354U9Wcq+hmMJ5R1toQQWDqgAx9/In Q4bdhtFUsQjO65Gb2t2nTYS8qmrnQuFjuH5TvE0=
X-Google-Smtp-Source: AOwi7QCQnDONvRmCAc56odUM8rdluKj1pKpDeJ+NljiQT+i6DTo3eyTla6RquW5rZ6nsKFFyf/bLqJj8eHxgU8DVTIw=
X-Received: by 10.202.253.209 with SMTP id b200mr2769928oii.279.1506698717803;  Fri, 29 Sep 2017 08:25:17 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.95.12 with HTTP; Fri, 29 Sep 2017 08:25:17 -0700 (PDT)
In-Reply-To: <0b0b3277-e8b6-697d-f886-d332ca68185d@gmail.com>
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>    <0b0b3277-e8b6-697d-f886-d332ca68185d@gmail.com>
From: Phillip Hallam-Baker 
Date: Fri, 29 Sep 2017 11:25:17 -0400
X-Google-Sender-Auth: mS2galZD-SJ_Cu3O_Av4DOKUu3g
Message-ID: 
To: Stewart Bryant 
Cc: Lee Howard , IETF Discussion Mailing List ,  sunset4-chairs@ietf.org,  sunset4@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org,  IETF-Announce 
Content-Type: multipart/alternative; boundary="001a113d36f8dbb961055a55a16b"
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: Fri, 29 Sep 2017 15:25:20 -0000

--001a113d36f8dbb961055a55a16b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 29, 2017 at 11:14 AM, Stewart Bryant 
wrote:

> On 29/09/2017 15:59, Phillip Hallam-Baker wrote:
>
>
>
> On Thu, Sep 28, 2017 at 12:18 PM, Lee Howard  wrote:
>>
>> Then change the name to NPv4?
>>
>> Do we care what people do on their private networks? Is it any of our
>> business?
>>
>> Lee
>>
>>
> =E2=80=8BSince network use of IETF protocols is at least as important as =
Internet,
> yes it is very much IETF business if it wants to remain relevant.
>
> As for what the IPv4 consortium would do, I wrote out a draft list:
>
> * Determine IPR policy.
> * Chose venues for upcoming meetings.=E2=80=8B
> * Form advisory committees.
> * Hold elections to advisory committees.
> * Set a schedule of membership fees.
>
> And that is just for starters.
>
>
> ... and they might perhaps figure out some technology wheeze that we did
> not notice, or which was less pure than we would accept, but none the les=
s
> acceptable to most users, and thereby find a way to extend the service li=
fe
> of IPv4.
>
> - Stewart
>

=E2=80=8BLike running IPv4 on the internal network and only translating to =
IPv6 at
the interface? That is exactly what I would expect such a body to develop.=
=E2=80=8B
And the reason companies not represented in IETF would be more than happy
to pay to join such a consortium is that gifting $50K/year to develop
standards to keep their legacy systems running would be a lot cheaper than
paying network equipment vendors millions to upgrade all the gear in their
company.

--001a113d36f8dbb961055a55a16b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On =
Fri, Sep 29, 2017 at 11:14 AM, Stewart Bryant <stewart.bryant@gmail=
.com> wrote:

 =20
   =20
 =20
  

    
On 29/09/2017 15:59, Phillip
      Hallam-Baker wrote:

    

      

        


        

        


          
On Thu, Sep 28, 2017 at 12:18 PM, Lee
            Howard <lee@asgard.org>
            wrote:
            

              

                
Then change the name to NPv4?

                


                

                
Do we care what people do on their private
                  networks? Is it any of our business?

                
                    


                    

                    
                      

                        
Lee

                      

                    
                      

                        


                        

                      

                    

            

            


            

            
=E2=80=8BSince
              network use of IETF protocols is at least as important as
              Internet, yes it is very much IETF business if it wants to
              remain relevant.

            


            

            
As for
              what the IPv4 consortium would do, I wrote out a draft
              list:

            


            

            
*
              Determine IPR policy.

            
* Chose
              venues for upcoming meetings.=E2=80=8B

            
* Form
              advisory committees.

            
* Hold
              elections to advisory committees.

            
* Set a
              schedule of membership fees.

            

            


            

            
And that
              is just for starters.

          

        

      

    

    

    ... and they might perhaps figure out some technology wheeze that we
    did not notice, or which was less pure than we would accept, but
    none the less acceptable to most users, and thereby find a way to
    extend the service life of IPv4. 

    

    - Stewart

=E2=80=8BLike running IPv4 on =
the internal network and only translating to IPv6 at the interface? That is=
 exactly what I would expect such a body to develop.=E2=80=8B And the reaso=
n companies not represented in IETF would be more than happy to pay to join=
 such a consortium is that gifting $50K/year to develop standards to keep t=
heir legacy systems running would be a lot cheaper than paying network equi=
pment vendors millions to upgrade all the gear in their company.





--001a113d36f8dbb961055a55a16b--


From nobody Fri Sep 29 18:48:10 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 50DDE1342D3; Fri, 29 Sep 2017 18:48:08 -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 MoRM9j-PjvD9; Fri, 29 Sep 2017 18:48:07 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 0E3C1133032; Fri, 29 Sep 2017 18:48:07 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id z84so625493pfi.2; Fri, 29 Sep 2017 18:48:07 -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=5GXIFAvtfi/q53ONR3zsDJbu7zjE6SWjBh12rNDtbAI=; b=FTy5BUEnzP+GVlcIpRBJNYVEZxou5kCdDvDlMoZY50feONANMTyY5aCYWEUEKpbiC4 M9jLa/yrtPYJUhJ0uAEpYSekjl/jJTEi58On8qteWdwbpIMwSFlVlGm20RdhSUocZRnh rIKnnkxRqxZZDRDIOwi1TCfWDdg/1+DqX26d0H0M63tgWuPK+KqInXi0KbATsKoso2f1 J216xKi7I7Uw94KPO/IC+F/9sGRPw7LSACuTihaikqtTHU1jQL7AxwFK5+BV5FBHy2gT Uvy3sr0FN/spo5OD1HHmjnLNnbKYu8LXzqpwieRaoMN0gPOdUNNjM7qcD+VcvN6iq8Zw hFMA==
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=5GXIFAvtfi/q53ONR3zsDJbu7zjE6SWjBh12rNDtbAI=; b=gMIxrNkPbglntaoNsukHKzycPvgILyrJAs4ILbz6kC0aBCzHoWn3Lh/BYIOuqdVsUY HpYYmWBeEHbn5GH5LWoEo4y6FhdGMJ7sb5FoFyQTFEn4CJitXPLf60+xTAHEc0DkuJ+f HsUHCgWh+YNUhv2kgYOnb4y7YNnJBSls1YpyLQdJzb7UqV4lMtEVWT1ZrgsoqCpcFJhY QzKSvFfKydJKY7/VC71zEH+oWY7XihXfJuEWxzhmCKORSi/V3zAUSSrpY0e2lNIIAsnh OlroDMcQn8RrQxqY4L+Hkbn0bFOi3+4MLOFcnM8s5lzkJ3guV/Lf4CM1pMri/cmzp+3w 32iA==
X-Gm-Message-State: AHPjjUjeEmJcKsY9H5KAoSdhEjiftD9poYB8pEBnpO1ruverE0EpaAqa sqvVAo4Vp+AXdSONe2lXa4w=
X-Google-Smtp-Source: AOwi7QBTwWwucyeHGq1Iy5ti69HjRu8B/YRPOfmQ5e8FGe5wjyjmW5ImByaMFgcajAnNUcIbwE1ITw==
X-Received: by 10.101.92.6 with SMTP id u6mr7468909pgr.198.1506736086579; Fri, 29 Sep 2017 18:48:06 -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 p85sm9471487pfj.47.2017.09.29.18.48.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 18:48:05 -0700 (PDT)
To: ietf@ietf.org
Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org, terry.manderson@icann.org
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Sat, 30 Sep 2017 14:48:13 +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: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.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: Sat, 30 Sep 2017 01:48:08 -0000

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.

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.

The rest will take care of itself. There's no need to preach.

A few suggestions follow. The main problem at the moment is
too many words.

Abstract

   The IETF has stopped working on solutions that are specific to
   IPv4, except where needed to mitigate documented security issues,
   to facilitate the transition to IPv6, or to enable IPv4
   decommissioning.
...
1.  Statement

   The IETF has developed IPv6 to replace IPv4.

   Ongoing focus is required to ensure that future IETF work supports
   the evolution of the Internet towards IPv6-only operation. However,
   until the time when IPv4 is no longer in widespread use, the IETF
   needs to continue to update IPv4-only protocols and features for
   vital operational or security issues...
   ...
      The IESG will review proposed working group charters to ensure
      that new work will be capable of operating with IPv6, and with
      or without IPv4.

Note: that "with or without" is important if we expect to be taken
seriously.

      The IETF will update IPv4 protocols and features only to
      repair serious security faults or to facilitate IPv4
      decommissioning and IPv6 transition.

and delete this because it's redundant after the above changes:

      New IETF work will explicitly support IPv6, or be IP version
      agnostic (because it is implemented above the network layer),
      except IPv4-specific transition technologies.

Regards
   Brian Carpenter


From nobody Sat Sep 30 02:48:18 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 05E351321DC; Sat, 30 Sep 2017 02:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 e3p_d2KkQVJL; Sat, 30 Sep 2017 02:48:09 -0700 (PDT)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 253A01329F9; Sat, 30 Sep 2017 02:48:09 -0700 (PDT)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 46C3F31D12; Sat, 30 Sep 2017 11:48:06 +0200 (CEST)
Received: by mail.sources.org (Postfix, from userid 1000) id 5C62619000B; Sat, 30 Sep 2017 11:45:57 +0200 (CEST)
Date: Sat, 30 Sep 2017 11:45:57 +0200
From: Stephane Bortzmeyer 
To: Eliot Lear 
Cc: adrian@olddog.co.uk, ietf@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org
Message-ID: <20170930094557.hmhcgsjoagfq52xv@sources.org>
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> <01ce01d33887$b8c3b390$2a4b1ab0$@olddog.co.uk> <66239ec4-8fb0-15a5-6433-bb8decea96f2@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <66239ec4-8fb0-15a5-6433-bb8decea96f2@cisco.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 9.1
X-Charlie: Je suis Charlie
User-Agent: NeoMutt/20170113 (1.7.2)
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: Sat, 30 Sep 2017 09:48:12 -0000

On Thu, Sep 28, 2017 at 11:08:19PM +0200,
 Eliot Lear  wrote 
 a message of 418 lines which said:

> I have these questions:
> 
>  1. If I wish to add a new DHCPv4 option as well as a similar DHCPv6
>     iption, would that contravene the intent of this document?
>  2. If I wish to add a field that would permit IPv4 addresses and IPv6
>     addresses, would that contravene the intent of this document?

For me, section 1 of the draft is crystal-clear "No IPv4-only feature
will be added unless there's an equivalent feature added in the IPv6
version." Which means the answer is No to your two questions.


From nobody Sat Sep 30 02:53:09 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 B95461344B9; Sat, 30 Sep 2017 02:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lH44h3-6ibJh; Sat, 30 Sep 2017 02:53:07 -0700 (PDT)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 BAA3D1344B5; Sat, 30 Sep 2017 02:53:07 -0700 (PDT)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 656D131D12; Sat, 30 Sep 2017 11:53:06 +0200 (CEST)
Received: by mail.sources.org (Postfix, from userid 1000) id 3201319000B; Sat, 30 Sep 2017 11:48:30 +0200 (CEST)
Date: Sat, 30 Sep 2017 11:48:30 +0200
From: Stephane Bortzmeyer 
To: Stewart Bryant 
Cc: ietf@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org
Message-ID: <20170930094830.eqzyj2rjqvg3nted@sources.org>
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> <1c9d4fae-cae8-5669-ec4b-f8029ee6ede4@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1c9d4fae-cae8-5669-ec4b-f8029ee6ede4@gmail.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 9.1
X-Charlie: Je suis Charlie
User-Agent: NeoMutt/20170113 (1.7.2)
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: Sat, 30 Sep 2017 09:53:08 -0000

On Thu, Sep 28, 2017 at 06:17:24PM +0100,
 Stewart Bryant  wrote 
 a message of 60 lines which said:

> A lot of the world still relies heavily on IPv4, and many countries
> would rightly regard IPv4 as critical national infrastructure.

So what? The draft never says "IPv4 MUST be shutdown tomorrow".

> If the IETF announces that it is no longer supporting IPv4,

The draft says nothing like that, quite the opposite.

I think the discussion derailed from an actual draft to a fight
against a strawman.