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]/
raw minutes for RIPE35 DB-WG
- Previous message (by thread): raw minutes for RIPE35 DB-WG
- Next message (by thread): draft agenda for DB-WG meeting, RIPE 36, Budapeat
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jake Khuon
khuon at GBLX.Net
Thu May 18 09:43:22 CEST 2000
### On Thu, 18 May 2000 08:38:44 +0200, Randy Bush <randy at psg.com> casually ### decided to expound upon Daniel Karrenberg <Daniel.Karrenberg at ripe.net> ### the following thoughts about "Re: raw minutes for RIPE35 DB-WG": RB> > This is a bad idea. Many people querying the RIPE NCC whois server RB> > do so with the intention to obtain authoritative information from the RB> > RIPE DB, and they get just that by default. Changing this behaviour would RB> > result in a lot of confusion, irritation and serious user support load. RB> > Given the fact that those who want to see data from all sources can RB> > obtain that by just adding '-a' to their queries, such a change is totally RB> > unnecessary. RB> RB> thank you. RB> RB> hint: it will break existing scripts. and one could not even fix them, RB> unless you put in -not-a or something similarly disgusting. The issue here is that the current policy is a requirement for all information pertaining to RIPE allocations to be shown by default. The proposal I made to do first-hit all-source-searching was in response to the above policy. The motivation is that I would like to see some ability for independent distributed registry support whereby any organisation may run their own registry and pull their RIPE information out of the RIPE DB, maintain it themselves in their own registry, and then mirror the information back to RIPE DB servers for query. I myself saw no alternative to acheiving this goal without either changing the default search behaviour in the whois server or changing the policy. I thus chose to propose the technical solution and saw no other technical solution although I would be more than happy to have someone propose something better. BTW, current tools don't do source filtering? -- /*====================[ Jake Khuon <khuon at GBLX.Net> ]======================+ | Network Systems Engineer, Net-Eng/NSM-Arch /~_ |_ () |3 /-\ |_ | | VOX: +1 (408) 543-4828 Fax: +1 (408) 543-0074 \_| C R O S S I N G | +===============[ 141 Caspian Court, Sunnyvale, CA 94089 ]===============*/
- Previous message (by thread): raw minutes for RIPE35 DB-WG
- Next message (by thread): draft agenda for DB-WG meeting, RIPE 36, Budapeat
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]