November 1998 - Test - lists.nanog.org

Re: Exodus / Clue problems
by James McKenzie 16 Nov '98

16 Nov '98

I sent this to him. I'm posting it here as others are having problems with the host. I just had a customer of mine log an a complaint, I've put a call into the Exodus New Jersey facility. They are paging there systems Admin. James >Date: Sun, 15 Nov 1998 15:21:36 -0800 >To: TTSG <ttsg(a)ttsg.com> >From: James McKenzie <mcs(a)1ipnet.net> >Subject: Re: Exodus / Clue problems >In-Reply-To: <199811152309.SAA28380(a)heimdall.ttsg.com> >References: <3.0.5.32.19981115150412.00aa7490(a)mail.1ipnet.net> from "James McKenzie" at Nov 15, 98 03:04:12 pm> > >#ftp 209.67.50.254 > >Connected to 209.67.50.254. >220 dns4.register.com FTP server (Version wu-2.4.2-academ[BETA-16](1) Thu May 7 >23:18:05 EDT 1998) ready. >Name (209.67.50.254:mcs): ^]q >331 Password required for q. >Password: >530 Login incorrect. >ftp: Login failed. >Remote system type is UNIX. >Using binary mode to transfer files. >ftp> quit >221 Goodbye. > >ns:22# nslookup dns4.register.com >Server: localhost >Address: 127.0.0.1 > >Non-authoritative answer: >Name: dns4.register.com >Address: 209.67.50.254 > >Forman Interactive Corp (REGISTER-DOM) REGISTER.COM >Register.Com (DOMAIN-DIRECT-DOM) DOMAIN-DIRECT.COM >Register.Com (DOMAINS-DIRECT-DOM) DOMAINS-DIRECT.COM >Register.Com (YAHOO-REGISTER-DOM) YAHOO-REGISTER.COM >Register.Com (NETSCAPE-REGISTER-DOM) NETSCAPE-REGISTER.COM >Register.Com (EXCITE-REGISTER-DOM) EXCITE-REGISTER.COM >Register.Com (REGISTERYOURDOMAIN2-DOM) REGISTERYOURDOMAIN.COM >Register.Com (DOMAINSONSALE-DOM) DOMAINSONSALE.COM >Register.Com (DOMAINNAMESFORLESS-DOM) DOMAINNAMESFORLESS.COM >Register.Com (DOMAINS-DIRECTLY-DOM) DOMAINS-DIRECTLY.COM >Register.Com (TOREGISTER-DOM) TOREGISTER.COM >Register.Com (SITEREGISTRATION2-DOM) SITEREGISTRATION.COM >register.com (CLOVERSKY-DOM) CLOVERSKY.COM > > >Forman Interactive Corp (REGISTER-DOM) > 201 Water St. > Brooklyn, NY 11201 > USA > > Domain Name: REGISTER.COM > > Administrative Contact, Technical Contact, Zone Contact: > Forman, Internic (PF61) internic(a)FORMAN.COM > 212-627-4988 (FAX) 212-627-6477 > Billing Contact: > Forman, Internic (PF61) internic(a)FORMAN.COM > 212-627-4988 (FAX) 212-627-6477 > > Record last updated on 25-Aug-98. > Record created on 01-Nov-94. > Database last updated on 15-Nov-98 04:46:26 EST. > > Domain servers in listed order: > > DNS1.REGISTER.COM 209.67.50.220 > DNS2.REGISTER.COM 209.67.50.241 > > > web site http://www.register.com > > > Looks like you might be looking at someone who's hacked there site, but this should help get you in touch with them. > > > James > > > > >At 06:09 PM 11/15/98 -0500, you wrote: >>> >>> >>> I'm not exodus but I am a customer in their Santa Clara, Walsh facility. >>> You sure got someone stupid. >>> >>> What's the problem? Perhaps I can help get some help. >>> >> Thanks......... >> >> Actually, this is out of New Jersey........... >> >> Looks like a heavy duty, repeated port scan..... >>heimdall:/home/ttsg# traceroute 209.67.50.254 >>traceroute to 209.67.50.254 (209.67.50.254), 30 hops max, 40 byte packets >> 1 nac-wsh6-e0-10Mb.nac.net (207.99.55.6) 168.931 ms 169.109 ms 169.792 ms >> 2 nac-wsh1-e0-10Mb.nac.net (207.99.55.1) 169.745 ms 169.32 ms 169.808 ms >> 3 h2-0-401.frame1.whi.nac.net (209.123.11.93) 179.754 ms 179.293 ms 179.80s >> 4 nac-globalcenter-Fa2-1-100mb.nac.net (207.99.5.191) 169.79 ms 179.18 ms s >> 5 vc37.atm1-0.cr1.DCA.globalcenter.net (206.132.191.162) 179.747 ms 199.092s >> 6 * vnva-01.core.exodus.net (192.41.177.119) 190.242 ms 217.626 ms >> 7 heva-02-h8-1-0.core.exodus.net (209.1.169.217) 191.728 ms 209.631 ms 209s >> 8 heva-05-p1-0.core.exodus.net (209.185.249.38) 209.729 ms 179.74 ms 319.7s >> 9 jcnj-06-p0-1.core.exodus.net (209.185.9.202) 259.623 ms 179.555 ms 199.8s >>10 jcnj-01-p12-0-0.core.exodus.net (209.1.169.186) 229.731 ms 189.627 ms 17s >>11 vlan921.rsm2-j8-b.lan.exodus.net (209.185.160.7) 189.733 ms 199.615 ms 1s >>12 209.67.50.254 (209.67.50.254) 219.754 ms 199.405 ms 249.803 ms >> >> >> Seems to have slacked off after I set a few machines to do a fast >>ping of it........ >> >> Tuc/TTSG >>> James >>> >>> At 05:38 PM 11/15/98 -0500, you wrote: >>> >Hi, >>> > >>> > Sorry to cross post, but is there anyone monitoring this list >>> >from Exodus with 1/2 a clue who might be able to help me? I called the >>> >NOC with an in-progress abuse and was told : >>> > >>> > 1) We don't know who owns that IP >>> > 2) We can't get into our own routers >>> > 3) We don't have a ticket system >>> > 4) The abuse people have a ticket system, but only if we >>> > can associate it to a customer (See #1) >>> > 5) We don't know how often the "abuse@" is checked >>> > 6) Email us the logs, and thanks for calling. >>> > >>> > >>> > AAAAAAAAARRRRRRRRRRGGGGGGGGGGGHHHHHHHHHHHHH!!!!!!!!!!!!!!! >>> > >>> > Tuc/TTSG >>> > >>> > >>> >>> James McKenzie >>> mcs(a)1ipnet.net >>> http://www.1ipnet.net >>> >> >> James McKenzie mcs(a)1ipnet.net http://www.1ipnet.net

1 0

Re: Hold on to your news servers
by Paul Vixie 16 Nov '98

16 Nov '98

> It's unfortunate that someone with such a long history and undoubtedly a > wealth of experience chooses to spend their time in these fruitless > endeavors rather than using that energy for something useful. That's a very portable paragraph. A lot of folks have said it about me, for example. And I've said it about a lot of folks other than just Karl. So while it's well said, it's about how people view each other rather than about Karl in particular. -- Paul Vixie <paul(a)vix.com>

2 1

Re: Hold on to your news servers
by John Fraizer 15 Nov '98

15 Nov '98

Christ, Don't you people have anything better to do than to piss and moan about Karl on NANOG? This is NOT an issue that relates to NANOG. Take it to i.dont.give.a.damn.usenet.admin.anarchy and give it a rest here! At 10:13 PM 11/13/98 -0600, Karl Denninger wrote: >On Fri, Nov 13, 1998 at 09:42:41PM -0600, Edward S. Marshall wrote: >> On Fri, 13 Nov 1998, Dean Anderson wrote: >> > Anyone who cancels someone elses post who is not a moderator or the >> > original poster should lose their account/job at ISP/etc. >> > >> > So lets start sending in complaints... >> >> And you'd complain to...who? Karl's an independant entity now. > >Correct :-) > >What's even more fun is that since the system doesn't EMIT any articles >it consumes (it emits only cancels, sourced there) you can't figure out >where it gets its feeds from.... good luck getting the system's feeds >cut off under those circumstances :-) > >-- >-- >Karl Denninger (karl(a)denninger.net) http://www.mcs.net/~karl >I ain't even *authorized* to speak for anyone other than myself, so give >up now on trying to associate my words with any particular organization. > > ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

Fruitless Endeavors
by mark＠vielle.datasys.net 15 Nov '98

15 Nov '98

: > It's unfortunate that someone with such a long history and undoubtedly a : > wealth of experience chooses to spend their time in these fruitless : > endeavors rather than using that energy for something useful. The greatest danger to good computer science research today may be excessive relevance . . . [C]ommercial pressure . . . will divert the attention of the best thinkers from real innovation to exploitation of the current fad, from prospecting to mining a known lode -- Dennis Ritchie Communications of the ACM, August, 1984 One way to reveal the real problems that need to be solved is to exacerbate them the conditions that cause them. Bad ideas and wasted time have a valid place in this business.

1 0

Hold on to your news servers
by Jeff Garzik 15 Nov '98

15 Nov '98

Hey guys, this is a heads-up about Karl Denninger's new clean-news system. I haven't seen any posts on this list about it. His message describing the implementation is attached below, posted "publicly" on chi.internet. (skip the quoted stuff) Karl is about to send out cancel messages, cancelling _every_ Usenet binary that is not PGP-signed by someone registered with his system. He says that these cancels will only go out to people he explicitly peers with, and not Usenet at large. He then adds that what these peers do with the cancel msgs is their own business. Folks, the goal is good, but the implementation is bad. These cancel msgs will leak out to Usenet at large. History proves this; leaking of net.*, bofh.*, clari.*, etc. occurs all the time despite admins' best efforts. And when these cancels leak, every news server on Usenet will * suddenly be receiving _thousands_ of additional cancels, and * 99.9999% of the binaries out there will disappear from your servers. I do not want to be handling the support calls when this occurs. If you are interested in this issue, there is a discussion on news.admin.net-abuse.usenet, thread "Karl Denninger loses his marbles..." Or ask me, I'm more than happy to outline the technical ramifications of this, and why it's a bad idea, in more detail. I'll cut and paste from my e-mails to Karl. :) Jeff (news admin/consultant) P.S. Had mailer problems. Apologies if you are seeing this twice. >Path: news.teleport.com!uunet!in3.uu.net!nntp.ntr.net!news.maxwell.syr.edu!news-xfer.newsread.com!netaxs.com!newsread.com!news.mcs.net!ddsw1!news.mcs.net!not-for-mail >From: karl(a)Denninger.Net (Karl Denninger) Newsgroups: chi.internet Subject: Re: MegsInet Newsgroup server Date: 12 Nov 1998 03:59:06 GMT Organization: Karls Sushi and Packet Smashers Message-ID: <72dmea$stt$1(a)Nntp1.mcs.net> References: <3647E943.3A3(a)spambusters.ml.org> <72dgku$jo6(a)enews4.newsguy.com> NNTP-Posting-Host: kdhome-2.pr.mcs.net X-Newsreader: trn 4.0-test69 (20 September 1998) Xref: news.teleport.com chi.internet:17477 In article <72dgku$jo6(a)enews4.newsguy.com>, Tommy the Terrorist <mayday(a)newsguy.com> wrote: >In article <3647E943.3A3(a)spambusters.ml.org> Clifton T. Sharp Jr., >agent150(a)spambusters.ml.org writes: >>There were some problems of late. One notable thing from the statistics >>is that we weren't getting our usual hundreds of thousands of articles >>from the MCI feed. Since C&W bought MCI's internet stuff, it seems like >>anything associated with the former MCI has gone straight to hell. It >>looks to me that as of now the problems are fixed; the newsgroups I follow >>have suddenly found hundreds of articles apiece. > >Who's kidding who? I presume you guys have heard of a certain asshole in >New York government (what a redundancy!) named Vacco? Presumably the >problem is the collective flushing of digital toilets now that ISP's have >become the new hunting ground for Evil Substances, etc. > >The problem with this particular war is that nothing short of a total >victory for the people, to keep anything and everything on ISP's, can >possibly prevent the state aggressors from eating away at free forums of >communications as fast as they can have their pet narks post child >pornography (with impunity) to anywhere they want the police to >"legitimately" attack and destroy. And if that happens, then the last >permitted forum of free speech in America, or damn near anywhere else, is >dead, and the only hope of humanity for political progress will be in >violence so unrestrained and universal that the smallest and weakest of >people have an equal power of destruction because it is unlimited for >all. And that is what inevitably will happen, unless something worse >happens. Read this. It solves the problem. And yes, this system WILL be going online. The software is already working. The "Clean-News" System ======================= ABSTRACT: "Clean-News" is a means to identify the poster of binary data on Usenet, remove most illegal content, and create a presumption of accountability. IMPLEMENTATION - USER SIDE: The "Clean-News" servers will have a key-ring of PGP keys. Anyone wanting to post "unmolested" binaries does the following: 1. Creates a PGP key for either 2.6.2 or 5.0 of the PGP software. 2. Obtains, from the www.clean-news.org web site, a list of authorized signers of their PGP key. 3. Contacts one of those signers, follows their procedures (which may include the payment of a fee), produces appropriate identification demanded by that signer, and gets their public key *signed* by that organization or individual. That is, the signer *vouches* for the authenticity of the key; that it belongs to the person who claims to be represented, that the email address associated with it is valid, and creates and maintains appropriate records to back up that assertion. 4. Submits the SIGNED key to the clean-news.org system. This database (of signed keys) is PUBLIC. Anyone can query it given an article which is signed by said key and obtain the name, email address, AND SIGNER of the key in question. The person with the private key associated with the signed, public key is then free to post binaries on Usenet, and clean-news will not molest them. IMPLEMENTATION - SERVER SIDE: The "clean-news" system obtains a feed from major backbone sites. It accepts all articles sent to it and maintains no database. It speaks both the older "ihave" protocol as well as the "check/takethis" newer NNTP protocol. Upon receipt of an article, the software checks to see if the posting contains binary data. It looks for common encoding formats - UUENCODE and MIME image data, primarily. Textual messages are ignored. Binary messages are run through the PGP software, and the output of the PGP verification process is read back. This process returns one of several results: 1. No signature on the file at all. 2. A signature is on the file, but the key ID is not known. 3. A signature is on the file, and the key is known, but it is not certified as "trusted". 4. A signature is on the file, is valid, and the key is both known and has a level of trust associated with it. In cases 1 - 3, the clean-news system emits a cancel message for the article in question immediately upon receipt. It does this by following the convention established for NOCEMs and other "spam cancels"; that is, it prepends "cancel." to the Message ID, and emits the cancel with this synthetic message Id. It also returns the posting with the system identification "clean-news" in the PATH line to permit aliasing out of the clean-news feed by those site admins who do not want the cancels. In case 4, the binary is ignored, as textual messages are. IMPLICATIONS - USENET SITE ADMINS READ THIS: 1. If you DO NOT want the "Clean-News" cancels, you should alias out the site "clean-news" from your Usenet software. Note that doing this will REMOVE any presumption that you would otherwise gain by ACCEPTING this feed. 2. If you DO want the "Clean-News" cancels, then do nothing, and further, contact your upstream News peers and insure that THEY are not aliasing out the feed. 3. If you CANNOT obtain these cancels (because all your upstreams are aliasing them out), or if you want the BEST possible feed, contact feedme(a)clean-news.org by email. You will receive in response an automated email detailing how to obtain a direct feed of the clean-news cancels. Note that this feed is rather low in volume - while it emits MANY cancels, they are small articles. You MUST BE able to keep up with this feed - the feed software will NOT keep articles for more than a few hours before it "junks" them. The feed will come to you via a Diablo feed system and is UNIDIRECTIONAL. Attempting to connect back to the Diablo machine will fail. 4. If you want to pass these cancels on to your PEERS, be advised that some of them may consider this service to be a "bad thing". I recommend, but obviously cannot enforce, that such is noticed to your peers so they may alias out the feed if they do not want it. WHAT DOES THIS MEAN TO POSTERS: 1. The use of a valid key creates a *presumption*, but not proof, that the poster really is who they said they are. That is, enough to get a search warrant. If Kiddie Porn shows up with a signature, the TRUSTED SIGNER of the key is determinable. That signer must, to be considered a trusted signer, keep records suitable for interrogation based on a published policy (ie: "serve us with a subpoena", etc). The LEO in question then asks the signer for the data, and complies with the policy they have set (which may include obtaining a warrant and/or subpoena). They then get a search warrant for the alleged perpetrator of the transmission, and see if in fact the material in question is being emitted there using standard forensic techniques. 2. LEGITIMATE binary posters have nothing to fear. Anonymous binaries get cancelled instantly, as do any which are unauthenticated. Those which ARE authenticated are free to be posted, but your identity is known, its undeniably yours (since it WAS your private key used to sign the article) and if you post something "naughty" the LEOs have all they need to come after you. WHAT ARE MY RESPONSIBILITIES AS A USER OF THIS SYSTEM WHO SUBMITS A KEY? Your primary responsibility is to PROTECT YOUR PRIVATE KEY. It is *STRONGLY* recommended that you keep this key on a protected, safe, removable device (such as a floppy with write-protect enabled) and NOT let it out of your personal control. If your PRIVATE key is COMPROMISED (ie: you lose the disk, you have reason to believe someone has stolen a copy of the key file, etc) you should IMMEDIATELY contact the introducer (the organization or person you had sign the key) *AND* the clean-news system at "revoke(a)clean-news.org" by email. When you contact the clean-news system, SIGN YOUR REVOCATION REQUEST. DO NOT send anything other than a revocation request to the above address. NOTE THAT REVOCATION OF A KEY IS PERMANENT AND CANNOT BE REVERSED. You should ALSO immediately revoke the key from any other key rings that you may have registered this key with. Note that ANY message signed with your key will be PRESUMED to be issued by you *PERSONALLY*. For this reason you should take EXTREME care with your private key. If it is stolen and used for illicit purposes those transactions will be traced to *YOU*, and you could find yourself under investigation by either civil or criminal authorities for something you have not done. HOW DO YOU REVOKE A KEY IF IT IS COMPROMISED? Keys may be revoked by: 1. The person who owns it at any time (ie; "I lost my key disk"). 2. Any LEO who provides an affidavit that said key was used to post copyrighted or otherwise illegal material. 3. Any LEO who provides an affidavit that a trusted introducer is not in fact trusted (ie: cannot produce the records, or produces false records, regarding a key they signed). 4. A trusted introducer may revoke their signature of any person's key that they have signed, in the event they discover that the key does not in fact belong to the person claimed or identification was falsified. When a key is invalidated the owner of the key is notified by email that their key was removed, and why (which of the above categories "happened"). A cancelled or revoked key is removed from the key ring, and is treated exactly as if it was never submitted to the system. To revoke a key as the owner of the key, send a PGP-signed request to "revoke(a)clean-news.org". IF THE REQUEST IS NOT SIGNED OR THE SIGNATURE IS INVALID IT WILL BE IGNORED. Assuming that the signature is good, you will be notified by return email when the revocation is processed. IS THERE A COST FOR THIS? 1. Individuals do not pay to list keys. However, INTRODUCERS may charge for signing a key (at their discretion) and maintaining the records necessary to comply with identification requests. 2. Systems desiring a *direct* feed may be assessed a small charge to cover the operating expenses of the systems involved. NO CHARGE FOR THE FEED ITSELF IS MADE, NOR FOR THE PROCESSING - ONLY THE TRANSPORT. If you receive a feed of the cancels you are encouraged to propagate it to others on mutually-agreeable terms to others who are also willing to receive it. WHAT ABOUT PRIVACY ISSUES? 1. The records of the clean-news system are EXPLICITLY public. Ergo, submitting a public key to the system constitutes publication of that key, and the fact that it is signed by one or more organizations and individuals. HOWEVER, that, alone, is worthless to an interloper. The email address on the key does NOT have to be valid, nor does the name - it must only map to a unique person at the SIGNER'S location which can be disclosed through their policies. As such, there is no privacy issue on the keyring used by the clean-news system ITSELF. 2. Customers and users who have their keys signed by an introducer should make themselves aware of the privacy policies of the signer. IF YOU ARE NOT COMFORTABLE WITH THEIR PROCEDURES AND ASSURANCES, YOU SHOULD USE A DIFFERENT KEY SIGNER! -- -- Karl Denninger (karl(a)denninger.net) http://www.mcs.net/~karl I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization.

5 6

Re: Is it time for an disruption analysis working group for the Internet?
by Dean Anderson 15 Nov '98

15 Nov '98

In aviation and probably the power industry, there is sense (and a reality) that lives and property are at stake. While the same may soon be true of the internet, there is still a perception that no one dies if the 'internet is down', and no property is destroyed though income is certainly lost. So there is no compelling need to force people to cooperate. Even if you can't force people to cooperate with information, there is still a lot of information about network disasters that will either leak out, or can be deduced or measured remotely. If you have someone with the credible technical authority to make accurate judgements about what happened and how it can be avoided, pressure can still be applied through bad publicity. Even the FAA's enforcement is for the most part pretty lassiz faire. It is well known in aviation circles that FAA regulations are "written in blood", by analyzing accidents and developing a set of rules to avoid them. Failure to follow the rules may result in your own death, and possibly others. Death is a pretty severe penalty. Many FAA enforcement actions are 'post-crash'. The rules aren't there to satisfy the ego of a bureaucrat, and the penalties are enforced more harshly by nature than by the FAA. >>How is this handled in other networked industries? I'm sure that the same >>issues of proprietary information and public humliation exist there; how >>do they deal with it? ... >A point from aviation -- incidents such as near-misses can be reported >without fear of liabiity, because the consensus is that it's more important >to recognize potential safety problems than it is to set up opportunities >for acting against individuals or setting up opportunities for lawsuits. This sounds pretty utopian. A counter point is that while this is the official spin, the fact is that the FAA treats non-reporting as suspicious. When there is a near miss, it usually involves a fault by 2 to 5 people: the controller if in controlled airspace, the pilots in command of both aircraft, and the copilots of both aircraft if they have copilots. If a near miss is reported, the non-reporting persons are asked "Were you aware that a near miss occurred?" If no, why not, if yes, why didn't you report it? Failure to report a near miss is much like refusing to take the breath-a-lyzer after a dwi stop. Usually not as bad as guilty, but a strong message is usually sent anyway. Later, they get into the question of who should have anticipated a collision course or who failed to follow instructions/procedures, etc. But if you report a near miss, and you were at fault, you will still be punished by the FAA. One must worry that someone else will report it: other pilots, other controllers, passengers, people on the ground, etc. And there have been cases where passengers reported near misses (at JFK) which were not reported by either pilots or controllers, until questioned by the FAA. Note also that a pilot is required by FAA regulations to be of "High moral character" to hold an ATP (Airline Transport) rating. While the Democrats (admittedly with huge public support) have worked hard to remove the concept, "High moral character" actually requires that one be honest, and do the right thing despite one's embarrassment or disinclination to do so. For pilots and controllers, it means reporting near misses and telling the truth about what happened. Of course, the FAA doesn't cite this specifically when revoking a pilots or controllers license, but it still affects their decisions and the penalties they impose. My point with all this is to illustrate that these are vastly different systems with vastly different underpinning behavioral motivations. I think to get something like this to work for the internet, you need to have an agency with enough purpose (e.g. people have to be at risk of death, or property must be at risk of destruction) to force people to cooperate. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Is it time for an disruption analysis working group for the Internet?
by Sean Donelan 15 Nov '98

15 Nov '98

Have we reached a critical mass of multi-provider disruptions to make it possible to do something yet? Most networked industries have some group which collects and analyzes information about disruptions. What's interesting is how often similar disruptions had precursor events across multiple different service providers. For example, there have been several cases in the last few months of root and gtld servers failing to transfer zone files. And there have been several cases of routers not withdrawing routes after an erroneous announcement. It is only after the major disruption occurs does the information get shared, usually via the public news media. Once upon a time, the IETF had a group called 'netstat,' and NANOG had presentations about the 'State of the Internet.' Neither have appeared on the agenda of those organizations for a variety of reasons recently. If there was a process for providers to submit initial and final reports about significant service disruptions; and a group to organize a regular report of common root causes across multiple providers (not a report card on any single provider) would any provider voluntarily participate? I'm not thinking about a real-time shared trouble ticket system, but something on the same scale as other industry outage reports to industry working groups. I suspect I know the answer to that question. Craig, Randy, Jhawk stop reading here----------------------------------- On the other hand, suppose instead of being very hard to reach I suddenly started returning reporters' phone calls promptly and telling them about this great idea I have to improve the reliability of the Internet. Eventually one will write a story about it, and maybe even get some decent coverage. How high up do I have to shoot in order to get your CEO's attention? Does it have to be the front page of the New York Times? Would that change the answer to the question above? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 5

Re: Hold on to your news servers (fwd)
by MegaZone 14 Nov '98

14 Nov '98

Once upon a time John M. Brown shaped the electrons to say... >Wouldn't it be nice if people actually quoted things correctly.... > >Quoting from his FAQ as posted on inet-access. > >" THIS CANCEL ADVISORY SYSTEM IS OPT-IN; THE CANCELS > WILL *NOT* BE GENERALLY INJECTED BACK INTO THE USENET > NEWS STREAM. " Yeah - and I have a bridge I'm selling. Have you been reading Karl's rants on this subject? He expects that the people who sign up for this service will control leakage. Sure, and pigs will fly. We have see many times that sites do NOT control leakage of local groups, clarinews feeds, bofh.*, etc. Do you honestly believe, for a second, that these cancels will NOT find their way back into the general stream? I sure as hell don't. It is a BROKEN implementation - can so far on inet-access Karl has done his usual job of refusing to listen to anyone other than himself when they have tried to suggest other means of distributing this to make it TRULY OPT-IN. And not OPT-IN - in Utopia only, and OPT-OUT in the real world. If he pushes ahead with this system as he has described it to date, it would be a very bad thing. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

1 0

Cisco IOS12.0 x 11.1CC
by Rubens Kuhl Jr. 14 Nov '98

14 Nov '98

Searching CCO for some keywords, I've found two interesting documents: http://www.cisco.com/warp/public/620/ios_11_1cc.html tells that IOS 11.1CC(17) was the basis for IOS 12.0(1). In other words, if 11.1CC(17) was good for you, 12.0(1) (and possibly 12.0(1a)) would also meet your requirements. http://www.cisco.com/warp/public/620/ios_12_0s.html tells that the IOS 11.1CC line will be replaced by IOS 12.0S. Cisco sources indicate that 12.0(3)S will be the first public release, and 12.0(4)S would be a better choice. Does someone know the release date of 12.0(2)S ? I'm trying to estimate a schedule for IOS 12.0(4)S deployment, based on release date of 12.0(2)S and two increments of 7 weeks for each release. Rubens Kuhl Jr.

2 1

For amusement (more on root nameserver problem)
by David R. Conrad 14 Nov '98

14 Nov '98

Hi, Received the following recently. I'll let it speak for itself. Regards, -drc -------- Original Message -------- >>From: FGC Sunnyvale NOC [mailto:snvnoc@globalcenter.net] >>Sent: Wednesday, November 11, 1998 4:14 PM >>To: global(a)isi.net >>Subject: Internet Degradation November 11, 1998 >> >>Inconsistencies between InterNIC and the Internet Software Consortium >>(root-servers.net) caused a wide-scale DNS outage today starting around >>17:15 UTC (09:15 PST). Technically, F.ROOT-SERVERS.NET's cache seemed to >>have been removed or in some way distorted. A number of domains may have >>shown up as non-existant during queries. This has in no way affected >>internal FGC nameservers. >> >>Unfortunately, InterNIC was unaware of this situation directly. The >>Internet Software Consortium who maintain the root-servers were >>unavailable for discussing the situation directly. >> >>The situation was resolved at approximately 20:30 UTC (12:30 PST). >> >>Frontier GlobalCenter ticket #981111066 was created to track this >>service degradation. >> >>If you have questions regarding this email notification, wish to be >>removed from the customer list, or require further assistance, please >>send Email to 'snvnoc(a)globalcenter.net' or call 1-888-541-9888, >>outside the US dial +1-408-541-9888. Thanks!

1 0