[Stackevo-discuss] some comments on draft-iab-protocol-transitions-05

Joe Touch <touch@isi.edu> Tue, 10 January 2017 22:50 UTC

Return-Path: <touch@isi.edu>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 408B51295D5 for <stackevo-discuss@ietfa.amsl.com>; Tue, 10 Jan 2017 14:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Bkpe53EyKNm7 for <stackevo-discuss@ietfa.amsl.com>; Tue, 10 Jan 2017 14:50:57 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu []) (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 24F3B1295F7 for <stackevo-discuss@iab.org>; Tue, 10 Jan 2017 14:50:57 -0800 (PST)
Received: from [] (nib.isi.edu []) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0AMoP73029617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Jan 2017 14:50:26 -0800 (PST)
To: "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>
From: Joe Touch <touch@isi.edu>
Message-ID: <3277f3d0-b937-a984-299f-b26983c37e5f@isi.edu>
Date: Tue, 10 Jan 2017 14:50:25 -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
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo-discuss/y26QoLkSKZfzZaksRGy8TVmT9OI>
Cc: Dave Thaler <dthaler@microsoft.com>
Subject: [Stackevo-discuss] some comments on draft-iab-protocol-transitions-05
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2017 22:50:58 -0000

Hi, Dave (et al.),

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



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

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.