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/db-wg@ripe.net/
Parts of blocks, FAQ
- Previous message (by thread): RIPE Database Deletions Automated
- Next message (by thread): No subject
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Karrenberg
Daniel.Karrenberg at ripe.net
Thu Nov 12 12:19:07 CET 1992
The question and answer below might be of general interest. ------- Forwarded Message Date: Wed, 11 Nov 92 16:25:11 +0100 From: Marten Terpstra <Marten.Terpstra at ripe.net> Sender: Marten.Terpstra at ripe.net To: Havard.Eidnes at runit.sintef.no cc: nic at ripe.net Subject: Re: Block vs. single RIPE DB entries Havard.Eidnes at runit.sintef.no writes: * Hi, * * is it possible to both register a block and a single entry as an exception * within that block in the RIPE database, eg. * * inetnum: 192.51.0.0 - 192.51.15.0 * * and * * inetnum: 192.51.5.0 * * and the "right thing" will happen upon lookup using whois? Or is this * method of registration discouraged? It is possible, but when the database is queried for this network, both the block AND the individual entry will appear, causing confusion. The only way to solve this is by deleting the complete block, and sending in smaller blocks that have the right information. In your example if 192.51.5 has different information from all the others, what should happen is to delete the complete block, and send in updates for 192.51.0 - 192.51.4 and 192.51.5 and 192.51.6 - 192.51.15. Not very nice, but the only solution. Maybe in the future we can come up with a (even) more clever solution. - -Marten ------- End of Forwarded Message
- Previous message (by thread): RIPE Database Deletions Automated
- Next message (by thread): No subject
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]