- db-wg - mailman.ripe.net

[training] RIPE NCC Webinars - new dates
by Training Team 29 Oct '13

29 Oct '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 0

Support for recursive expansion of as-set to a list of ASNs
by Job Snijders 21 Oct '13

21 Oct '13

Dear DB-WG, Now that the new database backend is in place, this should allow for awesome features such as server sided recursion of AS-SETs into a list of ASNs. Implementing IRRd's !i flag will prevent a lot of back and forth communication between whois server and client to provide the client with a full list of ASNs which are part of an AS-SET. Clients such as bgpq3 support this flag. I've filed an enhancement request on github: https://github.com/RIPE-NCC/whois/issues/72 But we could use this thread to assess community support and gather a sense of priority. Kind regards, Job

3 2

abuse-c + org / inetnum
by Gilles Massen 19 Oct '13

19 Oct '13

Dear WGs, In the light of the upcoming RIPE meeting I'd like to bring the problem of a single entity (organisation) wanting different abuse-c for different resources up again. The discussion starting in June (http://www.ripe.net/ripe/mail/archives/db-wg/2013-June/004079.html ) was rather open ended. Apparently the only workable solution at this point is to create a duplicate organisation object with a different abuse-c. Is data duplication really the solution that the WGs would like? Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

6 6

Route Polict Verification
by Alexander Azimov 17 Oct '13

17 Oct '13

Dear colleagues, During current RIPE meeting I have presented my report about verification of route policy from registries with deeper analysis for RIPE database. I analysed the customer to provider relations because of its global visibility. The result are fearful: 60% of link completeness, less than half of this amount have information about Pref values and again most of pref values have errors. As a result there is only 10% likelihood to find real priorities using this dataset. The community must decide how to change this situation. In my opinion there are only two ways to overcome this problem: verify this data or delete at all. All our data is available on our website <http://radar.qrator.net>. The collected data is based on imitation mathematical model with use of AS paths recovered from BGP views and novel active verification abilities that could detect priorities on every level of BGP decision making process. We are eager for collaboration and eager to help RIPE Stats or RIPE DB to verify policy data, highlight errors and give other aggregated data if community decides that it is needed. -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa(a)highloadlab.com | visit: www.qrator.net

4 6

Korrektion: RIPE67 DB-WG Draft Agenda V2
by Wilfried Woeber 16 Oct '13

16 Oct '13

..."of course" I go it wrong, my sincere apologies: [1] for remote participation: this is *08:00 UTC* Oh my, blush, Wilfried

1 0

RIPE67 DB-WG Draft Agenda V2
by Wilfried Woeber 16 Oct '13

16 Oct '13

Dear DB-WG folks, Chairpersons, "Meeting"! This is the 2nd draft of an agenda for the DB-WG Meeting at RIPE67 in Athens, scheduled for October 17, 2013. For time slot allocations please refer to the most up-to-date meeting plan at https://ripe67.ripe.net/programme/meeting-plan/ The DB-WG Meeting is scheduled for *Thursday*, starting at 11:00 local time[1] in the morning. The length of our timeslot is 90 Minutes. The overall (draft) RIPE 67 meeting outline is already available at https://ripe67.ripe.net/programme/meeting-plan/ Changes from V1: - the separate items pertaining to the DataBase are lumped together - a new item on GeoLoc Data Management Please feel free to propose additional topics to be discussed! I'd also suggest that you submit your points of view regarding the topics on the proposed agenda on the mailing list, preferably before the WG meeting's start :-) Best regards, hope to see you soon in Athens, Wilfried. [1] for remote participation: this 09:00 UTC ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list B. Data Base Update (Denis.W., Johan.Å., RIPE NCC) - operational report - software release management and TEST DB - things "in the pipe" - WEIRDS C. UTF-8 transparency in the Registry - functionality and/or restrictions by components - policy or business logic interactions, - coordination /input with/from other WGs D. Common Format for GeoLoc data (Zoltan Sz., Google) Y. Input from other Working Groups and/or Task Forces - review of abuse contact stuff (N.N. t.b.c.)) Z. AOB ________________________________________________________________________ 16.10.2013 11:20 UTC

1 0

[training] RIPE NCC Webinars - new dates
by Training Team 15 Oct '13

15 Oct '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://lirportal.ripe.net/training/courses 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

Improvements to RIPE Database Software Release Management
by Johan Åhlén 10 Oct '13

10 Oct '13

Dear colleagues, Following recent discussion regarding the release management of the RIPE Database software, we looked closely at our procedures and would like to propose some improvements. Together with the Database Working Group chairs, we've scheduled an informal meeting during RIPE 67, open for anyone that is interested in this topic, to discuss the proposals and talk about how we can improve our procedures. The meeting will take place on Monday, 14 October from 18:00-19:00 in room Sigma + Theta. We hope you will join us. Of course, you can also send your feedback and suggestions to this list. This is what we propose: - Split the RIPE Database software into smaller modules. Modularisation would minimise the release frequency for our services. For instance, with a modern API like RDAP we might have bi-weekly major releases and weekly minor releases to quickly respond to changes in the specification. With the NRTM feed, there might be just one major release per year or even less. - Replace the "emergency release" with a "minor release" that only contains patches for operational purposes and bug fixes. No new functionality would be introduced and no feature changes. We would also have "major releases" where functionality is added, changed or removed. With major releases we would keep the minimum two-week user test period leading up to the production release as stated in the previously proposed release procedure. With any minor release, we would put it in production as soon as it's available. Most bugs affect some users. Rather than trying to determine urgency based on numbers of users, size of users, number of networks affected, importance of functionality affected, etc., we would treat all bugs the same. In short, if someone reports an issue to us, we fix it right away. This process has generally worked well over recent years. - Improve the test environment. We know that users would like to have their real data to do proper testing. To solve this issue, we propose to use snapshots of the current database for this purpose. - Improve communication surrounding new releases. This covers all documentation and how we inform users about changes. We hope that you find this way forward beneficial. Kind regards, Johan Åhlén Assistant Manager Database RIPE NCC

2 2

Syntax Change to Aut-num Object in the RIPE Database
by Denis Walker 09 Oct '13

09 Oct '13

Dear colleagues, We would like to give you a heads-up about a proposal, currently being considered, to add two new attributes to the aut-num object in the RIPE Database: "import-via:" and "export-via:". In this email we are not concerned with the details of this specific change so much as the fact that a change is being considered. We know that these objects are very important for routing and many of them are updated daily in the RIPE Database. We also know that many scripts exist for auto-generating these objects and processing the contents. Although the RFC for RPSL clearly states that scripts should be written to ignore attributes they don't recognise, we don't know if all scripts are written this way. The RIPE NCC is considering the best ways to get information about any changes to routing object syntax in the RIPE Database out to the people who need to know. We would welcome any feedback on this issue from the community. Regards, Denis Walker Business Analyst RIPE NCC Database Team

1 0

Re: [db-wg] new "via" attributes in aut-num Class
by Erik Bais 09 Oct '13

09 Oct '13

Hi Job & Johan, I think the implementation makes sense and my compliments on the draft. It looks good: > http://tools.ietf.org/html/draft-snijders-rpsl-via Is this already in the new db version or is this still waiting for more community support ? For me, support +1. Kind regards, Erik Bais A2B Internet > > 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