- db-wg - mailman.ripe.net

abuse-c: important points on it's usage
by denis 13 Jan '16

13 Jan '16

HI All I make no apologies for the length of this email, but I would ask anyone concerned with abuse handling, RIPE Database data management and RIPE Database maintenance to read it. I am not trying to be a perfectionist or technical purist, but the changes being forced through now do matter. cheers denis When "abuse-c:" was first proposed, Tobias (co-chair of Anti Abuse WG) and I spent a lot of time discussing how to achieve the intended goal. We came up with the current implementation, which after community discussion was approved. But you never think of everything in the first instance. I believe there is one piece missing that allows the whole system to be broken (see later). I also believe the changes being made (without proper discussion) by the RIPE NCC's 'improvements' to Webupdates will break the abuse-c system over time. As a separate issue, but related to this, I think the RIPE NCC should give advance notice to the community of changes to interfaces like Webupdates and allow some discussion on significant changes like ORGANISATION object creation and authorisation and not just 'slip them in', then try to justify them when someone notices. These are major changes to the way the RIPE Database works. They are not just changing the look and feel of Webupdates as an interface tool. So lets start with some history. The goal of "abuse-c:" When the data model was designed there was no thought given to abuse contacts. The internet was much smaller and more personal. The data model was built on the principle of human readability and not programatic parsing. So when the need for abuse reporting was first considered necessary it was good enough to add things like: remarks: In case of abuse contact me(a)here.com You could put this anywhere and someone would find it. Then it got a bit more formal and we introduced the "abuse-mailbox:" attribute. But this was allowed in five or six object types. None of these were the resource objects. So the information was scattered all over the database. This was still almost impossible to find programatically. The goal of "abuse-c:" was: -to have one way of documenting abuse contact details -parsable programatically -very simple for majority of resources -flexible for any other resource situation The "abuse-c:" design Tobias and I considered many options to achieve these goals. What we focussed in on was that most small to medium LIRs may have many resources but only one person/role handling abuse complaints. All these resource objects in the database referenced their one ORGANISATION object. So by adding the "abuse-c:" attribute to the one ORGANISATION object, referencing a ROLE object containing the contact details, we handled a large number of simple cases in a very simple way. All the resources referencing this one ORGANISATION object and all the more specific resources would inherit this contact information from this one location. Easy to set up, easy to maintain. But there are other situations. For example sub allocations. We also considered that accountability is an important element of this public registry database. There is a notion that when a resource is allocated or assigned by the RIPE NCC to an organisation, then that organisation is ultimately responsible for anything that happens regarding that resource. This is why ORGANISATION objects are mandatory for any organisation that wants to hold internet resources. So we considered that if part of the responsibility has been delegated to another organisation with a sub allocation, it is not unreasonable that another ORGANISATION object should be created to reflect this delegated responsibility. If this second organisation handles the abuse reporting for this sub allocation, then another "abuse-c:" attribute can be added to their ORGANISATION object to reflect this. If the LIR who is responsible for this allocation, including the sub allocation, wants to handle all abuse reports for the whole of their allocation then no "abuse-c:" should be added to the second ORGANISATION object. The sub allocation will then continue to inherit the abuse contact details of the LIR who holds the whole resource. Inheritance vs Scattering The data model for the RIPE Database was not designed with inheritance in mind. In many situations duplicated, redundant data is scattered all over the database. There are over 3 million INETNUM objects in the database. They all contain one or more "admin-c:" and "tech-c:" attributes. In reality all these references are to a few tens of thousands of individual roles. These contacts could be inherited from the ORGANISATION objects in the way "abuse-c:" has been set up. The "abuse-c:" was designed to be inherited and not to be duplicated where it is not needed. The changes made recently to Webupdates by the RIPE NCC (without any discussion) breaks the inheritance of "abuse-c:". It forces the scattering of more redundant data throughout the database. If you create an ORGANISATION object with Webupdates it forces the addition of an "abuse-c:" attribute whether it is needed or not. They argue that you can refer to an existing ROLE object making it the same abuse contact. Even if this was set up correctly it is redundant data. In reality people setting this up quickly will just take the easy option of giving any email address (mickey(a)mouse.com). They may not realise the impact of this. But this simple mistake overrides the LIRs genuine abuse contact details from any point in a network where this new ORGANISATION object is referenced. Understanding your network and the RIPE Database What it comes down to is that you should understand how your network is structured. You should at least know who needs to be contacted, for what reason, from which point in your network. Unfortunately with the current data model you also need to have at least a basic understanding of how the data is structured within the RIPE Database. And to be honest if you don't understand the basic structure of the RIPE Database you should not be managing data in it, maintaining it or documenting it. With knowledge of your network and the database you can decide where you need to put "abuse-c:" attributes. DO NOT add extra, redundant "abuse-c:" attributes. What can possibly go wrong? In defence of their unannounced changes to Webupdates, the RIPE NCC has argued that adding additional "abuse-c:" attributes is harmless and will NOT lead to bad data in the database. Forcing users to add additional, redundant data that breaks the principle of inheritance is in itself technically wrong. But without being a technical purist what else can go wrong? Once these additional references have been added, the seeds have been sown for future mistakes. It all depends now on who maintains what and who is notified of what changes. The referenced ROLE object can be changed or the "abuse-mailbox:" value in the ROLE object can be changed. This could be accidental or with good intent, but just got it wrong or even maliciously. Without the proper checks this can easily go unnoticed. Over time some/many of these redundant references may/will get out of sync with what they should refer to. In a few years time someone will argue that all this contact data is messed up, abuse-c did not work and we will invent a new system... The missing bit The "abuse-c:" attribute does work and will work well if used properly. But there is one bit missing from the original design....proper notifications. We need another attribute adding to the ORGANISATION object abuse-notif: [required] [multiple] [] This will allow the resource holder to keep an audit trail of any changes made to the abuse contact details for any parts of their resources. The 'required' (as defined in the database documentation) means it is syntactically optional, but business rules enforce it's presence in some situations. This should be added to any ORGANISATION object referenced by a resource object. Any addition, change or deletion of any part of the abuse contact details ("abuse-c: attribute, referenced ROLE object, "abuse-mailbox:" attribute) at any part of a network will be notified to the resource holder's email address specified in this attribute. Only the "abuse-notif:" referenced via the top level of a resource object will be notified. Any redundant references in more specific objects will be ignored (and should be removed, warned or disallowed). This means the resource holder will always be notified if anything is changed at any point in the resources/networks they are responsible for. I also think it would be useful if RIPEstat could give a visual representation of where abuse contacts are located within a network. This would allow a resource holder to review who is managing abuse for any part of their networks.

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 13 Jan '16

13 Jan '16

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

Meanwhile, at ICANN...
by Shane Kerr 06 Jan '16

06 Jan '16

All, Not necessarily RIPE Database related, but I thought I'd point out that ICANN is considering replacing WHOIS for gTLD: https://www.icann.org/news/announcement-2016-01-04-en Cheers, -- Shane

3 2

Release 1.84 deployed to RC
by Tim Bruijnzeels 09 Dec '15

09 Dec '15

Dear working group, We have deployed release 1.84 to RC. This release was necessary to prepare for hardware upgrades of the whois infrastructure. Note that this release does not include the work for deprecating "changed:". This work will be part of release 1.85 that we plan to deploy to RC on 21 December, and to production on 1 February 2016. We needed to give precedence to this release, so that we will be able to upgrade the server infrastructure in January, while the release for "changed:" is still being evaluated in RC. Even though we plan to deploy 1.85 to RC on 21 December, we will only upgrade the server hardware and move to 1.84 in production in January. This upgrade does not include any API changes, however the hardware upgrade itself will involve a short outage of the RIPE DB updates. We want to do this operation after the end of year holidays when we are fully staffed, and will communicate a more detailed plan closer to the date. Please let us know if you have any concerns, comments or questions. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

[training] RIPE NCC Training Courses January-March 2016
by Training Services 07 Dec '15

07 Dec '15

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 Amsterdam, London, Toulouse, Prague, Baku, St. Petersburg, Helsinki, Vilnius, Chisinau, Bishkek. 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 - RIPE Database Training Course - Basic IPv6 Training Course - DNSSEC Training Course - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

anyone using the RIPE Databse MUST now have an SSO account?
by ripedenis＠yahoo.co.uk 02 Dec '15

02 Dec '15

Hi guys When was it discussed, agreed or announced that Webupdates will no longer allow objects to be created or updated with a password? As Webupdates is the only way to access an unfiltered version of your own MNTNER object, it is no longer possible to even retrieve a version of your own MNTNER without signing up for an SSO account. I did not realise this has become mandatory. So has it been agreed that SSO is the only authorisation method allowed to access the RIPE Database? Did I miss the announcement that passwords and PGP are being deprecated? cheersdenis

6 6

revisiting rpsl-related set of rcf documents?
by Wilfried Woeber 26 Nov '15

26 Nov '15

Following up on the discussion here, during the DB-WG session in Bucharest, where changes to different aspects of using the RIPE registry database - including a reference to discussions relating to cross-RIR authorisation - I'd like to ask the following question to the community: Is it about time to revisit the set of RFCs and either get them updated to properly reflect the (more) current reality, or consciously have them declared historic and overtaken by events? What's your point of view? Thanks, Wilfried

6 7

RIPE TEST DATABASE REST INTERFACE PROBLEM
by PRANEETH, MANASVI 25 Nov '15

25 Nov '15

Hi, I have created a maintainer EIPAM-MNT for testing the ripe rest in Test system. But looks like the query/update function is not working through rest Interface. Can you confirm whether the RIPE REST is working for TEST database. [cid:image001.png@01D125DE.B2187610] Request sent: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <whois-resources> <objects> <object type="INET6NUM"> <source id="TEST"/> <attributes> <attribute name="inet6num" value="2001:1be0:1000:1e::/64"/> <attribute name="netname" value="EIPAMGUYATT"/> <attribute name="descr" value="EIPAMGUYATT"/> <attribute name="country" value="US"/> <attribute name="admin-c" value="EP1-TEST"/> <attribute name="tech-c" value="EP1-TEST"/> <attribute name="status" value="ASSIGNED"/> <attribute name="mnt-by" value="EIPAM-MNT"/> <attribute name="mnt-lower" value="TEST-DBM-MNT"/> <attribute name="source" value="TEST"/> </attributes> </object> </objects> </whois-resources> Response received: Errormessage part: <errormessages> <errormessage severity="Error" text="Authorisation for [%s] %s failed using "%s:" no valid maintainer found "> <args value="inet6num"/> <args value="2001:1be0:1000:1e::/64"/> <args value="mnt-by"/> <args value=""/> </errormessage> <errormessage severity="Error" text="The maintainer '%s' was not found in the database"> <args value="EIPAM-MNT"/> </errormessage> <errormessage severity="Error" text="Unknown object referenced %s"> <attribute name="tech-c" value="EP1-TEST"/> <args value="EP1-TEST"/> </errormessage> <errormessage severity="Error" text="Unknown object referenced %s"> <attribute name="mnt-by" value="EIPAM-MNT"/> <args value="EIPAM-MNT"/> </errormessage> <errormessage severity="Error" text="Unknown object referenced %s"> <attribute name="admin-c" value="EP1-TEST"/> <args value="EP1-TEST"/> </errormessage> <errormessage severity="Info" text="To create the first person/mntner pair of objects for an organisation see https://apps.db.ripe.net/startup/"/<https://apps.db.ripe.net/startup/%22/>> </errormessages> Thanks, Manasvi praneeth Nannapaneni INSTAR-EIPAM Development/office:(636) 544-5448/mp418b(a)att.com<mailto:(636)%20544-5448/mp418b@att.com>

2 2

Database release 1.83 deployed to RC environment
by Alex Band 24 Nov '15

24 Nov '15

Dear colleagues, We are happy to announce the deployment of RIPE Database software release 1.83 to the Release Candidate (RC) environment, which has gone live on Friday 30 October. This release is still focussed on seamlessly integrating RIPE NCC Access (SSO) into the webupdates user interface. In addition, several other changes have been made, such as: - Webupdates will show full object details by default - Partial route object creation has been greatly improved, indicating which maintainer needs to complete the authorisation - When deleting a person object, you will be prompted to also delete the associated maintainer if it has no other dependencies - When trying to delete an object that is still referenced, you will get a list of blocking objects - Auto-complete of person, role and organisation attributes is now available throughout the interface - The TEST database now has its own URL instead of having to be selected with a radio button Please let us know if you have any questions or comments. Kind regards, Alex Band Product Manager RIPE NCC

3 4

RIPE 72 minutes
by Nigel Titley 19 Nov '15

19 Nov '15

Folks Here is the first cut at the minutes. Comments (and particularly complaints about missing/additional action points) to me All the best Nigel

1 0

RIPE 71 DB-WG agenda V4
by Piotr Strzyzewski 19 Nov '15

19 Nov '15

Dear DB-WG Members This is the 4th draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Although the agenda is fully packed right now, please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. Database Updates (Tim Bruijnzeels, RIPE NCC) [~30 min] . operations . new functionality . "changed:" deprecation . Implementation proposal descr line . restrict usage of RIPE-NCC-RPSL-MNT . other aspects . personalised authentication C. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] D. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] E. Afrinic IRR (Michel Odou) [~10 min] Afrinic IRR homing project update (Tim Bruijnzeels, RIPE NCC) [~10 min] F. ROUTE object authorisation update (Job Snijders) [~5 min] G. Control over associating objects for number blocks (William Sylvester) [~5 min] X. Heads up about recent discussions at db-wg mailing list Y. Input from other Working Groups and/or Task Forces Z. AOB __________________________________________ -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Bootstraping a new private whois instance
by CUBIC, SCOTT 18 Nov '15

18 Nov '15

Hi all, I'm new to the db-wg, and I'm just beginning to explore the code from https://github.com/RIPE-NCC/whois.git. I'd like to use the code to run a private whois server to integrate with our Infoblox IPAM system. I've cloned the repository and followed the instructions posted at https://github.com/RIPE-NCC/whois/wiki/Installation-instructions . The instructions, however, don't include any details on 'priming' the whois database - using the SQL from the whois-commons/target/classes/<database>_schema.sql files, I get all my databases and tables created, but there is no data in the tables. I'm assuming that I need to have at least a 'mntner' in the WHOIS_LOCAL/mntner table, and I added a single entry manually with an object_id of 0, but I still can't seem to use any update method (synchupdates, REST, etc.) to add new information to the database. Would it be possible to get a push in the right direction for manually populating the WHOIS database with enough stuff (user IDs, passwords, etc.) to begin using the APIs to modify the database? Regards, Scott Cubic cubic(a)att.com<mailto:cubic@att.com>

2 1

Control over associating objects for number blocks
by William Sylvester 18 Nov '15

18 Nov '15

Dear Database Working Group Members, At the last RIPE meeting we discussed the topic of orphaned objects, and it seems that this term was confusing to some. This is an attempt to clarify the problem and hopefully find a solution forward. This continues to be a problem where number block holders are getting “locked” out of being able to manage their routing objects and in-addr records. Today, we continue to have a problem where a block holder does not have an ability to manage the objects that operationally impact their number blocks. Examples include a routing or reverse dns object that exist in the database but are not currently maintained by an active number block maintainer. This is typically the case where a number block holder (usually legacy) may have contracted services through a third party. Time goes by, the business relationship ends but the third party never removed their associated records (in-addrs, routing objects, etc). The number block holder now seeks to update the block (either directly or through a new service provider) and is unable to add these resource records to their number block. The database can help fix this problem through allowing the appropriate control for a number block holder to maintain their own information. In many cases the last resort is to contact RIPE NCC to make the change to an object the number block holder should have had online access to manage directly in the first place. This proposal intends to enable number block holders to have a greater ability to manage their own resources. I propose that the maintainer of a number block shall have full control over the association of contacts, routing, and reverse dns entries related to the number block held. The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block. The number block maintainer shall have an ability to delete the relationship between a related object and the number block through the LIR Portal, Webupdates, and related systems. Open items to discuss; 1) What is the best method to enable a number block holder to manage and control objects associated with their blocks in Ripe DB? 2) Should any objects be excluded from this control? 3) What is a reasonable schedule for announcements and implementation? Thank you for your consideration and I look forward to your comments. Billy William Sylvester william.sylvester(a)addrex.net<mailto:william.sylvester@addrex.net>

5 12

Solving the issue of rogue ROUTE objects in the RIPE Database
by denis 14 Nov '15

14 Nov '15

Hi All I raised an idea before the last RIPE Meeting but it did not generate a lot of interest at that time. I brought it up again yesterday on the Anti Abuse WG list and it seemed to get quite a bit of support. So I will bring it back to the DB WG as it is a DB issue. I have CC'ed both AA WG and Routing WG for information. But it may be useful to keep the discussion now on the DB WG list. I don't claim this will solve all the problems of the universe, but it does satisfy an immediate goal to have all ROUTE objects in the RIPE Database created with the knowledge and approval of the related resource holders. And I believe it could be implemented in a relatively short space of time giving immediate benefits. cheers denis STEP 1 Any ROUTE object submitted for creation in the RIPE Database involving an out of region resource (address space and/or ASN) where that out of region resource does not exist in the authoritative RIR database (has not been allocated or assigned), reject the creation. The RIPE NCC mirrors the operational data from all the other 4 RIRs. These mirrors are updated daily as well as the RIRs daily stats. It is easy to determine if a resource is registered in the authoritative database. STEP 2 For those ROUTE objects from STEP 1 where the out of region resource does exist, hold the object creation as pending. The mechanism for doing this already exists in the RIPE Database software as it is used for multiple authentications. Lookup the out of region resource(s) in the authoritative database(s) and find the contacts for that resource. Send a notification to those contacts informing them of the pending ROUTE object creation in the RIPE Database. The notification mechanism already exists in the RIPE Database software. If they don't approve, do nothing and the creation request will time out after a week and the object will not be created. If they do approve, respond in some way (many technical options for doing this that the RIPE NCC can choose from). If appropriate approval(s) are received within a week, create the ROUTE object. STEP 3 On a daily basis, for each ROUTE object in the RIPE Database that relates to an out of region resource, check for the continued existence of that resource in the appropriate RIR database. If it no longer exists, delete the ROUTE object from the RIPE Database. STEP 4 This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received, delete the ROUTE object from the RIPE Database. We can be a bit more generous on the timing for this step and even send multiple reminder notifications to be sure. (Possible) STEP 5 If a delete request is sent to the RIPE Database for a ROUTE object related to out of region address space without the proper authorisation, send a notification to the contacts for the authoritative address space holder. If an appropriate response is received back, delete the ROUTE object. This would simulate the reclaim functionality for RIPE address space holders. AUT-NUM copies Another byproduct of implementing this is that we no longer need to hold copies of AUT-NUM objects in the RIPE Database. The out of region ASN auth requirement is satisfied by the appropriate response to the notification. So all 'foreign' AUT-NUM objects could be immediately deleted. (Or after allowing time for these ASN holders to make sure their routing policy is actually up to date in the authoritative AUT-NUM object.)

10 25

RIPE 71 DB-WG agenda V3
by Piotr Strzyzewski 13 Nov '15

13 Nov '15

Dear DB-WG Members This is the 3rd draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Although the agenda is fully packed right now, please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. DB Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New and revised DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~10 min] (proposed, test, deployment) . "changed:" deprecation . Implementation proposal descr line . restrict usage of RIPE-NCC-RPSL-MNT . other aspects D. Personalised authentication update (Tim Bruijnzeels, RIPE NCC) [~10 min] E. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] F. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] G. Afrinic IRR homing project update (Job Snijders/Tim Bruijnzeels, RIPE NCC) [~10 min] Afrinic IRR (Michel Odou) [~10 min] H. ROUTE object authorisation update (Job Snijders) [~5 min] I. Control over associating objects for number blocks (William Sylvester) [~5 min] X. Heads up about recent discussions at db-wg mailing list Y. Input from other Working Groups and/or Task Forces Z. AOB __________________________________________ -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] Solving the issue of rogue ROUTE objects in
by Sascha Luck [ml] 06 Nov '15

06 Nov '15

the RIPE Database Reply-To: In-Reply-To: <563CC2EB.2040509(a)inex.ie> X-Operating-System: FreeBSD 10.1-RELEASE On Fri, Nov 06, 2015 at 03:10:35PM +0000, Nick Hilliard wrote: >On 06/11/2015 14:00, Sascha Luck [ml] wrote: >personal information is not exported for route: objects, >therefore this does not apply: That's the point Nick, for "verification" of out-of-area contacts, this information would *have* to be exported. In this scheme from other RIRs to the NCC but it would, if the others implemented similar schemes, also be exported from the NCC to other RIRs. rgds, Sascha Luck > >> remarks: **************************** remarks: * >> THIS OBJECT IS MODIFIED remarks: * Please note that all >> data that is generally regarded as personal remarks: * >> data has been removed from this object. remarks: * To >> view the original object, please query the RIPE Database at: >> remarks: * http://www.ripe.net/whois remarks: >> **************************** > >Nick >

1 0

RIPE 71 DB-WG agenda V2
by Piotr Strzyzewski 05 Nov '15

05 Nov '15

Dear DB-WG Members This is the 2nd draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Although the agenda is fully packed right now, please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. DB Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New and revised DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~10 min] (proposed, test, deployment) . "changed:" deprecation . Implementation proposal descr line . restrict usage of RIPE-NCC-RPSL-MNT . other aspects D. Personalised authentication update (Tim Bruijnzeels, RIPE NCC) [~20 min] E. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] F. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] G. Afrinic IRR homing project update (Job Snijders/Tim Bruijnzeels, RIPE NCC) [~10 min] H. ROUTE object authorisation update (Job Snijders) [~5 min] I. Control over associating objects for number blocks (William Sylvester) [~5 min] Y. Input from other Working Groups and/or Task Forces Z. AOB __________________________________________ -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] Database release 1.83 deployed to RC environment
by Alexander Stranzky 02 Nov '15

02 Nov '15

Am 02.11.15 um 12:00 schrieb db-wg-request(a)ripe.net: > Dear colleagues, > > We are happy to announce the deployment of RIPE Database software release 1.83 to the Release Candidate (RC) environment, which has gone live on Friday 30 October. > > - When deleting a person object, you will be prompted to also delete the associated maintainer if it has no other dependencies Does this affect REST API calls in any way? > - When trying to delete an object that is still referenced, you will get a list of blocking objects How does the REST API implement that? Does it send the objects along the error message(s) or can either part be omitted? Best regards, Alexander Stranzky -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181-1898119 * Fax: +49 6181-1898117 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

2 1

RIPE 71 DB-WG agenda V1
by snash 28 Oct '15

28 Oct '15

Can we please consider whether there is consensus on the response to Job's presentation in RIPE70, regarding authority to permit an AS to originate a route. This has been discussed in the "Temporary Origins" thread. Regards Steve Nash ------------------------------ Date: Tue, 27 Oct 2015 14:58:57 +0100 From: Piotr Strzyzewski <Piotr.Strzyzewski(a)polsl.pl> To: db-wg(a)ripe.net Subject: [db-wg] RIPE 71 DB-WG agenda V1 Message-ID: <20151027135857.GE21621(a)hydra.ck.polsl.pl> Content-Type: text/plain; charset=utf-8 Dear DB-WG Members This is the 1st draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. Database Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New and revised DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~30 min] (proposed, test, deployment) D. Personalised authentication update (Tim Bruijnzeels, RIPE NCC) [~10 min] E. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] F. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] G. Afrinic IRR homing project update (Job Snijders/Tim Bruijnzeels, RIPE NCC) [~10 min] Y. Input from other Working Groups and/or Task Forces Z. AOB __________________________________________ -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski(a)polsl.pl ------------------------------

2 1

RIPE 71 DB-WG agenda V1
by Piotr Strzyzewski 27 Oct '15

27 Oct '15

Dear DB-WG Members This is the 1st draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. Database Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New and revised DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~30 min] (proposed, test, deployment) D. Personalised authentication update (Tim Bruijnzeels, RIPE NCC) [~10 min] E. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] F. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] G. Afrinic IRR homing project update (Job Snijders/Tim Bruijnzeels, RIPE NCC) [~10 min] Y. Input from other Working Groups and/or Task Forces Z. AOB __________________________________________ -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Database release 1.82 deployed to RC environment
by Trudy Prins 19 Oct '15

19 Oct '15

Dear colleagues, We are happy to announce the deployment of RIPE Database software release 1.82 to the Release Candidate (RC) environment. We plan to deploy this version to production on Wednesday 14 October. This release introduces a number of features on the internal API of the RIPE Database that were needed to support the automatic updating of placeholder objects when resources are transferred into or out of the RIPE region. This release should not introduce any publicly visible changes, but we encourage all of you to test the new release in the RC environment. Note that the previous release 1.81 has not been deployed to production. While testing in the RC environment, we found a number of small issues in the User Interface (UI) that we will fix shortly. Technically the UI is not part of the core whois, but version 1.81 introduces a number of changes to the internal API in support of the new UI. Since that UI is not deployed now, there is no need to deploy 1.81 now either. And to avoid doing unnecessary upgrades of the production environment it was decided to skip this release, and deploy these changes only when 1.82 is deployed. Please let us know if you have any questions or comments. Kind regards, Trudy Prins Manager Software Engineering RIPE NCC

2 1

Feedback on updated Database documentation
by Alex Band 14 Oct '15

14 Oct '15

Dear working group, I have an ongoing project to write RIPE Database documentation that is clear and readable, focussing on achieving your goal and offer best practices. I've got a bit of a collection going now: Setting up maintainers and hierarchical authorisation: https://www.ripe.net/manage-ips-and-asns/db/support/security/maintainers The different authentication methods for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/support/security/protecting-data Configuring Reverse DNS: https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns Managing route objects in the IRR: https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-… I'd really like feedback from you, the users of the RIPE Database, to understand how usable it is and what needs clarifications, diagrams, examples, corrections or additions. I'd also love to hear which topic I should cover next. Thanks, and have a good weekend! -Alex

1 1

Interruption of RIPE Database and Related Services
by Trudy Prins 05 Oct '15

05 Oct '15

Dear colleagues, Starting at approximately 14:30 UTC on 4 October 2015, RIPE Database queries and updates, the LIR Portal and other related services experienced problems. Our investigation found that the service interruptions were due to a hardware failure. The queries were restored at 16:00 UTC and other affected services were restored at around 21:00 UTC. The ability of the RIPE Database to process incoming mail-updates was restored at 12:30 UTC on 5 October 2015. Please be aware that all mail-updates sent to Whois during this outage period must be considered lost. A summary of the hardware failure is as follows: The RAID controller on the master MySQL server reinitialised all of a sudden, causing IO errors. Unfortunately, we also experienced another (unrelated) hardware problem at the same time with the external load balancers. This combination of issues significantly affected the time it took us to rectify the situation. We apologise for any inconvenience this may have caused. Kind regards, Trudy Prins Software Engineering Manager

1 0

RIPE Database and related services interruption
by Theodoros Polychniatis 04 Oct '15

04 Oct '15

Dear colleagues, Since 14:30 UTC on 4 October 2015, RIPE Database queries and updates, the LIR Portal and other related services have been experiencing problems. We are investigating at the moment. We apologise for any inconvenience this may cause. Kind regards, Theodoros Polychniatis Senior Software Engineer RIPE Database Team

1 0

db object hijacking
by Nick Hilliard 03 Oct '15

03 Oct '15

some interesting data here: > https://www.lightbluetouchpaper.org/2015/10/02/badness-in-the-ripe-database/ Nick

3 2