Hi Piotr,
Correct me if I am wrong, but this is more or less the same what RIPE NCC is doing right now. Allocations are maintained by RIPE-NCC-HM-MNT, organisation objects with org-type field set to LIR are maintained by RIPE-NCC-HM-MNT. Those objects are filled with date coming from both internal database (used also for accounting purposes) and LIR portal. Every year LIRs are paying their invoices, which proves that both email and snail mail addresses provided as billing contacts are working.
But it does not mean that admin-c, tech-c, IRT and all other objects are accurate. For example: We are at the moment just using the delegated information, which is not good but we are working on. Different subject. We see loads of abuse-mailbox attributes not being correct, or giving back a "mailbox full" or "550 - address not existing" We receive at least every second month an email where somebody is asking us why we are sending reports to them, because they are not working for this company for years, but the objects are still linked to the inet(6)num or aut-nums. One of those guys (74 years old) now sued his old company, he worked for until 2002, because they didn't change the whois information on his request for over a year and he was getting frustrated. These are the things that should be faced with this proposal. Another idea could be, that once a year an email is sent to the email address in the person object and person it self has to acknowledge that the information is accurate and so on. If those mails bounce or the customer is not replying within a few days the issue will be forwarded to the maintainer of the netrange. By thinking about this approach I think this could at least work pretty good as well. And the best would be a combination. Sending update request for inet(6)num, aut-num, IRT, ..., Organization Objects to the maintainers and send frequent requests for person objects to the person it self. Sounds more reasonable? Thanks, Tobias