raw minutes for RIPE35 DB-WG
Dear DB-WG, attached pleae find a copy of the raw notes as taken by the Scribe. Many thanks to Engin for compiling the notes and sending them shortly after the meeting. The fact that they are still in raw format is exclusively my fault. As I've received offers for help this situation should improve... A more comprehensive version could be posted to the web-site. Please refer to the draft agenda and to tomorrow's wg meeting for more details. Thank you. Wilfried. ______________________________________________________________________ Date: Thu, 2 Mar 2000 11:11:38 +0100 (CET) From: Engin Gunduz <engin@ripe.net> To: woeber@cc.univie.ac.at Subject: Draft minutes of RIPE35 DB WG Hi Wilfried, I'm attaching the draft minutes for RIPE35 DB WG. I couldn't pick up the names of a couple of participants, unfortunately. Also, since they are not on the web site, the URLs of presentations are not complete yet. Regards, -engin Engin Gunduz RIPE NCC DB Group -=-=-=-=-=-=-=-=-=-=-=- RIPE 35 Database Working Group Thursday, Feb 24th Agenda: Slot#1 ,9:00 A. Administrative Stuff (Wilfried Woeber, Chair) B. RIPE DB, operational update (NCC: AMRM, 20 mins) C. A short review on the maintainer mechanism - are there any security concerns? D. A "smarter" whois client E. (tentatively) Is there an interest to register CERT/IRT-related info? Slot#1, 11:00 F. Status of reimplementation project (NCC, JLSD 20mins) G. Transition to RIPE DB v3.0 and transition TF (JLSD & WW, 15 mins) H. Do we need/want a DB review/re-structuring TF - future topics of interest - I/O with other WGs - Logistics Y. Input from other WGs Z. AOB ------------------- Chair: Wilfried Woeber Scribe: Engin Gunduz Participants: 65 A. Administrative Stuff The proposed agenda agreed with an addition of item "D". Scribe appointed, Engin Gunduz. B. RIPE DB, operational update (NCC: AMRM) (presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/...... ) AMRM provided an update on: - Performance - Software status - Reimplementation - Other RIPE DB services - ripe-dbm mailbox - Operational issues C. A short review on the maintainer mechanism WW: 1. There was a useful presentation by Olaf (Kolkman) about PGP. DB is an example for PGP being used with weaker authorisation methods. Has anybody used PGP? (4 people raised their hands). 2. CENTR activity. We've been talking about removing domain objects from whois db. Do you have any timing for this? AMRM: This is a political question, please ask this to Joao. D. A "smarter" whois client WW: Technical framework: NCC has offered mechanism to referral mechanism. This is working nicely. The central whois server has to act as a proxy. But, whois client needs to know whois.ripe.net. Now, we can have a client who tries to find a TXT field from DNS, so that it would know which whois server to query. We may ask NCC to implement this. What do you think? Should NCC spend resources for this? We will chase this issue. Peter Koch: There was some intelligence in one of the old RIPE whois clients which enabled it to query whois-<tld>.ripe.net. AMRM: We don't know about this. E. Is there an interest to register CERT/IRT-related info? WW: Background: It's becoming more frequent that people are abusing network resources. Now, how would you find out whom to contact in such cases? Proposal: We can have a mechanism to point the user to a proper point. Would anybody be volunteer for a blueprint? AMRM: In roles, we have "trouble" attribute. This is for such cases. But I think you mean a more sophisticated thing. Former chair of FIRST: You must be in FIRST organisation. (Break) Slot #2: (11:00) F. Status of reimplementation project (NCC, JLSD) (presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/...... ) Questions: Jake Khoun: There are three-five groups trying to implement RPSL. Isn't it possible to create a subgroup to coordinate activities? JLSD: We tried to bind people together. WW: This is a good input. We can found (a top level, not local) an open forum. RIPE NCC employees can follow ARIN & APNIC mailing lists. WW: More than 50% of the objects in the RIPE whois DB are not exactly related to RIPE, being an IP registry. JLSD: It will be hard to find a solution to this. Domains are growing extremely fast. We are trying to find a solution. We have talked to DENIC & Norwegian domain registry, they are going to move their objects. They expect to get their domain objects in approximately 3 weeks, and person objects in 2-3 months. We are happy to help them. So, I just ask for coordination here. If you want to delete your domain objects, please let us know. We have referral mechanism, we can use it. Jake Khoun: I had a proposal: The behaviour of whois server could be to search all sources, instead of only RIPE source, and, to stop at the first match. David Kessens: I think the main reason for current default behaviour was to save computer resources. But I don't think that this is the case anymore. We must be able to change the default behaviour. But I don't like the idea of stopping at the first match. G. Transition to RIPE DB v3.0 and transition TF (JLSD & WW) WW: Who is in general think that they will be hit by new interfaces? (Three persons raised their hands, Jake Khoun, Nigel Titley, and one more person). WW: So, could we count on you to form a Transition Task Force? JLSD: We can use db-beta list for this. WW: We will get back to you about this before May. JLSD: Agreed. WW: Another point: There was a bug report on security of RIPE DB software. JLSD: The mntner "feature" was already there. Finally the community say that it is a bug. But at this point of time, there is no point in fixing this in the old DB. A participant: Is it difficult to fix this? JLSD: The question is, should we divert the resourses to it or not. Jake Khoun: The actual fix would be to put proper mntners to objects. WW: There was a report on some unauhorised changes to objects. So, nobody must have unprotected objects in the DB. Now, should we tell the users that they must use at least CRYPT-PW, but not MAIL-FROM? Dmitry Morozovsky: RIPN does not put unprotected objects in their DB. Can RIPE do that with the reimplementation? WW: We must have the social engineering first, I think, e.g., putting a text in ACK messages which says that the MAIL-FROM authorisation is not good enough. AMRM: Some users just don't read ACK or notification messages. Jake Khoun: There should be enough emphasis on using CRYPT-PW & PGP instead of MAIL-FROM. Action Point: on NCC to draft a proposal. H. Do we need/want a DB review/re-structuring TF WW: I'm looking for someone to help me documenting our achievements. I don't have time to do proper documentation. Please any volunteer find me in breaks. WW: What should be the future of the DB WG? I'd like to get some input on what should we have as a charter? What are we supposed to do. Please think about your personal priorities, and provide input. Apologies for no minutes. Y. Input from other WGs No input. Z. AOB There wasn't any other business. Chair thanks to participants and closes RIPE35 DB WG meeting. -=-=-=-=-=-=-=-=-=-=-=-
At 20:31 17-5-00 , Wilfried Woeber, UniVie/ACOnet wrote:
Jake Khoun: I had a proposal: The behaviour of whois server could be to search all sources, instead of only RIPE source, and, to stop at the first match.
David Kessens: I think the main reason for current default behaviour was to save computer resources. But I don't think that this is the case anymore. We must be able to change the default behaviour. But I don't like the idea of stopping at the first match.
This is a bad idea. Many people querying the RIPE NCC whois server do so with the intention to obtain authoritative information from the RIPE DB, and they get just that by default. Changing this behaviour would result in a lot of confusion, irritation and serious user support load. Given the fact that those who want to see data from all sources can obtain that by just adding '-a' to their queries, such a change is totally unnecessary. Daniel
This is a bad idea. Many people querying the RIPE NCC whois server do so with the intention to obtain authoritative information from the RIPE DB, and they get just that by default. Changing this behaviour would result in a lot of confusion, irritation and serious user support load. Given the fact that those who want to see data from all sources can obtain that by just adding '-a' to their queries, such a change is totally unnecessary.
thank you. hint: it will break existing scripts. and one could not even fix them, unless you put in -not-a or something similarly disgusting. randy
### On Thu, 18 May 2000 08:38:44 +0200, Randy Bush <randy@psg.com> casually ### decided to expound upon Daniel Karrenberg <Daniel.Karrenberg@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@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 ]===============*/
participants (4)
-
Daniel Karrenberg
-
Jake Khuon
-
Randy Bush
-
Wilfried Woeber, UniVie/ACOnet