- db-wg - mailman.ripe.net

Wilfried Woeber: Fwd: Re: Invalid data in the RIPE database
by Marten Terpstra 26 Apr '94

26 Apr '94

Wilfried has some mail connectivity problems to the RIPE NCC, therefore he asked me to resend the mail below concerning the as-in and as-out attributes. -Marten ------- Forwarded Message Date: Tue, 26 Apr 1994 16:36:51 +0100 From: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> Sender: <woeber(a)cc.univie.ac.at> To: marten(a)ripe.net cc: woeber(a)cc.univie.ac.at Subject: Fwd: Re: Invalid data in the RIPE database Marten, this was (one of) the message(s) that made it to L.Joncheray, but didn't reach you personally and the -wg lists. Maybe you could forward them, to keep the chaos down to a reasonable level. Sorry, Wilfried. From: ACCESS::WOEBER "Wilfried Woeber, UniVie/ACOnet" 26-APR-1994 11:31 :48.07 To: MX%"Marten.Terpstra(a)ripe.net" CC: MX%"lpj(a)merit.edu",MX%"routing-wg(a)ripe.net",MX%"db-wg(a)ripe.net",WOEBER Subj: Re: Invalid data in the RIPE database =Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> writes = * = * > Laurent Joncheray <lpj(a)merit.edu> writes: = * > 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... = * = * More radical question: Considering that the NSFnet is going away and = * the routing registry has routing policy, should these attributes = * be deprecated or even removed totally? = =Jean-Michel writes = = * 1- obsolete this field. = * 2- Implement what Laurent proposes (automatic download from Merit). = =I feel for Daniels and Jean-Michel's first option. They should =definately be deprecated (although I have always viewed them as info =only attibutes) and preferably removed. Although some people may find I agree with this point of view. I'm going to put it on the agenda for the DB-WG at the Amsterdam RIPE-Meeting. We should have a *short* review and then agree on a proposal and a *timeschedule* to remove this information from the database. =this information useful currently, wrong information is worse than no =information. I'd say obsolete. Agreed. At the same time we should come up with a recommendation for new ways of storing pieces of information that people maybe still want to record in the DB. (Like connect, gateway, and the like). Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.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 -------------------------------------------------------------------------- ------- End of Forwarded Message

1 0

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

26 Apr '94

Why not deciding this by mail and doing it *now*? (since everybody seems to agree) 10 min to remove those lines from the DB file (grep -v is fine) 10 min to disable the nsf-in attribute in the conf file (or dbupdate.pl) 1h ? to rebuilt the index file. No big deal... > =I feel for Daniels and Jean-Michel's first option. They should > =definately be deprecated (although I have always viewed them as info > =only attibutes) and preferably removed. Although some people may find > > I agree with this point of view. > > I'm going to put it on the agenda for the DB-WG at the Amsterdam > RIPE-Meeting. We should have a *short* review and then agree on a > proposal and a *timeschedule* to remove this information from the > database. > > =this information useful currently, wrong information is worse than no > =information. I'd say obsolete. > > Agreed. > At the same time we should come up with a recommendation for new > ways of storing pieces of information that people maybe still want to > record in the DB. (Like connect, gateway, and the like). > > Wilfried. > -------------------------------------------------------------------------- > Wilfried Woeber : e-mail: Wilfried.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 > -------------------------------------------------------------------------- > -- 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

Re: Invalid data in the RIPE database
by farrache＠ccpnxt5.in2p3.fr 26 Apr '94

26 Apr '94

Hello, I would prefer to obsolete this field. Gilles

2 1

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