- db-wg - mailman.ripe.net

New Procedure for RIPE Database Software Releases
by Johan Åhlén 28 Jun '13

28 Jun '13

Dear colleagues, We have recently received valuable input on how we can improve our release procedures for the RIPE Database software. In order to further reinforce our processes, we have defined a new procedure together with the Database Working Group (WG) Chairs that will address the concerns that have been raised about the stability of the Database software by the community. The purpose of the new procedure is to give you notice of what the next release will contain and how it might affect you as a user. No matter what the impact of a new feature is, an announcement will always precede the deployment to production and you will be given sufficient time to test your software. The procedure is not too far from how we have been working up until now, but will be more strictly defined and will hopefully eliminate any surprises. We propose to proceed as follows: - We will move to a four to six week release cycle for the Database software - There will be no more than three new features per release - Each new release will be announced to the WG mailing list at least two weeks before we deploy to production - In the event that we are required to deviate from what was stated in the announcement, we will announce this to the WG mailing list - The new release will be available in Test Database at least two weeks before we deploy to production - We will announce to the WG mailing list when we have successfully completed deployments to Test Database - We will announce to the WG mailing list when we have successfully completed deployments to Production Database - In the special case of required emergency fixes, we will announce this to the WG mailing list as well as the website as soon as possible - We will make a follow-up announcement to the WG mailing list and the website as soon as a fixed version has been deployed - These two emergency announcements can be combined for security reasons, or if the problem is solved in less than 30 minutes For the initial release announcements, the following template will be used: Release number Expected date of deployment to Test Database Expected date of deployment to Production Database New features Impact on existing functionality Operational improvements Impact on existing functionality Fixed bugs Impact on existing functionality Expected upcoming features for next release We hope that you will find this procedure beneficial and with your consent we would like to move ahead with it effective immediately. We also intend to publish this procedure to the website together with a roadmap of what we expect that the upcoming releases will contain. Kind regards, Johan Åhlén Assistant Manager Database RIPE NCC

1 0

DB Software - release and deployment improvements
by Wilfried Woeber 28 Jun '13

28 Jun '13

Dear DB-WG, NCC-Services and Routing WG Community! Over the recent month or so, a deployment of a new version of the DB-SW, to the production environment, turned out to (potentially) have serious impact on automated router configurations in (an) operator's network(s). The issue was reported to the NCC's DB-WG Group and the specific problem has already been fixed (actually on the same day as reported). Here's the link to the service announcement page: http://www.ripe.net/lir-services/service-announcements/ripe-database-query-… However, as the incident seemes serious enough, a small group of interested people (Rüdiger, Nigel Titley, folks from the NCC and myself) started to dig a bit deeper, into what was (and is) perceived to be aspects that need review, more transparency and maybe improvement. We plan to look at some aspects, amongste others, like: - better communication regarding upcoming new SW releases - better transparency when and where (TEST DB, Production DB,...) new software will be deployed - version control and documentation But the most important thing is an improved and more transparent process to deploy new software versions *as soon as possible*! Then we can take it from there... While this message is also sent to the NCC Services and Routing WG, fyi, I'd like to suggest to have follow-up comments and discussion on the DB-WG List! Looking forward to fruitful discussions, best regards, Wilfried

1 0

Re: [db-wg] [address-policy-wg] Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects
by Emilio Madaio 26 Jun '13

26 Jun '13

Dear Peter, thank you very much for your input and remark. I apologize if I forgot to include the IPv6 and Database WG mailing lists as decided during RIPE 66 on request of the community. I slavishly followed the procedure defined by the Cosmetic Surgery Project that was meant for the Address Policy WG mailing list only. The original announcement for the extended Review Phase is available at: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-June/007931.h… For further feedback the draft of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… Please send your feedback on this draft document before 9 July 2013. Best Regards Emilio Madaio Policy Development Officer RIPE NCC On 6/25/13 5:51 PM, Peter Koch wrote: > On Tue, Jun 25, 2013 at 03:29:45PM +0200, Emilio Madaio wrote: > >> https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… > > May I express some doubts about the 'cosmetic surgery project'? > The project was introduced as early as October 2009 and RIPE 513 was published > in February 2011. What appears to happen is a very late post publication copy > editing. In this particular case, the policy itself is a change to the > database attributes and - other than, say, address allocation/assignment > policies - not very likely read its own. Any structural changes > to the document (where's the template, by the way?) and changes to style > (passive voice here and there) or readability might better be invested > in the general database documentation. > > The new draft eliminates the data protection aspect from the > introduction/motivation section, which I consider a loss. The abstract > wins, though. The draft continues to use 2000::/46 for the example > where some chunk of 2001:DB8::/32 as per RFC 3849 might be a better choice. > > -Peter >

1 0

Guidance Requested: Reassigning Referenced ASNs
by Andrea Cima 25 Jun '13

25 Jun '13

[Apologies for duplicates] Dear colleagues, At the Address Policy WG session during RIPE 66, the RIPE NCC requested guidance from the RIPE community on reassigning referenced 16-bit ASNs. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the RIPE NCC has around 1,400 returned 16-bit ASNs that are currently referenced in route objects, and "import" and "export" lines in aut-num objects. Problem: there is a need for 16-bit ASNs by operators. However, because these ASNs are referenced, they are not being reassigned. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf This email has been sent to both the Address Policy WG and RIPE Database WG mailing lists, due to the impact the proposals would have on the RIPE Database. However, we would ask to keep the discussion on the Address Policy WG mailing list to facilitate participation and the channeling of feedback. Thank you in advance for your input and best regards, Andrea Cima RIPE NCC

2 1

Object Tags in the RIPE Database
by Johan Åhlén 19 Jun '13

19 Jun '13

Dear colleagues, The recent RIPE Database software rewrite has enabled us to offer new and valuable functionality to the community with minimal effort. One of these features is the Object Tags functionality, initially introduced by Kaveh Ranjbar at RIPE 66 and since then communicated to the community and the Database Working Group Chairs. We are now happy to announce that the Object Tags feature is fully deployed. Object Tags is publicly visible metadata related to an object in the RIPE Database. The tags do not appear by default and users can enable them by supplying the --show-tag-info option. The tags will appear in the comment section and it does not change the default behaviour of your queries. The main goal of the tags is to improve the data quality in the RIPE Database by, for example, better notifying users of potential issues with an object. As a secondary benefit, query results can now be filtered based on tags, making it easier for users to find exactly what they need. The RIPE NCC will maintain a list of the available tags on a webpage referenced in the Help section and in related documentation. Currently, there are two types of tags: - Objects due to be deleted by the automated clean-up are tagged: Unreferenced # will be deleted in n days - All RIPE and GRS resource data is tagged with either: {SOURCE}-REGISTRY-RESOURCE or {SOURCE}-USER-RESOURCE For more information and examples of how the new feature can be used, I'd like to refer you to Kaveh's RIPE Labs article at: https://labs.ripe.net/Members/kranjbar/ripe-database-object-tags We hope that you can come up with creative ways of using this functionality. We are eager to hear how you use this feature and what we can do to make it better. I would also like to take this opportunity to introduce myself as not everyone here knows who I am. My name is Johan Åhlén and I'm the new Assistant Database Team Manager at the RIPE NCC. I'm taking over Kaveh's role of managing the Database Team as Kaveh has accepted the new position of Head of Science Division. Before managing the Database Team, I worked as a Senior Software Engineer in the Business Applications Department where I was involved in the development of both internal and external RIPE NCC applications. I look forward to working with you all. Kind regards, Johan Åhlén Assistant Database Team Manager RIPE NCC

1 0

Historical data in ripe-db. whois with "--list-versions"
by Bengt Gördén 17 Jun '13

17 Jun '13

Hi, I've been using this service and I like it. But I ran into a problem, I think. I'm trying to see the history for 194.228.90.192/26. whois -h whois.ripe.net 194.228.90.192/26 <-------- Works. I get an inetnum for the network whois -h whois.ripe.net -- "--list-versions 194.228.90.192/26" <--------- Doesn't work. Provides no revision list whois -h whois.ripe.net 194.228.0.0/16 <-------- Works. I get an inetnum for the network whois -h whois.ripe.net -- "--list-versions 194.228.0.0/16" <--------- Works. Gives revision list Am I doing something wrong here? I suspect that the /26 inetnum hasn't changed since 2002 but shouldn't there be at least a rev. 1 for it? Or is it as it says in the proposal "there might have been cases were some changes are missing in the history, mainly for technical reasons"? regards, /bengan

2 2

API - INET6NUM Object Creation Bug
by Tim Garrison 10 Jun '13

10 Jun '13

Greetings, I have understood that doing an HTTP POST to https://apps.db.ripe.net/whois/create will respond with an HTTP201 status code and a 'Location' header pointing to the created object. This seems to work great for 'inetnum' and 'person' objects, but I've discovered that for 'inet6num' objects, the parent network block's handle is used in this header. This is creating problems for me in my current project, and I was wondering if someone could possibly take a look. Thanks! -- Tim Garrison Software Engineer II tgarrison(a)softlayer.com 281.714.4213 Direct 713.540.4325 Cell 866.398.7638 Toll-Free 281.714.4657 Fax SoftLayer Technologies, Inc. 315 Capitol Street Suite 205 Houston, TX 77002 http://www.softlayer.com/

2 2

[Training] New E-Learning Videos: Role Object and Abuse-C Set up
by Sandra Bras 10 Jun '13

10 Jun '13

[Apologies for duplicates] Dear colleagues, We are pleased to announce the launch of two new RIPE Database videos as part of our online training. The topics are: - Create a Role Object https://www.ripe.net/lir-services/training/e-learning/ripe-database/contact… - Set up Abuse Contact Information https://www.ripe.net/lir-services/training/e-learning/ripe-database/contact… For more videos go to https://www.ripe.net/lir-services/training/e-learning. Stay tuned! We plan to announce more exciting E-Learning news in the coming months. RIPE NCC E-Learning Tutorials are a free service available to everyone. If you have any questions or comments, feel free to contact us at <e-learning(a)ripe.net>. Happy learning! Sandra Brás E-Learning Project Manager

1 0

[training] RIPE NCC Training Courses July-September 2013
by Training Team 27 May '13

27 May '13

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 Rome, Chisinau, Munich, Moscow, Prague, London, Ljubljana, Yerevan, Malmö, Istanbul, 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 0

Reminder:Cosmetic Surgery Project, new revised RIPE Policy, document for IPv6 database objects
by Emilio Madaio 21 May '13

21 May '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". At the request of the proposers of the original policy proposal that produced ripe-513, we’re sending a reminder about the document review and inviting the IPv6 Working Group Mailing List and Database Working Group Mailing List subscribers to participate in the review process. A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… We encourage you to read the edited draft of ripe-513 and send any comments to <address-policy-wg at ripe.net> by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0