From nobody Wed Jan 4 23:17:15 2017 Return-Path: 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 BF9D01298BC for ; Wed, 4 Jan 2017 23:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 SwF82PEvyXYQ for ; Wed, 4 Jan 2017 23:17:12 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2059E12947E for ; Wed, 4 Jan 2017 23:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13165; q=dns/txt; s=iport; t=1483600632; x=1484810232; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=cUgVexGuzVUzKEjO4p0Vne9lLE0QcfrtK+YuEdUAPKM=; b=QlLA5KlA2oulRXkj14hKdENbn+4Ye71sw3+/AgyJie2qwNwi3AmfRaAa jAMN1V/YiE8uxLlP6NEl1zGtYuZxr+Ls9iku2EB0fQulTUOS/1mqLnVb7 iyo5dsy39gXQ8m6mO5QIq6UAkTVDARKercWrUtfsa+jJqI5Vkmurp8n5Q M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAQDO8W1Y/xbLJq1HFhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM4AQEBAQF+L12NV3KTVo96hSqCCSqCQoM2AoIXFAECAQEBAQE?= =?us-ascii?q?BAWMohGkBBR0GZgsSBhMQBwICRgMOBwwGAgEBiGwOrzqCJSuJfQEBAQcBAQEBA?= =?us-ascii?q?QETCgWIR4FZgQaEEByDIoJeBZsQg2WBfnOCT4gdgXaFCIMnhjWSRB84gQ8SBxM?= =?us-ascii?q?VhQ+BSD01iGYBAQE?= X-IronPort-AV: E=Sophos;i="5.33,319,1477958400"; d="asc'?scan'208,217";a="648513697" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 07:17:09 +0000 Received: from [10.61.99.65] (dhcp-10-61-99-65.cisco.com [10.61.99.65]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v057H942000365; Thu, 5 Jan 2017 07:17:09 GMT To: architecture-discuss@ietf.org, iab@iab.org References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> From: Eliot Lear Message-ID: Date: Thu, 5 Jan 2017 08:17:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XhKbwDqQOkb0753faSpTJF48qSlRgiNmg" Archived-At: Subject: Re: [arch-d] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 07:17:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XhKbwDqQOkb0753faSpTJF48qSlRgiNmg Content-Type: multipart/mixed; boundary="nMoUKkAvGK3MbgdCD1UPJBBl8kHafVXfo"; protected-headers="v1" From: Eliot Lear To: architecture-discuss@ietf.org, iab@iab.org Message-ID: Subject: Re: Call for Comment: (Out With the Old and In With the New: Planning for Protocol Transitions) References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> In-Reply-To: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> --nMoUKkAvGK3MbgdCD1UPJBBl8kHafVXfo Content-Type: multipart/alternative; boundary="------------7E0607B8C31249B4107D5FE1" This is a multi-part message in MIME format. --------------7E0607B8C31249B4107D5FE1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dave and the rest of the IAB, First, I have to say that I very much appreciate Dave in particular keeping focus on this area. It's good advice not just for the IETF, but for those who are following. Still, I'd suggest you take another swing. In general I would suggest that there needs to be more meat. The abstract states that this memo summarizes various things. Ok. The question for me is this: what is it that the board would like to convey to the IETF or to others by way of advice on how to do things better the next time? Now maybe it is because I've been around this block a few times, but I must admit I am left wanting more. And to be sure, there is more to want. See below regarding that. The extreme example of this is Section 4.5. Why does one need a contingency plan? What should an analysis look like in terms of deriving it? On organization, you seem to be hiding lessons learned in the appendix.=20 I advise against it. Figure out what you really want to convey and then use the information in the Appendix or from elsewhere to support your discussion. Perhaps one of the most successful transitions we have seen is HDTV in America. It might be worth including that in your appendix. How is it that hundreds of millions of broadcast sets eventually all got converted over in a fixed time period? Obsolescence played a role, regulation played a role, industry alignment played a HUGE role: frequency demand and the ability to sell a much better product with (perhaps) a higher margin for a time made a big difference, I think. HDTV might make a good comparison against, say, IPv6. HTTP/2 versus HTTP/1.1 goes tot he heart of RFC 5218. Because HTTP1.1 has "enjoyed" wild success, there is an opportunity to revisit that.=20 For instance, is it still enjoying wild success or is it simply now just wild? That is, has H2 taken its primary use case, leaving everything other than what it was designed to do? And maybe that's okay. One could argue that the other use cases look a lot like CoAP, and yet CoAP may only cover a fraction. I'd suggest that there is an entire topic that you could plumb and is worth hitting head on: has the world become more 2-sided? One thing we might stand to learn from HTTP/1.1 and HTTP2 is how much code was needed where to get bank for the buck? The Alexa 12, for instance, would argue that hitting just a handful of browsers made a massive difference re what we see on the Internet, and the value is sufficient to just those sites, and a few content networks like Akamai to sustain the new protocol. It doesn't really say, however, how to turn off the old stuff, or even whether it is necessary to do so. In the context of IoT, there are right now (plus or minus) a gazillion frameworks floating about that are all about code and not about protocol. It is a foregone conclusion that there will be some consolidation to a number that looks closer 5-10 so that network effects can be enjoyed. Well if that's the case, one question, and maybe this is one for Laura Denardis, is whether this consolidation is a good thing for protocol development. On the one hand it offers tremendous scaling ability to effect transitions. On the other hand, it may concentrate power into a very small group of people regarding that transition. Nits Section 1, Bottom of Page 3, Point 3: > *Don't* *under*estimate the cost of things *other* than the hardware/so= ftware itself. This phrase is nearly a triple-negative. How about restating it along the following lines: It's important to consider costs that go beyond hardware and software, such as... All the best, Eliot On 1/5/17 2:17 AM, IAB Executive Administrative Manager wrote: > This is an announcement of an IETF-wide Call for Comment on=20 > draft-iab-protocol-transitions-05. > > The document is being considered for publication as an Informational RF= C=20 > 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 t= o > 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. > > --------------7E0607B8C31249B4107D5FE1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Dave and the rest of the IAB,

First, I have to say that I very much appreciate Dave in particular keeping focus on this area.=C2=A0 It's good advice not j= ust for the IETF, but for those who are following.=C2=A0 Still, I'd sug= gest you take another swing.

In general I would suggest that there needs to be more meat.=C2=A0= The abstract states that this memo summarizes various things.=C2=A0 Ok.= =C2=A0 The question for me is this: what is it that the board would like to convey to the IETF or to others by way of advice on how to do things better the next time?=C2=A0 Now maybe it is because I've bee= n around this block a few times, but I must admit I am left wanting more.=C2=A0 And to be sure, there is more to want.=C2=A0 See below = regarding that.=C2=A0 The extreme example of this is Section 4.5.=C2=A0 Why d= oes one need a contingency plan?=C2=A0 What should an analysis look like in= terms of deriving it?

On organization, you seem to be hiding lessons learned in the appendix.=C2=A0 I advise against it.=C2=A0 Figure out what you real= ly want to convey and then use the information in the Appendix or from elsewhere to support your discussion.

Perhaps one of the most successful transitions we have seen is HDTV in America.=C2=A0 It might be worth including that in your appendix.=C2= =A0 How is it that hundreds of millions of broadcast sets eventually all got converted over in a fixed time period?=C2=A0 Obsolescence played a ro= le, regulation played a role, industry alignment played a HUGE role: frequency demand and the ability to sell a much better product with (perhaps) a higher margin for a time made a big difference, I think.=C2=A0 HDTV might make a good comparison against, say, IPv6.

HTTP/2 versus HTTP/1.1 goes tot he heart of RFC 5218.=C2=A0 Becaus= e HTTP1.1 has "enjoyed" wild success, there is an opportunity to revisit that.=C2=A0 For instance, is it still enjoying wild success= or is it simply now just wild?=C2=A0 That is, has H2 taken its primary= use case, leaving everything other than what it was designed to do?=C2=A0= And maybe that's okay.=C2=A0 One could argue that the other use cas= es look a lot like CoAP, and yet CoAP may only cover a fraction.

I'd suggest that there is an entire topic that you could plumb and is worth hitting head on: has the world become more 2-sided?=C2= =A0 One thing we might stand to learn from HTTP/1.1 and HTTP2 is how much code was needed where to get bank for the buck?=C2=A0 The Alex= a 12, for instance, would argue that hitting just a handful of browsers made a massive difference re what we see on the Internet, and the value is sufficient to just those sites, and a few content networks like Akamai to sustain the new protocol.=C2=A0 It doesn't really say, however, how to turn off the old stuff, or even whether it is necessary to do so.

In the context of IoT, there are right now (plus or minus) a gazillion frameworks floating about that are all about code and not about protocol.=C2=A0 It is a foregone conclusion that there wi= ll be some consolidation to a number that looks closer 5-10 so that network effects can be enjoyed.=C2=A0 Well if that's the case, one question, and maybe this is one for Laura Denardis, is whether this consolidation is a good thing for protocol development.=C2=A0 = On the one hand it offers tremendous scaling ability to effect transitions.=C2=A0 On the other hand, it may concentrate power into= a very small group of people regarding that transition.

Nits

Section 1, Bottom of Page 3, Point 3:

Don't underestimate=
 the cost of things other than the hardware/software itself.
=

This phrase is nearly a triple-negative.=C2=A0 How about restating= it along the following lines:

It's important to consider costs that go beyond hardware and software, such as...


All the best,

Eliot


On 1/5/17 2:17 AM, IAB Executive Administrative Manager wrote:
This is an announcement of an IETF-wide Call for Com=
ment on=20
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/draf=
t-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.

--------------7E0607B8C31249B4107D5FE1-- --nMoUKkAvGK3MbgdCD1UPJBBl8kHafVXfo-- --XhKbwDqQOkb0753faSpTJF48qSlRgiNmg 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 iQEcBAEBCAAGBQJYbfL1AAoJEIe2a0bZ0nozTMMH/28RDzy49u5D+fKiKUZGgqm9 zCiAclOp5lM54TXcSXjTFXwRD9q+h78CJ3aTy/2LVQ4kQkmCwd6V3DJQ2mc/2dqQ O41JdTJ/XiNUSX0UYLCScGE+XtBcgcjMseve6BbWPXl+D2AqmjuzX/AAaWAMncZJ yxgXs6TjAWM8h57b9ADHWtru0NEGynizSa4WKo49FjKJKts8glcb1kikuJXagRHp 0t+zASTos3CTPunJNhuI8SU6bC3A0MJtttJJ+n9fa5bBmFkarN10fWMzcSZk3npK XfUlyBftd+wMNWRaSpbB+AFfmPtD+K9MSB6i2kgven3BLuM9jGtvWqoudW2SYUs= =x9fq -----END PGP SIGNATURE----- --XhKbwDqQOkb0753faSpTJF48qSlRgiNmg-- From nobody Mon Jan 9 16:51:13 2017 Return-Path: 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 ; 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 ; 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 ; Mon, 9 Jan 2017 16:51:09 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id 127so36443522pfg.1 for ; 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 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: Subject: Re: [arch-d] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. > > From nobody Mon Jan 9 17:07:46 2017 Return-Path: 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 94AFC1299B7 for ; Mon, 9 Jan 2017 17:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156] 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 6P-oZwkMvj_d for ; Mon, 9 Jan 2017 17:07:43 -0800 (PST) Received: from atl4mhob23.registeredsite.com (atl4mhob23.registeredsite.com [209.17.115.117]) by ietfa.amsl.com (Postfix) with ESMTP id B70851299B5 for ; Mon, 9 Jan 2017 17:07:43 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id v0A17gf8113044 for ; Mon, 9 Jan 2017 20:07:42 -0500 Received: (qmail 16785 invoked by uid 0); 10 Jan 2017 01:07:42 -0000 X-TCPREMOTEIP: 68.100.192.186 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.0.11?) (lee@asgard.org@68.100.192.186) by 0 with ESMTPA; 10 Jan 2017 01:07:42 -0000 User-Agent: Microsoft-MacOutlook/14.7.1.161129 Date: Mon, 09 Jan 2017 20:07:36 -0500 From: Lee Howard To: Brian E Carpenter , , Message-ID: Thread-Topic: [IAB] Call for Comment: (Out With the Old and In With the New: Planning for Protocol Transitions) References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> <3f8254a6-ff3f-e944-3ef9-6ce2bf36df93@gmail.com> In-Reply-To: <3f8254a6-ff3f-e944-3ef9-6ce2bf36df93@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [arch-d] [IAB] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 01:07:45 -0000 Change advocates diluted their credibility, which may have affected perception of the new protocol. I agree with your point, and need to think about whether it=B9s important for the audience of this document. Lee On 1/9/17, 7:51 PM, "IAB on behalf of Brian E Carpenter" wrote: >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. >>=20 >> The document is being considered for publication as an Informational >>RFC=20 >> within the IAB stream, and is available for inspection at: >> https://datatracker.ietf.org/doc/draft-iab-protocol-transitions/ >>=20 >> The Call for Comment will last until 2017-02-01. Please send comments to >> architecture-discuss@ietf.org and iab@iab.org. >>=20 >> Abstract >>=20 >> 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. >>=20 >>=20 > > From nobody Tue Jan 10 02:15:19 2017 Return-Path: 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 45DB01293DC for ; Tue, 10 Jan 2017 02:15:17 -0800 (PST) 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 Qf3ZRnK9DDST for ; Tue, 10 Jan 2017 02:15:16 -0800 (PST) Received: from mail-wj0-x22c.google.com (mail-wj0-x22c.google.com [IPv6:2a00:1450:400c:c01::22c]) (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 BD3E9127A91 for ; Tue, 10 Jan 2017 02:15:15 -0800 (PST) Received: by mail-wj0-x22c.google.com with SMTP id kq3so34117111wjc.0 for ; Tue, 10 Jan 2017 02:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=CZUrfUdOwLHJ3QWuCHJijibOF1wkFvWRoDYbzTnoTUU=; b=gFhjA/oEuXgBwQS+eau4l6KoXwpL6R5Rn/25JmPPqznaggnbyPQjhAeqbmQir/3g7H EhajFOgG/k836IYHOSYQRhK2jZIpFLUmUtmxaE6O6apLl68frrjnYtGPhYqTuyKbk0B2 eqVuukprq5W4GBtf5oYRkWDQI7hrdoqB0Ij67mJB51jb7ju70+e+tDVhY9Y3TUuZhg1P 8A8aBrq/zUeh8zcWAh7NYVUofqS8IvKdbYbTCo2N8LaC6hI5elNFKmGSPN6QcMP8xopn D4+rDWuGCZxU0hYzs6N/He60Um5bgJwCtRLUqg5BznSNYutJkEcxCKZLAVkEcLKxwD3J +esA== 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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CZUrfUdOwLHJ3QWuCHJijibOF1wkFvWRoDYbzTnoTUU=; b=X0mvh/WqVkW504jRTdcY/UbOSG8pBe6jgZ1d6BkIBncq0Gau0m5hzOW4rXjJYePP/r 6dRVjUQyJECfGNYuSfbP33YlW7+ayvjzSNsMzkjoiLhkhAJnWcwFKqMyanwY6gxTh2pD HuucrRmA9cc9XmKelqYEOqv4L7hRgle8ggQUIcJYfMIz172JIvEIojsHUSZ2Ceb1TD4s kZOQH1E8Z8y3Es184uqc2nvp0N9n+A70DewRvQtQhCYur/EbfRrw0p8Sztxb1bidrSMX hSyMi/y2KsJMztB8iyyvc3Te42MN3iawMRXm0PYi/IQqfqrI8nvwLWtYILfhnaoJmpxJ B5qA== X-Gm-Message-State: AIkVDXJteLeLqSZRqfV4Oy1gC0oJcqeCg8+AmyT0gnwIdnCWx620u+lAPBAWC3ort2gNXg== X-Received: by 10.194.243.231 with SMTP id xb7mr1563356wjc.60.1484043313955; Tue, 10 Jan 2017 02:15:13 -0800 (PST) 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 ei2sm2365929wjd.47.2017.01.10.02.15.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 02:15:13 -0800 (PST) To: architecture-discuss@ietf.org References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <637543fe-ece5-1562-d000-f4d2d3c4f3d1@gmail.com> Date: Tue, 10 Jan 2017 10:15:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:15:17 -0000 A really good example of a transition mechanism that is not called out in this draft is the RIB. In routing we have for years used the RIB as a clearing house to allow the routing protocols which run ships in the night and are incompatible with each other to exchange connectivity information between each other. We can thus introduce new local routing protocols at will. The (unsolved) routing equivalent of a problem of IPv6 proportions is BGP. An example from ancient history outside the IETF was the DECnet Phase 4 to Phase 5 transition. This was required to have a transition method indeed a as recall a hands-off transition method. It was designed about the same time as IPv6. The word at the time was that migration design too 80% or so of the design effort. It is likely that if IPv6 which presumably would have been fundamentally different, had stated this as a day one goal we would be in a better place now. Where this document appears to stop short is to recommend, maybe even require that all revisions to Internet scale protocols MUST include a documented seamless migration technical design, and that all new protocols that are expected to be deployed at that scale MUST include the capability of being seamlessly replaced. Best Regards Stewart From nobody Tue Jan 10 15:04:59 2017 Return-Path: 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 9FD3C1295AD for ; Tue, 10 Jan 2017 15:04:58 -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 4ZW7fUSb9kSm for ; Tue, 10 Jan 2017 15:04:56 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d: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 4ADB71295D5 for ; Tue, 10 Jan 2017 15:04:56 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id a20so192231439qkc.1 for ; Tue, 10 Jan 2017 15:04:56 -0800 (PST) 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=eJB1GNyoM2hn3LRnQtDme6eWujBLYt1MelxJPcArsLs=; b=BM/7C1180v3KEWArrFWZqIYbM7de8OcnfvVn+Tfs1HbxCFVxcYhtY02Oxt1dePvLdB u5lcKEu9Z2EzdqW3h5spuNcQU6+1kubCBlnWGyp49U6wGciqjWZ8IBMWWGY6dTWruxxR ifIGBAToMPwGD+YYsErariyd9UOjdCy8X4bfPjxFjaU8pp7iZlDbpG+NXP1s0IwNtb8O vwtOMx8l+RJhhSwqRv0xSpknKo4m0wiF/eQRssokXOG377OBebIUn3SGOwzcNb77rojU ygqEDZxTo1XRP1HujQFgmo/mat96iTkEXxIIef7JI6/Amd8pPZaCIeY+8ggdxuXMkhqz cnGA== 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=eJB1GNyoM2hn3LRnQtDme6eWujBLYt1MelxJPcArsLs=; b=JH4HDzIcTgbN+HO/phMrrf1mngxHrN95FtHMOR683AX2lnwHCp+9L/iko7RGV+qQg4 nFglMioGKuINuZ3PJBH1pIpLSAERe6/2wQxvMrZB+eTSLDMWkop4EZ7LyCJA1tKB+zDH tNbmV+y6BiKKQ81M9hM1PlQ6FfTt+xROCcRT3LXY6jUJ9Sp2hqIhrTQzQ93mgGtruzwS p5pyhki4xSlVNXNyjQTPM/1l1oz7atObZJhgiCEop2tRQMGc5O1hCZFmHdaZfH2+ejhe v+uNGytlMOoqnMgnyL40vmMaYfkYq6cVVfhwWwuTr6UW0jLOXR16wM7shGrH37Nm0xtJ 9wjw== X-Gm-Message-State: AIkVDXIS5cDdrFtX3hC++UYk+OJAcahutpzIZBXoQHaWbxsqasGWNWt3Mo3CRsigkuNoWphbT8zZteuA7ooUbw== X-Received: by 10.55.138.2 with SMTP id m2mr5246714qkd.115.1484089495379; Tue, 10 Jan 2017 15:04:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 10 Jan 2017 15:04:54 -0800 (PST) In-Reply-To: References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 11 Jan 2017 12:04:54 +1300 Message-ID: To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IAB , architecture-discuss@ietf.org Subject: Re: [arch-d] [IAB] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:04:58 -0000 Hi Eliot, I'm going to speak for myself and pick on a few points you make, and let others comment on the things that I am less knowledgeable about. You ask for more meat on the document in a couple of ways. I think that you do raise some relevant questions, and it's probably the case that the IAB needs to consider the effect of market consolidation. I do think that we should avoid burdening this document with a requirement to address all of those concerns though. We're learning, particularly as feedback on this document comes in, that there are lots of great examples of how transitions can be wildly different. Based on that, I'm not sure that this document can never be comprehensive enough to address all possible considerations. In fact, I don't see that to be its purpose. A document that highlights the importance of considering transition factors is of more benefit now than a detailed manual that we may never publish (not suggesting that was your intent, just drawing on the extremes). On 5 January 2017 at 20:17, Eliot Lear wrote: > HTTP/2 versus HTTP/1.1 goes tot he heart of RFC 5218. Because HTTP1.1 has > "enjoyed" wild success, there is an opportunity to revisit that. For > instance, is it still enjoying wild success or is it simply now just wild? > That is, has H2 taken its primary use case, leaving everything other than > what it was designed to do? And maybe that's okay. One could argue that > the other use cases look a lot like CoAP, and yet CoAP may only cover a > fraction. I don't agree with the implied characterization of h2. It is true that h2 provides optimizations that are primarily aimed at certain styles of deployment. Consequently, those deployments are more likely to spend the effort to analyze the performance trade-offs and deploy the new code. You are also (probably) talking about deployments that tend to move a lot faster. But h2 is functionally complete as a replacement for HTTP/1.1. To suggest that only really big sites, CDNs and major browsers are the ones that are using h2 is just wrong. Use of h2 in things like APIs is pretty widespread now, it's just not as obvious. Multiplexing there is a huge win for throughput and efficiency. We've also seen cogent arguments that insist that h2 is almost perfectly suited to IoT deployments because of those same optimizations. Though we're seeing the effect of some of the choices we made to package changes together: IoT devices generally prefer to use use weaker crypto than h2 permits. (Not sure what you are getting at with the "just wild" statement.) From nobody Tue Jan 10 16:02:13 2017 Return-Path: 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 74F881295F6 for ; Tue, 10 Jan 2017 16:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 2wI39HTgWQdR for ; Tue, 10 Jan 2017 16:02:10 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EE41295E4 for ; Tue, 10 Jan 2017 16:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7026; q=dns/txt; s=iport; t=1484092929; x=1485302529; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=icwEyqxYchsjI3rqZNUWnwiFRaQfTjvmTgM2FYmeDvk=; b=EEpwmQq/fAm1ByLhaRPFZk1nsIy9wJEpG0lSO3nUMwAnBkST+lSePNEG AKwpvw8w6pGxZtqZ6cpRp2UV7ZMwSWDPaNzqgsSyiLqbwZZ31ZoX62w9y D1PJQmaMoYnOWjyDEb8ScUi5/O4ZlBj04eK0Q0n9J5AzxDQtoul3uunVZ g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAQBZdXVY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAR9fA4EKjVeSJpUnggsqhGiBEAKCBT8UAQIBAQEBAQE?= =?us-ascii?q?BYyiEaQEBAQMBHQZKDAULCxgjBwICVwYNBgIBARqISggOsDaCJYoRAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARAKBYhHgl+EF4M3gl4FkBeLDINngX91glCIJ4oshjWSXh8?= =?us-ascii?q?4gRISBxUVOIRmgWgdNYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,345,1477958400"; d="asc'?scan'208";a="371049085" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jan 2017 00:02:08 +0000 Received: from [10.154.160.78] ([10.154.160.78]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0B028Cm022271; Wed, 11 Jan 2017 00:02:08 GMT To: Martin Thomson References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> From: Eliot Lear Message-ID: <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> Date: Tue, 10 Jan 2017 16:02:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dqaUfXrP0dUsmKPTU2umn7HqbdT2BQJuR" Archived-At: Cc: IAB , architecture-discuss@ietf.org Subject: Re: [arch-d] [IAB] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:02:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dqaUfXrP0dUsmKPTU2umn7HqbdT2BQJuR Content-Type: multipart/mixed; boundary="n8KvqEnJuqJfQJ2sCftKsHKhdUcRRj3fP"; protected-headers="v1" From: Eliot Lear To: Martin Thomson Cc: architecture-discuss@ietf.org, IAB Message-ID: <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> Subject: Re: [IAB] Call for Comment: (Out With the Old and In With the New: Planning for Protocol Transitions) References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> In-Reply-To: --n8KvqEnJuqJfQJ2sCftKsHKhdUcRRj3fP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, Thanks for your response. Pelase see below. On 1/10/17 3:04 PM, Martin Thomson wrote: > Hi Eliot, > > I'm going to speak for myself and pick on a few points you make, and > let others comment on the things that I am less knowledgeable about. > > You ask for more meat on the document in a couple of ways. I think > that you do raise some relevant questions, and it's probably the case > that the IAB needs to consider the effect of market consolidation. I > do think that we should avoid burdening this document with a > requirement to address all of those concerns though. It's your document. Decide what you want with it. > We're learning, particularly as feedback on this document comes in, > that there are lots of great examples of how transitions can be wildly > different. Based on that, I'm not sure that this document can never > be comprehensive enough to address all possible considerations. In > fact, I don't see that to be its purpose. A document that highlights > the importance of considering transition factors is of more benefit > now than a detailed manual that we may never publish (not suggesting > that was your intent, just drawing on the extremes). It is important to state why those factors are important. It is not necessary to list every possible one. Choose wisely so that your points are illustrated. Don't hide that information in an Appendix. > > On 5 January 2017 at 20:17, Eliot Lear wrote: >> HTTP/2 versus HTTP/1.1 goes tot he heart of RFC 5218. Because HTTP1.1= has >> "enjoyed" wild success, there is an opportunity to revisit that. For >> instance, is it still enjoying wild success or is it simply now just w= ild? >> That is, has H2 taken its primary use case, leaving everything other t= han >> what it was designed to do? And maybe that's okay. One could argue t= hat >> the other use cases look a lot like CoAP, and yet CoAP may only cover = a >> fraction. > I don't agree with the implied characterization of h2. It is true > that h2 provides optimizations that are primarily aimed at certain > styles of deployment. Consequently, those deployments are more likely > to spend the effort to analyze the performance trade-offs and deploy > the new code. You are also (probably) talking about deployments that > tend to move a lot faster. > > But h2 is functionally complete as a replacement for HTTP/1.1. To > suggest that only really big sites, CDNs and major browsers are the > ones that are using h2 is just wrong. Use of h2 in things like APIs > is pretty widespread now, it's just not as obvious. Multiplexing > there is a huge win for throughput and efficiency. > We've also seen cogent arguments that insist that h2 is almost > perfectly suited to IoT deployments because of those same > optimizations. Though we're seeing the effect of some of the choices > we made to package changes together: IoT devices generally prefer to > use use weaker crypto than h2 permits. The jury is still out on how well H2 will succeed.[1] We can say it has been very well adopted in a particular use case. Because IoT is a broad term, I have no doubt but that H2 will be appropriate in some cases.=20 Just because the code is in APIs does not mean it will be used. It is unlikely to be appropriate in many cases for numerous reasons, not the least of which is its code complexity as compared to http/1.1 and CoAP, and the other being that there is more crypto work needed in closed systems (maybe ANIMA BrSKI will help with that). However, none of this was really my point. My point was really more about how demand and use of http/1.1 has evolved. 5218 makes the point that http/1.1 was wildly successful. See the figure in section 1.2.1.=20 That means that it has been broadly adopted well beyond its intended design space. But now we see peeling away of some of those uses to other protocols, such as h2 and CoAP. How then do we evaluate what is left? Are all uses left beyond the design space? That is what I meant by =E2=80=9Cjust wild=E2=80=9D. My point is that a careful analysis of = that would be good follow-on work from 5218. One question is simply this: how does wild success evolve over time? Showing a certain amount of continuity in the board's work seems to me a good thing, and it seems to me that the document starts down that path, but is somewhat unfocused with its examples. Again, that they are in the appendix is indicative of that. You may find that an analysis such as what I described informs this work, because there are two questions that leads to: [1] when is =E2=80=9C= just wild=E2=80=9D aspect a bad thing? [2] When it is bad, what if any guidan= ce does the board have to eliminate it? If it's not a bad thing, then how much managing of the tail is really necessary when use cases differ? And that brings me back to the example I mentioned: HDTV. In that case managing the tail was deemed very important because one key incentive was being able to redeploy the old frequencies. When do we care about that on the Internet and what incentives do we have to leverage? Regards, [1] https://w3techs.com/technologies/details/ce-http2/all/all --n8KvqEnJuqJfQJ2sCftKsHKhdUcRRj3fP-- --dqaUfXrP0dUsmKPTU2umn7HqbdT2BQJuR 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 iQEcBAEBCAAGBQJYdXX/AAoJEIe2a0bZ0nozf78H/ibbaQZLXe+T6kO9t948LykG R0sFjI8vRxCeY/uSCB5J00GNLfy5N/tTi6fee086NZj/hGHgLl59CxrBflcB7uJ6 LWBXd86PD4nAFjPYn/k0LRwym3WIDPcbOiQ49XjP+P71H80ELapGxaW9LXAq4lx7 vkMJ/DYhYPZP+TsWjSWbRIs8zN9np3qZH6ITgvvkms8ir6/SCpJDqtFL1cGddV8Q V765weYSk8sFZ/UUkHyWg+UzMktdN7AKIQ0jHMIyYi/+57OrHuCbp2LqMZWkJL3L 7yVRsvnkyyVWFyBbgeT+JZ0kxwqq0AEK7I6Wppl1z1RgjSP8d0kbfQDBEJRe1kc= =cpwU -----END PGP SIGNATURE----- --dqaUfXrP0dUsmKPTU2umn7HqbdT2BQJuR-- From nobody Tue Jan 10 16:56:04 2017 Return-Path: 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 6BCDE129455; Tue, 10 Jan 2017 16:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] 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 VbRtEl60Xwa8; Tue, 10 Jan 2017 16:56:00 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 03B7F129454; Tue, 10 Jan 2017 16:56:00 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0B0tbRX018014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Jan 2017 16:55:37 -0800 (PST) References: <3277f3d0-b937-a984-299f-b26983c37e5f@isi.edu> To: "architecture-discuss@ietf.org" From: Joe Touch X-Forwarded-Message-Id: <3277f3d0-b937-a984-299f-b26983c37e5f@isi.edu> Message-ID: <1b5f66a7-7980-b610-1691-7a145294fa67@isi.edu> Date: Tue, 10 Jan 2017 16:55:36 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <3277f3d0-b937-a984-299f-b26983c37e5f@isi.edu> Content-Type: multipart/alternative; boundary="------------B5466B082AADCB2645909448" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: IAB IAB Subject: [arch-d] Fwd: some comments on draft-iab-protocol-transitions-05 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:56:01 -0000 This is a multi-part message in MIME format. --------------B5466B082AADCB2645909448 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, I posted some comments on this doc to the stackevo list. Joe -------- Forwarded Message -------- Subject: some comments on draft-iab-protocol-transitions-05 Date: Tue, 10 Jan 2017 14:50:25 -0800 From: Joe Touch To: stackevo-discuss@iab.org CC: Dave Thaler Hi, Dave (et al.), I had some thoughts on this doc, summarized below. I hope they're useful. Joe ------- The discussion of IPv4-6 transition might include a discussion of paths not taken in IPv4, e.g., earlier versions included variable length addressing. Regarding new features, it might be useful to discuss how options are handled. We include them to future-proof a protocol, to ease the transition to new features. However, we too often succumb to commercial pressures to ignore this flexibility in favor of performance or economy. That's why IPv4 fragments are being dropped, why IPv6 options are now limited in total length, and why options are generally deprecated for traffic that expects to successfully traverse the Internet. It's also how we're boxing ourselves into needing IPv-next rather than augmenting what we have in our hands. There are a few design lessons here that might be useful to point out. A discussion of TLV vs. fixed tag encodings would be useful. Reasons to put version IDs, or demuxing tags in most protocols would be useful too (as we learned for the TCP Experimental option codepoints). It might be useful to have a more detailed discussion of handling "TBD" fields, e.g., when they MUST be set to X by legacy sources, MUST be ignored vs. discarded if not zero by legacy receivers, and when to use each strategy. I.e., we're constantly oscillating between considering a "thin waist" either ossification or stability; the former when we actually need new capabilities (like more addresses), the latter when we actually want things to work (like running DNS over HTTP). We need to understand that to know whether and how we want to support transitions like these. ------ --------------B5466B082AADCB2645909448 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, all,

I posted some comments on this doc to the stackevo list.

Joe



-------- Forwarded Message --------
Subject: some comments on draft-iab-protocol-transitions-05
Date: Tue, 10 Jan 2017 14:50:25 -0800
From: Joe Touch <touch@isi.edu>
To: stackevo-discuss@iab.org <stackevo-discuss@iab.org>
CC: Dave Thaler <dthaler@microsoft.com> 


Hi, Dave (et al.),

I had some thoughts on this doc, summarized below. I hope they're useful.

Joe

-------

The discussion of IPv4-6 transition might include a discussion of paths
not taken in IPv4, e.g., earlier versions included variable length
addressing.

Regarding new features, it might be useful to discuss how options are
handled. We include them to future-proof a protocol, to ease the
transition to new features. However, we too often succumb to commercial
pressures to ignore this flexibility in favor of performance or economy.
That's why IPv4 fragments are being dropped, why IPv6 options are now
limited in total length, and why options are generally deprecated for
traffic that expects to successfully traverse the Internet. It's also
how we're boxing ourselves into needing IPv-next rather than augmenting
what we have in our hands.

There are a few design lessons here that might be useful to point out. A
discussion of TLV vs. fixed tag encodings would be useful. Reasons to
put version IDs, or demuxing tags in most protocols would be useful too
(as we learned for the TCP Experimental option codepoints). It might be
useful to have a more detailed discussion of handling "TBD" fields,
e.g., when they MUST be set to X by legacy sources, MUST be ignored vs.
discarded if not zero by legacy receivers, and when to use each strategy.

I.e., we're constantly oscillating between considering a "thin waist"
either ossification or stability; the former when we actually need new
capabilities (like more addresses), the latter when we actually want
things to work (like running DNS over HTTP). We need to understand that
to know whether and how we want to support transitions like these.

------
--------------B5466B082AADCB2645909448-- From nobody Tue Jan 10 17:27:09 2017 Return-Path: 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 D5E13129401 for ; Tue, 10 Jan 2017 17:27:07 -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=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 3XP5ZJYmFuP5 for ; Tue, 10 Jan 2017 17:27:06 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 71F21126BF7 for ; Tue, 10 Jan 2017 17:27:06 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id 11so95542363qkl.3 for ; Tue, 10 Jan 2017 17:27:06 -0800 (PST) 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:content-transfer-encoding; bh=etjLsMoo4vhwR+1F9KkpbpoWjWgZXhX/k9rU7FJmjW4=; b=r+roq8GNGHXugWitRx1OdlL0HufIrY59O++IhU46Lv3ooCLhxcihtv6J/oE07QzAiX YbPQ6vFMwlhT0CdW5B/CuRgFYolpict8FWQ4MR89imdT17mKpYsxqDnWV5Km9Flqlp7b DIeCVA5z333z51ESwT5AutQ2k2wa7NcEE46LE9MbpkfDBCB0d/PzTUFte8E+Q6aFKbHv UdybG3hD91XOm5p6q5WLam8yDjyPudFYYaAEoS0AASV1PiPMTznyEmZSNEuDX2PHlEsE lFr4TapYiWStRvG2wqatBZ8VVaW8XPIIPRG3gCMVSJl15OcofaPzMIiOmiBEfAqorgZq Fuxg== 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:content-transfer-encoding; bh=etjLsMoo4vhwR+1F9KkpbpoWjWgZXhX/k9rU7FJmjW4=; b=Dh+ZcEu54F7/lMKQ6IJPzAzrp9FfTVTwHonIHvGQxap8UMs34dt9pMhguWHV+VZMb3 /WVsp7hGcHyr6YNlrxe0/SMk1un+51blo2DgqUYGioM/jvByqQNnAV3CByoHR2Q4fK/t M68mRV9Fs2xJZOtGsO2cvc/TgtWMY0k7Faf15wl9TsqX+Rfc6VVDky/pNHjC7boBFzc1 hDcxecGfkJ2CS4hnsPk+3tTAFyz32gWszBY1qHKSE4raYPVD0nWOXSN+fw2vqQZwBwQ6 un4UGgJavPVXFiqQxpUrVYhRxnkMEzP9oVGYZee88ZrW7TpTZYO7e3+4wZAGx+FkwH3r v/JQ== X-Gm-Message-State: AIkVDXK/GH2v3IA8jjW964N1JRioor7m/R59trvETFkNgpi3DhdX/qkWXqSxFt4gDCyiatQ0zX425BQ0hEDbWw== X-Received: by 10.55.101.82 with SMTP id z79mr5709257qkb.68.1484098025597; Tue, 10 Jan 2017 17:27:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 10 Jan 2017 17:27:05 -0800 (PST) In-Reply-To: <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> From: Martin Thomson Date: Wed, 11 Jan 2017 14:27:05 +1300 Message-ID: To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IAB , architecture-discuss@ietf.org Subject: Re: [arch-d] [IAB] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 01:27:08 -0000 On 11 January 2017 at 13:02, Eliot Lear wrote: > You may find that an analysis such as what I described informs this > work, because there are two questions that leads to: [1] when is =E2=80= =9Cjust > wild=E2=80=9D aspect a bad thing? [2] When it is bad, what if any guidan= ce does > the board have to eliminate it? If it's not a bad thing, then how much > managing of the tail is really necessary when use cases differ? And > that brings me back to the example I mentioned: HDTV. In that case > managing the tail was deemed very important because one key incentive > was being able to redeploy the old frequencies. When do we care about > that on the Internet and what incentives do we have to leverage? Ahh, so the question is how you address the protocol that *is* rather than the protocol that *was* or maybe just the protocol that you wished there is. That's a question we spent inordinate amounts of time on in h2. And there I agree with you that the question of whether those deviant uses (in the nicest sense) need to be considered with a new version. My view would be that a lot of the value that a (wildly successful) protocol gets is from those deviant uses. Consequently, failing to consider the protocol that *is* when designing for replacement is a good way to fail at the replacement. I think Section 4.1 does address this point, though more concisely than you might prefer. In my opinion, the question of whether you intend for the old version to eventually disappear is usually a moot question for protocols. The HDTV example might not apply here. I can't imagine we'd be looking to reassign the meaning of version 4 in the IP header any time soon. Protocols either die or they don't and we only care to the extent that we have to support them. They usually just die by degrees. For instance, while we might want SSLv2 to disappear completely, that's not something we worry about as long as we ourselves aren't exposed to it (we still carry the code for SSLv3, but it's been given notice). To take an example familiar to me, web sites spend considerable effort on browser compatibility, though few sites today spend any time at all on IE6. That doesn't mean that IE6 is no longer used anywhere, it's just that the incentive to support it is so greatly diminished it might as well be gone. I'll leave it to others whether there needs to be text on this point. I'm of the view that this is a document about the introduction of a protocol and less about the decommissioning of a protocol. We could probably write a great deal on decommissioning, but it might be better as a separate document. From nobody Tue Jan 10 22:02:31 2017 Return-Path: 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 CAD41129731; Tue, 10 Jan 2017 22:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.989 X-Spam-Level: X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=p/3HKsfC; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=p+yV3uF/ 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 Qno07OFYUwwJ; Tue, 10 Jan 2017 22:02:28 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F7F129721; Tue, 10 Jan 2017 22:02:28 -0800 (PST) Received: from SUBMAN.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id v0B62Cg3015631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2017 22:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1484114540; x=1484200940; bh=EmRAnKrYRN8rAk3zeJp83wfPui4ZfRvdqJ2t7BAkeeQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p/3HKsfCNJFrfKImypiGjCWSbrkAqFmdDRbOQyky5J89c6zZei5DzHFtlPpWDwWWx JViKPmg/zlbaxPp0aZqjTiD/VVMuB5lTXMKwqdgkUucGB4xEt5K1/Y9nIg2WGPDBf6 UI/bbV2ClY+v+cicJYX3iE3KUlNYI/FRaSjIYVGo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1484114540; x=1484200940; i=@elandsys.com; bh=EmRAnKrYRN8rAk3zeJp83wfPui4ZfRvdqJ2t7BAkeeQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p+yV3uF/sAHr7GAp0MmtyIF7AwoRkpPjI4neoiZLNHMK6MR4skT0bIE38o3ZVcjGh ZsApqJ6LuihT6iXA/K/qGfIdkHgHfNvpvgWJSQ+z23GKKCKeIb5LDYuA9W9QmVUjg6 vBAcHlrfsLkeCSBhpzEzLBmCMjvkUVfYBoZFLEGg= Message-Id: <6.2.5.6.2.20170110191336.0e812710@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Jan 2017 21:35:50 -0800 To: Martin Thomson , Eliot Lear From: S Moonesamy In-Reply-To: References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: IAB , architecture-discuss@ietf.org Subject: Re: [arch-d] [IAB] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 06:02:30 -0000 Hi Martin, Eliot, At 17:27 10-01-2017, Martin Thomson wrote: >In my opinion, the question of whether you intend for the old version >to eventually disappear is usually a moot question for protocols. The >HDTV example might not apply here. I can't imagine we'd be looking to >reassign the meaning of version 4 in the IP header any time soon. > >Protocols either die or they don't and we only care to the extent that >we have to support them. They usually just die by degrees. For >instance, while we might want SSLv2 to disappear completely, that's >not something we worry about as long as we ourselves aren't exposed to >it (we still carry the code for SSLv3, but it's been given notice). I didn't catch Eliot's point about HDTV at first. In the field of software, the developers sometimes drop support for an old version of a protocol [1]. From a SSO perspective, the IETF is said to have an open maintenance process for its standards. Does that maintenance process apply to the obsolete version of the protocol? Does that maintenance process only apply to bug fixing or does it also comprise adding new features to the obsolete protocol? An observation about Bitcoin is included in Section 1 of the draft. Bitcoin is not an IETF technical specification or protocol. Bitcoin was described as "a peer-to-peer electronic cash system" [2]. The closest analogy, based on the arguments of an ITAT paper, is IPv6 as it comes with a built-in payment system. The Early-Adopters incentive(s) did not work for IPv6. How could the IETF provide a long-term advantage in its protocols? Did having the policy-making organizations mentioned by example in the draft make a significant difference [3] in turning the IPv6 transition into an example of a successful protocol transition? Is the IAB responsible for planning for transition for an IETF protocol? Regards, S. Moonesamy 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807107 2. https://bitcoin.org/bitcoin.pdf 3. I am not sure about the meaning of "enabled" or "facilitated". From nobody Wed Jan 11 03:57:30 2017 Return-Path: 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 D34A3129E1B for ; Wed, 11 Jan 2017 03:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 X4Kf6pzW2hqM for ; Wed, 11 Jan 2017 03:57:27 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA36129E19 for ; Wed, 11 Jan 2017 03:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2499; q=dns/txt; s=iport; t=1484135847; x=1485345447; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=q/e/GwXxbTbvxip46rJM9UtNoLYo/EMAZK0ZtPzwEnU=; b=err0Sum6MJejS1pEcBNmmkFm302w4eBaUWBaUnYpOTjChKn5HppRFFWT Q8wZVauzaUJVDWN2sqmJMv0SPA9GX2NAswA1LyQMjr609RdBQGl6Ert7S cNZOgPWeYYvIT8gNC3Dqi7As2OY8xORf2jka9TQ6i8NjC3r12VaZ/jChy 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAQD+HHZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAYEBLIQtighykSGVJ4ILhRKBEAKCLxQBAgEBAQEBAQF?= =?us-ascii?q?jKIRqAQUdBlYQCxgjBwICVwYNCAEBiHywPoIlihYBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERD4hHgl+HToJeBZAZixGDZ4F/i22KLYY4kmEfOIETEgcVFYUigWgdiRsBAQE?= X-IronPort-AV: E=Sophos;i="5.33,345,1477958400"; d="asc'?scan'208";a="651526741" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 11:57:23 +0000 Received: from [10.61.98.112] (dhcp-10-61-98-112.cisco.com [10.61.98.112]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0BBvM2L006722; Wed, 11 Jan 2017 11:57:22 GMT To: Martin Thomson References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> From: Eliot Lear Message-ID: <378aa597-20e0-781e-98da-1391e4d74fb8@cisco.com> Date: Wed, 11 Jan 2017 03:57:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1I6Xg5a2j04Hb7lH8e225FJlMQedaK68r" Archived-At: Cc: IAB , architecture-discuss@ietf.org Subject: Re: [arch-d] [IAB] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:57:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1I6Xg5a2j04Hb7lH8e225FJlMQedaK68r Content-Type: multipart/mixed; boundary="6kbVHuM7vFrhCK1FXqPn7SuluhAVD9JTl"; protected-headers="v1" From: Eliot Lear To: Martin Thomson Cc: architecture-discuss@ietf.org, IAB Message-ID: <378aa597-20e0-781e-98da-1391e4d74fb8@cisco.com> Subject: Re: [IAB] Call for Comment: (Out With the Old and In With the New: Planning for Protocol Transitions) References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> In-Reply-To: --6kbVHuM7vFrhCK1FXqPn7SuluhAVD9JTl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, On 1/10/17 5:27 PM, Martin Thomson wrote: > In my opinion, the question of whether you intend for the old version > to eventually disappear is usually a moot question for protocols. The > HDTV example might not apply here. I can't imagine we'd be looking to > reassign the meaning of version 4 in the IP header any time soon. > > Protocols either die or they don't and we only care to the extent that > we have to support them. That might be a point worth capturing, but your use of version 4 is well chosen, because we are quite a lot about the resources associated to it versus version 6 ;-) Eliot --6kbVHuM7vFrhCK1FXqPn7SuluhAVD9JTl-- --1I6Xg5a2j04Hb7lH8e225FJlMQedaK68r 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 iQEcBAEBCAAGBQJYdh2hAAoJEIe2a0bZ0nozP/oIAKcbXU2QJM4oBdBjtAJxzejG la85Q+YImWt3KVv5OZHMOCxeHjTHYhNlqQS0vQoQCzEUXQyyJaX/2DDd93TbQaBH WWB6INSGyWyTR8vxsQF/tLY5+qxw8k5XvoIkx4V6teFYHDxrryZgaYOI7319XcuK 8p9KHFL+NmWfGwug43tVcUmu91Xb4kB65fQ3m6h1A+z26w1ZF5FBCDnVd6unplrA 8d/xnIFekPCKOfSwtt7sagMdDoDJCKpm3+N3J7qujEpVWsNNz4+W89DX/mG5DkXG T2YqlTYDuIRDzYNnX5qb/W6O7FfZbTs4CzrpWjO7JXmOGsH09LhmaK/f7wFW1uM= =DgYI -----END PGP SIGNATURE----- --1I6Xg5a2j04Hb7lH8e225FJlMQedaK68r-- From nobody Wed Jan 11 08:53:30 2017 Return-Path: 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 89C1A12975C for ; Wed, 11 Jan 2017 08:53:28 -0800 (PST) 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 mQrnlj6W9BWN for ; Wed, 11 Jan 2017 08:53:27 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 0EFE7129681 for ; Wed, 11 Jan 2017 08:53:27 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id 11so116219439qkl.3 for ; Wed, 11 Jan 2017 08:53:26 -0800 (PST) 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=NPMBrdRS0F49R70etCahxBK4eImO1+YjC8EnoH3YkM4=; b=gvb1uBTYGJvSEjmp+E9VWCs9Ir/NT80i3ppI9asyih9d5ueeTvExSvd5WyIAjYfdL3 9wXqlpmjXctO0o9si9VnBZqJDilLxBFf96slLnJjvd7Ll9PL41iaVn/Il7AwQayVuvuA +bAgiFW7TH07irv73Zszyekf0f9qGsIC9Z0mSeWQEFZIJz4qMQwKhYBbvWid5kWLJ14q atlDYIqOtZfeayzLHCaFDWDltXna14jSqFQUo0Yg1Sr7NMF3Zn+u26pEm4QlQBGBanuT CQ8Vkmdyb8ONpwW19RzrtgaBw8upKqgqTJULhwZ1iFrJmT2K7ZYBGcmhEMCboNdJJXQK E4Tg== 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=NPMBrdRS0F49R70etCahxBK4eImO1+YjC8EnoH3YkM4=; b=qz+AhbWC4/YcKASS+NbSbnXaDahzdvoofb+FmYclqAM/uxfu8oun41udJso8KXkyDk dJLmqPjrcLYc42IG7mIGZpAI1yU18I0+x/3lPfg0t6OfZ/WbOOnk8DPsd45taLYx5++U 7Of8Xj8cD5fg0r49JjNRXYcRgXYdnaDKAf8gv3LgGC1V8yVcmH3cLflaYzAF8Ndn+NB2 M7yF353VygAmtQpskBCwMA1epzCU5d3FLoNzfIETaL0nUwgeGQDOXgMx0cNHNJ3azfsk VLwslccn6ZAD2Kra/2c3DaN988u3QLFombQIQW7RGxdJhX7BiS1C1TZLNzGZwKFlWsdL YO1g== X-Gm-Message-State: AIkVDXKb6CIFpljsGiLmJq2938o4D1p40vYQ2ad3Q2ukKZIOqSpqWOwsUqVqcQ4xtDjl85FOjGIi61iVfdiBKg== X-Received: by 10.55.105.70 with SMTP id e67mr2276697qkc.89.1484153606092; Wed, 11 Jan 2017 08:53:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.182.66 with HTTP; Wed, 11 Jan 2017 08:52:55 -0800 (PST) In-Reply-To: <6.2.5.6.2.20170110191336.0e812710@elandnews.com> References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> <3f13be22-cf8a-d2b8-6ac3-70f405e2a04b@cisco.com> <6.2.5.6.2.20170110191336.0e812710@elandnews.com> From: Ted Hardie Date: Wed, 11 Jan 2017 08:52:55 -0800 Message-ID: To: S Moonesamy Content-Type: multipart/alternative; boundary=001a114fe7247bbcf60545d470ca Archived-At: Cc: IAB , architecture-discuss@ietf.org Subject: Re: [arch-d] [IAB] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:53:28 -0000 --001a114fe7247bbcf60545d470ca Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 9:35 PM, S Moonesamy wrote: > Hi Martin, Eliot, > > > Is the IAB responsible for planning for transition for an IETF protocol? > > The charter of the IAB puts long-range planning in the IAB's set of responsibilities when that is done as part of its architectural oversight (see section 2.1 of RFC 2850). In practice that means that some transitions are completely outside of the IAB's remit, some the IAB contributes to (by reviewing charters for proposed work, proposing workshops on the relevant space, etc.), and some it advocates (the transition to default-confidential operation for the Internet being the most recent). Once the community accepts the advocacy, though, the work goes on in the IETF. regards, Ted > Regards, > S. Moonesamy > > --001a114fe7247bbcf60545d470ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 10, 2017 at 9:35 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Hi Martin, Eliot,


Is the IAB responsible for planning for transition for an IETF protocol?

The charter of the IAB puts long-range= planning in the IAB's set of responsibilities when that is done as par= t of its architectural oversight (see section 2.1 of RFC 2850).=C2=A0 In pr= actice that means that some transitions are completely outside of the IAB&#= 39;s remit, some the IAB contributes to (by reviewing charters for proposed= work, proposing workshops on the relevant space, etc.), and some it advoca= tes (the transition to default-confidential operation for the Internet bein= g the most recent).=C2=A0 Once the community accepts the advocacy, though, = the work goes on in the IETF.

regards,

= Ted
=C2=A0
Regards,
S. Moonesamy


--001a114fe7247bbcf60545d470ca-- From nobody Sat Jan 14 15:48:36 2017 Return-Path: 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 DD9BD129E7A; Sat, 14 Jan 2017 15:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 u47utVk0O3fM; Sat, 14 Jan 2017 15:48:33 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 B2511129E76; Sat, 14 Jan 2017 15:48:33 -0800 (PST) Received: from [10.32.60.28] (50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v0ENlcZh060209 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 14 Jan 2017 16:47:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-163.dsl.dynamic.fusionbroadband.com [50.1.51.163] claimed to be [10.32.60.28] From: "Paul Hoffman" To: architecture-discuss@ietf.org, iab@iab.org Date: Sat, 14 Jan 2017 15:48:31 -0800 Message-ID: <0D528A55-C9C1-413A-8067-31157CDB99DB@vpnc.org> In-Reply-To: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> References: <148357904166.13056.1797751203596240116.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Subject: Re: [arch-d] Call for Comment: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 23:48:35 -0000 On 4 Jan 2017, at 17:17, IAB Executive Administrative Manager wrote: > This is an announcement of an IETF-wide Call for Comment on > draft-iab-protocol-transitions-05. I have read this version of the draft and think it will be a useful RFC. Kudos for having the document also cover transitions outside the IETF standards process; this document can be useful to developers who have created proprietary standards as well as organizations transitioning from one type of communications system to another. Having case studies that run the gamut from "this worked well" to "this was painful" is also valuable. --Paul Hoffman From nobody Tue Jan 17 07:50:29 2017 Return-Path: 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 DED86129544; Tue, 17 Jan 2017 07:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 Ptig21w-6lkh; Tue, 17 Jan 2017 07:50:25 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 88FEA129541; Tue, 17 Jan 2017 07:50:25 -0800 (PST) Received: from [10.199.9.122] ([12.219.129.12]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v0HFprOI028295 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jan 2017 07:51:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1484668313; bh=X8e+H2YmDJlBw0wdcP26SHgnvaswoPfO5kIaXKj5fCU=; h=From:Subject:To:Cc:Reply-To:Date:From; b=O47VwcvYcS0KCYLnJA40PasgqdJvMz8Dnzw2IHtYZTSuxSA4i/7krzvqt6b5P3nym 2+wSikySTK3DHR54h92UdRftYVnFuURrGHEmCssSKejgkJ866Nhs04l3MhU35gb1vD CZ61tEhPB7/BqzTy/rQ0huvjIyswwpf7WeZ/TU4M= From: Dave Crocker Organization: Brandenburg InternetWorking To: architecture-discuss@ietf.org Message-ID: <80f3ae1d-b303-7d58-7b14-495dc09e6f05@dcrocker.net> Date: Tue, 17 Jan 2017 07:50:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IAB IAB Subject: [arch-d] Review of: draft-iab-protocol-transitions-05 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:50:28 -0000 Review of: draft-iab-protocol-transitions-05 Reviewer: D. Crocker Date: 16 Jan 2017 Summary: The draft provides an overview of the issues in achieving a transition from one capability to another. (It's worth considering whether this should include introduction of new capabilities -- that is, "transitioning" from no capability. Many adoption issues are the same. The topic is of fundamental importance to IETF work and is often overlooked or viewed idealistically. So a document like this should be quite helpful (if folks will pay attention to it.) The document is well-organized and well-written. There are some clarifications and expansions worth considering, as noted below, and some basic points cited here: The document tends to merely mention essential issues, such as incentives, without giving much insight into either methods for adequately assessing incentives or deciding how to consider them in protocol design. The document also seems to conflate "adoption" with "transition". Much of the content of the document applies to initial adoption of a protocol, as well as to later transitions to revisions. While transitions carry significant additional burdens, beyond initial adoption, the IETF needs attention to initial adoption issues every bit as much as it needs attention to transition issues. Although the document references open source implementations and the challenges of having a timeline, it should emphasize the role of the former more and the severe problems with the latter. Might be worth adding some examples of highly successful transitions. MIME is, predictably, my favorite example. There had been multiple attempts to replace existing, text-based email with a new version that supported multi-media. MIME instead created an overlay that required no change to the infrastructure. These above suggestions are in line with Eliot's call for more 'meat'. The document touches on essential issues. But for the IETF to deal with the issues well, there needs to be more detailed basis giving guidance for how to attend to them. This is particularly important for issues such as incentives analysis and aligning to incentives, since they are topics not normally within the purview of Internet engineers. (If the feeling is that the meat should be added via later documents then there should at least, now, be development of some plan for those documents.) Stewart's call for considering the requirement of transition considerations -- I'd suggest 'adoption considerations' -- would press working groups to do far more due diligence about the barriers to adoption that is typically done now. Detailed: > 1. Introduction > > A "transition" is "the process or period of changing from one state > or condition to another". There are several types of such Use of quotation marks implies that the text comes from elsewhere. Where? > transitions, including both technical transitions (e.g., changing > protocols or deploying an extension) and organizational transitions > (e.g., changing what organization manages the IETF web site, or the > RFC production center). This document focuses solely on technical It would be better for the examples to not be IETF-centric and especially not to require the reader to know about the internals of the IETF, such as about the RFC production center. In this case, perhaps: changing what organization manages a web site that uses IETF specifications. Would authorizing a new network management team constitute a transition? > 2. Transition vs. Co-existence > > There is an important distinction between a strict "flag-day" style > transition where an old mechanism is immediately replaced with a new > mechanism, vs. a looser co-existence based approach where transition > proceeds in stages where a new mechanism is first added alongside an > existing one for some overlap period, and then the old mechanism is > removed at a later stage. > > When a new mechanism is backwards compatible with an existing > mechanism, transition is easiest, and the difference between the two > types of transition is not particularly significant. However, when I suspect you don't mean quite what is written. The differences still might be highly significant. More likely: transition is easiest because the timing of adoption by each party is not critical. > no backwards compatibility exists (such as in the IPv4 to IPv6 > transition), a transition plan must choose either a "flag day" or a > period of co-existence. When a large number of entities are > involved, a flag day becomes impractical. Coexistence, on the other > hand, involves additional costs of maintaining two separate > mechanisms during the overlap period which could be quite long. > Furthermore, the longer the overlap period, the more the old > mechanism might get further deployment and thus increase the overall > pain of transition. A phrase like "period of co-existence" encourages the reader to think that the period can be constrained. Besides making flag days impractical, large scale operation renders control over the length of a transition impractical. In fact it tends to ensure an extremely long adoption tail, measured in years and probably decades. This is not a small point, when designing for transitions. At base, 'transitions' for Internet scale are really long-term cohabitation. > Often the decision between a "flag day" and a sustained co-existence > period may be complicated when differing incentives are involved > (e.g., see the case studies in the Appendix). For any IETF work, when has a flag day been specified and implemented successfully? While the idea of a flag day is appealing, it isn't ever practical both because of Internet scale and because multiple, independent administrations are (nearly) always involved. > > 3. Translation/Adaptation Location > > A translation or adaptation mechanism is often required if the old > and new mechanisms are not interoperable. Care must be taken when > determining whether one will work and where such a translator is best > placed. > > A translation mechanism may not work for every use case. For > example, if a translation from one protocol (or protocol version) to > another produces indeterminate results, translation will not work > reliably. In addition, if translation always produces a downgraded > protocol result, the incentive considerations in Section 4.2 will be > relevant. > > Requiring a translator in the middle of the path can hamper end-to- > end security and reliability. For example, see the discussion of > network-based filtering in [RFC7754]. > > On the other hand, requiring a translation layer within an endpoint > can be a resource issue in some cases, such as if the endpoint could > be a constrained node [RFC7228]. > > In addition, when a translator is within an endpoint, it can can > attempt to hide the difference between an older protocol and a newer > protocol, either by exposing one of the two sets of behavior to > applications and internally mapping it to the other set of behavior, > or by exposing a higher level of abstraction which is then > alternatively mapped to either one depending on detecting which is > needed. In contrast, when a translator is in the middle of the path, > typically only the first approach can be done since the middle of the > path is typically unable to provide a higher level of abstraction. > > Any transition strategy for a non-backward-compatible mechanism > should include a discussion of where it is placed and a rationale. > The transition plan should also consider the transition away from the > use of translation and adaptation technologies. This discussion should also consider the complexity of translation required. It is sometimes possible to make the new design easier to translate to/from the old, or to make it more difficult. Enthusiasm for new features often causes this point to be ignored. The original Deering IPv6 design was pretty easy to translate. In fact, if IPv6 addressing had been made a superset of existing IPv4, translation would have been trivial. The major challenge in translation is for semantic differences. Often, syntactic differences can be translated seamlessly. Semantic ones almost never. Hence, attention to transition, when there is any interest in translation, should include documenting the syntactic and semantic differences; > > 4. Transition Plans > > A review of the case studies described in Appendix A suggests that a > good transition plan includes at least the following components: an > understanding of what is already deployed and in use, an explanation > of incentives for each entity involved, a description of the phases > of the transition along with a proposed timeline, a method for Overall, quite a good list. However for IETF efforts -- that is, for anything to be deployed at Internet scale -- any concept of a transition timeline is misleading, at best. There is no history of succeeding with an attempt at timely transition, nevermind attempting to predict it. Hence, trying to set a schedule distracts from the well-established track showing that transitions essentially take forever. Hence the most practical approach is to talk about adoption milestones and, in particular, considering what constitutes 'critical mass'. That is, when is it reasonable to consider adoption sufficient to ensure the continued use and further adoption of the capability? Also, there is almost always need for an entity facilitating the transition. The issue here isn't one of authority but of advocacy and focus. Otherwise -- even with a good understanding of incentives -- the effort is left to happenstance. This is an entity independent of the IETF. > > > Thaler Expires July 8, 2017 [Page 5] > > > Internet-Draft Planning for Transition January 2017 > > > measuring the transition's success, a contingency plan for failure of > the transition, and an effective method for communicating the plan to > the entities involved and incorporating their feedback thereon. We > recommend that such criteria be considered when evaluating proposals > to transition to new or updated protocols. Each of these components > is discussed in the subsections below. > > 4.1. Understanding of Existing Deployment > > Often an existing mechanism has variations in implementations and > operational deployments. For example, a specification might include > optional behaviors that may or may not be implemented or deployed. > In addition, there may also be implementations or deployments that > deviate from, or include vendor-specific extensions to, various > aspects of a specification. It is important when considering a > transition to understand what variations one is intending to > transition from or co-exist with, since the technical and non- > technical issues may vary greatly as a result. > > 4.2. Explanation of Incentives > > A transition plan should explain the incentives to each involved > entity to support the transition. Note here that many entities other > than the endpoint applications and their users may be affected, and > the barriers to transition may be nontechnical as well as technical. > When considering these incentives, also consider network operations > tools, practices, and processes, personnel training, accounting and > billing dependencies, and legal and regulatory incentives. It's worth noting that an analysis of incentives is too easily led astray by wishful thinking and by a failure to adequately consider the realities of the entities being described. An obvious (and frequent) example of misjudging incentives is ever thinking that any commercial operation adopts something out of a sense of civic obligation or long-term benefit. Although there are, of course, exceptions, the pattern is never encouraging. Consequently, analysis of incentives should carefully justify the /basis/ for claiming the incentives. This is aided by an honest consideration of the barriers to adoption for each entity. What could cause them to fail to adopt or take longer? > If there is opposition to a particular new protocol (e.g., from > another standards organization, or a government, or some other > affected entity), various non-technical issues arise that should be > part of what is planned and dealt with. Similarly, if there are > significant costs or other disincentives, the plan needs to consider > how to overcome them. The pragmatics of the incentives analysis is facilitated by looking at whatever advocacy group has formed to promoted the adoption. Who are the folk promoting the transition and what are their capabilities for making it likely to succeed. Here, too, the challenge is to avoid wishful thinking... > > 4.3. Description of Phases and Proposed Timeline > > Transition phases might include pilot/experimental deployment, > coexistence, deprecation, and removal phases for a transition from > one technology to another incompatible one. Hmmm. Rather than attempting a timeline, it probably helps more to consider specifying criteria that need to be satisfied, to go from one phase to the next. So a term like "phases" and "milestones" makes more sense. > Timelines are notoriously difficult to predict and impossible to > impose on uncoordinated transitions at the scale of the Internet, but > rough estimates can help all involved entities to understand the > intended duration of each phase. So, yes, good that this is in the document, but I'll suggest it show up earlier and, if anything, even stronger. > > > > > Thaler Expires July 8, 2017 [Page 6] > > > Internet-Draft Planning for Transition January 2017 > > > 4.4. Measurement of Success > > The degree of deployment of a given protocol or feature at a given > phase in its transition can be measured differently, depending on its > design. For example, server-side protocols and options which > identify themselves through a versioning or negotiation mechanism can > be discovered through active Internet measurement studies. > > 4.5. Contingency Planning > > A contingency plan can be as simple as providing for indefinite > coexistence between an old and new protocol. This seems an unusual enough topic to warrant more detail. What types of contingency have been done and proved useful? What other sorts might be considered? > > 4.6. Communicating the Plan > > Many of the entities involved in a protocol transition may not be > aware of the IETF or the RFC series, so dissemination through other > channels is key for sufficiently broad communication of the > transition plan. While flag days are impractical at Internet scale, > coordinated "events" such as World IPv6 Launch may improve general > awareness of an ongoing transition. Yes, but... Is there any basis for believing that that event was actually useful in gaining wider adoption? If so, it's worth citing the documentation. How do the IPv6 statistics support this? My point is that events should be considered with a skeptical eye towards pragmatics. It is far too easy to conduct an event that feels encouraging to those putting it on but which has little practical benefit. The downside of this is that, at the least, it drains energy from the community promoting adoption. > Appendix A. Case Studies > > Appendix A of [RFC5218] describes a number of case studies that are > relevant to this document and highlight various transition problems > and strategies (see for instance the Inter-Domain Multicast case > study in Section A.4 of [RFC5218]). We now include several > additional case studies that focus on transition problems and > strategies. Many other equally good case studies could have been > included, but, in the interests of brevity, only a sampling is > included here that is sufficient to justify the conclusions in the > body of this document. > > A.1. Explicit Congestion Notification This one sounds more like "adoption" than "transition". It's a new mechanism and the adjustments were to find a way to get /any/ stable use. > A.2. Internationalized Domain Names > > The deployment of Internationalized Domain Names (IDN) has a long and > complicated history. This should not be surprising, since > internationalization deals with language and cultural issues > regarding differing expectations of users around the world, thus > making it inherently difficult to agree on common rules. > Furthermore, because human languages evolve and change over time, > even if common rules can be established, there is likely to be a need > to review and update them regularly. > > There have been multiple technical transitions related to IDNs, There have been multiple specifications. From what I've seen, the specification process has paid little attention to transition. (There's an ICANN initiative to get better /adoption/, but that's not strictly the same as is meant here for /transition/.) This section highlights the challenge of distinguishing between the fact of specification evolution, versus the process of transitioning between versions. This section seems to cite the specifications rather than transition details. > including the introduction of non-ASCII in DNS, the transition to > each new version of Unicode, and the transition from IDNA 2003 to > IDNA 2008. A brief history of the introduction of non-ASCII in DNS > > > > Thaler Expires July 8, 2017 [Page 12] > > > Internet-Draft Planning for Transition January 2017 > > > and the various complications that arose therein, can be found in > section 3 of [RFC6055]. While IDNA 2003 was limited to Unicode > version 3.2 only, one of the IDNA 2008 changes was to decouple its > rules from any particular version of Unicode (see [RFC5894], > especially section 1.4, for more discussion of this point, and see > [RFC4690] for a list of other issues with IDNA 2003 that motivated > IDNA 2008). However, the transition from IDNA 2003 to IDNA 2008 > itself presented a problem since IDNA 2008 did not preserve backwards > compatibility with IDNA 2003 for a couple of codepoints. > Investigations and discussions with affected parties led to the IETF > ultimately choosing IDNA 2008 because the overall gain by moving to > IDNA 2008 to fix the problems with IDNA 2003 was seen to be much > greater than the problems due to the few incompatibilities at the > time of the change, as not many IDNs were in use, and even fewer that > might see incompatibilities. > > A couple browser vendors in particular were concerned about the couple of > differences between IDNA 2003 and IDNA 2008, and the fact that if a > browser stopped being able to get to some site, or unknowingly sent a > user to a different (e.g., phishing) site instead, the browser would > be blamed. As such, any user-perceivable change from IDNA 2003 > behavior would be painful to the vendor to deal with, and hence they > could not depend on solutions that would need action by other > entities. > > Thus, to deal with issues like such incompatibilities, applications > and client-side frameworks often want to map one string into another > (namely, a string that would give the same result as when IDNA 2003 > was used) before invoking DNS. "want"? this sounds more like prescription than about a case study of what actually was done. > To provide such mapping (and some other functioanlity), the Unicode > Consortium published [TR46] that continued down the path of IDNA 2003 > with a code point by code point selection mechanism. This was > implemented by some, but never adopted by the IETF. > > Meanwhile, the IETF did not publish any mapping mechanism, but > [RFC5895] was published on the Independent Submission stream. In > discussions around mapping, one of the key topics was about how long > the transition should last. At one end of the duration spectrum is a > flag day where some entities would be broken initially but the change > would happen before IDN usage became even more ubiquitous. At the > other end of the spectrum is the need to maintain mappings > indefinitely. Local incentives at each entity who needed to change, > however, meant that a short timeframe was impractical. I don't understand the above. Again, it appears to be a discussion of possibilities rather than the details of something that was part of a case study. > > There are many affected types of entities with very different > incentives. For example, the incentives affecting browser vendors, > registries, domain name marketers and applicants, app developers, and > > > > Thaler Expires July 8, 2017 [Page 13] > > > Internet-Draft Planning for Transition January 2017 > > > protocol designers are each quite different, and the various > solutions require changes by multiple types of entities, where the The substance of listing these entities is in talking about actual incentives, not merely saying they will be different. Readers need to see enough detail to learn something about applying the concern they should have. > benefits do not always align with the costs. If there is some group > (or even an individual) that is opposed to a change/transition and > able to put significant resources behind their opposition, > transitions get a lot harder. > > Finally, it is worth pointing out that there are multiple naming > contexts, and the protocol behavior within each naming context can be Huh? How is this statement relevant to IDN? > different. Hence applications and frameworks often encounter a > variety of behaviors and may or may not be designed to deal with > them. See sections 2 and 3 of [RFC6055] for more discussion. > > In summary, all this diversity can cause problems for each affected > entity, especially if a competitor does not have such a problem, > e.g., for browser vendors if competing browsers do not have the same > problems, or for an email server provider if competing server > providers do not have the same problems. > > A.3. IPv6 ... > Indeed, not until a few years after IPv4 runout in various Regional > Address Registry (RIR) regions did IPv6 deployment significantly > increase. The RIRs and others conducted surveys of different > industries and industry segments to learn why people did not deploy > IPv6 [IPv6Survey2011] [IPv6Survey2015], which commonly listed lack of > a business case, lack of training, and lack of vendor support as > primary hurdles. Arguably forward-looking companies collaborated > with ISOC on World IPv6 Day and World IPv6 Launch to jump start > global IPv6 deployment, and arguably their work gave vendors What incentives did it give them? > incentives to support IPv6 well. Key aspects of World IPv6 Day and > World IPv6 Launch that contributed to their successes were the > communication mechanism, and the measurement metrics and contingency > plans that were announced in advance. As a case study it will help to describe what constituted success for these events and why those criteria were the right ones. > Several efforts have been made to mitigate the lack of a business > case. Some governments (South Korea, Japan) provided tax incentives > to include IPv6. Other governments (Belgium, Singapore) mandated > IPv6 support by private companies. Few of these had enough value to > drive significant IPv6 deployment. > > The concern about lack of training is often a common issue in > transitions. Because IPv4 is so ubiquitous, its use is routine and > simplified with common tools, and it is taught in network training > everywhere. While IPv6 deployment was low, ignorance of it was no > obstacle to being hired as a network administrator or developer. > > Organizations with the greatest incentives to deploy IPv6 are those > which continue to grow quickly, even after IPv4 free pool exhaustion. > > > > Thaler Expires July 8, 2017 [Page 15] > > > Internet-Draft Planning for Transition January 2017 > > > Thus, ISPs have had varying levels of commitment, based on the growth > of their user base, services being added (especially video over IP), Really? That makes theoretical sense, but what is the data to support it? > and the number of IPv4 addresses they had available. Cloud-based > providers, including CDN and hosting companies, have been major > buyers of IPv4 addresses, and several have been strong deployers and > advocates of IPv6. As an example, this fact mostly serves to highlight how difficult it is to figure who has what incentive. > > Different organizations will use different transition models for > their networks, based on their needs. Some are electing to use > IPv6-only hosts in the network with IPv6-IPv4 translation at the > edge. Others are using dual-stack hosts with IPv6-only routers in > the core of the network, and IPv4 tunneled or translated through them > to dual-stack edge routers. Still others are using native dual-stack > throughout the network, but that generally persists as an interim > measure: adoption of two technologies is not the same as > transitioning from one technology to another. Finally, some walled > gardens or isolated networks, such as management networks, use > IPv6-only end-to-end. Again, knowing that there is such variance highlights a problem but does not offer insight into dealing with it. > > It is impossible to predict with certainty the path IPv6 deployment > will have taken when it is complete. Lessons learned so far include > aligning costs and benefits (incentive), and ensuring incremental > benefit (network effect, or backward compatibility). > > A.4. HTTP/2 > > HTTP/2 [RFC7540] is a new version of the popular HTTP protocol > [RFC7230]. The original versions of HTTP (0.9 [HTTP0.9], 1.0 > [RFC1945], and 1.1 [RFC2616]) have only small differences; each > iteration made small improvements over the previous version without > making major changes. > > The changes in HTTP/2 are largely aimed at improving performance. > The primary improvement is request multiplexing, which is supported is to > by request prioritization and flow control. HTTP/2 includes > efficiency improvements with header compression [RFC7541] and binary > framing. > > A.4.1. Bundling of Features with New Versions > > The bundling of additional constraints on a new version of a protocol > could affect adoption by making the transition more costly. However, > the transition to a new version also represents an opportunity to > improve multiple aspects of a protocol at the same time. > > The HTTP working group decided that a new version of the protocol > represented an opportunity to improve security posture. HTTP/2 is > much stricter about its use of TLS. In particular, a long list of "to improve security posture"? is a word missing? > > > > Thaler Expires July 8, 2017 [Page 16] > > > Internet-Draft Planning for Transition January 2017 > > > TLS cipher suites are prohibited, constraints are placed on the key > exchange method, and renegotiation is prohibited. These changes did > cause deployment problems. Though most were minor and transitory, > disabling renegotiation caused problems for deployments that relied > on the feature to authenticate clients and prompted new work to > replace the feature. > > A number of other features or characteristics of HTTP were identified > as potentially undesirable. Several such features were considered > for removal during the design process. This included trailers, the > 1xx series of responses, certain modes of request forms, and the > unsecured (http://) variant of the protocol. For each of these, the > risk to the successful deployment of the new version was considered > to be too great to justify removing the feature. However, deployment > of the unsecured variant of HTTP/2 remains extremely limited. I'm not understanding the basis for having the 'However' here. How does that sentence connect with the preceding text? For that matter, what is the 'unsecured variant'? > > A.4.2. Planning for Replacement > > HTTP/1.1 provides a mechanism, Upgrade, to transition to an entirely > different protocol. That same facility was little used other than to > enable the use of WebSockets [RFC6455]. However, with performance > being a primary motivation for HTTP/2, a new mechanism was needed to > avoid spending an additional round trip on this negotiation. A new > mechanism was added to TLS to permit the negotiation of the new > version of HTTP: Application Layer Protocol Negotiation (ALPN) > [RFC7301]. Upgrade was used only for the unsecured variant of the > protocol. This highlights a problem with a mechanism that is put into a protocol 'for future use' and without having adequate sense of how it will be used. It tends not to work very well (or at all.) This also happened with SNMP's original 'security' field. > > ALPN was identified as the way in which future protocol versions > would be negotiated. The mechanism was well-tested during > development of the specification, which proved that new versions > could be deployed safely and easily using ALPN. Several draft > versions of the protocol were successfully deployed during protocol > development, and version negotiation was never shown to be an issue. > > Confidence that new versions would be easy to deploy if necessary > lead to a particular design stance that might be considered unusual > in light of the advice in RFC 5218 [RFC5218], though is completely > consistent with RFC 6709 [RFC6709]: many of the ways in which the > protocol might be extended were removed unless an immediate need was > understood. This decision was made on the basis that it would be > easier to revise the entire protocol than it would be to ensure that > an extension point was correctly specified and implemented such that > it would be available when needed. This is far to important an observation to have it buried at the end of the appendix. -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 26 20:06:34 2017 Return-Path: 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 B1F50129C92 for ; Thu, 26 Jan 2017 20:06:32 -0800 (PST) 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=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 cdwNG4Aoh0-m for ; Thu, 26 Jan 2017 20:06:31 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D08129453 for ; Thu, 26 Jan 2017 20:06:31 -0800 (PST) Received: (qmail 14664 invoked from network); 27 Jan 2017 04:06:29 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Jan 2017 04:06:29 -0000 Date: 27 Jan 2017 04:06:07 -0000 Message-ID: <20170127040607.77613.qmail@ary.lan> From: "John Levine" To: rfc-interest@rfc-editor.org In-Reply-To: <97787578-d1ef-12d2-9faf-30da51e3b5c2@rfc-editor.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: iab@iab.org, architecture-discuss@ietf.org Subject: Re: [arch-d] [rfc-i] Fwd: Call for Comment: (Digital Preservation Considerations for the RFC Series) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 04:06:32 -0000 >Abstract > > The RFC Editor is both the publisher and the archivist for the RFC > Series. This document applies specifically to the archivist role of > the RFC Editor. It provides guidance on when and how to preserve > RFCs, and the tools required to view or re-create RFCs as necessary. > This document also highlights where gaps are in the current process, > and where compromises are suggested to balance cost with ideal best > practice. I'm generally in agreement with the advice in this draft, except for the parts about paper. We know that good quality paper with black ink is stable for centuries, because we have books from the 1700s and earlier in libraries that we can still read. I also know a surprising number of people doing retrocomputing who retype source code from old printouts from the 1960s. After 50 years, the electronic media are missing or unreadable, but the printouts are still OK. So I would suggest printing out the XML and perhaps one of the formatted versions (so they can see what the XML is supposed to say) of RFCs on good paper and filing them away. I think we can assume that OCR in the future will be at least as good as it is now, so as long as the printouts use a reasonable typeface, it'll be possible to scan them in if need be. It doesn't have to be in real time; a printathon once or twice a year should be plenty. R's, John From nobody Tue Jan 31 15:02:13 2017 Return-Path: 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 CF1E4129A6B for ; Tue, 31 Jan 2017 15:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 f42qx_G28JPe for ; Tue, 31 Jan 2017 15:02:10 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073FD12963A for ; Tue, 31 Jan 2017 15:02:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 676981E566B; Tue, 31 Jan 2017 15:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlaGfmUwgFkG; Tue, 31 Jan 2017 15:00:57 -0800 (PST) Received: from Heathers-MacBook-Pro.local (c-50-159-75-65.hsd1.wa.comcast.net [50.159.75.65]) by c8a.amsl.com (Postfix) with ESMTPSA id 0EFD51E5669; Tue, 31 Jan 2017 15:00:56 -0800 (PST) To: John Levine , rfc-interest@rfc-editor.org References: <20170127040607.77613.qmail@ary.lan> From: "Heather Flanagan (RFC Series Editor)" Message-ID: <2a89e3c6-730a-3d35-6cb9-2d9425e400c7@rfc-editor.org> Date: Tue, 31 Jan 2017 15:02:08 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170127040607.77613.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: iab@iab.org, architecture-discuss@ietf.org Subject: Re: [arch-d] [IAB] [rfc-i] Fwd: Call for Comment: (Digital Preservation Considerations for the RFC Series) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:02:12 -0000 On 1/26/17 8:06 PM, John Levine wrote: >> Abstract >> >> The RFC Editor is both the publisher and the archivist for the RFC >> Series. This document applies specifically to the archivist role of >> the RFC Editor. It provides guidance on when and how to preserve >> RFCs, and the tools required to view or re-create RFCs as necessary. >> This document also highlights where gaps are in the current process, >> and where compromises are suggested to balance cost with ideal best >> practice. > I'm generally in agreement with the advice in this draft, except for > the parts about paper. > > We know that good quality paper with black ink is stable for > centuries, because we have books from the 1700s and earlier in > libraries that we can still read. I also know a surprising number of > people doing retrocomputing who retype source code from old printouts > from the 1960s. After 50 years, the electronic media are missing or > unreadable, but the printouts are still OK. > > So I would suggest printing out the XML and perhaps one of the > formatted versions (so they can see what the XML is supposed to say) > of RFCs on good paper and filing them away. I think we can assume > that OCR in the future will be at least as good as it is now, so as > long as the printouts use a reasonable typeface, it'll be possible to > scan them in if need be. It doesn't have to be in real time; a > printathon once or twice a year should be plenty. > Thank you for the feedback, John. Paper can indeed be a very stable material for archival purposes. For digital-born documents, I think it's insufficient for the purpose of archiving all the information intended to be captured with a digital document and leaving it readable for the future. Yes, information can be printed out that describes the metadata for the document. The XML is human readable, in that it is not encrypted or compiled in any way that a standard text reader and printer couldn't handle. However, all that readable-but-not-user-friendly paper takes up space and requires its own expertise to store and maintain in a properly archival fashion. The RFC Editor does not have that experience, nor the proper space, to store an ever growing body of work. We could of course work on that, buying the correct paper and ink, reprinting all the RFCs, and finding suitable climate (both humidity and temperature, with appropriate fire suppression) controlled storage to house the material. But that seems like a waste of resources when there are actual archivists who can and will handle our material properly, in its digital form. That said, of the archivists I've approached about the Series, the only paper of interest is the original set that has unique, hand-written annotations in the margins. All the newer documents are only interesting in their digital form. The content is still interesting, but it takes up much less physical space, and they have the processes in house for handling the issues of bit rot. They also expect to support the readability of the material (since we are using common publication formats) far into the future. Thanks, Heather