- db-wg - mailman.ripe.net

[training] RIPE NCC Training Courses October-December 2013
by Training Team 22 Aug '13

22 Aug '13

[Apologies for duplicate e-mails] 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 Kiev, Belgrade, Tallinn, Hamburg, Oslo, Paris, Dublin, Vienna, Barcelona, Muscat, Manchester, 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 - Database Training Course (new) - IPv6 for LIRs Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 1

Urgent release of RIPE Database software
by Johan Åhlén 21 Aug '13

21 Aug '13

Dear colleagues, We were recently made aware of some issues with the documentation related to the REST API. To fix these issues requires a new release of the Database software as some parts of the documentation are generated from the active code. The documentation is vital for anyone wanting to use the service. We therefore believe it is necessary to make a new release containing this fix only and deploy it directly to production later today. In this particular case we don’t believe it is necessary to put the release in test beforehand. The only fix is for the documentation and this is preventing users form using the service, so it's quite urgent. This fix should have no impact on any other part of the RIPE Database service. If you have any questions then please let us know. Kind regards, Johan Åhlén Assistant Manager Database RIPE NCC

6 10

[training] RIPE NCC Webinars - new dates
by Training Team 19 Aug '13

19 Aug '13

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 1

More REST API Issues - /create not working
by Tim Garrison 16 Aug '13

16 Aug '13

Greetings again. I almost feel like I'm a pioneer when it comes to using the new REST API at rest.db.ripe.net, as I keep discovering things that don't seem to align with the documentation. That aside, my most recent experience is in regards to the /create method. When using the same payload structure as outlined at https://rest.db.ripe.net/api-doc/path__create.html I receive an HTTP 400 response with the error message as follows: Unrecognized field "whois-resources" (Class net.ripe.db.whois.api.whois.domain.WhoisResources), not marked as ignorable at [Source: org.eclipse.jetty.server.HttpInput@17d9461b; line: 1, column: 21] (through reference chain: net.ripe.db.whois.api.whois.domain.WhoisResources["whois-resources"]) Has the structure of the payloads changed from what is listed in the example JSON request object or is this legitimately a bug? -- Tim Garrison Software Engineer III *SoftLayer, an IBM Company* 315 Capitol Street Suite 205, Houston, TX 77002 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison(a)softlayer.com

2 1

rest.db.ripe.net redirects to balancer://public-ripe/api-doc/
by Tim Garrison 15 Aug '13

15 Aug '13

This seems like a pretty serious issue and I think the subject speaks for itself. However: tgarrison@tgarrison:~$ curl -i https://rest.db.ripe.net/ HTTP/1.1 301 Moved Permanently Date: Wed, 14 Aug 2013 15:00:06 GMT Server: Apache/2.2.15 (CentOS) Location: balancer://public-ripe/api-doc/ Content-Length: 322 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="balancer://public-ripe/api-doc/">here</a>.</p> <hr> <address>Apache/2.2.15 (CentOS) Server at rest.db.ripe.net Port 443</address> </body></html> tgarrison@tgarrison:~$ It would be nice if this could be fixed. Thanks. -- Tim Garrison Software Engineer III *SoftLayer, an IBM Company* 315 Capitol Street Suite 205, Houston, TX 77002 281.714.4213 direct | 713.540.4325 mobile | 281.714.4657 fax | tgarrison(a)softlayer.com

2 4

new "via" attributes in aut-num Class
by Aris Lambrianidis 14 Aug '13

14 Aug '13

> Dear colleagues, > > We received the suggested patch to the RIPE Database software from Job Snijders containing the implementation of the features he describes below. The code he submitted meets the quality standards we have in the Database team and from a technical point of view we are willing to apply the patch. > > If the community supports the addition of the proposed attributes the RIPE NCC can go ahead and merge his implementation and make it available in the next release. > > Kind regards, > > Johan Åhlén > Assistant Manager Database > RIPE NCC > > On 14 Aug 2013, at 15:50, Job Snijders <job.snijders at atrato.com> wrote: > Hello Everybody, I think this is a nice, clean way to work towards ratifying some much needed route servers specific attributes, so this is a +1 from me for the patch to be merged. -- Best regards, Aris Lambrianidis AMS-IX NOC http://www.ams-ix.net/

1 0

new "via" attributes in aut-num Class
by Job Snijders 14 Aug '13

14 Aug '13

Dear working group, As some of you might know I've been working on extending the RPSL syntax to make life easier for certain scenario's, such as operating a Route Server. The purpose of the new attributes and the patch is to make life easier for Route Server operators whom have to deal with participants who have been assigned a 32 bit ASN. There currently is no way to relay information between non-adjacent ASNs, and 32 bit ASNs do not fit into standard BGP communities when coupled with an action code. Often Route server operators overload BGP communities to assess which participant should receive what prefixes, the "via" feature addresses exactly that concern. I have submitted the following draft to the IETF: http://tools.ietf.org/html/draft-snijders-rpsl-via And I have submitted a patch for the RIPE whois server to support the feature. https://github.com/job/whois The extension should be backward compatible with minimal impact on existing tools and processes, following Section 10.2 of RFC2622. RPSL parsers which do not understand the new attributes are expected to just ignore it. I am looking for feedback from this community, and especially the community's blessing to allow RIPE NCC to adopt the patch. Kind regards, Job

2 1

Draft proposal: Guidance Requested: Reassigning Referenced ASNs
by Ingrid Wijte 14 Aug '13

14 Aug '13

Dear colleagues, Thank you for your feedback on this issue. Based on the input we have received we propose taking the following action: - The RIPE NCC will send an email to the maintainer and contacts of the RIPE Database objects in which the returned AS numbers are referenced, asking for the reference to be removed. - The RIPE NCC will send three additional reminders, at intervals of three weeks from each other, for a total of four emails. - If after four emails the reference is still in place, the RIPE NCC will update the RIPE Database object itself, removing the reference. - If the reference is being recreated within one month from deletion (possibly due to automatic updates), the RIPE NCC will contact the organisation through means of communication other than email. The total number of RIPE Database objects that reference returned AS numbers is currently about 2000. All references are in the policy attributes of aut-num objects. No route(6) objects are involved. Thank you again and best regards, Ingrid Wijte RIPE NCC

2 1

New RIPE Database Release Available Soon
by Johan Åhlén 08 Aug '13

08 Aug '13

Dear colleagues, We are pleased to announce that a new release of the RIPE Database will be available soon. Details about the upcoming release, including dates, descriptions of the changes and other factors that might affect you as a user, can be found here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.67… The first new feature is a diff functionality, which allows you to see, in detail, what changes were made between two versions of an object in the RIPE Database. Head over to RIPE Labs to read more about the diff feature: https://labs.ripe.net/Members/denis/diff-functionality-in-the-ripe-database We have also improved the way the Global Resource Service (GRS) data is imported. This allows us to present a more complete data set for all Internet resources throughout the world. This RIPE Labs article will bring you up to speed on the GRS improvements: https://labs.ripe.net/Members/denis/the-ripe-global-resource-service Lastly, we have also made several improvements to the REST API. As there are some changes, the new implementation will be deployed and running in parallel to the old version up until the next release. This provides you with time to verify your software and scripts against the new release. The implications of these changes are described in the release notes linked above. If you have any questions or comments, we look forward to hearing them! Kind regards, Johan Åhlén Assistant Manager Database RIPE NCC

2 2

abuse-c + org
by Gilles Massen 04 Jul '13

04 Jul '13

Dear WG, and RIPE NCC staff, While trying to add an abuse-c to our resources, I was quite surprised that you can only attach the abuse-c to an org object (while the policy suggests otherwise and implementation notes are not very clear on the limitation). So I'd like to ask why this restriction exists? What is wrong with adding an abuse-c directly to an inet[6]num or aut-num? Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

8 15