- db-wg - mailman.ripe.net

crypted password
by Max Tulyev 25 Jul '06

25 Jul '06

Hi! Why not to hide crypted password in mntner objects from public queries? It is so easy to crack now. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

6 10

Proposal to change the syntax of "nserver:" attribute
by Katie Petrusha 11 Jul '06

11 Jul '06

[Apologies for duplicate mails] Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and update the delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server without a trailing "." [ipv4_address] is an IPv4 address of the name server [ipv6_address] is an IPv6 address of the name server If [domain_name] is followed by an IP address, it must be inside the zone that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) -- Katie Petrusha RIPE NCC

10 16

Re: Need help with ripe-dbase-2.3
by Denis Walker 10 Jul '06

10 Jul '06

Dear Alex Unfortunately version 2 of the RIPE Database code was taken out of production more than 5 years ago. We have archives of the code but no one at the RIPE NCC works on it now. I am sorry but we are unable to assist you with this problem. I have copied this email to the Database Working Group in case some one in the community can assist you. Maybe there are others still running this version of the code. Regards Denis Walker Software Engineering Department RIPE NCC Alex Moura wrote: > Hello, > > We have been using the ripe-dbase-2.3 sucessfully on a server with > perl-5.00503, but now we are having problems to make it run on a new > server with perl-5.8.8. > The server runs, but dies after sucessfully replying a query, > recording only this error message: > > File: (...)/db-root/log/err/errlog > Fatal error: accept failed: No child processes PID: 98560 > > I'd like to know if this code would work with perl-5.8. I will try to > run it with perl-5.6.2, as it seem to be the oldest version od perl > available at the FreeBSD ports. > > We know this code is old, but I'm hopeful to have some answer about > this issue, once we have made some customizations to fufill our > organization needs, and we'd like to avoid - at least for now - having > to port these customizations to the most recent ripe-dbase code. > > Thank you in advance, > > Alex

1 0

2006-03 Policy Proposal Withdrawn (LIR-PARTITIONED status for IPv6)
by Filiz Yilmaz 06 Jul '06

06 Jul '06

PDP Number: 2006-03 LIR-PARTITIONED status for IPv6 Dear Colleagues The proposal 2006-03, LIR-PARTITIONED status for IPv6 has been withdrawn. The proposer decided that the proposal was no longer necessary. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Yet another ipv6 bug ;)
by Max Tulyev 03 Jul '06

03 Jul '06

Hi! If I go to www.ripe.net right now and ask for ORG-RL14-RIPE in whois from IP 2a01:d8:0:99:211:11ff:fe1f:bfc9 - I get %ERROR:208: connection refused From IP 195.209.61.241 everything seems to be fine. What is it? -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 1

Network Upgrade
by Brian Riddle 27 Jun '06

27 Jun '06

[Apologies for duplicate e-mails] Dear Colleagues, I am pleased to announce that the network is now stable following the recent problems we experienced during last week's network upgrade. We have identified two key issues responsible for the instability. 1. Our current firewalls have been chosen to generously accommodate all previously experienced traffic levels. This is an IPv6 related issue which does not affect the stability of the network. 2. We have agreed with Juniper that this high CPU utilisation is an abnormal state which must be addressed. We have open tickets with our suppliers concerning these issues. The network upgrade has been a long-term project with many carefully planned and implemented steps. It is great to see the end of the tunnel appearing and we thank you for your patience and support in this matter. Regards, Brian Riddle IT Manager RIPE NCC

1 0

Yesterday, 21 June, from 12:54 - 13:29 (CET), the RIPE NCC experienced a,network outage.
by Brian Riddle 22 Jun '06

22 Jun '06

[Apologies for duplicate e-mails.] Dear Colleagues, Yesterday, 21 June, from 12:54 - 13:29 (CET), the RIPE NCC experienced a network outage. The outage was caused by a firewall failure during the implementation of our new network infrastructure. We are currently working with Juniper to investigate the problem. We have scheduled maintenance today, 22 June, from 18:00 - 21:00 (CET) to resolve this. During this time, there will be some interruption to services. We apologise for any inconvenience caused by yesterday's outages and today's scheduled maintenance. If you have any questions, please e-mail: <ops(a)ripe.net> Regards, Brian Riddle IT Manager RIPE NCC -- Brian Riddle RIPE Network Coordination Center IT Manager Singel 258 Amsterdam NL http://www.ripe.net +31 20 535 4444 GPG Key fingerprint = 0EBA E8BA 236A D4CD B7A8 C679 A353 054D 2D35 9BE9

1 0

Bug report
by Max Tulyev 22 Jun '06

22 Jun '06

Hi! I can access to Crypt CGI interface at https://www.ripe.net/cgi-bin/crypt.cgi from 195.209.50.18 (IPv4), but from 2a01:d8:0:99:211:11ff:fe1f:bfc9 (IPv6) I can't. I can see http://www.ripe.net (not https probably?) from both addresses. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0

RIPE NCC (AS3333) Maintenance 18:00 - 21:00 (CEST) Today, June 21.
by James Aldridge 21 Jun '06

21 Jun '06

[Apologies for duplicate e-mails.] Dear Colleagues, The RIPE NCC will carry out emergency network maintenance today, June 21, between 18:00 and 21:00 (CEST). During this time, there will be some interruption to our peerings. This work is part of a programme of ongoing network upgrades. We apologise for any inconvenience that this may cause. If you have any questions, please contact: <ops(a)ripe.net> Regards, James -- James Aldridge, Systems & Network Engineer, RIPE NCC Operations Group Tel: +31 20 535 4444 / Fax: +31 20 535 4445

1 0

Bug?
by Max Tulyev 20 Jun '06

20 Jun '06

Hi! I got some troubles with web whois service at www.ripe.net. If my IP is 195.209.50.18 (IPv4) - I can do any queries. But if it is 2a01:d8:0:99:211:11ff:fe1f:bfc9 (IPv6) - I see this error message back to any of my queries (and to non-address queries too): %ERROR:203: address passing not allowed % % Sorry, you are not allowed to pass addresses on the query line. % Please contact us for such permission. For the moment, % continuing this will cause permanent denial of access. Mozilla Firefox tries IPv6 first if there is both addresses and connectivities... Is it a bug or a feature? -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 1

Maintenance of whois-test.ripe.net
by Agoston Horvath 16 Jun '06

16 Jun '06

[Apologies for duplicate e-mails.] Dear Colleagues, We will carry out maintenance work on flute.ripe.net (also known as whois-test.ripe.net) on Monday, 19 June at 11:00-13:00 (GMT). During this period, you may experience outages when trying to use the following services: - whois-test (queries and updates) - whois queries over ipv6 (including the web interface) - rrcc - dbconstat - surfme We apologise for any inconvenience. If you have any questions please contact: <ripe-dbm(a)ripe.net>. Regards, Agoston Horvath Software Engineering Department RIPE NCC

1 0

Update convention
by Niall O'Reilly 16 Jun '06

16 Jun '06

Begin forwarded message: > domain: 3.5.3.e164.arpa > nserver: ns01.3.5.3.e164.arpa 137.43.132.54 > nserver: ns02.3.5.3.e164.arpa 213.190.149.193 > nserver: enum1.eu.afilias.info > notify: ENUM-353-OPS(a)LISTSERV.HEANET.IE > changed: Niall.oReilly(a)ucd.ie 20060614 > changed: someone(a)comreg.ie 20040323 > changed: hostmaster(a)ripe.net 20041222 > source: RIPE > ***Error: Required attribute "descr" is missing > ***Error: Required attribute "admin-c" is missing > ***Error: Required attribute "tech-c" is missing > ***Error: Required attribute "zone-c" is missing I thought we used to have a convention that attributes to be left unchanged in an existing object could validly be omitted in the update request. Did I miss a considered change, or am I doing some "wishful recollection"? /Niall

2 1

Suggestion: un-necessary error message
by Niall O'Reilly 16 Jun '06

16 Jun '06

Begin forwarded message (extracted from a recent update attempt): > changed: Niall.oReilly(a)ucd.ie 20060614 > changed: oonagh.oreilly(a)comreg.ie 20040323 > changed: hostmaster(a)ripe.net 20041222 > source: RIPE > ***Error: The dates in the changed: attributes should be in > accending order > '20040323' was found after '20060614' Wouldn't it be just as easy to sort the attributes into the correct order as to generate an error message? /Niall

4 5

Request for unsuscription
by Mathias VDB 15 Jun '06

15 Jun '06

_________________________________________________________________ Windows Live Mail : venez tester la version bêta ! http://www.ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0…

1 0

Last Call: Proposal for Returning IRT objects
by Denis Walker 15 Jun '06

15 Jun '06

Dear Colleagues On 16 May 2006, we sent out the latest draft of the proposal for returning IRT objects to the RIPE Whois Database. The main difference between this and the previous draft is the introduction of a two-stage implementation plan. We have received no comments on the draft so far. You can find the proposal in the list archives at: http://www.ripe.net/ripe/maillists/archives/db-wg/2006/msg00087.html This is a last call for feedback. Please send any comments to the Database Working Group mailing list before 30 June 2006. After this date we plan to implement the change, taking into account any final comments from the community. Regards Denis Walker Software Engineering Department RIPE NCC

1 0

Outage of Syncupdate and Webupdate (correction)
by Trudy Prins 12 Jun '06

12 Jun '06

[Apologies for duplicate e-mails] Dear Colleagues, Correction: Please note that the service was restarted on *Sunday, 11 June at 23:53:54 GMT* and not as stated in the previous message. If you have any questions or concerns about this, please e-mail: ripe-dbm(a)ripe.net. Regards, Trudy Prins User Support Coordinator Software Engineering Department ------------------------------------------------------ Previous message: Dear Colleagues, The Syncupdate service and the Webupdate service were unavailable from Sunday, 11 June 15:08:19 GMT until Monday, 12 June 23:53:54 GMT. The services are now available again. We apologise for any inconvenience. If you have any questions or concerns about this, please e-mail: ripe-dbm(a)ripe.net. Regards, Trudy Prins User Support Coordinator Software Engineering Department

1 0

Outage of Syncupdate and Webupdate
by Trudy Prins 12 Jun '06

12 Jun '06

[Apologies for duplicate e-mails] Dear Colleagues, The Syncupdate service and the Webupdate service were unavailable from Sunday, 11 June 15:08:19 GMT until Monday, 12 June 23:53:54 GMT. The services are now available again. We apologise for any inconvenience. If you have any questions or concerns about this, please e-mail: ripe-dbm(a)ripe.net. Regards, Trudy Prins User Support Coordinator Software Engineering Department

1 0

Re: Deprecation of ip6.int scheduled for 1 June 2006
by Andrei Robachevsky 02 Jun '06

02 Jun '06

Dear Colleagues, This is a reminder that from 1 June 2006, reverse delegations in the ip6.int DNS tree corresponding to IPv6 address space allocated by the RIPE NCC will no longer be supported. On 1 June 2006, RIPE NCC delegations will be deleted from the ip6.int zone. Following this we will remove the zones from the authoritative servers and delete the corresponding DOMAIN objects in the RIPE Whois Database. The maintainers of the DOMAIN objects to be deleted will also receive individual notifications 1 week prior to the deletion. This is being coordinated with other RIRs and is based on an IETF Best Current Practice document (RFC 4159). Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC On 14 March 2006 Andrei Robachevsky wrote: > Dear Colleagues > > In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', > as a Best Current Practice document. The RFC noted that maintenance of > "ip6.int" is no longer needed and called on the Regional Internet > Registries (RIRs) to decide when to stop providing support for the > domain. The RIRs have jointly agreed to do this on 1 June 2006. > > There will be a short presentation on this at the RIPE 52 Meeting in > Istanbul. You can find more information about this meeting at: > > http://www.ripe.net/ripe/meetings/ripe-52/index.html > > Regards > > Andrei Robachevsky > Chief Technical Officer > RIPE NCC > > > > >

1 1

2006-03 New Policy Proposal (LIR-PARTITIONED status for IPv6)
by Filiz Yilmaz 01 Jun '06

01 Jun '06

PDP Number: 2006-03 LIR-PARTITIONED status for IPv6 Dear Colleagues A new RIPE Policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-03.html We encourage you to review this proposal and send your comments to <db-wg(a)ripe.net> before 29 June 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

please help, can't start whoisserver
by Nicolae Ghimbovschi 29 May '06

29 May '06

Hi everybody ! I'm a newbie in working with a whoisserver, and I can't start it, i get errors I have compiled and installed whoisserve-3.3.0 ,from RIPE site, under Fedora Core 5. #./build.sh --prefix=/opt/whoisd --disable-xmltest --disable-xslttest everything worked fine. But when I run to make the sample database I get errors. In files rip.conf.sample and sources.config.sample I have configured the following lines: in rip.conf.smaple RIPADMIN xmachine.fedora,3306,root,hello,RIPADMIN and in sources.conf.sample DATABASE SAMPLEDB host: xmachine.fedora port: 3306 trx_support: n user: root password: hello /DATABASE [root@xmachine bin]# ./make_db -c /opt/whois/conf/rip.config.sample -s SAMPLE -1 sqlhost=xmachine.fedora sqlport=3306 sqluser=root sqlpswd=hello sqldbname=SAMPLEDB npasses=1 = 10:27:16 Loading database [SAMPLEDB] (source [SAMPLE]) started = 10:27:16 Loading the database [SAMPLEDB] [see list in /dev/tty] *******************Sun May 28 10:27:17 EEST 2006****************** Creating tables\n Creating tables\n creating main database ERROR 1060 (42S21) at line 246: Duplicate column name 'interface_v6_lsp' creating RIPADMIN database Sun May 28 10:27:17 EEST 2006\n Making indexes\n ERROR 1146 (42S02) at line 1: Table 'SAMPLEDB.person_role' doesn't exist Sun May 28 10:27:18 EEST 2006\n Loading tables - 1 of 1 pass\n Sun May 28 10:27:18 EEST 2006 Loading /opt/whois/var/tmp/load/SAMPLE/sample.db.gz D: Making SQL connection to SAMPLEDB(a)xmachine.fedora ...OK starting processing stream Table 'SAMPLEDB.mntner' doesn't exist[SELECT object_id FROM mntner WHERE mntner='TEST-DBM-MNT' ] died: +315 modules/ud/ud_core.c ./load_all.sh: line 15: 3464 Done ${UNZIP1} ${object_file} 3465 | eval ${FILTER} 3467 Segmentation fault | $LOADER -L $1 -p ${PROPERTIES} -s ${SOURCE} *** ERROR: Loader failure [139]. Exiting\n ************** ERROR *************** *** 10:27:18 Error loading database=SAMPLEDB for source=SAMPLE, ./make_db exiting ************************************ ######################################################## ##when making an empty database I get the following ######################################################## [root@xmachine bin]# ./make_db -c /opt/whois/conf/rip.config.sample -s SAMPLE -0 sqlhost=xmachine.fedora sqlport=3306 sqluser=root sqlpswd=hello sqldbname=SAMPLEDB npasses=0 = 10:30:27 Loading database [SAMPLEDB] (source [SAMPLE]) started = 10:30:27 Loading the database [SAMPLEDB] [see list in /dev/tty] *******************Sun May 28 10:30:28 EEST 2006****************** Creating tables\n Creating tables\n creating main database ERROR 1007 (HY000) at line 1: Can't create database 'SAMPLEDB'; database exists ERROR 1060 (42S21) at line 246: Duplicate column name 'interface_v6_lsp' creating RIPADMIN database ERROR 1007 (HY000) at line 2: Can't create database 'RIPADMIN'; database exists Sun May 28 10:30:28 EEST 2006\n Making indexes\n ERROR 1146 (42S02) at line 1: Table 'SAMPLEDB.person_role' doesn't exist Sun May 28 10:30:28 EEST 2006\n Making more indexes\n Sun May 28 10:30:28 EEST 2006 creating indexes for aux tables ERROR 1146 (42S02) at line 4: Table 'SAMPLEDB.tech_c' doesn't exist Sun May 28 10:30:28 EEST 2006 creating indexes for leaf tables ERROR 1146 (42S02) at line 1: Table 'SAMPLEDB.names' doesn't exist Sun May 28 10:30:28 EEST 2006 saving CURRENTSERIAL=22 ERROR 1146 (42S02) at line 1: Table 'SAMPLEDB.serials' doesn't exist Finished Sun May 28 10:30:28 EEST 2006 = 10:30:29 Loading database [SAMPLEDB] (source [SAMPLE]) finished without errors ######################################################## ##when checking the database ######################################################## [root@xmachine bin]# ./whois-server -c /opt/whois/conf/rip.config.sample -p test.pid Configuration [/opt/whois/conf/rip.config.sample]: /opt/whois/log/riperr/riperrlog Check the DB Checking the Database [SAMPLEDB]...died: +230 modules/ud/ud_recover.c Segmentation fault [root@xmachine bin]# ./whoisd_start Starting whois-server daemon with configuration /opt/whois/conf/rip.config.sample from /opt/whois/bin ./whoisd_start: line 174: 3639 Segmentation fault $NOHUP_NICENESS $WHOISRIP -p $pid_file -c ${CONFIG} >>$err_log 2>&1 mv: cannot stat `core': No such file or directory ######################################### #from Error log: ######################################### Warning: undefined configuration variable: SAWFILE Warning: undefined configuration variable: RIR Error: Incomplete configuration file. Was this intended ??? 2 configuration variables undefined. died: +168 modules/sq/mysql_driver.c 060528 10:39:45 whoisd crashed & restarted\n/opt/whois/bin/whois-server -c /opt/whois/conf/rip.config.sample.q\n 060528 10:39:46 /opt/whois/bin/whois-server -p /opt/whois/bin/whois- server.pid -c /opt/whois/conf/rip.config.sample.q Configuration [/opt/whois/conf/rip.config.sample.q]: Warning: undefined configuration variable: SAWFILE Warning: undefined configuration variable: RIR Error: Incomplete configuration file. Was this intended ??? 2 configuration variables undefined. Mandatory variable(s) undefined <<<<<<<<<<<<<<< >>>>>>>>>>> Best Regards, Nicolae

2 1

Mike Simkins is out of the office.
by Mike.Simkins＠sungard.com 28 May '06

28 May '06

I will be out of the office starting 26/05/2006 and will not return until 30/05/2006. I will respond to your message when I return. If you have an urgent issue - please call the IOC at 1-800-41-1181 where someone will be able to help you immediately

1 0

RIPE 52 Draft Minutes of the DB WG meeting posted to web site
by Nigel Titley 26 May '06

26 May '06

Folks, The final draft minutes have been sent to the RIPE NCC webmaster for posting to the RIPE website. You *all* failed to spot that I misnumbered the action points as 51.n rather than 52.n (actually, so did I until I extracted the actions ready for uploading to the web site). Enjoy Nigel

1 0

RIPE 52 Draft Minutes of the DB WG meeting (Final Call)
by Nigel Titley 24 May '06

24 May '06

Folks, Having posted the 2nd draft of the minutes on the 8th May and having received no comments I am assuming that these are now acceptable as a record of the RIPE 52 meeting. I'll give it until the end of the week and then post the minutes and actions to the DB-WG website. Thanks to all who commented Nigel

1 0

Database query tool for ip allocations
by Fuat Demir (Garanti Teknoloji) 24 May '06

24 May '06

Hi, I'm looking for a tool that sends a query to the database whether the source ip is in the db or not. The database which will be looked up for the query should contain the ip allocations and ISP ip blocks of the all RIR's (RIPE, ARIN, LACNIC, APNIC, AfriNIC) and it must be keep updated in a period of time, for example, daily. The tool will give permission or restriction to the packets by sending query to the updated database and new allocations will not be discarded. How could i achieve this ? Thank you. Fuat Demir Garanti Technology This message and attachments are confidential and intended solely for the individual(s) stated in this message. If you received this message although you are not the addressee, you are responsible to keep the message confidential. The sender has no responsibility for the accuracy or correctness of the information in the message and its attachments. Our company shall have no liability for any changes or late receiving, loss of integrity and confidentiality, viruses and any damages caused in anyway to your computer system. Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi herhangi bir zarardan sorumlu tutulamaz.

1 0

Proposal for returning IRT objects
by Denis Walker 16 May '06

16 May '06

[Apologies for duplicate mails] Proposal for returning IRT objects Motivation ---------- The original proposal for the IRT object (ripe-254) did not make adequate provision for presenting the irt information to the user. A new query flag ("-c") was introduced. Because of the way this flag was implemented and the objects it returned, it was not considered intuitive or helpful. It can also cause confusion. A discussion held at the RIPE 51 meeting decided that the original implementation was a misunderstanding of the requirements. For more information, see AOB in the Database Working Group minutes: http://www.ripe.net/ripe/wg/db/minutes/ripe-51.html There was further discussion at the RIPE 52 meeting, details of which can be found at: http://www.ripe.net/ripe/maillists/archives/db-wg/2006/msg00052.html Objectives ---------- - To increase the availability of the irt information to users. - To promote the use of the IRT object. - To make it easier for third party tool writers to find the correct contacts. Background ---------- There has been confusion in the past about the implementation of the IRT object. We have been studying the concept and looking deep into the whois query code. Our understanding of how this works now, and how the community wants it to work in the future, has changed. This proposal outlines the current behaviour and what we now understand to be the desired behaviour. Current behaviour ----------------- A standard query for address space returns the queried inetnum and related objects. This does not include an IRT object, even if it is directly referenced by the queried INETNUM object. By using the "-r" flag, the related personal objects are filtered out but ROUTE objects are still returned. By using the "-c" flag, an INETNUM object is returned with a referenced IRT object and objects related to this INETNUM. This may not be the INETNUM in the query. No ROUTE objects are returned. If no (less specific) INETNUM references an IRT object, nothing is returned. By using the "-rc" flags, the related personal objects are filtered out, including the IRT object. The only object returned is the referencing INETNUM object, which may not be the one in the query. So it is not possible to find IRT objects without returning personal objects related to the referencing INETNUM object. New behaviour ------------- A standard query for address space returns the queried INETNUM and related objects. This does not include an IRT object, even if it is directly referenced by the queried INETNUM object. This is the same as the current behaviour. We propose to change this default behaviour at the second stage of implementation (see Implementation below). By using the "-r" flag, the related personal objects are filtered out but ROUTE objects are still returned. A standard query for address space including the "-c" query flag returns the queried inetnum and related objects. This will also include an IRT object referenced by the queried INETNUM object or the closest less specific INETNUM object, if one exists. It will also still include any ROUTE objects. By using the "-rc" flags, the related personal objects are filtered out. The IRT object will still be returned along with any ROUTE objects. When using any other address space query flags (lLmMxb) or querying for other object types, query behaviour remains the same as the current behaviour. If the "-c" query flag is used, it will be ignored. Implementation -------------- We propose a two stage implementation. The majority of the address space queries are made without any specific flags. We therefore propose to change the behaviour to return an IRT object by default (if one exists) only at the second stage. For the first stage, we propose changing the behaviour of the "-c" flag and the "-rc" flag combination as described above. This should not make any fundamental changes to the way the queries work. Existing tools and scripts should not fail. The web query form on www.ripe.net will add the "-c" flag to address space queries, making it a default. This only occurs if no other address space query flags (lLmMxbc) are present. At the second stage, the query server will add the "-c" flag to any address space query that does not include any of the address space query flags (lLmMxbc). This will make standard queries return IRT objects by default. This second stage changes the current behaviour of queries. This may break some tools and scripts. We can mitigate this by providing new query flags or using existing ones in different ways so that the behaviour resulting from the first stage of implementation can be reproduced. Tool writers ------------ Currently any third party tools that use the "-c" flag to find IRT objects run the risk of being blocked for returning too many personal objects. With the new behaviour, the "-rc" flags can be used to return the IRT objects without the personal objects. If only the IRT object is needed, "-rc -T irt" can be used. Notes ----- Any references to INETNUM and ROUTE objects also imply INET6NUM and ROUTE6. A consequence of this change is the return of an object with no direct reference from the queried object. With grouping turned on (default without "-G"), we assume that the IRT object should be grouped with the queried INETNUM object. -- Denis Walker Software Engineering Department RIPE NCC

1 0