Fatty Pipes with Y2K problem - OT humor

Fri Jun 18 10:38:42 UTC 1999

Btw, the Y2K annoying which does have place make more troubles than 
Y2K problem itself. If you think a little you understand Y2K problem can 
cause input/output errors during different requests, billung, accounting 
problems, etc etc, but hardly can influence real-time systems. No one 
router or server over the world know really about the year - it know 
_xxxxxxx seconds since yyyyyyy date_ time, and next second always is 
xxxxxx+1_. The problem exists, of course, because a lot of people should 
enter _the date of some event_ into this real-time systems (just before 
or after Y2K), and bad software can cause a mistaken data 
encoding/decoding, but when someone write in the magazine _the chip in 
your car can stop the engine just at 00:00:00 1 January_, written by some 
paper dirter, it have a little with the reality.

This is just as with the hackers - anty-hackers systems and filters cause 
not less problems then the hackers themself.

On Thu, 17 Jun 1999, Sean Donelan wrote:

> Date: Thu, 17 Jun 1999 21:15:33 -0500
> From: Sean Donelan <SEAN at SDG.DRA.COM>
> To: rjoffe at centergate.com, nanog at merit.edu
> Subject: Re: Fatty Pipes with Y2K problem - OT humor
> 
> 
> rjoffe at centergate.COM (Rodney Joffe) writes:
> >We have had a significant pipe problem at our Sherman Oaks facility in
> >Los Angeles as a result of a Y2K test failure :-) The staff is currently
> >off-line recovering! Seriously.
> >
> >Sean, one for your book :-)
> >
> >http://www.cbs2.com/news/stories/news-990617-081237.html
> 
> I smell a problem :-)  But hardly the first.  The best one I've heard
> so far was the entire country of Fiji went off-line a few weeks ago when
> the telco was conducting their Y2K test.
> 
> Even if you think everything will work correctly, having a contigency
> plan is still a good idea.  BTW, President Clinton signed an executive
> order setting up the US Y2K coordination center I spoke about at NANOG
> this week.  But guess what, the vendor of the conference bridge the NCS
> uses doesn't have a Y2K readiness statement on their web page.
> 
> And speaking of that, to bring this on topic:
> NOC communications, and communicating during contigency operations.
> 
> During the recent virus/worm scare an old problem has re-appeared.  For
> a variety of reasons some organizations feel the best response to these
> virus/worms is to pull up the drawbridges and shut-off their network
> connections each time a new one makes the rounds.  This also happened
> during the "Morris" Worm ten years ago, and one of the reasons why BBN
> was tasked with creating the Network Manager's Phonebook.  
> 
> I can't ask you to go against your corporate security people. But consider
> planning how to keep a NOC contact up and running when you feel you must
> disconnect the rest of your corporate or agency network.  If you pull the
> plug on your main (only?) mail server, how do you redirect your NOC mail?
> The government backbone networks seemed to do this more than commercial
> networks, but the principle applies to both.
> -- 
> Sean Donelan, Data Research Associates, Inc, St. Louis, MO
>   Affiliation given for identification not representation
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)