RPSL announcement text

Mailman List Mirror (Read Only)
1

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

2

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/

3

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.