In message <CAKvLzuELQ8-GjkTnVc7Gk=_jGmdfvuSurH_XmkV71skA6iPADQ@mail.gmail.com> denis walker <ripedenis@gmail.com> wrote:
If this block was transferred from RIPE to APNIC then it is easy to update the placeholder at that moment to make a referral to APNIC. But what if the object is transferred again to another region? The RIPE Database would have to track all transfers, otherwise the referral may become stale information.
You make it sound like this "tracking" is somehow difficult. But I'm effectively doing it every day, day in and day out, based on the daily RIR "stats" files, and it's not actually that hard.
The RIPE NCC effectively already provides this referral service with RIPE GRS. It solves this problem 100% for all RIR administered address space.
The code that I've cooked up does it for 100% of... address space. Period.
Why do we need the NRO to start discussions with IANA on how to fix a problem that already has a fully implemented and working solution?
We don't. At least I don't. I already have what I need. As regards to RIPE's "working solution" all I can say is that it's nothing personal, but personally I don't much feel like relying on any given RIR for data & updates relating to the holdings of other RIRs, especially when the needed data about the holdings of other RIRs can be fetched from those other RIRs themselves directly. There's also some other potentially issues with relying on RIPE for this data, to wit: *) Is RIPE guaranteeing that it will support its interface to this data forever? If not, how long is the commitment? (I am thinking about various OS "Long Term Support" distributions that provide some guarantees that the stuff will still be usable in, say, 5 years from now.) *) Is RIPE guaranteeing that it will -freeze- its interface to this data forever and not make any API changes? *) It seems to me that it is a given that whatever RIPE is distributing / publishing must, by definition, not be as fresh and up-to-the-minute as what the individual RIRs are themselves publishing in their respective daily "stats" files. (If I'm wrong about this, then please do enlighten me.) Regarding that last point, I think that it would be Swell if all of the five RIRs would start updating their respective "daily" stats files in near real-time, i.e. whenever a change is made to any of them. Perhaps RIPE NCC would like to volunteer to be the test case for this. It would also be Swell if these files were provided via rsync, so that local mirrored copies could be usefully updated more than once a day. (Rsync seems especially well suited for this, as the files mostly don't change from day to day, and mostly would not change even from hour to hour or minute to minute, even if they were being updated by the RIRs in near real time.) Again, maybe RIPE NCC might like to lead the way on this. Regards, rfg