[VOIP] Security

From owner-ietf-outbound Thu Feb 1 01:40:30 2001 Received: by ietf.org (8.9.1a/8.9.1a) id BAA11405 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 01:40:04 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10865; Thu, 1 Feb 2001 01:35:53 -0500 (EST) Received: from isi.edu (ras34.isi.edu [128.9.176.134]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id WAA19501; Wed, 31 Jan 2001 22:29:13 -0800 (PST) Message-ID: <3A7901DF.441EB775@isi.edu> Date: Wed, 31 Jan 2001 22:27:43 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ed Gerck CC: Keith Moore , "J. Noel Chiappa" , midcom@ietf.org, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Ed Gerck wrote: > > Keith Moore wrote: > > > I expressed an opinion that this group should confine itself to addressing > > short-term goals rather than trying to make NATs a part of the Internet > > architecture. > > NATs are already part of the Internet, and gaining share. An alternate perspective is that the Internet continues to (mostly) work despite the presence of NATs. It is a paradox to begin one standard by selectively omitting current standards (e.g., RFC1122). Joe From owner-ietf-outbound Thu Feb 1 02:30:21 2001 Received: by ietf.org (8.9.1a/8.9.1a) id CAA21140 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 02:30:03 -0500 (EST) Received: from mailhub.doruk.net.tr ([212.58.5.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21113 for ; Thu, 1 Feb 2001 02:29:40 -0500 (EST) Received: from smtp.doruk.net.tr (smtp.doruk.net.tr [212.58.4.4]) by mailhub.doruk.net.tr (8.11.0/8.11.0) with ESMTP id f117Scq16393 for ; Thu, 1 Feb 2001 09:28:38 +0200 Received: from mail.viranova.com.tr ([212.2.223.18]) by smtp.doruk.net.tr (8.8.8/SCO5) with ESMTP id JAA17366 for ; Thu, 1 Feb 2001 09:32:59 +0200 (TSI) Received: by MAIL with Internet Mail Service (5.5.2650.21) id <1C2944J6>; Thu, 1 Feb 2001 09:14:46 +0200 Message-ID: <00E441D03D24D411913C00D0B71C506417758A@MAIL> From: =?ISO-8859-9?Q?B=2E_Elzem_=D6zg=FCrce?= To: ietf@ietf.org Subject: [VOIP] Security Date: Thu, 1 Feb 2001 09:14:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C1E.A7FFE020" X-Loop: ietf@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08C1E.A7FFE020 Content-Type: text/plain; charset="ISO-8859-9" Running voice services with IP technology raises several thorny security issues. Authentication can be problematic. Service providers may not maintain the detailed call records that are traditional in voice communications. Confidentiality may be at risk. Packet encryption may present obstacles to desirable law enforcement objectives, such as those provided by court-approved wiretapping. This session will compare the security issues inherent in packetized voice with those that arise in the existing PSTN and offer potential solutions to these problems. http://www.cmpevents.com/ctx/d.asp?option=Net ------_=_NextPart_001_01C08C1E.A7FFE020 Content-Type: text/html; charset="ISO-8859-9" Content-Transfer-Encoding: quoted-printable [VOIP] Security

Running voice services with IP technology raises = several thorny security issues. Authentication can be problematic. = Service providers may not maintain the detailed call records that are = traditional in voice communications. Confidentiality may be at risk. = Packet encryption may present obstacles to desirable law enforcement = objectives, such as those provided by court-approved = wiretapping.

This session will compare the security issues = inherent in packetized voice with those that arise in the existing PSTN = and offer potential solutions to these problems.

http://www.cmpevents.com/ctx/d.asp?option=3DNet

------_=_NextPart_001_01C08C1E.A7FFE020-- From owner-ietf-outbound Thu Feb 1 03:00:20 2001 Received: by ietf.org (8.9.1a/8.9.1a) id DAA21479 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 03:00:03 -0500 (EST) Received: from web10004.mail.yahoo.com (web10004.mail.yahoo.com [216.136.130.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21425 for ; Thu, 1 Feb 2001 02:56:28 -0500 (EST) Message-ID: <20010201075629.20099.qmail@web10004.mail.yahoo.com> Received: from [216.6.88.34] by web10004.mail.yahoo.com; Wed, 31 Jan 2001 23:56:29 PST Date: Wed, 31 Jan 2001 23:56:29 -0800 (PST) From: Anshul Jain Subject: First bit of IP Addresses To: ietf@ietf.org Cc: Anshul Jain In-Reply-To: <3A7901DF.441EB775@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Hi, I am not clear in basics of ip address format, why we are not using the first bit as 0 to define new class of addresses, may this double the available IPs, Regards, __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-ietf-outbound Thu Feb 1 03:10:19 2001 Received: by ietf.org (8.9.1a/8.9.1a) id DAA21675 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 03:10:03 -0500 (EST) Received: from web10004.mail.yahoo.com (web10004.mail.yahoo.com [216.136.130.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21432 for ; Thu, 1 Feb 2001 02:57:06 -0500 (EST) Message-ID: <20010201075707.20129.qmail@web10004.mail.yahoo.com> Received: from [216.6.88.34] by web10004.mail.yahoo.com; Wed, 31 Jan 2001 23:57:07 PST Date: Wed, 31 Jan 2001 23:57:07 -0800 (PST) From: Anshul Jain Subject: First bit of IP Addresses To: ietf@ietf.org Cc: Anshul Jain MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Hi, I am not clear in basics of ip address format, why we are not using the first bit as 0 to define new class of addresses, may this double the available IPs, Regards, __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-ietf-outbound Thu Feb 1 04:51:01 2001 Received: by ietf.org (8.9.1a/8.9.1a) id EAA22471 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 04:50:03 -0500 (EST) Received: from aegir.EU.net (aegir.EU.net [193.242.90.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22428 for ; Thu, 1 Feb 2001 04:43:37 -0500 (EST) Received: from aegir.EU.net (localhost.eu.net [127.0.0.1]) by aegir.EU.net (8.9.3/8.9.3) with ESMTP id KAA08024; Thu, 1 Feb 2001 10:43:32 +0100 (MET) Message-Id: <200102010943.KAA08024@aegir.EU.net> To: Anshul Jain cc: ietf@ietf.org Subject: Re: First bit of IP Addresses In-reply-to: Your message of "Wed, 31 Jan 2001 23:57:07 PST." <20010201075707.20129.qmail@web10004.mail.yahoo.com> From: James Aldridge Date: Thu, 01 Feb 2001 10:43:32 +0100 Sender: jhma@KPNQwest.net X-Loop: ietf@ietf.org Anshul Jain wrote: > I am not clear in basics of ip address format, why we are not using the > first bit as 0 to define new class of addresses, may this double the > available IPs, Hmmm... and why not call this new class of addresses "Class A"? In the classful world: bit 1 = 0 -> Class A bits 1,2 = 10 -> Class B bits 1,2,3 = 110 -> Class C bits 1,2,3,4 = 1110 -> Class D (Multicast) etc. James From owner-ietf-outbound Thu Feb 1 07:40:40 2001 Received: by ietf.org (8.9.1a/8.9.1a) id HAA24963 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 07:40:03 -0500 (EST) Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24579 for ; Thu, 1 Feb 2001 07:29:42 -0500 (EST) Received: from caplin.cs.ui.ac.id (caplin.cs.ui.ac.id [152.118.36.9]) by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA32430; Thu, 1 Feb 2001 19:50:35 +0700 Received: from rmsbase.vlsm.org (IDENT:root@rmsbase.acad.cs.ui.ac.id [152.118.26.15]) by caplin.cs.ui.ac.id (8.9.3/8.9.3) with ESMTP id TAA00250; Thu, 1 Feb 2001 19:34:34 +0700 (JAVT) Received: from vlsm.org (IDENT:rms46@rmsbase.vlsm.org [152.118.26.15]) by rmsbase.vlsm.org (8.9.3/8.8.7) with ESMTP id TAA01376; Thu, 1 Feb 2001 19:30:49 +0700 Sender: rms46@VLSM.ORG Message-ID: <3A7956F7.1761708C@vlsm.org> Date: Thu, 01 Feb 2001 19:30:47 +0700 From: "Rahmat M. Samik-Ibrahim" Organization: VLSM-TJT X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org CC: dick@eGroups.com Subject: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Joe Touch wrote: > It is a paradox to begin one standard by selectively omitting > current standards (e.g., RFC1122). I believe that that is called "making progress". Cited from section 4.20 of RFC-1336: "I think three factors contribute to the success of the Internet: 1) public documentation of the protocols, 2) free (or cheap) software for the popular machines, and 3) vendor independence." Thus, it is not "end-to-end-purity" or because the existence of any organization. Speaking of keeping standards, I am wondering why STD-2 is still RFC-1700, although the current version is kept by IANA at http://www.iana.org/numbers.htm . regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Good bye hegemony - http://sapi.vlsm.org/DLL/linuxrouter From owner-ietf-outbound Thu Feb 1 07:50:11 2001 Received: by ietf.org (8.9.1a/8.9.1a) id HAA25390 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 07:50:03 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24630 for ; Thu, 1 Feb 2001 07:30:43 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id EAA05578; Thu, 1 Feb 2001 04:30:27 -0800 (PST) Date: Thu, 1 Feb 2001 04:30:27 -0800 (PST) From: "James P. Salsman" Message-Id: <200102011230.EAA05578@shell9.ba.best.com> To: mcr@research.solidum.com Subject: NATs and peer-to-peer (was Re: [midcom]...) Cc: ietf@ietf.org, lgl@qualcomm.com X-Loop: ietf@ietf.org > It was ... peer-to-peer things that made the Internet popular. Yes. Before there was the web (back in the days of HOSTS.TXT and ftp clients on so few platforms that one's best efforts to convert carriage returns were often foiled), email-based file servers were popular, and they still are. Asyncronous messaging of files is why Internet messages, which support sevral methods of in-line file transfer, are dominant and will continue to be. > Based upon some data on "web ready cell phones" being used primarily > to send text messages .... The advantage of such messaging is not that it is text, but that it is asyncronous. Anyone who is interested in obtaining asyncronous audio file messaging on cellular telephones might ask Laurence Lundblade at Qualcomm -- mailto:lgl@qualcomm.com -- about which models of the QCP phone line will be capable of supporting it, etc. The last I heard there was some question as to whether the manufactuer would include a routine for data transfer from the voice memo buffer to the seperate CPU address space used for the PalmOS Eudora program. Qualcomm's highest-level management have advocated this for years, it turns out (and I have it on good authority that is why there is a vocodec built in to Eudora); I wonder if they realize that those goals are again being thwarted by some overseas programmer goofing off instead of writing code for an already-existing API. Cheers, James From owner-ietf-outbound Thu Feb 1 09:51:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id JAA28385 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 09:50:02 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28196 for ; Thu, 1 Feb 2001 09:42:11 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f11EfkUB073090; Thu, 1 Feb 2001 09:41:51 -0500 Message-Id: <200102011441.f11EfkUB073090@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: smd@ebone.net (Sean Doran) Cc: ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-Reply-To: Your message of "Thu, 01 Feb 2001 05:34:31 +0100." <20010201043431.18E6F8A3@sean.ebone.net> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-422550230P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 01 Feb 2001 09:41:45 -0500 X-Loop: ietf@ietf.org --==_Exmh_-422550230P Content-Type: text/plain; charset=us-ascii On Thu, 01 Feb 2001 05:34:31 +0100, Sean Doran said: > "Hm, now let's see, a router on the 'outside' just sent back this > odd ICMP message. Whatever should I do with it?" may not be so Given the unauthenticated nature of ICMP, this should give you pause. I *already* get *enough* headaches with routers and NATs and trying to do PMTU Discovery throught them. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-422550230P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOnl1qXAt5Vm009ewEQLRBACeLxZrlRakgkYpciNAa87qOlcQBqwAnjnI f1sMdbe0C9LDpkyz5jRhBmyt =vxhN -----END PGP SIGNATURE----- --==_Exmh_-422550230P-- From owner-ietf-outbound Thu Feb 1 10:00:12 2001 Received: by ietf.org (8.9.1a/8.9.1a) id KAA28616 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 10:00:02 -0500 (EST) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28260 for ; Thu, 1 Feb 2001 09:44:26 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.12.0.Beta1/8.12.0.Beta1) with ESMTP id f11EiHUB050040; Thu, 1 Feb 2001 09:44:17 -0500 Message-Id: <200102011444.f11EiHUB050040@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: James Aldridge Cc: Anshul Jain , ietf@ietf.org Subject: Re: First bit of IP Addresses In-Reply-To: Your message of "Thu, 01 Feb 2001 10:43:32 +0100." <200102010943.KAA08024@aegir.EU.net> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-401379168P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 01 Feb 2001 09:44:17 -0500 X-Loop: ietf@ietf.org --==_Exmh_-401379168P Content-Type: text/plain; charset=us-ascii On Thu, 01 Feb 2001 10:43:32 +0100, James Aldridge said: > In the classful world: > bit 1 = 0 -> Class A > bits 1,2 = 10 -> Class B > bits 1,2,3 = 110 -> Class C > bits 1,2,3,4 = 1110 -> Class D (Multicast) > etc. Note that since the creation of CIDR, class A/B/C has been essentially deprecated in favor of address/mask pairs. In fact, so much so that in today's net, stuff that still insists on class A/B/C distictions is considered "broken". -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-401379168P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOnl2QHAt5Vm009ewEQKWDQCgpqkZj6rsOpJZggFhjNzVOvH8bFMAn0aY M2KJ9ivtFOY/jHcy31aHsp7/ =Zc+H -----END PGP SIGNATURE----- --==_Exmh_-401379168P-- From owner-ietf-outbound Thu Feb 1 11:00:26 2001 Received: by ietf.org (8.9.1a/8.9.1a) id LAA29802 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 11:00:03 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29689 for ; Thu, 1 Feb 2001 10:52:46 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14OM1l-00045y-00; Thu, 01 Feb 2001 15:52:05 +0000 Date: Thu, 1 Feb 2001 15:52:05 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Valdis.Kletnieks@vt.edu cc: Sean Doran , ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-Reply-To: <200102011441.f11EfkUB073090@black-ice.cc.vt.edu> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 1 Feb 2001 Valdis.Kletnieks@vt.edu wrote: > On Thu, 01 Feb 2001 05:34:31 +0100, Sean Doran said: > > "Hm, now let's see, a router on the 'outside' just sent back this > > odd ICMP message. Whatever should I do with it?" may not be so > > Given the unauthenticated nature of ICMP, this should give you pause. if supplying the IP header and first 64 bytes of the packet that was sent to it isn't authentication, I don't know what is. L. PGP From owner-ietf-outbound Thu Feb 1 11:10:20 2001 Received: by ietf.org (8.9.1a/8.9.1a) id LAA00081 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 11:10:03 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29818; Thu, 1 Feb 2001 11:00:35 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14OM2g-00046P-00; Thu, 01 Feb 2001 15:53:02 +0000 Date: Thu, 1 Feb 2001 15:53:01 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Ed Gerck cc: midcom@ietf.org, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-Reply-To: <3A789A3E.63620B61@nma.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Wed, 31 Jan 2001, Ed Gerck wrote: > You miss at least one other possibility. If it is possible to develop > an addressing scheme that works in a heterogeneous network, then > we can have point-to-point functionality across system borders and > do not require a homogeneous address space to do so. Now, if you > look into the science of Thermodynamics (for example) you will see that > this involves a meta-problem that was already solved two centuries ago. Explain. > NATs are a consequence of a choice rather than makers of a choice. > The choice is to use heterogeneous networks. NATs fake a homogeneous address space for disjoint/overlapping *homogeneous networks*. You just layer IP over the top of the heterogeneous networks - so we already have that addressing scheme you want. NATs are primarily a consequence of heterogeneous administration with short-term local-optimisation goals that dictate use of homogeneous network technology. (Address space shortages are also a result of heterogeneous administration of a homogeneous and limited resource. As are most things.) Considered use of truly heterogeneous networks does not offer the local optimisation NATs do (more translation, gateway maintenance), and is rejected. > I contend that the reasons for this choice can be found in Nature well, yes. everything can be found in nature. > -- for example, to adapt to local needs > without imposing more expensive non-local changes. This is not an Internet > phenomenon, it is IMO the reflection of a more general principle. Oh, right. Since we're waffling; http://pespmc1.vub.ac.be/SUBOPTIM.html and Gleick's 'Faster' (and Vinge's 'Deepness in the Sky', for that matter) make some interesting statements and predictions about the system-wide dangers of local optimisations. The zeroth law of thermodynamics does not, IMO; entropy analogies can be highly misleading. It's useful to reflect on why we should be designing protocols with a lot of overhead, redundancy, and slack in them. Contrast the success, adaptability, longevity and utility of the ever-so-slack http with that of the bit-efficient gopher. The lack of slack in the ATM header. Or the slack in the GSM control channel that led almost by accident to SMS. If there's no slack, there's no serendipity, no escaping the local minimum by subverting it. That doesn't have much to do with anything other than the work required to handle the protocol reliably in NAT, though. L. IETF: optimising everything into a dead-end local minimum since 1986. PGP From owner-ietf-outbound Thu Feb 1 12:10:21 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA03400 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 12:10:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03313; Thu, 1 Feb 2001 12:07:41 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14ONCu-0004vU-00; Thu, 01 Feb 2001 17:07:40 +0000 Date: Thu, 1 Feb 2001 17:07:39 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: ietf@ietf.org cc: midcom-admin@ietf.org, poised@lists.tislabs.com Subject: Mail sent to midcom (fwd) Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org IETF mailing lists are intended for OPEN discussion; the benefits (cross-pollination between lists, lack of inhibition about stating your opinions) are widely recognised as outweighing widely-accepted drawbacks (e.g. Peter Lewis advertising every forum everywhere he can think of, allisat going on yet another hallucinogen-induced trip down memory lane). midcom is not open. midcom should not be part of the IETF, much less a working group. No, I don't care that having a moderator-in-the-middle filtering everything is in the spirit of the midcom charter and must be for my own good. I _really_ don't like the concept of an IETF-approved poster to a mailing list on an IETF-run server. We can do our own filtering, if we choose to, and we don't need the IETF to do it for us. Moderator approval of individual posters is outside the spirit of RFC2418, and would require AD and IESG approval. What are we coming to? L. PGP ---------- Forwarded message ---------- Date: Thu, 1 Feb 2001 11:00:40 -0500 (EST) From: midcom-admin@ietf.org To: l.wood@eim.surrey.ac.uk Subject: Mail sent to midcom Your mail to 'midcom' with the subject: Re: [midcom] WG scope/deliverables Is being held until the list moderator can review it for approval. The reason it is being held: Only approved posters may post without moderator approval. Either the message will get posted to the list, or you will receive notification of the moderator's decision. From owner-ietf-outbound Thu Feb 1 12:41:06 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA04056 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 12:40:04 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03852 for ; Thu, 1 Feb 2001 12:30:03 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA18660; Thu, 1 Feb 2001 09:29:29 -0800 Received: from hursley.ibm.com ([9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20724; Thu, 1 Feb 2001 09:29:34 -0800 Message-ID: <3A799C3E.A10E3F8F@hursley.ibm.com> Date: Thu, 01 Feb 2001 11:26:22 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ed Gerck CC: ietf@ietf.org Subject: head hurting [was Re: [midcom] WG scope/deliverables References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Well, I don't think this is about midcom any more but something here made my head hurt... Ed Gerck wrote: ... > You miss at least one other possibility. If it is possible to develop > an addressing scheme that works in a heterogeneous network, then > we can have point-to-point functionality across system borders er, that is what the Internet concept was invented for by Pouzin, Cerf and Kahn in the early 1970's. The references are in RFC 1958. That addressing scheme is called IP; the problem is that 32 bits are no longer enough. > .....and > do not require a homogeneous address space to do so. at some level you must have an unambiguous namespace. If 10.1.1.1 is used in two different places there must be a way of distinguishing them. Unfortunately, today we do this without the benefit of an explicit namespace - the distinction is implicit in the instantaneous state of NAT automata, i.e. the internal state of all NATs is an extension to the IPv4 address space. Thus when 10.1.1.1 is behind a NAT that has loaned it address 9.1.1.1, its implicit address is 9.1.1.1+10.1.1.1. That's an unambiguous address space; it's just implicit. (NAPT, multiple NAT or NAT-PT make it a bit more complex, but don't change what I'm saying in principle - the implicit address just gets longer.) A rendez-vous service for NATted peers would have to construct an identifier explicitly, and it might as well be this implicit one. Brian From owner-ietf-outbound Thu Feb 1 12:50:09 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA04394 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 12:50:03 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03894; Thu, 1 Feb 2001 12:31:21 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA05383; Thu, 1 Feb 2001 09:30:34 -0800 (PST) Received: from spandex (rtp-vpn-78.cisco.com [10.82.192.78]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AEC15283; Thu, 1 Feb 2001 09:30:18 -0800 (PST) Message-ID: <041a01c08c74$d800cd00$d45904d1@cisco.com> From: "Melinda Shore" To: , Cc: , References: Subject: Re: Mail sent to midcom (fwd) Date: Thu, 1 Feb 2001 12:31:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > No, I don't care that having a moderator-in-the-middle filtering > everything is in the spirit of the midcom charter and must be for my > own good. I _really_ don't like the concept of an IETF-approved > poster to a mailing list on an IETF-run server. Given how trivially easy it is to subscribe to midcom and other IETF mailing lists I'm not sure that it's appropriate to describe the filtering process as anything but completely loose. I'm also not certain that I see the value in having people who don't read a mailing list posting to it, but okay, whatever. Complain about Allisat if you will, but at least he was subscribed to the mailing lists to which he was posting (Peter Lewis and the folks at Upperside are just spammers). The mailing list as delivered unto us by the IETF administrator has a preset policy of holding email from someone not on the mailing list until it's released by an administrator. We can change that if people feel sufficiently strongly. Melinda From owner-ietf-outbound Thu Feb 1 13:10:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA05036 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 13:10:02 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04777 for ; Thu, 1 Feb 2001 13:01:40 -0500 (EST) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA17765; Thu, 1 Feb 2001 10:01:35 -0800 (PST) Message-ID: <3A79A400.74B9E7E3@isi.edu> Date: Thu, 01 Feb 2001 09:59:28 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Rahmat M. Samik-Ibrahim" CC: ietf@ietf.org, dick@eGroups.com Subject: Re: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> <3A7956F7.1761708C@vlsm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Rahmat M. Samik-Ibrahim" wrote: > > Joe Touch wrote: > > > It is a paradox to begin one standard by selectively omitting > > current standards (e.g., RFC1122). > > I believe that that is called "making progress". Cited > from section 4.20 of RFC-1336: > "I think three factors contribute to the success of the > Internet: > 1) public documentation of the protocols, > 2) free (or cheap) software for the popular machines, and > 3) vendor independence." The unstated assumption of #1 is that there are protocols, that they are designed carefully and conservatively to result in a stable specification to code to. Certainly protocols evolve and even are replaced. It's more productive to replace a standard than ignore it, though. > Thus, it is not "end-to-end-purity" or because the existence > of any organization. I asserted neither per se. > Speaking of keeping standards, I am wondering why STD-2 > is still RFC-1700, although the current version is kept by > IANA at http://www.iana.org/numbers.htm . Very good question. I'll be glad to raise the issue with IANA; at least 1700 and STD-2 should be obsoleted in their current form. Joe From owner-ietf-outbound Thu Feb 1 13:20:13 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA05473 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 13:20:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05062; Thu, 1 Feb 2001 13:10:49 -0500 (EST) Received: from DC-DESK.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA16913; Thu, 1 Feb 2001 10:08:41 -0800 Message-Id: <5.0.2.1.2.20010201100341.02c775d8@dcrocker.songbird.com> X-Sender: dhc2@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 01 Feb 2001 10:05:39 -0800 To: Ed Gerck From: Dave Crocker Subject: Re: [midcom] WG scope/deliverables Cc: Keith Moore , "J. Noel Chiappa" , midcom@ietf.org, ietf@ietf.org In-Reply-To: <3A789A3E.63620B61@nma.com> References: <200101312118.QAA15700@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: >You miss at least one other possibility. If it is possible to develop >an addressing scheme that works in a heterogeneous network, then >we can have point-to-point functionality across system borders and >do not require a homogeneous address space to do so. There is roughly 30 years of experience in this realm that suggests otherwise. The difference between theory and practise is practise. If you wish to formulate a detailed technical specification, and subject it to community review and testing, perhaps you will indeed show show us an approach that will work. Until then, your suggestion is just an untested theory. d/ From owner-ietf-outbound Thu Feb 1 13:30:11 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA05976 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 13:30:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05277; Thu, 1 Feb 2001 13:15:51 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14OOGW-0005WY-00; Thu, 01 Feb 2001 18:15:28 +0000 Date: Thu, 1 Feb 2001 18:15:28 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Melinda Shore cc: ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) In-Reply-To: <041a01c08c74$d800cd00$d45904d1@cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 1 Feb 2001, Melinda Shore wrote: > The mailing list as delivered unto us by the IETF administrator > has a preset policy of holding email from someone not on the > mailing list until it's released by an administrator. That is not what the message said. People posting from multiple or changing addresses are presumably inconvenienced, since you're checking the email address, not the person. So, two specific complaints: 1. unclear message, privately described to me as 'kind of offensive'. (you could fire subscription information and a copy of the list charter with pointers to workgroup drafts etc. at new email addresses not previously seen along with an if-you've-seen-this-sorry preface, however. That would be useful and inclusive.) 2. morally wrong, contrary to the open inclusive spirit of the IETF and just plain risky to be holding *any* email for a discussion list for moderator approval in the first place. RFC2418, chapter and verse. It's a starting step down a slippery slope. We don't want to go there. L. is apparently 'approved' by quite a number of IETF mailing lists. > We can change that if people feel sufficiently strongly. > > Melinda PGP From owner-ietf-outbound Thu Feb 1 13:40:17 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA06543 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 13:40:02 -0500 (EST) Received: from postal.redback.com (hiddenuser@prattle.redback.com [155.53.12.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05406; Thu, 1 Feb 2001 13:18:15 -0500 (EST) Received: from red.redback.com (red.redback.com [155.53.42.56]) by postal.redback.com (Postfix) with ESMTP id 0F1FCB76784; Thu, 1 Feb 2001 10:18:15 -0800 (PST) Received: from red.redback.com by red.redback.com (8.9.3) id KAA55749; Thu, 1 Feb 2001 10:18:06 -0800 (PST) Message-Id: <200102011818.KAA55749@red.redback.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: L.Wood@eim.surrey.ac.uk Cc: Ed Gerck , midcom@ietf.org, ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Thu, 01 Feb 2001 15:53:01 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2001 10:18:06 -0800 From: Greg Minshall X-Loop: ietf@ietf.org from some of the discussion, esp. yesterday, i had thoughts of deriving an anti-NAT polemic and posting it. i planned on mentioning all of the other brain-dead, obsolete technologies "we" (IP) had in the past ignored, and how we had triumphed while they had died off. i was thinking of things like IBM mainframes, BSC, SDLC, and ultimately got around to thinking of things "in our community" such as UUCP over asynch (mostly) phone lines, etc. but as i thought of it, i realized that what "we" successfully ignored in the past were things that had little use (the ISO acronym popped up in my mind). things that were heavily used, we somehow brought into the fold and, in some sense, stepped on their shoulders on our way to "the world of greater connectivity". the examples are numerous, and happened in different ways. "we" invented ways of interconnecting (at least at the level of e-mail, the killer app of the 80s) with IBM mainframes, VMS boxes, etc. we ran IP over BSC and SDLC. we invented MX records, as well as bizarre addressing formats (!%.etc.), to interconnect between the SMTP world and the UUCP world. i guess if i think anything about all that, it is that if NATs are ubiquitous, we should figure out how to deal with them. and, that (hopefully), we will achieve the "greater interconnectivity" on top of, and to some extent in spite of NATs. cheers, Greg Minshall From owner-ietf-outbound Thu Feb 1 14:00:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA07662 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 14:00:02 -0500 (EST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07305; Thu, 1 Feb 2001 13:52:56 -0500 (EST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 01 Feb 2001 11:52:12 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 01 Feb 2001 11:52:03 -0700 From: "Hilarie Orman" To: , Cc: , , , Subject: Re: [midcom] WG scope/deliverables Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07305 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit Dave Cheriton's TRIAD is an example of such a proposal. Hilarie >>> Dave Crocker 02/01/01 11:05AM >>> At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: >You miss at least one other possibility. If it is possible to develop >an addressing scheme that works in a heterogeneous network, then >we can have point-to-point functionality across system borders and >do not require a homogeneous address space to do so. There is roughly 30 years of experience in this realm that suggests otherwise. The difference between theory and practise is practise. If you wish to formulate a detailed technical specification, and subject it to community review and testing, perhaps you will indeed show show us an approach that will work. Until then, your suggestion is just an untested theory. d/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From owner-ietf-outbound Thu Feb 1 14:10:07 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA08226 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 14:10:02 -0500 (EST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07774 for ; Thu, 1 Feb 2001 14:02:11 -0500 (EST) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA23252; Thu, 1 Feb 2001 11:01:34 -0800 Received: from hursley.ibm.com ([9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA20508; Thu, 1 Feb 2001 11:01:40 -0800 Message-ID: <3A79B1C2.B20E36DB@hursley.ibm.com> Date: Thu, 01 Feb 2001 12:58:10 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Joe Touch CC: ietf@ietf.org Subject: Re: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> <3A7956F7.1761708C@vlsm.org> <3A79A400.74B9E7E3@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Joe Touch wrote: ... > > Speaking of keeping standards, I am wondering why STD-2 > > is still RFC-1700, although the current version is kept by > > IANA at http://www.iana.org/numbers.htm . > > Very good question. I'll be glad to raise the issue with IANA; > at least 1700 and STD-2 should be obsoleted in their current form. afaik nothing in 1700 has been rescinded, so it isn't obsolete; it's simply updated by http://www.iana.org/numbers.htm IANA can't change the status of an STD - that's an IESG action. If you think this matters, I would raise it with the latter. Brian From owner-ietf-outbound Thu Feb 1 14:30:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA09296 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 14:30:03 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08154 for ; Thu, 1 Feb 2001 14:08:03 -0500 (EST) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA27289; Thu, 1 Feb 2001 11:08:00 -0800 (PST) Message-ID: <3A79B38F.CE3A4E32@isi.edu> Date: Thu, 01 Feb 2001 11:05:51 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Brian E Carpenter CC: ietf@ietf.org Subject: Re: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> <3A7956F7.1761708C@vlsm.org> <3A79A400.74B9E7E3@isi.edu> <3A79B1C2.B20E36DB@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > Joe Touch wrote: > ... > > > Speaking of keeping standards, I am wondering why STD-2 > > > is still RFC-1700, although the current version is kept by > > > IANA at http://www.iana.org/numbers.htm . > > > > Very good question. I'll be glad to raise the issue with IANA; > > at least 1700 and STD-2 should be obsoleted in their current form. > > afaik nothing in 1700 has been rescinded, so it isn't obsolete; > it's simply updated by http://www.iana.org/numbers.htm I was using the term 'obsolete' as in 'obsoleted by', as used in other standards that have been updated by subsequent RFCs. > IANA can't change the status of an STD - that's an IESG action. > If you think this matters, I would raise it with the latter. Agreed. I was expecting that IANA would initiate taking the action with the IESG, not that they would supercede it. Joe From owner-ietf-outbound Thu Feb 1 14:40:08 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA09640 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 14:40:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08262 for ; Thu, 1 Feb 2001 14:10:30 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA25096; Thu, 1 Feb 2001 14:10:29 -0500 (EST) Message-Id: <200102011910.OAA25096@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Greg Minshall cc: ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Thu, 01 Feb 2001 10:18:06 PST." <200102011818.KAA55749@red.redback.com> Date: Thu, 01 Feb 2001 14:10:29 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org [recipient list trimmed] > i guess if i think anything about all that, it is that if NATs are ubiquitous, > we should figure out how to deal with them. perhaps. but I note that for many of the examples you quoted, "dealing with them" was not nearly as nice as "not having to deal with them". for instance, having email gateways was clearly better than not having any way to exchange mail between Internet/DECnets/BITNET/uucp/CSnet/etc. at the same time, email gateways never worked as well as we would have liked. they often required users to know arcane details about addressing in foreign email systems and how the addressing from different email systems were combined (things like "ATLAS::BITNET%\"USER@NODE\""@xxx.yyy were entirely too common), they introduced many additional kinds of failure which were difficult to diagnose, non-delivery reports from foreign systems were unreliable (either going to the wrong place or not being able to be returned to the sender) and hard to decipher, and return addresses were often trashed so that replies didn't work. Even the simple question "what is your email address?" was not simple to answer - the answer depended on context, and many users honestly didn't know the answer for anything beyond a very local (to them) context. Many users couldn't give their email addresses to others. I'll also note that email gateways were once ubiquitous, but now are much less common. we do need NATs in IPv4 to work around the address space shortage as well as to allow connectivity for networks using private address space which cannot easily be renumbered, just as we once needed mail gateways. but just like mail gateways, they don't have to stay around forever, and NAT use will also decline when better alternatives are available. Keith (who wrote email gateways in a past life) From owner-ietf-outbound Thu Feb 1 14:50:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA09987 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 14:50:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08906; Thu, 1 Feb 2001 14:20:32 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA25222; Thu, 1 Feb 2001 14:20:27 -0500 (EST) Message-Id: <200102011920.OAA25222@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Melinda Shore" cc: L.Wood@eim.surrey.ac.uk, ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) In-reply-to: Your message of "Thu, 01 Feb 2001 12:31:42 EST." <041a01c08c74$d800cd00$d45904d1@cisco.com> Date: Thu, 01 Feb 2001 14:20:27 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > The mailing list as delivered unto us by the IETF administrator > has a preset policy of holding email from someone not on the > mailing list until it's released by an administrator. We can > change that if people feel sufficiently strongly. For me it's completely UNacceptable to expect people to subscribe to an IETF mailing list in order to post to it. MIDCOM is an example of a group that could potentially have huge effects on other protocols; it's important for such a group to be able to accept input from, and have discussions with other groups, without expecting all of the participants to subscribe to that group. However, I have no problem with having postings from non-subscribers screened by a moderator - PROVIDED that the moderator forwards anything to the list that could POSSIBLY be legitimate for the list, and that he/she does so in a timely fashion. The role of the moderator in this case is to act as an intelligent spam filter, not to influence the discussion. (This might actually work better if the poster does not get a message saying that his posting is being held for screening.) There's another subtlety here - lists that filter mail from non-subscribers penalize folks who use subaddressing for incoming list mail, since they don't post from the same address at which they are subscribed. Ideally, lists should not consider subaddresses when comparing a contributor's address against the list of subscribers. Failing that, it's helpful if a subscriber can get his "From" address registered as one for which there is special permission to post. Keith From owner-ietf-outbound Thu Feb 1 15:20:17 2001 Received: by ietf.org (8.9.1a/8.9.1a) id PAA10760 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 15:20:02 -0500 (EST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10626 for ; Thu, 1 Feb 2001 15:13:36 -0500 (EST) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id PAA31088; Thu, 1 Feb 2001 15:12:49 -0500 Received: from bubble.watson.ibm.com (bubble.watson.ibm.com [9.2.215.93]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id PAA19048; Thu, 1 Feb 2001 15:12:49 -0500 Received: (from prasad@localhost) by bubble.watson.ibm.com (8.9.3/8.9.3/04/21/2000) id PAA05094; Thu, 1 Feb 2001 15:12:46 -0500 Date: Thu, 1 Feb 2001 15:12:46 -0500 From: V Guruprasad To: Hilarie Orman Cc: ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables Message-ID: <20010201151246.A5059@bubble.watson.ibm.com> Mail-Followup-To: Hilarie Orman , ietf@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from HORMAN@novell.com on Thu 2001.02.01 11:52:03 -0700 X-Loop: ietf@ietf.org On Thu, 2001.02.01, Hilarie Orman wrote: > Dave Cheriton's TRIAD is an example of such a proposal. > > Hilarie > > >>> Dave Crocker 02/01/01 11:05AM >>> > At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: > >You miss at least one other possibility. If it is possible to develop > >an addressing scheme that works in a heterogeneous network, then > >we can have point-to-point functionality across system borders and > >do not require a homogeneous address space to do so. Nimrod, not Triad - fails heterogeneity. -p. From owner-ietf-outbound Thu Feb 1 15:50:17 2001 Received: by ietf.org (8.9.1a/8.9.1a) id PAA11309 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 15:50:02 -0500 (EST) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11247; Thu, 1 Feb 2001 15:47:28 -0500 (EST) Received: from two.elistx.com (two.elistx.com [209.116.254.209]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G8300D6YJ4GO7@eListX.com>; Thu, 01 Feb 2001 15:48:18 -0500 (EST) Date: Thu, 01 Feb 2001 15:49:46 -0500 From: James M Galvin Subject: Re: Mail sent to midcom (fwd) In-reply-to: "01 Feb 2001 17:07:39 GMT." Sender: galvin@eListX.com To: L.Wood@eim.surrey.ac.uk Cc: ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com Reply-to: James M Galvin Message-id: <0G8300D6ZJ4GO7@eListX.com> Content-id: <13928.981060585.0@two.elistx.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" X-Loop: ietf@ietf.org ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13928.981060585.1@two.elistx.com> Although it is true that RFC2418 does not explicitly permit the "review" of messages submitted to elists from non-subscribers, it is in fact an accepted practice on IETF elists. So much so that the IESG has published a statement regarding the policy and procedures of such practices: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt Speaking for myself, I wish that all IETF elists could and would adopt the practice of reviewing all non-subscriber submissions for at least obvious irrelevance. If someone has the time it would be nice to have a more careful review to ensure messages are on-topic as described by a Working Group's charter, but that is certainly not required. The first would go a long way towards eliminating spam on IETF elists. Just to be clear, I'm making a distinction between moderation and review to reject obvious irrelevance. In that context, I agree with you that the phrasing in the notification message you received could be improved, but I think it's an unfair leap from "reviewing messages" to "midcom is not open" without even asking what the actual policy and practice is and confirming whether or not the AD and IESG are aware of it. Melinda's note makes it clear, at least to me, that the policy is consistent with the spirit of RFC2418 and the IESG statement indicated above. Speaking as Co-Chair of this working group, unless you have a specific request for a change to RFC2418 or the IESG statement, I don't see any basis for continued discussion of this point on the poised elist. If you object to how the midcom elist is operating you need to take that up with the midcom-admin and the relevant AD. Jim co-Chair of the POISSON Working Group ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Return-Path: galvin@elistx.com Thu F Status: R X-Status: X-Keywords: Return-path: Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G8300B01AFN15@eListX.com> for galvin@msgstore.elistx.com; Thu, 01 Feb 2001 12:40:35 -0500 (EST) Received: from FORWARD-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G8300B01AFM14@eListX.com> (original mail from owner-ietf-outbound@ietf.org) for galvin@msgstore.elistx.com; Thu, 01 Feb 2001 12:40:34 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G8300B01AFM13@eListX.com> for galvin+*@forward.forw.elistx.com (ORCPT galvin@elistx.com); Thu, 01 Feb 2001 12:40:34 -0500 (EST) Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G83008LLAFLQF@eListX.com> for galvin@forw.elistx.com (ORCPT galvin@elistx.com); Thu, 01 Feb 2001 12:40:34 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.acm.org (8.9.3/8.9.3) with ESMTP id MAA86706; Thu, 01 Feb 2001 12:39:19 -0500 Received: by ietf.org (8.9.1a/8.9.1a) id MAA03399 for ietf-outbound.09@ietf.org; Thu, 01 Feb 2001 12:10:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03313; Thu, 01 Feb 2001 12:07:41 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14ONCu-0004vU-00; Thu, 01 Feb 2001 17:07:40 +0000 X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ Date: Thu, 01 Feb 2001 17:07:39 +0000 (GMT) From: Lloyd Wood Subject: Mail sent to midcom (fwd) X-Sender: eep1lw@regan.ee.surrey.ac.uk To: ietf@ietf.org Cc: midcom-admin@ietf.org, poised@lists.tislabs.com Reply-to: L.Wood@eim.surrey.ac.uk Message-id: Organization: speaking for none MIME-version: 1.0 Content-type: TEXT/PLAIN X-Loop: ietf@ietf.org X-No-Archive: yes IETF mailing lists are intended for OPEN discussion; the benefits (cross-pollination between lists, lack of inhibition about stating your opinions) are widely recognised as outweighing widely-accepted drawbacks (e.g. Peter Lewis advertising every forum everywhere he can think of, allisat going on yet another hallucinogen-induced trip down memory lane). midcom is not open. midcom should not be part of the IETF, much less a working group. No, I don't care that having a moderator-in-the-middle filtering everything is in the spirit of the midcom charter and must be for my own good. I _really_ don't like the concept of an IETF-approved poster to a mailing list on an IETF-run server. We can do our own filtering, if we choose to, and we don't need the IETF to do it for us. Moderator approval of individual posters is outside the spirit of RFC2418, and would require AD and IESG approval. What are we coming to? L. PGP ---------- Forwarded message ---------- Date: Thu, 1 Feb 2001 11:00:40 -0500 (EST) From: midcom-admin@ietf.org To: l.wood@eim.surrey.ac.uk Subject: Mail sent to midcom Your mail to 'midcom' with the subject: Re: [midcom] WG scope/deliverables Is being held until the list moderator can review it for approval. The reason it is being held: Only approved posters may post without moderator approval. Either the message will get posted to the list, or you will receive notification of the moderator's decision. ------- =_aaaaaaaaaa0-- From owner-ietf-outbound Thu Feb 1 16:10:08 2001 Received: by ietf.org (8.9.1a/8.9.1a) id QAA11651 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 16:10:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11605; Thu, 1 Feb 2001 16:08:10 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA26209; Thu, 1 Feb 2001 16:08:08 -0500 (EST) Message-Id: <200102012108.QAA26209@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: James M Galvin cc: Keith Moore , ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) In-reply-to: Your message of "Thu, 01 Feb 2001 15:59:57 EST." Date: Thu, 01 Feb 2001 16:08:08 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > There's another subtlety here - lists that filter mail from > non-subscribers penalize folks who use subaddressing for incoming > list mail, since they don't post from the same address at which they > are subscribed. Ideally, lists should not consider subaddresses > when comparing a contributor's address against the list of > subscribers. Failing that, it's helpful if a subscriber can get his > "From" address registered as one for which there is special > permission to post. > > Your suggestion to "not consider subaddresses" is impractical at best, > and illegal regardless. On the contrary, it's clearly practical as I have running code in bulk_mailer that does this (which will be in the next release). Nor is it illegal. Since there are no standards regarding list filtering, there are no standards that prohibit lists from doing filtering using fuzzy matching rather than exact matching on an address. My guess is that most lists that filter on source address are already taking liberties when comparing addresses - they're doing case-insensitive comparisons of the local-part when according to the standards the local-part is allowed to be case-sensitive. It doesn't take rocket science for the list to seperately compare the domain of an email address and the portions of the local-parts up to but not including any of the separators commonly used: ( + - / . = # ) > hosting the elist. Even if it did you're suggesting the elist server > should peek or otherwise parse the localpart of an non-local email > address and that is wrong. Guess we'd better put a stop to those case-insensitive comparisons, then. > The only practical solution is, as you propose, that the elist needs to > have a separate list of addresses approved to submit messages. Actually I've demonstrated that there is another practical solution, one which is unlikely to penalize those using subaddresses at all. Keith From owner-ietf-outbound Thu Feb 1 16:50:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id QAA12277 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 16:50:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12214; Thu, 1 Feb 2001 16:48:17 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14ORaQ-0006iS-00; Thu, 01 Feb 2001 21:48:14 +0000 Date: Thu, 1 Feb 2001 21:48:13 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: James M Galvin cc: ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com, Scott Bradner , Allison Mankin Subject: Re: Mail sent to midcom (fwd) In-Reply-To: <0G8300D6ZJ4GO7@eListX.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Thu, 1 Feb 2001, James M Galvin wrote: > Although it is true that RFC2418 does not explicitly permit the "review" > of messages submitted to elists from non-subscribers, correct. > it is in fact an accepted practice on IETF elists. (or elitists, as they perhaps should be known?) I like to request a public list of those lists. It would be interesting to spot any patterns in the data. > So much so that the IESG has published a statement regarding the > policy and procedures of such practices: > > http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt Note the use in that statement of the terms 'might be needed', 'persistent' and 'excessive'. midcom's list policy clearly does not fall within that scope (a single email from me to midcom is neither persistent nor excessive). > Speaking for myself, I wish that all IETF elists could and would adopt > the practice of reviewing all non-subscriber submissions for at least > obvious irrelevance. The IESG statement does not cover that. RFC2418 does not cover that. > Just to be clear, I'm making a distinction between moderation and review > to reject obvious irrelevance. irrelevance and its obviousness is in the eye of the beholder. I would be extremely worried if messages were suppressed because e.g. a WG chair had deemed a matter to be settled and would not permit further discussion because further discussion is irrelevant (thinking of e.g. recent heated EF technical debate on diffserv). That's where this is heading. > In that context, I agree with you that the phrasing in the > notification message you received could be improved, but I think > it's an unfair leap from "reviewing messages" to "midcom is not > open" without even asking what the actual policy and practice is > and confirming whether or not the AD and IESG are aware of it. Just to be clear: midcom's policy falls outside stated IESG policy, and we've agreed that it is not permitted by RFC2418. midcom is reviewing messages, based on email address and then content. midcom is not open. There's a direct causal relationship between those two statements. > Melinda's > note makes it clear, at least to me, that the policy is consistent with > the spirit of RFC2418 see your first sentence... > and the IESG statement indicated above. which it isn't. > Speaking as Co-Chair of this working group, unless you have a specific > request for a change to RFC2418 or the IESG statement, I'd like a statement that RFC2418 will be adhered to by mailing lists. > I don't see any basis for continued discussion of this point on > the poised elist. so future emails will be filtered by the moderator? > If you object to how the midcom elist is operating you need to take that > up with the midcom-admin and the relevant AD. done. on cc. On open IETF lists, I have the right to post what you deem to be rubbish, and you have the right to choose to ignore me (and the satisfaction of doing so). midcom's policy limits those rights a priori without consensus or even persistent complaints from list members. regards, L. www.isoc.org: 'ISOC is active in areas such as censorship'. No kidding. > Jim > co-Chair of the POISSON Working Group PGP From owner-ietf-outbound Thu Feb 1 18:00:14 2001 Received: by ietf.org (8.9.1a/8.9.1a) id SAA13792 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 18:00:02 -0500 (EST) Received: from solidum.com (wirespeed.solidum.com [207.35.224.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13761 for ; Thu, 1 Feb 2001 17:58:57 -0500 (EST) Received: from research.solidum.com (phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id RAA07962 for ; Thu, 1 Feb 2001 17:58:59 -0500 Received: from phobos.solidum.com (phobos.solidum.com [127.0.0.1]) by research.solidum.com (8.11.0/8.11.0) with ESMTP id f11MvuZ27343 for ; Thu, 1 Feb 2001 17:57:56 -0500 (EST) Message-Id: <200102012257.f11MvuZ27343@research.solidum.com> To: ietf@ietf.org Subject: Re: Mail sent to midcom (fwd) In-Reply-To: Your message of "Thu, 01 Feb 2001 16:08:08 EST." <200102012108.QAA26209@astro.cs.utk.edu> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Thu, 01 Feb 2001 17:57:56 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Keith" == Keith Moore writes: Keith> On the contrary, it's clearly practical as I have running code in Keith> bulk_mailer that does this (which will be in the next release). Keith> Nor is it illegal. Since there are no standards regarding list filtering, >> The only practical solution is, as you propose, that the elist needs to >> have a separate list of addresses approved to submit messages. Keith> Actually I've demonstrated that there is another practical solution, one Keith> which is unlikely to penalize those using subaddresses at all. Frankly, both are useful and they are complementary. I run many lists. They are now all restrict_post, but I always make a corresponding -nomail list. Both are managed by majordomo, but -nomail has defunct aliases. tcpdump-workers@tcpdump.org is like this, and receives daily posts from people reporting problems. I have a script that subscribes them to the -nomail list, and then reposts their message. People who post once usually post a second time. It's a lot less hassle than spamming several hundred people, and then dealing with the "why is that spam there..." etc. If this is too strong medecine for the IETF, then a system of "+censored" lists would help. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ietf-outbound Thu Feb 1 18:40:12 2001 Received: by ietf.org (8.9.1a/8.9.1a) id SAA14590 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 18:40:02 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14508; Thu, 1 Feb 2001 18:36:02 -0500 (EST) Received: from localhost by torque.pothole.com (8.9.3/1.1.29.3/11Jan01-1206AM) id SAA0000073656; Thu, 1 Feb 2001 18:36:05 -0500 (EST) Message-Id: <200102012336.SAA0000073656@torque.pothole.com> To: ietf@ietf.org, poised@lists.tislabs.com, Scott Bradner , Allison Mankin , midcom-admin@ietf.org Subject: Re: Mail sent to midcom (fwd) In-reply-to: Your message of "Thu, 01 Feb 2001 21:48:13 GMT." Date: Thu, 01 Feb 2001 18:36:05 -0500 From: "Donald E. Eastlake 3rd" X-Mts: smtp X-Loop: ietf@ietf.org I believe most IETF WG mailing lists restrict automatic posting to those subscribed and a list of other from addresses. As a practical matter, in this age of spam, that is considered "open" and, if not in place, is commonly demanded by a consensus of the WG. Every WG is a little different and I believe these sorts of policies should be determined on a WG by WG basis by the WG chair, the WG consensus, and the AD. From: Lloyd Wood Date: Thu, 1 Feb 2001 21:48:13 +0000 (GMT) Reply-To: L.Wood@eim.surrey.ac.uk To: James M Galvin cc: ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com, Scott Bradner , Allison Mankin In-Reply-To: <0G8300D6ZJ4GO7@eListX.com> Message-ID: >On Thu, 1 Feb 2001, James M Galvin wrote: > >> Although it is true that RFC2418 does not explicitly permit the "review" >> of messages submitted to elists from non-subscribers, > >correct. It doesn't explicitly prohibit it either. >> it is in fact an accepted practice on IETF elists. > >(or elitists, as they perhaps should be known?) > >I like to request a public list of those lists. It would be >interesting to spot any patterns in the data. I don't think there is and don't see why there would be a centralized list of specific WG mailing list policies. Both the TRADE and XMLDSIG WG's, which I chair and co-chair respectively, block most non-subscriber posting. I consider this to be consistent with RFC 2418 and in both cases the policies were installed early in the WG existence after numerous complaints by WG members about spam. >> So much so that the IESG has published a statement regarding the >> policy and procedures of such practices: >> >> http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt > >Note the use in that statement of the terms 'might be needed', >'persistent' and 'excessive'. midcom's list policy clearly does not >fall within that scope (a single email from me to midcom is neither >persistent nor excessive). I interpret moderation to be the human review and approval of all messages that get to the list. Any WG that permits unrestricted posting after you subscribe is not moderated. >> Speaking for myself, I wish that all IETF elists could and would adopt >> the practice of reviewing all non-subscriber submissions for at least >> obvious irrelevance. > >The IESG statement does not cover that. RFC2418 does not cover that. > >> Just to be clear, I'm making a distinction between moderation and review >> to reject obvious irrelevance. > >irrelevance and its obviousness is in the eye of the beholder. I would >be extremely worried if messages were suppressed because e.g. a WG >chair had deemed a matter to be settled and would not permit further >discussion because further discussion is irrelevant (thinking of e.g. >recent heated EF technical debate on diffserv). As long as WG chairs are trusted to determine WG consensus, I don't see why they can't determine if a message is obviously irrelevant to the tasks for which a WG was created. I'm not claiming a WG chair would never make a mistake but their decision are subject to review. Anyway since those who subscribe can post whatever they want, judgement usually doesn't enter the picture. >That's where this is heading. > >> In that context, I agree with you that the phrasing in the >> notification message you received could be improved, but I think >> it's an unfair leap from "reviewing messages" to "midcom is not >> open" without even asking what the actual policy and practice is >> and confirming whether or not the AD and IESG are aware of it. > >Just to be clear: midcom's policy falls outside stated IESG policy, >and we've agreed that it is not permitted by RFC2418. As far as I can see, midcom's policy is unrelated to the IESG policy, which covers manual moderation of all posting. Nor do I see any agreement that it is not permitted by RFC 2418. It depends on what "open" means. The definition of words changes with circumstances. In the country or the early Internet, an open house might have no lock or guard and a host might, as many did, have a "guest" account with no password. In the middle of Manhattan or the modern Internet, open means you have locks and guards and you usually check out people who haven't gone through a procedure to get on an access list. >midcom is reviewing messages, based on email address and then >content. midcom is not open. There's a direct causal relationship >between those two statements. I believe your definition of open differs from mine. >> Melinda's >> note makes it clear, at least to me, that the policy is consistent with >> the spirit of RFC2418 > >see your first sentence... In which he said that such a policy was not explicitly permitted in 2418 which is not at all saying that it is prohibited. >> and the IESG statement indicated above. > >which it isn't. > >> Speaking as Co-Chair of this working group, unless you have a specific >> request for a change to RFC2418 or the IESG statement, > >I'd like a statement that RFC2418 will be adhered to by mailing lists. In my opinion, it is being adhered to. In any case, it is not the job of any particular WG, even POISSON, to be a policeman over other WGs. >> I don't see any basis for continued discussion of this point on >> the poised elist. > >so future emails will be filtered by the moderator? The poised mailing list is not moderated. >> If you object to how the midcom elist is operating you need to take that >> up with the midcom-admin and the relevant AD. > >done. on cc. On open IETF lists, I have the right to post what you >deem to be rubbish, and you have the right to choose to ignore me (and No, you do not have an unlimited right to post what Jim Galvin considers rubbish, for certain definitions of rubbish, on the poised mailing list, since he is a co-chair of the working group. Nor do you have any unlimited right to post what Fred Baker, as IETF chair, considers rubblish, for certain definitions of rubbish, on the IETF list. If these facts mean that the poised and ietf lists don't meet your definition of open, so be it. >the satisfaction of doing so). midcom's policy limits those rights a >priori without consensus or even persistent complaints from list >members. > >regards, > >L. > >www.isoc.org: 'ISOC is active in areas such as censorship'. No kidding. > >> Jim >> co-Chair of the POISSON Working Group > >PGP Donald From owner-ietf-outbound Thu Feb 1 19:10:18 2001 Received: by ietf.org (8.9.1a/8.9.1a) id TAA15170 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 19:10:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15130; Thu, 1 Feb 2001 19:09:31 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA28148; Thu, 1 Feb 2001 19:09:22 -0500 (EST) Message-Id: <200102020009.TAA28148@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Donald E. Eastlake 3rd" cc: ietf@ietf.org, poised@lists.tislabs.com, Scott Bradner , Allison Mankin , midcom-admin@ietf.org Subject: Re: Mail sent to midcom (fwd) In-reply-to: Your message of "Thu, 01 Feb 2001 18:36:05 EST." <200102012336.SAA0000073656@torque.pothole.com> Date: Thu, 01 Feb 2001 19:09:22 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > I believe most IETF WG mailing lists restrict automatic posting to > those subscribed and a list of other from addresses. I have the opposite belief. I've been using subaddresses for several years (so I wasn't posting from the same address at which I was receiving list mail) and most of the lists in which I've participated did not restrict such postings. It's only very recently that I've seen a significant problem. Keith From owner-ietf-outbound Thu Feb 1 20:10:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id UAA15978 for ietf-outbound.10@ietf.org; Thu, 1 Feb 2001 20:10:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15846 for ; Thu, 1 Feb 2001 20:03:13 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA28638; Thu, 1 Feb 2001 20:03:05 -0500 (EST) Message-Id: <200102020103.UAA28638@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Richardson cc: ietf@ietf.org Subject: Re: Mail sent to midcom (fwd) In-reply-to: Your message of "Thu, 01 Feb 2001 17:57:56 EST." <200102012257.f11MvuZ27343@research.solidum.com> Date: Thu, 01 Feb 2001 20:03:01 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > I run many lists. They are now all restrict_post, but I always make > a corresponding -nomail list. Both are managed by majordomo, but -nomail > has defunct aliases. > > tcpdump-workers@tcpdump.org is like this, and receives daily posts > from people reporting problems. if the list is set up right, people don't have to report such problems. the suspect messages go to the moderator; the moderator either approves them or not based on whether they're on topic for the list. if they are, the moderator can add the poster's address to the list of those who can post withut moderation. adding support for recognizing subaddresses just optimizes this process - the moderator doesn't have to deal with quite so many messages, and the posters who are using subaddresses don't have even their first message delayed. the system works fine either with our without the optimization. but it would be nice if mailing lists weren't hostile to those using subaddresses. Ketih From owner-ietf-outbound Fri Feb 2 05:01:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id FAA05422 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 05:00:02 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05389 for ; Fri, 2 Feb 2001 04:58:30 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id BAA06400; Fri, 2 Feb 2001 01:57:09 -0800 (PST) Date: Fri, 2 Feb 2001 01:57:09 -0800 (PST) From: "James P. Salsman" Message-Id: <200102020957.BAA06400@shell9.ba.best.com> To: l.wood@eim.surrey.ac.uk Subject: Re: Mail sent to midcom (fwd) Cc: ietf@ietf.org X-Loop: ietf@ietf.org Lloyd, I second your request: >>... unless you have a specific request for a ... IESG statement, > > I'd like a statement that RFC2418 will be adhered to by mailing lists. So would I. I use multiple email addresses: [local-subaddr]@bovik.org, bovik@best.com, etc. -- like thousands of other people. And as people on this list should know by now, I value pseudonymity and anonymity in the rare circumstances that they are necessary and in the common circumstances that they are sufficient. Lately, the only clear need for this kind of thing has been those virus-alert email warnings. What's next, computer-prion alerts? ("Warning: This message was edited by the author and not approved by the U.N. Department of Culture! Further perusal of this message might eat away at your brain. This message brought to you by a robot authorized to prevent you from seeing what its creator thinks you shouldn't." :) My local USENET newsgroups have a "cancelcritter" that uses a rule-based system to decide what articles are velveeta. The fact that it operates behind the scenes is pretty strange. If it would only summarize the subject lines and source addresses of the messages it has cancelled on a regular basis, that would be great. But because it does, some people claim that it often makes mistakes, and so it is another one of the many similar reasons that cancels are often ignored by news admins these days. Similarly, instead of moderating non-subscriber messages, the default for mailing lists should be to pass them through unless the conditions described in: >> http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt in particular: >... 'persistent' and 'excessive'.... are detected. So, for example, if you have the tenth non-subscriber message in the last hour on a list that usually gets ten messages a day, then maybe it is time to start holding them for the moderator. Similarly, for "middle boxes," if you are keeping statistics on the packets you are forwarding, and all the sudden the proportion of SYNs from a particular neighbor spikes, maybe it is time to emulate a source quench on that neighbor. (Or heck, why not even send a few ICMP source quenches just to say you did.) And now, for the "thinking outside the box" economic analogy for this class of problems. Lately, I've been running a data collection routine that is intended to promote reading literacy using internet technologies: http://www.bovik.org/reps-char.cgi Roughly half of the example children represented in the data presented by that script are poor readers for their age level. Why are they poor readers? Because they live in poor school districts with large class sizes and insufficient insitutional support. Why are they in those circumstances? Because their wealthy metropolitan neighbors are so carefully concerned with the education of their own children, that the often carefully adjust the flow of funds to limit the distribution based on "performance" such that the schools that already have the smaller class sizes and the best paid teachers get more money, and no progress in class size or teacher salaries is made in the poorly-performing schools. So, just as some list administrators limit the ability to post in a timely fashion to those already subscribed, many states have complicated school funds distribution formulas which act to limit the resources needed for good education to those who already have them. In both cases, it is done in the interest of protecting a resource, ease of communication or reading literacy ability, by hoarding it to those who already have it. The analogious solution to the one proposed above would be similar to the Bush education plan, which only cuts off funds after three years of poor school performance. Cheers, James From owner-ietf-outbound Fri Feb 2 06:00:21 2001 Received: by ietf.org (8.9.1a/8.9.1a) id GAA05962 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 06:00:02 -0500 (EST) Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05889 for ; Fri, 2 Feb 2001 05:56:04 -0500 (EST) Received: from caplin.cs.ui.ac.id (caplin.cs.ui.ac.id [152.118.36.9]) by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA24206 for ; Fri, 2 Feb 2001 18:16:59 +0700 Received: from rmsbase.vlsm.org (IDENT:root@rmsbase.acad.cs.ui.ac.id [152.118.26.15]) by caplin.cs.ui.ac.id (8.9.3/8.9.3) with ESMTP id SAA06011 for ; Fri, 2 Feb 2001 18:01:01 +0700 (JAVT) Received: from vlsm.org (IDENT:rms46@rmsbase.vlsm.org [152.118.26.15]) by rmsbase.vlsm.org (8.9.3/8.8.7) with ESMTP id RAA01339; Fri, 2 Feb 2001 17:57:16 +0700 Sender: rms46@VLSM.ORG Message-ID: <3A7A928A.12FA96F@vlsm.org> Date: Fri, 02 Feb 2001 17:57:14 +0700 From: "Rahmat M. Samik-Ibrahim" Organization: VLSM-TJT X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> <3A7956F7.1761708C@vlsm.org> <3A79A400.74B9E7E3@isi.edu> <3A79B1C2.B20E36DB@hursley.ibm.com> <3A79B38F.CE3A4E32@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Joe Touch wrote: >> IANA can't change the status of an STD - that's an IESG action. >> If you think this matters, I would raise it with the latter. > Agreed. I was not aware that there was ever a proposed STD-1 I-D and/ or last call. Anyway, is it possible to declare (by whoever) the http://www.iana.org/numbers.htm as STD-2? Or, perhaps a mini RFC as STD-2 that informs where to get the current numbers? I also believe that more information should be added into an RFC: - where to get an RFC - where to get the recent status of an RFC It is sometimes very confusing for the internet community at large, to trace back the source of accurate information. PS, these following was cited from a standard /etc/services: -------------------------------------------------------------- # Note that it is presently the policy of IANA to assign a single well-known # port number for both TCP and UDP; hence, most entries here have two entries # even if the protocol doesn't support UDP operations. # Updated from RFC 1700, ``Assigned Numbers'' (October 1994). Not all ports # are included, only the more common ones. [...] # From ``Assigned Numbers'': #> The Registered Ports are not controlled by the IANA and on most systems #> can be used by ordinary user processes or programs executed by ordinary #> users. #> Ports are used in the TCP [45,106] to name the ends of logical #> connections which carry long term conversations. For the purpose of #> providing services to unknown callers, a service contact port is #> defined. This list specifies the port used by the server process as its #> contact port. While the IANA can not control uses of these ports it #> does register or list uses of these ports as a convienence to the #> community. regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Good bye hegemony - http://sapi.vlsm.org/DLL/linuxrouter From owner-ietf-outbound Fri Feb 2 07:59:28 2001 Received: by ietf.org (8.9.1a/8.9.1a) id HAA06449 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 07:20:01 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06410 for ; Fri, 2 Feb 2001 07:17:39 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f12CFpC03050; Fri, 2 Feb 2001 07:15:51 -0500 Message-Id: <200102021215.f12CFpC03050@hygro.adsl.duke.edu> To: L.Wood@eim.surrey.ac.uk cc: ietf@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) In-Reply-To: Message from Lloyd Wood of "Thu, 01 Feb 2001 21:48:13 GMT." Date: Fri, 02 Feb 2001 07:15:51 -0500 From: Thomas Narten X-Loop: ietf@ietf.org Lloyd, Just to be clear: > > If you object to how the midcom elist is operating you need to take that > > up with the midcom-admin and the relevant AD. > done. on cc. On open IETF lists, I have the right to post what you > deem to be rubbish, and you have the right to choose to ignore me (and > the satisfaction of doing so). midcom's policy limits those rights a > priori without consensus or even persistent complaints from list > members. Are you asserting that you (and anyone else for that matter) have the right to spam an IETF mailing list and that filtering/moderating such messages is inappropriate? I would be surprised if there is widespread support for such a view. What complicates the overall issue is that in all the cases I'm aware of where "moderating" goes on, it is to reduce spam. I suspect few people would argue that spam filtering is an unacceptable "censorship" in practice. However, because spam filters can make mistakes, it is highly desirable (as a sanity check/second opinion) for a human to double check automatic rejections. Unfortunately, having a human look at a message and decide whether to forward it on will always be viewed as moderation/censorship by some regardless of the reasons for doing so. Consider the two extremes: automatic spam filters in which no human has chance to overrule an automatic rejection, and completely open mailing lists with no anti-spam filters. Neither of these seems to be desired in the majority of cases, and any in-betweens would appear to require some level of human "moderation". Thomas From owner-ietf-outbound Fri Feb 2 08:01:37 2001 Received: by ietf.org (8.9.1a/8.9.1a) id IAA06855 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 08:00:02 -0500 (EST) Received: from china.com (TCE-E-7-182-11.bta.net.cn [202.106.182.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06558 for ; Fri, 2 Feb 2001 07:38:02 -0500 (EST) Message-Id: <200102021238.HAA06558@ietf.org> Received: from plain([213.112.130.48]) by china.com(JetMail 2.5.3.0) with SMTP id jm4c3a7acc04; Fri, 2 Feb 2001 12:33:45 -0000 From: ietf@ietf.org Reply-To: freebiesnow@hotmail.com To: ietf@ietf.org Subject: Revealed! - Scientifically Proven Strategies....... Date: Fri, 2 Feb 2001 13:32:09 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Loop: ietf@ietf.org .................Guaranteed To Double Your Profit's Every Month or You Keep The System For Free! Who else wants to know which strategy ,R. Crawford, Ohio, used to actually earn $40.000,- a month, just after the 5.th month? From then on he always earned $40.000 a month or much more. Do it yourself now! the secret revealed at http://home.no.net/bred/ I just saw your mail on the web so I thought you would like to now about this opportunity. Are you looking for something else? let me know, send a mail to freebiesnow@hotmail.com Sign Alf Jansen Jr From owner-ietf-outbound Fri Feb 2 08:10:14 2001 Received: by ietf.org (8.9.1a/8.9.1a) id IAA07360 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 08:10:03 -0500 (EST) Received: from china.com (TCE-E-7-182-11.bta.net.cn [202.106.182.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06560 for ; Fri, 2 Feb 2001 07:38:10 -0500 (EST) Message-Id: <200102021238.HAA06560@ietf.org> Received: from plain([213.112.130.48]) by china.com(JetMail 2.5.3.0) with SMTP id jm4c3a7acc04; Fri, 2 Feb 2001 12:33:45 -0000 From: ietf@ietf.org Reply-To: freebiesnow@hotmail.com To: ietf@ietf.org Subject: Revealed! - Scientifically Proven Strategies....... Date: Fri, 2 Feb 2001 13:32:09 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Loop: ietf@ietf.org .................Guaranteed To Double Your Profit's Every Month or You Keep The System For Free! Who else wants to know which strategy ,R. Crawford, Ohio, used to actually earn $40.000,- a month, just after the 5.th month? From then on he always earned $40.000 a month or much more. Do it yourself now! the secret revealed at http://home.no.net/bred/ I just saw your mail on the web so I thought you would like to now about this opportunity. Are you looking for something else? let me know, send a mail to freebiesnow@hotmail.com Sign Alf Jansen Jr From owner-ietf-outbound Fri Feb 2 08:30:11 2001 Received: by ietf.org (8.9.1a/8.9.1a) id IAA07904 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 08:30:03 -0500 (EST) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07654 for ; Fri, 2 Feb 2001 08:23:09 -0500 (EST) Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id FAA10663 for ; Fri, 2 Feb 2001 05:25:09 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <1D2B37PR>; Fri, 2 Feb 2001 05:23:11 -0800 Message-ID: <37BE60F57DF4D3119BE1009027AF96C577F1F3@vhqpostal1.verisign.com> From: Cameron Smith To: ietf@ietf.org Subject: Out of Office AutoReply: Revealed! - Scientifically Proven Strate gies....... Date: Fri, 2 Feb 2001 05:23:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org The message you sent to csmith@verisign.com was not received. Please re-send all key management related e-mails to sdawdy@verisign.com Regards, Cameron From owner-ietf-outbound Fri Feb 2 09:10:19 2001 Received: by ietf.org (8.9.1a/8.9.1a) id JAA09251 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 09:10:04 -0500 (EST) Received: from verdi.jlc.net ([199.201.159.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08918 for ; Fri, 2 Feb 2001 09:01:36 -0500 (EST) Received: by verdi.jlc.net (Postfix, from userid 104) id 855DF337B7; Fri, 2 Feb 2001 09:01:37 -0500 (EST) Date: Fri, 2 Feb 2001 09:01:37 -0500 From: John Leslie To: poised@lists.tislabs.com Cc: ietf@ietf.org Subject: Re: Mail sent to midcom (fwd) Message-ID: <20010202090137.E30747@verdi> References: <200102012336.SAA0000073656@torque.pothole.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102012336.SAA0000073656@torque.pothole.com>; from dee3@torque.pothole.com on Thu, Feb 01, 2001 at 06:36:05PM -0500 X-Loop: ietf@ietf.org I really don't want to participate in a flame-war about "moderation", but Donald E. Eastlake 3rd wrote: > > As long as WG chairs are trusted to determine WG consensus, I don't > see why they can't determine if a message is obviously irrelevant to > the tasks for which a WG was created. It is a bad idea to assign to the same person the tasks of limiting _input_ to a discussion and determining the _output_ of a discussion. We should _try_ to move away from any discussion of whether our leaders are "trustworthy", and instead discuss whether the _structures_ in place are designed correctly to achieve our purposes. -- John Leslie From owner-ietf-outbound Fri Feb 2 10:20:51 2001 Received: by ietf.org (8.9.1a/8.9.1a) id KAA11589 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 10:20:03 -0500 (EST) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11309 for ; Fri, 2 Feb 2001 10:10:15 -0500 (EST) Received: from two.elistx.com (two.elistx.com [209.116.254.209]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G84000A9Y6GDG@eListX.com> for ietf@ietf.org; Fri, 02 Feb 2001 10:11:05 -0500 (EST) Date: Fri, 02 Feb 2001 10:12:31 -0500 (EST) From: James M Galvin Subject: Re: Mail sent to midcom (fwd) In-reply-to: <200102012108.QAA26209@astro.cs.utk.edu> X-Sender: galvin@two.elistx.com To: Keith Moore Cc: ietf@ietf.org, poised@lists.tislabs.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I'm going to stick with my opinion and "agree to disagree" because although everything you say may be true, my experience suggests otherwise. The issue is that of false positives. I used to do what you describe but the algorithm got it wrong once, or at least one time that was brought to my attention. Not because the algorithm was buggy but because assuming "." is a separator between pure localpart and subaddress is wrong. I also had some strange experiences with "/" in "X.400" addresses, but that may be moot today. The downside of getting it wrong may only be annoying, in general, but as a service provider I can not afford to be annoying. In my opinion it does take rocket science because you're making semantic assumptions with no foundation whatsoever. I called it illegal because a localpart should be opaque outside its local environment. I tried to find a reference to this effect in some standard but couldn't. It may just be "practiced wisdom" but I can not remember a time when it wasn't true. You more or less got me on the case sensitivity issue. I also agree with your assessment that most filtering practices incorrectly do case insensitive comparisons of localparts. However, as a practical matter, I think this is one of those issues where you have to be "liberal in what you accept, conversative in what you send." I'm very careful to retain case settings (got that wrong once, too, many years ago) and I do case insensitive comparisons of localparts, but only after the domains match. This doesn't make it right, but I'm also careful to note duplicates so if there were two subscribers with the "same" localpart but with different case settings, it would get noticed immediately. Thus, in this case, I have a fail-safe so I'm comfortable doing it with automation. You're right about the lack of filtering standards and I for one think we should change that. Jim On Thu, 1 Feb 2001, Keith Moore wrote: Date: Thu, 01 Feb 2001 16:08:08 -0500 From: Keith Moore To: James M Galvin Cc: Keith Moore , ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) > There's another subtlety here - lists that filter mail from > non-subscribers penalize folks who use subaddressing for incoming > list mail, since they don't post from the same address at which they > are subscribed. Ideally, lists should not consider subaddresses > when comparing a contributor's address against the list of > subscribers. Failing that, it's helpful if a subscriber can get his > "From" address registered as one for which there is special > permission to post. > > Your suggestion to "not consider subaddresses" is impractical at best, > and illegal regardless. On the contrary, it's clearly practical as I have running code in bulk_mailer that does this (which will be in the next release). Nor is it illegal. Since there are no standards regarding list filtering, there are no standards that prohibit lists from doing filtering using fuzzy matching rather than exact matching on an address. My guess is that most lists that filter on source address are already taking liberties when comparing addresses - they're doing case-insensitive comparisons of the local-part when according to the standards the local-part is allowed to be case-sensitive. It doesn't take rocket science for the list to seperately compare the domain of an email address and the portions of the local-parts up to but not including any of the separators commonly used: ( + - / . = # ) > hosting the elist. Even if it did you're suggesting the elist server > should peek or otherwise parse the localpart of an non-local email > address and that is wrong. Guess we'd better put a stop to those case-insensitive comparisons, then. > The only practical solution is, as you propose, that the elist needs to > have a separate list of addresses approved to submit messages. Actually I've demonstrated that there is another practical solution, one which is unlikely to penalize those using subaddresses at all. Keith From owner-ietf-outbound Fri Feb 2 10:30:13 2001 Received: by ietf.org (8.9.1a/8.9.1a) id KAA11915 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 10:30:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11469 for ; Fri, 2 Feb 2001 10:15:34 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.2/8.11.2) id f12FFZR25162 for ietf@ietf.org env-from ; Fri, 2 Feb 2001 08:15:35 -0700 (MST) Date: Fri, 2 Feb 2001 08:15:35 -0700 (MST) From: Vernon Schryver Message-Id: <200102021515.f12FFZR25162@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: Mail sent to midcom (fwd) X-Loop: ietf@ietf.org > From: Thomas Narten > ... However, because spam filters can make mistakes, it is > highly desirable (as a sanity check/second opinion) for a human to > double check automatic rejections. Unfortunately, having a human look > at a message and decide whether to forward it on will always be viewed > as moderation/censorship by some regardless of the reasons for doing > so. > ... That seemes to assume that automated spam filters are necessarily based on content and have significant false positive rates. Neither need be true. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Fri Feb 2 10:40:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id KAA12213 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 10:40:02 -0500 (EST) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11819 for ; Fri, 2 Feb 2001 10:26:47 -0500 (EST) Received: from two.elistx.com (two.elistx.com [209.116.254.209]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G84000BCYY1DG@eListX.com> for ietf@ietf.org; Fri, 02 Feb 2001 10:27:38 -0500 (EST) Date: Fri, 02 Feb 2001 10:29:04 -0500 (EST) From: James M Galvin Subject: Re: Mail sent to midcom (fwd) In-reply-to: <200102020957.BAA06400@shell9.ba.best.com> X-Sender: galvin@two.elistx.com To: "James P. Salsman" Cc: ietf@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org Your suggestion to automate the detection of "persistent and excessive" could work for people and would help "throttle down" those discussions that need it from time to time, but it would not protect an elist from spam. With only one exception of which I am aware (and its not midcom), the only reason for the "moderation" is to identify spam and to prevent such one-off messages from ever getting to the subscribers. Jim On Fri, 2 Feb 2001, James P. Salsman wrote: Date: Fri, 02 Feb 2001 01:57:09 -0800 (PST) From: James P. Salsman To: l.wood@eim.surrey.ac.uk Cc: ietf@ietf.org Subject: Re: Mail sent to midcom (fwd) Lloyd, I second your request: >>... unless you have a specific request for a ... IESG statement, > > I'd like a statement that RFC2418 will be adhered to by mailing lists. So would I. I use multiple email addresses: [local-subaddr]@bovik.org, bovik@best.com, etc. -- like thousands of other people. And as people on this list should know by now, I value pseudonymity and anonymity in the rare circumstances that they are necessary and in the common circumstances that they are sufficient. Lately, the only clear need for this kind of thing has been those virus-alert email warnings. What's next, computer-prion alerts? ("Warning: This message was edited by the author and not approved by the U.N. Department of Culture! Further perusal of this message might eat away at your brain. This message brought to you by a robot authorized to prevent you from seeing what its creator thinks you shouldn't." :) My local USENET newsgroups have a "cancelcritter" that uses a rule-based system to decide what articles are velveeta. The fact that it operates behind the scenes is pretty strange. If it would only summarize the subject lines and source addresses of the messages it has cancelled on a regular basis, that would be great. But because it does, some people claim that it often makes mistakes, and so it is another one of the many similar reasons that cancels are often ignored by news admins these days. Similarly, instead of moderating non-subscriber messages, the default for mailing lists should be to pass them through unless the conditions described in: >> http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt in particular: >... 'persistent' and 'excessive'.... are detected. So, for example, if you have the tenth non-subscriber message in the last hour on a list that usually gets ten messages a day, then maybe it is time to start holding them for the moderator. Similarly, for "middle boxes," if you are keeping statistics on the packets you are forwarding, and all the sudden the proportion of SYNs from a particular neighbor spikes, maybe it is time to emulate a source quench on that neighbor. (Or heck, why not even send a few ICMP source quenches just to say you did.) And now, for the "thinking outside the box" economic analogy for this class of problems. Lately, I've been running a data collection routine that is intended to promote reading literacy using internet technologies: http://www.bovik.org/reps-char.cgi Roughly half of the example children represented in the data presented by that script are poor readers for their age level. Why are they poor readers? Because they live in poor school districts with large class sizes and insufficient insitutional support. Why are they in those circumstances? Because their wealthy metropolitan neighbors are so carefully concerned with the education of their own children, that the often carefully adjust the flow of funds to limit the distribution based on "performance" such that the schools that already have the smaller class sizes and the best paid teachers get more money, and no progress in class size or teacher salaries is made in the poorly-performing schools. So, just as some list administrators limit the ability to post in a timely fashion to those already subscribed, many states have complicated school funds distribution formulas which act to limit the resources needed for good education to those who already have them. In both cases, it is done in the interest of protecting a resource, ease of communication or reading literacy ability, by hoarding it to those who already have it. The analogious solution to the one proposed above would be similar to the Bush education plan, which only cuts off funds after three years of poor school performance. Cheers, James From owner-ietf-outbound Fri Feb 2 11:10:11 2001 Received: by ietf.org (8.9.1a/8.9.1a) id LAA13321 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 11:10:02 -0500 (EST) Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13113 for ; Fri, 2 Feb 2001 11:04:11 -0500 (EST) Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id IAA27921; Fri, 2 Feb 2001 08:03:38 -0800 (PST) Date: Fri, 2 Feb 2001 08:03:38 -0800 (PST) From: "James P. Salsman" Message-Id: <200102021603.IAA27921@shell9.ba.best.com> To: galvin@acm.org Subject: rule-based moderation (was Re: Mail sent to midcom (fwd)) Cc: ietf@ietf.org In-Reply-To: X-Loop: ietf@ietf.org Jim, Thanks for your comments: > Your suggestion to automate the detection of "persistent and excessive" > could work for people and would help "throttle down" those discussions > that need it from time to time, but it would not protect an elist from > spam. Neither does non-subscriber moderation. List spammers can subscribe first, from throw-away 3rd party accounts for example. The only way to completely block spam is prior restraint, which causes: - subjective judgements on borderline cases - need for moderator(s) to be on line often - delays in posting for everyone - other forums to become more useful None of those disadvantages are acceptable, as reflected in the official IETF Working Group guidelines. People who are not used to spam and incapable of ignoring it probably do not have the kind of experience with the internet which would help the IETF serve its mission and advance the state of the art, anyway. Having said that, if there is going to be a rule-based system in place to detect "persistent and excessive" posts to a list and spool such messages depending upon parameters such as subscriber/nonsubscriber source address, here are some more suggestions for paramters: - Redundancy. Messages substantially similar to recent messages (based on similarities seen in the virus warning floods of the past few months on the ietf list) might be held for a moderator to examine at his or her convienience. - HTML email. I am not the only one who would like to see HTML messages replaced with a message saying "This message contained only HTML; to view it, please visit http://www.ietf.org/...." - Size. Messages over several dozen kilobytes could be truncated and similar archive pointer URLs placed at the beginning and end of the list-sent message with a similar explanatory blurb. However, I would advise not including rules based on substrings (e.g., "make money fa$t" etc.) because that is an endless game of cat-and-mouse. Cheers, James From owner-ietf-outbound Fri Feb 2 11:20:09 2001 Received: by ietf.org (8.9.1a/8.9.1a) id LAA13744 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 11:20:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13411 for ; Fri, 2 Feb 2001 11:11:42 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA03106; Fri, 2 Feb 2001 11:11:42 -0500 (EST) Message-Id: <200102021611.LAA03106@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: James M Galvin cc: Keith Moore , ietf@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) In-reply-to: Your message of "Fri, 02 Feb 2001 10:12:31 EST." Date: Fri, 02 Feb 2001 11:11:41 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org Jim, I agree that it's wrong to assuming that "." is a separator, but if you have a subscriber named "xxx.yyy@zzz", how likely is it really that a posting from "xxx@zzz" is spam? Keith From owner-ietf-outbound Fri Feb 2 11:50:20 2001 Received: by ietf.org (8.9.1a/8.9.1a) id LAA15108 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 11:50:04 -0500 (EST) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14841 for ; Fri, 2 Feb 2001 11:44:25 -0500 (EST) Received: from two.elistx.com (two.elistx.com [209.116.254.209]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G85000H32IWD9@eListX.com> for ietf@ietf.org; Fri, 02 Feb 2001 11:44:57 -0500 (EST) Date: Fri, 02 Feb 2001 11:46:23 -0500 (EST) From: James M Galvin Subject: Re: Mail sent to midcom (fwd) In-reply-to: <200102021611.LAA03106@astro.cs.utk.edu> X-Sender: galvin@two.elistx.com To: Keith Moore Cc: ietf@ietf.org, poised@lists.tislabs.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org I agree that it's wrong to assuming that "." is a separator, but if you have a subscriber named "xxx.yyy@zzz", how likely is it really that a posting from "xxx@zzz" is spam? Aah, I wasn't seeing your heuristic correctly before. I agree, the probability such a thing is spam is pretty low, and the downside of getting it wrong is "harmless" enough. So, you could even automate such a thing. The ding that I got in this "parsing localpart space" was unsubscribing "xxx.yyy@zzz" because I assumed that "xxx@zzz" was a match. Fortunately, I've always sent "good-bye" messages so the mistake was caught more or less immediately, but it really turned me off to localpart parsing, which, spam filtering aside, I still think is wrong. Jim From owner-ietf-outbound Fri Feb 2 13:13:04 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA19630 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 13:12:41 -0500 (EST) Received: from kestrel.prod.itd.earthlink.net (kestrel.prod.itd.earthlink.net [207.217.121.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18670 for ; Fri, 2 Feb 2001 12:56:42 -0500 (EST) Received: from [192.168.0.1] (sdn-ar-002njprinP330.dialsprint.net [158.252.31.108]) by kestrel.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id JAA09925 for ; Fri, 2 Feb 2001 09:56:38 -0800 (PST) Mime-Version: 1.0 X-Sender: cook@pop3.netaxs.com Message-Id: Date: Fri, 2 Feb 2001 12:55:58 -0500 To: ietf@ietf.org From: Gordon Cook Subject: Light, PI Gig E - 2001 Annual Report see http://cookreport.com/lightipgige.shtml Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org Light, IP and Gigabit Ethernet A Road Map for Evaluation of Technology Choices Driving the Future Evolution of Telecommunications - 2000 COOK Report Interviews - Introduction to the 6th in an annual series. Contrary to some opinions, the COOK Report finds that the Internet revolution is not spelled dot com. The revolution is in fact to be found in a total revamping of the transport of bits. While the dot com empires of 1999 collapsed in 2000 the cost effectiveness of pushing the Internet Protocol over glass yielded more dividends than ever before. A growing amount of telecom traffic has migrated to a growing amount of fiber. The pure Internet play throws out SONET effectively doubling available fiber in the case where redundant loops were used. Whereas lighting each new fiber used to call for new bays of OC-48 SONET equipment at perhaps $100,000 a bay and up, a strand can now be lit at a gigabit by a $7,000 Ethernet switch on each end. While gigabit Ethernet over glass is the current preferred Internet way, ten gigabit Ethernet transport will be arriving by year's end. If 40 lambdas per strand were high end in 2000, 160 is likely to be common by year's end. With the completion of multiple metro fiber build outs, end-to-end fiber may now be taken or granted by most business customers. The explosion of bandwidth as the result of more fiber and technology that squeezes more bandwidth from each strand has meant that, in some instances, the delivery of a gigabit costs about what a T-1 did a decade ago. The bottom line is that telecommunications which is prepared to forego traversing the legacy PSTN is now upwards of 1000 times cheaper than that which powers a circuit-switched voice call. While corporate managed VPNs have been able to avoid the PSTN for some time, a new development has emerged in Canada where customer management of optical wavelengths using the OBGP protocol holds the promise that by year's end users of Canada's new public sector gigabit Ethernet over fiber infrastructure will be avoiding carrier clouds entirely. At the basic levels of both transport and network management the Internet revolution is shaping up to tell the PSTN that it is no longer needed. In telephony meanwhile protocols are being developed that will allow the diversion of large amounts of PSTN traffic to the Internet. ENUM is the major such protocol. This will allow Internet carriers to offer and deliver many services to PSTN attached phones that the PSTN itself cannot negotiate. Other protocols such as instant messaging are shaping up as coordinators for PSTN activity and off on switches that can control Internet connected devices. Fiber to the home is becoming more common and companies like World Wide Packets are gearing up to make gigabit Ethernet termination equipment that will give connected families, telephone, fax, high end video, ordinary TV and data off of the same line. Canarie the Canadian advanced internet agency has some interesting ideas about these developments stating that Divergence rather than Convergence may be the key to low cost fiber to the home. Here is a narrative paraphrase of the language of a slide from the presentation 'Optical Communities' in September 2000. When people first started looking at Fiber to the Home (FTTH), they deemed it to be too expensive because it assumed all services would be converged - date, voice and video. They noted that expensive terminal equipment would be required to segregate voice, data and video services at the home. Meanwhile voice traffic has largely gone wireless. Note that lifeline voice can significantly increase system costs by demanding high reliability and depending for this on DC battery power, 911 services. Perhaps it is time to conclude that the big driver for residential broadband is not voice or video. It is the Internet. Very soon Internet will carry video and second line voice. So instead of building a converged network such as FSAN, HFC, etc build an Internet network only. Divergence rather than Convergence may be the key to low cost FTTH. While the power of the new systems is awesome, there are additional issues that will keep very interesting the life of anyone who must evaluate these changes and plan a winning strategy for the future. While one better be aware of the key differences in the power of the technology when compared to the circuit switched world's way of doing things, one also needs to understand that progress has, in this case, waded out into new and uncertain territory. There are some growth and scaling issues where the answers are not yet clearly understood. For example readers should consider Bill St. Arnaud's paper on scaling issues of Internet growth. < http://www.canet3.net/library/papers/scaling.html> If the suppositions in this paper prove to be correct, then the role of backbones will have to be rethought and much Internet topology rearranged. One of the developments that influenced his thinking occurred on December 4, 2000 when Essex Corp announced an advance that enabled it to push as many as 4,000 lambdas down a single strand of fiber. On December 8 St. Arnaud posted the following to his Canarie mail list. "[Here are some excerpts from a recent article in Lightreading that I believe illustrates the point that Ultra dense wave division multiplexing systems is not about bandwidth, but connectivity. A number of companies are starting to realize that today's Internet architecture (which is still fundamentally based on the old telco network model) will not scale. As intelligence moves to the edge, the existing network architecture must grow at some function related to the square of the number of users. However [the problem is what to do] if the increase in the number of the customer's own wavelengths and the fiber in the network only grows linearly? Intriguingly such a customer owned network architecture starts to closely resemble the neuron architecture of the brain. Perhaps mother nature long ago discovered the most efficient architecture for distributed intelligence? - BSA]" From the December 4, 2000 issue of Lightreading.... http://www.lightreading.com/document.asp?doc_id=2760 "We don't need thousands of wavelengths for bandwidth, we need it for connectivity," says Simon Cao, chief technology officer at Avanex Corp. (Nasdaq: AVNX), a company that's developing high channel-count wavelength systems. Cao figures that the availability of thousands of channels in combination with tunable lasers will make it possible to eliminate complex optical switches, by using wavelength routing instead . That idea is the driving force behind all of Avanex's developments, he says." "Despite its careless capacity talk, Essex has also thought out how to take advantage of the extra connectivity. Moodispaw reckons that Essex's solution will be perfect for customer-owned wavelengths in the access network. About 1 Gbit/s would be adequate to supply a gigabit Ethernet line to a business. Each customer pays less for its wavelength, but the service provider is able to sell to a lot more customers, so everybody is happy." What this means is that we likely soon see customer owned wavelengths of a gigabit. Such wavelengths will be plentiful, affordable and matched to the speeds of the Internet's basic gigabit Ethernet end-to-end architecture. When only the rich and mighty carriers owned fiber and the very expensive lasers that could pump bits and the even more expensive SONET equipment that sustained the bits, we imagined that bandwidth was a valuable commodity obtainable only from "on high," or from upstream. Indeed the carriers recognized their position and charged large sums for the scarce commodity that they delivered. This situation has dramatically changed. If you own a piece of fiber in a metro area network, you can power that fiber with a lambda delivered as gigabit Ethernet for a one time investment of about $15,000. When you run out of bandwidth, adding the multiplexer necessary to turn the one lambda into four is also affordable. In this sense bandwidth can now be generated by customers and used very cheaply at the edge of the network over hops that in ideal conditions can be as much as 100 kilometers. Suddenly these customers can throw cheap bandwidth at quality of service issues. Their whole outlook on life starts to change rapidly. George Gilder was observed to say that "the companies that exploit bandwidth recklessly, will win." On January 29, 2001 Bill St. Arnaud observed "Although I may disagree with Gilder on some of his predictions, I think he's gotten this one right. To date most advanced optical network research is based around the assumption that bandwidth is a precious and rare commodity and therefore we must optimize the network topology and try to extract every possible bit of capacity. One of the underlying assumptions of the existing CA*net 3 network and proposed CA*net 4 network architecture is that bandwidth can be wasted. Rather than concentrating on applications and technologies that optimize the use of bandwidth, we want to concentrate on applications and technologies that waste bandwidth but in doing so derive the maximum benefit for the user - hence our focus on "customer empowered" optical networks. There is no question in our mind with customer empowered networks that bandwidth will be wasted, wavelengths will be orphaned and seen from the perspective of a central carrier the network topology will be less than optimum. But in a world of thousands of wavelengths and near infinite bandwidth who cares? The true measure is whether the customer can easily and rapidly deploy new broadband applications and services." "At CANARIE we are initiating a number of projects with this premise in mind - OBGP which will allow customers to setup and tear down their own wavelengths at will, WDD- wavelength disk drives will drive new concepts in distributed super computing, object oriented networking enables the wavelength to become a software object, community based condominium fiber networks, and much, much more. Stay tuned for more announcements and developments in this area." Arnaud's words portend a seismic shift in the telecommunications landscape. With the exception of some important qualifiers we believe that he is correct. One must understand that, for the time being, bandwidth is cheap only in proportion to the distance that it must travel. Very high bandwidth sent over long distances is still quite expensive. Bandwidth that must be provided on a corporate wide scale for mission critical activities is also somewhat expensive. What Arnaud is talking about will change the world. The only question is how fast. To sum up. Costs are falling. Depending on the regulatory environment, the amount of capital necessary to become a small scale telecommunications provider is rapidly shrinking. Independent back yard gigabit Ethernet providers can deliver broadband services at a fraction of the cost but equal in quality to what is accessible from larger more traditional companies. There appears to be a choice of two paths to our telecom future. One is to go with the highly innovative pure Internet approach of gigabit Ethernet over condominium fiber. Such a choice empowers the customer, facilitates decentralization over centralized control and provides small and innovative businesses with the environment that they need in order to flourish. The other path is to try to fore stall the innovation by squashing competitors with a massive vertically integrated company founded on older technology and leveraging access to content and over a network monopoly so pervasive that people will find they have no choice but to buy it. What could be in store for us all, if things go in this direction, was summarized by Scott Cleland CEO of the Precursor Group on Friday January 19th, 2001. "Precursor believes AOL-TW has budding 'Microsoft-like' potential to grow increasingly dominant by being the leading national company that brings together the various online interfaces (content, Internet access, buddy lists, instant messaging, etc.) to become the de facto consumer online access market standard much like Microsoft Windows brought together the various desktop applications to become the de facto consumer software market standard." On the one hand, the AOL infrastructure, which, compared to what the Canadians are doing, can most kindly be called archaic, has to be a terribly attractive vision for the ILECs. After all, it will give them plenty of time to finish depreciation of their copper plant. On the other hand innovative Internet technology ventures have the most to gain from taking the Canadian road. To facilitate making this choice with more certainty, in this publication we offer a recapitulation of COOK Report interviews on the shifting market domain of the optical network. These interviews are unique in that they treat complex key technical issues with attention to depth and detail found no where else. We believe that they form a set of resources that will permit readers to decide for themselves what direction is most beneficial to the future of their enterprise. As we ponder these developments, we realize that we may be standing on the cusp of events that may overturn the economic structure of the first five years of the commercial Internet. Then the largest backbones, UUNET and Sprint, set the price of bandwidth and determined conditions for connection to the Internet. But last week WorldCom announced that it was debranding mighty UUNET and Mike O'Dell, the chief architect of the Internet's largest global backbone, left the company. The problem is that these services take more and more resources to pay for ever larger routers and support huge growth rates in traffic. It is beginning to look like revenue derived from running such a facility may no longer match expenses as the availability of alternative sources of cheap bandwidth and Internet transit increases. For the largest backbones, sources of power only a year or two ago may now be turning into liabilities. The economics of bandwidth are in flux to such an extent that there is growing suspicion that for many large players business models that were sustainable five years ago have lead to the acquisition of huge debt today and that the next year may bring a round of major bankruptcies as the new economies of the technologies described in this report render traditional business models based on old technologies unsustainable. In the end the path of the Internet as the stupid network driven by these new technologies will predominate. We begin this six part report with a section on the basic Internet architecture and technologies of "Light, IP, and Gig E" to be followed by a section on their adoption in Sweden, Holland and of course our long special issue on Canada. February 2 2001 For Information on how to obtain the full report please go to http://cookreport.com/lightipgige.shtml -- **************************************************************** The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) cook@cookreport.com Index to 9 years of the COOK Report at http://cookreport.com Why ICANN is illegal. See 5 page version at http://cookreport.com/illegal.shtml and 168 page version at http://www.law.miami.edu/~froomkin/articles/icann.pdf **************************************************************** From owner-ietf-outbound Fri Feb 2 13:20:21 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA20060 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 13:20:03 -0500 (EST) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19726; Fri, 2 Feb 2001 13:15:07 -0500 (EST) Received: from ix.netcom.com (user-33qsdsc.dialup.mindspring.com [199.174.55.140]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA24003; Fri, 2 Feb 2001 13:15:00 -0500 (EST) Message-ID: <3A7B186F.C97D780D@ix.netcom.com> Date: Fri, 02 Feb 2001 12:28:32 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Lloyd and all, I am heartened to read your post and somewhat encouraged to see that other than myself and a very few others that someone has the courage to stand up for open discourse and free exchange of ideas on the IETF mailing lists. I for one agree with you that if filtering is needed by participants on any IETF mailing list it can be done on the participant level not through a moderator of any sort. Using a moderator is paramount to selective censorship. And any form of censorship is wrong.... Lloyd Wood wrote: > IETF mailing lists are intended for OPEN discussion; the benefits > (cross-pollination between lists, lack of inhibition about stating > your opinions) are widely recognised as outweighing widely-accepted > drawbacks (e.g. Peter Lewis advertising every forum everywhere he can > think of, allisat going on yet another hallucinogen-induced trip down > memory lane). > > midcom is not open. midcom should not be part of the IETF, much less a > working group. > > No, I don't care that having a moderator-in-the-middle filtering > everything is in the spirit of the midcom charter and must be for my > own good. I _really_ don't like the concept of an IETF-approved > poster to a mailing list on an IETF-run server. > > We can do our own filtering, if we choose to, and we don't need the > IETF to do it for us. Moderator approval of individual posters is > outside the spirit of RFC2418, and would require AD and IESG approval. > > What are we coming to? > > L. > > PGP > > ---------- Forwarded message ---------- > Date: Thu, 1 Feb 2001 11:00:40 -0500 (EST) > From: midcom-admin@ietf.org > To: l.wood@eim.surrey.ac.uk > Subject: Mail sent to midcom > > Your mail to 'midcom' with the subject: > > Re: [midcom] WG scope/deliverables > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Only approved posters may post without moderator approval. > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 112k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 From owner-ietf-outbound Fri Feb 2 13:21:54 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA20196 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 13:21:46 -0500 (EST) Received: from kestrel.prod.itd.earthlink.net (kestrel.prod.itd.earthlink.net [207.217.121.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18670 for ; Fri, 2 Feb 2001 12:56:42 -0500 (EST) Received: from [192.168.0.1] (sdn-ar-002njprinP330.dialsprint.net [158.252.31.108]) by kestrel.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id JAA09925 for ; Fri, 2 Feb 2001 09:56:38 -0800 (PST) Mime-Version: 1.0 X-Sender: cook@pop3.netaxs.com Message-Id: Date: Fri, 2 Feb 2001 12:55:58 -0500 To: ietf@ietf.org From: Gordon Cook Subject: Light, PI Gig E - 2001 Annual Report see http://cookreport.com/lightipgige.shtml Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org Light, IP and Gigabit Ethernet A Road Map for Evaluation of Technology Choices Driving the Future Evolution of Telecommunications - 2000 COOK Report Interviews - Introduction to the 6th in an annual series. Contrary to some opinions, the COOK Report finds that the Internet revolution is not spelled dot com. The revolution is in fact to be found in a total revamping of the transport of bits. While the dot com empires of 1999 collapsed in 2000 the cost effectiveness of pushing the Internet Protocol over glass yielded more dividends than ever before. A growing amount of telecom traffic has migrated to a growing amount of fiber. The pure Internet play throws out SONET effectively doubling available fiber in the case where redundant loops were used. Whereas lighting each new fiber used to call for new bays of OC-48 SONET equipment at perhaps $100,000 a bay and up, a strand can now be lit at a gigabit by a $7,000 Ethernet switch on each end. While gigabit Ethernet over glass is the current preferred Internet way, ten gigabit Ethernet transport will be arriving by year's end. If 40 lambdas per strand were high end in 2000, 160 is likely to be common by year's end. With the completion of multiple metro fiber build outs, end-to-end fiber may now be taken or granted by most business customers. The explosion of bandwidth as the result of more fiber and technology that squeezes more bandwidth from each strand has meant that, in some instances, the delivery of a gigabit costs about what a T-1 did a decade ago. The bottom line is that telecommunications which is prepared to forego traversing the legacy PSTN is now upwards of 1000 times cheaper than that which powers a circuit-switched voice call. While corporate managed VPNs have been able to avoid the PSTN for some time, a new development has emerged in Canada where customer management of optical wavelengths using the OBGP protocol holds the promise that by year's end users of Canada's new public sector gigabit Ethernet over fiber infrastructure will be avoiding carrier clouds entirely. At the basic levels of both transport and network management the Internet revolution is shaping up to tell the PSTN that it is no longer needed. In telephony meanwhile protocols are being developed that will allow the diversion of large amounts of PSTN traffic to the Internet. ENUM is the major such protocol. This will allow Internet carriers to offer and deliver many services to PSTN attached phones that the PSTN itself cannot negotiate. Other protocols such as instant messaging are shaping up as coordinators for PSTN activity and off on switches that can control Internet connected devices. Fiber to the home is becoming more common and companies like World Wide Packets are gearing up to make gigabit Ethernet termination equipment that will give connected families, telephone, fax, high end video, ordinary TV and data off of the same line. Canarie the Canadian advanced internet agency has some interesting ideas about these developments stating that Divergence rather than Convergence may be the key to low cost fiber to the home. Here is a narrative paraphrase of the language of a slide from the presentation 'Optical Communities' in September 2000. When people first started looking at Fiber to the Home (FTTH), they deemed it to be too expensive because it assumed all services would be converged - date, voice and video. They noted that expensive terminal equipment would be required to segregate voice, data and video services at the home. Meanwhile voice traffic has largely gone wireless. Note that lifeline voice can significantly increase system costs by demanding high reliability and depending for this on DC battery power, 911 services. Perhaps it is time to conclude that the big driver for residential broadband is not voice or video. It is the Internet. Very soon Internet will carry video and second line voice. So instead of building a converged network such as FSAN, HFC, etc build an Internet network only. Divergence rather than Convergence may be the key to low cost FTTH. While the power of the new systems is awesome, there are additional issues that will keep very interesting the life of anyone who must evaluate these changes and plan a winning strategy for the future. While one better be aware of the key differences in the power of the technology when compared to the circuit switched world's way of doing things, one also needs to understand that progress has, in this case, waded out into new and uncertain territory. There are some growth and scaling issues where the answers are not yet clearly understood. For example readers should consider Bill St. Arnaud's paper on scaling issues of Internet growth. < http://www.canet3.net/library/papers/scaling.html> If the suppositions in this paper prove to be correct, then the role of backbones will have to be rethought and much Internet topology rearranged. One of the developments that influenced his thinking occurred on December 4, 2000 when Essex Corp announced an advance that enabled it to push as many as 4,000 lambdas down a single strand of fiber. On December 8 St. Arnaud posted the following to his Canarie mail list. "[Here are some excerpts from a recent article in Lightreading that I believe illustrates the point that Ultra dense wave division multiplexing systems is not about bandwidth, but connectivity. A number of companies are starting to realize that today's Internet architecture (which is still fundamentally based on the old telco network model) will not scale. As intelligence moves to the edge, the existing network architecture must grow at some function related to the square of the number of users. However [the problem is what to do] if the increase in the number of the customer's own wavelengths and the fiber in the network only grows linearly? Intriguingly such a customer owned network architecture starts to closely resemble the neuron architecture of the brain. Perhaps mother nature long ago discovered the most efficient architecture for distributed intelligence? - BSA]" From the December 4, 2000 issue of Lightreading.... http://www.lightreading.com/document.asp?doc_id=2760 "We don't need thousands of wavelengths for bandwidth, we need it for connectivity," says Simon Cao, chief technology officer at Avanex Corp. (Nasdaq: AVNX), a company that's developing high channel-count wavelength systems. Cao figures that the availability of thousands of channels in combination with tunable lasers will make it possible to eliminate complex optical switches, by using wavelength routing instead . That idea is the driving force behind all of Avanex's developments, he says." "Despite its careless capacity talk, Essex has also thought out how to take advantage of the extra connectivity. Moodispaw reckons that Essex's solution will be perfect for customer-owned wavelengths in the access network. About 1 Gbit/s would be adequate to supply a gigabit Ethernet line to a business. Each customer pays less for its wavelength, but the service provider is able to sell to a lot more customers, so everybody is happy." What this means is that we likely soon see customer owned wavelengths of a gigabit. Such wavelengths will be plentiful, affordable and matched to the speeds of the Internet's basic gigabit Ethernet end-to-end architecture. When only the rich and mighty carriers owned fiber and the very expensive lasers that could pump bits and the even more expensive SONET equipment that sustained the bits, we imagined that bandwidth was a valuable commodity obtainable only from "on high," or from upstream. Indeed the carriers recognized their position and charged large sums for the scarce commodity that they delivered. This situation has dramatically changed. If you own a piece of fiber in a metro area network, you can power that fiber with a lambda delivered as gigabit Ethernet for a one time investment of about $15,000. When you run out of bandwidth, adding the multiplexer necessary to turn the one lambda into four is also affordable. In this sense bandwidth can now be generated by customers and used very cheaply at the edge of the network over hops that in ideal conditions can be as much as 100 kilometers. Suddenly these customers can throw cheap bandwidth at quality of service issues. Their whole outlook on life starts to change rapidly. George Gilder was observed to say that "the companies that exploit bandwidth recklessly, will win." On January 29, 2001 Bill St. Arnaud observed "Although I may disagree with Gilder on some of his predictions, I think he's gotten this one right. To date most advanced optical network research is based around the assumption that bandwidth is a precious and rare commodity and therefore we must optimize the network topology and try to extract every possible bit of capacity. One of the underlying assumptions of the existing CA*net 3 network and proposed CA*net 4 network architecture is that bandwidth can be wasted. Rather than concentrating on applications and technologies that optimize the use of bandwidth, we want to concentrate on applications and technologies that waste bandwidth but in doing so derive the maximum benefit for the user - hence our focus on "customer empowered" optical networks. There is no question in our mind with customer empowered networks that bandwidth will be wasted, wavelengths will be orphaned and seen from the perspective of a central carrier the network topology will be less than optimum. But in a world of thousands of wavelengths and near infinite bandwidth who cares? The true measure is whether the customer can easily and rapidly deploy new broadband applications and services." "At CANARIE we are initiating a number of projects with this premise in mind - OBGP which will allow customers to setup and tear down their own wavelengths at will, WDD- wavelength disk drives will drive new concepts in distributed super computing, object oriented networking enables the wavelength to become a software object, community based condominium fiber networks, and much, much more. Stay tuned for more announcements and developments in this area." Arnaud's words portend a seismic shift in the telecommunications landscape. With the exception of some important qualifiers we believe that he is correct. One must understand that, for the time being, bandwidth is cheap only in proportion to the distance that it must travel. Very high bandwidth sent over long distances is still quite expensive. Bandwidth that must be provided on a corporate wide scale for mission critical activities is also somewhat expensive. What Arnaud is talking about will change the world. The only question is how fast. To sum up. Costs are falling. Depending on the regulatory environment, the amount of capital necessary to become a small scale telecommunications provider is rapidly shrinking. Independent back yard gigabit Ethernet providers can deliver broadband services at a fraction of the cost but equal in quality to what is accessible from larger more traditional companies. There appears to be a choice of two paths to our telecom future. One is to go with the highly innovative pure Internet approach of gigabit Ethernet over condominium fiber. Such a choice empowers the customer, facilitates decentralization over centralized control and provides small and innovative businesses with the environment that they need in order to flourish. The other path is to try to fore stall the innovation by squashing competitors with a massive vertically integrated company founded on older technology and leveraging access to content and over a network monopoly so pervasive that people will find they have no choice but to buy it. What could be in store for us all, if things go in this direction, was summarized by Scott Cleland CEO of the Precursor Group on Friday January 19th, 2001. "Precursor believes AOL-TW has budding 'Microsoft-like' potential to grow increasingly dominant by being the leading national company that brings together the various online interfaces (content, Internet access, buddy lists, instant messaging, etc.) to become the de facto consumer online access market standard much like Microsoft Windows brought together the various desktop applications to become the de facto consumer software market standard." On the one hand, the AOL infrastructure, which, compared to what the Canadians are doing, can most kindly be called archaic, has to be a terribly attractive vision for the ILECs. After all, it will give them plenty of time to finish depreciation of their copper plant. On the other hand innovative Internet technology ventures have the most to gain from taking the Canadian road. To facilitate making this choice with more certainty, in this publication we offer a recapitulation of COOK Report interviews on the shifting market domain of the optical network. These interviews are unique in that they treat complex key technical issues with attention to depth and detail found no where else. We believe that they form a set of resources that will permit readers to decide for themselves what direction is most beneficial to the future of their enterprise. As we ponder these developments, we realize that we may be standing on the cusp of events that may overturn the economic structure of the first five years of the commercial Internet. Then the largest backbones, UUNET and Sprint, set the price of bandwidth and determined conditions for connection to the Internet. But last week WorldCom announced that it was debranding mighty UUNET and Mike O'Dell, the chief architect of the Internet's largest global backbone, left the company. The problem is that these services take more and more resources to pay for ever larger routers and support huge growth rates in traffic. It is beginning to look like revenue derived from running such a facility may no longer match expenses as the availability of alternative sources of cheap bandwidth and Internet transit increases. For the largest backbones, sources of power only a year or two ago may now be turning into liabilities. The economics of bandwidth are in flux to such an extent that there is growing suspicion that for many large players business models that were sustainable five years ago have lead to the acquisition of huge debt today and that the next year may bring a round of major bankruptcies as the new economies of the technologies described in this report render traditional business models based on old technologies unsustainable. In the end the path of the Internet as the stupid network driven by these new technologies will predominate. We begin this six part report with a section on the basic Internet architecture and technologies of "Light, IP, and Gig E" to be followed by a section on their adoption in Sweden, Holland and of course our long special issue on Canada. February 2 2001 For Information on how to obtain the full report please go to http://cookreport.com/lightipgige.shtml -- **************************************************************** The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) cook@cookreport.com Index to 9 years of the COOK Report at http://cookreport.com Why ICANN is illegal. See 5 page version at http://cookreport.com/illegal.shtml and 168 page version at http://www.law.miami.edu/~froomkin/articles/icann.pdf **************************************************************** From owner-ietf-outbound Fri Feb 2 13:30:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA20640 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 13:30:02 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20082 for ; Fri, 2 Feb 2001 13:20:14 -0500 (EST) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA14867; Fri, 2 Feb 2001 10:20:12 -0800 (PST) Message-ID: <3A7AFA48.7462BFBC@isi.edu> Date: Fri, 02 Feb 2001 10:19:52 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Rahmat M. Samik-Ibrahim" CC: ietf@ietf.org Subject: Re: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> <3A7956F7.1761708C@vlsm.org> <3A79A400.74B9E7E3@isi.edu> <3A79B1C2.B20E36DB@hursley.ibm.com> <3A79B38F.CE3A4E32@isi.edu> <3A7A928A.12FA96F@vlsm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Rahmat M. Samik-Ibrahim" wrote: > > Joe Touch wrote: > > >> IANA can't change the status of an STD - that's an IESG action. > >> If you think this matters, I would raise it with the latter. > > > Agreed. > > I was not aware that there was ever a proposed STD-1 I-D and/ > or last call. STDs are labels of existing standard RFCs which go through the usual procedure. From RFC1718, the Tao of the IETF: > To help clear up some confusion, there are now two special sub-series > within the RFCs: FYIs and STDs. The For Your Information RFC sub- > series was created to document overviews and topics which are > introductory. Frequently, FYIs are created by groups within the IETF > User Services Area. The STD RFC sub-series was created to identify > those RFCs which do in fact specify Internet standards. > Anyway, is it possible to declare (by whoever) > the http://www.iana.org/numbers.htm as STD-2? Or, perhaps a > mini RFC as STD-2 that informs where to get the current > numbers? The procedure would generally be to update RFC1700, resubmit it, and _then_ have STD-2 point to that new RFC. (something IANA would do) Alternately, or at least as an interim, the text in STD2 could include the URL. However, URLs are not considered "normative references", so it doesn't appear it would be appropriate to use just the URL as a persistent solution here. > I also believe that more information should be added into an > RFC: > - where to get an RFC > - where to get the recent status of an RFC As far as I know, the recent status is supposed to be at the top of the RFC. As to where to get them, that's already in rfc-index.txt (which is in the same directory as the RFCs): > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to: rfc-info@ISI.EDU > with the message body help: ways_to_get_rfcs. > > For example: > > To: rfc-info@ISI.EDU > Subject: getting rfcs > > help: ways_to_get_rfcs Joe From owner-ietf-outbound Fri Feb 2 14:00:14 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA22208 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 14:00:03 -0500 (EST) Received: from solidum.com (wirespeed.solidum.com [207.35.224.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20804 for ; Fri, 2 Feb 2001 13:31:41 -0500 (EST) Received: from research.solidum.com (phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id NAA29061 for ; Fri, 2 Feb 2001 13:31:42 -0500 Received: from phobos.solidum.com (phobos.solidum.com [127.0.0.1]) by research.solidum.com (8.11.0/8.11.0) with ESMTP id f12IUdZ29790 for ; Fri, 2 Feb 2001 13:30:39 -0500 (EST) Message-Id: <200102021830.f12IUdZ29790@research.solidum.com> To: ietf@ietf.org Subject: Re: Mail sent to midcom (fwd) In-Reply-To: Your message of "Thu, 01 Feb 2001 20:03:01 EST." <200102020103.UAA28638@astro.cs.utk.edu> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Date: Fri, 02 Feb 2001 13:30:39 -0500 From: Michael Richardson X-Loop: ietf@ietf.org >>>>> "Keith" == Keith Moore writes: >> I run many lists. They are now all restrict_post, but I always make >> a corresponding -nomail list. Both are managed by majordomo, but -nomail >> has defunct aliases. >> >> tcpdump-workers@tcpdump.org is like this, and receives daily posts >> from people reporting problems. Keith> if the list is set up right, people don't have to report such problems. Keith> the suspect messages go to the moderator; the moderator either approves The daily reports are about tcpdump, not about problems on the list. Keith> them or not based on whether they're on topic for the list. if they Keith> are, the moderator can add the poster's address to the list of those Keith> who can post withut moderation. That is *exactly* what happens. Keith> adding support for recognizing subaddresses just optimizes this Keith> process - the moderator doesn't have to deal with quite so many Yes. Many mailers do this. Mailman at IETF won't even let me subscribe with a subaddress, since it uses the SMTP From: to determine subscription. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ietf-outbound Fri Feb 2 15:00:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id PAA25065 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 15:00:03 -0500 (EST) Received: from smtp1.zocalo.net (smtp1.zocalo.net [157.22.1.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24766 for ; Fri, 2 Feb 2001 14:53:31 -0500 (EST) Received: from red.redback.com (66.161.131.zocalo.net [131.161.253.66] (may be forged)) by smtp1.zocalo.net (8.9.1/8.9.1) with ESMTP id LAA08142; Fri, 2 Feb 2001 11:53:28 -0800 (PST) Received: from red.redback.com by red.redback.com (8.9.3) id LAA57850; Fri, 2 Feb 2001 11:53:26 -0800 (PST) Message-Id: <200102021953.LAA57850@red.redback.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Keith Moore cc: ietf@ietf.org Subject: Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Thu, 01 Feb 2001 14:10:29 EST." <200102011910.OAA25096@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Feb 2001 11:53:26 -0800 From: Greg Minshall X-Loop: ietf@ietf.org Keith, > perhaps. but I note that for many of the examples you quoted, "dealing > with them" was not nearly as nice as "not having to deal with them". absolutely. i was very happy when we moved from the previous world to the (more or less pure) IP world. i will be very happy when we move from the NAT world to the (more or less pure) IPv6 world. Greg (who wrote email gateways in a past life) From owner-ietf-outbound Fri Feb 2 15:30:19 2001 Received: by ietf.org (8.9.1a/8.9.1a) id PAA26576 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 15:30:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26274; Fri, 2 Feb 2001 15:23:18 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA06524; Fri, 2 Feb 2001 15:23:11 -0500 (EST) Message-Id: <200102022023.PAA06524@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Melinda Shore" cc: L.Wood@eim.surrey.ac.uk, ietf@ietf.org, midcom-admin@ietf.org, poised@lists.tislabs.com Subject: Re: Mail sent to midcom (fwd) In-reply-to: Your message of "Thu, 01 Feb 2001 12:31:42 EST." <041a01c08c74$d800cd00$d45904d1@cisco.com> Date: Fri, 02 Feb 2001 15:23:11 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > > No, I don't care that having a moderator-in-the-middle filtering > > everything is in the spirit of the midcom charter and must be for my > > own good. I _really_ don't like the concept of an IETF-approved > > poster to a mailing list on an IETF-run server. > > Given how trivially easy it is to subscribe to midcom and > other IETF mailing lists I'm not sure that it's appropriate > to describe the filtering process as anything but completely > loose. you're missing the point. one shouldn't have to jump through extra hoops (even if they're trivial to jump through) just to contribute to a working group discussion. > I'm also not certain that I see the value in having > people who don't read a mailing list posting to it, but okay, > whatever. for midcom it's especially valuable, since a number of people in midcom seem to think that they have the right to redesign the architecture of the Internet. they definitely need clue inputs from elsewhere. Keith From owner-ietf-outbound Fri Feb 2 15:40:24 2001 Received: by ietf.org (8.9.1a/8.9.1a) id PAA27079 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 15:40:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27048; Fri, 2 Feb 2001 15:39:56 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA14886; Fri, 2 Feb 2001 12:39:08 -0800 (PST) Received: from spandex (rtp-vpn-177.cisco.com [10.82.192.177]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AEG11773; Fri, 2 Feb 2001 12:38:53 -0800 (PST) Message-ID: <009501c08d58$5bd07340$d45904d1@cisco.com> From: "Melinda Shore" To: "Keith Moore" Cc: , , , References: <200102022023.PAA06524@astro.cs.utk.edu> Subject: Re: Mail sent to midcom (fwd) Date: Fri, 2 Feb 2001 15:40:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > you're missing the point. one shouldn't have to jump through extra > hoops (even if they're trivial to jump through) just to contribute > to a working group discussion. Please note: one doesn't have to jump through hoops. At any rate, I've opened up the mailing list, not because the arguments here have been particularly (or even mildly) compelling but because the notification that's sent to people whose messages are being held for manual release is misleading and a tad obnoxious and it can't be edited by the list admin. Better to get rid of it completely. Melinda From owner-ietf-outbound Fri Feb 2 17:10:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA01762 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 17:10:03 -0500 (EST) Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01338 for ; Fri, 2 Feb 2001 17:01:05 -0500 (EST) Received: (qmail 27444 invoked from network); 2 Feb 2001 22:01:06 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 2 Feb 2001 22:01:06 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 02 Feb 2001 16:01:03 -0600 Message-ID: <3A7B2E0D.4AF653A0@nma.com> Date: Fri, 02 Feb 2001 14:00:45 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Greg Minshall CC: Keith Moore , ietf@ietf.org Subject: harbinger, Re: [midcom] WG scope/deliverables References: <200102021953.LAA57850@red.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Greg Minshall wrote: > absolutely. i was very happy when we moved from the previous world to the > (more or less pure) IP world. > > i will be very happy when we move from the NAT world to the (more or less > pure) IPv6 world. > > Greg (who wrote email gateways in a past life) I think that it is a truism that homogeneous networks are simpler. However, if this becomes "the" reason not to use heteregenous networks (and NATs), then we are denying the usefulness of local solutions to local problems. We are also restraing locally controlled growth and optimizations. Since it is also a truism that a local maximum (or, minimum) does not have to be a global maximum (or, minimum), then we see that a homogeneous network must not be the best global solution either. In other words, that is why the Net never was and resists being be a homogeneous network. It would be a less efficient design. Thus, we need to be able to cope with diversity, not try to iron it out. The NAT ugly duckling, the misfit to some, may well be a harbinger. Cheers, Ed Gerck From owner-ietf-outbound Fri Feb 2 17:30:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA02643 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 17:30:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02217 for ; Fri, 2 Feb 2001 17:21:55 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA07591; Fri, 2 Feb 2001 17:19:25 -0500 (EST) Message-Id: <200102022219.RAA07591@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ed Gerck cc: Greg Minshall , Keith Moore , ietf@ietf.org Subject: Re: harbinger, Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Fri, 02 Feb 2001 14:00:45 PST." <3A7B2E0D.4AF653A0@nma.com> Date: Fri, 02 Feb 2001 17:19:24 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org Ed, We agree that the net has never been entirely homogeneous, and that it would be a Bad Thing if people were forced to make their local nets conform to someone's idea of the Right Way to do their networks. Thus, I have few problems with folks who want to use NATs within their local networks and who understand and accept the limitations of that approach - even though, as you are fond of pointing out, this is an example of a local optimization that is sub-optimal for the global Internet community. OTOH, I have a big problem with constraining and/or encouraging folks to use NATs, while misleading folks about their limitations; and with attempts to make NATs a part of the Internet architecutre and thereby forcing everyone to accept those limitations. Thus we are objecting to much the same thing - not only the attempt to constrain what people can do with their local networks (e.g. preventing folks from getting global addresses) but also the attempt to constrain the kinds of software that people can deploy. Keith From owner-ietf-outbound Fri Feb 2 18:10:23 2001 Received: by ietf.org (8.9.1a/8.9.1a) id SAA04281 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 18:10:02 -0500 (EST) Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03932 for ; Fri, 2 Feb 2001 18:03:35 -0500 (EST) Received: (qmail 20369 invoked from network); 2 Feb 2001 23:03:37 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 2 Feb 2001 23:03:37 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 02 Feb 2001 17:03:34 -0600 Message-ID: <3A7B3CB5.C8406B9F@nma.com> Date: Fri, 02 Feb 2001 15:03:17 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Ed Gerck , Greg Minshall , ietf@ietf.org Subject: Re: harbinger, Re: [midcom] WG scope/deliverables References: <200102022219.RAA07591@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Keith Moore wrote: > Ed, > > We agree that the net has never been entirely homogeneous, and that it > would be a Bad Thing if people were forced to make their local nets > conform to someone's idea of the Right Way to do their networks. Yes. > Thus, I have few problems with folks who want to use NATs within their > local networks and who understand and accept the limitations of that > approach - even though, as you are fond of pointing out, this is an > example of a local optimization that is sub-optimal for the global > Internet community. If it would be imposed. But IMO it is, however, globally optimal for the Internet community to be able to solve their problems locally. > OTOH, I have a big problem with constraining and/or encouraging folks > to use NATs, while misleading folks about their limitations; misleading is always bad. > and with attempts to make NATs a part of the Internet architecutre and thereby > forcing everyone to accept those limitations. This is where we seem to diverge. IMO: (1) NATs are part of the Net archictecture and a harbinger, not an intrusion or a misfit; (2) everything has limitations, but having no choice is always the worse limitation. So, rather than following the "let a thousand standards bloom" dictum, I think that NATs (and similar approaches) are actually a way to provide for interoperation and reduce heterogeneity -- and its effect, which is isolation. Cheers, Ed Gerck From owner-ietf-outbound Fri Feb 2 18:20:13 2001 Received: by ietf.org (8.9.1a/8.9.1a) id SAA04594 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 18:20:02 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04027 for ; Fri, 2 Feb 2001 18:07:29 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Fri Feb 2 18:05:05 EST 2001 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Fri Feb 2 18:06:34 EST 2001 Received: from research.bell-labs.com (dhcp-6-173.pa.bell-labs.com [135.250.6.173]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAA24687 (AUTH gja); Fri, 2 Feb 2001 15:06:32 -0800 (PST) Message-ID: <3A7B3D65.3DE36F0B@research.bell-labs.com> Date: Fri, 02 Feb 2001 15:06:13 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: harbinger, Re: [midcom] WG scope/deliverables References: <200102021953.LAA57850@red.redback.com> <3A7B2E0D.4AF653A0@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Ed Gerck wrote: [..] > Thus, we need to be able to cope with > diversity, not try to iron it out. Depends why the diversity exists. Coping is the reaction of people who feel they cannot change the underlying causes. Apparently not everyone feels so powerless that NAT is their only answer. What you call "ironing out", others call "minimising the reasons for gratutitous diversity" cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-ietf-outbound Fri Feb 2 18:30:13 2001 Received: by ietf.org (8.9.1a/8.9.1a) id SAA04953 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 18:30:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04884 for ; Fri, 2 Feb 2001 18:28:42 -0500 (EST) Received: from DC-DESK.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA13609; Fri, 2 Feb 2001 15:28:44 -0800 Message-Id: <5.1.0.7.2.20010202150501.030fa008@dcrocker.songbird.com> X-Sender: dhc2@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Fri, 02 Feb 2001 15:16:36 -0800 To: ietf@ietf.org, poised@lists.tislabs.com From: Dave Crocker Subject: Re: Mail sent to midcom (fwd) In-Reply-To: References: <200102012108.QAA26209@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 10:12 AM 2/2/2001 -0500, James M Galvin wrote: >I called it illegal because a localpart should be opaque outside its >local environment. I tried to find a reference to this effect in some >standard but couldn't. It may just be "practiced wisdom" but I can not >remember a time when it wasn't true. MUST be opaque, not should be. Not only has it always been true, but it has usually caused problems when violated. The language in RFC822bis is definitive, though not as obnoxiously forceful as seems to be needed, to make the point for this thread: >>3.4.1. Addr-spec specification >>... >> >>The local-part portion is a domain dependent string. In addresses, it is >>simply interpreted on the particular host as a name of a particular >>mailbox. Firewalls and proxies are exceptions that I personally explain in terms of their being authorized on behalf of the "particular host". There is some operational fantasy to that explanation, given that the agents are typically operated by a different group than the ones running the email user software, but it is the real theory that such agent services work on. That it, such agents are part of a common administrative domain which authorizes their messing with the data. Stray relays and services that are out it the great beyond of the general Internet are NOT so authorized. They are MUCH more likely to interpret the local-part incorrectly d/ From owner-ietf-outbound Fri Feb 2 18:40:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id SAA05325 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 18:40:04 -0500 (EST) Received: from comp3 (cust.64-52-42.078.ip.eurekaeast.net [64.52.42.78]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04994 for ; Fri, 2 Feb 2001 18:31:11 -0500 (EST) Message-Id: <200102022331.SAA04994@ietf.org> From: "a friend" To: Subject: WOW! Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Fri, 2 Feb 2001 18:31:47 X-Loop: ietf@ietf.org ASCOT CASINO www.ascotcasino.com WILL GIVE YOU $20 FOR EVERY $100 UP TO A MAXIMUM OF $500 YOU DEPOSIT AND PLAY- VIDEO SLOTS, & PAYDAY SLOTS, ROULETTE, MINI BACARRAT, VIDEO POKER, PAI GOW AND CYBER STUD . -OR- PLAY BLACKJACK 400 TIMES IN ONE SESSION This offer remains valid during the month of February 2001 only and expires on the 1st March 2001 From owner-ietf-outbound Fri Feb 2 19:40:19 2001 Received: by ietf.org (8.9.1a/8.9.1a) id TAA07282 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 19:40:02 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07088 for ; Fri, 2 Feb 2001 19:39:21 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f130dKU18637; Fri, 2 Feb 2001 16:39:20 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id AAA05263; Sat, 3 Feb 2001 00:39:20 GMT Date: Sat, 3 Feb 2001 00:39:20 GMT Message-Id: <200102030039.AAA05263@gra.isi.edu> To: minshall@redback.com, egerck@nma.com Subject: Re: harbinger, Re: [midcom] WG scope/deliverables Cc: moore@cs.utk.edu, ietf@ietf.org X-Sun-Charset: US-ASCII X-Loop: ietf@ietf.org *> *> In other words, that is why the Net never was and resists being be a homogeneous *> network. It would be a less efficient design. But the lesson of the Internet is that efficiency is not the primary consideration. Ability to grow and adapt to changing requirements is the primary consideration. This makes simplicity and uniformity very precious indeed. Bob Braden From owner-ietf-outbound Fri Feb 2 19:50:20 2001 Received: by ietf.org (8.9.1a/8.9.1a) id TAA07474 for ietf-outbound.10@ietf.org; Fri, 2 Feb 2001 19:50:02 -0500 (EST) Received: from sean.ebone.net (IDENT:postfix@sean.ebone.net [195.158.227.211]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07388 for ; Fri, 2 Feb 2001 19:46:22 -0500 (EST) Received: by sean.ebone.net (Postfix, from userid 1113) id 10584817; Sat, 3 Feb 2001 01:46:23 +0100 (CET) To: ietf@ietf.org Subject: "redesign[ing] the architecture of the Internet" Message-Id: <20010203004623.10584817@sean.ebone.net> Date: Sat, 3 Feb 2001 01:46:23 +0100 (CET) From: smd@ebone.net (Sean Doran) X-Loop: ietf@ietf.org N.B.: I trimmed this: | From: Keith Moore | To: "Melinda Shore" | Cc: L.Wood@eim.surrey.ac.uk, ietf@ietf.org, midcom-admin@ietf.org, | poised@lists.tislabs.com | Subject: Re: Mail sent to midcom (fwd) | Sender: owner-poised@lists.tislabs.com Down to this: ietf@ietf.org Keith Moore asserts: | for midcom it's especially valuable, since a number of people in | midcom seem to think that they have the right to redesign the | architecture of the Internet. they definitely need clue inputs | from elsewhere. Keith, who does have the right to redesign the architecture of the Internet, and under what circumstances? This is a serious question. Sean. From owner-ietf-outbound Sat Feb 3 00:10:26 2001 Received: by ietf.org (8.9.1a/8.9.1a) id AAA15643 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 00:10:04 -0500 (EST) Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15531 for ; Sat, 3 Feb 2001 00:01:37 -0500 (EST) Received: (qmail 18881 invoked from network); 3 Feb 2001 05:01:39 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 3 Feb 2001 05:01:39 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 02 Feb 2001 23:01:35 -0600 Message-ID: <3A7B908E.DD528AB4@nma.com> Date: Fri, 02 Feb 2001 21:01:02 -0800 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Braden CC: minshall@redback.com, egerck@nma.com, moore@cs.utk.edu, ietf@ietf.org Subject: Re: harbinger, Re: [midcom] WG scope/deliverables References: <200102030039.AAA05263@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Bob Braden wrote: > *> > *> In other words, that is why the Net never was and resists being be a homogeneous > *> network. It would be a less efficient design. > > But the lesson of the Internet is that efficiency is not the primary > consideration. Ability to grow and adapt to changing requirements is > the primary consideration. This makes simplicity and uniformity > very precious indeed. Is this now a semantic discussion? Ok, if you want to go than that slope, what I call "efficient design" of course includes "to grow and adapt to changing requirements," "simplicity" and "uniformity". Because "efficient" is all these and more -- efficient is "productive without waste" (Webster). BTW, a design that is too simple is not efficient, because it wastes resources and does not allow what could otherwise be possible. This is the other side of Ockham's razor, when all possibilities are tried in order to find the best one, not just the simplest one. Cheers, Ed Gerck > > > Bob Braden From owner-ietf-outbound Sat Feb 3 00:20:18 2001 Received: by ietf.org (8.9.1a/8.9.1a) id AAA15999 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 00:20:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15861 for ; Sat, 3 Feb 2001 00:12:16 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA11619; Sat, 3 Feb 2001 00:12:05 -0500 (EST) Message-Id: <200102030512.AAA11619@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: smd@EBONE.NET (Sean Doran) cc: ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" In-reply-to: Your message of "Sat, 03 Feb 2001 01:46:23 +0100." <20010203004623.10584817@sean.ebone.net> Date: Sat, 03 Feb 2001 00:12:05 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Keith, who does have the right to redesign the architecture > of the Internet, and under what circumstances? > > This is a serious question. and it deserves a serious answer. To make fundamental changes to the architecture of the Internet would affect a great many people with widely varying interests. Such an effort would therefore need to be done slowly and deliberately, with broad input, a great deal of care in its management, sound technical foundation, a design team or teams of *very* talented people to evaluate multiple approaches according to previously-established criteria, with iterated review and feedback from a wide variety of interests. In short, it would need to try to get at least rough consensus from the whole technical community. The IPv6 effort tried to approximate this idealized process. It was a painful struggle. A lot of people weren't happy with the result, and hardly anyone is happy with all of the result. But at least there was an attempt to get broad input, consider a variety of approaches, and to craft a compromise that served the needs of a wide range of interests. If we had to do another thing like this we might handle it better based on what we learned last time around. But most of us hope we won't have to do something else like this anytime soon. As for the circumstances, we'd have to have a shared realization either that the old architecture could no longer serve our needs (such as we had with IPv4) or that a new architecture would be so far superior to the old one that it would be worth the pain of development and transition. Contrast this with the kind of effort (and there have been a few things like this in recent years, so I'm not singling anyone out in particular) that says "we'll just tweak this one thing here to solve our immediate problem" even though this tweak creates problems for other interests who aren't represneted in the working group. Keith From owner-ietf-outbound Sat Feb 3 00:30:11 2001 Received: by ietf.org (8.9.1a/8.9.1a) id AAA16562 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 00:30:03 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15964 for ; Sat, 3 Feb 2001 00:19:23 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA11689; Sat, 3 Feb 2001 00:16:47 -0500 (EST) Message-Id: <200102030516.AAA11689@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ed Gerck cc: moore@cs.utk.edu, ietf@ietf.org Subject: Re: harbinger, Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Fri, 02 Feb 2001 21:01:02 PST." <3A7B908E.DD528AB4@nma.com> Date: Sat, 03 Feb 2001 00:16:47 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > BTW, a design that is too simple is not efficient, because it wastes > resources and does not allow what could otherwise be possible. granted that there is such a thing as too simple an answer for most design problems... but one can waste resources and be inflexible much more easily by making a design too complex than by making it too simple. moreover, the limitations of a too-simple design are usually much easier to identify and correct than those of a too-complex design. Keith From owner-ietf-outbound Sat Feb 3 02:10:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id CAA25223 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 02:10:02 -0500 (EST) Received: from ns1.vrx.net (ns1.vrx.net [216.13.76.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24967 for ; Sat, 3 Feb 2001 02:04:27 -0500 (EST) Received: from [192.168.1.14] (dsl0029.netquest.net [206.117.109.29]) by ns1.vrx.net (Postfix) with ESMTP id 006BFD20C for ; Sat, 3 Feb 2001 02:04:26 -0500 (EST) Mime-Version: 1.0 X-Sender: 50398.stef@mail.nma.com Message-Id: In-Reply-To: <200102030516.AAA11689@astro.cs.utk.edu> References: <200102030516.AAA11689@astro.cs.utk.edu> Date: Fri, 2 Feb 2001 23:04:25 -0800 To: ietf@ietf.org From: Einar Stefferud Subject: Re: harbinger, Re: [midcom] WG scope/deliverables Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Loop: ietf@ietf.org I too was a strong advocate and strongly disapproved of LANs that were not openly connected with full capabilities to the net, until I had my own home system and discovered that I had no interest in being totally visible and accessible at all times, especially when I was not always around to monitor things. So, now I am very happy behind my little XRouter NAT box, with an ISP service out there where I can have a login shell if I wish. But I do not find any need for a shell account and so do not have one, as long as I have POP or IMAP for my EMail, and an ISP that does not block any of my desired DNS destinations. Lets me sleep well! Without hiring a security staff;-)... But, I also note that I choose this because it is good for me locally, not because I cannot get an IP number for some reason. So, much of this argument appears to be based on the simple fact that IP numbers are scare, and so some companies have chosen to go along with NATS when they have no other reason than the shortage of available IP numbers. If so, then that is the problem to solve and leave those of us who want NATS alone in our happiness;-)... Even with IPV6, I would stay the way I am. In short, not everyone really wants their Internet to be totally homogeneous! Cheers...\Stef At 00:16 -0500 03/02/01, Keith Moore wrote: > > BTW, a design that is too simple is not efficient, because it wastes > > resources and does not allow what could otherwise be possible. > >granted that there is such a thing as too simple an answer for >most design problems... but one can waste resources and be inflexible >much more easily by making a design too complex than by making it too >simple. moreover, the limitations of a too-simple design are usually >much easier to identify and correct than those of a too-complex design. > >Keith From owner-ietf-outbound Sat Feb 3 13:32:33 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA07846 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 13:30:02 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07607 for ; Sat, 3 Feb 2001 13:21:45 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA16874; Sat, 3 Feb 2001 10:21:29 -0800 (PST) Received: from pipsqueak (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id f13ILGp23938; Sat, 3 Feb 2001 10:21:16 -0800 (PST) Message-ID: <001601c08e0e$645ee1c0$3690130a@pipsqueak> From: "Eliot Lear" To: "Keith Moore" Cc: References: <20010203004623.10584817@sean.ebone.net> <200102030512.AAA11619.23964@astro.cs.utk.edu> Subject: Re: "redesign[ing] the architecture of the Internet" Date: Sat, 3 Feb 2001 10:23:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > > Keith, who does have the right to redesign the architecture > > of the Internet, and under what circumstances? > > > > This is a serious question. > > and it deserves a serious answer. While I don't agree with Keith's phrasing or use of the word "right", I do believe it boils down to a question I'd like to ask (and answer) in response: How does the IETF assert authority to cause changes? It does so through technical merit. In as much as most of the standards have technical merit, people will view the IETF as an authority. We degrade that authority when we allow stupid things through the standards process or when we make statements that are excessively obvious or wrong to the Internet community (for some definition of community). I don't doubt for a second that each and every AD understands this, and takes his or her role quite seriously. A scalable attainable (or better yet - demonstrable) technical vision is an important part of the IETF's credibility, and our standards process is built around it. Such power should not be underestimated. Even so, we as an organization have NO claim on the future of the "Internet Architecture", whatever that is. A small group individuals with a cute idea can have dramatic impact, no matter what the IETF thinks. Witness WWW and NAT. Eliot From owner-ietf-outbound Sat Feb 3 13:51:25 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA08313 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 13:50:03 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08290 for ; Sat, 3 Feb 2001 13:49:59 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Sat Feb 3 13:48:11 EST 2001 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Sat Feb 3 13:48:11 EST 2001 Received: from research.bell-labs.com (ex-vpn64.pa.bell-labs.com [135.250.1.64]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAA25123 (AUTH gja); Sat, 3 Feb 2001 10:48:10 -0800 (PST) Message-ID: <3A7C52E0.D664B815@research.bell-labs.com> Date: Sat, 03 Feb 2001 10:50:08 -0800 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: NAT isn't a firewall Re: harbinger, Re: [midcom] WG scope/deliverables References: <200102030516.AAA11689@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Einar Stefferud wrote: [..] > had my own home system and discovered that I had no interest in being > totally visible and accessible at all times, especially when I was > not always around to monitor things. > > So, now I am very happy behind my little XRouter NAT box, with an ISP > service out there where I can have a login shell if I wish. NAT doesn't primarily provide security, a firewall does. A firewall doesn't have to do NAT. If you dont mind the number of IP addresses you get from your ISP, install a smart firewall and ditch the NAT box (or twiddle some config options in your Xrouter... whatever) [..] > But, I also note that I choose this because it is good for me > locally, not because I cannot get an IP number for some reason. You need a firewall. This isn't immediately relevant to a discussion about the architectural implications of, or reasons for, NAT. > So, much of this argument appears to be based on the simple fact that > IP numbers are scare, and so some companies have chosen to go along > with NATS when they have no other reason than the shortage of > available IP numbers. > > If so, then that is the problem to solve and leave those of us who > want NATS alone in our happiness;-)... Even with IPV6, I would stay > the way I am. With IPv6 I would hope you'd still want a firewall on your home connection. But that's not NAT. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-ietf-outbound Sat Feb 3 14:21:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA09137 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 14:20:02 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09019 for ; Sat, 3 Feb 2001 14:12:06 -0500 (EST) Received: from DC-DESK.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA29316 for ; Sat, 3 Feb 2001 11:12:07 -0800 Message-Id: <5.1.0.7.2.20010203105812.02ec6d98@dcrocker.songbird.com> X-Sender: dhc2@dcrocker.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.0.7 (Beta) Date: Sat, 03 Feb 2001 10:59:19 -0800 To: ietf@ietf.org From: Dave Crocker Subject: Re: "redesign[ing] the architecture of the Internet" In-Reply-To: <200102030512.AAA11619@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org >The IPv6 effort tried to approximate this idealized process. It >was a painful struggle. A lot of people weren't happy with the result, >and hardly anyone is happy with all of the result. But at least and, in fact, the "architectural" changes were relatively minor. that should make the possibility of major architectural changes all the more intimidating. d/ From owner-ietf-outbound Sat Feb 3 15:30:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id PAA10822 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 15:30:02 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10799 for ; Sat, 3 Feb 2001 15:28:19 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01606; Sat, 3 Feb 2001 12:28:03 -0800 (PST) Received: from localhost.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AGA02170; Sat, 3 Feb 2001 12:27:48 -0800 (PST) Received: by localhost.cisco.com (Postfix, from userid 500) id F121B18992; Sat, 3 Feb 2001 15:27:52 -0500 (EST) Date: Sat, 3 Feb 2001 15:27:52 -0500 From: Scott Brim To: Grenville Armitage Cc: ietf@ietf.org Subject: Re: NAT isn't a firewall Re: harbinger, Re: [midcom] WG scope/deliverables Message-ID: <20010203152752.A2124@localhost.co-nectschools.net> Mail-Followup-To: Scott Brim , Grenville Armitage , ietf@ietf.org References: <200102030516.AAA11689@astro.cs.utk.edu> <3A7C52E0.D664B815@research.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A7C52E0.D664B815@research.bell-labs.com>; from gja@research.bell-labs.com on Sat, Feb 03, 2001 at 10:50:08AM -0800 X-Loop: ietf@ietf.org On Sat, Feb 03, 2001 at 10:50:08AM -0800, Grenville Armitage wrote: > > > Einar Stefferud wrote: > [..] > > had my own home system and discovered that I had no interest in being > > totally visible and accessible at all times, especially when I was > > not always around to monitor things. > > > > So, now I am very happy behind my little XRouter NAT box, with an ISP > > service out there where I can have a login shell if I wish. > > NAT doesn't primarily provide security, a firewall does. A firewall > doesn't have to do NAT. If you dont mind the number of IP addresses > you get from your ISP, install a smart firewall and ditch the NAT > box (or twiddle some config options in your Xrouter... whatever) Although address obfuscation through combining NAT with your firewall can provide a small amount of additional security. ...Scott From owner-ietf-outbound Sat Feb 3 17:20:24 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA12968 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 17:20:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12915 for ; Sat, 3 Feb 2001 17:10:56 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA16110; Sat, 3 Feb 2001 17:10:55 -0500 (EST) Message-Id: <200102032210.RAA16110@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eliot Lear" cc: "Keith Moore" , ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" In-reply-to: Your message of "Sat, 03 Feb 2001 10:23:22 PST." <001601c08e0e$645ee1c0$3690130a@pipsqueak> Date: Sat, 03 Feb 2001 17:10:54 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Even so, we as an organization have NO claim on the future of the "Internet > Architecture", whatever that is. I strongly disagree. IETF essentially "owns" the Internet Protocol specification and has change control over it. > A small group individuals with a cute idea can have dramatic impact, > no matter what the IETF thinks. Witness WWW and NAT. no argument that such a group can have "dramatic impact" (for good or ill) but that's not the same thing as changing the architecture. a bomb can have a dramatic impact on a building also. but when a building is bombed, we don't use the word "architecture" to refer to the rubble. Keith From owner-ietf-outbound Sat Feb 3 19:10:24 2001 Received: by ietf.org (8.9.1a/8.9.1a) id TAA15257 for ietf-outbound.10@ietf.org; Sat, 3 Feb 2001 19:10:03 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15058 for ; Sat, 3 Feb 2001 19:02:04 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.2/8.11.2) id f14023V07977 for ietf@ietf.org env-from ; Sat, 3 Feb 2001 17:02:03 -0700 (MST) Date: Sat, 3 Feb 2001 17:02:03 -0700 (MST) From: Vernon Schryver Message-Id: <200102040002.f14023V07977@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" X-Loop: ietf@ietf.org > From: Keith Moore > > Even so, we as an organization have NO claim on the future of the "Internet > > Architecture", whatever that is. > > I strongly disagree. IETF essentially "owns" the Internet Protocol > specification and has change control over it. If you have "change control" over something and I change it, then things happen. First my changes are backed-out. Second, I'll be yelled at, removed from the access list, demoted, and/or fired. The legal wrangling between Sun and Microsoft is a demonstration of what happens when one real world outfit violates the change control of another. If a rogue IETF WG or cabal of commercial developers violates the "change control" of the IETF on IP, what happens? Does Fred Baker remove names from an access list at venera.isi.edu? > > A small group individuals with a cute idea can have dramatic impact, > > no matter what the IETF thinks. Witness WWW and NAT. > > no argument that such a group can have "dramatic impact" (for good > or ill) but that's not the same thing as changing the architecture. > > a bomb can have a dramatic impact on a building also. but when a > building is bombed, we don't use the word "architecture" to refer > to the rubble. When I filter the evocative words from that, it seems to support Mr. Lear's point. A minority inside or outside the IETF group can affect things. As Mr. Lear said, the only "change control" of the IETF over the supposed "architecture of the Internet" comes from virtues of the IETF's work, not copyrights, contracts, laws, CVS access control lists, or mission statements. If official "Network Architecture" were such a good thing, the various GOSIP's would have been followed, and we wouldn't have this Internet mess. Among my pet peeves is inflating self- or group-importance with the word "architecture." Talk about "the architecture of the Internet" is as hollow as "implementing TCP/IP" among those who unpack and install things. The Internet has a shape. Much of that shape was intended, but at least as much just happened. Calling the shape of the Internet "architecture" as opposed to the results of a bomb is at least optimistic and arguably obviously wrong. If the Internet has an architecture, then what are those NAT boxes and redirecting proxies? Where is the ECO that authorized the world wide web? The HTTP RFCs are archeology and triage, not engineering change orders to change the architecture. Appealing to the change control that the IAB has over the architecture of the Internet is a bad way to deal with rogue groups, whether inside or outside IETF. If it were good, we'd have TP1 instead of IPv6, since that was the Architectural Decision of the IAB. Far better is to ensure that the consequences of the rogue (or any) group's plan are understood widely and early, and then let the intellectual and commercial markets decide. (but that does not mean that the IETF gets to review all documents and monitor all discussions.) In other words and contrary to some recent complaints, it's good to publicize the problems in the notion of NAT as it has evolved. Thanks in part to Keith Moore's efforts, the part of the public that prattles "implement web a server" to mean "configure Apache" instead of "write Apache" is beginning to get a glimmer that NAT boxes might not be wonderful cornucopias of IP addresses that also provide perfect security. The best way to deal with the next error is not to outlaw discussion of it or even to require that its advocates meet in public (because you can't), but to think and talk about it. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Sun Feb 4 00:50:30 2001 Received: by ietf.org (8.9.1a/8.9.1a) id AAA11724 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 00:50:03 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11701 for ; Sun, 4 Feb 2001 00:47:59 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.2/8.11.2) id f145lxe12839 for ietf@ietf.org env-from ; Sat, 3 Feb 2001 22:47:59 -0700 (MST) Date: Sat, 3 Feb 2001 22:47:59 -0700 (MST) From: Vernon Schryver Message-Id: <200102040547.f145lxe12839@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" X-Loop: ietf@ietf.org > From: Keith Moore > ... The IETF, through the processes > defined in 2026 and other documents, has change control. ... Ok, then let's revoke the changes made in the Pacific Northwest to the purely IETF protocol, PPP, starting with MS-CHAP and DNS-in-LCP. Others can offer other examples of changes to purely IETF protocols from the same and other industry leading vendors that bypassed the IETF's change control and that many of us agree should be reconsidered. I support the jihad against NAT boxes (although there are much worse such as redirecting proxies). However, advocating or hoping to deal with NAT or anything else by appealing to the IETF's change control authority is worse than a distraction, because people outside The Standards Process see it as obviously silly and useless. People remember that the IETF started as a finger in the eye of the folks who had de jure and de facto change control for network protocols and Architecture. The only real change control of the IETF or any standards outfit is the ability to offer something somehow, not necessarily technically better. Pointing out an evil must be only a preamble to describing a better alternative, or those who say they are "implementing NAT" will quite rightly continue pointing and clicking their way through GUI's. Discouraging the use of a bad thing without offering an alternative is not just a waste of time, but a "crying of wolf" that reduces the IETF's ability to control change. I guess the fix for NAT is IPv6, so let's all drink to 128 bits but let's *please* not worry about the change control authority that exists only among standards committees. Vernon Schryver vjs@rhyolite.com From owner-ietf-outbound Sun Feb 4 02:00:39 2001 Received: by ietf.org (8.9.1a/8.9.1a) id CAA18647 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 02:00:04 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18208 for ; Sun, 4 Feb 2001 01:55:06 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id BAA21326; Sun, 4 Feb 2001 01:54:57 -0500 (EST) Message-Id: <200102040654.BAA21326@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vernon Schryver cc: ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" In-reply-to: Your message of "Sat, 03 Feb 2001 22:47:59 MST." <200102040547.f145lxe12839@calcite.rhyolite.com> Date: Sun, 04 Feb 2001 01:54:57 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > However, advocating or hoping to deal with NAT > or anything else by appealing to the IETF's change control authority is > worse than a distraction, because people outside The Standards Process > see it as obviously silly and useless. yes but I was making that argument to folks who *are* inside the IETF, rather than to folks on the outside. I agree with you that most vendors don't give a d*mn about who has change control over the internet standards...most feel quite free to abuse them (and harm interoperability) at the whim of a marketroid. NATs are a good example of this, but hardly the only one. Keith From owner-ietf-outbound Sun Feb 4 12:11:01 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA09733 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 12:10:02 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09659 for ; Sun, 4 Feb 2001 12:07:10 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id SAA12084; Sun, 4 Feb 2001 18:06:36 +0100 Message-Id: <4.3.2.7.2.20010204075916.0b58aeb8@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Feb 2001 08:01:55 -0800 To: "Rahmat M. Samik-Ibrahim" , ietf@ietf.org From: Harald Alvestrand Subject: Re: FAQ: The IETF+Censored list In-Reply-To: <3A78CD5B.4525CCE4@vlsm.org> References: <200102010015.BAA18532@dokka.maxware.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ietf@ietf.org At 09:43 01/02/2001 +0700, Rahmat M. Samik-Ibrahim wrote: >Harald Tveit Alvestrand wrote: > > > The IETF+Censored mailing list > >I believe that that message itself does not comply >BCP-45/RFC-3005. The "inappropriate" list from that document includes: > - Unsolicited bulk e-mail > - Discussion of subjects unrelated to IETF policy, meetings, > activities, or technical concerns > - Unprofessional commentary, regardless of the general subject > - Announcements of conferences, events, or activities that are not > sponsored or endorsed by the Internet Society or IETF. Which of those categories do you think it falls under? > Furthermore, the filter itself is somehow >out-of-date. > >http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters > >May I be listed in that filter anyway :^)? requests to be added are routinely denied by the administrator .-) -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-outbound Sun Feb 4 12:30:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA09943 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 12:30:03 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09920 for ; Sun, 4 Feb 2001 12:29:22 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 4 Feb 2001 17:29:11 +0000 To: Scott Brim cc: Grenville Armitage , ietf@ietf.org Subject: Re: NAT isn't a firewall Re: harbinger, Re: [midcom] WG scope/deliverables In-reply-to: Your message of "Sat, 03 Feb 2001 15:27:52 EST." <20010203152752.A2124@localhost.co-nectschools.net> Date: Sun, 04 Feb 2001 17:29:09 +0000 Message-ID: <1904.981307749@cs.ucl.ac.uk> From: Jon Crowcroft X-Loop: ietf@ietf.org In message <20010203152752.A2124@localhost.co-nectschools.net>, Scott Brim type d: >>Although address obfuscation through combining NAT with your firewall >>can provide a small amount of additional security. against which attacks ? it doesnt provide better privacy, or non repudation, or access control, or any normal service that one would regard as an enhancement of security - in fact, having one address shared by multiple host s means there are less things an attacker needs to remember :-) cheers jon From owner-ietf-outbound Sun Feb 4 13:00:15 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA10269 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 13:00:02 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10199 for ; Sun, 4 Feb 2001 12:54:39 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA28726; Sun, 4 Feb 2001 09:54:26 -0800 (PST) Received: from localhost.localdomain.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with ESMTP id AGA03727; Sun, 4 Feb 2001 09:54:08 -0800 (PST) X-Mailer: emacs 20.7.1 (via feedmail 8 I); VM 6.90 under Emacs 20.7.1 Sender: sbrim@cisco.com From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14973.38719.135775.569633@localhost.localdomain> Date: Sun, 4 Feb 2001 12:54:07 -0500 To: Jon Crowcroft Cc: Grenville Armitage , ietf@ietf.org Subject: Re: NAT isn't a firewall Re: harbinger, Re: [midcom] WG scope/deliverables In-Reply-To: <1904.981307749@cs.ucl.ac.uk> References: <20010203152752.A2124@localhost.co-nectschools.net> <1904.981307749@cs.ucl.ac.uk> Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Jon, this is a nit, two digressions off the main thread, so I'll take it off-list. More mail soon. ...Scott On 4 Feb 2001 at 17:29 +0000, Jon Crowcroft apparently wrote: > > In message <20010203152752.A2124@localhost.co-nectschools.net>, Scott Brim type > d: > >>Although address obfuscation through combining NAT with your firewall > >>can provide a small amount of additional security. > > > against which attacks ? it doesnt provide better privacy, or non > repudation, or access control, or any normal service that one would > regard as an enhancement of security - in fact, having one address > shared by multiple host s means there are less things an attacker > needs to remember :-) > > > cheers > > jon From owner-ietf-outbound Sun Feb 4 13:10:12 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA10394 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 13:10:02 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10295 for ; Sun, 4 Feb 2001 13:01:01 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA06075; Sun, 4 Feb 2001 10:00:28 -0800 (PST) Received: from pipsqueak (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id f14I0OX23199; Sun, 4 Feb 2001 10:00:25 -0800 (PST) Message-ID: <002f01c08ed4$a2972800$3690130a@pipsqueak> From: "Eliot Lear" To: "Keith Moore" Cc: References: <001601c08e0e$645ee1c0$3690130a@pipsqueak> <200102032210.RAA16110.11403@astro.cs.utk.edu> Subject: Re: "redesign[ing] the architecture of the Internet" Date: Sun, 4 Feb 2001 10:02:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit > I strongly disagree. IETF essentially "owns" the Internet Protocol > specification and has change control over it. Well, I still disagree, but at least you've taken a step in the right direction by being more specific. Internet Architecture is an amorphous blob. > > A small group individuals with a cute idea can have dramatic impact, > > no matter what the IETF thinks. Witness WWW and NAT. > > no argument that such a group can have "dramatic impact" (for good > or ill) but that's not the same thing as changing the architecture. Today we have transparent proxies, reverse caches, global DNS redirectors, and all sorts of other amusing Things. You can say they're not part of the architecture. But what does it mean? They're there because the functionality needs to be there and otherwise wasn't. The same could be said about NATs, as bad as they are. Remember Ritchie's famous quote, "you can fill a void and it could still suck"? The fact is X is here as opposed to something better. Did the people at MIT have the right to write X??? From owner-ietf-outbound Sun Feb 4 16:00:49 2001 Received: by ietf.org (8.9.1a/8.9.1a) id QAA11526 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 16:00:02 -0500 (EST) Received: from www.lightreading.com ([64.55.104.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11499 for ; Sun, 4 Feb 2001 15:59:48 -0500 (EST) Received: from mail pickup service by www.lightreading.com with Microsoft SMTPSVC; Sun, 4 Feb 2001 16:10:58 -0500 From: "Light Reading Registrant" To: "Jeff Goldblum" Subject: Welcome to Light Reading Message-ID: X-OriginalArrivalTime: 04 Feb 2001 21:10:58.0133 (UTC) FILETIME=[F80CE850:01C08EEE] Date: 4 Feb 2001 16:10:58 -0500 X-Loop: ietf@ietf.org Thank you for taking the time to register for Light Reading. This memo is to confirm that the email address you are registered under is ietf@ietf.org If you would like to tell other people about our site, we've made it easy for you to spread the word, on http://lightreading.com/register/refer.asp We are committed to keeping you up to date with optical networking developments around the world by providing ground-breaking news and in-depth analysis, with the occasional touch of humour. Please feel free to contact us on editors@lightreading.com if you have suggestions for improving our web site or newsletter, or comments about what we're already doing. If you want to cancel your registration to Light Reading at any time, please forward this message to unsubscribe@lightreading.com: From owner-ietf-outbound Sun Feb 4 17:20:45 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA12236 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 17:20:02 -0500 (EST) Received: from cisco.com (peridot.cisco.com [171.69.18.72]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12122 for ; Sun, 4 Feb 2001 17:10:11 -0500 (EST) Received: from earthlink.net ([10.21.172.156]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA12617; Sun, 4 Feb 2001 14:09:38 -0800 (PST) Message-ID: <3A7DA78E.60CCD415@earthlink.net> Date: Sun, 04 Feb 2001 14:03:42 -0500 From: Peter Deutsch in Mountain View X-Mailer: Mozilla 4.08 [en] (Win95; I) MIME-Version: 1.0 To: Keith Moore CC: ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" References: <200102030512.AAA11619@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit g'day, Keith Moore wrote: . . . > To make fundamental changes to the architecture of the Internet would > affect a great many people with widely varying interests. Such an > effort would therefore need to be done slowly and deliberately, with > broad input, a great deal of care in its management, sound technical > foundation, a design team or teams of *very* talented people to > evaluate multiple approaches according to previously-established > criteria, with iterated review and feedback from a wide variety of > interests. In short, it would need to try to get at least rough > consensus from the whole technical community. Okay, I now I've gotten that out of my system, I encourage you to read the "Yes, Minister" and "Yes, Prime Minister" books that arose from the BBC series of the same names. The authors brilliantly skewered the sometimes overwhelming pomposity of both the British Civil Service and the British Political Class who seek to manipulate the system to their own, sometimes even benevolent, ends. Of particular relevance would be any one of the several explanations offered up by Sir Humphrey Appleby as to what the Civil Service would do to any idea that they regarded as "too brave" or "radical". I'm sure that if I spent five minutes leafing through my now somewhat tattered copies I'd find passages that were completely in sympathy with yours. Keith, you lived through the OSI Wars, the explosion of the Web and the exponential growth of the past 15 years. To now write about things being "done slowly and deliberately" suggests that you missed something here. The "Internet Architecture" didn't spring full blown from the brow of a collective benevolent elite, and the role of the IETF today isn't to preserve this legacy for all time against the infidels. It's to continue the good work that got us here. If the IETF really were to slow down as much as your message seems to indicate you want it to would simply doom the organization to irrelevance. Fortunately, there is little evidence that the group is following your lead on this, but this is getting a little tiresome. > The IPv6 effort tried to approximate this idealized process. It > was a painful struggle. A lot of people weren't happy with the result, > and hardly anyone is happy with all of the result. But at least > there was an attempt to get broad input, consider a variety of > approaches, and to craft a compromise that served the needs of a > wide range of interests. Oh, and by the way - so far, it hasn't solved the problem it was designed for (because it hasn't been widely adopted), is poorly understood by people who should be using it and the market has supplied a host of competing, sometimes crusty (and yes sometimes downright ugly) alternatives to some subsets of the problem. This is what we have to look forward to, if we can save "the architecture" from NATs? BTW, the above sentiment is *NOT* intended as a slight on the many smart people who put a lot of effort into IPv6. I just want to caution you that your "slow and deliberate" process wont necessarily get you where you want to go. Sadly, the real world moves too fast, and people will tend to do what they feel is in their own best interests. Your goal should be to harnass that energy for good. You don't do that by fiat or commandment. You've fought the good fight against NATs. Unfortunately, you lost. Perhaps this is due in some small part because your fundamental approach has been to claim omnipotence for the IETF (or, as you put it "for IETF", what's with the missing article, anyways??). You chastize the apostates, attempt to abrogate concepts by exercising a non-existant moral authority supposedly due the IETF because of its past successes and heck, now you even claim that the IETF "essentially 'owns' the Internet Protocol specification and has change control over it". Wow... As if the IETF can or should attempt to maintain its technical leadership role by hiding behind intellectual property or patent law. Boy, has anyone around here read "Animal Farm" lately? "Four Layers Good, Seven Layers Better", anyone?? . . . > Contrast this with the kind of effort (and there have been a few > things like this in recent years, so I'm not singling anyone out in > particular) that says "we'll just tweak this one thing here to solve > our immediate problem" even though this tweak creates problems for > other interests who aren't represneted in the working group. The bottom line is that the "IETF way" was a success more because it embraced just such Darwinian Selection than because it embraced the measured, slow-paced path to architectual purity you now advocate. Nobody likes *all* of the somewhat interesting, if architecturally implausible, organisms sometimes thrown up for consideration by the Darwinian process. But only *some* people hate the fact that it lead to humanity (and thus, IP! :-) Keith, you really should trust the process a lot more than you do... - peterd -- -------------------------------------------------------------------------------- Peter Deutsch work email: pdeutsch@cisco.com Director of Engineering private : pdeutsch@earthlink.net Content Networking Business Unit Cisco Systems "So finally Hacker proposed what Appleby had always proposed: namely, that they start by creating equal opportunities for both women and blacks. In the recruitment grades. And they drew up terms of reference for an interdepartmental committee to report on methods of choosing the right individuals to be civil servants, to report four years hence. By which time Hacker would certainly no longer be the Minister." - "Yes, Minister", pg. 373 Jonathan Lynn & Anthony Jay ISBN: 0 563 20665 9 -------------------------------------------------------------------------------- From owner-ietf-outbound Sun Feb 4 17:30:06 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA12377 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 17:30:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12207 for ; Sun, 4 Feb 2001 17:16:46 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA26782; Sun, 4 Feb 2001 17:16:33 -0500 (EST) Message-Id: <200102042216.RAA26782@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Eliot Lear" cc: "Keith Moore" , ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" In-reply-to: Your message of "Sun, 04 Feb 2001 10:02:26 PST." <002f01c08ed4$a2972800$3690130a@pipsqueak> Date: Sun, 04 Feb 2001 17:16:33 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org > Today we have transparent proxies, reverse caches, global DNS redirectors, > and all sorts of other amusing Things. You can say they're not part of the > architecture. But what does it mean? They're there because the > functionality needs to be there and otherwise wasn't. The same could be > said about NATs, as bad as they are. Remember Ritchie's famous quote, "you > can fill a void and it could still suck"? The fact is X is here as opposed > to something better. no argument about that. so now that these things are here and we understand their deficiencies, let's work on something better! Keith From owner-ietf-outbound Sun Feb 4 18:10:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id SAA12826 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 18:10:02 -0500 (EST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12780 for ; Sun, 4 Feb 2001 18:05:32 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA27245; Sun, 4 Feb 2001 18:05:26 -0500 (EST) Message-Id: <200102042305.SAA27245@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Peter Deutsch in Mountain View cc: Keith Moore , ietf@ietf.org Subject: Re: "redesign[ing] the architecture of the Internet" In-reply-to: Your message of "Sun, 04 Feb 2001 14:03:42 EST." <3A7DA78E.60CCD415@earthlink.net> Date: Sun, 04 Feb 2001 18:05:26 -0500 Sender: moore@cs.utk.edu X-Loop: ietf@ietf.org Peter, It does often seem to be the case that poorly designed short-term solutions to problems are adopted before well-designed things that work well in the long-term, particularly when the long-term solutions come with a greater transition cost. NATs made more sense than IPv6 for a certain subset of popular applications meeting certain criteria; the error was in people assuming (or being misled) that these were the only applications of interest. Now people are proposing solutions to the NAT problems which are more complex than IPv6, at a time when IPv6 is becoming available "off the shelf". The "fight" isn't "over" because the Internet continues to grow, and to evolve quite rapidly and probably will continue to do so for quite some time. Neither NAT nor IPv6 (as we know it now) will be the terminal state. And while I would be the first to admit that the entire Internet suite of protocols didn't spring fully formed from Athena's head, neither do I buy an argument that assumes that everything worthwhile occurs organically and that natural selection in the marketplace is the only force that matters. A great deal of the success of the Internet is due to some good solid design in IP and TCP. These did not crop up at random, and they did not come from a private vendor; and they proved superior to competing technologies from both vendors and ISO. And if for example OSI had won instead of TCP it is difficult to imagine how the web would have succeeded under such conditions. In the physical world, bridges are designed, not discovered. It requires substantial investment and usually inconvenience to build them; they don't just happen by accident. But when a bridge gets too weak or the traffic load gets too large for it, we don't argue that the bridge is as Nature intended. Instead, we build a better bridge. Keith From owner-ietf-outbound Sun Feb 4 20:50:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id UAA13792 for ietf-outbound.10@ietf.org; Sun, 4 Feb 2001 20:50:02 -0500 (EST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13747 for ; Sun, 4 Feb 2001 20:42:42 -0500 (EST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA11638 for ; Mon, 5 Feb 2001 10:42:38 +0900 (JST) To: ietf@ietf.org Subject: IETF50 event social register page X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Mon, 05 Feb 2001 10:42:38 +0900 Message-ID: <11636.981337358@coconut.itojun.org> Sender: itojun@itojun.org X-Loop: ietf@ietf.org http://www.lucent-ietf.com/registration.html the webpage is silent about if the credit card information gets sent securely, or insecurely. in fact, it gets sent securely over https (Submit button points to an URL starts with "https"). it would be better if there's some mention about it, otherwise people will start yell about this :-) itojun From owner-ietf-outbound Mon Feb 5 00:10:30 2001 Received: by ietf.org (8.9.1a/8.9.1a) id AAA17557 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 00:10:04 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17458 for ; Mon, 5 Feb 2001 00:04:14 -0500 (EST) Received: (from braden@localhost) by boreas.isi.edu (8.9.3/8.9.3) id VAA22783; Sun, 4 Feb 2001 21:04:04 -0800 (PST) Date: Sun, 4 Feb 2001 21:04:04 -0800 (PST) From: Bob Braden Message-Id: <200102050504.VAA22783@boreas.isi.edu> To: moore@cs.utk.edu, pdeutsch@earthlink.net Subject: Re: "redesign[ing] the architecture of the Internet" Cc: ietf@ietf.org X-Sun-Charset: US-ASCII X-Loop: ietf@ietf.org *> *> Keith, you lived through the OSI Wars, the explosion of the Web and the *> exponential growth of the past 15 years. To now write about things being *> "done slowly and deliberately" suggests that you missed something here. *> The "Internet Architecture" didn't spring full blown from the brow of a *> collective benevolent elite, and the role of the IETF today isn't to You have one thing right... it wasn't "collective" in the modern IETF sense. Otherwise, this discussion seems to bear little relationship to the actual background history of Internet development. Not that the actual history is particularly relevant to today... Bob Braden From owner-ietf-outbound Mon Feb 5 01:50:12 2001 Received: by ietf.org (8.9.1a/8.9.1a) id BAA23791 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 01:50:02 -0500 (EST) Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23094 for ; Mon, 5 Feb 2001 01:45:22 -0500 (EST) Received: from caplin.cs.ui.ac.id (caplin.cs.ui.ac.id [152.118.36.9]) by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id OAA22598 for ; Mon, 5 Feb 2001 14:05:50 +0700 Received: from rmsbase.vlsm.org (IDENT:root@rmsbase.acad.cs.ui.ac.id [152.118.26.15]) by caplin.cs.ui.ac.id (8.9.3/8.9.3) with ESMTP id NAA19480 for ; Mon, 5 Feb 2001 13:49:58 +0700 (JAVT) Received: from vlsm.org (IDENT:rms46@rmsbase.vlsm.org [152.118.26.15]) by rmsbase.vlsm.org (8.9.3/8.8.7) with ESMTP id NAA01038; Mon, 5 Feb 2001 13:46:14 +0700 Sender: rms46@VLSM.ORG Message-ID: <3A7E4C36.3C8D2C31@vlsm.org> Date: Mon, 05 Feb 2001 13:46:14 +0700 From: "Rahmat M. Samik-Ibrahim" Organization: VLSM-TJT X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> <3A7956F7.1761708C@vlsm.org> <3A79A400.74B9E7E3@isi.edu> <3A79B1C2.B20E36DB@hursley.ibm.com> <3A79B38F.CE3A4E32@isi.edu> <3A7A928A.12FA96F@vlsm.org> <3A7AFA48.7462BFBC@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Joe Touch wrote: >> I was not aware that there was ever a proposed STD-1 I-D and/ >> or last call. > STDs are labels of existing standard RFCs which go through > the usual procedure. But, neither I was aware that there was ever an I-D and/or a last call for RFC-2600 or RFC-2700. >> Anyway, is it possible to declare (by whoever) >> the http://www.iana.org/numbers.htm as STD-2? Or, perhaps a >> mini RFC as STD-2 that informs where to get the current >> numbers? > The procedure would generally be to update RFC1700, > resubmit it, and _then_ have STD-2 point to that new RFC. > (something IANA would do) I believe this is a problem. Accurate information exists, but it can not be published because it is not in a traditional RFC format :-(. > As far as I know, the recent status is supposed to be > at the top of the RFC. > As to where to get them, that's already in rfc-index.txt > (which is in the same directory as the RFCs): Unfortunately, it is not so obvious (especially for the one who has no idea about the RFC-Editor mechanism) that rfc-index.txt exists. regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Good bye hegemony - http://sapi.vlsm.org/DLL/linuxrouter From owner-ietf-outbound Mon Feb 5 02:21:26 2001 Received: by ietf.org (8.9.1a/8.9.1a) id CAA01852 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 02:20:02 -0500 (EST) Received: from nettaxi.com (ts004d39.lap-ca.concentric.net [64.1.211.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01790 for ; Mon, 5 Feb 2001 02:13:19 -0500 (EST) Date: Mon, 5 Feb 2001 02:13:19 -0500 (EST) From: Benefitsall@nettaxi.com Message-Id: <200102050713.CAA01790@ietf.org> Reply-To: Benefitsall@nettaxi.com To: ietf@ietf.org Subject: BenefitsAll X-Loop: ietf@ietf.org Dear Friend Sorry to impose, but we got your name from an Internet search of venture capital contacts. I am sure you get these requests all the time...YES, we are ANOTHER "Dot Com " company. We are called BenefitsAll. Can you help us, or lead us in the right direction, to investors, or help us to get the word out ? Our site is up, running and being "soft marketed". Our results are quite impressive. We have hundreds of retailer partners and member/shoppers signed up. We also have dozens of organizations who have signed up with us and all with WITH NO ADVERTISING. At this point we have a small dedicated staff and a highly professional board of advisors from various industries. Our staff and advisors have helped us achieve goals we would have never thought possible. We completed our business plan a few months back and are only now today 2/5/01) presenting it to investors. We wanted to make sure we had a workable concept before we asked others to risk their money. Our Business plan is available upon request. Below is a quick summary. Call or email us for more information. Our phone # is 818 707 1723. Ask for Donn Delson at ext 4# Company Overview BA is an online fundraising site that will link nonprofit organizations and their members with major online retailers, wherein they can shop and earn rebates. BA will retain 35 percent of the rebate given by the retailer as the nonprofits' shop online. BA's goal is to create a portal that will bring shopping traffic from the site to the retailers. The demographic value of this traffic will eventually create a secondary revenue stream from advertisers. Founders Donn Delson and Robert Breines strongly believe in this concept. Rather than selling a product, carrying inventory, and shipping it, BA intends to carry minimal overhead. Instead it will be the "Black Box" intermediary that will provide a service, charge a small percentage fee for each transaction, and is the conduit for these transactions. Once the software is developed, the majority of expenses will be devoted to sales and marketing. Delson and Breines feel so strongly that they have chosen to invest the initial seed capital to build, test and validate the working model before asking others to invest. Industry Analysis and Competition The universe of online shopping rebate sites consists or about 12 companies, of which the majority are focused on schools exclusively. One of these incorporates schools and charities and a few target charities only. There is one site that caters to religious organizations and none to the knowledge of BA that targets civic/arts, service organizations and clubs. None offer the winning combination of high rebates, depth of retailers, ability to change and channel contributions. One of the challenges for BA will be to build awareness of its uniqueness as the only site that serves the broad spectrum of organizations. Competitive Edge BA starts with a critical competitive edge: there is no competitor known to us that can claim to afford the user the almost limitless choice of beneficiaries for their online shopping rebates. Each time a consumer or business agent shops through the BenefitsAll site they can choose which organization they desire to benefit from the rebate earned. Furthermore, BA offers significantly more merchant choices than any other site, with more than 350 retailers versus 250 for the next closest competitor. It promotes the availability of rebates up to 30 percent of purchase price, compared to a high of 20 percent from the next closest competitor. BA has experienced positive initial success. To realize its growth goals, BA requires additional capital to fully implement its advertising and promotional efforts, develop brand awareness, secure new organizations, and to build awareness and regular use by their membership. Thank you in advance for your consideration. Please contact us for the full plan that we can email and or discuss with you personally From owner-ietf-outbound Mon Feb 5 08:40:49 2001 Received: by ietf.org (8.9.1a/8.9.1a) id IAA05187 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 08:40:02 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05140 for ; Mon, 5 Feb 2001 08:36:05 -0500 (EST) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14Plgr-0003Dh-00; Mon, 05 Feb 2001 13:28:21 +0000 Date: Mon, 5 Feb 2001 13:28:19 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Keith Moore cc: Ed Gerck , ietf@ietf.org Subject: Re: harbinger, Re: [midcom] WG scope/deliverables In-Reply-To: <200102030516.AAA11689@astro.cs.utk.edu> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: ietf@ietf.org On Sat, 3 Feb 2001, Keith Moore wrote: > > BTW, a design that is too simple is not efficient, because it wastes > > resources and does not allow what could otherwise be possible. > > granted that there is such a thing as too simple an answer for > most design problems... but one can waste resources and be inflexible > much more easily by making a design too complex than by making it too > simple. moreover, the limitations of a too-simple design are usually > much easier to identify and correct than those of a too-complex design. and by the time you've corrected most of the limitations of the too-simple design, you've got your too-complex design anyway. witness the ever-more-complex TCP, the world's most baroque sliding-window protocol. L. PGP From owner-ietf-outbound Mon Feb 5 09:40:13 2001 Received: by ietf.org (8.9.1a/8.9.1a) id JAA06931 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 09:40:02 -0500 (EST) Received: from c014.sfo.cp.net (c014-h008.c014.sfo.cp.net [209.228.12.72]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06777 for ; Mon, 5 Feb 2001 09:32:16 -0500 (EST) From: narakamath@lightel.com Received: (cpmta 21137 invoked from network); 5 Feb 2001 06:31:45 -0800 Date: 5 Feb 2001 06:31:45 -0800 Message-ID: <20010205143145.21136.cpmta@c014.sfo.cp.net> X-Sent: 5 Feb 2001 14:31:45 GMT Received: from [165.247.117.147] by mail.lightel.com with HTTP; 05 Feb 2001 06:31:45 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: moore@cs.utk.edu Cc: pdeutsch@earthlink.net, moore@cs.utk.edu, ietf@ietf.org X-Mailer: Web Mail 3.8.1.2 Subject: Re: "redesign[ing] the architecture of the Internet" X-Loop: ietf@ietf.org Keith, I couldn't agree with you more. I don't have all the previous debates on top of my head, but we have to be careful that we dont make a mess out of something good, namely TCP/IP. TCP/IP is the 'sliced bread' of the Internet. Also, I think ATM will die a lingering death notwithstanding the support of ATM by erstwhile monopoly carriers. Advances like IP Over SONET and IP switching will kill ATM. Nara From owner-ietf-outbound Mon Feb 5 12:20:19 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA12269 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 12:20:02 -0500 (EST) Received: from web9105.mail.yahoo.com (web9105.mail.yahoo.com [216.136.128.242]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12176 for ; Mon, 5 Feb 2001 12:15:17 -0500 (EST) Message-ID: <20010205171511.74488.qmail@web9105.mail.yahoo.com> Received: from [216.79.62.80] by web9105.mail.yahoo.com; Mon, 05 Feb 2001 09:15:11 PST Date: Mon, 5 Feb 2001 09:15:11 -0800 (PST) From: Kevin Farley Reply-To: sixdrift@yahoo.com Subject: Re: NAT ... again To: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org First I have to say that this thread has been an amusing source of analogies (some from myself). I laughed... I cried... it has to be a best seller. I now ask the question again: if NAT stinks, where's the air freshener? And the corollary question: if IPv6 is the answer, where's the beef? Kevin Farley __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-ietf-outbound Mon Feb 5 13:20:19 2001 Received: by ietf.org (8.9.1a/8.9.1a) id NAA13409 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 13:20:02 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13374 for ; Mon, 5 Feb 2001 13:18:28 -0500 (EST) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA25645; Mon, 5 Feb 2001 10:18:21 -0800 (PST) Message-ID: <3A7EEE65.B06324FF@isi.edu> Date: Mon, 05 Feb 2001 10:18:13 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Rahmat M. Samik-Ibrahim" CC: ietf@ietf.org Subject: Re: STD-2 is obsolete References: <200101312118.QAA15700@astro.cs.utk.edu> <3A789A3E.63620B61@nma.com> <3A7901DF.441EB775@isi.edu> <3A7956F7.1761708C@vlsm.org> <3A79A400.74B9E7E3@isi.edu> <3A79B1C2.B20E36DB@hursley.ibm.com> <3A79B38F.CE3A4E32@isi.edu> <3A7A928A.12FA96F@vlsm.org> <3A7AFA48.7462BFBC@isi.edu> <3A7E4C36.3C8D2C31@vlsm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit "Rahmat M. Samik-Ibrahim" wrote: > > Joe Touch wrote: > > >> I was not aware that there was ever a proposed STD-1 I-D and/ > >> or last call. > > > STDs are labels of existing standard RFCs which go through > > the usual procedure. > > But, neither I was aware that there was ever an I-D and/or a > last call for RFC-2600 or RFC-2700. RFC2026 indicates that there are some RFCs, notably STD1, which are reissued periodically, and it isn't clear that this goes back through the draft procedure. Assigned numbers, by its own description, is a snapshot of an ongoing process. The fact that it was accepted as an RFC implies that it ncan and should be updated periodicaly. Finally, the document itself declares that the current values for the assigned numbers are NOT in the document, but rather in a file at the following address: > The files in this directory document the currently assigned values for > several series of numbers used in network protocol implementations. > > ftp://ftp.isi.edu/in-notes/iana/assignments -- > >> Anyway, is it possible to declare (by whoever) > >> the http://www.iana.org/numbers.htm as STD-2? Or, perhaps a > >> mini RFC as STD-2 that informs where to get the current > >> numbers? The 'mini RFC' is already in STD-2, FWIW. > > As to where to get them, that's already in rfc-index.txt > > (which is in the same directory as the RFCs): > > Unfortunately, it is not so obvious (especially for the one who > has no idea about the RFC-Editor mechanism) that rfc-index.txt > exists. Search engines are your friend in this case. A quick search on Google points, first shot, to the RFC-Editor, which indicates the index: http://www.rfc-editor.org/ The IETF's RFC pages also contain a link to that RFC: http://www.ietf.org/rfc.html Joe From owner-ietf-outbound Mon Feb 5 14:00:18 2001 Received: by ietf.org (8.9.1a/8.9.1a) id OAA14507 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 14:00:02 -0500 (EST) Received: from dalexc02.drtn.corp (exchange.datareturn.com [216.46.242.254]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14353 for ; Mon, 5 Feb 2001 13:53:21 -0500 (EST) Received: by DALEXC02 with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 12:53:06 -0600 Message-ID: <72B2F584B912D41198E500508B0CCDFF03B9AF27@DALEXCH01> From: Stevan Pierce To: "Nanog (E-mail)" , "IETF (E-mail)" Subject: MTU Settings Date: Mon, 5 Feb 2001 12:53:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org I am looking for the various MTU settings for different types of lines. I have the general settings that come inside TCP/IP Illustrated, but would like to find other tables. Also, how big is a packet that is encrypted with IPSec? (Assuming that we are not counting the payload.) Stevan From owner-ietf-outbound Mon Feb 5 16:11:03 2001 Received: by ietf.org (8.9.1a/8.9.1a) id QAA17552 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 16:10:02 -0500 (EST) Received: from e2emsx.endtoend.com ([207.219.115.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17474 for ; Mon, 5 Feb 2001 16:07:41 -0500 (EST) Received: by E2EMSX.ENDTOEND.COM with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 16:02:49 -0500 Message-ID: From: Dave Robinson To: ietf@ietf.org Subject: RFC 2260 Date: Mon, 5 Feb 2001 16:02:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-Loop: ietf@ietf.org Has anyone out there found ISP's who will support RFC 2260 section 5.2? From owner-ietf-outbound Mon Feb 5 16:40:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id QAA18296 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 16:40:02 -0500 (EST) Received: from foo-bar-baz.cc.vt.edu (IDENT:root@foo-bar-baz.cc.vt.edu [128.173.14.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18098 for ; Mon, 5 Feb 2001 16:30:09 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from foo-bar-baz.cc.vt.edu (IDENT:valdis@localhost.localdomain [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.11.0/8.11.0) with ESMTP id f15LU7V27897; Mon, 5 Feb 2001 16:30:08 -0500 Message-Id: <200102052130.f15LU7V27897@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4+dev To: Dave Robinson Cc: ietf@ietf.org Subject: Re: RFC 2260 In-Reply-To: Your message of "Mon, 05 Feb 2001 16:02:48 EST." X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1242174669P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 05 Feb 2001 16:30:07 -0500 X-Loop: ietf@ietf.org --==_Exmh_-1242174669P Content-Type: text/plain; charset=us-ascii On Mon, 05 Feb 2001 16:02:48 EST, Dave Robinson said: > Has anyone out there found ISP's who will support RFC 2260 section > 5.2? The NANOG@merit.edu list would probably be a better place to ask.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1242174669P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOn8bX3At5Vm009ewEQKXOgCgu/f3Bfg8zAZJ+RaZB4D65InKO7gAoMkM fFNejSe1m8NOOKi5JOyteEkl =jo4g -----END PGP SIGNATURE----- --==_Exmh_-1242174669P-- From owner-ietf-outbound Mon Feb 5 17:10:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA18879 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 17:10:01 -0500 (EST) Received: from web11506.mail.yahoo.com (web11506.mail.yahoo.com [216.136.172.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18800 for ; Mon, 5 Feb 2001 17:07:03 -0500 (EST) Message-ID: <20010205220703.35744.qmail@web11506.mail.yahoo.com> Received: from [207.173.224.6] by web11506.mail.yahoo.com; Mon, 05 Feb 2001 14:07:03 PST Date: Mon, 5 Feb 2001 14:07:03 -0800 (PST) From: ME Subject: Point to Multipoint To: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Does anyone know where I can get information regarding (ATM Backbone) Point to Multipoint provisioning. __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-ietf-outbound Mon Feb 5 21:00:22 2001 Received: by ietf.org (8.9.1a/8.9.1a) id VAA22039 for ietf-outbound.10@ietf.org; Mon, 5 Feb 2001 21:00:02 -0500 (EST) Received: from alpha.prbusiness.net (alpha.prbusiness.net [64.209.68.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22012 for ; Mon, 5 Feb 2001 20:54:28 -0500 (EST) Received: from SPAMTOP (unverified [64.50.112.2]) by alpha.prbusiness.net (Vircom SMTPRS 4.3.183) with ESMTP id ; Mon, 5 Feb 2001 17:56:30 -0800 Message-ID: <000401c08fe0$1953ea30$c801a8c0@Oware.net> Reply-To: "Jasen G. Strutt" From: "Jasen G. Strutt" To: , "ME" References: <20010205220703.35744.qmail@web11506.mail.yahoo.com> Subject: Re: Point to Multipoint Date: Mon, 5 Feb 2001 17:57:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Dorado Software Inc. www.doradosoftware.com End to end provisioning with their Access product and a wealth of information. Regards- ----- Original Message ----- From: "ME" To: Sent: Monday, February 05, 2001 2:07 PM Subject: Point to Multipoint > Does anyone know where I can get information regarding > (ATM Backbone) Point to Multipoint provisioning. > > __________________________________________________ > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > From owner-ietf-outbound Tue Feb 6 09:30:21 2001 Received: by ietf.org (8.9.1a/8.9.1a) id JAA15143 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 09:30:03 -0500 (EST) Received: from china.kw.com.cn ([159.226.25.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15031 for ; Tue, 6 Feb 2001 09:27:31 -0500 (EST) Received: by china.kw.com.cn (Postfix, from userid 639) id 2DB8039EA3; Tue, 06 Feb 2001 22:30:06 +0800 (CST) To: ietf@ietf.org Subject: An alternative to TCP (part 1) Message-Id: <20010206143006.2DB8039EA3@china.kw.com.cn> Date: Tue, 06 Feb 2001 22:30:06 +0800 (CST) From: jag@kw.com.cn (Jun'an Gao) X-Loop: ietf@ietf.org Motivations 1. There are two annoying incompetence of TCP. One is that TCP does not distinguish packet loss caused by network transmission error from that caused by network congestion. The congestion control and avoidance mechanism makes TCP drop its transmit window upon detecting a packet loss, thus lowers the transmit rate even if the loss is caused by physical link transmit error. This results in an unnecessary reduction in link bandwidth utilization, especially in the environment of wireless physical links. The other is that the unit of TCP sequence number is byte (octet) while the the sequence number is only 32 bit wide. It is not a big problem for a no-more-than-100Mbps network. But in a modern gigabit network, it takes only about 36 seconds to consume the whole sequence number space when transmitting at the maximum bit rate. 2. There is an observation that congestion control is somewhat the obligation of routing system. If it were to be done by the end host, an end host application might exploit UDP to avoid the congestion control of TCP. In fact the video stream applications have caused some network congestion troubles. 3. Abundant IPv6 addresses, especially the 64 bit interface ID space, makes transport layer multiplexing is somewhat unnecessary. IPv6 has the built-in support for multiple simultaneous addresses. It further recalls the necessity of transport layer multiplexing. And quite a number of users (would?) prefer a new IP address in each new connection, for the sake of anonymity. 4. There is no checksum field in the IPv6 fixed header. The designers of IPv6 count on link layer and transport layer error check and/or correction mechanism to ensure data transmit reliability. So transport layer should somehow enhance the error check and/or correction mechanism. Besides, the IPv6 authentication header provides a much stronger data integrity check mechanism than traditional TCP/IP checksum. A new transport protocol should try to take advantage of AH. 5. Some applications such as stream media or interactive TVs do not require reliability that TCP provides, but need to preserve data transmission order and the connection state for a considerable duration of packet exchange or transmission. 6. Doing traffic shaping at the network edge is better than on the host node for the sake of application programming. Key Points 1. Designed for IPv6. Free of constraint bestowed by IPv4. 2. No upper layer port as in TCP. 3. There may be a number of IPv6 addresses for a physical server, each address is bound to one (and only one) logical network service. The services could be registered appropriately. 4. Each time the client end initiates a new connection it will allocate a new IPv6 address. The allocation may be done randomly, providing client anonymity. 5. Receiver-Urged retransmission. 6. Inherit some basic mechanism and some enhancement of TCP, namely: -- Piggybacking. -- Three-way handshaking during connection setup phase in normal mode. -- Initial Sequence Number selection method, which guarantee crash recovery. -- Graceful simplex connection close, with modification to avoid FIN-WAIT2 deadlock. -- Explicit congestion notification, now the mandatory congestion control and avoidance mechanism. -- Accumulative acknowledgement. -- Selective acknowledgement. 7. Integrated with IPv6 AH. Managed to take account of features provided by ISAKMP, RSVP and MPLS. Most importantly, Admission Control and Traffic Shaping are to be integrated in the near future. From owner-ietf-outbound Tue Feb 6 10:10:14 2001 Received: by ietf.org (8.9.1a/8.9.1a) id KAA17034 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 10:10:02 -0500 (EST) Received: from foo-bar-baz.cc.vt.edu (IDENT:root@foo-bar-baz.cc.vt.edu [128.173.14.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16428 for ; Tue, 6 Feb 2001 09:58:18 -0500 (EST) From: Valdis.Kletnieks@vt.edu Received: from foo-bar-baz.cc.vt.edu (IDENT:valdis@localhost.localdomain [127.0.0.1]) by foo-bar-baz.cc.vt.edu (8.11.0/8.11.0) with ESMTP id f16Ew0V05311; Tue, 6 Feb 2001 09:58:00 -0500 Message-Id: <200102061458.f16Ew0V05311@foo-bar-baz.cc.vt.edu> X-Mailer: exmh version 2.3.1 01/19/2001 with nmh-1.0.4+dev To: jag@kw.com.cn (Jun'an Gao) Cc: ietf@ietf.org Subject: Re: An alternative to TCP (part 1) In-Reply-To: Your message of "Tue, 06 Feb 2001 22:30:06 CST." <20010206143006.2DB8039EA3@china.kw.com.cn> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_391846488P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 06 Feb 2001 09:58:00 -0500 X-Loop: ietf@ietf.org --==_Exmh_391846488P Content-Type: text/plain; charset=us-ascii On Tue, 06 Feb 2001 22:30:06 CST, jag@kw.com.cn (Jun'an Gao) said: > 1. There are two annoying incompetence of TCP. One is that TCP does not > distinguish packet loss caused by network transmission error from that > caused by network congestion. The congestion control and avoidance mechanism > makes TCP drop its transmit window upon detecting a packet loss, thus lowers > the transmit rate even if the loss is caused by physical link transmit error. This may have been an issue back in the days of noisy, error-prone modems. These days, the *right* answer is to fix the hardware. On the other hand, I believe much of Van Jacobsen's initial tuning work on TCP had to do with the fact that even on noisy lossy lines, some 95% of lost packets were due to router congestion rather than actual mangling of bits on the wire. Yes, I know parts of the world still have poor infrastructrure. But even there, error-correcting modems do wonders. And if you're in an environment such as wireless where packets literally DO dissapear into the ether on a regular basis even when there is no congestion, RFC2018 describes 'Selective ACK' to allow recovery without losing your window. > The other is that the unit of TCP sequence number is byte (octet) while the > the sequence number is only 32 bit wide. It is not a big problem for a > no-more-than-100Mbps network. But in a modern gigabit network, it takes only > about 36 seconds to consume the whole sequence number space when transmitting > at the maximum bit rate. RFC1323 addressed this issue in May 1992. > 2. There is an observation that congestion control is somewhat the obligation > of routing system. If it were to be done by the end host, an end host > application might exploit UDP to avoid the congestion control of TCP. In general, a router cannot *force* an end host to not send a packet. The best it can do is send a notification that if a packet *is* sent, it has a high likelyhood to be dropped on the floor. ICMP Source Quench - although as Van Jacobsen showed, the same effect can be gotten just by treating a dropped packet as an implicit source quench. > In fact the video stream applications have caused some network congestion troubles. Well.. Yes. RSVP and related are still more or less experimental... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_391846488P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOoAQ+HAt5Vm009ewEQJySwCfSRbgDlW5sJecEkEmh1Lm6jALulwAnjpe Re6ed2Ca1M67uXkNTYKI+835 =l3rp -----END PGP SIGNATURE----- --==_Exmh_391846488P-- From owner-ietf-outbound Tue Feb 6 12:00:20 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA22535 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 12:00:02 -0500 (EST) Received: from localhost.localdomain ([216.52.68.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22309 for ; Tue, 6 Feb 2001 11:56:51 -0500 (EST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f16H1bJ04628 for ; Tue, 6 Feb 2001 12:01:37 -0500 Sender: francis@localhost.localdomain Message-ID: <3A802DF0.90B35408@ecal.com> Date: Tue, 06 Feb 2001 12:01:37 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: An alternative to TCP (part 1) References: <20010206143006.2DB8039EA3@china.kw.com.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Jun'an Gao wrote: > 6. Doing traffic shaping at the network edge is better than on the host node for The host *is* the edge of the network. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |World domination should never be left to chance.| |francis@ecal.com| | \=================================================================/ From owner-ietf-outbound Tue Feb 6 12:50:44 2001 Received: by ietf.org (8.9.1a/8.9.1a) id MAA24976 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 12:50:03 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24825 for ; Tue, 6 Feb 2001 12:47:11 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id MAA19457; Tue, 6 Feb 2001 12:47:07 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 6DF39895; Tue, 6 Feb 2001 12:47:06 -0500 (EST) Sender: shalunov@internet2.edu To: jag@kw.com.cn (Jun'an Gao) Cc: ietf@ietf.org Subject: Re: An alternative to TCP (part 1) References: <20010206143006.2DB8039EA3@china.kw.com.cn> From: stanislav shalunov Date: 06 Feb 2001 12:47:06 -0500 In-Reply-To: <20010206143006.2DB8039EA3@china.kw.com.cn> Message-ID: <87vgqnzoth.fsf@cain.internet2.edu> Lines: 31 X-Mailer: Gnus v5.7/Emacs 20.4 X-Loop: ietf@ietf.org jag@kw.com.cn (Jun'an Gao) writes: > There are two annoying incompetence of TCP. One is that TCP does > not distinguish packet loss caused by network transmission error > from that caused by network congestion. But ECN seems to address this issue, and it can work for UDP as well as TCP. > This results in an unnecessary reduction in link bandwidth > utilization, especially in the environment of wireless physical > links. One could argue that it's a responsibility of wireless link-layer protocols to ensure that random loss is rare (say, by employing an ECC). > The other is that the unit of TCP sequence number is byte (octet) > while the the sequence number is only 32 bit wide. What practical implications does sequence numbers wrap-around have in foreseeable future? At 10Gbps, sequence number space will last for 3.4s, which seems to be larger than your typical round-trip time of a hundred or two milliseconds. It seems it could start to be a problem at 100Gbps speeds, but current trend seems to be to increase the number of 10Gbps lamdba channels rather than their bandwidth... -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ I never let school stand in the way of my education. -- Mark Twain From owner-ietf-outbound Tue Feb 6 17:10:57 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA03492 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 17:10:01 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03340 for ; Tue, 6 Feb 2001 17:03:47 -0500 (EST) Received: from yuri.dns.microsoft.com ([172.30.236.11]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 6 Feb 2001 13:28:48 -0800 Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 6 Feb 2001 13:29:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: An alternative to TCP (part 1) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Feb 2001 13:29:36 -0800 Message-ID: Thread-Topic: An alternative to TCP (part 1) Thread-Index: AcCQZntF9Ct5ZzGvTMSH0AikLgpbMwAGjaZQ From: "Christian Huitema" To: "stanislav shalunov" , "Jun'an Gao" Cc: X-OriginalArrivalTime: 06 Feb 2001 21:29:38.0104 (UTC) FILETIME=[E86E6B80:01C09083] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA03340 X-Loop: ietf@ietf.org Content-Transfer-Encoding: 8bit > One could argue that it's a responsibility of wireless > link-layer protocols to ensure that random loss is rare (say, > by employing an ECC). For slow links, maybe. But TCP's congestion avoidance algorithm does make the assumption that 90%+ of the losses are caused by congestion, not link errors. Plug in the asymptotic behavior that tells you that the average data rate scales as 0(1/sqrt(loss-rate)). For a 1 Mbps data-rate, with 512 bytes packets and 100 ms RTT, that means a loss rate of at most 0.34%, of which 0.034% at most should come from transmission errors. That means a bit-error rate after ECC of less that 1.E-7; OK, we can probably engineer most links to do that. Now, consider a high speed network, with connections running at 1Gbps, with 8 Kbytes packets and still about 100 ms RTT. To not be slowed down by the congestion avoidance algorithm, we need a packet loss rate better that 1.E-6. If less than 10% of the losses are due to congestion, that means a bit error rate better of about 1.E-12. Well, I am not at all sure that we can hit that one. It only gets better with speed, by the way. To reach 10 Gbps, you will need a BER of 1.E-14. That amounts to missing at most one bit every 2 hours. There are very many ways to not achieve that... -- Christian Huitema From owner-ietf-outbound Tue Feb 6 17:30:09 2001 Received: by ietf.org (8.9.1a/8.9.1a) id RAA03889 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 17:30:02 -0500 (EST) Received: from mailserver.tantivy.com ([216.79.62.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03517 for ; Tue, 6 Feb 2001 17:10:46 -0500 (EST) Received: by TANPROX with Internet Mail Service (5.5.2653.19) id <1D4N3M1W>; Tue, 6 Feb 2001 17:04:52 -0500 Message-ID: From: Larry Foore To: "'jag@kw.com.cn'" Cc: "'ietf@ietf.org'" Subject: RE: An alternative to TCP (part 1) Date: Tue, 6 Feb 2001 17:04:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ietf@ietf.org >1. There are two annoying incompetence of TCP. One is that TCP does not > distinguish packet loss caused by network transmission error from that > caused by network congestion. The congestion control and avoidance mechanism > makes TCP drop its transmit window upon detecting a packet loss, thus lowers > the transmit rate even if the loss is caused by physical link transmit error. > This results in an unnecessary reduction in link bandwidth utilization, > especially in the environment of wireless physical links. Agreed. This discontinuity allows room for NAT-like "fixes" that don't benefit the entire well being of the Internet as an entity. This has been seen with some of the limitations of PEPs (split connections more specifically). I have explored such options for wireless systems. The trade matrix looks a lot like one for a NATed network -- good in the short term, questionable in the long term. > The other is that the unit of TCP sequence number is byte (octet) while the > the sequence number is only 32 bit wide. It is not a big problem for a > no-more-than-100Mbps network. But in a modern gigabit network, it takes only > about 36 seconds to consume the whole sequence number space when transmitting > at the maximum bit rate. Is this really a problem? How often would a single TCP session have allocated to itself an entire gigabit link? I'm not aware of any end systems or apps that generate data at this rate (especially for any extended length of time), much less accept it. Maybe I'm looking at this wrong. Respectfully, -Larry **************************************************************************** This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above. From owner-ietf-outbound Tue Feb 6 20:00:25 2001 Received: by ietf.org (8.9.1a/8.9.1a) id UAA05407 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 20:00:02 -0500 (EST) Received: from smtp.tndh.net (evrtwa1-ar3-182-130.dsl.gtei.net [4.33.182.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05316 for ; Tue, 6 Feb 2001 19:53:15 -0500 (EST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 06 Feb 2001 16:53:14 -0800 Received: from EaglesWings [4.33.178.101] by smtp.tndh.net [4.33.182.130] (SLmail 3.2.3113) with SMTP id 2492A2A8440D4CA4BAF3E859C21E689E for plus 2 more; Tue, 06 Feb 2001 16:53:13 -0800 From: "Tony Hain" To: "Larry Foore" , Cc: Subject: RE: An alternative to TCP (part 1) Date: Tue, 6 Feb 2001 16:51:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: 85438200-505D4363-A2323C73-ADEF6B38 Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit Larry Foore wrote: > Is this really a problem? How often would a single TCP session have > allocated to itself an entire gigabit link? I'm not aware of any end > systems or apps that generate data at this rate (especially for any extended > length of time), much less accept it. Maybe I'm looking at this wrong. Just over too short a time window. 15 years ago the same was said for 2Mbps rates when people started thinking about moving up to a whopping 45. Think 10 years out and the question becomes 'who would be willing to settle for as little as 1Gbps per connect?' Tony From owner-ietf-outbound Tue Feb 6 20:50:24 2001 Received: by ietf.org (8.9.1a/8.9.1a) id UAA06044 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 20:50:02 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05788 for ; Tue, 6 Feb 2001 20:35:12 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id UAA28871 for ; Tue, 6 Feb 2001 20:35:09 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id AD8BA895; Tue, 6 Feb 2001 20:35:07 -0500 (EST) Sender: shalunov@internet2.edu To: ietf@ietf.org Subject: Re: An alternative to TCP (part 1) References: From: stanislav shalunov Date: 06 Feb 2001 20:35:07 -0500 In-Reply-To: Message-ID: <87wvb3xol0.fsf@cain.internet2.edu> Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.4 X-Loop: ietf@ietf.org Larry Foore writes: > How often would a single TCP session have allocated to itself an > entire gigabit link? At SC2000 there was an application (non-interlaced HDTV) using 1.5Gbps. A web search brings up this: http://ssadler.phy.bnl.gov/adler/sc2k/sc2kpg3.html > This message is intended only for the individual or entity to whom > it is addressed and may contain information that is privileged, > confidential, and exempt from disclosure under applicable law. If > you are not the intended recipient, or the employee or agent > responsible for delivering the message to the intended recipient, > you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited, and you are > requested to please notify us immediately by telephone at > (321-956-8846) and return the original message to the address above. I guess I just violated that by quoting you. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war would really set back cable [television]." -- Ted Turner From owner-ietf-outbound Tue Feb 6 21:10:16 2001 Received: by ietf.org (8.9.1a/8.9.1a) id VAA06397 for ietf-outbound.10@ietf.org; Tue, 6 Feb 2001 21:10:02 -0500 (EST) Received: from china.kw.com.cn ([159.226.25.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06203 for ; Tue, 6 Feb 2001 20:57:29 -0500 (EST) Received: from jag (unknown [159.226.25.80]) by china.kw.com.cn (Postfix) with SMTP id 0A27C39EA1 for ; Wed, 07 Feb 2001 10:00:16 +0800 (CST) From: "Jun'an Gao" To: ietf@ietf.org Reply-To: "Jun'an Gao"