A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on January 1, 2000, the transition to the Routing Policy Specification Language (RPSL) database will be complete. After January 1, RIPE-181 object submissions will no longer be accepted. RIPE-181 submissions made between now and 1/1/2000 will continue to be visible on whois.radb.net as RIPE-181 objects converted to RPSL. Availability of the database in both syntax languages eases the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL. RIPE-181 queries will be possible until January 1 via whois queries to whois-ripe181.radb.net. However, you will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net. For more information, see: http://www.merit.edu/radb/announce.html Please send questions or comments to db-admin@radb.net. --Gerald Winters Merit IRRd team
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? On Tue, 7 Dec 1999, Gerald Andrew Winters wrote:
Date: Tue, 7 Dec 1999 16:59:25 -0500 (EST) From: Gerald Andrew Winters <gerald@merit.edu> To: nanog@merit.edu, radb-announce@merit.edu Cc: irrd-team@merit.edu Subject: RPSL announcement text
A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on January 1, 2000, the transition to the Routing Policy Specification Language (RPSL) database will be complete. After January 1, RIPE-181 object submissions will no longer be accepted.
RIPE-181 submissions made between now and 1/1/2000 will continue to be visible on whois.radb.net as RIPE-181 objects converted to RPSL. Availability of the database in both syntax languages eases the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL.
RIPE-181 queries will be possible until January 1 via whois queries to whois-ripe181.radb.net. However, you will need to *RECONFIGURE* your tools to explicitly query whois-ripe181.radb.net and send RIPE-181 submissions to auto-ripe181.radb.net.
For more information, see:
http://www.merit.edu/radb/announce.html
Please send questions or comments to db-admin@radb.net.
--Gerald Winters Merit IRRd team
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
On Wed, 8 Dec 1999, Alex P. Rudnev wrote:
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?
Maybe that manager didn't believe that there were actually going to be any problems come Y2K, and wanted to make sure he was getting his money's worth from his engineers :)
A reminder for users of the RADB database service: at 12:00:00 a.m. EDT on January 1, 2000, the transition to the Routing Policy Specification Language (RPSL) database will be complete. After January 1, RIPE-181 object submissions will no longer be accepted.
RIPE-181 queries will be possible until January 1 via whois queries to
This doesn't actually make much sense...it says that the -submission- system will be changing, but then that -queries- will be possible until that date. Is it one, the other, or both? -- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre
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
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/
And show me please what's Y2K uncompliant in this, for example: whois -h whois-ripe181.ra.net AS701 aut-num: AS701 as-name: AMUFSOFU descr: Alternet admin-c: Not available tech-c: See MAINT-AS701 mnt-by: MAINT-AS701 changed: DB-admin@merit.edu 950201 source: RADB ??? _Changed_ field is here the only suspected field, and 99% software don't use this field in the request development. And so on. If some product is not 100% Y2K ready, it does not mean it can't work in 2000 year. And vice versa, btw. may be, someone from nanog have some statistic showing how people are stopping to use old ripe181 server and begin to use new one? If really a few use old interface, I apologize. Alex R.
And so on. If some product is not 100% Y2K ready, it does not mean it can't work in 2000 year. And vice versa, btw.
may be, someone from nanog have some statistic showing how people are stopping to use old ripe181 server and begin to use new one? If really a few use old interface, I apologize.
More to the point, if there's such a Y2k problem with this software/protocol/format, then why aren't RIPE (the original authors) running around changing to RPSL? Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
I'v checked a more docs; may be I was wrong because 90% of this programs requested whois data are not sesitive to the RIPE181-RPSL data change. If so, sorry. Alex. On Wed, 8 Dec 1999, Simon Lockhart wrote:
Date: Wed, 08 Dec 1999 20:28:46 +0000 From: Simon Lockhart <simonl@rd.bbc.co.uk> To: Alex P. Rudnev <alex@virgin.relcom.eu.net> Cc: Gerald Andrew Winters <gerald@merit.edu>, irrd-team@merit.edu, nanog@merit.edu Subject: Re: RPSL announcement text
And so on. If some product is not 100% Y2K ready, it does not mean it can't work in 2000 year. And vice versa, btw.
may be, someone from nanog have some statistic showing how people are stopping to use old ripe181 server and begin to use new one? If really a few use old interface, I apologize.
More to the point, if there's such a Y2k problem with this software/protocol/format, then why aren't RIPE (the original authors) running around changing to RPSL?
Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
Aleksei Roudnev, (+1 415) 585-3489 /San Francisco CA/
the operational issue is not y2k this or that. the issue for ops folk is that it is a change being made during what is anticipated to be the worst part of the the y2k window which could be made some other time. this means that, if it is visible in any way, it can be confused with y2k symptoms thus adding to real operators' (as opposed to nanog posters') debugging problems at what may be a bad time. randy
Simon, On Wed, Dec 08, 1999 at 08:28:46PM +0000, Simon Lockhart wrote:
More to the point, if there's such a Y2k problem with this software/protocol/format, then why aren't RIPE (the original authors) running around changing to RPSL?
Because they already fixed RIPE-181 and made the rather trivial change from a 6 digit date field to a 8 digit date field some time back. This is not to say that it doesn't make sense for them to switch to RPSL, but Y2K issues are not the thing that requires them to do so. David K. ---
participants (6)
-
Alex P. Rudnev -
David Kessens -
Gerald Andrew Winters -
Patrick Evans -
Randy Bush -
Simon Lockhart