- lir-wg - mailman.ripe.net

doc update for the (new) RIPE DB-Software
by Wilfried Woeber, UniVie/ACOnet 01 Sep '93

01 Sep '93

Dear DB-interested folks, according to action 15.11 on me from the 15th RIPE meeting, and as the beta test phase for the new DB-Software is making good progress, we have to agree on the structure, contents and production of new or updated documentation as well. Thus I ask all of you to contribute to this discussion on the DB-WG list. A copy of this is also sent to the Local-IR list FYI, however I propose to have the real discussion going on on th DB-WG list. Amongst other things, I think we should agree on - what is the intended audience for the doc? - what is a good structure? - who should contribute and how/when do we produce the paper(s) Regards, Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 436111 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 436111 170 NIC: WW144 -------------------------------------------------------------------------------

2 1

Authorisation and Notification of Changes
by Daniel Karrenberg 01 Sep '93

01 Sep '93

Folks, here is my long promised writeup on the "notify" and "maintainer" attributes. I hope it is clear enough. It will be discussed at the next RIPE meeting. Hopefully no substantive changes will be necessary. Suggestions on how to improve clarity are always welcome of course. Daniel Authorisation and Notification of Changes in the RIPE Database Daniel Karrenberg RIPE NCC ABSTRACT Two new attributes for all objects in the RIPE database are proposed in order to implement a generalised method for authorising changes and to notify interested parties of any changes made to a specific object. In addition the authorisation method provides a convenient way for distributed maintenance of the database. The Notify Attribute Each RIPE database object will have an optional attribute called notify. The value of the notify attribute is one valid RFC822 e-mail address. There can be multiple notify attributes. Whenever the object concerned is changed in the database a notification message will be sent to each e-mail addresses appearing in a notify attribute. This makes it straightforward to keep track of changes to specific objects and prevent changes from going unnoticed. Multiple notify attributes make it possible to notify a number of interested parties. This could be used to alert all contact persons for an object or the local contact per- sons as well as the relevant service provider. Although it may be tempting to put many notify attributes on database objects in order to notify everyone even remotely interested, this is not recommended. A very few key addresses should be sufficient. Prior to entering any mail address here, the explicit or implicit consent of the person responsible for that particular mailbox needs to be obtained. - 2 - The Maintainer Attribute Each RIPE database object will have an optional attribute called maintainer. The value of the maintainer attribute is a registered maintainer name. There can only be one main- tainer attribute per object. Whenever a change to the object concerned is attempted in a copy of the database the maintainer attribute of the current database object is examined. If there is no maintainer attribute or the maintainer name is authorised to make changes in the copy of the database the update proceeds causing the necessary notifications as per the notify attribute. If the maintainer name has no authorisation to change the local copy of the database, the update request is forwarded to the maintainer for processing. No notifications are per- formed in this case. The following data needs to be maintained locally about each maintainer: Maintainer name Authority none change whole database change only own objects Forwarding Info mail/RFC822-address other/address Authorisation none mail/RFC-822-address other/key Application 1: Regional Registries In order to align the InterNIC and RIPE databases it has been agreed that European objects will be maintained in Europe. The RIPE NCC will provide the data for these objects to the InterNIC for inclusion in their database without further processing. The RIPE NCC will refer all updates for non-European objects to the InternNIC and the InterNIC will refer all updates for European objects to the RIPE NCC for processing. This can be achieved by creating two maintainer names: - 3 - INTERNIC and RIPE-NCC and tagging all European objects with RIPE-NCC and vice versa. The tags can be phased in slowly, avoiding a flag day with the associated massive consistency problems. Over time all objects in the RIPE database would be thus tagged. Updates from third parties for objects with the maintainer attribute added can now be referred correctly. Updates from the other registry for objects it maintains can be accepted without further checking. Example 2: Local Registries Some European local registries keep their own copies of the database containing the objects within their area. This leads to consistency problems as updates can be sent both to the RIPE NCC and to the local registry. Referrals are per- formed by ad hoc methods. Frequently only one of the data- bases is updated and alignment needs to be done manually. By registering maintainer names for the local registries and tagging the appropriate objects this can be automated and made more reliable. The NCC would forward update requests for locally maintained objects to the local registry unless they come from that local registry itself. Example 3: Guarded Objects Some objects such as the autonomous-system object (see ripe-81) need to be protected against changes by anyone but a designated guardian since changes to these objects have a direct operational impact. By registering appropriate maintainer names for the guardi- ans and tagging the objects to be protected this functional- ity can be provided in a canonical way. Any change by third parties to such an object will not only be prevented but cause automatic notification of the guardian through the forwarding mechanism.

2 1

Confirmation of subscription to local-ir@ripe.net
by RIPE Mailing List Maintenance 17 Aug '93

17 Aug '93

Dear All, This is just a confirmation that you are subscribed on the RIPE Mailing list Local Internet Registries <local-ir(a)ripe.net>, the mailing list that deals with the distributed assignment of class C network number assignments. All "official" announcements from the NCC concerning IP number assignments go on this (low volume) list, and everyone who has received (parts of) one or more class C network number blocks for reassignment should be on this list. Please check your entry below, and if changes to your entry need to be made, please reply to the sender of this mail (not the whole list please). Regards, Marten Terpstra RIPE Network Coordination Centre PS One piece of news then, 193.x.y has almost been fully delegated (NOT assigned, just delegated). The NCC has received 194.x.y from IANA/InterNIC for future delegations, and has set up 194.in-addr.arpa procedures like the 193.in-addr.arpa procedures. # # Local Internet Registries <local-ir(a)ripe.net> # ACOnet <Wilfried.Woeber(a)CC.UniVie.ac.at> ARNES <bonac(a)ijs.si> ARNES <jauk(a)ijs.si> BELNET <Stephan.Biesbroeck(a)cs.kuleuven.ac.be> BELWUE <merdian(a)rus.uni-stuttgart.d400.de> CH-NIC <poole(a)chsun.chuug.ch> CERN <fluckiger(a)vxcern.cern.ch> CNS <ih(a)chernikeeff.co.uk> DATANET <son(a)tele.fi> DE-NIC <hostmaster(a)deins.informatik.uni-dortmund.de> DEMON <ripe(a)demon.co.uk> DFN <rauschenbach(a)dfn.de> DKNET <netpasser(a)dkuug.dk> ECRC <Dave.Morton(a)ecrc.de> EMPB <surf030(a)kub.nl> EMPB <pcn(a)tbit.dk> ESTONIA <jack(a)anubis.kbfi.ee> EUNET <hostmaster(a)eu.net> EUNET-AT <waltraud(a)hp4at.eunet.co.at> EUNET-BE <local-ir(a)belgium.eu.net> EUNET-BG <daniel(a)digsys.bg> EUNET-CS <jiri.orsag(a)vscht.cs> EUNET-DE <afs(a)walhalla.Germany.EU.net> EUNET-DK <jensen(a)dkuug.dk> EUNET-ES <jrivero(a)Spain.EU.net> EUNET-FI <ojala(a)fuug.fi> EUNET-GR <stelios(a)csi.forth.gr> EUNET-GR <pantelis(a)ics.forth.gr> EUNET-HR-SI <Ivan.Pepelnjak(a)nil.si> EUNET-IE <local-ir(a)ieunet.ie> EUNET-IT <hostmaster(a)italy.eu.net> EUNET-NL <martijn(a)nluug.nl> EUNET-NO <aras(a)norway.eu.net> EUNET-PT <jalm(a)puug.pt> EUNET-SI <Ivan.Pepelnjak(a)nil.si> EUNET-UK <hostmaster(a)uknet.ac.uk> FORTH <PANTELIS(a)grearn.csi.forth.gr> FUNET <Jyrki.Soini(a)rip.funet.fi> ITALY <staff(a)nis.garr.it> IVO <Seppo.Meri(a)ivo.fi> HEANET <noreilly(a)epee.ucd.ie> HEANET <mnorris(a)dalkey.hea.ie> HUNGARNET <hostmaster(a)sztaki.hu> INFONET <abe(a)infonet.com> ISLAND <marius(a)rhi.hi.is> ISRAEL <hank(a)vm.tau.ac.il> JNT <r.day(a)jnt.ac.uk> NASK <irek(a)frodo.nask.org.pl> PIPEX <local-ir(a)pipex.net> RACAL <sridewood(a)cix.compulink.co.uk> RCCN <local-ir(a)fccn.pt> REDIRIS <ip(a)rediris.es> RENATER <Annie.Renard(a)inria.fr> RIPE-NCC <staff(a)ripe.net> RU-NIC <olg(a)ussr.eu.net> RU SPACE INTERNET <ABEL%ESOC1.BITNET(a)vm.gmd.de> SUNET <ber(a)sunet.se> SURFNET <netmaster(a)surfnet.nl> SWIPNET <ripe-info(a)swip.net> SWITCH <ch-zone-contact(a)switch.ch> TELEPOST NORWAY <ipdrift(a)telepost.no> TIPNET <in-ripe(a)tip.net> UK-NIC <hostmaster(a)nic.ja.net> UNINETT <Havard.Eidnes(a)runit.sintef.no> XLINK <nipper(a)ira.uka.de> # # guests # IANA <jkrey(a)isi.edu> MERIT <epg(a)merit.edu> David Conrad <davidc(a)iij.ad.jp>

1 0

Local registry Workshop
by Daniel Karrenberg 16 Aug '93

16 Aug '93

Dear fellow regitrars, following the positive reactions we received to the idea of a closed workshop for local-ir`s, we are happy to tell you that a workshop will be held: date: Wednesday 15th September, 1993 time: 10.00 am - 12.00 (coffee at 11.00 am) venue: CWI, Kruislaan 409, 1098 SJ Amsterdam room: to be confirmed. Please bring with you any examples of ir applications that you would consider interesting for others to hear about, learn from and discuss. Overhead slides would be useful. The NCC will contribute a few cases and there will be ample time for Q&A and discussion. Daniel

1 0

WAR STORIES closed local-ir workshop
by Anne Lord 10 Aug '93

10 Aug '93

Dear All, Before anyone rushes off to make travel arrangements for the RIPE meeting, this is just to advise you that there is still a provisional plan to hold a local-ir workshop on the morning of the first day of the RIPE meeting (Sept 15th). More definate noises about this will come at the end of the week/next week when the chairman of the group returns from his hols. cheers, Anne

1 0

Workshop for local-IRs
by Anne Lord 05 Aug '93

05 Aug '93

Dear All, At the last RIPE meeting there was a proposal to hold a "local-ir workshop". The idea behind this was to share experiences on running a local registry: trading war-stories and funny experiences, develop a common feeling on what should and should not be escalated to the NCC etc. We have just had someone asking whether this is still planned for the next RIPE meeting. Daniel is the chairman of the group and also on holiday, so we decided that you could decide. So can you let me know if you would still like to see this workshop happen. It would probably be scheduled for the first day of the RIPE meeting in the morning. ie. Wednesday 15th. Prompt replies would be very much appreciated :-) let me know what you think, cheers, Anne

2 1

Re: The addition of guarded fields
by Tony Bates 27 Jul '93

27 Jul '93

bonito(a)nis.garr.it (Antonio_Blasco Bonito) writes: * I think we, as part of the european networking community, should pursue * the spreading of technical knowledge among network providers and * network operators. IP routing is not a trivial issue for the time being, * and the best results in routing coordination is obtained, in my opinion, * when the largest possible number of network operators do the right thing. * This is the spirit of the Internet, I think. * The NCC is a neutral organizations but this does not mean they should * act on behalf of network operators. The net result could be a minor * diffusion of relevant technical knowledge. * Service providers and even large network users communities should know * what they are doing when registering networks, creating guarded fields. * * Also, local registries (down the tree from the NCC) must improve their * efficiency. The Internet is growing very very fast in Europe and we * have to use solutions that scale. A do-all NCC is not the solution, I guess * . * I think the NCC is going is the opposite direction (i.e. proposing * the PRIDE project, which I feel a very important activity in the next futur * e) * Thought I'd comment on this a little as I'm currently working on much stronger syntax checking for the new databsse software. Whilst it is not complete it's pretty careful and it raises exactly the point Blasco brings up. Here are the basic results on the Database breaking them down by object. Object Errors Oks Warnings Total (% in error) aut-num 47 47 0 94 50.0 bdry-gw 0 7 0 7 0.0 domain 1284 913 0 2197 58.4 inetnum 899 8566 0 9465 9.5 person 1087 8824 10 9921 11.0 rout-pr 0 3 0 3 0.0 This is pretty bad as you can see. This includes much stronger checking of mandatory fields and syntax as they are written in the documents which is why the aut-num is high as we currently have a lot of missing mandatory fields. Once the new software is in place the syntax checker will spot all of these. However, it still remains that many entries are submitted without even checking the syntax of the object. At some point we must also remove these errors although this needs some careful thinking about. Any ideas ? Of course one can argue that stronger syntax checking should have been done from day one but it is historic as part of this original software was done before their was an NCC. However, please can we all try to be careful with updates at least til' the software is fully in place ;-). --Tony.

1 0

RE: Workshop for local-IRs
by Wilfried Woeber, UniVie/ACOnet 23 Jul '93

23 Jul '93

Dear Anne, >We have just had someone asking whether this is still planned for the >next RIPE meeting. Daniel is the chairman of the group and also on >holiday, so we decided that you could decide. So can you let me know if >you would still like to see this workshop happen. It would probably >be scheduled for the first day of the RIPE meeting in the morning. >ie. Wednesday 15th. > >Prompt replies would be very much appreciated :-) I'd be really interested to attend on Wednesday 15th, in the morning. Wilfried.

1 0

Re: Workshop for local-IRs
by Erik-Jan.Bos＠SURFnet.nl 23 Jul '93

23 Jul '93

Anne, > At the last RIPE meeting there was a proposal to hold a "local-ir > workshop". The idea behind this was to share experiences on running > a local registry: trading war-stories and funny experiences, > develop a common feeling on what should and should not be escalated > to the NCC etc. > > We have just had someone asking whether this is still planned for the > next RIPE meeting. Daniel is the chairman of the group and also on > holiday, so we decided that you could decide. So can you let me know if > you would still like to see this workshop happen. It would probably > be scheduled for the first day of the RIPE meeting in the morning. > ie. Wednesday 15th. Sounds great to me. I heart some rumors that it would be on Tuesday 14th, but I vote for Wednesday 15th (although it is close to home for me :-) ). > Prompt replies would be very much appreciated :-) Prompt enough?! __ Erik-Jan.

1 0

Request for Information re: Internet Service Providers
by Marten Terpstra 19 Jul '93

19 Jul '93

------- Forwarded Message Date: Sat, 17 Jul 1993 14:33:40 -0700 (PDT) From: Susan Estrada <sestrada(a)nic.cerf.net> Sender: ietf-request(a)IETF.CNRI.Reston.VA.US To: ietf(a)CNRI.Reston.VA.US cc: Susan Estrada <sestrada(a)nic.cerf.net> Subject: Request for Information re: Internet Service Providers I am writing a book called Connecting to the Internet: A Buyer's Guide. I will be including a list (DLIST) of dedicated line providers to make it easy for the reader to find a connection. If you have a network and I have not already contacted you, I need the information at the end of this message for your network. If you would like to add your information, please reply by Tuesday, July 20, noon. The book is going to be published by O'Reilly and Associates and should be available in August. The list will be made available on the Internet courtesy of O'Reilly upon completion. Details are forthcoming about how to get updates of DLIST or add your network information in the future. This message should be forwarded to anyone you think should see it. Thanks for your assistance. Susan Estrada sestrada(a)cerf.net - -------------------------- Network Name: Service Area: Contact: Voice: email: FTP more info: Network Description (short paragraph): ------- End of Forwarded Message

2 1