- db-wg - mailman.ripe.net

setuid dbupdate
by Gabor Kiss 06 Dec '96

06 Dec '96

Dear Ambrose, The ripe-dbase-2.0.4/README file writes: - perl has some build in checks for suid perl scripts. These are all taken care of, so dbupdate should not complain about not being able to do things because it is running suid or sgid. Have a look in the code for dbupdate to see what silly things one has to do to get around these checks ... kissg writes: This is not enough. ;-) Under Solaris 2.5, and with ... This is perl, version 5.003 with EMBED built under solaris at Sep 17 1996 16:40:19 + suidperl security patch I get: "Insecure dependency in open while running with -T switch at /usr/local/whois/lib/addkey.pl line 52." 52: if (open(OVERFLOWADD, ">>".$db[1].$OVERFLOWEXTENSION.$value)) { I tried at least six different tricks to avoid this message. No success. (Hardcoded direct setuid C wrapper is not included in the six.) Any suggestion? Gabor

2 1

None
by Paul Libauer 14 Nov '96

14 Nov '96

subscribe

1 0

Re: [RADB #2390] RADB Timezone
by sds＠jazzie.com 13 Nov '96

13 Nov '96

Gerald Winters suggests (see below) that this work group might be a good place to discuss the timezone used when calculating a proper date for the changed: field of RADB objects. Is there a valid rationale for the RADB's use of a local timezone rather than Universal Time? If not, can this work group make a recommendation (formally or otherwise) to the RADB suggesting Universal Time be used to calculate the date for this field? The other inter-registry consistency issues Gerald mentions are likely important too, but this one seems ... totally without controversy. Or am I missing something? -- Sean Shapira sds(a)jazzie.com +1 206 443 2028 Gerald A. Winters (gerald(a)merit.edu) > > Sean, > > Actually there are some good reasons to use universal > time. For example, we import the ripe registry and they > are not using EST as we are. So there is some conflict > there. > There has been talk of enforcing consistency among the > registries (ie, aut-num policy, maintainer registration, ...) > and the changed date (ie, time-stamping) will undoubably play > an important role. > I think the changed data is ignored to a certain extent because > humans supply the date and not the software. The software only > checks for dates in the future, I believe, but will accept dates > in the past. So the changed date is more like a hazy indicator > rather than a precise time stamp. You know the the real/exact > changed date is <= to the actual changed date. > The place to bring this point up is at the RIPE meetings > to the data base working group. > > --Gerald > > Sean Shapira writes: > >In response to a recent RADB update request I received: > >> WARNING: date in "changed" (961113) is in the future - changed to 961112 > > > >The trouble? I'm guessing auto-dbm(a)ra.net was using Eastern > >Standard Time; I was using Universal Time. It seems a window > >of vulnerability exists during which auto-dbm has an incorrect > >idea of the "one true date" ;-). > > > >Seriously, as the global route registration database of last > >resort, doesn't using Universal Time in the RADB make sense? > > > >-- > >Sean Shapira sds(a)jazzie.com +1 206 443 2028 > > Serving the Net since 1990. > > -- > Gerald A. Winters gerald(a)merit.edu > Merit Network, Inc. (313) 747-3522 (office) > 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) > Ann Arbor, MI 48105-2785

2 1

Telnet interface to the RIPE database.
by RIPE Database Administration 13 Nov '96

13 Nov '96

Dear Colleagues, If you use the telnet interface to the RIPE database, please note that a "-k" option is available. This will keep the connection open until you close it yourself. Example: ------- [ambrose] $telnet whois.ripe.net 43 Trying 193.0.0.194... Connected to dbase.ripe.net. Escape character is '^]'. -k Ambrose Magee % Server is running at low priority for -M, -m and -k queries person: Ambrose Magee [...stuff deleted...] source: RIPE -T route 193.0.0.0/24 route: 193.0.0.0/24 [...stuff deleted...] source: RIPE -k Connection closed by foreign host. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Version 2.0.4 of the RIPE Database Software.
by RIPE Database Administration 12 Nov '96

12 Nov '96

Dear Colleagues, Version 2.0.4 of the interface software for the RIPE database is now available at ftp://ftp.rip.net/ripe/dbase/software/ripe-dbase-2.0.4.tar.gz . This new version has the following changes: enparse.pl and enread.pl have been improved to fix the problem of empty attribute lines; whoisd.pl has been changed to give clearer error messages for the "-s" and "-k" options; src/Makefile has been improved in a few minor ways. I wish to thank David Kessens for sending patches for the above files. If you have any problems, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TEST database.
by RIPE Database Administration 12 Nov '96

12 Nov '96

Dear Colleagues, You can now create your own maintaininer objects in the TEST database. You do not need to send them to <ripe-dbm(a)ripe.net> anymore. If you have more problems, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TROTS -- RIPE Database questionnaire
by ppbakke＠cs.vu.nl 06 Nov '96

06 Nov '96

Dear reader, This questionnaire is sent to you by the TROTS project team. This team, consisting of students from the Vrije Universiteit Amsterdam, is currently looking at the RIPE database and hopes to gain some information on how users employ this database, and on what their attitude towards this database is. We would appreciate it if you could find time to sit down for a moment and fill in the questions that are in this questionnaire. The questions are set up in such a way that it doesn't take much time to answer them. The outcome of our project might help the RIPE NCC together with the RIPE Database Working Group to make a better database and improve the quality of its services. Thank you in advance, The TROTS project team. INSTRUCTIONS: If you find brackets under a question (i.e. [ ]), you can fill in a 'x' for the appropriate answer (i.e. [x]). If you find a word, followed by a semicolon (i.e. 'answer:'), you can write down your answer after it. (i.e. 'answer: this is my answer') We would appreciate it if we receive your reply before Wednesday, November 13th 1996. ========================= THE QUESTIONS ========================= -> SECTION I: INTRODUCTION 1. Who are you? (optional) Company name: Name: 2. What is your function? (optional) [ ] Network administrator [ ] Network technician [ ] Other, namely: 3. How do you use the database? [ ] for updates and queries. -> GOTO Section II [ ] only for queries. -> GOTO Section III [ ] I do not use it. -> As a last question: can you tell us why not? Answer: -> SECTION II: UPDATES 1. What kind of updates do you perform? [ ] in the assignment registry [ ] in the routing registry [ ] both 2. How do you grade making updates by the e-mail interface in the database? [ ] easy [ ] not so easy [ ] indifferent [ ] not so hard [ ] hard 3. Do you know what templates stand for and how to use them? [ ] Yes [ ] No [ ] I do not know what is meant by this question 4. How do you fill in the templates? (you can fill in more than one answer) [ ] by hand [ ] by applications (which: ) [ ] by applications that I wrote myself (for what: ) 5. When changing an object, do you always delete older objects or objects that are not referenced anymore? If not, can you tell us why? [ ] Yes [ ] No, because [ ] I have no time [ ] it is too much of a hassle [ ] do not know how [ ] other: 6. Do you always update the database when the facts change? If not, can you tell us why? [ ] Yes [ ] No, because [ ] I have no time [ ] too much of a hassle [ ] do not always know that facts have changed [ ] other: 7. Are there any routing policies which you would like to adopt, but cannot represent in the database? If so, which ones? [ ] No [ ] Yes, namely: 8. Can you give us an indication on how many updates you perform per month? [ ] less than 10 [ ] 10 - 50 [ ] 50 - 100 [ ] more than 100 -> SECTION III: QUERIES 1. How do you make queries? [ ] By using whois [ ] By using the RIPE tools (like prtraceroute) [ ] I run applications that make use of it (other than tools of RIPE) 2. What do you make queries for? [ ] trouble shooting [ ] making routing tables [ ] other, namely: 3. Do you ever encounter ambiguous/inconsistent data while making queries? If so, can you give us examples and a rate of how often this happens? [ ] No. [ ] Yes, namely: 4. Can you always find what you are looking for? [ ] Yes. [ ] No -> Can you give examples of what you could not find? Examples: 5. Do you miss any data that you would like to see added? If so, can you state which? [ ] No. [ ] Yes, namely: -> SECTION IV: GENERAL 1. How useful do you consider the database? [ ] I could not live without it. [ ] It is a nice feature. [ ] It's not very useful. 2. How would you grade the overall quality of the database on a scale of 1 to 5 (5 being the best) ? [ ] 1 [ ] 2 [ ] 3 [ ] 4 [ ] 5 3. Do you have any remarks you want to add? Remarks:

1 0

Finger tool to get a NIC handle.
by RIPE Database Administration 05 Nov '96

05 Nov '96

Dear Colleagues, You can no longer use `finger handle.YOURINITIALS(a)whois.ripe.net' to obtain the next free NIC handle. You will only get a message about using the `AUTO' NIC-handle mechanism. This finger tool was shut down because it could give NIC-handles with more than 4 characters in the initials and more than 11 characters in total. Furthermore, it placed an unacceptable (and unnecessary) load on the whois server, particularly at peak times. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TEST database.
by RIPE Database Administration 28 Oct '96

28 Oct '96

Dear Colleagues, The TEST database is working again. Thank you for your patience. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

TEST database is tempoarily out of order.
by RIPE Database Administration 26 Oct '96

26 Oct '96

Dear Colleagues, The TEST database is temporarily out of order. It will be fixed as soon as possible. Regards, RIPE Database Administration.

1 0

Re: List of known bugs.
by Wilfried Woeber, UniVie/ACOnet 22 Oct '96

22 Oct '96

= > > =keep an exception for NEW only ... = > > Not just *another* exception please !! = > = > Agreed. I used dots for a reason ;-). = > I would prefer to use another uncommon word or a clear separator. I just = > don't like case sensitivity lazy as I am... = =How about 'createobj'? =Not very likely to be a common word in subject lines. I could live with that. =the other possibility is to do away with the subject line stuff =and create a real command interface. Actually I prefer the latter. Me too. It would be much cleaner and the password:-line mechanism was the first step into that direction, true ? Wilfried.

1 0

Re: mnt-nfy
by zsako＠banknet.net 21 Oct '96

21 Oct '96

> From owner-db-wg(a)ripe.net Fri Oct 18 08:19:02 1996 > In my opinion notifications should *not* be sent to the originator of > the change request. We had too many complaints about too many > notifications. Those wishing to receive notifications of their own > changes can easily achieve that by putting an alias mailbox into their > notification attributes. I think I have no problem with the above (I mean I will not argue in favour of changing this). > Note also that this smartness quite consciously introduces less > 'security' because it allows someone to make clandestine changes by > forging his From:-address to avoid notification. We did this because > those with really high security requirements shoud use maintainers with > a stronger authentication menthod. Correct. However I originally noticed that this "feature" also works by adding a Reply-to: in the header... My point at the RIPE meeting was that when sending an update with a Reply-to, the mnt-nfy DOES get a "warning" message, that somebody made SOME updates, (since the "Congratulations" are sent to her), but has no clue wrt. WHAT exactly has been modified (usually the Subject: line does not provide accurate information - if at all)... (Of course, the situation can be even worse if the From: line is forged...) If I remember correctly, at the DB-WG session the absence of the notification (in the Reply-to case at least) was considered a *bug*. I still incline to consider the "Reply-to case" a bug (or *unwanted* feature). Forging the mail header is usually less trivial than adding a Reply-to. The latter can even occur inadvertently (this is how I discovered all the above). Janos PS. I suppose (and strongly hope :)) the authentication is based on the From: and not the Reply-to:.

3 2

Re: List of known bugs.
by Wilfried Woeber, UniVie/ACOnet 21 Oct '96

21 Oct '96

=I have a couple of comments on things that you list as bug that might =sometimes be better listed as a feature or are not as a bug at all...: But then at least as an undocumented wiseguy approach. Sorry for the sarcasm, but we seem to be doing some reverse intent engineering these days.. =under persons: = => 2/. FEATURE => Titles such as "Dhr" will be interpreted as names; a request => to create a person object for "Dhr J Russell" will receive => a nic-hdl = DJR#-RIPE, not JR#-RIPE. => => 3/. FEATURE => Titles such as "Mr" will be rejected. = =2 & 3 are the same issue. The software has a built in list of common =titles. However, such a list can never be complete and making it complete =might hurt people that speak other languages and that might have a common =title in one country as their first name in their local language. =Therefore I included a short list (that contains Mr(s)/Dr among others) =that would catch most of the problems. Of course, any very common title =that I forgot can be added if desired so. I have to think about that. PArt o fme likes the approach, the other one thinks it's a *very* bad idea to have potentially different reject lists. How does that interact with NRT-Mirroring in particular and object exchange in general? Shouldn't that move to somehow, somewhere into the update interface, and maybe be made controllable? => 4/. A person object may be created with a nic-hdl of the form => ASxxxx, even if there is an aut-num object with the same => AS number. A whois enquiry on ASxxxx will retrieve both => objects. = =What's the bug here ? It is perfectly valid to have AS# as your InterNIC =handle and it can indeed also be a valid AS number at the same time: = =$ internic AS100 =Sackheim, Andy (AS100) andys(a)DAVSYS.COM =daVinci Systems, Inc. =5410 NW 33d Ave Suite 100 =Ft. Lauderdale, FL 33309 =(305) 484-8100 Agreed. No bug. We have the -T flag to control the software behaviour. =In the past there was a bug in the database software that would regard =AS# as an AS number and thus wouldn't look up any persons that had the =same AS# as their NIC handle. = => 5/. The Auto-Nic-Hdl mechanism allows a maximum of four initials. => => However, when using the finger handle mechanism, => a RIPE nic-hdl may be generated which has more than 11 => characters e.g. => => ambrose $finger => handle.AMBROSE(a)whois.ripe.net => => gives => => First free handle: AMBROSE251-RIPE. = =I think that the limit of four is a healthy limit. This limit can be =increased if desired. No, I think 4 is definitely the maximum. If we had enforced a limit of 3, we wouldn't have had less ambiguity with AUTO-x and the like. But now it's 4, so let's stick with it. =It seems that the bug is in the finger tool, not in =the Auto_Nic-hdl mechanism. The problem here is that there is never =decided about a formal limit on the number of initials. = As the finger tool is to be decommissioned anyway, so what. => 6/. When a pseudo-person object is deleted, and its nic-handle used => in a genuine role object, the role object is not found using a => recursive look-up, even though it is in the database. = =This is not true. The problem some people might have had was: = =role objects are not allowed in 'admin-c:' fields as decided by the =database workinggroup. The software is optimized to not do unnessecary =lookups and will thus not do a lookup for a role object in 'admin-c:' =fields. Another wiseguy approach. We know, that we cannot guarantee integrity. Unless we change the very basic maintainance model, that is. Thus the SW should *not* imply integrity = The real bug is thus that there is no check that disallows the =use of role objects in 'admin-c:' fields, this is not possible right now =due to the lack of the 'non-existing references' checking (which is a =known problem!). The problem can be softened by changing the config file =and allowing role objects in the 'admin-c:' fields (for lookups). That's exactly the other way 'round. Note that we had input recently from other WGs to tighten the rules and have the SW enforce the decisions. =However, this defeats the decision made by the database working group for =not allowing role objects in the 'admin-c:' field... We have discussed that and I expect some activity towards closing that gap in the foreseeable future. =In all objects: = => 1/. The "NEW" keyword is case insensitive. If it appears anywhere => in the Subject line of an update, the update will be disallowed => with the message "ERROR: object already exists". => => E.g. an update with the following in its header: => => Subject: Old person object, but new address. = =This is a feature but probably not a very desirable one... I agree, about the not very desirable :-) =I think it is =a good thing to keep the keywords case insensitive (this was also the case =for LONGACK), It depends, see below =however something a less common word then NEW could solve =this problem just like LONGACK (nobody is using that in real life ;-)) or =keep an exception for NEW only ... Not just *another* exception please !! My preference would be for a real solution. Enforcing UPPERCASE is the minimum. I'd even vote for addtional constraints, like FLAG only being recognized at the very begging/end of the line, or even requiring some special characters to surround the FLAG string. Pick your favourite convention, like double quotes, html brackets,... =In routes: = => 2/. RIPE-181 states that the guardian attribute is mandatory in the => aut-num object. However, it is optional in the database => template. = =This is change decided by the database working group some time ago. =Some people would like to go even further and would like to obsolete the =attribute altogether or convert it to 'notify:' attributes. Unless I forget, I'll put it on the agenda for the January RIPE Meeting to obsolete it. => 3/. RIPE-181 states that "Whenever a route object is => created or deleted or => the comm-list attribute changes, the guardians of all communities and => ASes referenced by the old and new objects will be notified in addition = =The 'guardian:' attribute is behaving exactly as a 'notify:' attribute. =From the 2.0 release notes: = =- All support for the historical 'guarded' objects have been removed. The = guardian attribute can be obsoleted if the database working group = wishes to. Present guardian attributes will act as a 'notify:' attribute. Ditto. Another source for complexity. = =In inetnum: = => 2/. An inetnum object may be created with an range limit of => *.*.*.* - 255.255.255.255; a warning will be generated, => but the entry will be allowed. = =This can be solved with an hierarchical authorization 'inetnum:' object. For that special case I agree. =I don't think it's a good idea to include thousands of specific tests for =problems that happen only once in 1,000,000 updates. These kind of tests =tend to cause more harm then solving anything: If you disallow =255.255.255.255 people can still do 255.255.0.0 or 10.0.0.0 - 194.0.0.0. = =However, in *all* cases the software will issue a warning that you used a =very large range and asks the user to check if that was intended. This =should catch most of these problems. Furthermore, this kind of errors is =so obvious that other people will report it very, very soon when found as =happened recently ... Again, I don't support throwing in more tests at random. Instead I'd like to see structural tests that can be defined, implemented easily (concept-wise) and enforced by the IR rules. E.g. addess ranges must not overlap each other and should be in line wity registry allocations, etc. We're discussing this issue already. =In maintainer objects: = => 1/. Use of MAIL-FROM authorisation: => => use the full e-mail address gievn in the "From" field of => the mail header of the update message. = =This is not true. You may use part of the E-mail address, however be =warned that the matching is done case-sensitive as specified by RFC822 =(this is in fact sometimes a very nice security by obscurity mechanism ;-)) Well for the "nice" :-/ Is this in line with the notfication suppression logic? I don't think this is a good idea at all. Even if it's in the Books, what do we want to achieve by trying to enforce it? I think reality in the Mail environment is (mostly) caseINsensitive these days... =David K. Comments, please! Cheers, Wilfried.

3 2

Re: mnt-nfy
by zsako＠banknet.net 21 Oct '96

21 Oct '96

> From davidk(a)isi.edu Fri Oct 18 18:33:24 1996 Dear David, > > My point at the RIPE meeting was that when sending an update with a Reply-to, > > the mnt-nfy DOES get a "warning" message, that somebody made SOME updates, > > (since the "Congratulations" are sent to her), but has no clue wrt. WHAT > > exactly has been modified (usually the Subject: line does not provide accurate > > information - if at all)... > > This is true. You will receive less information then with a notification > message in this case. This is clearly a disadvantage, but also an > advantage for those people that are getting a bit tired of the amount of > mails coming from the RIPE database automatic department. OK. I understand now, this really IS a feature. > > > (Of course, the situation can be even worse if the From: line is forged...) > > But you will always get at least one message from the database whether it > is an ACK message or a notify message. The smartness only eliminates more > mails sent to one and the same E-mail address. And again <ripe-dbm(a)ripe.net> > is always willing to investigate with the maillogs if you suspect > someting like this (in fact I *did* found a forgery once and I can assure > you that the person that did it will not do it another time ...) In fact I knew the NCC has very good logging (I once had to use this "service" :) ), but I thought we could spare some investigation. However, if such "errors" are infrequent, I agree it is not worth changing the behaviour. > > > PS. I suppose (and strongly hope :)) the authentication is based on the From: > > and not the Reply-to:. > > I can tell you from first hand experience (that is the code is > implemented as required in the specs) that the authentication is done on > the From: field and nothing else then that. This is what I wanted to hear, thank you. :) (I do not worry any more). Thanks again and regards, Janos

1 0

MAIL-FROM Authentication scheme.
by RIPE Database Administration 18 Oct '96

18 Oct '96

Dear Janos Zsako, I wish to draw your attention to ripe-120. There, under "Authentication Schemes; MAIL-FROM" it states: This authentication method checks the content of the RFC822 From: header of an update request against the regular expression specified as <auth-info>. As Daniel has already stated, those with really high security requirements shoud use maintainers with a stronger authentication menthod. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

mnt-nfy
by Domain registration staff 18 Oct '96

18 Oct '96

Dear folks, Recently I found that RIPE DBM doesn't send me notification about changes of guarded objects (e.g. AS1955). Specially I send updates from the address to notify. The version 2 software is so smart, that knows that no use to notify the sender itself, or this is some bug? Regards Gabor Kiss

3 2

List of known bugs.
by RIPE Database Administration 17 Oct '96

17 Oct '96

Dear Colleagues, A list of known bugs in the software for the interface to the RIPE database is now available at: ftp://ftp.ripe.net/ripe/dbase/bugs Please send comments to <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 1

Re: mnt-nfy
by zsako＠banknet.net 17 Oct '96

17 Oct '96

> From owner-db-wg(a)ripe.net Thu Oct 17 16:13:02 1996 Gabor, > Recently I found that RIPE DBM doesn't send me notification about > changes of guarded objects (e.g. AS1955). Specially I send updates from > the address to notify. The version 2 software is so smart, that > knows that no use to notify the sender itself, or this is some bug? I have raised this issue in the DB-WG at RIPE-25. It was definitely considered a *bug* (not a feature :)). I was asked to repeat the experiment and send a "warning" message with the details to ripe-dbm(a)ripe.net soon after that, in order to help them identify the problem. I apologise publicly, because I must admit I forgot to do so... Regards, Janos

1 0

Re: Short summaries of WG sessions [DataBase]
by Gabor Kiss 11 Oct '96

11 Oct '96

> Input received from the DNS-WG asked for a referral mechanism in the > RIPE-DB to support registering 2nd and lower level domain objects at the > site of a TLD Administration, but still offering access with whois by way > of the RIPE-DB. There was a reasonable number of TLDs represented that > promised support on their end for implementing that approach. > > The decision reached calls for an interim solution to add a referral > mechanism to domain: objects. This would only be used in (TLD) domain: > objects that describe the TLD and point to the authoritative DB that holds > the 2nd and any lower level data. Who are working on the referral mechanism? Is there some info on the net about the current state? I've a few idea and I don't want to reinvent the wheel. ;-) Gabor

2 1

Re: Short summaries of WG sessions [DataBase]
by Wilfried Woeber, UniVie/ACOnet 11 Oct '96

11 Oct '96

Hi Gabor ! => The decision reached calls for an interim solution to add a referral => mechanism to domain: objects. This would only be used in (TLD) domain: => objects that describe the TLD and point to the authoritative DB that holds => the 2nd and any lower level data. = =Who are working on the referral mechanism? =Is there some info on the net about the current state? Please see: Subj: 2nd draft, minutes of DB-WG meeting at RIPE 25 [ ... ] Action (9) on RIPE NCC (Ambrose Magee, Carol Orange, Daniel Karrenberg), To propose and implement (a.s.ap.) a referral mechanism for TLD domain: objects (only). And Daniel's comment: To: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> CC: db-wg(a)ripe.net Subject: Re: 2nd draft, minutes of DB-WG meeting at RIPE 25 From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> Date: Thu, 10 Oct 1996 18:01:55 +0200 > DNS: > > Janos Zsako thought that the referral should be implemented in the server n > ot > in the client! Definitely! =I've a few idea and I don't want to reinvent the wheel. ;-) = =Gabor Please keep us posted, either in private or on the db-wg list. Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

draft minutes of DB-WG meeting at RIPE 25
by Wilfried Woeber, UniVie/ACOnet 10 Oct '96

10 Oct '96

This is the 1st draft of the minutes for the DB WG meeting at RIPE 25. I expect to add a couple of URLs to point to presentations as soon as they might become available from the RIPE FTP-Server. The Action List probably needs renumbering, to get it aligned with the summary notes for the plenary. As always, all comments, input and improvements welcome. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- Minutes for the DB WG meeting RIPE 25, Amsterdam, NL **1st DRAFT**, 9-Oct-1996 Chair: Wilfried Woeber Scribe: John Crain Participants: 51 (according to the sign-up list) A. Administrative stuff John Crain offered to take notes. Thanks a lot, John! The proposed agenda was agreed, including the following additional items: - Input from the DNS-WG and - Input from the Local-IR WG both for agenda item Y. General input from other WGs and - advisories: in aut-num: objects for Z. AOB B. DB-SW status report by the RIPE NCC Carol Orange offered the report on the state of the RIPE Database and the DB-SW. Version 2.0 of the software was released recently and put into production at the NCC. Important new features are: - inverse lookup (whois -i) - the package is now fully classless - support for near real-time-shadowing (As an aside, a DB-Workshop was offered on Monday morning.) More details about the growth of the DB and the increase in the number of objects, etc. were shown on the slides. [ These slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] Activities for the short term future are - produce documentation - fix any version 2.0 bugs - try to improve consistency In general, version 2.0 is found to run very well. Sabine Dolderer reported on problems with the handling of old (invalid) handles. This is one of the known problems. Sabine was asked to report the problem to the ripe-dbm(a)ripe.net mailbox. C. DB consistency and sanity checks Is it worthwhile doing more sanity checking? There was general consensus that the quality and consistency of the data in the RIPE-DB should be improved. The group formally supports this activity which is also part of the RIPE NCC Activity Plan for 1997. A project has already been set up with the Free University of Amsterdam to look at the consistency issues in general. Students may wish to interview selected users. The Local-IR staff and the users of the Routing Registry are expected to contribute to this activity. The group then identified a couple of obvious inconsistencies which should be checked, either at the time of a transaction or on a regular basis. E.g. - person/role objects being refered to no longer exists - persons (multiple) with and without nic-hdls. - person objects which are no longer referenced by any other object (proposal to eventually remove these objects, considering the age of the object) - multiple route objects with different origin, where there is obviously no trasnition and/or multi homing. The various checks, when they get implemented eventually, should at least generate warnings, both at the time of an update and on a regular basis. The logistics (frequency, identifying the proper recipients for the warnings, etc.) need more work. The discussion of a potential reservation of some NIC-Handle types (like AUTOxx-RIPE, ROLExx-RIPE, etc.) led to the conclusion - that there is no need for special handling of role: objects - and that AUTOxx-RIPE should be reserved to avoid confusion when requesting automatic handle assignment with the AUTO-xx mechanism. Niall O'Reilly suggested that the various registries should help with the transistion process by changing old person objects that are (mis-)used to define a role into correct role objects. D. Inverse lookup discussion Is automatic recursion still useful? Just observed as a fact, quite a few people have aliases defined to disable the automatic recursion for their environment. However, for compatibility reasons and because most of the casual users are expected to need the information provided by the recursion, the decision was to stick with the current default (recursion is on by default, use -r flag to disable it). However, the behaviour of the software when doing an inverse lookup ("-i" flag) is to be changed to imply "-r" (recursion disabled). Discussion then moved on to find out wether inverse lookup should be allowed for all attributes. Common feeling was that it is not necessary for all attributes, but it might be useful to implement for a couple of additional attributes. In order to find out about the real need, a discussion on the DB-WG list should be started and the NCC was asked to look at the logs to find out about "popular" failed queries. Kurt Kayser asked about the software behaviour and the timing involved when a "server running at low priority" message is issued. This message is issued for general queries that (potentially) produce a large number of hits. As long as the TCP connection is up, it's still working. E. Documentation Ambrose Magee was then introduced as the new primary maintainer of the DB-SW. He reported on the proposed structure of the Documentation for the RIPE Database objects, the usage and the software. The group endorsed the concept with some minor proposals for improvement and stressed the importance of the documentation, and in general, the importance of consolidation vs. new functionality. In particular, the proposal is to have a main document that is stable and a set of appendices with things that may change or require more freequent updates. [ The slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] One of the suggestins was to seperate the advanced sections (e.g. on how to obtain the database etc.) from the general user documentation. Nigel Titley proposed to start working with the sections on the whois client and utilities and move that information to the beginning of the documentation Bernhard Stockman asked for a list of all active objects (Index), including definition of the syntax and the also the semantics. Daniel proposed to add that functionality toi the software itself, probably by adding a whois -T with -v and possibly whois -T to report all objects. This is is already available for listing the schema for an individual object. F. New functionality Even thouogh there was some discussion on new functionality, like a URL: attribute and amendments to a cgi script to provide access to the data via html, it was stressed that for the time being consolidation should be the priority instead of new functions. The maintainers of the DB-SW were asked to maintain and publish the "consolidated wish-list" and the "known bug list". Y. General input from other WGs DNS: There was concern over potential conflicts between information in RIPE Database and the TLD's internal databases. Becuase of that potential conflict, some TLD administrators do not register their secondaries in the RIPE DB. Referal to their database would be useful. Daniel Karrenberg reported that this referal mechanism is already on the wish list. No design work has been done yet. There is a couple of potential implications, e.g. the idea to implement the referral for other (all?) objects. Guy Davis observed that it might be useful to do a more specific search on hosts/domains for DNS. Daniel Karrenberg was in favour of more specific, but has mixed feelings on referral because of all the different whois initiatives within the Internet. Thus he suggested to implement a quick fix for the top level domains only. Janos Zsako thought that the referral should be implemented in the server not in the client! Wilfried Woeber observed that the referral approach can only be useful if most TLD's are willing to supply an interface for whois. There was an indication of considerable interest to offer access to the local TLD data. Local-IR: Mandatory attributes (as described in the regsistry procedures) should be made mandatory in the database (enforced by the software). In particular the status: attribute in inetnum: objects and the nic-hdl: attribute in general should be made mandatory. Of course, this implies a major clean-up of the database by the LIR's! Daniel Karrenberg observed that initially this will only be applicable for new objects. The clean-up will come later. Kevin Hoadley asked for some time to implement the necessary changes to local scripts and procedures. The following discussion led to a proposal to start enforcing this on the 1st of January 1997. A. Blasco Bonito asked about potential implications of making the 'status:' attribute mandatory. Carol Orange suggested to define an additional value for the status: (USED?) to distinguish between address space allocations, assignments and usage. A. Blasco Bonito's comment that "The general attitude of LIR's who are large providers is to assign to other smaller providers. These then distribute to their customers." prompted Daniel Karrenberg to state that "If this is the case then they are not following the registration policies." A mandatory status: attribute has implications that have to be discussed in more detail. Z. AOB Brian Renaud proposed to obsolete the advisory: attribute for aut-num: objects. For 'route:' objects, these atrtributes should remain valid. Ther was general agreement and the NCC was asked to implement that change. Following up on a mail received from David Kessens, ther was a review of the various mailing lists that dal with different aspects of the database business. These are: DB-WG DB-BETA RRIMPL Daniel Karrenberg described the scope of these lists and observed that all three have their own specific use: - DB-BETA is for people running new code. - DB-WG is for architecture discussions - RRIMPL has a wider scope Bugs in the released version of the RIPE DB-SW should be submitted to ripe-dbm(a)ripe.net discussions about details of running new code should go to db-beta@ripe-net. Sabine Dolderer observed that if there are two maintainers then the "weakest" one is used. Daniel Karrenberg pointed out that there is no hierarchy involved. The software just scans all entries and tries to find a match. The first match found is honored. This is in line with the current concept and design. This is the correct behaviour as all maintainers are equally authorized. To allow specific maintainer functions is at the moment beyond the functionality of the DB. Appendix: New actions [The relative numbering is going to change to match the full meeting minutes] Action (1) on Wilfried Woeber and Carol Orange, To come up with a technical proposal for better DB consistency checking. Action (2) on all WG members, To think about implications of the proposed DB consistency checking and to provide input. Action (3) on RIPE NCC (Carol Orange, Daniel Karrenberg), To report about the FUA findings (on DB consistency) at next ripe meeting. Action (4) on RIPE NCC (Carol Orange, Daniel Karrenberg), To document the approach to find and change references to person objects in order to support migration to mandatory handles (using inverse look up and "search and replace") and send it to the list. Action (5) RIPE NCC (Ambrose Magee) (time allowing), To implement the change that "whois -i ..." implies "whois -i -r ..." Action (6a) on Wilfried Woeber, To ask on the DB-WG mailing list about the need of improved inverse lookup functionality (more attributes allowed for -i). Action (6b) on Daniel Karrenberg, To look at query logs for "failed" -i attempts. Action (7) on Ripe NCC (Ambrose Magee), Produce the RIPE-DB Documentation a.s.a.p. and according to the agreed structure. Action (8a) on RIPE NCC (Carol Orange), Publish the "known bugs" list, on the Web or on the FTP-Server. Action (8b) on RIPE NCC (Carol Orange), Publish the "open issues" list (consolidated wishlist) on the Web or on the FTP server. Action (9) on RIPE NCC (Ambrose Magee, Carol Orange, Daniel Karrenberg), To propose and implement (a.s.ap.) a referral mechanism for TLD domain: objects (only). Action (10) on Wilfried Woeber and the RIPE NCC, To make a proposal on the technical and procedural requirements of making the status: attribute for inetnum: objects mandatory. Action (11) on RIPE NCC (Ambrose Magee), To change the DB-SW to obsolete the advisory: attribute in inetnum: objects. Action (12) on RIPE NCC (Ambrose Magee), To add mailing lists with their descriptions to the database documents. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -WW, 9-OCT-1996 20:05:57

3 2

2nd draft, minutes of DB-WG meeting at RIPE 25
by Wilfried Woeber, UniVie/ACOnet 10 Oct '96

10 Oct '96

This is the 2nd draft of the minutes for the DB WG meeting at RIPE 25. It incoporates comments by David Kessens. I expect to add a couple of URLs to point to presentations as soon as they might become available from the RIPE FTP-Server. The Action List probably needs renumbering, to get it aligned with the summary notes for the plenary. As always, all comments, input and improvements welcome. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- Minutes for the DB WG meeting RIPE 25, Amsterdam, NL **1st DRAFT**, 9-Oct-1996 Chair: Wilfried Woeber Scribe: John Crain Participants: 51 (according to the sign-up list) A. Administrative stuff John Crain offered to take notes. Thanks a lot, John! The proposed agenda was agreed, including the following additional items: - Input from the DNS-WG and - Input from the Local-IR WG both for agenda item Y. General input from other WGs and - advisories: in aut-num: objects for Z. AOB B. DB-SW status report by the RIPE NCC Carol Orange offered the report on the state of the RIPE Database and the DB-SW. Version 2.0 of the software was released recently and put into production at the NCC. Important new features are: - inverse lookup (whois -i) - the package is now fully classless - support for near real-time-shadowing (As an aside, a DB-Workshop was offered on Monday morning.) More details about the growth of the DB and the increase in the number of objects, etc. were shown on the slides. [ These slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] Activities for the short term future are - produce documentation - fix any version 2.0 bugs - try to improve consistency In general, version 2.0 is found to run very well. Sabine Dolderer reported on problems with the handling of old (invalid) handles. This is one of the known problems. Sabine was asked to report the problem to the ripe-dbm(a)ripe.net mailbox. C. DB consistency and sanity checks Is it worthwhile doing more sanity checking? There was general consensus that the quality and consistency of the data in the RIPE-DB should be improved. The group formally supports this activity which is also part of the RIPE NCC Activity Plan for 1997. A project has already been set up with the Free University of Amsterdam to look at the consistency issues in general. Students may wish to interview selected users. The Local-IR staff and the users of the Routing Registry are expected to contribute to this activity. The group then identified a couple of obvious inconsistencies which should be checked, either at the time of a transaction or on a regular basis. E.g. - person/role objects being refered to no longer exists - persons (multiple) with and without nic-hdls. - person objects which are no longer referenced by any other object (proposal to eventually remove these objects, considering the age of the object) - multiple route objects with different origin, where there is obviously no trasnition and/or multi homing. The various checks, when they get implemented eventually, should at least generate warnings, both at the time of an update and on a regular basis. The logistics (frequency, identifying the proper recipients for the warnings, etc.) need more work. The discussion of a potential reservation of some NIC-Handle types (like AUTOxx-RIPE, ROLExx-RIPE, etc.) led to the conclusion - that there is no need for special handling of role: objects - and that AUTOxx-RIPE should be reserved to avoid confusion when requesting automatic handle assignment with the AUTO-xx mechanism. Niall O'Reilly suggested that the various registries should help with the transistion process by changing old person objects that are (mis-)used to define a role into correct role objects. D. Inverse lookup discussion Is automatic recursion still useful? Just observed as a fact, quite a few people have aliases defined to disable the automatic recursion for their environment. However, for compatibility reasons and because most of the casual users are expected to need the information provided by the recursion, the decision was to stick with the current default (recursion is on by default, use -r flag to disable it). However, the behaviour of the software when doing an inverse lookup ("-i" flag) is to be changed to imply "-r" (recursion disabled). Discussion then moved on to find out wether inverse lookup should be allowed for all attributes. Common feeling was that it is not necessary for all attributes, but it might be useful to implement for a couple of additional attributes. In order to find out about the real need, a discussion on the DB-WG list should be started and the NCC was asked to look at the logs to find out about "popular" failed queries. Kurt Kayser asked about the software behaviour and the timing involved when a "server running at low priority" message is issued. This message is issued for general queries that (potentially) produce a large number of hits. As long as the TCP connection is up, it's still working. E. Documentation Ambrose Magee was then introduced as the new primary maintainer of the DB-SW. He reported on the proposed structure of the Documentation for the RIPE Database objects, the usage and the software. The group endorsed the concept with some minor proposals for improvement and stressed the importance of the documentation, and in general, the importance of consolidation vs. new functionality. In particular, the proposal is to have a main document that is stable and a set of appendices with things that may change or require more freequent updates. [ The slides are expected to become available soon ] [ at ftp://ftp.ripe.net/ripe/presentations/ ] One of the suggestins was to seperate the advanced sections (e.g. on how to obtain the database etc.) from the general user documentation. Nigel Titley proposed to start working with the sections on the whois client and utilities and move that information to the beginning of the documentation Bernhard Stockman asked for a list of all active objects (Index), including definition of the syntax and the also the semantics. Daniel again proposed to add that functionality to the software itself. This is already on the consolidated wish-list, and to be implemented by adding a whois -T with -v and possibly whois -T to report all objects. whois -T <type> is already available for listing the schema for an individual object. F. New functionality Even thouogh there was some discussion on new functionality, like a URL: attribute and amendments to a cgi script to provide access to the data via html, it was stressed that for the time being consolidation should be the priority instead of new functions. The maintainers of the DB-SW were asked to maintain and publish the "consolidated wish-list" and the "known bug list". Y. General input from other WGs DNS: There was concern over potential conflicts between information in RIPE Database and the TLD's internal databases. Becuase of that potential conflict, some TLD administrators do not register their secondaries in the RIPE DB. Referal to their database would be useful. Daniel Karrenberg reported that this referal mechanism is already on the wish list. No design work has been done yet. There is a couple of potential implications, e.g. the idea to implement the referral for other (all?) objects. Guy Davis observed that it might be useful to do a more specific search on hosts/domains for DNS. Daniel Karrenberg was in favour of more specific, but has mixed feelings on referral because of all the different whois initiatives within the Internet. Thus he suggested to implement a quick fix for the top level domains only. Janos Zsako thought that the referral should be implemented in the server not in the client! Wilfried Woeber observed that the referral approach can only be useful if most TLD's are willing to supply an interface for whois. There was an indication of considerable interest to offer access to the local TLD data. Local-IR: Mandatory attributes (as described in the regsistry procedures) should be made mandatory in the database (enforced by the software). In particular the status: attribute in inetnum: objects and the nic-hdl: attribute in general should be made mandatory. Of course, this implies a major clean-up of the database by the LIR's! Daniel Karrenberg observed that initially this will only be applicable for new objects. The clean-up will come later. Kevin Hoadley asked for some time to implement the necessary changes to local scripts and procedures. The following discussion led to a proposal to start enforcing this on the 1st of January 1997. A. Blasco Bonito asked about potential implications of making the 'status:' attribute mandatory. Carol Orange suggested to define an additional value for the status: (USED?) to distinguish between address space allocations, assignments and usage. A. Blasco Bonito's comment that "The general attitude of LIR's who are large providers is to assign to other smaller providers. These then distribute to their customers." prompted Daniel Karrenberg to state that "If this is the case then they are not following the registration policies." A mandatory status: attribute has implications that have to be discussed in more detail. Z. AOB Brian Renaud proposed to obsolete the advisory: attribute for aut-num: objects. For 'route:' objects, these atrtributes should remain valid. Ther was general agreement and the NCC was asked to implement that change. Following up on a mail received from David Kessens, ther was a review of the various mailing lists that dal with different aspects of the database business. These are: DB-WG DB-BETA RRIMPL Daniel Karrenberg described the scope of these lists and observed that all three have their own specific use: - DB-BETA is for people running new code. - DB-WG is for architecture discussions - RRIMPL has a wider scope Bugs in the released version of the RIPE DB-SW should be submitted to ripe-dbm(a)ripe.net discussions about details of running new code should go to db-beta@ripe-net. Sabine Dolderer observed that if there are two maintainers then the "weakest" one is used. Daniel Karrenberg pointed out that there is no hierarchy involved. The software just scans all entries and tries to find a match. The first match found is honored. This is in line with the current concept and design. This is the correct behaviour as all maintainers are equally authorized. To allow specific maintainer functions is at the moment beyond the functionality of the DB. Appendix: New actions [The relative numbering is going to change to match the full meeting minutes] Action (1) on Wilfried Woeber and Carol Orange, To come up with a technical proposal for better DB consistency checking. Action (2) on all WG members, To think about implications of the proposed DB consistency checking and to provide input. Action (3) on RIPE NCC (Carol Orange, Daniel Karrenberg), To report about the FUA findings (on DB consistency) at next ripe meeting. Action (4) on RIPE NCC (Carol Orange, Daniel Karrenberg), To document the approach to find and change references to person objects in order to support migration to mandatory handles (using inverse look up and "search and replace") and send it to the list. Action (5) RIPE NCC (Ambrose Magee) (time allowing), To implement the change that "whois -i ..." implies "whois -i -r ..." Action (6a) on Wilfried Woeber, To ask on the DB-WG mailing list about the need of improved inverse lookup functionality (more attributes allowed for -i). Action (6b) on Daniel Karrenberg, To look at query logs for "failed" -i attempts. Action (7) on Ripe NCC (Ambrose Magee), Produce the RIPE-DB Documentation a.s.a.p. and according to the agreed structure. Action (8a) on RIPE NCC (Carol Orange), Publish the "known bugs" list, on the Web or on the FTP-Server. Action (8b) on RIPE NCC (Carol Orange), Publish the "open issues" list (consolidated wishlist) on the Web or on the FTP server. Action (9) on RIPE NCC (Ambrose Magee, Carol Orange, Daniel Karrenberg), To propose and implement (a.s.ap.) a referral mechanism for TLD domain: objects (only). Action (10) on Wilfried Woeber and the RIPE NCC, To make a proposal on the technical and procedural requirements of making the status: attribute for inetnum: objects mandatory. Action (11) on RIPE NCC (Ambrose Magee), To change the DB-SW to obsolete the advisory: attribute in aut-num: objects. Action (12) on RIPE NCC (Ambrose Magee), To add mailing lists with their descriptions to the database documents. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -WW, 9-OCT-1996 20:05:57

2 1

Slides of RIPE Database 2.0 Workshop
by RIPE Database Administration 10 Oct '96

10 Oct '96

Dear Colleagues, The slides for the RIPE Database 2.0 Workshop (held during the recent RIPE meeting) are available at: ftp://ftp.ripe.net/ripe/presentations/ripe-m25-orange-DB-Workshop.ps.tar.gz Please send any comments to <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Re: draft minutes of DB-WG meeting at RIPE 25
by Wilfried Woeber, UniVie/ACOnet 10 Oct '96

10 Oct '96

=> The various checks, when they get implemented eventually, should at least => generate warnings, both at the time of an update and on a regular basis. = =One note on this one: = =The new software doesn't create a new object anymore when adding a NIC =handle to an existing object. It will only do this when there are other =differences between the new and old object then the 'changed:' and the =added NIC handle attribute. Thanks for the note. => Daniel proposed to add that functionality toi the software itself, probably => by adding a whois -T with -v and possibly whois -T to report all objects. => This is is already available for listing the schema for an individual object. = =Wasn't this proposal on the wish list for a long, long time (and even =accepted by the database working group as a good thing) ?!? = =davidk> List of current proposals: =davidk> =davidk> 5) whois -tv Yes it was. I'll re-word that to properly reflect history. From the technical point of view, it doesn't hurt to propose it again for implementation :-) => Action (11) on RIPE NCC (Ambrose Magee), => To change the DB-SW to obsolete the advisory: attribute in inetnum: objects. = ^^^^^^^^ = =No further comments ... ;-) That's the fate of lazy people (like me) who do a cut-n-paste from the local *broken* copy. Yours, standing at the corner of the room, and facing the walls, Wilfried.

1 0

Re: Fwd: Re: Short summaries of WG sessions [DataBase]
by Wilfried Woeber, UniVie/ACOnet 09 Oct '96

09 Oct '96

Hi David ! => Z. AOB => - clarification abou mailing lists => - obsolete advisories in inetnum objects => => Action (11) on RIPE NCC (Ambrose Magee), => To change the DB-SW to obsolete the advisory: attribute in inetnum: objects. = =Just to avoid even more confusion on this trickey advisory topic: = =I assume you are talking about the 'aut-num:' object since the 'inetnum:' =object never had support for this ... You're right, of course. I was mixed up, and John's notes are correct anyway! Could the minute folks at the NCC (Roderik?) please fix the text ? Thanks and apologies, Wilfried.

1 0