Re: [arch-d] Call for Comment: <draft-iab-protocol-transitions> (Out With the Old and In With the New: Planning for Protocol Transitions)

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 10 January 2017 00:51 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9721296A2 for <architecture-discuss@ietfa.amsl.com>; Mon, 9 Jan 2017 16:51:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] autolearn=unavailable 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 PdS7I6XcDwPD for <architecture-discuss@ietfa.amsl.com>; Mon, 9 Jan 2017 16:51:09 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 8D8C7129665 for <architecture-discuss@ietf.org>; Mon, 9 Jan 2017 16:51:09 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id 127so36443522pfg.1 for <architecture-discuss@ietf.org>; Mon, 09 Jan 2017 16:51:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=jHIQ6OTGem6SdoozgS9FxFGBoe1xDkF9NV591wvA1hE=; b=vVJRGauuU6t8Fb7QQRIQwxpRMMrRKehkI5+1I36SS6eWyFR9IFyJLFBvsrNmJ0iVs8 mryX2IEl2GWhyUnokJXsKpyx57mrZrxtA3LQgLBHxeEZa1VmPyD4UyaRsrKrPABFYYzL GAtDVDmfWC/LGHopsUm4ZDuM9Z2eF16GgSjzxWjKeLTeirhApg4c8w112akuOitJW2YZ Za8q0mtEDNxZQIwYGxSyq8X6Pr+zPiIS9ZdUoV7yHTM5bZV1pghbNRJJ1mLam9UbH/Gl bwhZb1Gh7lSKuO8hhSC+yKscwLDtlEtPDXDwx3Gs7yXUjKz8cixZMtTpRFXVqBwjX2+j QSKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=jHIQ6OTGem6SdoozgS9FxFGBoe1xDkF9NV591wvA1hE=; b=Keq2ku5ixVLt+/loBwvqSZqCTYAjs6z/e+jckSJSxi18q4GKqacepbvoDpgGKwuaMw umHGOU1TKLCU9NDwf0YqQsJS3UwyYNg0sQsjH6mafPjVPj2cFZl4VyOttbeaULBFw0Q3 lW0YIKFB7TFWoef4uDvwIm3Z2CC//FJZcUe6GXnvYB7wcb7KnNUdkxt2SlQHiRCXeX8G JEnPGhhwQ88Tgt10HKI9nmawmpYcXZYtAemxXB75/j/2NxnaK452fzuZtfFOzEaCIMFX 2KM1+ZoVb3mVDDT98wC2Lu3JeaDhTjxhfn2dhtWKrE7OvJWmn7EcW842Wq8UY7PzOGYF DClw==
X-Gm-Message-State: AIkVDXILVehCIX3tKC8NpNzFMjTNHcsG1f4En0HWlMos4Ae1RsfKOzDZvSErs5Q11Z/8Zg==
X-Received: by 10.84.217.19 with SMTP id o19mr783221pli.21.1484009469108; Mon, 09 Jan 2017 16:51:09 -0800 (PST)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id s136sm211474pgs.46.2017.01.09.16.51.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 16:51:08 -0800 (PST)
To: architecture-discuss@ietf.org, iab@iab.org
References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <3f8254a6-ff3f-e944-3ef9-6ce2bf36df93@gmail.com>
Date: Tue, 10 Jan 2017 13:51:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/4-sjwP-INboBKu-JuvrOlAy4S9s>
Subject: Re: [arch-d] Call for Comment: <draft-iab-protocol-transitions> (Out With the Old and In With the New: Planning for Protocol Transitions)
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2017 00:51:11 -0000

I think this is now in pretty good shape.

There is one aspect of the IPv6 case study that might, or might not,
be useful to mention. I refer to a tendency for overstated claims,
some of which were just exaggerated and some of which were simply
untrue. This didn't come from IETF sources. In fact some of us
ran around after the perpetrators giving talks about "IPv6 myths".
For example, there was a persistent myth that IPv6 was more secure
than IPv4. (There was also a myth that IPv6 was less secure than IPv4.)

This was highly unhelpful, especially when it infected the government
mandates.

Regards
   Brian

On 05/01/2017 14:17, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on 
> draft-iab-protocol-transitions-05.
> 
> The document is being considered for publication as an Informational RFC 
> within the IAB stream, and is available for inspection at:
> https://datatracker.ietf.org/doc/draft-iab-protocol-transitions/
> 
> The Call for Comment will last until 2017-02-01. Please send comments to
> architecture-discuss@ietf.org and iab@iab.org.
> 
> Abstract
> 
>    Over the many years since the introduction of the Internet Protocol,
>    we have seen a number of transitions from one protocol or technology
>    to another, throughout the protocol stack.  Many protocols and
>    technologies were not designed to enable smooth transition to
>    alternatives or to easily deploy extensions, and thus some
>    transitions, such as the introduction of IPv6, have been difficult.
>    This document attempts to summarize some basic principles to enable
>    future transitions, and also summarizes what makes for a good
>    transition plan.
> 
>