- db-wg - mailman.ripe.net

RIPE Database Deletions Automated
by Daniel Karrenberg 03 Nov '92

03 Nov '92

How to delete a RIPE database object? To delete an object from the RIPE database, please send in a normal database update for the object to be deleted including a delete attribute as the last attribute listed. In order to delete person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk(a)ripe.net nic-hdl: DK58 changed: ripe-dbm(a)ripe.net 920826 source: RIPE one would send in person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk(a)ripe.net nic-hdl: DK58 changed: ripe-dbm(a)ripe.net 920826 source: RIPE delete: karrenberg(a)moneymakers.inc.com person has moved The value of the delete attribute is a comment which can be used to record reasons for the deletion. It will be archived and can be used by database administrators to verify delte requests. In order to safeguard against unwanted deletions the object will only be deleted if all attributes in the delete request match those in the database. Otherwise a diagnostic will be returned to the requestor and the deletion refused.

1 0

Re: Deletion Procedure
by Daniel Karrenberg 03 Nov '92

03 Nov '92

> Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> writes: > > How to delete a RIPE database object? > > The NCC proposes to implement this by an normal database update t > the object to be deleted including a delete attribute as the last > attribute listed. We have received zero comments on this, so it will be implemented. Daniel

1 0

Routing tags update procedure
by Marten Terpstra 03 Nov '92

03 Nov '92

All, please find below the NCC proposal for updating the routing tags as defined in Jean-Michel's paper. We would really like to get this procedure in place and working real fast now. Please comment. With no comments we assume you agree and will implement the procedure. -Marten --------------------- Introduction This document describes a procedure for updating the routing attributes to the RIPE database as defined in ripe-60. These routing tags are essential for routing of networks that are known in the RIPE database. Therefore updates of these attributes must be: - properly authorized - guarded against typing errors - efficient for both maintainers of the attributes and the maintainers of the whole database With the above in mind, the NCC proposes an update mechanism described below. The procedure For each of the routing privileges and boundary gateways tags, a list of all networks having this attribute is kept seperately from the database proper. These lists will be the *only* source of routing information used in the database. Normal database updates do *never* change these attributes. If an update include such an attribute and a discrepancy between the values in the update and those in the database is found, a diagnostic will be send to the originator of the update. The attributes as defined in the files are incorporated in the database at each normal update run. To ensure authorisation, we propose to maintain the lists on a the central NCC database server, where each of the guardians of a tag keeps track of his or her own list. The lists are maintained through individual logins for each of the guardians. The guardians can themselves decide in what manner they want to update their list. The NCC will offer interactive logins, ftp logins or any other means that might be found useful. File Format We propose to keep the file format as simple as possible. The name of the file should indicate the name of the attributes. This means that there cannot be two attribute with the same name. The format within the file we propose as the "inetnum:" entry for each of the networks, seperated by an empty line. If a guardian feels that he would want more fields to identify a network that will get his attribute, he is free to do so. An attribute will only be added to a network if all fields defined in the list match a network in the database. Advantages The update procedure as proposed above has the following advantages: - Authorisation of adding/deleting is guarenteed - No need for mailing back and forth of authorisation messages - Simple procedure for both database maintainers and guardians - Guardian keeps full control of his attribute - Could be implemented at the NCC without too much delay Pilot When the file format has been decided on, we propose the current participants in the pilot that make use of the attributes in the CERN area to start a pilot implementing this update procedure.

1 0

Re: Operational Contacts
by Duncan Rogerson 23 Oct '92

23 Oct '92

> POC for the network. But if <customer> has problems, and <service_provider> > wants to contact <customer>, the appropriate information can be stored > in the general contact information as well. Pls keep in mind, that this > contact information doesn't supersede the named [at]c's in the objects, > but will provider general contact point if the specific poeple are not What I read from this is that we have to distinguish between the service provider's NOC and the customers own NOC. So we should have operational contact details for both the end site and their service provider ? So, assuming we still go with the NOC object idea, that means a NOC object is created for the service provider, and one for the end site's own NOC. Each network the end site registers then has a pointer to their NOC, and also to their service provider's. Does this make sense, or am I falling asleep already seeing as the weekend is here ? :) I just don't think we gain anything having information spread all over the database, that could be maintained much more easily in one object. Dunc

1 0

Re: Operational Contacts
by Duncan Rogerson 23 Oct '92

23 Oct '92

> I am very reluctant to put an interim solution into place. If we're going to keep this sort of information in the database, I think it makes much more sense to have a NOC object, and then pointers to it from other objects. We don't gain much from an interim solution, other than the work involved in converting from the interim to the final situation. The effort involved in this would be better spent in doing it the right way from the start ... (IMHO, of course :)) Dunc

2 1

Re: Operational Contacts
by Arnold Nipper 23 Oct '92

23 Oct '92

>The following is my recollection of the Paris discussion about this: > >Andreas Schachtner had proposed to add an attribute to all non-person >objects specifying the mailbox of the operational contact points. >This had been mailed around on ripe-op before the Paris meeting. > >The proposal was discussed and a separate NOC object was proposed in >order to prevent duplication of the same data all over the database >and have a better mapping with reality. This was considered a too >heavyweight soloution for the time being. > We should soon introduce this new NOC object. If for example a service provider wants to give support to all his customer networks, all three attributes have to be added to a lot of networks. And then the phone number changes ... Don't waste time. >Consensus was to add separate optional attributes to all objects except >persons for e-mail, phone and fax of the operational contacts. If this >gets widely used then introduction of a NOC object and replacement of >these attributes by a pointer to it can be considered at a later stage. > >I propose the following naming: > > ATTR op op-phone > ATTR of op-fax > ATTR om op-mail > >All optional and multiple. > >Semantics: > > Generic contact information for operational purposes like a > common mailbox for the NOC or operations group and/or a > NOC hotline etc. > > Not intended for duplication of information that can be found > via the tc, ac, and zc persons! > >Comments? > >Daniel Arnold

4 3

New nsf.db in RIPE database format
by Stefan Fassbender +49 2241 14 3180 22 Oct '92

22 Oct '92

Hi, what about keeping the infos out of nis.nsf.net: nsfnet/announced.networks/country.now nis.nsf.net: nsfnet/announced.networks/country3.now somewhere on ftp.ripe.net. Those files provide the most useful information about NSFNET networks (at least for my administrative needs), ie they show the countries and the NSFNET announcements and they are up-to-date. What about converting them into the RIPE database format with the tags *in: *na: *cy: *ni: *ch: *so: and storing them as: ftp.ripe.net: ripe/dbase/nsf-t1.db ftp.ripe.net: ripe/dbase/nsf-t3.db or better to merge them into one database called: ftp.ripe.net: ripe/dbase/nsf.db with such entries: *in: 132.165.0.0 *na: CEA-SIEGE *cy: FR *n1: 1=590 14=750 15=756 20=1800 *n3: 1=1800 *ch: 910503 Merit *so: NSF This (small) database might replace the usually out-of-date nsfnets.db. (We could provide a gawk-script for the conversion) Any comments? -stefan-

2 1

Operational Contacts
by Daniel Karrenberg 21 Oct '92

21 Oct '92

The following is my recollection of the Paris discussion about this: Andreas Schachtner had proposed to add an attribute to all non-person objects specifying the mailbox of the operational contact points. This had been mailed around on ripe-op before the Paris meeting. The proposal was discussed and a separate NOC object was proposed in order to prevent duplication of the same data all over the database and have a better mapping with reality. This was considered a too heavyweight soloution for the time being. Consensus was to add separate optional attributes to all objects except persons for e-mail, phone and fax of the operational contacts. If this gets widely used then introduction of a NOC object and replacement of these attributes by a pointer to it can be considered at a later stage. I propose the following naming: ATTR op op-phone ATTR of op-fax ATTR om op-mail All optional and multiple. Semantics: Generic contact information for operational purposes like a common mailbox for the NOC or operations group and/or a NOC hotline etc. Not intended for duplication of information that can be found via the tc, ac, and zc persons! Comments? Daniel

1 0

Deletion Procedure
by Daniel Karrenberg 21 Oct '92

21 Oct '92

To balance the formalism stuff with something technical :-). I think this was consensus in Paris. Please comment. How to delete a RIPE database object? The NCC proposes to implement this by an normal database update t the object to be deleted including a delete attribute as the last attribute listed. In order to delete person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk(a)ripe.net nic-hdl: DK58 changed: ripe-dbm(a)ripe.net 920826 source: RIPE one would send in person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: dfk(a)ripe.net nic-hdl: DK58 changed: ripe-dbm(a)ripe.net 920826 source: RIPE delete: karrenberg(a)moneymakers.inc.com person has moved The value of the delete attribute is a commentary which can be used to record reasons for the deletion which will be archived and can be used by database administrators to verify delte requests. In order to safeguard against unwanted deletions the object will only be deleted if all attributes in the delete request match those in the database. Otherwise a diagnostic will be returned to the requestor and the deletion refused.

1 0

Copyright / Copyleft
by Daniel Karrenberg 21 Oct '92

21 Oct '92

Welcome to the db-wg list. Lets start with something formalistic. One open point at the Paris meeting was a copyright statement to the DB and a position about database ownership. Due to some acute concerns about actual junk mail abuse we need a warning message. The NCC together with the RIPE and the DB WG chairmen have drafted the following warning: # Restricted rights. # # Except for agreed Internet operational purposes, no part of this publication # may be reproduced, stored in a retrieval system, or transmitted, in any form # or by any means, electronic, mechanical, recording, or otherwise, without # prior permission of RIPE. # # Any use of this material to target advertising or similar activities are # expressedly forbidden and will be prosecuted. RIPE requests to be notified # of any such activities or suspicions thereof. This text will be prepended to all copies of the full database and in the Interactive information server access to the DB. Including it in the whois output would have us alterately roasted by flames and deafened by roaring laughter. The purpose of this is to tell people "you should not abuse the data, especially not for mailings" and to be able to tell them "you have been warned" when they actually do. Note that this consciously leaves open: - the ownership issue of the database - the concrete specification of "agreed Internet operational purposes" which would fill pages and pages - if and in what way action will be taken should abuse happen, the prosecution threat is in there just to make clear we really mean it in case of advertising I do not think it is worth our while to spend much effort on discussing the particular wording etc. pp. So I ask you to comment to me privately and I will summarise and propose a new wording if this should be necessary which I hope will not be the case. NB: RIPE still has to take a position on the ownership issue. Daniel

1 0