Re: [sunset4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4) to Proposed Standard

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 30 September 2017 01:48 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <e007e7cd-7df8-bd9a-98d2-956d08fa4307@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/sunset4/0DU6s-9E6Y5tSbjTXAhmGGWREw4>
Subject: Re: [sunset4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (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 <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=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