August 2014 - 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

Draft minutes of RIPE 67 meeting
by Nigel Titley 05 Nov '14

05 Nov '14

Please find draft minutes of the DB-WG meeting held in Athens today. Comments, complaint, misrepresentations etc, to me Nigel

1 1

Proposal to remove "referral-by" attribute in "mntner" object or make it optional
by Martin Tõnusoo 06 Oct '14

06 Oct '14

Hello, "referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object: [martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$ I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: [martint@ ~/ripe-db]$ for year in {2000..2014}; do for month in January February March April May June July August September October November December; do wget -q --no-check-certificate https://www.ripe.net/ripe/mail/archives/db-wg/$(printf '%s-%s.txt.gz\n' "$year" "$month"); done; done [martint@ ~/ripe-db]$ zgrep -Hi "referral-by" * 2000-August.txt.gz:-irb (or -ireferral-by) <maintainer name> 2000-August.txt.gz:Returns all objects whose referral-by attribute matches the query 2001-August.txt.gz:referral-by: RIPE-DBM-MNT 2001-May.txt.gz:If you mean referral-by, it points to mntner handle, mandatory in mntner 2003-April.txt.gz:referral-by: RIPE-DBM-MNT 2003-April.txt.gz:referral-by: RIPE-DBM-MNT 2003-August.txt.gz:> referral-by: RIPE-DBM-MNT 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz:> referral-by: MAINT-RGNET 2003-December.txt.gz:> referral-by: MAINT-RGNET 2003-December.txt.gz:> > referral-by: MAINT-RGNET 2003-December.txt.gz:> > referral-by: MAINT-RGNET 2003-July.txt.gz:referral-by: RIPE-DBM-MNT 2004-April.txt.gz:referral-by: RIPE-DBM-MNT 2004-June.txt.gz:referral-by: [mandatory] [single] [inverse key] 2004-June.txt.gz:referral-by: RIPE-DBM-MNT 2004-June.txt.gz:Subject: [db-wg] Proposed Change 2004.2: Removal of "referral-by:" Attribute 2004-June.txt.gz:[2004.2] Removal of "referral-by:" Attribute from the MNTNER Object 2004-June.txt.gz:Remove the "referral-by:" attribute from the MNTNER objects' schema. This 2004-June.txt.gz:The "referral-by:" attribute was introduced into MNTNER objects when the 2004-June.txt.gz:"referral-by:" is defined in RFC2725: 2004-June.txt.gz: referral-by This attribute is required in the maintainer object. It 2004-June.txt.gz: referral-by. An auth-override can only be added to a maintainer 2004-June.txt.gz: those identified by the maintainer in the referral-by have 2004-June.txt.gz: "referral-by" attribute is now mandatory in the "maintainer" object 2004-June.txt.gz: referenced by a "referral-by" attribute elsewhere. 2004-June.txt.gz:The RIPE NCC introduced the "referral-by:" attribute as a place-holder, 2004-May.txt.gz:referral-by: [mandatory] [single] [inverse key] 2005-May.txt.gz:> referral-by: [mandatory] [single] [inverse key] 2005-May.txt.gz:> > referral-by: [mandatory] [single] [inverse key] 2005-November.txt.gz:>referral-by: RIPE-DBM-MNT 2005-November.txt.gz:> >referral-by: RIPE-DBM-MNT 2005-November.txt.gz:> > >referral-by: RIPE-DBM-MNT 2007-July.txt.gz:> referral-by: RIPE-DBM-MNT 2007-July.txt.gz:>> referral-by: RIPE-DBM-MNT 2007-June.txt.gz: referral-by: RIPE-DBM-MNT 2007-June.txt.gz: referral-by: RIPE-DBM-MNT 2007-June.txt.gz:> referral-by: RIPE-DBM-MNT 2007-June.txt.gz:> referral-by: RIPE-DBM-MNT 2012-April.txt.gz:referral-by: DEV-ROOT-MNT 2013-March.txt.gz:referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:>> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:>>> referral-by: TRUBNIKOV-MNT [martint@ ~/ripe-db]$ He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version. Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. WBR, Martin Tonusoo -------------------------- LINXTELECOM www.linxtelecom.com -------------------------- NOC 24/7: +372 622 3300

13 25

last-modified:, a succesor to changed:
by Job Snijders 16 Sep '14

16 Sep '14

Dear DB Working Group, Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled: Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed Eleanor:~ job$ whois -h whois.radb.net AS15562 | grep changed changed: unread(a)ripe.net 20000101 Eleanor:~ job$ Fantastic! Now we are absolutely none the wiser. :-) I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:". The "last-modified" attribute is set by the whois server software and represents the date and time at which the last succesful modification was received by the server. When a user submits an update for an object in which the attribute is present, the server software will ignore the attribute, insert its own attribute with the current time, and present a warning to the user that the user's version of "last-modified" was ignored. The "last-modified" attribute should be presented by the server software in all types of objects (autnums, poems, etc) for which the server is responsible (e.g. do not touch foreign or mirrored objects). The date and time are represented following the ISO 8601 [1] profile for complete date plus hours, minutes and seconds, always expressed in UTC, including the special UTC designator 'Z'. The "last-modified" attribute should be presented above, but close to the "source:" attribute. The advantage is that the date and time are both human readable and computer parsable! A valid example "last-modified" attribute would be: last-modified: 2014-04-15T13:15:30Z I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation. Kind regards, Job [1] - https://xkcd.com/1179/

15 43

IP Address Space Course this November in London
by Training Services 26 Aug '14

26 Aug '14

Dear Colleagues, We are happy to announce a new RIPE NCC training course that will take place on the Sunday before the RIPE 69 Meeting in London this November. This new course will focus on how to obtain, transfer, manage and protect your IP address space. The course is free of charge and is open to anyone interested. The course will cover the most frequently asked questions the RIPE NCC receives about IP address space. Course title: RIPE NCC Presents: IP Address Space Basics How to obtain, transfer, manage and protect your IP addresses Goals: By the end of this course, you will be able to: - Manage your IPv4 and IPv6 addresses according to current RIPE Policies - Understand how to obtain IPv4 addresses through transfers - Protect your address space from hijacking Target audience: Anyone interested in the policies and procedures around address space in the RIPE NCC service region, and companies looking at address space transfers, mergers and acquisitions. No prior knowledge of the topic is necessary. Time: Sunday, 2 November, 10:00–16:00 Outline: - Becoming a RIPE NCC member (why and how) - Obtaining IP addresses (IPv4 and IPv6) - IP address space transfers, mergers and acquisitions - IPv6 basics - Address space hijacking - Resource Certification (RPKI) Cost: Free of charge. Coffee and lunch will be provided. The course will be delivered by representatives from the RIPE NCC’s Training Services and Registration Services departments. If you are interested in attending this course, please let us know asap by sending an email to training(a)ripe.net. Be quick - we only have 40 seats available on a first come, first served basis! If there is enough interest, we will continue to offer courses on different topics of interest alongside future RIPE Meetings. Kind regards, Training Services

1 0

RIPE Database Release 1.75
by Denis Walker 20 Aug '14

20 Aug '14

Dear colleagues, The RIPE NCC is pleased to announce the RIPE Database software release 1.75 to the Release Candidate (RC) environment. Detailed information about features, changes and how this release might affect your operations, are available in the release notes: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.75 The main feature of this release is that we have implemented the changes required within the RIPE Database, as part of the implementation for the accepted RIPE Policy Proposal 2014-01, 'Abandoning the Minimum Allocation Size for IPV4'. These changes are detailed in the release notes. This release also fixes a number of issues, described within the release notes. More information about the RC environment is available online: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… We look forward to any questions or comments you might have. Regards, Denis Walker RIPE NCC

2 4

Personalised auth / killing mntner proposal
by Tore Anderson 19 Aug '14

19 Aug '14

https://ripe68.ripe.net/archives/video/181/ Anyone know the status of this proposal? Tore, who keeps punting his "clean up mntner mess" todo item in the hope that it will be overtaken by events

1 0

[training] RIPE NCC Training Courses October-December 2014
by Training Services 19 Aug '14

19 Aug '14

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Ljubljana, Norway, Tbilisi, Berlin, Bratislava, Amman, Lyon, Athens, London, Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0