- Test - lists.nanog.org

Re: NAVYJOBS.COM
by edfang＠visi.net 22 Apr '96

22 Apr '96

Why limit to companies with 200+ hosts. You open yourself to much more trouble (read legal) if this was the case. If you just said everybody had to take a domain under your balanced tree aa.com ab.com ac.com etc then you could project some sort of fairness to the whole idea. Nobody could really complain about getting unfair treatment, there are no openings for discussion. Names would be delegated in the slots that had openings. I don't think you could get this to fly with the current nameholders, but an interesting concept nonetheless. Ed > Why not to restrict first-level domains to companies > which can demonstrate that they have 1000+ hosts? > Companies with 200+ hosts then should use .A.COM -- .Z.COM > (i know, some of them are taken, but that can be fixed). > Smaller companies should use .xx.COM (and xx is NOT choosen > by the companies -- it is just the random seed and/or > registry ID). > <snip> > That kind of defeats the "menmonic" value of names but > still beats telephone numbers (and then, what kind of > mnemonic can be used to distinguish between thousands of > nearly identical small businesses?) > > --vadim >

1 0

RE: NAVYJOBS.COM
by Jim Fleming 22 Apr '96

22 Apr '96

On Monday, April 22, 1996 11:47 AM, Michael A. Patton[SMTP:MAP@bbn.com] wrote: <snip> @the expression). The other possibility is the contract went to some @upstart that doesn't even _think_ about domains other than .COM ... @ I was told recently by a "DOS expert" that .COM comes from the file extensions used by Microsoft, as in COMMAND.COM. This person "educated" me that Microsoft uses the .COM extension for "popular" programs like COMMAND.COM and that .COM stands for "common" and also "command". I was informed that everyone registers in the .COM domain to make sure that they are compatible with the version of the Internet supported by DOS and Windows. Needless to say...I was surprised that the origin of .COM was sort of lost in the translation...I guess when you have a hammer like DOS, everything looks like a nail... I guess if companies like AOL, Prodigy and Compuserve can convince their subscribers that they are "on the Internet", maybe everyone else can now convince people that _are_ on the Internet...that they are really on DOS....or something else...:-) -- Jim Fleming UNETY Systems, Inc. Naperville, IL 60563 e-mail: JimFleming(a)unety.net

1 0

NAVYJOBS.COM
by Sean Doran 22 Apr '96

22 Apr '96

I was happily watching the hockey playoffs just now (well, as happily as possible without Hockey Night in Canada), and noticed a commercial for U.S. Navy Recruiting. Why why why why why are they in .COM?! I think we should be told. Sean.

6 6

Re: NAVYJOBS.COM
by Scott Bradner 22 Apr '96

22 Apr '96

> Why why why why why are they in .COM?! cuz the ad agency was clueless? Scott

3 2

Re: NAVYJOBS.COM
by avg＠postman.ncube.com 22 Apr '96

22 Apr '96

exp(M) (shoul've been exp(t)) is the growth of Internet. Any sane policy will have to account for it (and, no, just doing three levels is not enough, there should be a way to go into more levels if needed later). The idea of using "randomizing" sub-domain is to get people used to the idea of randomization in domain names. Then it can be moved into protocol or implementations. It also fixes the name collision and transparent introduction of multiple registries. There is no other way to satisfy N users when every one of them wants to be named "Itty Bitty Machines". --vadim

1 0

Re: NAVYJOBS.COM
by avg＠postman.ncube.com 22 Apr '96

22 Apr '96

Well, that solution have a problem not present in vanilla DNS -- nameservers no longer correspond to administrative boundaries. And it does not do anything to fix the name collision problem. --vadim >From nanog-owner(a)merit.edu Mon Apr 22 19:26 PDT 1996 Return-Path: <nanog-owner(a)merit.edu> Received: from postman.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA16645; Mon, 22 Apr 1996 19:26:03 +0800 Received: from titan.sprintlink.net by postman.ncube.com (4.1/SMI-4.1) id AA28280; Mon, 22 Apr 96 19:27:42 PDT Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id WAA01557 for <avg(a)titan.sprintlink.net>; Mon, 22 Apr 1996 22:27:31 -0400 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id VAA29036 for nanog-outgoing; Mon, 22 Apr 1996 21:38:51 -0400 (EDT) Received: from chops.icp.net (chops.icp.net [199.0.55.71]) by merit.edu (8.7.5/merit-2.0) with ESMTP id VAA29030 for <nanog(a)merit.edu>; Mon, 22 Apr 1996 21:38:48 -0400 (EDT) Received: by chops.icp.net id <20637>; Mon, 22 Apr 1996 21:38:40 +0100 From: Sean Doran <smd(a)icp.net> To: pferguso(a)cisco.com, smd(a)icp.net Subject: Re: NAVYJOBS.COM Cc: john(a)interport.net, nanog(a)merit.edu Message-Id: <96Apr22.213840+0100_edt.20637+44(a)chops.icp.net> Date: Mon, 22 Apr 1996 21:38:31 +0100 Sender: owner-nanog(a)merit.edu Precedence: bulk Content-Type: text Content-Length: 2174 Status: R | Personally, I like the <eighty-subdomains>.BigCompany.COM. approach; | it just scales better. Less messy. Tastes great. Me too. However, there appears to be some counterpressure to move towards what I perceive as some kind of system which lacks any real hierarchy in the sense of domains. Perhaps instead of trying to "fix" the DNS by creating huge new bunches of things to the right of the last normally-seen dot, we should move towards something completely different. Maybe instead of: <whatever>.COM being considered as three tokens and being looked up as: ask a ROOT nameserver for COM NSes ask a COM nameserver for <whatever> NSes ask a <whatever> nameserver for appropriate info (all modulo caching) instead we treat it as (leaving out the '<' '>' stuff out of laziness): <w><h><a><t><e><v><e><r><.><c><o><m> and look up like this: ask a ROOT nameserver for M NSes ask a M nameserver for O NSes ... ask a <w> nameserver for appropriate info that will scale to a huge number of generally unformatted labels for things. This strikes me as a practical way of moving towards ".Earth" and ".Alt" and thousands of other "top-level-domains". Other than technical scalability, the other general design goal for any changes to the status quo wouuld have to be administrative scalability. As a too-easy example, in this model that's essentially making sure an overworked or evil delegator for $origin ever.com won't break the ability of people wanting $origin whatever.com or $origin never.com from going about obtaining those names. Perhaps some form of automagic registration scheme should be available to allow for others to initiate any rightwards growth of names unless they involve certain charaters (like '.', perhaps, so as not to overly confuse people who are used to foo.bar.com being under the administration of whoever is in charge of bar.com) Again, I worry about being wasteful of other people's time here; this could be a non-issue for operators big and small for all I know, so I'll drop back into read-only mode for a bit, and let smarter DNS people and folks more in the trenches talk it out (or ignore it). Sean.

1 0

Re: NAVYJOBS.COM
by avg＠postman.ncube.com 22 Apr '96

22 Apr '96

The current problem with DNS is not load on root NSes (however, even a blind person can see how exponential growth at more-than Moore's law will get it to the point where you simply won't be able to find a box fast enough to run root NS). Those of us with longer memories remember times when 16Mb on AGSes was "more than enough for any foreseeable future". And, yes, followinmg your analogy, 99.999% of routers do not have to have more than 100 routes in them. Does it help a dozen of dying backbone boxes much? The current problem is increased name collisions. Which is, to say, a fundamental one. No matter how you jump you won't be able to decrease rate of name collisions w/o increasing depth of the tree. The only other remedy is to stop choosing natural abbreviations and start doing as AOL does with customer names. Which is, essentially, an inferior way to do exactly what i proposed to do. (And, BTW, there's life after 26 letters are done with; you can set moving "line in the sand" on who gets shorter names). But -- the idea that first level domains are sexy got to be stomped out before anything real can be done about DNS. New TLDs is merely moving the problem one level higher. It definitely cannot fix anything. --vadim PS. No, i don't call to "rename Internet". I call to stop the insane practice of building the flat namespace. >From GAVRON(a)ACES.COM Mon Apr 22 17:45 PDT 1996 Return-Path: <GAVRON(a)ACES.COM> Received: from postman.ncube.com by butler.ncube.com (5.0/SMI-SVR4) id AA16312; Mon, 22 Apr 1996 17:45:36 +0800 Received: from Hearts.ACES.COM by postman.ncube.com (4.1/SMI-4.1) id AA18743; Mon, 22 Apr 96 17:47:04 PDT Received: from ACES.COM by ACES.COM (PMDF V4.3-10 #4107) id <01I3RYXO7X0G000031(a)ACES.COM>; Mon, 22 Apr 1996 17:46:44 -0700 (MST) Date: Mon, 22 Apr 1996 17:42:30 -0700 (MST) From: Ehud Gavron <GAVRON(a)ACES.COM> Subject: Re: NAVYJOBS.COM In-Reply-To: Your message dated "Mon, 22 Apr 1996 15:45:23 +0800" <9604222245.AA15747(a)butler.ncube.com> To: avg(a)postman.ncube.com Cc: john(a)interport.net, smd(a)icp.net, nanog(a)merit.edu, GAVRON(a)ACES.COM Message-Id: <01I3UN0PL9NS000031(a)ACES.COM> Organization: ACES Research Inc. Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Length: 1809 Status: R Vadim asks: >Why not to restrict first-level domains to companies >which can demonstrate that they have 1000+ hosts? Creating a problem to solve a problem is not a solution. Paul already said that a 16MB 486 can handle root DNS just fine. This does not bespeak of a problem requiring "renumbering" hundreds of thousands of domains. FURTHER, your "big win" is only a 1/26 lessening of load. If the problem is such that 1/26 is a "big win" I think it's not big enough to rename the Internet for. ... >What we should worry about is number of first-level >domains/number of hosts ratio. It is the same problem >as with routing. The solution is also the same -- No, it's not the same problem as routing. All routers with non-default rules need to know about all routes. The only possible analogy for that in DNS is root nameservers. These (as Paul pointed out in a previous post, since he runs F) are not saturated, and don't require that many resources. If you feel the growth of domain names is such that it will outstrip a 486 w/16MB soon, tell me when it will be a SIGNIFICANT problem. I.e. when will it outstrip a real machine (Sun, VAX, Alpha, SGI) with real memory (64MB? 128MB? 4G?) Remember, upgrading HUNDREDS of routers all running 45Mbps is a priority. Upgrading 8 boxes running BIND and doing it well is a much much much lower priority. >mnemonic can be used to distinguish between thousands of >nearly identical small businesses?) >--vadim >PS. Obviously if IBM registers 100 domain names it is > still a lot less damage than a small ISP (with 1000 dial-up > customers) which registers a domain name for every such > customer. Big folks registering POISONOUS-BURGER.COM and > SHIT-ON-TV.COM aren't really a problem. Zillion of > MOM-AND-POP.COMs is. Ehud

1 0

request to network operators
by Jeremy Porter 20 Apr '96

20 Apr '96

In keeping with my goal of providing the Nanog community with some numbers based in fact, that indicate paths toward sustainable Internet economics. Please note, all raw data I gather and my methods will be published, hopefully at May Nanog. This work is based on cost studies of resource utilizations in the various parts of the net. Some people may not agree with my conclusions or my methods, and I don't realistic hope to end the various debates on policy, but the calculations cannot be made without reasonable data that reflects todays Internet. I have traffic data comming from 3 of 5 of the major naps, and hope to get the last two on board soon. I need flap data, but it apears that the RA project has reasonable data to work from. Lastly I need information on router table utilization, speicifcly if you have Cisco routers at 3 or more of major exchanges, and basicly run "defaultless". Specificly I'm looking at processor and memory utilziation in Cisco routers with large numbers of views/paths. The magic command in this case would be: show ip bgp sum If for security reasons, you do not wish send the whole output, I would be happy with the first summary part, as I don't need the peer information. The Cisco firmware version would be helpful, but not required. It would be nice to have a MAE-East and MAE-West snapshot, but I'm not terribly picky, and realize that you will be taking time out of your schedule for this. Anyone that sends me a snapshot of 2 or more routers, I buy lunch for at Nanog. Thanks. -- Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-339-6094 http://www.fc.net

1 0

Northwest Internet eXchange (NIX) operational!
by Eric Kozowski 20 Apr '96

20 Apr '96

The NIX is now initially operational! IXA and NWNexus are currently exchanging traffic. Structured should be connected next week (if I get time to hook the circuit up). According to Ed @ NWNexus, traffic is running between 25kbps to 65kbps, with only the two of them connected. For those of you not familiar w/ NIX, take a look at: http://www.structured.net/nix Eric PS - Thanks to Ed and Nikos for getting things rolling while I was busy w/ other things. -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3235 FAX "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0

IRR visualization
by eddy＠isi.edu 19 Apr '96

19 Apr '96

Hello everyone, Sorry for duplicates of this message. The visualization front end for the IRR is available from: ftp://ftp.isi.edu/eddy/irrv-0.2.1.tar.gz There is also a README file: irrv-README available from the same location. Please note this software runs as a module under the scotty/tkined network management package, that are also freely available. http://www.cs.tu-bs.de/ibr/projects/nm/tkined/welcome Bug reports are eagerly awaited 8-). Just as important, i'd like to solicit the opinions and suggestions of the NANOG and RPS communities as to the capabilities a visualization tool that you would find useful. Thank you, -- - rusty eddy(a)isi.edu

1 0