- db-wg - mailman.ripe.net

"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

RIPE68 DB-WG Draft Agenda V3
by Wilfried Woeber 13 May '14

13 May '14

This is the V3 draft of an agenda for the DB-WG Meeting at RIPE68 in Warsaw, scheduled for Wednesday, May 14, 2014. For remote participation see https://ripe68.ripe.net/live/main/ Looking forward to see you tomorrow! Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list B. Data Base Operational Update (Denis Walker, Ed Shryane, RIPE NCC) C. New DB-Software functionality - in test, schduled for deployment (sponsoring LIR) D. Removal of attributes - consensus on removing referral-by:, implementation - consensus on removing changed:, implementation - status and implementation of last-modified - any open issues? E. 2012-07 implementation F. Status update on IETF WEIRDS activities (Ed Shryane, RIPE NCC) G. Personalised Authorisation (Denis Walker, RIPE NCC) Y. Input from other Working Groups and/or Task Forces t.b.c. Z. AOB - removal of geo-location functionality? - removal of white pages service? - creation of a TF for a major review of the DB environment? ________________________________________________________________________ 13.05.2014 13:00 UTC

1 0

[training] RIPE NCC Training Courses July-September 2014
by Training Services 12 May '14

12 May '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 Valencia, Tirana, Vilnius, Budapest, Tel Aviv, Samara, Düsseldorf, Stockholm, Belfast, Amsterdam, Ankara. 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 - Database Training Course - Basic IPv6 Training Course - Routing Security Training Course - 2 day Advanced Training Course - DNSSEC Training Course - Measurements Tools workshop For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Fwd: RIPE68 DB-WG Draft Agenda (interim) V2
by Wilfried Woeber 11 May '14

11 May '14

Sorry for the finger-trouble :-( -ww144 -------- Original Message -------- Subject: RIPE68 DB-WG Draft Agenda (interim) V2 Date: Sun, 11 May 2014 12:34:23 +0200 From: Wilfried Woeber <Woeber(a)CC.UniVie.ac.at> Reply-To: Woeber(a)CC.UniVie.ac.at Organization: UniVie - ACOnet To: db-wg(a)CC.UniVie.ac.at CC: RIPE NCC Meeting Role <meeting(a)ripe.net>, RIPE WG Chairs <wg-chairs(a)ripe.net> This is an (interim) 2nd draft of an agenda for the DB-WG Meeting at RIPE68 in Warsaw, scheduled for Wednesday, May 14, 2014. Please expect anotehr update closer to the WG MEeting Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list B. Data Base Operational Update (Denis Walker, Ed Shryane, RIPE NCC) C. New DB-Software functionality - in test, schduled for deployment (sponsoring LIR) D. Proposals for changes to schema - consensus on removing referral-by:? - discussion changed: vs. last-modified E. 2012-07 implementation F. Status update on IETF WEIRDS activities (Ed Shryane, RIPE NCC) G. Personalised Authorisation (Denis Walker, RIPE NCC) Y. Input from other Working Groups and/or Task Forces - review of abuse contact stuff (N.N. t.b.c.)) Z. AOB ________________________________________________________________________ 11.05.2014 10:30 UTC

1 0

Support for expansion of an origin into a list of prefixes
by Job Snijders 01 May '14

01 May '14

Dear RIPE DB-WG, Much like my previous request regarding server side expansion of objects, I'd very much like the RIPE Database team to implement two flags which IRRd currently supports: !g & !6 I've filed an enhancement request on github: https://github.com/RIPE-NCC/whois/issues/73 The !g and !6 flags signficantly reduce the amount of RPSL interpretation a client has to perform, as the server provides the clients with a straight answer (abeit simplified). If the DB team implements such a feature, I'd also very much like an implementation in context or RDAP so I can query for lists of prefixes through HTTP rather than WHOIS. Kind regards, Job

2 1

RIPE Database Release 1.73
by Denis Walker 29 Apr '14

29 Apr '14

Dear colleagues, The RIPE NCC is pleased to announce the RIPE Database software release 1.73 to the Release Candidate (RC) environment. For information about features, changes and how this release might affect your operations, please see the release notes: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.73 Major features introduced in this release include the: -Addition of a "sponsoring-org:" attribute for End User resources -Addition of a "status:" attribute for all AUT-NUM objects -Change of "status:" values for all legacy (early registration) INETNUM objects to 'LEGACY' This release also fixes a number of issues. More details are available in the release notes. Where necessary, data in the RC Database has been changed to reflect the new/changed attributes. Please check your data and test your implementation in the RC environment. 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 Business Analyst RIPE NCC Database Team

1 0

Proposal: DB object syntax change
by Piotr Strzyzewski 25 Apr '14

25 Apr '14

Dear working group I would like to propose syntax change of the role attribute of the ROLE object in the RIPE DB. Bellow you can find all details. I would like to hear your opinion about this idea and ask for the support to allow RIPE NCC to implement it. ------------- Short description: I would like to propose to change the syntax of the role attribute of the ROLE object from <person-name> to <organisation-name>, where both <person-name> and <organisation-name> are defined in RIPE Database Update Reference Manual. I would like to emphasize that I don't want to change the syntax of the nic-hdl attribute of the ROLE object. Nevertheless, my proposal influence the automatic mechanism of choosing the nic-hdl attribute value of the ROLE object, while it is created with AUTO directive. Rationale: Abuse-c implementation have influenced business procedures of LIRs and have led to increased importance of ROLE object. Since ROLE object is mandatory in the process of proper abuse-c registration, LIRs could be interested in automatic creation of it. Right now, due to its syntax, the role attribute of the ROLE object has number of limitations and cannot accept bunch of characters and or whole labels/words which are natural parts of company names. As an example, it is impossible to create ROLE objects with one of the following role attributes: - Company Father, Son & Daughter Abuse Team - 4U Network Abuse Team - 123 Ltd. Hostmaster - WOW! Network Dept. and so on. Moreover, the original intention was for the ROLE object to represent business roles and not personal data (see: paragraph 1.2.17 of the RIPE Database Update Reference Manual). Taking this into account the <organisation-name> would be the natural choice since it both perfectly solves the problem and is already well defined and implemented. Possible problems: As for now, the nic-hdl attribute of the ROLE object is auto-generated and based on the value of the role attribute. Since <person-name> do not allow all-numeric labels, this mechanism is quite simple. However, similar mechanism exists for the auto-generated organisation attribute of the ORGANISATION object, where <organisation-name> allows this kind of labels. While this is significant change to syntax, I would like to emphasize that <person-name> is a subset of <organisation-name>. This means that even if some people may rely on the current syntax, this change would most probably not influence their procedures. ----------- Best regards, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

7 11