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 important part. > -----Original Message----- > From: Keith Moore [mailto:moore@xxxxxxxxxx] > Sent: Tuesday, July 03, 2007 11:16 PM > To: Clint Chaplin > Cc: ietf@xxxxxxxx > 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 > >> protocol stack. > > adsl mib > > enum > > geopriv > > mediactrl > > speechsc > > emu > > kitten > > ltans > > openpgp > > pkix > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf