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%
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? 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/