Hmm, who was this clueless manager who decided to do such things in the 1-th of January. I guess the programmers over the world will be very busy during january looking for the hidden Y2K bugs and fixing it, and why RADB decided to add some more troubles just in this days? Why don't wait until, at least, February? What terrible happen if this changes will be delayed a little?
Thanks for your comments. I'm not sure how much you know about our system so I'll give you the basics. We are in the tail end of a long process to convert the IRR here at merit from RIPE181 to RPSL. The conversion process is outlined in the following draft: ftp://ftp.isi.edu/internet-drafts/draft-ietf-rps-transition-02.txt The draft was authored collectively from the community including RIPE, MCI/CW, and ISI. We have been following the guidelines as set forth in this document. As we proceed along the conversion process we have kept the community informed by speaking at the popular conferences. This has given the community many opportunities to voice their feedback and to have a say in the process. We also have an open communication link to the major ISP's who have been informed well in advance of the coming changes and are working with us to implement the conversion process. 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. --Jerry Winters