This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] Policy Proposal: Frequent Update Reminder
- Previous message (by thread): [anti-abuse-wg] Policy Proposal: Frequent Update Reminder
- Next message (by thread): [anti-abuse-wg] Policy Proposal: Frequent Update Reminder
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Piotr Strzyzewski
Piotr.Strzyzewski at polsl.pl
Thu Oct 7 19:01:52 CEST 2010
On Fri, Oct 01, 2010 at 09:42:02AM +0200, Tobias Knecht wrote: Hi Tobias > > 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. That's true. > 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? A bit more. ;-) IMHO good API to this acknowledge mechanism will be more then necessary. Regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski at polsl.pl
- Previous message (by thread): [anti-abuse-wg] Policy Proposal: Frequent Update Reminder
- Next message (by thread): [anti-abuse-wg] Policy Proposal: Frequent Update Reminder
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]