- db-wg - mailman.ripe.net

Invalid data in the RIPE database
by Laurent Joncheray 26 Apr '94

26 Apr '94

Dear database managers, i had a look at some entries in the RIPE database and at the 'nsf-in' network attribute. For a lot of them the value in the RIPE db is inconsistant with the Merit (NSF) database. Moreover some networks in the RIPE DB have this attribute but are not routed by NSF (for instance 193.128.12/24). It is usefull to keep such data when it can mislead people who use your DB to generate configuration files or aggregate lists? Or can you automaticly generate those values from the NSF database so they will be consistant? Thanks for your answer, Laurent -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

7 6

Re: Whois database and list of networks
by jimi＠dxcoms.cern.ch 22 Apr '94

22 Apr '94

Daniele, Thank you for your proposal. We all agree that the aggregates should be stored somehow in the Ripe database and that the current structure does not allow such representations of blocks/aggregates. This is now becoming the main priority of the routing-wg and (probably) the Ripe NCC. A proposal will be sent out very soon now, and we'll then be able to discuss this in more details. I'm sure your input will be considered and appreciated. -- Jean-Michel >----- Text sent by Daniele Vannozzi follows ------- > > We would like to know your opinion about this problem and our proposal. > The GARR-NIS manages a whois database (whois.nis.garr.it) where each > network is described with the RIPE database format plus other "italian > GARR-NIS" tags. We produce the access lists for the GARR border routers > starting from GARR-NIS whois database (we use the nlc tool). > In addition to that we are requested to produce the "aggregate" networks > list (CIDR) from GARR-NIS database as well. > > In our opinion it is difficult to get the right information about > network blocks from the whois database as it is currently managed > because many network blocks are splitted in smaller blocks (usually > corresponding to the really announced networks or because of different > contact point). > > We would like to announce the whole original block while maintaining > into the GARR-NIS database the splitted blocks. > An additional gain using this scheme would be to store different > rev-srv: server for each block for example). > > We have thought the following solution: add a new tag inet-block: into > the network object which describes the original block size. In this way > it is possible to store in the same object entry both the information > for route aggregates (inet-block:) and other data we need (like > rev-srv:, contact people, etc). > > This is a example: > > inetnum: 193.204.160.0 - 193.204.161.0 > netname: ROMA3-NET > inet-block: 193.204.160.0 - 193.204.167.0 > country: IT > admin-c: Fabio Martinelli > tech-c: Aldo Altamore > connect: GARR > aut-sys: AS137 > bdrygw-l: INFN-MIL INFN-CNAF > rev-srv: decsrv.caspur.it > rev-srv: dns.nis.garr.it > rev-srv: matrm3.mat.uniroma3.it > ...... > ...... > > inetnum: 193.204.162.0 - 193.204.167.0 > netname: ROMA3-NET > inet-block: 193.204.160.0 - 193.204.167.0 > country: IT > admin-c: Fabio Martinelli > tech-c: Aldo Altamore > connect: LOCAL > ....... > ....... > > Please let us know your opinion. > > > The GARR-NIS Staff > > Daniele Vannozzi Phone: +39 50 593280 > GARR-NIS Phone NIS: +39 50 593360 > c/o CNUCE - Istituto del CNR Fax: +39 50 904052 > Via Santa Maria 36 Telex: 500371 - CNUCE > 56100 Pisa - Italy E-mail: vannozzi(a)nis.garr.it > -- Jean-Michel

1 0

Whois database and list of networks
by Daniele Vannozzi 22 Apr '94

22 Apr '94

We would like to know your opinion about this problem and our proposal. The GARR-NIS manages a whois database (whois.nis.garr.it) where each network is described with the RIPE database format plus other "italian GARR-NIS" tags. We produce the access lists for the GARR border routers starting from GARR-NIS whois database (we use the nlc tool). In addition to that we are requested to produce the "aggregate" networks list (CIDR) from GARR-NIS database as well. In our opinion it is difficult to get the right information about network blocks from the whois database as it is currently managed because many network blocks are splitted in smaller blocks (usually corresponding to the really announced networks or because of different contact point). We would like to announce the whole original block while maintaining into the GARR-NIS database the splitted blocks. An additional gain using this scheme would be to store different rev-srv: server for each block for example). We have thought the following solution: add a new tag inet-block: into the network object which describes the original block size. In this way it is possible to store in the same object entry both the information for route aggregates (inet-block:) and other data we need (like rev-srv:, contact people, etc). This is a example: inetnum: 193.204.160.0 - 193.204.161.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: GARR aut-sys: AS137 bdrygw-l: INFN-MIL INFN-CNAF rev-srv: decsrv.caspur.it rev-srv: dns.nis.garr.it rev-srv: matrm3.mat.uniroma3.it ...... ...... inetnum: 193.204.162.0 - 193.204.167.0 netname: ROMA3-NET inet-block: 193.204.160.0 - 193.204.167.0 country: IT admin-c: Fabio Martinelli tech-c: Aldo Altamore connect: LOCAL ....... ....... Please let us know your opinion. The GARR-NIS Staff Daniele Vannozzi Phone: +39 50 593280 GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56100 Pisa - Italy E-mail: vannozzi(a)nis.garr.it

1 0

Internet Registry Object
by Daniel Karrenberg 20 Apr '94

20 Apr '94

I have an action to propose a "registry" object for the RIPE database. Defining such an object is not so much of a problem. In fact we already have the information needed in tagged format. Look at the Irish Internet registries as an example: org: EUnet IE status: Provider person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie org: HEAnet status: Provider person: Mike Norris address: 21 Fitzwilliam Square address: Dublin 2 country: Ireland (ie) phone: +353 1 6612748 fax: +353 1 6610492 e-mail: mnorris(a)hea.ie org: IE EUnet status: Registry of Last Resort person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie However putting this in the database is not all. We need to define a querying mechanism. This is where the problem starts. Options: 1) Return all the regsitries on queries for the country code together with the toplevel domain object. 2) Return all registries on queries for "cc-reg" or some such magic. 3) Add a special flag to whois to query for registries. All these options are not very applealing because all of them have a big potential for user confusion. Also I am convinced that this information should always be presented together with some information about what a local registry is and what it is not. What did we want to achieve by putting this information in the database? - easy updates via the normal means - access to up to date information at all times between publications of the local registry list We can achieve the -more important- second goal by making this information available via the RIPE document store together with the explanatory information. This could be implemented quickly (before the RIPE meeting). The first goal cannot be achieved that way. But since the amount of info and changes is expected to be small, the NCC can process update requests manually. So my conclusion is not to include this in the database but in the document store. If I have not considered some important argument, please let me know pricately or via a discussion on these lists. If there is consensus we will implement it that way. Daniel

2 4

Re: Internet Registry Object
by Wilfried Woeber, UniVie/ACOnet 20 Apr '94

20 Apr '94

>With 113 relatively stable entities I do not think that manual update >by the NCC is a problem. > >Daniel Daniel, if you want to handle the update manually, fine with me! Can we then use the ripe-dbm mailbox and use the tagged format you have already? E.g. let's assume my phone number changes and I update my person entry. Then it would be natural to think about having the same thing updated in the IR-entry. >PS: Also an answer to Wilfired's message. Thanks :-) Wilfried.

2 1

RE: Internet Registry Object
by Wilfried Woeber, UniVie/ACOnet 19 Apr '94

19 Apr '94

Dear all, lend me a couple of minutes to describe my expectations, without going into technical implementation details, as described by Daniel below... 1. How about using proven and widely known tools and info-channels? For me this means putting objects into the database, and maybe having them guarded (for ease of update). I don't really believe in manual update procedures... Finding info should be possible both through the Interactive Info Service at the NCC, and probably through the WWW interface. 2. Lets investigate a setup, - where we get the over-all info from the document store (the envelope), - more details by looking into a WWW compound document and getting - the details dynamically out of the database (clicking on an item). Please feel free to give me a blow on the head... Cheers, Wilfried. ________________________________________________________________________________ Daniel said: I have an action to propose a "registry" object for the RIPE database. Defining such an object is not so much of a problem. In fact we already have the information needed in tagged format. Look at the Irish Internet registries as an example: org: EUnet IE status: Provider person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie org: HEAnet status: Provider person: Mike Norris address: 21 Fitzwilliam Square address: Dublin 2 country: Ireland (ie) phone: +353 1 6612748 fax: +353 1 6610492 e-mail: mnorris(a)hea.ie org: IE EUnet status: Registry of Last Resort person: Michael Nowlan address: O'Reilly Institute address: Trinity College address: Dublin 2 country: Ireland (ie) phone: +353 1 671 9361 phone: +353 1 702 1787 fax-no: +353 1 677 2204 e-mail: mn(a)dec4ie.ieunet.ie However putting this in the database is not all. We need to define a querying mechanism. This is where the problem starts. Options: 1) Return all the regsitries on queries for the country code together with the toplevel domain object. 2) Return all registries on queries for "cc-reg" or some such magic. 3) Add a special flag to whois to query for registries. All these options are not very applealing because all of them have a big potential for user confusion. Also I am convinced that this information should always be presented together with some information about what a local registry is and what it is not. What did we want to achieve by putting this information in the database? - easy updates via the normal means - access to up to date information at all times between publications of the local registry list We can achieve the -more important- second goal by making this information available via the RIPE document store together with the explanatory information. This could be implemented quickly (before the RIPE meeting). The first goal cannot be achieved that way. But since the amount of info and changes is expected to be small, the NCC can process update requests manually. So my conclusion is not to include this in the database but in the document store. If I have not considered some important argument, please let me know pricately or via a discussion on these lists. If there is consensus we will implement it that way. Daniel -------------------------------------------------------------------------------- Return-Path: <dfk(a)ripe.net> Received: from email.univie.ac.at by access.cc.univie.ac.at (MX V3.1) with SMTP; Fri, 15 Apr 1994 14:14:45 +0100 Received: from ncc.ripe.net by email.univie.ac.at with SMTP (PP) id <29896-0(a)email.univie.ac.at>; Fri, 15 Apr 1994 14:14:59 +0200 Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA27717 (5.65a/NCC-2.2); Fri, 15 Apr 1994 14:14:47 +0200 Received: from localhost.ripe.net by reif.ripe.net with SMTP id AA12109 (5.65a/NCC-2.1); Fri, 15 Apr 1994 14:14:47 +0200 Message-ID: <9404151214.AA12109(a)reif.ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Sender: Daniel.Karrenberg(a)ripe.net

1 0

Merit Routing Registry
by epg＠merit.edu 18 Apr '94

18 Apr '94

Merit is happy to announce the Merit Routing Registry. Whereas Merit designed and manages the PRDB (Policy Routing Data Base) for the NSFNET service, RIPE pioneered a policy routing registry for the European community. The RIPE Routing Registry is based on the document, RIPE-81. With RIPE's collaboration, Merit installed RIPE-81 software and then extended the policy descriptions in order to realize more complex policies. The Merit Routing Registry will be a companion registry to the RIPE Routing Registry and is intended to serve the community that is not served by RIPE. This is a new service and we consider ourselves still in the beta phase. Registrations may be basic policy descriptions defined in RIPE-81 or complex routing policy descriptions defined in the Extended Policy Syntax document by Chen, Gerich, Joncheray, and Yu. The Extended Policy Syntax document may be found on rrdb.merit.edu:pub/meritrr/policy_syntax.txt. Documentation for using the MeritRR can be found on rrdb.merit.edu:pub/meritrr. Merit and RIPE anticipate that the combined registries will provide a more comprehensive picture of the routing interactions in the Internet. We are working together to allow the two registries to appear like one virtual registry to the various tools that are developed. We welcome your comments on all aspects of this project. For more information, please respond to rradmin(a)rrdb.merit.edu. Elise Gerich, Merit Network, Inc. Daniel Karrenberg, RIPE NCC

1 0

Re: Corrupted data
by Tony Bates 15 Apr '94

15 Apr '94

Following on from the mail yesterday about errors in aut-num objects in the database. Please find a new set of database errors on ftp.ripe.net:ripe/dbase/errors/* -rw-r--r-- 1 tony dbase 0 Apr 15 11:59 as-macro.errors -rw-r--r-- 1 tony dbase 5319 Apr 15 11:55 aut-num.errors -rw-r--r-- 1 tony dbase 0 Apr 15 11:58 bdry-gw.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:00 community.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:01 dom-prefix.errors -rw-r--r-- 1 tony dbase 103796 Apr 15 12:06 domain.errors -rw-r--r-- 1 tony dbase 58285 Apr 15 12:46 inetnum.errors -rw-r--r-- 1 tony dbase 320852 Apr 15 12:38 person.errors -rw-r--r-- 1 tony dbase 0 Apr 15 12:00 rout-pr.errors As you can see person has the most errors. Please can all (especialy local-irs take a look at these files and correct where possible. Here's a summary of the amount of errors over what is in the database. Object Number in DB Number in Error aut-num 322 11 domain 3222 354 inetnum 16107 176 person 16366 1072 Please look at these files. Remember many of the errors are where mandatoy fields are not in the object rather than syntax errors. The next round will be to start chasing people individually. Thanks, --Tony.

1 0

Corrupted data
by Laurent Joncheray 14 Apr '94

14 Apr '94

Could you clean up these data? Some of the policies are not RIPE-81 compliant. Thanks. alc: reading file "/f/rrdb/dbase-beta/data/ripe.db" (RIPE-DB)... ERROR (201339): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ao: AS1853" ERROR (201348): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ai: AS1800 ANY" ERROR (201349): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ai: AS1880 ANY" ERROR (201368): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1755 100 AS1755 AS690" ERROR (201369): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1883 200 AS1755 AS690" ERROR (201382): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1880 100 AS1755 AS690" ERROR (201395): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1880 100 AS1755 AS690" ERROR (201396): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1883 200 AS1755 AS690" ERROR (201414): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*df: AS1755 100 AS1755 AS690" ERROR (203306): attribute value error in db file /f/rrdb/dbase-beta/data/ripe.db: "*ao: AS1755 AND AND NOT (AS1729)" ERROR (205269): object *am undefined alc: Printing stat for db RIPE-DB alc: ipblock: 16075 objects, 38766 count alc: autsys: 321 objects, 321 count -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

2 1

A ROUGH alternate proposal to CLNS DB for RIPE
by Susan Hares 06 Apr '94

06 Apr '94

Wilfried: I'm thrilled to see your response. The reason I proposed this change was to align it with the IP CIDR object. My hope was we could then leverage the IP CIDR work to quickly implement the CLNS. So, I am looking at implementation at RIPE NCC and MERIT. I would like to expand prtraceroute and whois servers to use the CLNS. The host.txt option is certainly open to question. I suggest we talk about the benefits of the proposal without this section. To discuss the "host.txt" section, I suggest we query the noop(a)merit.edu tuba(a)merit.edu lists to determine the distribution of the DNS NSAP object. If it is far enough along, then we should can this. Otherwise, it may be a very useful "bootstrapping" function to support. If you agree, I will send notes to this and the rare-clns-wg4 mail list. In the implementation these objects could be kept in a different sequence of files that could be easily cut when the DNS NSAP object is widely deployed. Again, many thanks for such a thought response! Sue Hares

1 0