- db-wg - mailman.ripe.net

Discrepancies between Merit and RIPE DB
by Laurent Joncheray 11 Nov '93

11 Nov '93

Here are the differences between the Merit and the RIPE databases: Number of entries: 3791 No difference: 608 (16%) Small diferences: 1354 (35%) Substrings: 968 (25%) Typos: 481 (12) Order: 78 (2%) Punctuation: 51 (1%) Abbreviations: 244 (6%) One Word only: 75 (1%) Differences: 1829 (48%) 100%: 277 (7%) 80%: 303 (7%) 60%: 335 (8%) 40%: 463 (12%) 20%: 451 (11%) A file with the list of addresses and differences is available on request. -- Laurent Joncheray, Merit Network Inc, 1071 Beal Avenue, E-Mail: lpj(a)merit.edu Ann Arbor, MI 48109, USA Phone: (313) 936 2065 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

1 0

discrepancies RIPE - InterNIC
by Laurent Joncheray 11 Nov '93

11 Nov '93

Thanks to the InterNIC folks, the InterNIC data relative to the Network numbers is available on a flat file on merit.edu. We ran a comparison between the InterNIC and the Merit data, and between the RIPE data and the InterNIC data. since RIPE is authoritative for the European information and the InterNIC is authoritative for everything else, it seems most important to address those discrepancies (RIPE/InterNIC). Here is the result of the first comparison between RIPE and InterNIC: (The data may be old for some networks, and our program may have some bugs... The result for the Merit/InterNIC data are not provided) Number of entries: 10423 Unregistered in NIC DB: 5298 (50%) No difference: 108 (1%) Small differences: 2047 (19%) Substrings: 1604 (15%) Typos: 510 (4%) Order: 356 (3%) Punctuation: 21 (0%) Abbreviations: 186 (1%) One Word only: 5 (0%) Differences: 2970 (28%) 100%: 758 (7%) 80%: 498 (4%) 60%: 494 (4%) 40%: 723 (6%) 20%: 497 (4%) Remarks: - 10423 represents the number of networks and blocks in the RIPE DB; each block is counted as 1 network. - The addresses for the RIPE networks are got from the 'Administrative Contact' entries. For 10423 networks, 224 do not have a administrative contact entry in the persons databases. In such a case we use the 'description' attribute to get the address. Some entries are duplicated in the person DB, which creates some strange addresses (e.g. 193.84.64.0 -> Alexandr Modry) - 'Unregistered in NIC DB' means the network is part of the RIPE block in the NIC BD, but does not have its own entry. - 'Substrings' means all the words of one address are on the second address (e.g. "Celisoft Data AB, Box 718, S-941 28 Piteaa, Sweden" and "Celisoft Data AB, Celisoft Data AB, BOX 718, S-941 28 PITEAA, SWEDEN") - The differences are given in percentage of number of different words. 100% means 80% to 100% of the word are differents. We also take into account the typos, abbreviations, punctuation, etc... which are not a 'difference' per se. - The program which compares the addresses takes about 20s for 10000 entries. The program which reads the InterNIC data and formats them for comparison takes about 20 minutes. We'd like to set up a plan with RIPE and the InterNIC to eliminate the discrepancies. Merit has a list of the 5298 networks without entry in the NIC DB and can provide a detailed list of the address differences for the other inconsistences. Do you all have any suggestions as to how we can proceed to resolve this problem? Laurent & Enke. PS: Could InterNIC provide your flat file periodicly? (once a week?) PS: Any comments are wellcome.

3 2

Re: A Question
by Daniel Karrenberg 03 Nov '93

03 Nov '93

Jack, sorry about that late reply. First I have been away and then swamped. The answer has been a little longer than expected. Thus I CC it to the relevant RIPE working groups too fort their information. Daniel > Haven't mailed for awhile. I hope everything is going well over the > pond. I was wondering if you could fill me in on a little RIPE > philosophy. Tall order. :-) If we keep it down to specifics ... > Right now, its my understanding that authorized users can > automatically update the ripe database. If that is correct, how do you > make sure that what the authorized user is telling you is the correct > information. The original RIPE DB authorisation scheme: "No authorisation but *very* good audit trails." Anyone can change anything in the database but it will be logged. True, if you are mailicious and really determined you can do things and we will not be able to trace you far. But we will know what was done when and from where and we will be able to take appropriate action. We have decided to cross that particular bridge when we get to it. Together with a very quick response to queries about update problems this has worked rather well. After three years of experience with now 38,000 objects in the database and just under 1000 updates on an average working day I can not recall more than about a dozen incidents of unintentional changes being made by third parties. All of those have been resolved rather quickly and none has been intentional or malicious. Since we are now starting to do routing registry functions which are critical to operations we are starting to introduce some authorisation for the routing policy elements in the database. Some objects will not be changeable at all but by an authorised guardian. Currently these are some deprecated objects nad the autonomous system and community objects. Additionally some attributes will be guarded. The most important is the "aut-sys" attribute of the network object which defines membership of a network in an AS. These attribute will not be updated or updatable via the normal method but via a totally separate authorised method by the guardians of the respective autonomous system. The authorisation method for this will be Unix login security in most cases. You can read more about all this in ripe-81 ripe-96 ripe-89 ripe-72 and others. > An example: > > Say I'm a mean guy and I want to register a net that I do not own, and > is currently not in the RIPE database, to myself before my competitor > has registered it. How do you make sure that I'm allowed to register > this new net in the database? We do not. But we keep track of registry assignments separately from the database. If someone claims a network and has no assignment from the appropriate registry (either the NCC or a local registry) then he looses. > The only way I can check this today is > to see if the internic has given the net out and if it is registered > to the apporpriate person sending in the database addition. Same thing here. > Now if I'm > a provider, I do not "own" this address so things get a little > confusing. Not at all. The registry has the obligation to keep a record of what they assigned separately from the database and to register networks in the RIPE database no less than 24h after assignment. So there will be a trace. Also a flag will be raised if such an assignment is made for a net already in the database. At the NCC we keep simple SCCS files (yes I am *that* old) for the register. Together with the database audit trail this is more than adequate to document who did what when. We also keep an archive of all registry mail messages and faxes (full-text indexed with WAIS). We also have a filing cabinet used for those old fashioned hardcopy requests. It is not too full yet so we can keep office supplies and other stuff in it as well. :-) If there is a conflict both the datbase audit trails and the register of the registry concerned will be examined. If there are conflicts the latter is most likely to be ruled authoritative. To date such a case still has to happen - apart from administrative snafus which *do* happen once in a while. Daniel

1 0

RE: DB Minutes
by Wilfried Woeber, UniVie/ACOnet 01 Oct '93

01 Oct '93

>I propose to add the text below to the DB minutes: Good idea. I think the example 2 should be corrected. See below. ---- |In case two or more guardians want to set an attribute |which can only have one value, the current state of the |attribute will not be changed and all guardians concerned will |be notified. | |Example: | |The aut-sys attribute of network 193.193.193.0 in the database is AS193. |AS4711 adds this network to his guardian file. At the next database cleanup |all guardian files will be examined. | | 1) if the AS193 guardian file still contains 193.193.193.0 a conflict | exists and the cuurent database state prevails: AS193 will remain | | 2) if 193.193.193.0 has been removed from the AS193 guardian file | no conflict exists and AS193 will be replaced by AS4711 ^^^^^^ |Similarly the aut-sys attribute will remain undefined if it is undefined |and two guardians add it simultaneouly. | |Since the cleanup runs every 24 hours guardians involved in a change should |coordinate their changes such that they are done in the same 24h period. | ---- >clear? Yes, Sir! :-) Wilfried.

2 1

DB Minutes
by Daniel Karrenberg 01 Oct '93

01 Oct '93

The routing wg posed the question "how will a conflict between two guardians be resolved?". To my recollection this was discussed briefly in the DB WG but not minuted (my fault). I propose to add the text below to the DB minutes: ---- In case two or more guardians want to set an attribute which can only have one value, the current state of the attribute will not be changed and all guardians concerned will be notified. Example: The aut-sys attribute of network 193.193.193.0 in the database is AS193. AS4711 adds this network to his guardian file. At the next database cleanup all guardian files will be examined. 1) if the AS193 guardian file still contains 193.193.193.0 a conflict exists and the cuurent database state prevails: AS193 will remain 2) if 193.193.193.0 has been removed from the AS193 guardian file no confluict exists and AS193 will be replaced by AS193 Similarly the aut-sys attribute will remain undefined if it is undefined and two guardians add it simultaneouly. Since the cleanup runs every 24 hours guardians involved in a change should coordinate their changes such that they are done in the same 24h period. ---- clear?

1 0

Database beta: Bug in enkeys.pl
by Daniel Karrenberg 28 Sep '93

28 Sep '93

Gabor Kiss <kissg(a)sztaki.hu> found a bug in enkeys.pl. His fix is included below. It has been incorporated in the beta release. Future announcements like this will only be made to the list <db-beta(a)ripe.net>. Be sure to get on this list if you use the beta release. Daniel *** /tmp/T0a09361 Tue Sep 28 17:40:00 1993 --- enkeys.pl Tue Sep 28 17:17:28 1993 *************** *** 1,9 **** # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.13 $ ! # $Author: marten $ ! # $Date: 1993/08/19 14:53:37 $ # require "misc.pl"; --- 1,9 ---- # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.14 $ ! # $Author: dfk $ ! # $Date: 1993/09/28 16:16:57 $ # require "misc.pl"; *************** *** 39,45 **** $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); } --- 39,45 ---- $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9\-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); }

1 0

Beta RIPE database software
by Marten Terpstra 27 Sep '93

27 Sep '93

folks, I have made a beta database distribution for you all, with the emphasis on BETA. I just packed all the sources and stuff together, documentation and manual pages have not been updated to include all the changes we made over the last weeks, so this is "as is". A "real" distribution will follow whenever I am back in November, or Daniel may make one before that. You can find it on: ncc.ripe.net:/dbase-beta/dbase-beta.tar.Z NOTE this is NOT on ftp.ripe.net. The directory dbase-beta is NOT readable, but the dist can be fetched anyway. Have fun, -Marten

2 1

Re: Obsoleting "connect"
by Wilfried Woeber, UniVie/ACOnet 24 Sep '93

24 Sep '93

Folks, sorry for being late to voice my opinion, but I'm again out of office. BTW, I'm glad that Helsinki University provides my with decent access to the Internet! *> I tend to agree with you here but before we change the database config to *> make connect optional I guess we should get the okay from the chair who *> will be coordinating the new definitions for the objects. * *I agree. It is my understanding that this approach was a general consensus, thus I propose to (immediately) proceed in this direction. *> Also, we can take it a step further in that if the connect field is there *> it is LOCAL (something to add to the syntax checker ;-(). * *I was thinking of a multi-step phase-in of the new policy, and that this *would be the natural next step. Or do we just jump into it with both feet *rigt away? Well, sometimes you have to jump, although in this case I would strongly advocate a step-by-step approach. I'd also like to keep the possibility of submitting objects with connect: attributes other than LOCAL, as long as we have not agreed on and implemented a decent replacement functionality. More so if the attribute is optional, I don't see the case for doing more syntax checking for an attribute that is about to go away. I include the relevant section of the DB-WG minutes FYI. I think the wording does reflect the proposed approach reasonably well: ---------- 6. DB usage conventions and recommendations Quite some time was spent to discuss the connect: attribute of the network object. It was agreed that the only well-defined value is LOCAL. This attribute should eventually be obsoleted. Later it was noted that it is currently mandatory and should be made optional after one round of mailing-list discussion. However, there is a need for the functionality, maybe the community: approach is the right way to go (eg. create community NSF). Still there is concern that some of the approaches that are obvious for "old hands in networking" are not necessarily useful for the end-users. Maybe the tools coming out of the PRIDE project can help to solve this problem. NCC to start the discussion with a rough proposal before the next meeting. ---------- Wilfried.

3 2

Guarded Objects are now better protected
by Daniel Karrenberg 24 Sep '93

24 Sep '93

Dear colleagues, A recent accident has caused us to protect the guarded objects in the database a little better before the maintainer attribute is fully implemented. Guarded objects can from now on only be updated thru the manual procedure which involves plausibility checking by NCC staff. The manual procedure uses the old mailbox ripe-dbm(a)ripe.net. Any updates for guarded objects sent to the auto-dbm(a)ripe.net mailbox will be refused with the error message: *ERROR*: guarded objects cannot be updated via automatic procedure If you get such an error, re-send the update to ripe-dbm. Once the maintainer attribute is implemented authorisation will be handled automatically. Daniel PS: We hope to have the update procedure for guarded *attributes* deployed next week.

1 0

Obsoleting "connect"
by Havard Eidnes 23 Sep '93

23 Sep '93

Hi, if my memory serves me well, I think the RIPE DB working group concluded to restrict the legal values for the "connect" field to only "LOCAL", and if wider connectivity for a net has been established to not use this attribute in the objects in the database. However, this is somewhat at odds with the current definition of the connect field in the inetnum template, where the attribute is mandatory. So what do you put in an object which has wider connectivity than internal to the "home" autonomous system? My proposal to progress this decision (as mentioned at the end of the RIPE meeting) is thus to initially demote the "connect" attribute from mandatory to optional, and later add stricter checks in the RIPE database software for the values of the connect attribute. Currently updates missing the connect field are being bounced (I know, I tried it while I was at the RIPE meeting :-) - Havard

1 0