North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: RPSL announcement text

  • From: Alex P. Rudnev
  • Date: Wed Dec 08 14:55:31 1999

Sorry if I wrote something raw; I suspect a lot about your system and do not
complain about it.

I simple want to note that for the ISP engeneers first 2 or 3 weeks after new
year will be very busy, because the Y2K problem is for them accounting, billing,
different forms problem, and every company will have something (may be a little,
may be not in the provision network) to fix or improve.

And you propose to add some extra noise to this process. Are you sure no one
ever use your old data format for the building some filter, etc etc? I am sure
that such programs exists, and if you want to add extra troubles, you are
welcome.

No one is saying you should not change data and request format to the new one;
even if it cause some extra work over the ISP, it has it's own good reasons. But
why choose such interesting moment to do it? Just because it's round date?

> We now have two parallel servers running: our produciton
> (default) server, whois.radb.net which is fully RPSL compliant; and 
> our secondary server, whois-ripe181.radb.net which is running RIPE181.
> We have been running the production RPSL server since November 1 in preparation
> of the phasing out of the RIPE181 server.  So when Jan. 1 arrives nothing
> will change on our production server.
> 
> Finally, as I'm sure you already know, the RIPE181 language is not 
> Y2k compliant (see RIPE-181.ps).  So we made the decision to phase
> out the the RIPE181 server at the last possible moment.
Just again, what it means _is not Y2K compliant_? May be (I did not investigated
it) it has some options unavailable after 1-1-2000, but most data requests (such
as 'whois -h whois-ripe.net AS-RELCOM in case of RIPE, and so on) will work. You
just confirm my suspection - Y2K consist of 10% objective problems, and 90%
problems caused by the people who are ready to turn off networks, shutdown
services, change data withouth understanding what's really happen in Y2K and why
it's better in 90% cases do nothing to prevent extra damage.

Just this case? Are you saying ripe-181 server brtoke itself just in new year
night? Wrong. Do you mean it stop receiving requests and sending answers this
moment (and which moment - NY in Moscow or NY in San Francisco? -:))? If not,
why don't wait extra months to provide extra time for others.

May be I am wrong, but I hjardly suspect this was not very wise decision.


> 
> --Jerry Winters
> 
> 
> 

Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/