Hi Kevin,
(comments to follow)
"Kevin Oberman" writes:
While there is a great deal of old data that is obsolete, we use the
RADB to configure our routers and also for peering via the route
servers and find few problems that impact operations.
Well, we hope that the amount of obsolete/incorrect/bad data
is small. I don't think anyone really knows from a quantitative
standpoint as the problem is complex. The notion that the IRR
represents current routing policy is not held by everyone, so of
course there will be incorrect data. For example I've known people to
pre-register policy based on changes that are to occur sometime in
the future. Also, people make mistakes and what they register does not
always align with reality. We (merit) have been working on a tool called
PAIR which is designed to help people identify obsolete/incorrect routing
information. PAIR basically compares route announcements as seen at the
route servers to registered policy. Users can check their AS and see what
they are actually announcing, to whom and what they have configured in
the IRR. The routes are colorized, green being good and red (ie, not
announced but registered) and grey (ie, announced but not registerd)
probably indicating a problem. We have been working on quantitative
indicators for incorrect data and hope to have something soon.
I do suspect that a "sunset" clause will be needed some day to clear
out old cruft.
The idea of time-stamping and removing old objects has come up in the
past but has not gotten public support. The other registeries are leery of
crossing the line and taking a measure of resposibility for the db
correctness. The public is leery of giving any third party the power to
delete/update their objects. What if an ISP lost connectivity because
of so called "obsolete data" and then pointed the finger at the registry
administrator?
A sunset clause would have to take into consideration other factors
in order to work. For example, just because an object is old does not mean
it is obsolete or stale. Good data can remain
good for an indefinite period of time. And just because
an object is new does not mean it is good data or up to date (ie,
there is no safeguard in place that dissallows the registering
of incorrect data.)
I do agree with you that it would be nice to implement a system
that would allow the registry administator some power to take
corrective action to remove/update obsolete/incorrect db objects.
I really believe that if the user community really wants to
do something about obsolete information (and I do believe this
is true) then the registries need to have limited power to fix the
situation. The question is what should the power be and under what
situation?
--Gerald