December 1998 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 16 May '18

16 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Re: updating a person object
by Joao Luis Silva Damas 29 Dec '98

29 Dec '98

Hi, Object reordering only takes place when the mail contains AUTO nic-handle creation. This is because references to the new object need to be resolved (by creating the nic handle) before the other objects can be processed. If you don't request AUTO nic handle creation, there is no reordering. Therefore, sending a mail containing a delete followed by a creation should be safe (the only possibility for it to go wrong would be if between the processing of the deletion and the creation an update taking place at the same time grabs the old nic handle. This is extremely unlikely and impossible to do on purpose since it depends on machine load, etc). Once again, if the object in the deletion is referred to by other DB objects the deletion will fail. But in this case, so would the creation immediately after it, since the nic handle would be in use. regards, Joao "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> writes: * >you're right - it's possible this way if the person object isn't * >related to any other object in the database. FMPOV it should be * >strongly recommended that deletion and re-creation would be done * >by just _one_ email to 'auto-dbm@...' because of the sequential * >processing. This avoids the re-use of the NIC-handle by the * >'AUTO-1' mechanism in between two separate mails. * * This is also my "gut-feeling". * * However doing so in many cases generates "funny" error messages * due to object re-ordering within a single update message, and it * might interfere with what you had in mind. * * I think this is still not resolved completely. * Maybe the DB SW technicians could clarify this issue? * * Wilfried. *

7 9

Re: Maintainer creation policy
by Havard.Eidnes＠runit.sintef.no 29 Dec '98

29 Dec '98

> 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". Maybe I'm getting out of touch with things, but frankly, I do not see how this solves the "phone book" problem or any other problem for that matter. Instead I see it creating a few new problems... I also do not really understand from the description above what exactly is going to happen. Some interpretations: o All "person" objects referenced from other objects (except "role" objects) will result in the creation of a new maintainer object for that user, and the user's maintainer will be added as a mnt-by: attribute of the objects where the person was referenced earlier. If the total size of the database is a problem (and I think it is), this will not help one little bit, as this will add new objects corresponding to a *large* percentage of the person objects in the database. Furthermore, it is not necessarily true that users referenced as admin-c, tech-c or zone-c *own* the information registered, although there may be consensus that this is so for the Internet registry part of the RIPE database. For the other "subparts" of the database there may be policy implications of updating the information, a prime example could be information from the domain registry side. o The RIPE NCC will add mnt-by: attributes on all person objects referenced from other objects (except "role" objects). Which maintainer is to be used is not exactly stellar clear. I consider this to be an unlikely interpretation, although I must say that the statements above are sufficiently unclear that I do not clearly understand what is going to happen. I do not understand at all how this will reduce the "phone book" problem of the RIPE database, as this will not prevent the creation of "free- standing" objects in the RIPE database (?). I furthre presume that the "phone book" problem is exactly this -- free-standing, un-referenced person objects? Another alternative to the "phone book" problem could be that a large part of the RIPE database is indeed objects resulting from it making double duty as a domain registry information repository, although I still seem to remember statements by the RIPE NCC to the effect that this is not regarded as a problem. Why not just permit maintainer object creation by anyone satisfying the above requirements ("reference exists"), but not create the maintainer objects themselves or the mnt-by: attributes? I cannot see that there have been any comments to this proposal, so am I the only one who does not understand what is going to happen, and what the rationale for it is? I do however think that the effective time between announcement and implementation is way too short -- with IETF and Christmas and New Year holdays in-between it comes down to 1-2 weeks only. Regards, - Håvard

2 1

Re: updating a person object
by Andreas Scher 28 Dec '98

28 Dec '98

Hi Joao, >If the old object is being referenced by other objects in the Database, the >deletion will not succeed because of integrity checks. In this situation you >may ask ripe-dbm(a)ripe.net to modify the object for you. You will need to >produce some sort of ID to make sure you are the person responsible for that >object. More info upon request. thanks for the answers (to all others too). There where references to two other objects in the database. So I will send my request to ripe-dbm(a)ripe.net. Kindly regards Andreas Scher ----------------------------------------------------------------- Andreas Scher scher(a)planet.de -----------------------------------------------------------------

1 0

updating a person object
by Andreas Scher 28 Dec '98

28 Dec '98

Hello, is it possible to change (correct) the name of a person object without changing the nic handle (delete and create new) ? Perhaps is it possible to delete the object and create a new one with the old nic handle (not AUTO-1). Is it possible and allowed ? Thanks in advance Andreas Scher PS: I hope my question points to the right group. Please let me know the right address if not. ----------------------------------------------------------------- Unternehmensgruppe PLANET - Hagenower Strasse 73 - 19061 Schwerin -----------------------------------------------------------------

1 0

Re: Subnetting legacy Class B networks
by Wilfried Woeber, UniVie/ACOnet 16 Dec '98

16 Dec '98

Hi Randy! >for the record, verio also filters B on /16. we do so because that is what >the registries told us were allocation boundaries. if registries intend to >change these policies, it would be kind to warn and discuss. I think we should try keeping separate things separate. From my point of view, the information about the allocation boundaries as provided by the registries is one thing. Users (ISP customers), announcing subsets of address-space they got assigned somehow, maybe from a legacy class B block, is another thing. If they do so without checking the constraints of the routing system, on the technical side, or the contracts with their ISP(s), on the administrative side, then this is outside the responsibility of any IP-allocation- or Routing-Registry, I think. But I'm sure *you* are perfectly aware of that :-) Cheers, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

1 0

New RIPE database software release
by RIPE Database Administration 16 Dec '98

16 Dec '98

Dear Colleagues, we are happy to announce the new release of RIPE database software. It is running now on our production system and is available for download from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.2.tar.gz. Release notes are in: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-2.2 Most important new features are: - PGP authentication support - referral mechanism for domains - referential integrity checks - new syntax checks - bug fixes For more details please read the release notes. If you have any problems, questions, remarks, bug reports - please send mail to ripe-dbm(a)ripe.net. User documentation describing new release is being worked on and we hope to make it available soon. We would also like to inform you that we have migrated our database server to new hardware and OS platform - it is now running on Sun Enterprise E450 machine under Solaris 2.6 operating system. We hope you will experience performance improvements. Best regards, Roman Karpiuk RIPE NCC Database Group

5 4

Problems with <auto-dbm@ripe.net>
by RIPE Database Administration 11 Dec '98

11 Dec '98

Dear Colleagues, Mail for <auto-dbm(a)ripe.net> was not delivered since last night untill this morning. We have fixed the problem, and updates are now being processed again. No updates were lost; they were stored and you do need to send them again. However, there is a big queue of updates yet to be processed. We anticipate that the update queue will be at normal levels within 60 to 90 minutes. If you have any questions, please contact <ripe-dbm>. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Pedro Figueiredo ____________________________ RIPE Database Administration.

1 0

maintainer
by Hostmaster INTERNETX 10 Dec '98

10 Dec '98

Hi there, how we could get a maintainer-handle for protecting the handles of our customers? We have a class-c and are a ISP? If this is not enough, why? Best regards ________________________________ InternetX, Domain Service Center Hr. Bems, hostmaster(a)internetx.de Tel. +49 941 5839458 Fax. 5839460

2 1

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