- lir-wg - mailman.ripe.net

Re: Afrinic Proposal
by Mike Norris 28 Dec '98

28 Dec '98

Paula many thanks for that good news. I'm sure RIPE and the NCC wish Afrinic every success and will give every possible help and advice to the formation process. Can we invite some of the people concerned to RIPE 32? Perhaps Rob could feature this in the agenda? Regards. Mike ---------- > From: Paula Caslav <paula(a)ripe.net> > To: local-ir(a)ripe.net; lir-wg(a)ripe.net > Subject: FYI: Afrinic Proposal > Date: 28 December 1998 14:20 > > > Dear Registries, > > After a meeting in Cotonou Benin, there is a proposal to create a new > Regional Registry for the continent of Africa. If you are interested > in reading the proposal, please look at the web site: > > www.afrinic.org > > and if you wish to participate in the discussions, please subscribe to > the afrinic-discuss(a)afrinic.org mailing list. (Subscribe by sending a > "subscribe" request to afrinic-discuss-request(a)afrinic.org.) > > Kind regards, > > Paula Caslav > RIPE NCC

1 0

Maintainer creation policy
by Joao Luis Silva Damas 07 Dec '98

07 Dec '98

Dear all, the RIPE NCC is considering relaxing the requirements for obtaining a maintainer. This has certain consequences that we would like people to consider and then put forward comments either supporting or rejecting this proposal. We propose the following new policy: - The RIPE NCC will create maintainers for all users whose person/role object is mentioned in any object in the RIPE database except if it is only mentioned in other person or role objects. - If the person/role is not mentioned in any other object, the maintainer will not be created. This should allow all users to protect their data but prevent the database from becoming some sort of "phone book". Some consequences of this would be: - The RIPE NCC would no longer do any identity checks on the requester (compliance with the policy will be, of course, checked). - Users may wish to protect objects that already have (soft) maitainers. A clear example would be a user protecting a domain object with a soft maintainer (eg: auth: NONE) with their own maintainer (which may have PGP on it). - Users with inetnum,route,etc objects are strongly encouraged to protect their objects with a strong maintainer to prevent accidental or malicious "protection" by other users. Note: Any object can have more than one maintainer. To modify/delete an object only one maintainer authentication needs to be matched. In order to add a maintainer to an object that already has one (or more) the user will need cooperation from one of the previous maintainers. Waiting for your comments, Joao Damas RIPE DB Group RIPE NCC

1 0

Performance of auto-dbm, Thu, 27 Nov 1998
by RIPE Database Administration 26 Nov '98

26 Nov '98

Dear Colleagues, We had some performance problems this morning and we had to temporarily stop updates in order to restore performance to its usual level. Updates were restarted as soon as we had finished working on this problem and the queue of updates was quickly processed. We appreciate your patience and we assure you that your updates were not lost. During this time, they were stored; there is no need to send them again. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

RIPE Database incident of 27th October
by Joao Luis Silva Damas 16 Nov '98

16 Nov '98

Dear all, the RIPE NCC Database group has been reviewing the events regarding the RIPE Database incident of 27 October. We have produced a report that can be found at http://www.ripe.net/db/incident.html All data sent to the database, related to this incident, is accessible through this URL. If you have any questions regarding this incident or otherwise related to the RIPE Database we will be glad to answer them. Best regards, Joao Damas RIPE DB Group RIPE NCC

1 0

Réf. : From Address Forged
by GALL Thierry TPC-SRD 06 Nov '98

06 Nov '98

Actually, the address was "forged" but only partially by Trevor, and Hostmaster was in copy of the mail, More over it was an attempt to repair the original error and to avoid the work necessary to rebuild all the links that have destroyed. Please apologize again for all these perturbations. Thierry GALL

6 7

Re: Massive changed in the Ripe Database..
by Petra Zeidler 05 Nov '98

05 Nov '98

Thus wrote Mike Norris (mike.norris(a)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(a)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. ---------------------------------------------------------------------[ ]

6 5

Re: Events of Tuesday, 27 October 1998.
by Daniel Karrenberg 03 Nov '98

03 Nov '98

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(a)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.

4 6

Events of Tuesday, 27 October 1998
by RIPE Database Administration 03 Nov '98

03 Nov '98

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 <nic-handle>" 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 <ripe-dbm(a)ripe.net>. Regards, The RIPE NCC Database Group.

2 2

RE: Database performance - an update.
by Mike Norris 30 Oct '98

30 Oct '98

> 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

1 0

Database performance - an update.
by RIPE Database Administration 30 Oct '98

30 Oct '98

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.

1 0