IETF Logo Mail Archive

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> Wed, 04 October 2017 22:18 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 68782132F3F; Wed, 4 Oct 2017 15:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YljS36evm9f7; Wed, 4 Oct 2017 15:18:01 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E57F120724; Wed, 4 Oct 2017 15:18:01 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id m63so6961251pfk.7; Wed, 04 Oct 2017 15:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YV1Pq15Zzv8DIN9D+OYssBH9PX6ZqgcJ5JdgQ/Eix7k=; b=ebHFl3Gm56iHCeimmAJUbhmYd29/o0hx2MkFgxySHyNilysMRgMsTgavZW2TXi1i5F wa1lHoKvyEq1YXy34Cyfvq3DszJVJZgLuhVU507muQ4I0cHm5+6DMjrkFSYrvp/Oa9Ml WdTg3pYmrkl9vfVL5jPRKDS4lzSqJtjPz6p4/ahLdScrhB+xkcMdPo3wj4nyM4qgiT+6 zcN7QLyMgiHl2U+AKHz3Ej7xxo46LSlLWI8ia4gjDgLzk+qnMyO88ZXk0EHODCzVEfUZ XGnJ8ftnt1Xa3dDm7KewtT6LkZVzmAFh1wFtH0a+fRWvQq5basFndMA/AFqIDNJru4vM X2sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YV1Pq15Zzv8DIN9D+OYssBH9PX6ZqgcJ5JdgQ/Eix7k=; b=XXIA/0p9OQVclWmmrdNR6L6dtAvWLavXGyWUUQFTPMLmiWGp/uXXyNct+mqlrzE2nY txstN/mb8gOLIxO1tQAun4WCJhcLgghr0yMzJXubeCY0PLk/oGRb2OJWy8oXb42TYSM3 +maI/3NifhNfVpbQcMZe9DOj5hZ4AIwc4FjlvTfZ1G2G7I1a/EHW3NIqeFcyjlJVC9DM jRQVgyg1vsl3QNni7lGZ5qR+f+zhS6hvvlhuY2fcxG990KnmV0q1lV69JfbdWWlMvVFD lmcQawLrtmhKs8PuqIOxfVd8lOCDHxqMsRstG2CHz4J9muvzRJz51KrRVYstIc0FeYlo mIxQ==
X-Gm-Message-State: AHPjjUiCrKUiICaxmfPeQT7ceENRB8/GebTxxo8Ti3amM/F6/8FTMRr9 Yzq9ae3xo8hh6nK/PoGVvmpnUg==
X-Google-Smtp-Source: AOwi7QCTqMXfxS8pXMwYwgnwOcK9JImhbtWFntXyXs5GVZ3zhg2R82vLqxo+lFe2on7A2frEkH/CMQ==
X-Received: by 10.84.129.106 with SMTP id 97mr20787277plb.268.1507155480775; Wed, 04 Oct 2017 15:18:00 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j67sm18033616pfj.1.2017.10.04.15.17.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Oct 2017 15:17:59 -0700 (PDT)
To: Joe Touch <touch@strayalpha.com>, ietf@ietf.org
Cc: sunset4-chairs@ietf.org, draft-ietf-sunset4-ipv6-ietf@ietf.org, sunset4@ietf.org
References: <150660518277.13796.5801483741214576151.idtracker@ietfa.amsl.com> <e007e7cd-7df8-bd9a-98d2-956d08fa4307@gmail.com> <0766e92f-9b1d-d59e-5395-8c05c745f3b1@strayalpha.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <a2ec0242-85ed-8fd0-ee2e-83e7173f22e8@gmail.com>
Date: Thu, 05 Oct 2017 11:18:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <0766e92f-9b1d-d59e-5395-8c05c745f3b1@strayalpha.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sunset4/F_mlvJ6QxgzFZehmDSWsGo_mXBQ>
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: Wed, 04 Oct 2017 22:18:03 -0000

On 05/10/2017 01:38, Joe Touch wrote:
> 
> 
> On 9/29/2017 6:48 PM, Brian E Carpenter wrote:
>> First of all, I agree with those who have said this should be
>> a BCP, if published. BCPs are the way we publish IETF process
>> rules.
> A BCP with the right tone and focus might be useful.
> 
>> Secondly, I think many of the comments about the tone and slant
>> are correct. What we want to stop is work on solutions that
>> are *specific* to IPv4, and to chase down and elminate any
>> cases where successful IPv6 operation depends on the presence
>> of IPv4.
> 
> I disagree.
> 
> We need to consider IPv4 work as "maintenance mode", which can easily
> include solo IPv4 adjustments and/or include IPv4 support in new
> protocols that also support IPv6. Neither necessarily need involve
> transition or deprecation.

I'm not sure that we disagree modulo wordsmithing. Saying that IPv4
is in maintenance mode is fine. Security and bug fixes are clearly
maintenance.
 
> "no new work" or "no IPv4-specific work" both assume that IPv6 is a
> superset of IPv4, which it is not.

I don't see that assumption either stated or implied. If there are
features missing in IPv6, that's a completely separate topic.

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

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

Regards
   Brian

v2.23.0 | Report a Bug | By Email