economies of scale (was Re: solution to NAT...)
[PPP over TCP through NATs] doesn't provide any more global address space Why create more supply when it can be so easy to reduce demand? This reminds me of California's electricity crisis. It seems the internet administration community can easily do their part for this very fundamental aspect of fault-tolerance. For example, with this kind of a product: http://www.protonenergy.com/protonweb/html/energy.html What are the most popular such systems that take advantage of the economies of scale involved with not having a different UPS for each system or room or building or company or municipality? I ask not because I want to perpetuate the status quo, but mainly because this kind of thing makes it so much easier to introduce wind power, which costs 6 cents per kilowatt-hour, with modular turbine-powered windmills that can take less than six months to build. And although I know conservation is a better answer, I don't see people as being too predisposed towards it in most cases. If people are so fixated on growth, at least try to make sure they don't get themselves in an unsustainable bubble situation. Cheers, James
Re: Wall Street Journal: DNS is not secure
[EMAIL PROTECTED] wrote: Staff Reporter of THE WALL STREET JOURNAL WASHINGTON -- Computer experts discovered a flaw in widely used software that could let hackers hijack corporate and government Web sites and steal sensitive e-mail. Instead of WSJ, you might want to refer to http://www.cert.org/advisories/CA-2001-02.html http://www.isc.org/products/BIND/bind-security.html Anyway, I have spend the whole day to fix zones, since the current BIND does not like "TXT RR" as it used to be :-(. regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org Gong Xi Fa Cai - Hong Bao Na Lai
Re: economies of scale (was Re: solution to NAT...)
Keith, You are certainly correct: We are accustomed to thinking of conservation as a Good Thing, but an effective conservation plan can actually make a system less able to cope with fluctuations in load. That reminds me of another economic analogy to a contempoary internet engineering problem: multihoming's impact on the rounting table size in relation to the impact of multiple providers on the efficiency of health care. With increasing multihoming, the edge-network routing table size also increases, causing a lack of efficiency in routing which can have a significant impact on saturated network health. So, some people work towards the aggregation of routes by careful renumbering when possible. (RFC 2519) Similarly, if health care is limited and the destitute poor begin infecting the otherwise wealthy, then increasing medical costs will soon become very inefficient, overwhelming beneficial effects of unregulated free-market competition. Therefore, it is necessary to aggregate medical care to achieve the best possible economies of scale. Who is working towards this? http://www.allies-now.com Cheers, James
Re: Blast from the past
Here's some information about HOSTS.TXT from Jake Feinler, formerly of SRI-NIC. Alex. The SRI NIC registered hosts and maintained the official list of host names from 1970 up until the SRI NIC ceased to exist in Oct. 1992. At that time naming and addressing activities were turned over to NSI and SRI was no longer involved. However, I am not sure what the IETF discussion is referring to. HOSTS.TXT was originally an official file that hosts needed to load onto their machines to identify hostnames in headers. The file became too big for many machines, and there was network congestion due to everyone trying to download the file from the SRI machine. Consequently, some hosts started maintaining only a small subset of host names for sites with which they frequently communicated. Obviously that was a bad solution to the problem. Then the NIC provided a server that allowed one to refresh one's host tables automatically and/or query the server on the fly for a given hostname. This service was replicated at ISI and BBN (maybe other sites - I can't remember), and these additional servers refreshed their host tables from the NIC. Finally the network went to the domain naming system; however, SRI-NIC still continued to provide the official naming registration and distribution service for the Internet until we went offline. I left SRI in Sept. 1989. The NIC contract lasted until Oct. 1992. Dr. Jose Garcia-Luna, now at UC Santa Cruz, was leading the group until the contract ended. Mary Stahl and Sue Romano headed up the Name Service, so these people could give the definitive answer to the question asked.
International Conference for Java Development - Registration Open.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If you do not wish to receive future email messages, please forward this message to [EMAIL PROTECTED] (be sure to forward the ENTIRE message, or you may not be removed!) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Master new programming skills at the largest gathering of Java(tm) technology users coming to the East Coast in 2001! International Conference for Java Development Conference: February 28 - March 2/Exhibition: March 1-2 Marriott Marquis, New York City Java University(sm) Preconfernce: February 26 - 27 Register today for the only Java developer focused event coming to New York! Over 2,500 of your peers will be here, along with the industry's most respected technical experts, sought-after gurus and advanced users who will show you how to maximize Java technology to build the next generation enterprise applications. Dedicate yourself to 5 days of Java intellect and master new skills from those who are deploying Java in today's large-scale enterprise applications. Featuring Sun Microsystems' Java University Program on February 26 and 27. The International Conference for Java Development is proud to present Sun Microsystems' Java University(sm) Program. This two-day pre-conference program offers multiple full-day, code-level training sessions presented by industry experts. Learn about enterprise development, component development, using XML or prepare for and take the Programmer certification exam - onsite! Combine Java University with your three-day pass to maximize your investment in Java technology training. Register at: http://www.javacon2001.com or call 212-251-0006, ext. 13. For more information contact us at mailto:[EMAIL PROTECTED] Event Highlights *Presented by overwhelming demand, this will be the largest and most sophisticated Java event to come to New York in 2001. *Superior technical program - 5 tracks with over 70 sessions to select from. *Night School Sessions- Extend your day program or take independently *Expert faculty including Martin Fowler, Marco Pistoia, Peter Haggar, Bill Day, Elliotte Rusty Harold, Paul Lipton, Gregory Messner, Tyler Jewell, Gerry Seidman, Ed Roman, Marty Hall, Philip Heller *Free interactive exhibit floor. Over 10 hours of exploration are waiting for you *Sun Microsystems' Java University preconference training program *Get Certified! Take your Java technology certification exam at the show (provided by Prometric) Featuring 5 Concurrent Tracks *Java in the Real World *Design *Enterprise Java *Java for Wireless and Embedded Systems *Java Programming Two-Day Exhibit - Free Special Events Open to All! Exhibit Hours: Thursday, March 1 - 12:45 - 6:45 and Friday, March 2, 12:00 - 5:00 A full-scale exhibit hall packed with leading vendors will be on hand to demonstrate the latest products and answer your questions. All are welcome to fun-filled networking opportunities, including: *Keynote Presentations *Product Education Sessions *Technology Briefings *Panel Discussions *Welcome Reception *Product Giveaways Onsite Java technology certification exams by Prometric Testing facility in the Sun Education Pavilion. Hours: Thursday, March 1 - 12:45 - 8:00 and Friday, March 2, 8:00 - 5:00. Reserve your spot and get certified at the show. Register on-line for your free Exhibit Pass - a $25.00 value! Register at: http://www.javacon2001.com or call 212-251-0006, ext. 13. For more information contact us at mailto:[EMAIL PROTECTED] The Standard of Excellence We realize you have a choice for your IT training requirements. Every Camelot event is recognized for it's on-going commitment to unbiased and up to the minute technical presentations that are always led by industry leaders. This exceptional line-up of speakers and topics is the only event you can't afford to miss. The International Conference for Java Development is by produced by Camelot Communications Corp. Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Camelot Communications is independent of Sun Microsystems. ***DSIID60322[EMAIL PROTECTED]***
Re: [midcom] WG scope/deliverables
From: Keith Moore [EMAIL PROTECTED] If this group takes the attitude that NATs are inherently broken and that there's really no way to fix them in the long term without phasing out the NAT part, it's much more likely to produce something useful than if it tries to find a way to incorporate NATs into the mainstream architecture of the Internet. Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) You seem to be having problems accepting that fact that NAT's are selling several orders of magnitudes (I'd guess at least 3, but it's probably more) more units than your preferred alternative. Most people would regard this as a sign that the world has decided, and move on. When life gives you lemons, you have to make lemonade. NAT's are a fact of life, and we will, indeed, have to find some way of incorporating them into the mainstream architecture of the Internet. This is a subject on which I have pondered a lot, for several years - maybe you should wrestle with it too. Noel
Re: [midcom] WG scope/deliverables
In message [EMAIL PROTECTED], "J. Noel Chiappa" typed: Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) You seem to be having problems accepting that fact that NAT's are selling several orders of magnitudes (I'd guess at least 3, but it's probably more) more units than your preferred alternative. Most people would regard this as a sign that the world has decided, and move on. many nats cost nothin - many are check boxes on existing products - alternatives cost money - some day tho, they may be required like IP was when we started with x.25:-) When life gives you lemons, you have to make lemonade. NAT's are a fact of life, and we will, indeed, have to find some way of incorporating them into the mainstream architecture of the Internet. This is a subject on which I have pondered a lot, for several years - maybe you should wrestle with it too. when life gives you lemons, pick grapes instead and make wine or bottle spring water and sell that (with or without added CO2) its better for your teeth. cheers jon
Re: [midcom] WG scope/deliverables
Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) Noel, 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. I said this because I've looked at the problem quite extensively. The more I have done so, the more have concluded that there's no way to restore the valuable functionality that NATs have removed from the Internet without providing another global address space, and that it's much more efficient and less painful to embellish the NATs to become IPv6 routers than it is to embellish both the NATs and applications to support a segmented address space. Thus, while I accept that the market needs a short-term solution to deal with NATs, I also am firmly of the opinion that it's a short-term solution. IPv6 will be attractive for the same reasons that NAT was attractive - it will be the path of least pain to solving a pressing set of problems. Being over-ambitious about goals has prevented more than one working group from accomplishing anything useful, and exhausted lots of talented people in the process. I hardly think that advocating a little restraint in this group's ambition is sufficient justification for personal attacks. Keith
Re: [midcom] WG scope/deliverables
ietf-list folks: Given that a single contribution to a WG's discussion (keeping entirely within the charter) has resulted in multiple personal attacks, I felt compelled to respond to this message. But as this discussion is really specific to the midcom list, I've sent my full reply there. If you're really interested you can read it in the midcom list archives. Unless and until it becomes a process issue, I'd just as soon deal with purely personal disageements in private mail, rather than on the IETF list. Keith --- Keith Moore [EMAIL PROTECTED] wrote: Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) Noel, 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. With all due respect, Keith, you are saying that addressing NAT concerns should not be a short-term goal. You are OK with the WG addressing firewall concerns however. But, insisting on this and repeating the mantra many times over, even after the WG is formed with a specific mission and chater, is really disruptive to the work being done in the WG. The charter requires the work group to address both NAT and firewall concerns. It is very confusing and intimidating to the folks who are genuinely trying to contribute. You jump on the bandwagon the moment someone says anything about NAT. Soon it turns into a flaming fest. ...
Re: FAQ: The IETF+Censored list
Harald Tveit Alvestrand wrote: The IETF+Censored mailing list I believe that that message itself does not comply BCP-45/RFC-3005. 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 :^)? regrets, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Good bye hegemony - http://sapi.vlsm.org/DLL/linuxrouter
[VOIP] Security
Title: [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=Net
Re: [midcom] WG scope/deliverables
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
Re: [midcom] WG scope/deliverables
Bill Manning writes: | and tosses it w/o any abilitiy to notify the originating | party. Why is it necessary that there be an inability to notify the originating party? dkerr already proved it's cheep cheep cheep to maintain some types of state even with lots of flows per second, and the whole point is to consider ways in which midcom boxes can do speed-smarts trade-offs to help avoid such "inabilities" in the first place. No? "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 difficult to answer in a manner different than "ignore it, and hope the sender up eventually stops whatever it's doing to trigger the error message". Translating Mapping Gateways may be "tricky" enough to scare some people, but this is kindergarten compared to this very issue in MPLS... Sean.
Re: [midcom] WG scope/deliverables
The point being that if you have an arbitrary bunch of firewalls and NATs between any two points, then you are forced into telephone-like "call set-up" scenarios, which don't really scale to large groups, specially when the application consists of sporadic messages to arbitrary destinations. or in general, that networked applications sometimes involve more than two parties that are mutually communicating (and they don't necessarily use TCP exclusively) a lot of the proferred solutions seem to assume that pairwise mappings are sufficient; they aren't. Keith
RE: [midcom] WG scope/deliverables
The point being that if you have an arbitrary bunch of firewalls and NATs between any two points, then you are forced into telephone-like "call set-up" scenarios, which don't really scale to large groups, specially when the application consists of sporadic messages to arbitrary destinations. -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 6:01 PM To: Bill Manning Cc: Keith Moore; David T. Perkins; Michael Richardson; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables e.g. it takes (at least) two to tango... or peer. "at least". yes. Keith
Re: [midcom] WG scope/deliverables
e.g. it takes (at least) two to tango... or peer. "at least". yes. Keith
FAQ: The IETF+Censored list
The IETF+Censored mailing list At times, the IETF list is subject to debates that have little to do with the purposes for which the IETF list was created. Some people would appreciate a "quieter" forum for the relevant debates that take place, but the IETF's policy of openness has so far prevented the IETF from imposing any censorship policy on the [EMAIL PROTECTED] list. To give people an alternative, there is a list called "[EMAIL PROTECTED]". This list is a sublist (that is, it gets the same messages as) the open IETF discussion list. However, this list will not forward all messages; in particular, the filters have been set so that persons and discussions that are, in the view of Harald Alvestrand, irrelevant to the IETF list are not forwarded. Because this filter is automated, the criteria include: * Well known troublemakers * Well known crosspostings * Subjects that have led to recent non-conclusive exchanges * Some ways to say "unsubscribe" To join the list, [1]send the word "subscribe" in the BODY of a message to [EMAIL PROTECTED] (the URL here is an RFC 2368 mailto URL that does the Right Thing). To unsubscribe, [2]send the word "unsubscribe" in the BODY of a message to [EMAIL PROTECTED] Do not send to the list - your message will be filtered! (members of the main IETF list itself must follow instructions for that list, of course. You are only a member of ietf+censored if there is a comment on the bottom of your IETF list mail saying that the message has been sent through the ietf+censored list.) For fun, there is a special list for the rejected messages: [EMAIL PROTECTED] - subscribe in the same fashion, by [3]mail to [EMAIL PROTECTED] By public request, the current set of filters are listed at [4]http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters Some statistics on postings, which may be useful in getting a perspective on the effects of the filter, are at [5]posting-counts.html (started Oct 14, 1998). This page is http://www.alvestrand.no/ietf+censored.html, and is posted monthly in text form to [EMAIL PROTECTED] _ Harald Tveit Alvestrand [6] [EMAIL PROTECTED] References 1. mailto:[EMAIL PROTECTED]?body=subscribe 2. mailto:[EMAIL PROTECTED]?body=unsubscribe 3. mailto:[EMAIL PROTECTED]?body=subscribe 4. http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters 5. http://www.alvestrand.no/posting-counts.html 6. mailto:[EMAIL PROTECTED]
Re: [midcom] WG scope/deliverables
HI, On the list below, I believe that peer-to-peer applications like napster can work in a NAT world. All you need is a registration and rendezvous service to put the two peers together. This can be part of the box that also provides the NAT service. At 05:54 PM 1/31/2001 -0500, Michael Richardson wrote: NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson Regards, /david t. perkins
Re: [midcom] WG scope/deliverables
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. I said this because I've looked at the problem quite extensively. The more I have done so, the more have concluded that there's no way to restore the valuable functionality that NATs have removed from the Internet without providing another global address space, and that it's much more efficient and less painful to embellish the NATs to become IPv6 routers than it is to embellish both the NATs and applications to support a segmented address space. 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. NATs are a consequence of a choice rather than makers of a choice. The choice is to use heterogeneous networks. I contend that the reasons for this choice 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. BTW, I agree with Noel's solution that a NAT-haters list might be in order. Maybe you could call it NAT-not list, to avoid the "hate". Meanwhile, the rest of the world would continue to pursue ways to deal with the real-world needs answered by NATs (and things to come). Cheers, Ed Gerck
Re: [midcom] WG scope/deliverables
--- Keith Moore [EMAIL PROTECTED] wrote: Keith, why don't you start an NAT-Haters mailing list, and take all this disgust with NAT's there? (I'm quite serious about this.) Noel, 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. With all due respect, Keith, you are saying that addressing NAT concerns should not be a short-term goal. You are OK with the WG addressing firewall concerns however. But, insisting on this and repeating the mantra many times over, even after the WG is formed with a specific mission and chater, is really disruptive to the work being done in the WG. The charter requires the work group to address both NAT and firewall concerns. It is very confusing and intimidating to the folks who are genuinely trying to contribute. You jump on the bandwagon the moment someone says anything about NAT. Soon it turns into a flaming fest. I said this because I've looked at the problem quite extensively. The more I have done so, the more have concluded that there's no way to restore the valuable functionality that NATs have removed from the Internet without providing another global address space, and that it's much more efficient and less painful to embellish the NATs to become IPv6 routers than it is to embellish both the NATs and applications to support a segmented address space. Well, I (and perhaps many others) respectfully disagree. This is not a short-term solution yet, not until folks have V6 networks deployed. Thus, while I accept that the market needs a short-term solution to deal with NATs, I also am firmly of the opinion that it's a short-term solution. So, if you do agree working that dealing with NATs is a short term solution, why are you so repeatedly trying to torpedo the effort going in to solve the short term problems ? IPv6 will be attractive for the same reasons that NAT was attractive - it will be the path of least pain to solving a pressing set of problems. Agreed, perhaps with the exception of address renumbering. Being over-ambitious about goals has prevented more than one working group from accomplishing anything useful, and exhausted lots of talented people in the process. I hardly think that advocating a little restraint in this group's ambition is sufficient justification for personal attacks. This has been more than just a little advocation of restraint, I might add. Keith ___ midcom mailing list [EMAIL PROTECTED] http://www.ietf.org/mailman/listinfo/midcom Thanks. regards, suresh __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
RE: [midcom] WG scope/deliverables
Would such a rendezvous service work if their were NATs between each of the participants and the service itself (regardless of whether it is hosted on a NAT or not)? If so, wouldn't such a solution alter peer-to-peer to become a hub-and-spoke service requiring ISP mediation in the Internet case as opposed to peer-to-peer? -Original Message- From: David T. Perkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 3:41 PM To: Michael Richardson; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables HI, On the list below, I believe that peer-to-peer applications like napster can work in a NAT world. All you need is a registration and rendezvous service to put the two peers together. This can be part of the box that also provides the NAT service. At 05:54 PM 1/31/2001 -0500, Michael Richardson wrote: NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson Regards, /david t. perkins
Re: [midcom] WG scope/deliverables
NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows fastertm Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
