June 2007 - db-wg - mailman.ripe.net

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

17 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

Proposal - Maintaining person, role and domain objects
by Denis Walker 11 Jul '07

11 Jul '07

[Apologies for duplicate mails] Dear Colleagues, As a result of discussions during the Database Working Group session at RIPE 54, the RIPE NCC has nine proposals and implementation plans to present to the community. Although most of them are now in the final stages of preparation, we will send them out one at a time over the next few weeks for consideration by the community. The first one concerns maintaining all objects in the RIPE Database, which followed from a recommendation from the Data Protection Task Force (DP TF) (see below). We have already had some preliminary discussions about this with the DP TF. They provided the RIPE NCC with some very useful feedback, which is incorporated in this proposal. Regards Denis Walker RIPE NCC Maintaining person, role and domain objects ------------------------------------------- * Introduction * Proposal * Illustrations of how the checks work - New startup - Closing down - Modifying existing data * Implementation - Stage 1 - Stage 2 - Stage 3 * Statistics Introduction ------------ It was agreed at RIPE 54 that the "mnt-by:" attribute would be made mandatory on all objects. Currently, for person, role and domain objects, "mnt-by:" is optional. Making "mnt-by:" mandatory on person objects raises two clear issues: 1. It creates a chicken and egg situation between person and mntner objects. 2. Many person objects are not changed for years, so any change to syntax may take a long time to be reflected in the database. Many un-maintained person objects could therefore remain so for many years. Proposal -------- Making "mnt-by:" mandatory on role and domain objects does not cause any technical difficulties. To address all the issues relating to the person objects, we suggest a slightly different approach. 1. Make "mnt-by:" mandatory in person objects. 2. Provide a mechanism in dbupdate to handle the startup case where a new person and mntner objects are required. 3. Provide a mechanism in dbupdate to handle the closing down situation where the last person and mntner objects are to be deleted. 4. Extend the referential integrity checks so that a person object cannot be referenced unless it is maintained, except in a mntner object. 5. Extend the referential integrity checks so that a mntner object cannot be referenced unless the person objects it references are maintained. This does not include the cyclic case of a person and mntner object referencing each other. The referencing checks sound complicated in words, but are actually quite simple. The illustrations below explain how it works in practice. This approach has a number of advantages: 1. It accommodates the chicken and egg situation. 2. We already do referential integrity checks. Whenever there is a reference to a person object, the database software checks if the person object exists. We only have to extend this check to see if the person object is also maintained. 3. Whenever there is a reference to a mntner object, the database software checks if the mntner object exists. We only have to extend this check to see if the person objects referenced by the mntner are maintained. 4. Each time any other object (say an inetnum or aut-num) is modified, the referenced person objects need to be maintained. If not, the update will fail. This will not prevent anyone from working. If they are going to modify an inetnum object, they must be authorised to do so. They can apply the same mntner to any un-maintained person objects. This encourages users to maintain the existing person objects. A CGI script may be provided to make this process simple and quick if it is considered to be helpful. 5. No un-maintained person object can be linked to the white pages to avoid deletion. (The white pages will be explained in a later proposal.) Illustrations of how the checks work ------------------------------------ New startup Send an update message to dbupdate to create a person object and a mntner object. These must be the first two objects in an update message, in any order. The references to each other must also be in place. The database software will accommodate this. person: Den is address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE mnt-by: aardvark-mnt notify: denis(a)ripe.net changed: denis(a)ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis(a)ripe.net auth: X509-1 notify: denis(a)ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis(a)ripe.net 20040225 source: RIPE The update software will recognise that the first person/mntner object references a non-existent mntner/person object. It will check that this referenced object is next in the update message. If it is, the "mnt- by:" attribute will be removed from the person object. The person and mntner objects will be created, and then the person object will be modified to add back the "mnt-by:" attribute. The objects are now fully configured and can be used. The person object can be referenced by any other object where a nic-hdl is referenced. It can also be linked to the white pages. The mntner can be used to protect any data in the database. If the non-existent referenced object is not next in the update message then an error message will be generated and the update will fail. This is the current behaviour. Closing down The same situation occurs when closing down and deleting all the data. It is possible to delete all data except for the last person and mntner objects in the normal way. To delete these last two, send them together in an update message, both marked with the "delete:" pseudo attribute. Only these two objects should be in the update message. The update software will recognise that the first person/mntner object to delete is referenced in a mntner/person object. It will check that this referencing object is next in the update message and also marked for deletion. If so the person object will be modified first to remove the "mnt-by:" attribute. The mntner object will then be deleted, followed by the person object. Modifying existing data Suppose some data is to be modified and there is a reference to an un- maintained person object. Suppose you already have this data in the database: inetnum: 193.0.0.0 - 193.0.7.255 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands remarks: Used for RIPE NCC infrastructure. country: NL admin-c: DW-RIPE tech-c: DW-RIPE status: ASSIGNED PI mnt-by: AARDVARK-MNT mnt-lower: AARDVARK-MNT changed: bit-bucket(a)ripe.net 20060221 source: RIPE person: Den is address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 nic-hdl: DW-RIPE notify: denis(a)ripe.net changed: denis(a)ripe.net 20040318 source: RIPE mntner: AARDVARK-MNT descr: Mntner for denis' objects. admin-c: DW-RIPE tech-c: DW-RIPE upd-to: denis(a)ripe.net auth: X509-1 notify: denis(a)ripe.net mnt-by: AARDVARK-MNT referral-by: RIPE-DBM-MNT changed: denis(a)ripe.net 20040225 source: RIPE The inetnum and mntner objects both reference a person object that is not maintained. This situation can continue for the foreseeable future with no problem. The situation becomes problematic when some data needs to be changed. An attempt to modify the inetnum object will fail. This is because it references a person object that is not maintained. It also references a mntner object which references un-maintained person objects. (This will only happen in stage three of the implementation) These person objects will have to be maintained before the inetnum object can be modified. A CGI script will be provided to allow this to be done quickly and easily. When all referenced person objects are maintained, the original update can be resubmitted and will proceed. Implementation As with the CRYPT-PW deprecation this will have a staged rollout. Stage 1 * No new person, role or domain objects can be created without a "mnt-by:" attribute. * Any un-maintained person, role or domain object cannot be modified without adding a "mnt-by:" attribute. * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate a warning message in the acknowledgement. In this stage the acknowledgement message may include these warnings: ***WARNING: Un-maintained person object referenced [DW-RIPE] ***WARNING: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] Stage 2 * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate a warning message in the acknowledgement. * Any NEW reference to an un-maintained person object or to a mntner which has such references will generate an error message in the acknowledgement and the update will fail. In this stage the acknowledgement message may include these warnings and errors: ***WARNING: Un-maintained person object referenced [DW-RIPE] ***WARNING: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] ***ERROR: New reference to un-maintained person object [DW-RIPE] ***ERROR: New reference to un-maintained person object [DW-RIPE] in mntner [AARDVARK-MNT] Stage 3 * Any update where objects reference an un-maintained person object, either directly or through a mntner with such references, will generate an error message in the acknowledgement and the update will fail. In this stage the acknowledgement message may include these errors: ***ERROR: Un-maintained person object referenced [DW-RIPE] ***ERROR: Un-maintained person object referenced [DW-RIPE] in mntner [AARDVARK-MNT] Statistics ---------- While not a very statistically valid survey, we looked at a few days just after the RIPE meeting to see how many new person objects were created with and without mntner objects. We also queried the new objects some time after creation to allow for a "mnt-by:" to be added later. We also noted how many unique person objects were referenced in any objects in update messages with and without mntner objects. AUTO- references were ignored in both creations and updates, and multiple instances of the same person object being referenced many times were counted as one. -------------------------------------------------------- | Date |Created |Created |Referenced |Referenced | | |with |without |with |without | |--------------------------------------------------------| | 20070515 | 156 | 89 | 925 | 726 | | 20070516 | 111 | 67 | 1022 | 486 | | 20070517 | 85 | 48 | 476 | 185 | | 20070518 | 82 | 18 | 679 | 445 | --------------------------------------------------------

4 5

New test server for "IRT by default" behaviour
by Katie Petrusha 05 Jul '07

05 Jul '07

Dear Colleagues, On 1 August 2007, the RIPE NCC will update the RIPE Database server so that IP queries return IRT objects by default. Details of this change are available here: http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00113.html To help ensure a smooth transition, we have set up a test server, which can be accessed at: test-whois-default-irt.ripe.net port 43043 This server runs the updated RIPE Database software, and contains data identical to the RIPE Database. You may use this server to test your tools and queries against the new default behaviour. For command line parameters, use "-h test-whois-default-irt.ripe.net -p 43043 <your_query>". The test server will be decomissioned on 1 August 2007. If you have any questions, please send an e-mail to <ripe-dbm(a)ripe.net>. Regards, -- Katie Petrusha Database Department RIPE NCC

3 5

Draft Minutes from Tallin RIPE meeting
by Nigel Titley 29 Jun '07

29 Jun '07

Gentlefolk, I've been very remiss in not posting these minutes before, but the extra time has allowed Chris (of the RIPE NCC) and me to give them an extra burnishing. So, don your sunglasses, and view these excellent minutes. Comments welcome Nigel This email and any attachments may be confidential and/or legally privileged. If you have received this e-mail and you are not a named addressee, please inform the sender of this email by sending a return email to the address above and then delete the e-mail and your response from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail. Any views or opinions presented are solely those of the author. Any statements made, or intentions expressed in this communication may not necessarily reflect the view of Easynet. No content herein will bind Easynet or any associated company unless confirmed by the execution of a formal contract by Easynet. Any figures or amounts given in this email are quotations only and are subject to change. Although Easynet routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Easynet makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). Easynet Limited a company incorporated and existing under the laws of England and Wales, with company number 2954343 and having its registered office at 44-46 Whitfield Street London, W1T 2RJ.

1 0

IPv6 access to the RIPE Database server is restored
by Katie Petrusha 29 Jun '07

29 Jun '07

[ Apologies for duplicate mails ] Dear Colleagues, IPv6 access to the RIPE Database server has now been restored. The server was unable to respond to queries over IPv6 from 11:12 (UTC), 29 June 2007. Details of this incident are available at: http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00118.html We apologise for any inconvenience. If you have any questions or concerns about this, please send an e-mail to <ripe-dbm(a)ripe.net>. Regards, Katie Petrusha Database Department RIPE NCC

1 0

RIPE DB not accessible over IPv6
by Agoston Horvath 29 Jun '07

29 Jun '07

Dear Colleagues, >From 11:12 on 29 June 2007, the RIPE Database is not able to respond to queries over IPv6. All other services (updates, queries over IPv4) are unaffected. This problem is due to a firewall-related issue in our Juniper routers. We apologise for any inconvenience. If you have any questions or concerns about this, please contact us at: <ripe-dbm(a)ripe.net> Regards, Agoston Horvath Database Group RIPE NCC

1 0

"-c" flag to become default in RIPE Database server
by Katie Petrusha 27 Jun '07

27 Jun '07

[Apologies for duplicate mails] Dear Colleagues, On 1 August 2007, the following changes will be made to the default behaviour for IP queries of the RIPE Database: * The "-c" flag behaviour will become the default for all IP queries. This means that when querying an IP address or range, any query not containing the "-L", "-l", "-M", "-m" or "-x" flags will, by default, return the IRT object referenced by the closest less specific inet(6)num (if such a reference exists). * A new "-C" flag will be implemented to provide the old behaviour and ensure backwards compatibility. The behaviour of the "-c" flag itself will not change, nor will there be any change for those queries that include other IP flags ("-L", "-l", "-M", "-m" or "-x"). Please adjust any software that you maintain that queries the RIPE Database and relies on this behaviour. Regards, Katie Petrusha Database Department RIPE NCC

2 2

Proposal to remove "RIPE Document" status from RIPE database documents
by Katie Petrusha 26 Jun '07

26 Jun '07

[ Apologies for duplicate mails ] Dear colleagues, To your attention the proposal to remove "RIPE Document" status from RIPE Database documents. Introduction ------------ Currently all the RIPE Database documents are classed as official RIPE Documents. This means that any changes to the documents must be made via a formal, and sometimes lengthy, procedure. As a result, changes are grouped and updates to the documents are staged periodically, meaning that the documents are often out of date in some way. Based on discussions at RIPE 54, the RIPE NCC is currently finalising eight proposals to send to the community. Each of these will require changes to the database documentation. There are also a number of other issues still to be discussed by the Data Protection Task Force, any of which may result in further proposals, as well as software or procedure changes, which may require further changes to the documentation. To keep the documents up to date throughout this process will require almost monthly releases, which is not possible under the current scheme. Proposal -------- The documents listed below [1] do not define any RIPE policies. These documents explain how the database software applies policy that is defined in other formal RIPE Policy Documents and RFCs. The RIPE Database Update Reference Manual [1], for example, explains how the database software applies the route authentication process, but the process itself is defined in other official documents. We propose to remove the official RIPE Document status on the documents listed below [1]. This will allow us to more frequently modify these documents and keep them in line with developments as they occur. All documents will remain available to users on the RIPE website in the same format as they are currently presented. References ---------- [1] List of documents: * RIPE Database Query Reference Manual (ripe-401) * RIPE Database Update Reference Manual (ripe-252 and ripe-draft) * RIPE Database User Manual: Getting Started (ripe-402) -- Katie Petrusha Database Department RIPE NCC

1 0

Re: db-wg digest, Vol 1 #520 - 1 msg
by Denis W 26 Jun '07

26 Jun '07

Hi Joao I agree. So lets focus first on a consensus for stage 1. Then we can start work on that while we continue discussions on the other stages and the impacts they will have on work flow of LIRs. regards Denis RIPE NCC Cc: Database WG , ncc-services-wg From: Joao Damas Subject: Re: [db-wg] Proposal - Maintaining person, role and domain objects Date: Mon, 25 Jun 2007 11:00:20 +0200 To: Denis Walker Stage 1 makes a lot of sense to me as it has little consequences to older data while it makes sure new information going into the DB has a better chance of being kept as originally posted by the object creator. The other stages do need a bit more discussion as they may in fact affect a lot of legacy data and have the potential to add a burden to LIR operations. I am in favour of those extra steps, just think that there is a need to repeat the warnings and announcements before and insist on people making an impact analysis on their operations. Joao Damas On 21 Jun 2007, at 14:41, Denis Walker wrote: > [Apologies for duplicate mails] > > Dear Colleagues, > > As a result of discussions during the Database Working Group > session at > RIPE 54, the RIPE NCC has nine proposals and implementation plans to > present to the community. Although most of them are now in the final > stages of preparation, we will send them out one at a time over the > next > few weeks for consideration by the community. > > The first one concerns maintaining all objects in the RIPE > Database, which > followed from a recommendation from the Data Protection Task Force > (DP TF) > (see below). We have already had some preliminary discussions about > this > with the DP TF. They provided the RIPE NCC with some very useful > feedback, > which is incorporated in this proposal. > > Regards > Denis Walker > RIPE NCC > > > > Maintaining person, role and domain objects > ------------------------------------------- > > > Implementation > As with the CRYPT-PW deprecation this will have a staged rollout. > > Stage 1 > > * No new person, role or domain objects can be created without a > "mnt-by:" attribute. > * Any un-maintained person, role or domain object cannot be modified > without adding a "mnt-by:" attribute. > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate a warning message in the acknowledgement. > > In this stage the acknowledgement message may include these warnings: > > ***WARNING: Un-maintained person object referenced [DW-RIPE] > ***WARNING: Un-maintained person object referenced [DW-RIPE] in > mntner [AARDVARK-MNT] > > Stage 2 > > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate a warning message in the acknowledgement. > * Any NEW reference to an un-maintained person object or to a mntner > which has such references will generate an error message in the > acknowledgement and the update will fail. > > In this stage the acknowledgement message may include these warnings > and errors: > > ***WARNING: Un-maintained person object referenced [DW-RIPE] > ***WARNING: Un-maintained person object referenced [DW-RIPE] in > mntner [AARDVARK-MNT] > ***ERROR: New reference to un-maintained person object [DW-RIPE] > ***ERROR: New reference to un-maintained person object [DW-RIPE] in > mntner [AARDVARK-MNT] > > Stage 3 > > * Any update where objects reference an un-maintained person object, > either directly or through a mntner with such references, will > generate an error message in the acknowledgement and the update > will fail. > > In this stage the acknowledgement message may include these errors: > > ***ERROR: Un-maintained person object referenced [DW-RIPE] > ***ERROR: Un-maintained person object referenced [DW-RIPE] in mntner > [AARDVARK-MNT] > > > Statistics > ---------- > While not a very statistically valid survey, we looked at a few days > just after the RIPE meeting to see how many new person objects were > created with and without mntner objects. We also queried the new > objects some time after creation to allow for a "mnt-by:" to be added > later. We also noted how many unique person objects were referenced in > any objects in update messages with and without mntner objects. AUTO- > references were ignored in both creations and updates, and multiple > instances of the same person object being referenced many times were > counted as one. > > -------------------------------------------------------- > | Date |Created |Created |Referenced |Referenced | > | |with |without |with |without | > |--------------------------------------------------------| > | 20070515 | 156 | 89 | 925 | 726 | > | 20070516 | 111 | 67 | 1022 | 486 | > | 20070517 | 85 | 48 | 476 | 185 | > | 20070518 | 82 | 18 | 679 | 445 | > -------------------------------------------------------- > End of db-wg Digest --------------------------------- New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.

1 0

RIPE NCC Network Maintenance Wednesday 20 June 17:00 to 19:00 UTC/GMT
by Mark Guz 18 Jun '07

18 Jun '07

[apologies for duplicates] Dear Colleagues, On Wednesday 20/06/2007, between 17:00 and 19:00 (UTC), the RIPE NCC will carry out planned maintenance work on our network infrastructure. This may result in brief interruptions to RIPE NCC services during the posted maintenance window. We apologise for any inconvenience that this may cause. This work is due to planned resilience testing of our network. If you have any questions about this, please send an e-mail to: ops(a)ripe.net <mailto:ops@ripe.net>. Regards Mark Guz Senior Engineer RIPE NCC

1 0

***Error: Date in the future in changed: attribute '20070607'
by Max Tulyev 07 Jun '07

07 Jun '07

Hi! I just sent a request for creating a new object in the RIPE DB, but got such error. But we really have June, 07 now here (GMT+2) =) Is it a bug or a feature? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

5 7

Re: Network Maintenance - Tuesday, 5 June 2007
by James Aldridge 05 Jun '07

05 Jun '07

-------- James Aldridge wrote: > The RIPE NCC will perform planned maintenance work on Tuesday, 5 June > 2007 between 17:00 and 18:00 (UTC). > > This work will affect a number of servers and may result in a short > outage of some RIPE NCC services. We apologise for any inconvenience > that this may cause. This maintenance work has now been successfully completed. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC Tel: +31 20 535 4444 / Fax: +31 20 535 4445

1 0

RE: Changing/Adding route objects
by Michael Markstaller 05 Jun '07

05 Jun '07

Hi, getting back on this topic from quite a while ago, I just found it while having exactly this problem.. >On Wed, Apr 05, 2006 at 08:28:29AM +0200, Ihler, Hermann wrote: >> if OLD-ISP updates his objects as follows it also will >> work: > >But that's winfried's point: the old ISP need to actively enable >creation of the new route object. And/or it needs, as in my case, being able to actually do this in time. My favorite answer for today, waiting since Friday, is "This is an automated system, I cannot do this. I can only delete the object" (Which means in my basic understanding of IRR, if I don't create the new one in time, I'll be filtered by anybody doing best practice and use IRR..) This makes me waiting this night for this magic change to happen sometime.. I somehow don't trust on what this change from an "automated system" being oparted by poeple that don't have the mntner theirselve (maybe for some good reason) will actually do.. So I'm with the inital suggestion: the mntner of the inetnum should be able to override/make changes to the route-object of his own network, regardless which mntner is sitting on it. If there are good reasons against this, I'm happy to learn the these. regards Michael Markstaller

2 1

RIPE NCC Network Maintenance Thursday 07 June 1700-1900 UTC
by Mark Guz 04 Jun '07

04 Jun '07

[apologies for duplicates] Dear Colleagues, Between 17:00 and 19:00 (UTC/GMT) on Thursday, 07 June 2007, the RIPE NCC will carry out planned maintenance work on our network infrastructure. During this period, www.ripe.net and associated sites, ftp.ripe.net, whois.ripe.net and Authorative DNS services as provided by the RIPE NCC may be interupted. We apologise for any inconvenience that this may cause. If you have any questions about this, please e-mail ops(a)ripe.net Regards Mark Guz Senior Engineer Operations Department RIPE NCC

1 0

database mirroring
by Andres Riancho 01 Jun '07

01 Jun '07

List, I'm doing some research for my University project and I want to know if it is possible to create a local mirror of the whois server at whois.ripe.net . I have been reading a lot and found some references to "Near Real Time Mirroring" and also to the "-g" option of the whois client, but nothing that I could really use. Please note that I dont want to setup a whois server that forwards requests, I want a mirror. Could someone please point me to a document where I can find the requirements ( if any ) for mirroring the whois database, and also the technical details for making this happend ? Are there any copyright problems I should worry about when doing a whois.ripe.net mirror ? This is my first post to this list, so excuse me if this aint the right place to ask. Thanks in advance for all your replies. Cheers, -- Andres Riancho

1 0

Network Maintenance - Tuesday, 5 June 2007
by James Aldridge 01 Jun '07

01 Jun '07

Dear Colleagues, The RIPE NCC will perform planned maintenance work on Tuesday, 5 June 2007 between 17:00 and 18:00 (UTC). This work will affect a number of servers and may result in a short outage of some RIPE NCC services. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to <ops(a)ripe.net>. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC Tel: +31 20 535 4444 / Fax: +31 20 535 4445

1 0