From Daniel.Karrenberg at ripe.net Wed Oct 14 12:23:41 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 14 Oct 1998 12:23:41 +0200 Subject: /20 Initial Allocations Message-ID: <199810141023.MAA19650@x46.ripe.net> From Daniel.Karrenberg at ripe.net Wed Oct 14 12:24:34 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 14 Oct 1998 12:24:34 +0200 Subject: Initial Allocation Policy Message-ID: <199810141024.MAA19658@x46.ripe.net> Background ---------- The advisory council of ARIN asked ARIN to consider changing the current allcation policy. The initial allocation to a new LIR/ISP should be reduced from a /19 to a /20. The reason being that this would make it easier for new ARIN customers to receive an allocation directly from ARIN rather than from their up-stream provider. According to ARIN's local allocation policy they would then need to justify the utilisation of only a /21 instead of a /20 previously allocated to them by their upstream provider. Another motivation is to improve conservation of address space by reducing the amount of unused addresses in initial allocations. The new policy would not increase the load on the global routing, because the same amount of allocations would still be given out, just one longer prefix. Before deciding on this proposal ARIN has asked the other regional registries (APNIC and RIPE NCC) to also consider this change. Considerations -------------- Based on the RIPE NCC allocation data starting in 1992 we investigated how much impact the proposed change would have on the conservation of address space. We determined how many LIRs in our service region had not used more than a /20 from their initial /19 allocation within one year. The results are as follows: Of 1410 LIRs checked 304 (22%) had assigned not more than a /20 during the first 12 months of operations. This means that 78% of the LIRs had used more than a /20 within one year. The total amount of allocated but, after one year, not yet assigned address space was equivalent to 19 /16s. Some of the LIRs which did not have assigned more than a /20 after one year have since become inactive and the address space concerned will not be assigned in the foreseeable future. However 272 of the 304 are still operational and it is likely that most of them will assign more address space in the future. Further investigations showed that about 50% of those LIRs who haven't used more than a /20 appear to be multihomed. Conclusions ----------- These results have been presented to the LIR WG at the 31. RIPE Meeting in Edinburgh. The LIR WG is the body defining local address space policy for the RIPE NCC. The LIR WG didn't feel that this is a reason to change the current allocation policy. The benefits for conservation are not significant. However, the consequences for aggregation are likely to be noticeable if 80% of LIRs require a second allocation within a year. Furthermore the LIR WG expressed concerns about the routability of longer pefixes in the light of current prefix-length dependent filtering and flap dampening policies. Under the current circumstances the LIR WG did not see a valid reason to change the current allocation policy. We ask the ARIN membership to take this into consideration and consider other ways of achieving the aims of the proposed change. From Paula.Caslav at ripe.net Thu Oct 22 17:49:36 1998 From: Paula.Caslav at ripe.net (Paula Caslav) Date: Thu, 22 Oct 1998 17:49:36 +0200 Subject: web interface for ripe-141 form Message-ID: <199810221549.RAA00279@x30.ripe.net> Dear Local IRs, During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various possibilities to implement a web interface for the IP request form. We would like to further discuss this on the mailing list. Note that we distinguish here between 'syntax checks' which merely make sure the submitted form is sensible, and 'full checks' which check the data it contains. As a first step we propose to implement a public web page based at the RIPE NCC that LIRs can use to check the syntax of their IP request forms. The output will be a detailed error report or a request form suitable for pasting into an email. This would enable LIRs to check the syntax of a request before sending it to RIPE NCC, or a LIR customer to check the syntax of a form before sending it to the LIR. A next step would a web page based at the LIR's server that LIRs can use to check the syntax of their IP request forms. The output will be a detailed error report or an IP request form suitable for pasting into an email. The source code will be available to allow the LIR to make this available to their customers, with hooks so additional comments and local-language labels can be easily added or so the result can be automatically sent by the program in an email. At this phase, support would be limited initially. The last step would be a web page based at the RIPE NCC that will allow LIRs *only* ( controlled by password) to submit an IP request form. This would mean: - Requests within the LIR's assignment window will be fully checked but will *not* create a ticket and will *not* be forwarded to a RIPE NCC hostmaster for further processing. - Requests outside the LIR's assignment window will be fully checked. A new ticket will be created and all submissions of the form will be added to the ticket. This ticket will be forwarded to a RIPE NCC hostmaster on passing all the checks, or exceeding the number of checks limit. If you have any suggestions or comments, please let us know. Kind Regards, Maldwyn Morris P.S. I am sending this mail to both the local-ir list and the lir-wg list, to make sure that everybody is aware of this discussion. However the discussion itself should take place on the lir-wg mailing list. If you are not subscribed to that list but wish to follow this discussion, please send a mail to majordomo at ripe.net with HELP in the body. You can also follow the discussion in the archives on our web site.- Paula Caslav From lmb at pointer.teuto.de Thu Oct 22 19:15:40 1998 From: lmb at pointer.teuto.de (=?iso-8859-1?Q?Lars_Marowsky-Br=E9e?=) Date: Thu, 22 Oct 1998 19:15:40 +0200 Subject: web interface for ripe-141 form In-Reply-To: <199810221549.RAA00279@x30.ripe.net>; from "Paula Caslav" on 1998-10-22T17:49:36 References: <199810221549.RAA00279@x30.ripe.net> Message-ID: <19981022191540.N30767@pointer.teuto.de> On 1998-10-22T17:49:36, Paula Caslav said: > As a first step we propose to implement a public web page based at the > RIPE NCC that LIRs can use to check the syntax of their IP request > forms. The output will be a detailed error report or a request form > suitable for pasting into an email. While this is a great idea, I would rather like access to the "official" RIPE NCC robot code so we can use the real thing in our own ticketing system. I see the need for those poor folks who can't/don't want to run Perl (I just assume it is perl), but on our list, a web interface to the RIPE NCC hostmaster account is not very highly rated. Sincerely, Lars Marowsky-Brie -- Lars Marowsky-Brie Network Management teuto.net Netzdienste GmbH - DPN Verbund-Partner From leigh at wisper.net Thu Oct 22 20:12:00 1998 From: leigh at wisper.net (Leigh Porter) Date: Thu, 22 Oct 1998 18:12:00 +0000 Subject: web interface for ripe-141 form References: <199810221549.RAA00279@x30.ripe.net> <19981022191540.N30767@pointer.teuto.de> Message-ID: <362F756F.44A66187@wisper.net> Lars Marowsky-Brie wrote: How about developing a front-end that can run on the LIR's system instead, something that will present a nice Web front end and then send an email to the robot in the background? -- Leigh Porter > > As a first step we propose to implement a public web page based at the > > RIPE NCC that LIRs can use to check the syntax of their IP request > > forms. The output will be a detailed error report or a request form > > suitable for pasting into an email. > > While this is a great idea, I would rather like access to the "official" RIPE > NCC robot code so we can use the real thing in our own ticketing system. > > I see the need for those poor folks who can't/don't want to run Perl (I just > assume it is perl), but on our list, a web interface to the RIPE NCC > hostmaster account is not very highly rated. > > Sincerely, > Lars Marowsky-Brie > > -- > Lars Marowsky-Brie > Network Management > > teuto.net Netzdienste GmbH - DPN Verbund-Partner From patrick.de_groote at unisource.be Thu Oct 22 22:15:58 1998 From: patrick.de_groote at unisource.be (De Groote, Patrick) Date: Thu, 22 Oct 1998 22:15:58 +0200 Subject: web interface for ripe-141 form Message-ID: A syntax-checking web page would be valuable indeed. The registration of networks is not my primary job-description, but comes with the job. I therefore spend a lot of time getting the syntax right, due to the fact that it does not happen every day (or every week) that I need to fill out a ripe-141. Having the customer check out the syntax before he submits would be of equal, if not larger value. rgds Patrick Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer >-----Original Message----- >From: Paula Caslav [SMTP:Paula.Caslav at ripe.net] >Sent: Thursday, October 22, 1998 5:50 PM >To: local-ir at ripe.net >Cc: lir-wg at ripe.net >Subject: web interface for ripe-141 form > > >Dear Local IRs, > >During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various >possibilities to implement a web interface for the IP request form. >We would like to further discuss this on the mailing list. > >Note that we distinguish here between 'syntax checks' which merely >make sure the submitted form is sensible, and 'full checks' which >check the data it contains. > >As a first step we propose to implement a public web page based at the >RIPE NCC that LIRs can use to check the syntax of their IP request >forms. The output will be a detailed error report or a request form >suitable for pasting into an email. > >This would enable LIRs to check the syntax of a request before sending >it to RIPE NCC, or a LIR customer to check the syntax of a form before >sending it to the LIR. > >A next step would a web page based at the LIR's server that LIRs can >use to check the syntax of their IP request forms. The output will be >a detailed error report or an IP request form suitable for pasting >into an email. The source code will be available to allow the LIR to >make this available to their customers, with hooks so additional >comments and local-language labels can be easily added or so the >result can be automatically sent by the program in an email. At this >phase, support would be limited initially. > >The last step would be a web page based at the RIPE NCC that will >allow LIRs *only* ( controlled by password) to submit an IP request >form. > >This would mean: > >- Requests within the LIR's assignment window will be fully checked but > will *not* create a ticket and will *not* be forwarded to a RIPE NCC > hostmaster for further processing. > >- Requests outside the LIR's assignment window will be fully checked. > A new ticket will be created and all submissions of the form will be > added to the ticket. This ticket will be forwarded to a RIPE NCC > hostmaster on passing all the checks, or exceeding the number of > checks limit. > > >If you have any suggestions or comments, please let us know. > > >Kind Regards, > >Maldwyn Morris > >P.S. I am sending this mail to both the local-ir list and the lir-wg >list, to make sure that everybody is aware of this discussion. However >the discussion itself should take place on the lir-wg mailing list. If >you are not subscribed to that list but wish to follow this discussion, >please send a mail to majordomo at ripe.net with HELP in the body. You can >also follow the discussion in the archives on our web site.- Paula >Caslav > From lbernard at artinternet.fr Fri Oct 23 15:06:40 1998 From: lbernard at artinternet.fr (Laurent BERNARD) Date: Fri, 23 Oct 1998 15:06:40 +0200 Subject: web interface for ripe-141 form Message-ID: <4.1.19981023150536.00978730@mail.artinternet.fr> 'couldn't say it more accurately. Thanks. Best regards. ---------------------------------------------------- A syntax-checking web page would be valuable indeed. The registration of networks is not my primary job-description, but comes with the job. I therefore spend a lot of time getting the syntax right, due to the fact that it does not happen every day (or every week) that I need to fill out a ripe-141. Having the customer check out the syntax before he submits would be of equal, if not larger value. rgds Patrick Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer >-----Original Message----- >From: Paula Caslav [SMTP:Paula.Caslav at ripe.net] >Sent: Thursday, October 22, 1998 5:50 PM >To: local-ir at ripe.net >Cc: lir-wg at ripe.net >Subject: web interface for ripe-141 form > > >Dear Local IRs, > >During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various >possibilities to implement a web interface for the IP request form. >We would like to further discuss this on the mailing list. > >Note that we distinguish here between 'syntax checks' which merely >make sure the submitted form is sensible, and 'full checks' which >check the data it contains. > >As a first step we propose to implement a public web page based at the >RIPE NCC that LIRs can use to check the syntax of their IP request >forms. The output will be a detailed error report or a request form >suitable for pasting into an email. > >This would enable LIRs to check the syntax of a request before sending >it to RIPE NCC, or a LIR customer to check the syntax of a form before >sending it to the LIR. > >A next step would a web page based at the LIR's server that LIRs can >use to check the syntax of their IP request forms. The output will be >a detailed error report or an IP request form suitable for pasting >into an email. The source code will be available to allow the LIR to >make this available to their customers, with hooks so additional >comments and local-language labels can be easily added or so the >result can be automatically sent by the program in an email. At this >phase, support would be limited initially. > >The last step would be a web page based at the RIPE NCC that will >allow LIRs *only* ( controlled by password) to submit an IP request >form. > >This would mean: > >- Requests within the LIR's assignment window will be fully checked but > will *not* create a ticket and will *not* be forwarded to a RIPE NCC > hostmaster for further processing. > >- Requests outside the LIR's assignment window will be fully checked. > A new ticket will be created and all submissions of the form will be > added to the ticket. This ticket will be forwarded to a RIPE NCC > hostmaster on passing all the checks, or exceeding the number of > checks limit. > > >If you have any suggestions or comments, please let us know. > > >Kind Regards, > >Maldwyn Morris > >P.S. I am sending this mail to both the local-ir list and the lir-wg >list, to make sure that everybody is aware of this discussion. However >the discussion itself should take place on the lir-wg mailing list. If >you are not subscribed to that list but wish to follow this discussion, >please send a mail to majordomo at ripe.net with HELP in the body. You can >also follow the discussion in the archives on our web site.- Paula >Caslav > Laurent BERNARD "Not knowing it couldn't be done, he went ahead and did it" From ludger.bornhorst at t-online.de Fri Oct 23 15:02:55 1998 From: ludger.bornhorst at t-online.de (Ludger Bornhorst) Date: Fri, 23 Oct 1998 15:02:55 +0200 Subject: web interface for ripe-141 form References: <199810221549.RAA00279@x30.ripe.net> <19981022191540.N30767@pointer.teuto.de> Message-ID: <36307E7F.2180@t-online.de> Lars Marowsky-Brie wrote: > > On 1998-10-22T17:49:36, > Paula Caslav said: > > > As a first step we propose to implement a public web page based at the > > RIPE NCC that LIRs can use to check the syntax of their IP request > > forms. The output will be a detailed error report or a request form > > suitable for pasting into an email. > > While this is a great idea, I would rather like access to the "official" RIPE > NCC robot code so we can use the real thing in our own ticketing system. > > I see the need for those poor folks who can't/don't want to run Perl (I just > assume it is perl), but on our list, a web interface to the RIPE NCC > hostmaster account is not very highly rated. > > Sincerely, > Lars Marowsky-Brie > > -- > Lars Marowsky-Brie > Network Management > > teuto.net Netzdienste GmbH - DPN Verbund-Partner I agree with Lars. We would get more benefits on a webinterface between our LIR and our customers rather than between LIR and RIPE NCC. For us, it is important to establish a mail interface for our customers at our site. This mail interface shall do mostly the same as the RIPE NCC mail distribution robot. Question: Maybe it is a good idea to provide the "official" RIPE NCC robot code for downlaod, so that every LIR can use it and adjust it to their needs? kind regards -- Ludger Bornhorst, Deutsche Telekom AG, ZDK Zentrum fuer Datenkommunikation, Oldenburg, Germany Tel.: +49 441/234-5678 Fax : +49 441/27463 From nmalik at eu.concert.net Mon Oct 26 09:42:54 1998 From: nmalik at eu.concert.net (Naeem malik) Date: Mon, 26 Oct 1998 09:42:54 +0100 Subject: web interface for ripe-141 form Message-ID: <000401be00bc$9f7550f0$a9a69793@ws-4476.ge-eur.bt.com> Dear Local IRs, During the LIR WG meeting at RIPE 31 in Edinburgh we discussed various possibilities to implement a web interface for the IP request form. We would like to further discuss this on the mailing list. Note that we distinguish here between 'syntax checks' which merely make sure the submitted form is sensible, and 'full checks' which check the data it contains. As a first step we propose to implement a public web page based at the RIPE NCC that LIRs can use to check the syntax of their IP request forms. The output will be a detailed error report or a request form suitable for pasting into an email. This would enable LIRs to check the syntax of a request before sending it to RIPE NCC, or a LIR customer to check the syntax of a form before sending it to the LIR. I for one think it is a good idea. If anybody is interested, take a look at APNIC's equivalent web form at http://www.apnic.net/reg.html which would serve as a useful start and could be improved on. This could also be extended to submitting the network object, as it is a bit laborious at the moment. Another example if you'd like a look is available from the Cable & Wireless (used to be MCI) web pages (SWIP updates) http://infopage.cw.net/Address/swip.html I think this would be a useful development and would suggest that you endeavour to proceed with it. For those who LIR's who have not got a web form for their customers, I suggest taking a look at http://services.concert.net/address-space/request.html. Note this page has been designed for all the registries, RIPE/APNIC/ARIN and is used by our customers many times during the day. Com on guys, lets move into the 20th century. Regards, Naeem Malik From phk at critter.freebsd.dk Fri Oct 23 15:36:11 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 23 Oct 1998 15:36:11 +0200 Subject: web interface for ripe-141 form In-Reply-To: Your message of "Thu, 22 Oct 1998 22:15:58 +0200." Message-ID: <4759.909149771@critter.freebsd.dk> I think we hear the need for several things here. It sounds to me like the best idea right now would be to do two things: 1. release the perl/C/INTERCAL code used to validate the form to the interested LIRs. Needless to say, future updates needs to be released as well and announced to interested parties. This will as far as I can tell cater for the "high-end" users. 2. Make a web-form version of the ripe-141, where part of the URL is interpreted as where to email the completed form when the user types "submit". This would allow a LIR to reference the RIPE version of the form from their own pages, and have the result emailed to themselves before it hits RIPE by using their own email-address in the URL. Something like: http://www.ripe.net/webforms/ripe141.html?recipient=hostmaster at thislir.co.uk A slightly different use could be for LIRs to submit to RIPE using the same form: http://www.ripe.net/webforms/ripe141.html?recipient=hostmaster at ripe.net,ncclir=uk.thislir Who would not be satisfied with this ? Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal From ncc at ripe.net Wed Oct 28 12:44:20 1998 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Wed, 28 Oct 1998 12:44:20 +0100 Subject: New Document available: RIPE-185 Message-ID: <199810281144.MAA29769@x30.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-185 Title: European Internet Registry Policies and Procedures Author: RIPE Local Internet Registry Working Group Date: 26 October 1998 Obsoletes: ripe-159 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document is an update to ripe-159, the European Internet Registry Policies and Procedures document. It includes policy changes agreed upon by the LIR working group and the local-ir mailing list. The main change is that an allocation only needs to be 80% used up before requesting a new one (used to be 90%). There are also minor changes to make the text in the document clearer, and to include better examples. These changes were circulated to the local-ir list several weeks ago. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-185.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-185.txt plain text version You can also access the RIPE documents in HTML format via WWW: http://www.ripe.net/docs/ripe-185.html Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to with "send HELP" in the body text. From iris-nic at rediris.es Wed Oct 28 18:11:08 1998 From: iris-nic at rediris.es (IRIS-NIC) Date: Wed, 28 Oct 1998 18:11:08 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: "Neil J. McRae" "Re: Massive changed in the Ripe Database.." (Oct 28, 4:32pm) References: <199810280852.IAA14441@NetBSD.noc.COLT.NET> Message-ID: <981028181109.ZM29140@chico.rediris.es> [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] On Oct 28, 4:32pm, Neil J. McRae wrote: > Subject: Re: Massive changed in the Ripe Database.. > On Tue, 27 Oct 1998 18:31:50 +0100 (CET) > Winfried Haug wrote: > > > Hello, > > > > today we noticed, that a *huge* number of Ripe Handles has been > > deleted or modified by > > > > - From: Trevor McBryan > > - Subject: longack > > - Date: Tue, 27 Oct 1998 13:33:35 +0000 > > - Msg-Id: <3635CBAF.2C707C44 at rain.fr> > > > > We saw one change like this also. > We have seen other ten changes in our person objects too. -- +---------------------------------------------------------------+ | RedIRIS NIC | | Centro de Comunicaciones CSIC RedIRIS | | Serrano 142 Tel: + 34 915855150 | | 28006 Madrid Fax: + 34 915855146 | | SPAIN Email: iris-nic at rediris.es | +---------------------------------------------------------------+ From olli at spike.allcon.net Wed Oct 28 17:57:32 1998 From: olli at spike.allcon.net (Oliver J. Albrecht) Date: Wed, 28 Oct 1998 17:57:32 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: ; from Pavel Golubev on Wed, Oct 28, 1998 at 05:34:20PM +0200 References: <19981028093530.A5341@Space.Net> Message-ID: <19981028175732.A9857@spike.allcon.net> [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] Hi, On Wed, Oct 28, 1998 at 05:34:20PM +0200, Pavel Golubev wrote: > I think PGP-signed request (Internic for example) - good way to stop > unauthorized access to database... That's probably the best approach, *if* it's done right. Internic PGP authentication has a really bad track record of (mostly) not working as expected. Those of you who with PGP enabled handles or readers of the guardian list are probably well aware of this :-) Just my $0.02... -- Oliver J. Albrecht AllCon GmbH http://www.allcon.net/ Network Administration Westerallee 139 Tel: +49 461 90393-0 olli at spike.allcon.net D-24941 Flensburg Fax: +49 461 90393-33 From Marc.Roger at belnet.be Wed Oct 28 16:47:42 1998 From: Marc.Roger at belnet.be (Marc Roger) Date: Wed, 28 Oct 1998 16:47:42 +0100 (MET) Subject: Massive changed in the Ripe Database.. In-Reply-To: <19981028100321.A8146@spike.allcon.net> Message-ID: [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] Oliver, I have received the following answer this morning: > Date: Wed, 28 Oct 1998 11:22:13 +0100 (MET) > From: Trevor McBryan > Message-Id: <199810281022.LAA15215 at mason.rain.fr> > To: Marc.Roger at belnet.be > Subject: Re: Requested RIPE database object changes (fwd) > > Sorry for the error, > > All of the RIPE database objects associated with the addresses > managed by Global One are being transferred to their responsability. > > Unfortunately, I forgot part of a filter to overlook most of the > person objectso for the migration. > > Your object has NOT been deleted if there was a maintainer; otherwise, > the other objects are being recreated. > > The RIPE hostmaster/ncc is aware of the probleme and is working with > us for the corrections. > > Cordialement, > > Trevor McBryan I think it clarifies things a bit. On Wed, 28 Oct 1998, Oliver J. Albrecht wrote: > I don't know what this person is up to, but he also tried to > delete one of the handles maintained by us (SS1586-RIPE). > Shortly after it happened (yesterday around 18:00 GMT) , I > sent email asking for the reason, but received no reply yet. > Maybe someone in France would like to call this gentleman > on the phone: -- Marc.Roger at belnet.be, BELNET From dol at east.ru Wed Oct 28 17:51:27 1998 From: dol at east.ru (Basil V. Dolmatov) Date: Wed, 28 Oct 1998 19:51:27 +0300 (MSK) Subject: Massive changed in the Ripe Database.. In-Reply-To: <310440382fffffffffffffff22ff745a363757fa@dnstelecom.fr> Message-ID: [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] It is robot message... ;) All variants contain same typo "objectso"... ;) I think, that autoresponder is set on this address... -------------------------------------- Basil (Vasily) Dolmatov dol at east.ru +7-095-956-4951 East Connection ISP, Moscow, Russia. (http://www.east.ru) Nick handles ;) : BVD12, DOL1-RIPE, VVD2-RIPN On Wed, 28 Oct 1998, Pierre Reynes wrote: > Oliver, > > This is the answer we got from Trevor: > > ----BEGIN PASTE---- > Sorry for the error, > > All of the RIPE database objects associated with the addresses > managed by Global One are being transferred to their responsability. > > Unfortunately, I forgot part of a filter to overlook most of the > person objectso for the migration. > > Your object has NOT been deleted if there was a maintainer; otherwise, > the other objects are being recreated. > > The RIPE hostmaster/ncc is aware of the probleme and is working with > us for the corrections. > > Cordialement, > > Trevor McBryan > > ----END PASTE--- > > Best, > Pierre REYNES > -------------------------------------------------------------- > DNS TELECOM - Votre courtier en telecommunications > Imm. La Fayette 2, place des vosges 92051 Paris la Difense 5 > Tel: +33 (0)1 41 16 84 56 Fax: +33 (0)1 49 05 46 89 > Mobile: +33 (0)6 03 91 89 14 > Mailto:preynes at dnstelecom.fr > -------------------------------------------------------------- > Les Solutions Internet Intelligentes : > http://www.dnstelecom.fr/Solutions/Internet/ > > -----Original Message----- > From: Oliver J. Albrecht [mailto:olli at spike.allcon.net] > Sent: Wednesday, October 28, 1998 10:03 AM > To: haug at seicom.de; local-ir at ripe.net > Subject: Re: Massive changed in the Ripe Database.. > > > Hi, > > On Tue, Oct 27, 1998 at 06:31:50PM +0100, Winfried Haug wrote: > > > today we noticed, that a *huge* number of Ripe Handles has been > > deleted or modified by > > > > - From: Trevor McBryan > > - Subject: longack > > - Date: Tue, 27 Oct 1998 13:33:35 +0000 > > - Msg-Id: <3635CBAF.2C707C44 at rain.fr> > > I don't know what this person is up to, but he also tried to > delete one of the handles maintained by us (SS1586-RIPE). > Shortly after it happened (yesterday around 18:00 GMT) , I > sent email asking for the reason, but received no reply yet. > Maybe someone in France would like to call this gentleman > on the phone: > > person: Trevor McBryan > address: CSI Transpac > address: 12 bis rue Campagne Premiere > address: 75014 Paris > phone: +33 1 43 35 82 05 > fax-no: +33 1 43 35 82 47 > e-mail: tmcb at rain.fr > nic-hdl: TMCB > mnt-by: RAIN-TRANSPAC > changed: mcbryan at innet.lu 961205 > source: RIPE > > -- > Oliver J. Albrecht AllCon GmbH http://www.allcon.net/ > Network Administration Westerallee 139 Tel: +49 461 90393-0 > olli at spike.allcon.net D-24941 Flensburg Fax: +49 461 90393-33 > From sveta at lucky.net Wed Oct 28 18:21:32 1998 From: sveta at lucky.net (Svetlana Tkachenko) Date: Wed, 28 Oct 1998 19:21:32 +0200 (EET) Subject: Massive changed in the Ripe Database.. In-Reply-To: from Pavel Golubev at "Oct 28, 98 05:34:20 pm" Message-ID: <199810281721.TAA23606@burka.carrier.kiev.ua> [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] > > I think PGP-signed request (Internic for example) - good way to stop > unauthorized access to database... Why don't make "auth" attribute mandatory everywhere? Like in mntner object. From robert at irc.dknet.dk Wed Oct 28 19:36:04 1998 From: robert at irc.dknet.dk (=?ISO-8859-1?Q?Robert_Martin-Leg=E8ne?=) Date: Wed, 28 Oct 1998 19:36:04 +0100 (CET) Subject: PGP (Was: Re: Massive changed in the Ripe Database..) In-Reply-To: <19981028175732.A9857@spike.allcon.net> Message-ID: On Wed, 28 Oct 1998, Oliver J. Albrecht wrote: > That's probably the best approach, *if* it's done right. > Internic PGP authentication has a really bad track record of > (mostly) not working as expected. The NCC so far has only proven to be very competent, so I don't think that will be a problem. They work better than almost any ISP. -- Robert Martin-Leg?ne / Null ! robert at irc.dknet.dk (not working for dknet anymore) From ncc at ripe.net Wed Oct 28 12:44:20 1998 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Wed, 28 Oct 1998 12:44:20 +0100 Subject: New Document available: RIPE-185 Message-ID: <199810281144.MAA29769@x30.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-185 Title: European Internet Registry Policies and Procedures Author: RIPE Local Internet Registry Working Group Date: 26 October 1998 Obsoletes: ripe-159 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document is an update to ripe-159, the European Internet Registry Policies and Procedures document. It includes policy changes agreed upon by the LIR working group and the local-ir mailing list. The main change is that an allocation only needs to be 80% used up before requesting a new one (used to be 90%). There are also minor changes to make the text in the document clearer, and to include better examples. These changes were circulated to the local-ir list several weeks ago. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-185.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-185.txt plain text version You can also access the RIPE documents in HTML format via WWW: http://www.ripe.net/docs/ripe-185.html Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to with "send HELP" in the body text. From koch at sgh-net.de Wed Oct 28 21:13:31 1998 From: koch at sgh-net.de (Alexander Koch) Date: Wed, 28 Oct 1998 21:13:31 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: <19981028175732.A9857@spike.allcon.net>; from "Oliver J. Albrecht" on Wed, 28 Oct 1998 17:57:32 +0100 References: <19981028093530.A5341@Space.Net> <19981028175732.A9857@spike.allcon.net> Message-ID: <19981028211331.A24999@nuss.hannover.sgh-net.de> [PGP and InterNIC] Well, yes, InterNIC sux violently. Did whois.internic.net work at all today? *sigh* Though I think it's way easier (as a first step) to discuss about auth: being mandatory or any such thing. If you transfer domains, it's nice to have the same handle, sure, but as we've seen it has some *major* drawbacks (sp?). I think a mntner object with an email as authentication would suffice for something like this not happening again.. Though good old PGP would be nice. But then there's the question whether to support PGP 5 (please, don't ) or GNU PG or... Alexander -- SGH Internet Division, Alexander Koch, Systems Administration Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307 From Paula.Caslav at ripe.net Thu Oct 29 12:35:52 1998 From: Paula.Caslav at ripe.net (Paula Caslav) Date: Thu, 29 Oct 1998 12:35:52 +0100 Subject: ripe-141 web interface Message-ID: <199810291135.MAA05524@x30.ripe.net> Hi, Thanks for the interest in and discussion about our proposed release of the web interface for ripe-141 forms. We think there is sufficient interest to proceed, and would like to clarify what we are planning: First, we will write and install a public web page at RIPE NCC which allows the entry of a ripe-141 form for *syntax* checking. The output will be a plain text page which can be pasted into an email. Second, we will release the source code of the above, with an added hook to allow sending of the output by email. LIRs will be able to install adaptations of this for use by their customers to check and submit their requests to the LIR, and by their hostmasters to check and submit their requests to RIPE NCC. The LIRs will be free to use this code in any other systems they have. We will implement a public page at RIPE NCC first to allow us to debug the software before it is made publicly available, and understand any problems the LIRS have in the implementation. We would hope to release the software soon after it is written. We cannot release the full code that we use here at the RIPE NCC, because it does some checks that we can only make available for requests that are within a registry's assignment window. These checks include looking for policy problems (as opposed to pure syntax problems) such as reserved addresses or inefficient address space usage. This is something that we'd like to be able to track. For example if a registry sends a request through the robot and it gives an error that the addresses are not being used efficiently, and then they decide to just increase the numbers everywhere to make it look more efficient, we'd like to be able to track this (yes, we have seen this happen). Therefore we will only make this part of the code available for the requests that are within a registry's assignment window and do not have to be sent to the RIPE NCC for approval. Therefore, we can only make this available on our web server (as part of the third stage). The third stage would be a public web page at RIPE NCC with some form of password authentication, which would allow LIRs to *fully* check assignments both smaller and larger than their assignment window, with larger assignments being sent on to the RIPE NCC hostmasters. We hope this meets most people's requirements. Inetnum database object submission thorugh a web page is being discussed in the db-wg. Therefore if you are interested in this topic, please get involved in that working group. To clarify the setup here at RIPE NCC: All mail to hostmaster at ripe.net is handled by the 'autohmdist' robot. This robot calls the 'autohm' robot to check and respond to ripe-141 requests, which we are discussing here. Both robots add messages to the hostmaster ticketing system, 'rtt'. Human hostmasters read and respond to messages through rtt. Paula Caslav Registration Services Manager RIPE NCC Maldwyn Morris Software Manager RIPE NCC From ripe-dbm at ripe.net Thu Oct 29 15:46:11 1998 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Thu, 29 Oct 1998 15:46:11 +0100 Subject: Events of Tuesday, 27 October 1998 Message-ID: <199810291446.PAA17212@office.ripe.net> Dear Colleagues, On Tuesday, 27 October 1998, a user of the RIPE Network Management Database accidentally deleted many [person] objects. The objects affected were either not maintained by a 'mntner' object or were maintained by a 'mntner' object with an authentication mechanism of NONE. The RIPE NCC has investigated this and learned that it was a genuine mistake by this user. When a person object is deleted, its nic-handle is available for re-use immediately. Therefore, you may find that a nic-handle now points to a different person or role object. We recommend that you check the consistency of your data i.e. see if the nic-handles in the admin-c, tech-c, and zone-c lines of your objects refer to the correct person or role objects. We understand that an attempt was made to re-create the deleted objects by the individual who originally deleted them. Please search for your person objects using both the name and the nic-handle. It is possible that your object has been re-created, but with a different nic-handle. If so, you must update your inetnum, route, mntner, etc. objects that refer to the previous nic-handles in the admin-c, tech-c, and zone-c lines. You should replace the old nic-handles with the new ones. To check whether a certain nic-handle is referenced anywhere, you can use the inverse look-up flag. For example, you can do: "whois -i admin-c,tech-c,zone-c " to see if that nic-handle is referenced anywhere as admin-c, tech-c, or zone-c (e.g. as in domain objects). If one or more of your person and/or role objects have not been re-created, we suggest that you first try to re-create them using the original nic-handle. This way, you do not have to change any of the references that use this nic-handle. If the nic-handle has been re-used, you should try to create the person or role object with the AUTO-1 keyword. In this case, however, you will have to change the inetnum, domain, or other objects that reference this nic-handle to point to the new one. (Use the the "-i" flag mentioned above to find which objects reference the old nic-handle). The RIPE NCC shall, as a part of its service to the RIPE community, support users to restore their data to a consistent state. We estimate that this should take about one working day. Please note that it is the users responsibility to restore their own data. We would like to stress that the RIPE NCC operates the RIPE Database, however the responsibility for managing user data lies with the users. Mechanisms to protect data against unauthorised or unintentional modification exist for several years now. The RIPE NCC has always emphasized the importance of authentication mechanisms and has been recently working to introduce even stronger procedures. We encourage users to deploy these authentication mechanisms. Please read ripe-157, section 2.3 on how this works. If you have any problems with the RIPE Database, please send an email to . Regards, The RIPE NCC Database Group. From ripe-dbm at ripe.net Thu Oct 29 16:30:54 1998 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Thu, 29 Oct 1998 16:30:54 +0100 Subject: Big delays with . Message-ID: <199810291530.QAA23529@office.ripe.net> Dear Colleagues, Last night, there was a higher than usual number of messages to . Thus, there were some delays in processing these messages. This morning, we carried out some unrelated preventative maintenance and this has led to more delays. Your messages are being stored and will be processed as soon as possible. BTW, this maintenance was not linked to the recent actions of any user of the RIPE Database :-) If you have any questions, please contact . It is either Murphy's Law, or Hallowe'en, or the Great Pumpkin, or whatever, that this happened this week. We thank you for your patience. Regards, --------------------------- The RIPE NCC Database Group. From rimas at taide.lt Fri Oct 30 09:00:22 1998 From: rimas at taide.lt (Rimas Janusauskas) Date: Fri, 30 Oct 1998 09:00:22 +0100 (NFT) Subject: Events of Tuesday, 27 October 1998 In-Reply-To: <199810291446.PAA17212@office.ripe.net> Message-ID: On Thu, 29 Oct 1998, RIPE Database Administration wrote: > When a person object is deleted, its nic-handle is available for > re-use immediately. Therefore, you may find that a nic-handle now > points to a different person or role object. We recommend that you > check the consistency of your data i.e. see if the nic-handles in the > admin-c, tech-c, and zone-c lines of your objects refer to the correct > person or role objects. It's true, that nic-handle is available for re-use, but it could be (re)created only using directly. If AUTO-# is used to creat new nic handle, bigest value+1 is choosen although "holes" exists. > Please note > that it is the users responsibility to restore their own data. > We would like to stress that the RIPE NCC operates the RIPE Database, > however the responsibility for managing user data lies with the users. Is it possible implement such feature, that "e-mail" attribute(s) should be used as "notify" as well. In that case nic handle holder will be always informed about (un)expected changes. best regards, Rimas Janusauskas, Taide Net Hostmaster From ripe-dbm at ripe.net Fri Oct 30 16:27:54 1998 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Fri, 30 Oct 1998 16:27:54 +0100 Subject: Objects affected by events of 27/10/1998. Message-ID: <199810301527.QAA16160@office.ripe.net> Dear Colleagues, We keep detailed logfiles of all updates to the RIPE Database. We processed these files to produce lists of all objects affected by the incidents earlier this week. We have decided to make these files public, to support you when ensuring that your data is consistent. These files contain only the name and nic-handle of affected person objects. These files may be obtained by anonymous ftp from: ftp://ftp.ripe.net/ripe/dbase/981027-incident.Delete ftp://ftp.ripe.net/ripe/dbase/981027-incident.New ftp://ftp.ripe.net/ripe/dbase/981027-incident.Update There are also gzip'ed versions available, using the same filenames, with the .gz extension. If you have any questions, please contact . Regards, Ambrose Magee ----------------------- RIPE NCC Database Group From ripe-dbm at ripe.net Fri Oct 30 16:50:10 1998 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Fri, 30 Oct 1998 16:50:10 +0100 Subject: Database performance - an update. Message-ID: <199810301550.QAA18784@office.ripe.net> Dear Colleagues, I shall begin by saying that I wrote the two messages to the local-ir, lir-wg and db-wg yesterday. I wrote them for, and on behalf of, the RIPE NCC Database Group. I realise that many of you are unhappy that these messages had no personal signature. The responsibility for this oversight is mine. In all previous postings to these lists, I have signed my name. I shall continue to do this. You already know what happened on Tuesday, 27 October, last. Yesterday morning, we had no option but to do preventative maintenance of the database; this was not related to the activity of any user last Tuesday. However, nearly all updates were stopped until around 1630 MET. Unfortunately, there was a higher than usual number of updates sent to the database yesterday. These two facts had one result: a very long delay before your updates were processed. At this time there is still a long queue of unprocessed updates, but updates are being processed again. Obviously, a faster, more powerful machine would process updates quicker than the current machine. On Tuesday, the problem was that it was possible to delete objects referenced somewhere in the database before deleting all references to that object. Imposing such a constraint (referential integrity check) has been already been considered. Tuesday's incident was not a security problem - anyone with the correct authorization can still make a mistake. At the previous RIPE meeting in Edinburgh, we announced new software, including a referential integrity check, and new hardware, a Sun E450 machine. We intended to deploy both of these at the end of October or early November. We had bad luck that several unrelated problems occurred this week, just before the planned deployment of the new code and the new machine. Now, a status report. All your updates have been queued - there is no need to re-send them. We estimate that the situation should be back to normal tomorrow, if not sooner. We still plan to introduce the new software and hardware next week. We thank you all for your support in the past and we assure you of our continuing efforts to support you in your work. Your sincerely, Ambrose Magee -------------------------------------------------- for, and on behalf of, the RIPE NCC Database Group. From mike.norris at heanet.ie Fri Oct 30 17:27:19 1998 From: mike.norris at heanet.ie (Mike Norris) Date: Fri, 30 Oct 1998 16:27:19 -0000 Subject: Database performance - an update. Message-ID: <01BE0422.2AD73A60@pc19.heanet.ie> > I shall begin by saying that I wrote the two messages to > the local-ir, lir-wg and db-wg yesterday. I wrote them > for, and on behalf of, the RIPE NCC Database Group. I > realise that many of you are unhappy that these messages > had no personal signature. The responsibility for this > oversight is mine. In all previous postings to these lists, > I have signed my name. I shall continue to do this. Ambrose, you may not have put your name at the end of the mail, but we knew it was you anyway - your style is inimitable and your sense of humour unique. Keep up the good work and watch out for ghosts this weekend. Cheers. Mike Norris From Daniel.Karrenberg at ripe.net Sat Oct 31 01:07:32 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 31 Oct 1998 01:07:32 +0100 Subject: Events of Tuesday, 27 October 1998. In-Reply-To: Your message of Fri, 30 Oct 1998 18:20:02 +0100. <199810301720.SAA00160@vader.runit.sintef.no> References: <199810301720.SAA00160@vader.runit.sintef.no> Message-ID: <199810310007.BAA13392@kantoor.ripe.net> Harvard , thank you for your support. It is indeed not straightforward to roll back specific changes in a database that receives thousands of upates each day which are not independent of each other. One thing we have leared from this is that it may be a good idea not to re-use handles before some time period has expired in order to facilitate tis process. However there are other interdependencies as well and it will be impossible to design a system to roll back any amount of changes consistently and repecting constraints such as authorisation. I further would like to point out to everyone that we do provide authorisation and authentication methods *for more than five years* already. Those who used them properly weree not affected by this mistake at all! If you want to be safe, all you have to do is to use authorisation on your objects. See ripe-120 on how to do that. mLaswly, and maybe unnecessarily, I'd like to stress that we indeed have backup procedures in place which are designed to cope with failures under our responsibility, such as machine or storage media problems. If you have any further questions, please do not hesitate to contact us. Kind regards Daniel Karrenberg RIPE NCC Manager > Havard.Eidnes at runit.sintef.no writes: > > It is important to understand that the data in the RIPE database is > maintained by the users of the database, and not by the RIPE NCC > itself. > > I suspect that the problem is that a backup cannot easily be used to > restore the current "desired" state (minus the unfortunate update). > The reason is that old NIC handles may have been recycled, i.e. > reassigned to another object, and that object can subsequently have > been referenced by an explicit use of that recycled NIC handle in an > update. Sure, the subsequent updates could perhaps be doctored to > remedy this, but that is perhaps not easily or quickly done, and would > also mean "intervention in the data maintenance" by the RIPE NCC. > > I would thus tend to turn the argument above on its head and say that > we collectively, the maintainers of the data in the RIPE database, > have made inadequate use of the already available methods for > protecting the data we maintain there from unauthorized updates or > removals. From zeidler at xlink.net Fri Oct 30 16:48:47 1998 From: zeidler at xlink.net (Petra Zeidler) Date: Fri, 30 Oct 1998 16:48:47 +0100 Subject: Events of Tuesday, 27 October 1998. In-Reply-To: <3639B57F.5B4F52EC@noc.ntua.gr>; from Dimitrios Kalogeras on Fri, Oct 30, 1998 at 02:47:59PM +0200 References: <199810291259.NAA03658@office.ripe.net> <3639B57F.5B4F52EC@noc.ntua.gr> Message-ID: <19981030164847.A15292@xlink.net> Dear Mr. Kalogeras, Thus wrote Dimitrios Kalogeras (D.Kalogeras at noc.ntua.gr): [...] > > Mistakes are not improbable, however I can not condone your inadequate > backup procedures. Its totally out of imagination that you may have rouinned > the RIPE database. You have to keep yourself more dedicated to your work. > You forget that the RIPE DB is very much a moving target. There were backups, we (Xlink) even have a copy due to running a RIPE mirror, but what does that help? it took some time until the mass deletions were detected, and there were ample changes in the meantime. Re-enacting these would have been almost as much headache and also prone to oversights as repairing what was done and not interfering with standard operations. The only thing that /would/ have helped would have been a switch from take-first-free-handle to take-highest-existing+1, but that is not a trivial change either. kind regards, Petra Zeidler -- [X] Xlink Internet Service GmbH | | i.A. Petra Zeidler, Neukundenanschluss | zeidler at xlink.net | | Vincenz-Prie_nitz-Stra_e 3 [X] D-76131 Karlsruhe | Tel: 0721/9652-220 [X] Fax: 0721/9652-209 | | Geschdftsf|hrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. | Auftrdge erledigen wir zu unseren Allgemeinen Geschdftsbedingungen. ---------------------------------------------------------------------[ ] From zeidler at xlink.net Fri Oct 30 16:54:50 1998 From: zeidler at xlink.net (Petra Zeidler) Date: Fri, 30 Oct 1998 16:54:50 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: <01BE040C.A9199FA0@pc19.heanet.ie>; from Mike Norris on Fri, Oct 30, 1998 at 01:53:22PM -0000 References: <01BE040C.A9199FA0@pc19.heanet.ie> Message-ID: <19981030165450.B15292@xlink.net> Thus wrote Mike Norris (mike.norris at heanet.ie): > > well we should collect money for Mr. McBryan to spend him a > > two-week-last-minute-trip to ... lets say mallorca without > > internet access, then the community has time to fix all the > > mistakes he made :-))) > > Maybe he's signed up for one of the RIPE Local IR > training courses; wouldn't that be a lot better? shoot him to the moon? :-3 Would suit my feelings better .. anyone can err, but then messing with my repair work by faking our headers is way off bounds. This whole little escapade cost Xlink about 3 man-days work, and we're not finished mopping up yet. kind regards, Petra Zeidler -- [X] Xlink Internet Service GmbH | | i.A. Petra Zeidler, Neukundenanschluss | zeidler at xlink.net | | Vincenz-Prie_nitz-Stra_e 3 [X] D-76131 Karlsruhe | Tel: 0721/9652-220 [X] Fax: 0721/9652-209 | | Geschdftsf|hrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. | Auftrdge erledigen wir zu unseren Allgemeinen Geschdftsbedingungen. ---------------------------------------------------------------------[ ]