Well you say that you can't do this and that without knowing what you are doing.
A counterexample is the fact that the basic architecture of the most widely
used security protocol we have in use today were set by people who did not know
what they were doing. They had the good sense to later hire people who did but
they had already made the critical choices at that point.
Sure we beat them up for getting the security design wrong (he's talking about
an integrity attack, Marc), but they did make a design choice that none of the
rest of us who knew better would have done that has in hindsight turned out to
be completely right.
A similar set of issues surrounded the Web. The critical invention was 404 Not
Found. Scruffy links were the wrong way to do it in 1992 but today we
understand that only scruffy can work.
Architecture is about abstraction. Knowing what you can forget is the really
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Tuesday, July 03, 2007 11:16 PM
To: Clint Chaplin
Subject: Re: chicago IETF IPv6 connectivity
Clint Chaplin wrote:
there is NOBODY working in IETF for whom familiarity with IP,
including IPv6, is not essential.
whether they realize this is a different question. but
you cannot do
competent work in IETF without a basic understanding of the TCP/IP
my point stands. participants in all of these groups need to
understand basics of the TCP/IP protocol stack (including
UDP). for instance, you can't write a decent MIB without
understanding how SNMP works and to do that you need to
understand the consequences of its design choices (including
how it uses UDP). similarly, you can't do a competent job
designing new DNS records or using existing ones without
understanding the protocol limitations of DNS, which follow
to a large degree from
quirks in IP and UDP. You certainly can't do competent Internet
security work without understanding how the information is
going to be packetized, routed, and sent around the network,
and reassembled - i.e.
without understanding IP.
I once had a working group where the participants insisted
that they layer everything on top of HTTP because they didn't
understand TCP and weren't willing to learn. They didn't
even really understand HTTP or its limitations, for instance,
in being pretty much a remote-procedure-call mechanism (which
has certain inherent
inefficiencies) or being poor at handling asychronous
notifications (which they needed). All they knew was that
HTTP had APIs that they could call. And they didn't know how
to use those. And what they produced was a disaster.
Ietf mailing list
Ietf mailing list