May 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

RIPE Database Release 1.73.1 Available in the Release Candidate Environment
by Johan Åhlén 13 Jun '14

13 Jun '14

Dear colleagues, Based on feedback from users testing RIPE Database release 1.73 in the Release Candidate (RC) environment, the RIPE NCC Database Group have made some software improvements that we’ve decided to incorporate into the next deployment. We will not deploy version 1.73 to production. Instead, we will deploy the improved version, 1.73.1, to the RC environment today, 19 May, and to production on 27 May 2014. The main concern with RIPE Database release 1.73 was related to user-automated assignment generation in the RIPE Database for legacy address space. With release 1.73, if a legacy object was updated with an incorrect "status:" attribute value, then the update would fail. With version 1.73.1, the database software will accept the update, regardless of any value supplied by the user, but will show a warning if the “status:” attribute value is incorrect. For more information about this release and how it might affect your operations, please see the release notes: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.73… We look forward to any questions or comments you might have. Kind regards, Johan Åhlén Assistant Manager Database RIPE NCC

5 6

Blocking Access to Personal Data Objects in the RIPE Database
by Denis Walker 28 May '14

28 May '14

Dear colleagues, At RIPE 68, we again raised the issue of how the blocking mechanism works in the RIPE Database. Currently it is all or nothing — if a user queries for too much personal data, we block their access to everything. We often find that this causes issues for legitimate users of the database. This is a recent example of the requests our Customer Services department receives: "This is the outgoing NAT IP for a vast shared hosting cluster. We can't control the type of queries our customers run, there are over 250,000 websites, a tiny fraction might use RIPE but those customers are using RIPE database for a good reason and need to be able to query it. This is why I'm asking for a blanket allow.” Clearly we cannot whitelist any IP address for unlimited access to personal data. However, the option to only block access to personal data objects when the limit is reached would be a great help in these situations. No decision has been made on this issue. We are hoping that it can be further discussed by the community to see if a consensus can be reached. Regards Denis Walker Business Analyst RIPE NCC Database Team

8 7

"AND NOT" in as-expression
by Aris Lambrianidis 27 May '14

27 May '14

Good morning all, After tinkering around with import-via/export-via attributes, I realised that "AND NOT" is not supported in the as-expression part of peering specifications, although it is described in RFC2622 (along with the semantically equivalent EXCEPT) and included in example (6) of page 25. e.g. currently: import: from AS-AMS-IX-PEERS and not AS6777 accept ANY is not supported, while import: from AS-AMS-IX-PEERS except AS6777 accept ANY is. I have raised a ticket with RIPE NCC about it. Also, Job Snijders was kind enough to act quickly and provide patches for both irrtoolset and whois: https://github.com/RIPE-NCC/whois/pull/237 http://irrtoolset.isc.org/ticket/48 Kind regards, Aris Lambrianidis AMS-IX

2 4

Getting: HTTP/1.1 401 UNAUTHORIZED
by Ye, Hong 22 May '14

22 May '14

Hi Gurus, I am new to RIPE API and hope someone can help me get through this. Could some please let me know what is the proper way to use “curl” to get data back from following URL? I could use the same login name/password get in web portal but not from command line. Do I have to encode my logins? Or should I pass my logins as part of the URL parameters? Regards Hong Ye https://atlas.ripe.net/api/v1/measurement/xxxxxxxxxxx/result/?start=1392336… * Adding handle: conn: 0x7f9a74000000 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7f9a74000000) send_pipe: 1, recv_pipe: 0 * About to connect() to atlas.ripe.net port 443 (#0) * Trying 2001:67c:2e8:22::c100:69e... * Connected to atlas.ripe.net (2001:67c:2e8:22::c100:69e) port 443 (#0) * TLS 1.2 connection using TLS_RSA_WITH_AES_256_CBC_SHA256 * Server certificate: *.ripe.net * Server certificate: DigiCert High Assurance CA-3 * Server certificate: DigiCert High Assurance EV Root CA * Server certificate: Baltimore CyberTrust Root > GET /api/v1/measurement/xxxxxxxxxxx/result/?start=1392336000&stop=1392249599&format=json HTTP/1.1 > User-Agent: curl/7.30.0 > Host: atlas.ripe.net > Accept: */* > < HTTP/1.1 401 UNAUTHORIZED < Date: Wed, 21 May 2014 20:14:54 GMT * Server Apache is not blacklisted < Server: Apache < Vary: Cookie < Set-Cookie: atlasessp=3933053c2caeb8d03a3179fa216e0882; Domain=atlas.ripe.net; expires=Wed, 04-Jun-2014 20:14:54 GMT; httponly; Max-Age=1209600; Path=/ < Content-Length: 0 < Connection: close < Content-Type: text/html; charset=utf-8 < * Closing connection 0

2 1

[training] RIPE NCC Webinars - new dates
by Training Services 19 May '14

19 May '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Options for extending "abuse-c:"
by Denis Walker 15 May '14

15 May '14

Dear colleagues, At RIPE 67 in Athens, the RIPE NCC agreed to take another look at the implementation of RIPE Document ripe-563, "Abuse Contact Management in the RIPE Database." Two issues have been identified that are seen to be difficult to handle with the current model - partitioned subnets within one organisation and adding abuse contacts to more specifics for End Users. The RIPE NCC has considered these two issues and found what we believe to be practical solutions, available within the current model. More information about these solutions and the implementation of "abuse-c:" is available on RIPE Labs: https://labs.ripe.net/Members/denis/suggestions-for-improving-abuse-handling This topic will also be raised during the Anti-Abuse Working Group session at RIPE 68 in Warsaw. Regards, Denis Walker Business Analyst RIPE NCC Database Team

5 17