October 2015 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
by Tim Bruijnzeels 11 Feb '16

11 Feb '16

Dear working group, There is an open action point on us regarding the use of the RIPE-NCC-RPSL-MNT maintainer: https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004626.html > I'd like to ask RIPE NCC to provide the group with an implementation > plan and a timeline on how to prevent the RIPE-NCC-RPSL-MNT mntner from > being used to authenticate updates to an object after the object has > been created. We also ask that the RIPE NCC look into cleaning up > existing references to RIPE-NCC-RPSL-MNT and tell us their plan. Note that there is an ongoing an important parallel discussion about the authorisation of out-of-region IRR objects in general. But this is specifically about the use of 'RIPE-NCC-RPSL-MNT' on "mnt-by:". As long as we do have RIPE-NCC-RPSL-MNT, there are things we can improve and we want to propose the following to working group: 1) implement a business rule to prevent that this maintainer is used as 'mnt-by' Submitting an object that includes 'mnt-by: RIPE-NCC-RPSL-MNT' would result in a hard error, with a message like: "The RIPE-NCC-RPSL-MNT is used to authorise the creation of out-of-region aut-num and route(6) objects, but may not be used as 'mnt-by'" This is fairly trivial to implement, provided of course that the working group agrees to this. 2) remove the maintainer from existing objects There are roughly 2000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' only, and about 10000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' and at least one other maintainer. In the first case we propose to lock the object, i.e. set 'mnt-by: RIPE-NCC-LOCKED-MNT', and send out a custom notification to any contacts on the object explaining that the object has been locked to prevent a hijack of the object, and that ripe-dbm(a)ripe.net can be contacted to unlock the object. In the second case we propose to leave the remaining maintainer and send out a custom notification informing contacts on the object that the "RIPE-NCC-RPSL-MNT" has been removed to prevent a hijack of the object, and listing which maintainer(s) remain. Technically this is not difficult either, but it can result in a lot of questions. Therefore we prefer to do this in batches to make sure that we can process possible follow up requests to ripe-dbm(a)ripe.net properly. For reference we used a similar approach when dealing with locking the old MD5 passwords earlier this year. Provided that the working group agrees with this, we expect this can be done in the space of a few weeks after the business rule is implemented. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 14

Implementation proposal descr line
by Tim Bruijnzeels 11 Feb '16

11 Feb '16

Dear working groups, Following discussion in this group it was decided that the RIPE NCC should stop enforcing that the first "descr:" attribute of resource objects reflects the name of the organisation, for resources that it alloced or assigned. This practice has been place for a long time, but now that all such objects have a reference to an organisation object and the RIPE NCC ensures that this reflects the resource requests, this is no longer needed. Furthermore it was decided that the RIPE NCC should clean up existing organisation names in "descr:" attributes in order to: (1) avoid confusion about where the organisation name should be found; (2) avoid that the names here are different from the name of the actual organisation; (3) make it very clear which attributes are verified by RIPE NCC, and which attributes are not. Hereby the RIPE NCC would like to propose an implementation plan for these changes. We invite the working group to review and discuss if needed. As soon as the working group co-chairs formally call consensus, we can proceed to implement shortly. Implementation proposal: ======================== = Change "descr:" to an 'optional multiple' attribute We believe that the working group concluded that it would be appropriate to make "descr:" optional. The reason is that when the organisation name is cleaned up, there may be no description lines left. The working group considered whether the attribute should be 'single optional', but there seemed to be no strong preference for this, and it would have a bigger impact. Therefore we propose to go for the easier option of making it 'optional multiple'. Technically this change is not hard to do on the server side, but can impact users of the database because there may be no "descr:" attribute, and this can affect parsers. Because this can have an impact on automated systems the RIPE NCC will announce this change ncc-announce(a)ripe.net, and use a longer week staging period in the Release Candidate environment allowing users to test and update their systems. Dependent on formal consensus call we may be able to combine this with the upcoming release for deprecating "changed:" phase 3, to avoid delays. = Clean up existing "descr:" attributes where RIPE NCC enforced the organisation name The RIPE NCC will remove the "descr:" attributes that it has been enforcing. = Add "descr:" to allocation object editor in LIR Portal So that LIRs can edit this themselves. = Stop setting the "descr:" on new allocations or assignments done by the RIPE NCC We will leave "descr:" blank. It can be edited by the LIR or end-user later.

8 14

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

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