From touch at ISI.EDU Fri Nov 2 10:02:41 2001 From: touch at ISI.EDU (Joe Touch) Date: Fri, 02 Nov 2001 10:02:41 -0800 Subject: [ih] Simple question References: <200108141701.MAA14839@neverland.cs.utexas.edu> <3B7BA5DF.82D0160C@vlsm.org> <3B80A4F0.4D203308@isi.edu> <3B80D1F3.C7D0662@vlsm.org> Message-ID: <3BE2DFC1.5050508@isi.edu> Rahmat M. Samik-Ibrahim wrote: ... > > Whoops, this is not related to Internet History :-). > But, I still have no idea on since when and why exactly > there exists "a 6 months expire limit" for Internet Drafts. > Perhaps it is related with the disk capacities in > the 1980s? The decision to make them expire was not related to storage limits. It was (and is) a conscious decision to encourage the open exchange of half-baked ideas, without having them haunt their author ad nauseum. If they were to persist, the thought goes, they'd only be published in near-final form. The goal of the IDs is to encourage the evolution of ideas, which happens before that. Joe From moors at ieee.org Wed Nov 28 07:43:43 2001 From: moors at ieee.org (Tim Moors) Date: Wed, 28 Nov 2001 10:43:43 -0500 Subject: [ih] "Those who don't understand * [will] reinvent it" Message-ID: Does anybody know the source of the quote "Those who don't understand {TCP, UNIX} are {condemned, doomed} to reinvent it"? I have seen various attributions to Van Jacobson and James Van Bokkelen for the TCP variant, and Henry Spencer for the UNIX variant. Can anybody provide dates or sources? Thanks. Tim Moors ___________________________________ Web: http://uluru.poly.edu/~tmoors/ From craig at aland.bbn.com Wed Nov 28 08:13:58 2001 From: craig at aland.bbn.com (Craig Partridge) Date: Wed, 28 Nov 2001 11:13:58 -0500 Subject: [ih] "Those who don't understand * [will] reinvent it" In-Reply-To: Your message of "Wed, 28 Nov 2001 10:43:43 EST." Message-ID: <200111281613.fASGDwt53755@aland.bbn.com> The widely attributed quote for Spencer appears to be: Those who do not understand Unix are condemned to reinvent it, poorly. I cannot find a similar quote for TCP, either by searching Google (which turns up lots of Spencer UNIX quotes), or by searching my archives of the End-to-End, IETF-Hosts, or TCP-IP. All but the TCP-IP archive are close to complete. The closest I can find is a statement by Mike Padlipsky to the effect that the OSI protocols were "reinvented" ARPA protocols (TCP-IP note send 15 April 1989). Craig From the.map at alum.mit.edu Wed Nov 28 15:29:33 2001 From: the.map at alum.mit.edu (Mike Padlipsky) Date: Wed, 28 Nov 2001 15:29:33 -0800 Subject: [ih] "Those who don't understand * [will] reinvent it" In-Reply-To: <200111281613.fASGDwt53755@aland.bbn.com> References: Message-ID: <5.0.2.1.1.20011128145555.020629b0@mail.lafn.org> At 08:13 AM 11/28/01, you wrote: > The closest I can find is a statement by Mike Padlipsky to the effect >that the OSI protocols were "reinvented" ARPA protocols (TCP-IP note send >15 April 1989). nice to be remembered. amusingly enough, tho, the closest i can find is in the very next msg in my 'in-box', where lloyd wood cites the santayana line that i'm confident the questioned lines are allusions to ... and was already confident of that explanation when i read the initial msg, i might add. [he apparently cites it more accurately than i'd remembered it, i might also add: i 'always' thought it was merely 'those who ignore history are condemned to repeat it', somehow -- probably because that's how it's commonly misquoted by those who like to [mis]quote santayana, come to think of it. not that i feel up to doublechecking in/on 'bartleby', of c., being retired, after all, and never all that scholarly to begin w/. residual intellectual curiosity did prompt me to look in my elderly p-_odq_ a few mins. ago, but when it wasn't there i figured i'd put in enough effort on the intellectual curiosity front for one day.] what's left of my memory serves a fault on the particular line of mine you mention, b/t/w, but i'm certain that whenever i used reinvention in connection w/ isorm-based protocols i had reinventing the wheel -- and/or the travois; cf. p. 222 of The Book -- in mind rather than a play on santayana, whom i only ever talked about in connection w/ one of my favorite teaching stories from my pre-computer days, wh/ clearly isn't even remotely relevant to '[ih]'.... cheers, map [whose shoulder problems caused him to break down some time ago and create a 'signature' file to apologize for the lack of his formerly customary e-volubility -- and who's been employing shiftless typing for a long time now to spare his wristsnfingers, in case you didn't know ... and who's further broken down and done http://www.lafn.org/~ba213/mapstuff.html , rather grudgingly] From christos at ISI.EDU Thu Nov 29 16:21:32 2001 From: christos at ISI.EDU (Christos Papadopoulos) Date: Thu, 29 Nov 2001 16:21:32 -0800 (PST) Subject: [ih] TCP options: Bubba and Skeeter Message-ID: <200111300021.fAU0LW508101@boreas.isi.edu> Hi everyone, one of my students stumbled accross this one. Look at option kind numbers 16 and 17 below. Anyone knows the history behind it? Christos Papadopoulos Assistant Professor Department of Computer Science Voice: (213) 740-4780 University of Southern California FAX: (213) 740-7285 941 W. 37th Place email: christos at isi.edu SAL 238 Los Angeles, CA 90089-0781 ----- Forwarded message from Gina Fisk ----- Options 16 and 17: http://www.iana.org/assignments/tcp-parameters TCP OPTION NUMBERS The Transmission Control Protocol (TCP) has provision for optional header fields identified by an option kind field. Options 0 and 1 are exactly one octet which is their kind field. All other options have their one octet kind field, followed by a one octet length field, followed by length-2 octets of option data. Kind Length Meaning Reference ---- ------ ------------------------------- --------- 0 - End of Option List [RFC793] 1 - No-Operation [RFC793] 2 4 Maximum Segment Size [RFC793] 3 3 WSOPT - Window Scale [RFC1323] 4 2 SACK Permitted [RFC2018] 5 N SACK [RFC2018] 6 6 Echo (obsoleted by option 8) [RFC1072] 7 6 Echo Reply (obsoleted by option 8)[RFC1072] 8 10 TSOPT - Time Stamp Option [RFC1323] 9 2 Partial Order Connection Permitted[RFC1693] 10 3 Partial Order Service Profile [RFC1693] 11 CC [RFC1644] 12 CC.NEW [RFC1644] 13 CC.ECHO [RFC1644] 14 3 TCP Alternate Checksum Request [RFC1146] 15 N TCP Alternate Checksum Data [RFC1146] 16 Skeeter [Knowles] 17 Bubba [Knowles] 18 3 Trailer Checksum Option [Subbu & Monroe] 19 18 MD5 Signature Option [RFC2385] 20 SCPS Capabilities [Scott] 21 Selective Negative Acknowledgements [Scott] 22 Record Boundaries [Scott] 23 Corruption experienced [Scott] 24 SNAP [Sukonnik] 25 Unassigned (released 12/18/00) 26 TCP Compression Filter [Bellovin] ----- End of forwarded message from Gina Fisk ----- From craig at aland.bbn.com Fri Nov 30 05:59:45 2001 From: craig at aland.bbn.com (Craig Partridge) Date: Fri, 30 Nov 2001 08:59:45 -0500 Subject: [ih] TCP options: Bubba and Skeeter In-Reply-To: Your message of "Thu, 29 Nov 2001 16:21:32 PST." <200111300021.fAU0LW508101@boreas.isi.edu> Message-ID: <200111301359.fAUDxjt61649@aland.bbn.com> In message <200111300021.fAU0LW508101 at boreas.isi.edu>, Christos Papadopoulos wr ites: >Hi everyone, > >one of my students stumbled accross this one. Look at option >kind numbers 16 and 17 below. Anyone knows the history behind it? Knowles is certainly Stev Knowles -- haven't reached him but found a co-conspirator. Attached note sent with permission. Craig From: "Kastenholz, Frank" Subject: Re: skeeter & bubba TCP options? ah, the sins of ones youth that never seem to be lost... it was something that ben levy and stev and i did at ftp many many moons ago. bridgham and stev were the instigators of it. the idea was simple, put a dh key exchange directly in tcp so that all tcp sessions could be encrypted without requiring any significant key management system. authentication was not a part of the idea, it was to be provided by passwords or whatever, which could now be transmitted over the internet with impunity since they were encrypted... we implemented a simple form of this (doing the math was non trivial on the machines of the day). it worked. the only failure that i remember was that it was vulnerable to man-in-the-middle attacks. why "skeeter" and "bubba"? well, that's known only to stev... f