Subject: ruminations on late-game design changes

From: Paul Vixie <[email-masked]>
Date: Mon, 24 May 2004 14:35:06 +0000

it is widely agreed that ipv6 fails to resolve some of ipv4's longstanding
problems, such as the tension between the size of the routing table and
the size of a globally routeable address block, or address portability,
or address mobility, or automatic renumbering.  tony li once complained
about the speed of the ipv6 design cycle by saying that the delta between
ipv4 and ipv6 was "too little, too soon."  work continues to try to improve
the things that can be improved without new flag days -- but the point is,
the protocol design was frozen some years ago and some things were left out.

and so, in the 11th hour, when someone made a reasonable-sounding request
which was to change the ipv6 packet header format to put destination address
first, thus improving by 8 octet-times the earliest moment when a packet
level forwarding device could do cut-through routing/switching -- by starting
its CAM lookup earlier or whatever -- someone in the ipv6 working group had
what i'll call "the wisdom" to say, eternal microoptimization is a bad idea
and even if this particular idea is good, it would be part of something
larger than itself that would be bad, so, let's not do it.

i'd like to restate that case, but this time, against eternal redesign.  to
be sure, making enumeration more difficult isn't a microoptimization, it's
a redesign.  but the eternal redesign that has characterized the last ten
years of dnssec's "redesign cycle" is clearly no better a thing than eternal
microoptimization would have been.

once when praising the designers of Modula-3, niklaus wirth wrote that the
most difficult thing about programming language design was knowing what to
leave out.  i think this reasoning may apply to network protocol design also.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 May 2004 10:06:52 -0700

> leave out.  i think this reasoning may apply to network 

Bad example. Pascal was an abject failure because it contained
a major design flaw, it was impossible to implement I/O libraries
as character strings of different lengths were considered 
incompatible types.

This flaw was pointed out repeatedly during the design phase,
treated to similar filibustering, rejected by the standards
committee and every compiler devised a separate work arround.

Most of the flaws of C that demanded correction in Java and 
C# were solved long before in Pascal. C++ could have corrected 
them if total backwards compatibility had not crippled the 
design. Instead we had nearly fifteen years of wasted effort
in that field until Gosling worked out the right marketting
strategy to get the field back on track.

Tony Hoare was an advocate of simpler programming languages
long before Wirth, and he also pointed out (repeatedly) that
it could be overdone.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 May 2004 17:40:01 +0900

Paul Vixie;

> or address mobility, or automatic renumbering.

No.

IPv6 failed because it tries to solve a lot of problems most of
which are useless and impossible to solve. The only real problem
was routing table size one, which was seemingly too hard to solve
and ignored.

Packet format is a minor issue.

So is DNSSEC. In this case, real world operation is the real
problem and, unlike IPv6 one, is not solvable.

						Masataka Ohta