- NANOG - lists.nanog.org

infrastructure fund
by Bob Broedel 18 Mar '98

18 Mar '98

Subject: NSF PR 98-17: NSF AND NSI END INTERNET INTELLECTUAL : INFRASTRUCTURE FUND PORTION OF DOMAIN NAME REGISTRATION FEES http://www.nsf.gov/od/lpa/news/press/pr9817.htm ================================================ March 16, 1998 NSF PR 98-17 Media contact: Beth Gaston (703) 306-1070/egaston(a)nsf.gov ---------------------------------------------------------------------------- NSF AND NSI END INTERNET INTELLECTUAL INFRASTRUCTURE FUND PORTION OF DOMAIN NAME REGISTRATION FEES The National Science Foundation (NSF) and Network Solutions, Inc. (NSI) today announced the end of the Internet Intellectual Infrastructure Fund portion of domain name registration charges. As a result, the annual fee for domain name registration, which has been $50 since fees were imposed in 1995, will decline to $35, reducing the cost of domain name registration by 30 percent. The change will be effective April 1, 1998. The Internet Intellectual Infrastructure Fund was created to offset government funding for the preservation and enhancement of the intellectual infrastructure of the Internet. More than $45.5 million has been deposited into the fund to date. On March 12, the cooperative agreement between NSF and NSI was amended to stop contribution to the fund consistent with recommendations in the Clinton Administration draft discussion paper, "DNS Management Proposed Rule and Request for Public Comment (Improvement of Technical Management of Internet Names and Addresses)" -- commonly referred to as the "green paper." March 31 marks the end of the originally defined operational period in the agreement between NSF and NSI. Given the amount of the fund, NSF no longer believes it necessary to continue charging a percentage of the registration fee for the preservation and enhancement of the Internet's intellectual infrastructure. NSF has indicated that registration services for the Internet are now a self-sustaining activity and are beyond the mission of the agency which is to support science and engineering research and education. NSF does not intend to renew or recompete any agreement for registration services. Domain name registration is the process by which an alpha character string (e.g., nsf.gov) -- by which people navigate the Internet -- becomes associated with the twelve-digit Internet Protocol (IP) number which computers on the network actually use to locate and communicate with each other. In 1993, the National Science Foundation awarded a five-year cooperative agreement to Network Solutions, Inc. for registration services. Network Solutions is currently responsible for registration services for four top level domains: .edu for institutions of higher learning; .org for non-profit organizations; .net for network service providers; and .com for commercial organizations (the fastest growing realm). In 1997, the General Services Administration assumed responsibility for registration in the .gov domain, which is reserved for U.S. federal agencies. Fees for domain name registration services began in September 1995, as the demand for Internet registration became largely (97 percent) commercial and grew by orders of magnitude, exceeding NSF's ability to fund the registration. The NSF authorized NSI to begin charging a fee for domain name registration and set aside 30% for the Internet Intellectual Infrastructure Fund. No money from the fund has yet been spent. The future administration of domain name registration, particularly regarding generic top level domains (such as .com) which are not linked to any country code (such as .us,) is the subject of the Clinton Administration draft discussion paper. -NSF- Editors: Information about the fund and amounts deposited can be found at: http://rs.internic.net/announcements/iif-update.html The Clinton Administration draft discussion paper, "DNS Management Proposed Rule and Request for Public Comment (Improvement of Technical Management of Internet Names and Addresses)" can be found at: http://www.ntia.doc.gov Bob Broedel, Engineer TEL 850-644-6840 Meteorology Dept, 404 Love Bldg. E-M bro(a)huey.met.fsu.edu FLORIDA STATE UNIVERSITY, Tallahassee FL 32306-4520 USA -------------------------------------------------------------------- Free the internet2 lists from the Good Old Boys! --------------------------------------------------------------------

1 0

Floating an idea...
by Karl Denninger 18 Mar '98

18 Mar '98

Hi folks, What say all of you to the following idea: Block at the entry/peer router level all packets from networks which are shown to be "Smurf friendly" - that is, those network numbers and/or blocks which are smurf amplifiers (have directed broadcasts enabled)? I was thinking of something similar to the RBL, but that doesn't quite do it; a pull-down route to a sink doesn't do you any good, since what you're after is the *source* address. Now I know this may be entirely impractical for some folks, if for no other reason than CPU resources in those gateways. But this kind of thing would certainly send a message to those open amplifier networks in a big hurry. Think of it as an "attractive nuisance" problem (and fix). - -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

1 0

cisco MIP input/output rates
by Fancy Feast 18 Mar '98

18 Mar '98

Could someone running non-geek code with a 7500 series router and a MIP please verify that their XX second input/output rates are functional? I am seeing that it doesn't work at all running geeks code. Thanks, Alex

1 0

Anyone from @home out there?
by dougd＠mail.airmail.net 18 Mar '98

18 Mar '98

Sorry to spray the list, the usual methods have not met with much success. I am trying to reach an actual network engineer from @home.net that can work with me to resolve connectivity our mutual customers are having with their network and ours. Thanks

1 0

Re: Good morning, AOL
by Adam Rothschild 17 Mar '98

17 Mar '98

My hope is that someone from AOL (netops?) is lurking, and will pass it along. Though I do not want this to become an AOL bashing war, I doubt A, B, or C will generate the response desired... :) Regards, Adam On Tue, 17 Mar 1998, Peter Clark wrote: > I dobt AOL has any of their TOS people reading Nanog. > > I'd either A) mail postmaster, abuse, and tos(a)aol.com, B) sign on to AOL > and send a screen to TOS, or C) call AOL's 800 number and be ignored just > like the last time I tried to report someone. > > Just my 0x02c >

1 0

Good morning, AOL
by Adam Rothschild 17 Mar '98

17 Mar '98

Could someone from America Online's TOS department please drop me a note, ASAP? Thanks, Adam

1 0

why filtering ICMP can break PMTU-D
by Marc Slemko 17 Mar '98

17 Mar '98

I have had a few requests regarding just how ICMP messages not reaching where they should (for whatever reason, including using private address space that is filtered somewhere) can break path MTU discovery. Anyone interested who doesn't understand it should take a look at the brief description I have available at: http://www.worldgate.com/~marcs/mtu/ which tries to be as simple as possible and explain it in a way that almost anyone can understand. Was originally made for referencing in complaints to silly providers that break connectivity by broken filtering and can't understand the problems.

1 0

E-mail quotas
by Steve Hultquist 16 Mar '98

16 Mar '98

I'd like to get some input on how many of you are doing quotas for e-mail and what mechanism you are using for it. If you can take a minute, please send your replies to me (mailto:ssh@HSAnet.net) and I'll summarize to the list if there is interest. Thanks, ssh -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

1 0

Re: Building a NOC
by David A. Greer 16 Mar '98

16 Mar '98

Bill, Skipping John's message for a minute with the number of small ISP's out there it is actually forseeable that a book on starting an ISP might be possible to a limited extent. I would have welcomed such a book when I set up our internet gear (we would qualify as a medium sized ISP in our own right.) Now to get back to John's message, although there is some information out there that could be read there are a number of questions that you should ask yourself as far as scope of the project, number of sites, technical level at the remote sites, do you need to monitor Sniffers and the like or just plain Openview/Spectrum. Also does this NOC have to monitor and dispatch repair techs only or does it have to answer questions like how do I change my password on the server in my office. What about monitoring of the various servers in the enterprise? Novell? NT? Unix flavors, etc. Put all this together and the project manager in charge better have done it before at least once, or else this would quickly become a moneypit. Another major consideration is how much money and floor space is available for the NOC. I have seen several companies under-estimate the floor space needed and end up shoving stuff into corners to get it all into the allocated space, or scrimping money because the budget didn't live up to the pipe dreams of over eager planning personnel. David Greer Project Manager, Wide Area Telecommunications General Nutrition Companies, Inc. David-Greer(a)GNC-HQ.COM -----Original Message----- From: Goldstein_William(a)bns.att.com <Goldstein_William(a)bns.att.com> To: John_W_Connors(a)res.raytheon.com <John_W_Connors(a)res.raytheon.com>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, March 16, 1998 3:36 PM Subject: RE: Building a NOC

1 0

Re: [nsp] UDP broadcast filters. (fwd)
by Eric Germann 16 Mar '98

16 Mar '98

At 10:52 AM 3/16/98 -0800, Craig A. Huegen wrote: > <SNIP> </SNIP> > >#echo stream tcp nowait root internal >#echo dgram udp wait root internal >#chargen stream tcp nowait root internal >#chargen dgram udp wait root internal > As an additional note, on NT boxes, these can all be effectively whacked by not installing or disabling the "Simple TCP/IP Services" service. Mail me if you care. Eric ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0