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

[Dave Thaler <[e-mail]>]

To circle back, I agree and have added a new "Extensibility" section to address
these comments and others, and I will post an update soon...

However much of the detailed technical discussion is actually in RFC 6709,
which is cited in the new section.

Thanks for the great feedback.

Dave

-----Original Message-----
From: Tom Herbert [mailto:[e-mail]] 
Sent: Tuesday, January 10, 2017 3:53 PM
To: Joe Touch <[e-mail]>
Cc: [e-mail]; Dave Thaler <[e-mail]>
Subject: Re: [Stackevo-discuss] some comments on draft-iab-protocol-transitions-05

On Tue, Jan 10, 2017 at 2:50 PM, Joe Touch <[e-mail]> wrote:
> 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.
>
Agreed. The topic of extensibility to facilitate protocol transition needs more discussion. The principle to "Design for extensibility [RFC6709] so that things can be fixed up later." really doesn't seem to have worked out very well for either IPv4 (IP options) or IPv6 (ext. hdrs.) in practice.

Tom

> 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.
>
> ------
>
> _______________________________________________
> Stackevo-discuss mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo-discuss