Invalid data in the RIPE database
Dear database managers, i had a look at some entries in the RIPE database and at the 'nsf-in' network attribute. For a lot of them the value in the RIPE db is inconsistant with the Merit (NSF) database. Moreover some networks in the RIPE DB have this attribute but are not routed by NSF (for instance 193.128.12/24). It is usefull to keep such data when it can mislead people who use your DB to generate configuration files or aggregate lists? Or can you automaticly generate those values from the NSF database so they will be consistant? Thanks for your answer, Laurent -- Laurent Joncheray, E-Mail: lpj@merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM
----- Text sent by Laurent Joncheray follows ------- Dear database managers, i had a look at some entries in the RIPE database and at the 'nsf-in' network attribute. For a lot of them the value in the RIPE db is inconsistant with the Merit (NSF) database. Moreover some networks in the RIPE DB have this attribute but are not routed by NSF (for instance 193.128.12/24). It is usefull to keep such data when it can mislead people who use your DB to generate configuration files or aggregate lists? Or can you automaticly generate those values from the NSF database so they will be consistant?
I'm not really sure this information is needed in the RIPE database since we can now obtain very easily all the info as seen from Merit with a simple whois. I would therefore propose to either: 1- obsolete this field. 2- Implement what Laurent proposes (automatic download from Merit). Comments ? -- Jean-Michel
I'm also in favour of deleting it as it is not up to date and of little or no real relevance. It would have been useful if NACRs would have been accepted from this object but we never pushed for it to be anything but optional so there you go. --Tony.
Laurent Joncheray <lpj@merit.edu> writes: Dear database managers, i had a look at some entries in the RIPE database and at the 'nsf-in' network attribute. For a lot of them the value in the RIPE db is inconsistant with the Merit (NSF) database...
More radical question: Considering that the NSFnet is going away and the routing registry has routing policy, should these attributes be deprecated or even removed totally? Daniel
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> writes * * > Laurent Joncheray <lpj@merit.edu> writes: * > Dear database managers, * > i had a look at some entries in the RIPE database and at the * > 'nsf-in' network attribute. For a lot of them the value in the RIPE * > db is inconsistant with the Merit (NSF) database... * * More radical question: Considering that the NSFnet is going away and * the routing registry has routing policy, should these attributes * be deprecated or even removed totally? Jean-Michel writes * 1- obsolete this field. * 2- Implement what Laurent proposes (automatic download from Merit). I feel for Daniels and Jean-Michel's first option. They should definately be deprecated (although I have always viewed them as info only attibutes) and preferably removed. Although some people may find this information useful currently, wrong information is worse than no information. I'd say obsolete. -Marten
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> writes * * > Laurent Joncheray <lpj@merit.edu> writes: * > Dear database managers, * > i had a look at some entries in the RIPE database and at the * > 'nsf-in' network attribute. For a lot of them the value in the RIPE * > db is inconsistant with the Merit (NSF) database... * * More radical question: Considering that the NSFnet is going away and * the routing registry has routing policy, should these attributes * be deprecated or even removed totally?
Jean-Michel writes
* 1- obsolete this field. * 2- Implement what Laurent proposes (automatic download from Merit).
I feel for Daniels and Jean-Michel's first option. They should definately be deprecated (although I have always viewed them as info only attibutes) and preferably removed. Although some people may find this information useful currently, wrong information is worse than no information. I'd say obsolete.
I second that one. -- Willem
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> writes * * > Laurent Joncheray <lpj@merit.edu> writes: * > Dear database managers, * > i had a look at some entries in the RIPE database and at the * > 'nsf-in' network attribute. For a lot of them the value in the RIPE * > db is inconsistant with the Merit (NSF) database... * * More radical question: Considering that the NSFnet is going away and * the routing registry has routing policy, should these attributes * be deprecated or even removed totally?
Jean-Michel writes
* 1- obsolete this field. * 2- Implement what Laurent proposes (automatic download from Merit).
I feel for Daniels and Jean-Michel's first option. They should definately be deprecated (although I have always viewed them as info only attibutes) and preferably removed. Although some people may find this information useful currently, wrong information is worse than no information. I'd say obsolete.
I second that one.
-- Willem
I too. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
participants (7)
-
bonito＠nis.garr.it -
Daniel Karrenberg -
jimi＠dxcoms.cern.ch -
Laurent Joncheray -
Marten Terpstra -
Tony Bates -
Willem van der Scheun