- db-wg - mailman.ripe.net

Announcement - Database Consistency and Statistics Project
by Can Bican 14 Jan '02

14 Jan '02

Dear Colleagues, [Apologies for multiple messages]. The new version of database consistency project, along with whois server usage statistics have been released on the RIPE NCC's web pages, with the following url: http://www.ripe.net/db/dbconstat/ The goal of this project is to find the objects with consistencies not enforced by the database, and provide reports and statistics to help users correct them. It also aims at checking for the necessary protection of objects and tracing the query and update statistics of the RIPE whois server to analyze the current trends of using the database. The goals of the consistency project do not include, for example, reality checks for inetnum objects, but it addresses only internal inconsistencies in the database, such as invalid references. Here are the types of inconsistencies which are addressed in this project: * Inetnum object related: * Inetnum objects without status attribute, * Assigned inetnum objects without allocations, * Overlapping inetnum objects, * Inetnum objects with suspicious boundaries to form a network, * Assigned inetnum objects from assignments, * Inetnum objects with wrong PA or PI status, * Wrongly allocated inetnum objects. * Person object related: * Person objects with multiple identical copies, * Person objects which do not have any references to them, * Person objects not having a valid nic-handle, * Objects which have references to invalid nic-handles. * Maintainer object related: * Maintainer objects which do not have any references to them. * Protection related: * Weak authentications schemes for maintainers. * Inetnum objects with no mnt-lower attribute. Reports about individual inconsistencies are sent only to the maintainers of objects. If you'd like to receive the report for your inconsistencies, send an e-mail to auto-dbcon(a)ripe.net containing the maintainer name in its body, and the appropriate authentication. * If the authentication of your maintainer is MAIL-FROM, mail should be sent from the appropriate e-mail address, and should contain the following in its body: mntner: <maintainer_name> * If the authentication of your maintainer is CRYPT-PW, mail should contain the following lines in its body: mntner: <maintainer_name> password: <password> * If the authentication of your maintainer is PGPKEY, mail should contain the following line and should be signed with the appropriate key: mntner: <maintainer_name> If you supply an existing maintainer and the proper authentication, the report of the inconsistencies related to the maintainer will be mailed back to you. For questions, comments and suggestions, please contact ripe-dbm(a)ripe.net. -- Can Bican RIPE NCC

1 0

Some RIPE Database updates were processed twice
by Andrei Robachevsky 14 Jan '02

14 Jan '02

Dear Colleagues, Due to misconfiguration of our main whois server some 300 updates were not processed correctly. We needed to rollback the database and process them again. Those affected may receive acknowledgement and notifications from the RIPE Database twice. In such case please ignore the first message. The service now is back to normal. We are very sorry for the inconvenience. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 3

draft agenda (v1), for DB-WG meeting, RIPE 41, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 13 Jan '02

13 Jan '02

Dear WG list members, attached please find the 1st (initial) draft: Proposed Agenda for the DB-WG Meeting at RIPE #41 in Amsterdam, NL. Please expect some minor changes/adjustments/re-sequencing closer to the meeting date. Looking forward to see many of you in Amsterdam a few days from now, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-41, Jan. 14-18 2002, Amsterdam, NL 1. Draft Thursday, Jan 17th, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . volunteering a scribe . circulate list of participants . agenda bashing . status of minutes B. Actions Items . status of actions C. DB update (RIPE NCC, Andrei R.) 10 min . operations report D. DB software developments (RIPE NCC, N.N.) 30 min . bug fixes, re-writes, platform compatibility . meta-data proposal E. DB consistency and Statistics project (RIPE NCC, N.N.) 15 min F. IRT object implementation (RIPE NCC, N.N.) 15 min . implementation report, last-minute adjustments . how to use and promote the new features? G. Universal Whois Project (Andrew Newton, VeriSign App. Res.) 30 min . Needs of addressing information as it relates to domains in whois. . Overview of two technical solutions. . Unification of the addressing and domain databases into a more coherent "strategy". H. Modification of changed: attribute (tenative) I. "organisation:" Object re-visited (tentative) Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 13-JAN-2002 15:03:34 _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Routing Registry BOF at Miami NANOG (Feb 11)
by Larry J. Blunk 11 Jan '02

11 Jan '02

Merit will be hosting a Routing Registry BOF at the next NANOG meeting in Miami on Feb 11. Details on the meeting can be found at http://www.nanog.org/mtg-0202/. We also welcome any presentation proposals from interested parties. Regards, Larry J. Blunk Lead Engineer - Merit RADB project

1 0

IRT object
by Andrei Robachevsky 11 Jan '02

11 Jan '02

Dear Colleagues, The irt object has been implemented and we put the new software on our test whois server (please see http://www.ripe.net/ripencc/pub-services/db/testdb.html). We also took liberty to make some modifications to the original proposal (http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00036.html). Namely: - an "irt-nfy:" attribute is now optional/multiple/inevrse key in the irt object. It specifies an e-mail address used to send notifications whenever a reference to the object is added or removed. We thought it would be very useful from security prospective. - a name of an irt object should start with "IRT-" prefix reserved for this type of object. This will eliminate possible confusion, such as mixing up with mntner. We have created some object to play with: irt: IRT-TEST inetnum: 172.18.0.0 - 172.25.255.255 So you may try: $ whois -h test-whois IRT-TEST $ whois -h test-whois -i mnt-irt IRT-TEST $ whois -h test-whois -i irt-nfy bitbucket(a)ripe.net $ whois -h test-whois 172.18.10.1 $ whois -h test-whois -c 172.18.10.1 The irt objects are not created automatically, but are forwarded to RIPE Database Administration (ripe-dbm(a)ripe.net). But this restriction does not apply to the TEST database, so you may try to create one yourself. Have a nice weekend, Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Status of IRT object
by Gabriella Paolini 07 Jan '02

07 Jan '02

Dear all, which is the status of IRT object? Is the trial implementation available? This example shows again the need for a specific object. If someone uses whois information from cyberabuse.org, as many times people does, that information is wrong, because ciberabuse guys used Admin-c email without considering all other informations in inetnum object and in role object. Thanks and regards, Gabriella Paolini INFN-GARR [ Informations about 193.204.17.211 ] IP range : 193.204.16.0 - 193.204.23.255 Network name : UNIBAS-NET AS number : AS137 Infos : Universita' Degli Studi Di Basilicata Infos : Centro Interfacolta' Servizi Informatici E Telematici - Cisit Phone number : +39 06 49914352 Country : IT Abuse contact : enzo.valente(a)infn.it Source : RIPE right information are inetnum: 193.204.16.0 - 193.204.23.255 netname: UNIBAS-NET descr: Universita' degli Studi di Basilicata descr: Centro Interfacolta' Servizi Informatici e Telematici - CISIT country: IT admin-c: EV182-RIPE tech-c: GL965-RIPE tech-c: GM976-RIPE ... remarks: To notify abuse mailto: cert(a)garr.it remarks: Multiple lan of university departments remarks: GARR - Italian academic and research network mnt-by: GARR-LIR ... role: GARR LIR ... trouble: To notify abuse mailto: cert(a)garr.it trouble: Information at http://www.lir.garr.it/ ... person: Enzo Valente address: INFN - Dipartimento di Fisica address: Universita' La Sapienza address: Piazzale Aldo Moro,2 address: I-00185 Roma address: Italy phone: +39 06 49914352 fax-no: +39 06 4957697 e-mail: Enzo.Valente(a)infn.it ...

4 3

RIPE robot response
by Antonia López 04 Jan '02

04 Jan '02

Dear all, Every time I update or add an object to the RIPE database, the robot give back an e-mail like that (although I send my e-mail with non formatted text). <<FAILED: >> The action is made, then why this e-mail?? Thanks. Antonia Lopez Serrano

3 2

RE: RIPE robot response
by Boyan Krosnov 04 Jan '02

04 Jan '02

You sent a mime message with two parts part one is text/html the other is text/plain. The robot cannot parse html so it sees it as plain text and tries to process it. It then fails, as could be expected. Then it processes the text/plain part of your message, which succeedes. Never send html formated messages to the robot or it will spit errors at you. If you are using a MS exchange server you can make it send messages to all addresses @ripe.net in plain text format. Drop me a private e-mail for the exact configuration. Regards, CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 -----Original Message----- From: Antonia Lopez [mailto:antonia.lopez@abrared.com] Sent: Friday, January 04, 2002 6:18 PM To: 'db-wg(a)ripe.net' Subject: RIPE robot response Dear all, Every time I update or add an object to the RIPE database, the robot give back an e-mail like that (although I send my e-mail with non formatted text). <<FAILED: >> The action is made, then why this e-mail?? Thanks. Antonia Lopez Serrano

1 0

Re: RIPE robot response
by Janos Zsako 04 Jan '02

04 Jan '02

> From owner-db-wg(a)ripe.net Fri Jan 4 16:35:03 2002 > From: =?iso-8859-1?Q?Antonia_L=F3pez?= <antonia.lopez(a)abrared.com> Dear Antonia, This is probably because your mailer is cofigured to send the message BOTH in plaintext AND HTML (see below). The plaintext is interpreted correctly by the robot, while the HTML text is flaged with errors. Also, please note that you should change your password, as you forwarded it in cleartext to the list... :(( Best regards, Janos > Content-Type: multipart/alternative; > Content-Type: text/plain; > Dear all, > > Every time I update or add an object to the RIPE database, the robot give > back an e-mail like that (although I send my e-mail with non formatted > text). > > <<FAILED: >> > > The action is made, then why this e-mail?? > Content-Type: text/html; > Dear all, > > > Every time I update or add an object = > to the RIPE database, the robot give back an e-mail like that (although = > I send my e-mail with non formatted text).

1 0

RE: route object check-up
by Wilfried Woeber, UniVie/ACOnet 28 Dec '01

28 Dec '01

>while updating our database we've noticed some >inconsistency in ripe-db route object: 80.82.178.0/20 >so does anybody know why net and prefix combination for >route object could be invalid ? When the starting address is not properly aligned on a power of 2 for the block-size. The hint you are receiving, as attached below, is an indication for this, i.e. - 80.82.178.0 is only properly aligned for 2 consecutive Class Cs, 80.82.178.0 and 80.82.179.0), - whereas for a /20 (16 consecutive Class Cs) the proper alignment would be 80.82.176.0 Btw, the same issue might eventually arise when someone tries to do an aggregated announcement on the routing layer for this block. Possible solutions: - move the address block to the proper alignment - partiton the block into a set of smaller, consecutive, aligned chunks - try to register the address as a range (although this might trigger the same error message, depending on implementation of checks...) I guess the older versions of the software were less picky than the new implementation is... >With respect, >--- >RIPN Registry center >----- > >-------------------------------------------------------------------- > >Update [FAILED] > >dbupdate: >80.82.178.0/20 is an invalid net and prefix combination:- >length 20 (mask 255.255.240.0) is outside the range of 80.82.178.0 >Possible values with these combinates are: >based on length 80.82.176.0/20 >based on prefix 80.82.178.0/23 Regards, _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

route object check-up
by Oleg N. Bondarev 28 Dec '01

28 Dec '01

Dear all, while updating our database we've noticed some inconsistency in ripe-db route object: 80.82.178.0/20 so does anybody know why net and prefix combination for route object could be invalid ? With respect, --- RIPN Registry center ----- -------------------------------------------------------------------- Update [FAILED] dbupdate: 80.82.178.0/20 is an invalid net and prefix combination:- length 20 (mask 255.255.240.0) is outside the range of 80.82.178.0 Possible values with these combinates are: based on length 80.82.176.0/20 based on prefix 80.82.178.0/23

1 0

Creating route-objects
by Ionut Murgoci 10 Dec '01

10 Dec '01

Hi, Could somebody tell me how can i create a route-object for an assigned IP class in RPSL format? Thx, Ionut.

2 1

RIPE Database Updates Off-line 2001-12-08
by RIPE Database Administration 09 Dec '01

09 Dec '01

RIPE Database Users: The RIPE database will be operating in query-only mode from 10:00 to 17:00 tommorrow, Saturday, 8 December 2001. Any updates that arrive during this time will be queued, and processed when the database returns to normal operation. All queries will be answered normally by our secondary server. We are adding a new disk to the server due to warnings reported by our SCSI controller. No data has been lost or damaged; this is simply a precaution. Apologies for any inconveniences. Sincerely, -- Shane Kerr RIPE Database Administration

2 1

mnt-routes in allocation objects
by Sabrina Waschke 05 Dec '01

05 Dec '01

Dear all, This is to inform you that the RIPE NCC Registration Services will update all inetnum objects representing allocations made by the RIPE NCC to Local IRs (status: ALLOCATED PA") adding a mnt-routes attribute. We will use the maintainer specified in the mnt-lower attribute of the particular inetnum object. We will only add a mnt-routes attribute to allocation objects that have exactly one mnt-lower attribute (*). The updates will start on Monday, 10th December 2001. Until the introduction of RPSL there was no mnt-routes attribute. Adding a mnt-routes attribute to the inetnum object representing your allocation will enable you to create route objects matching the exact size of your allocation object. (You might have to pass other authorisations.) For a graphical overview of "Route Object Creation - Getting Authorisation from IP Space" please see: <http://www.ripe.net/ripencc/faq/database/route-creation-IP-space-c heck.html>. For more information about route object please read: <http://www.ripe.net/ripe/docs/databaseref-manual.html#1.2.15> and <http://www.ripe.net/ripe/docs/databaseref-manual.html#3.6.5>. (*) In general: If you want to update an object maintained by the RIPE-NCC-HM-MNT please send a message to <lir-help(a)ripe.net> including your registry ID and the revised object. Please note that we only accept these requests from official LIR contacts who are registered in our RIPE NCC internal registry files. If you have any further questions please do not hesitate to contact <lir-help(a)ripe.net> including your registry ID. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

1 0

Can anyone shed some light on this?
by Stephen Burley 05 Dec '01

05 Dec '01

route: 212.249.0.0/16 descr: UUNET CH origin: AS702 mnt-by: AS702-MNT password: ********* changed: jsc(a)ch.uu.net 20011204 source: RIPE I send the above object to the DB and get the following error: New FAILED: [route] 212.249.0.0/16 route: 212.249.0.0/16 descr: UUNET CH origin: AS702 mnt-by: AS702-MNT changed: stephenb(a)uk.uu.net 20011204 source: RIPE ***Error: Hierarchical authorisation failed, request forwarded to maintainer. Objects in RIPE-181 format are no longer accepted. Please see http://www.ripe.net/rpsl for more information. RIPE Database Maintenance Department Which is strange as the mainainer is us AS702-mnt. Any help on this matter whould be appreciated as this is not the only one. Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE

4 5

RE: Can anyone shed some light on this?
by Boyan Krosnov 05 Dec '01

05 Dec '01

http://www.ripe.net/ripe/docs/databaseref-manual.html 3.6.5 Protection of route object space The route object creation must satisfy several authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or, if no applicable route object is found, then an inetnum. Finally the creation must be authorised by the maintainer of the route object itself referenced by the "mnt-by:" attribute of the object. When checking for prefix authorisation, an exact route object prefix match is checked for first. If there is no exact match, then a longest prefix match that is less specific than the prefix is searched for. If the route prefix search fails, then a search is performed for an inetnum object that exactly matches the prefix or for the most specific inetnum object that is less specific than the route object submission. The aut-num object used for authentication checks is referenced by the "origin:" attribute of the route object. A route object must pass authorisation from both the referenced aut-num object and the route or inetnum object. Authorisation shall be tested using the maintainer(s) referenced in the "mnt-routes:" attribute(s) first. If that check fails, the "mnt-lower:" attributes are checked. If that check fails, the "mnt-by:" attributes are used for the authorisation check. ---------- aut-num: AS702 as-name: AS702 descr: UUNET - Commercial IP service provider in Europe .... mnt-routes: UUNETDK-MNT mnt-routes: AS1270-MNT mnt-routes: AS1849-MNT mnt-routes: AS1890-MNT mnt-routes: IWAY-NOC mnt-by: UUNET-MNT --------- I bet you didn't pass this authorization check. does this shed a light? :) BR, CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 > -----Original Message----- > From: Stephen Burley [mailto:stephenb@uk.uu.net] > Sent: Wednesday, December 05, 2001 12:30 PM > To: lir-wg(a)ripe.net > Cc: db-wg(a)ripe.net > Subject: Can anyone shed some light on this? > > > route: 212.249.0.0/16 > descr: UUNET CH > origin: AS702 > mnt-by: AS702-MNT > password: ********* > changed: jsc(a)ch.uu.net 20011204 > source: RIPE > > I send the above object to the DB and get the following error: > > New FAILED: [route] 212.249.0.0/16 > route: 212.249.0.0/16 > descr: UUNET CH > origin: AS702 > mnt-by: AS702-MNT > changed: stephenb(a)uk.uu.net 20011204 > source: RIPE > ***Error: Hierarchical authorisation failed, request forwarded to > maintainer. > > Objects in RIPE-181 format are no longer accepted. > Please see http://www.ripe.net/rpsl for more information. > > RIPE Database Maintenance Department > > Which is strange as the mainainer is us AS702-mnt. Any help > on this matter > whould be appreciated as this is not the only one. > > Regards > Stephen Burley > UUNET EMEA Hostmaster > SB855-RIPE > > > >

1 0

New Document available: RIPE-201
by RIPE NCC Document Announcement Service 04 Dec '01

04 Dec '01

<Apologies for duplicate mails> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-201 Title: Routing Registry Consistency Check Author: Joachim Schmitz, Engin Gunduz, Shane Kerr, Andrei Robachevsky, Joao Luis Silva Damas Date: 4 December 2001 Format: PS=33719 TXT=15425 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- "Routing Registry Consistency Check" describes a project to crosscheck European Internet routing against data registered in the RIPE Routing Registry. This project was proposed as a new activity by the RIPE Routing Working Group. The document gives an overview of the project, discusses the implementation, and mentions some points that have to be addressed in future design documents. This document is intended to solicit input from interested parties. 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-201.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-201.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-201 is available at the following URL: http://www.ripe.net/docs/rr-consistencycheck.html

1 0

Re: Object Metadata Proposal
by Janos Zsako 15 Nov '01

15 Nov '01

> From owner-db-wg(a)ripe.net Thu Nov 8 17:53:37 2001 > From: Andrei Robachevsky <andrei(a)ripe.net> Dear Andrei, I think both proposals (this one and the garbage collection) are very good and very useful. I just have a further suggestion and a question (I apologize if this has already been discussed). > Metadata Contents > ------------------ > Other meta-attributes may be added as needed. My suggestion would be to add a meta-attribute "creation-time:" which would store the date and time the object was created (as opposed to "update-time:", which only shows when it was last updated). This attribute would never change. The rationale behind having this attribute is that one would have a proof of the existence of the object in the database from (at least) creation-date (until at least query time). This may help for example auditing LIR assignments to the same end-user (which is limited to one AW worth in any 12 months). My question would be about the generation of the initial values (of update-time and ref-time) for the _existing_ objects. One aproach would be to use the "changed:" value for "update-time", and for "ref-time" the most recent "changed" value of the objects referencing the given object. The only problem is that we know "changed" is not (very) reliable. An other approach would be to use the time of the (initial) creation of the meta-attributes as initial value both for "update-time" and "ref-time". This is probably misleading. A better approach would probably be to leave these values empty, but this would not meet the current spec. The most exact approach would be to retrieve the exact values from the update logs, but this is probably too expensive. My question is which approach do you plan to take (one of the above or one I did not think about)? Thanks and regards, Janos

2 1

automatic DB cleanup proposal (v2)
by Andrei Robachevsky 08 Nov '01

08 Nov '01

Dear Colleagues, This is a slightly modified version of Ulf Kieber's proposal based now on metadata concept (please see "Object Metadata" proposal on the list next to this one). Your comments and suggestions are welcome. Thanks, Andrei Robachevsky RIPE NCC ----------------------------------------------------- Automatic DB Cleanup proposal ============================= Motivation ---------- In the light of data privacy issues raised by governmental organizations and in RIPE Database Working Group sessions during RIPE-39 and RIPE-40, as well as following the Great Dangling Person Objects Deletion after de.* ccTLD move-out it is necessary to implement an automized garbage collection procedure to remove personal data that is unreferenced for a certain amount of time. Proposed Change --------------- Four meta-attibutes "update-time:", "ref-time:", "ref-count:" and "expire-time:" should be maintained and used for this purpose (*). The values of these meta-attributes would be a modification timestamp, reference counter modification timestamp, reference counter and object expiration time (if applicable) respectively. The reference counter would contain the number of objects still refering to this object, and thus be similar to the link counter of an inode in a UNIX file system. The modification timestamp would be updated whenever the object is updated. The reference counter modification timestamp would be updated whenever link counter changes. The analogy in the UNIX file system would be sort of mtime and ctime. The expiration time will be updated for person and role object only. For other object types it will be emplty meaning "not set". The expiration time will be updated whenever link counter reaches zero or changes from zero to a positive value. In the first case the expiration time will be calculated by adding the expiration period to the time when this event occured. In the second case the expiration time will be unset (empty value). A garbage collection process running on a periodic basis should then generate a deletion update (transaction) overriding authorization checks (**) for all person and role objects that reached their expiration time. The expiration period is to be discussed and agreed upon in the community. The initial proposal is 90 days. Explicit generation of an update (transaction) is needed for tracking/debugging purposes. (*) Please see the "Object Metadata" proposal. (**) Overriding authorization allows deletion of a maintained object to be performed. Respective maintainers will be notified. Overriding authorization still doesn't allow deletion of a referenced object.

1 0

Object Metadata Proposal
by Andrei Robachevsky 08 Nov '01

08 Nov '01

Dear Colleagues, Please review the proposal below. This proposal is supposed to provide means for reliable timestamping, and also support garbage collection procedure (please see "Automatic DB cleanup proposal" following this one). But of course the functionality can be expanded when needed. Your comments are welcome as always, Best regards, Andrei Robachevsky RIPE NCC ------------------------------------------------------------- Object metadata proposal ======================== Motivation ---------- Several proposals already exist that require reliable status information about an object in the database, such as last update time, number of references, etc. These are requests for reliable timestamping and automatic cleanup procedure. In order to be reliable this information should be automatically generated by the database software and be outside users' control. Storing this information as part of the object data was generally considered not a good idea since this requires modifications to the object not solicited by the user, and breaks some basic principles of the RIPE Database. But in fact these attributes/facilities do not represent an object, but rather status information about the object. Extending Ulf Kieber's analogy with the Unix FS, they are part of the inode, not the data blocks. Object metadata --------------- Status information, or object metadata, will be automatically generated by the database, but stored and accessed separately from the object itself. This will not affect any object template, preserve users' data and add flexibility to the RIPE Database. Metadata Contents ------------------ Metadata contents will be presented as metadata attribute-value pairs, or meta-attributes. The initial set of meta-attributes is required by the above mentioned proposals and will include: update-time: <YYYY-MM-DD> <HH:MM:SS> This meta-attribute will store the time when the update (object creation or subsequent updates) was processed by the database software (when modification was made to the Database). ref-count: <number> The number of references to this object from other objects in the RIPE Database. Zero means the object is not referenced. ref-time: <YYYY-MM-DD> <HH:MM:SS> Last time the "ref-count:" was updated. It is empty if ref-count has never been updated. expire-time: <YYYY-MM-DD> <HH:MM:SS> This meta-attribute displays the time after which the object will be automatically deleted from the database overriding authorisation checks. Empty value of the meta-attribute means "not set". Please see "Automatic DB cleanup" proposal for more information. Other meta-attributes may be added as needed. Metadata will not propagate through NRTM. It is up to a NRTM client to generate the metadata as updates are processed. Querying Metadata ------------------ Object metatdata may be accessed by using "-q meta" flag when interrogating the database. This flag is can be used together with other queries, except other "-q" flags. Metadata of all objects returned will be displayed. An object metadata will be displayed after the object with a blank like between them. It is displayed as meta-attributes preceded by a '%' sign. According to RIPE whois definition a line starting with '%' sign should be generally considered as a comment and should be parsed at client's own risk. For example: $ whois -q meta RC1234-RIPE ... person: Referenced Contact nic-hdl: RC1234-RIPE ... changed: refcon(a)somedom.dom 20011005 source: RIPE %metainfo: RC1234-RIPE %update-time: 2001-10-05 16:50:07 %ref-time: 2001-10-06 09:17:33 %expire-time: %ref-count: 3 Using Metadata -------------- The metadata may be consulted by humans or metadata-aware clients for different purposes. The database software may use metadata for its garbage collection routine, or other internal processes.

1 0

LIR-PARTITIONED - Final version
by Nurani Nimpuno 23 Oct '01

23 Oct '01

Dear all, Following the announcement 28 Sep 2001 on these lists, please find below the final details of the LIR-PARTITIONED PROPOSAL. This proposal will be implemented by the RIPE NCC in the coming period and presented at the RIPE 41 meeting in January 2002. Comments and suggestions made on this list have been incorporated in the proposal below. +-----------------+ | LIR-PARTITIONED | +-----------------+ Background ----------- This proposal (initially named "LIR-ALLOCATED") was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 Jan 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.ht…) The full final proposal (15 Jan 2001) by Aldridge can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.ht… At the RIPE 38 meeting,(22-26 Jan 2001), the RIPE NCC accepted the action to implement this proposal. Motivation (as expressed by James Aldridge) -------------------------------------------- "For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s)." Database Objects affected ------------------------- Only inetnum objects may have the "LIR-PARTITIONED" status value. Usage ----- The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of lower-level objects representing assignments within the address space specified by the inetnum object with the status "LIR-PARTITIONED PA" OR "LIR-PARTITIONED PI". Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules: - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file) - The value of "LIR-PARTITIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA" or "LIR-PARTITIONED PA". - The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI" or "LIR-PARTITIONED PI". Additional clarification ------------------------ This proposal addresses the added inetnum status value as proposed by James Aldridge. This is strictly a database feature, allowing LIRs to delegate maintenance within their allocations in the RIPE Database. The implementation of this proposal will not affect IP address allocation policy. This means that it will not affect the responsibility LIRs have for allocations and assignments held by them. Furthermore, it will not change the manner in which the RIPE NCC verifies allocation utilisation. There is an on-going policy discussion addressing this specific issue. Kind regards, Nurani Nimpuno *-----------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *-----------------------------------*

1 0

changed attribute proposal and not only
by Andrei Robachevsky 11 Oct '01

11 Oct '01

Dear Colleagues, Please find enclosed the proposal of modification of the changed attribute that was presented at the RIPE-40 meeting in Prague. However, another proposal (or rather idea) came up in light of recent discussions regarding timestamping and cleanup procedures in the RIPE Database. Let me present you this idea first. As was pointed by the two proposals there is a need to store and display status information about an object in the database, such as last update time, number of references, etc. At the same time in order to be reliable this information should be automatically generated by the database software and be outside users' control. Regarding "changed attribute" proposal people felt that this changes some of the basic principles of the RIPE Database. Recent Ulf's proposal makes things even worse since it requires that modification to an object may be caused by an update of another object. But in fact these attributes/facilities do not represent an object, but rather status information about the object. Extending Ulf's analogy with the Unix FS, they are part of the inode, not the data blocks. So status information (object metadata) may be stored and displayed separately from the object itself by, say, using a flag. Much like we display the contents using cat, but status using ls. And this information will be used for cleanup procedure, reliable timestamping, etc. This will not affect any object template, preserve users' data and add flexibility to the database. Something like this: $ whois -q meta RC1234-RIPE ... person: Referenced Contact nic-hdl: RC1234-RIPE ... changed: refcon(a)somedom.dom 20011005 source: RIPE %metainfo: RC1234-RIPE %update-time: 2001-10-05 16:50:07 %ref-time: 2001-10-06 09:17:33 %ref-count: 3 Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Reminder: RIPE-181 to RPSL Migration; Phase 3.
by Andrei Robachevsky 09 Oct '01

09 Oct '01

Dear Colleagues, [Apologies for multiple messages] On and from Monday, 15th October, 2001, the RIPE Database will no longer accept updates in RIPE-181 format. Mail robot at <auto-181(a)ripe.net> will be shutdown. The update path for the TEST database will also be changed. We plan to discontinue <test-181(a)ripe.net> service on 11th October, 2001. If you are still sending updates in RIPE-181 format, we advise you to switch to RPSL before 15th October. Please send your objects in RPSL format to <auto-dbm(a)ripe.net>. You may use ripe2rpsl utility to convert your RIPE-181 objects to RPSL format before sending them to the RIPE Database. The utility can be found at ftp://ftp.ripe.net/tools/ripe2rpsl-3.0.2.tar.gz. As part of this final step we will also make some cleanup of the ftp.ripe.net site. - The top directory for the RIPE Database software and flat object files is ftp://ftp.ripe.net/ripe/dbase. - "Short" versions of flat object files [*] will not be supported. [*]Version of a flat object file where attribute names are abbreviated to 2 letter code starting with '*'. The name of the object file also contains the object type in abbreviated form. For example ripe.db.in is the "short" version of the flat file for inetnum objects, while ripe.db.inetnum is the "long " version that is RPSL compliant. For more information please visit http://www.ripe.net/rpsl If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

automatic DB cleanup proposal
by kieber＠gatel.net 09 Oct '01

09 Oct '01

Re everybody, following up to some personal talks during the RIPE meeting I propose an automatic cleanup of orphaned person and role objects in the RIPE DB. Motivation ---------- In the light of data privacy issues raised by governmental organizations and in RIPE Database Working Group sessions during RIPE-39 and RIPE-40, as well as following the Great Dangling Person Objects Deletion after de.* ccTLD move-out I propose an automized garbage collection procedure to remove personal data that is unreferenced for a certain amount of time. Proposed Change --------------- An additional attibute ``expire:'' with two values should be added to all person and role objects. The values to this attribute would be a reference counter and a modification timestamp. The reference counter would contain the number of objects still refering to this object, and thus be analog to the link counter of an inode in a UNIX file system. The modification timestamp would be updated whenever the object is updated or the link counter changes. The analogy in the UNIX file system would be sort of a mix of ctime and mtime. Both values could be combined into a single value, but each value of it's own may be of interest to some people. Combining both values would leave the resulting value useless to human interpretation. A garbage collection process running on a periodic basis should then delete all objects with a reference counter of ``0'' and a modification timestamp of more than e.g. 8000000 seconds (approx. 3 month) ago. The expiration period is to be discussed and agreed upon in the community. An additional switch to the whois client should be added to make the otherwise invisible attribute visible, the DB should consequently not accept ``expire:'' attributes in updates. (The DB could certainly be made more forgiving about this, but since the move to v.3 tightened the syntax we should probably not weaken it again.) Database Objects affected ------------------------- An additional attribute would be added to all person and role objects. role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Example ------- inetnum: 10.0.0.0 - 10.0.255.255 netname: XMAS descr: Santa's Workshop Inc. Christmas Toys Manufacturing Facility Northern Nowhere country: NN admin-c: SC12-RIPE tech-c: SWT95-RIPE status: ASSIGNED PA mnt-by: SANTA-SECURITY-MNT changed: jbgood(a)antarctic.nn 19960412 source: RIPE role: Santa Workshop Team address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 3333 fax-no: +12 12 221 4444 e-mail: team(a)antarctic.nn admin-c: SC12-RIPE tech-c: SC12-RIPE tech-c: RD212-RIPE nic-hdl: SWT95-RIPE mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE person: Santa A. Claus address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 2121 +12 12 122 2211 ext. 1221 fax-no: +12 12 221 1212 e-mail: santa(a)antarctic.nn nic-hdl: SC12-RIPE mnt-by: SANTA-SECURITY-MNT expire: 3 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE person: Rudolf R N Reindeer address: Santa's Workshop Inc. Jingle Bell Lane 21 1224CH Christmastown Northern Nowhere phone: +12 12 122 1111 fax-no: +12 12 122 2222 nic-hdl: RD212-RIPE e-mail: rudolf(a)xmas.nn mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE -- Ulf Kieber email: kieber(a)gatel.net Senior Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net The Database Toothbrush Proposal

4 4

Re: automatic DB cleanup proposal
by Wilfried Woeber, UniVie/ACOnet 09 Oct '01

09 Oct '01

Dear George, >I am worried that there may be *external* referencees to objects, and while >we have no 'contractual' obligation it might not be nice to do this >to people without some engagement but I expect most people would welcome >losing a path to spam. without going into any detail of the proposal itself, I perceive the fact that there are external references (allowed) _without "consent" and without documentation_ a major flaw in the architecture. In fact, there are mechanisms available already (at least in the RIPE DB-SW V2.x and V3.x) that allow us to deal with that requirement: maintainer objects. >As to automatic sweeping, I think there are problems with link counting >which are similar to those we've faced in discussing cross-database linkage >and references. Too many risks of the link count getting out of whack. Fair enough, a very valid concern! But I think the proposal is trying to describe the "user view" and the "abstract behaviour". >I think you could use it as a guide to a sweep, but not as a determinant >without some review and other checks. Eg to trigger more exhaustive checks >to see if there are are references in twisty ways. I agree. >cheers > -George Cheers, and thanks for partcipating in this discussion! Wilfried.

2 1