Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 71

Database Working Group RIPE 71
19 November 2015, 14:00-15:30
WG Chairs: Nigel Titley, Job Snijders, Piotr Strzyzewski
Scribe: Nigel Titley

A. Administrative Matters

  • Welcome
  • Select scribe (thanks to Nigel for volunteering again!)
  • Finalise agenda (agenda accepted)
  • Approval of minutes from previous WG meeting(s)
  • Review of action list (Nigel Titley)
Review of action list:

AP67.5 [AA-WG] To check that the Anti-Abuse Working Group has properly specified both what should be done with mail that is sent to the abuse contact and (possibly) its format.
Still ongoing but will have a response by RIPE 72.
AP69.1 [RIPE NCC] Produce a self contained document describing migration of the changed: attribute to the last-modified:/created: attributes
(Discharged)
AP69.2 [RIPE NCC] Come up with some straw man proposals for displaying history for objects where available (Ongoing)
AP69.3 [RIPE NCC] To examine and report on possible solutions to improving geolocation data in the RIPE DB (Ongoing but if no progress by RIPE 72 then kill it)
AP70.1 [All] Discuss deprecation of plain text passwords in email (Ongoing)
AP70.2 [RIPE NCC] Come up with a proposal for the status: field to fix the requirement that certain objects may need multivalued status. (Ongoing)

B. Database Updates (Tim Bruijnzeels, RIPE NCC)

The presentation is available at: https://ripe71.ripe.net/presentations/110-ripe71-db-update.pdf

Operations
  • Approx 70% of active maintainers have reset their passwords
  • Hardware is being upgraded and database moving to MariaDB from mysql
  • RIR-RIR transfers. Need to manage placeholder objects for Maintainers
  • Need to fix missing abuse-c: attributes
New functionality
  • “changed:" deprecation
  • Phase 2 released to production on 13th July. Phase 3 will deploy to RC soon.
  • Should we accept changed: but remove and reject?
  • Implementation proposal descr line
  • Restrict usage of RIPE-NCC-RPSL-MNT
  • Consensus to go ahead with this? Add it to change: phase 3
Other aspects
  • Personalised authentication
  • SSO integration. Will be discussed in a later presentation and lays the groundwork for personalised authentication
  • Fairly low priority at the moment. Should it be increased in priority?
Upcoming work
  • Finish hardware migration
  • WG requests
  • MAA process support
  • Lots of usability improvements
  • Explore inter RIR authorisation options. Involves discussion with other RIRs.

In response to a question from the floor (RV), it was stated that documentation on RPKI transfer between RIRs has been delayed by awaiting proposals from Adress-Policy and the IETF. Tim is willing to help work on this paper.

It was noted (WW) that the original RFC-set on RPKI has been overtaken by events and should be re-examined.

AP71.1 [WW144] To organise an effort to look at this.

C. Updated Database documentation (Alex Band, RIPE NCC)

The presentation is available at: https://ripe71.ripe.net/presentations/177-DBWG-RIPE71.pdf

Improving Database documentation
  • The documentation is very scattered and needs gathering together
  • Also the reference manual goes into a great deal of detail but isn't very helpful in operation
  • Now all in one place: ripe.net/db/support
  • A start has been made and a number of How-to documents have been published including a Business Rules manual, containing material never before published.
  • Alex would like to have suggestions on what to do next
Improving the user interface
  • Being logged in with SSO to the web front end will be mandatory, help will be given with migration from MD5
  • This does *not* affect core functionality
  • Addition of your SSO authentication line to the maintainer can be done simply from the web front end
More focus on the maintainer
  • Moved to a more prominent position in the webupdate interface
Auto-complete and syntax checking in the webupdate interface
  • Helps avoiding many syntax changes
Help in removing person/maintainer pairs
Notification of blocking objects
  • Makes removal of person objects much easier
Route object creation
  • Makes creation of out-of-region route objects much easier. Where dual maintainer authentication is needed, details of the other maintainer are given.

A request was received from the floor (RV) for the identity of the originator of a dual authentication request to be included in the notification to the other maintainer.

D. Routing policies vs. reality in BGP (Tomas Hlavacek)

The presentation is available at: https://ripe71.ripe.net/presentations/123-rpslvsbgp.pdf

Comparison of what is recorded in the RIPE DB as against what is actually present in the real world
  • Limited to RIPE region
  • Completed in July 2015
  • Code is open source and available
  • 77% of route origin data is correct and improving but there are substantial amounts of cruft still
  • Only 37.3% of paths verified correctly. Some of this is due to BGP variations and alters over time

For further details see the presentation.

E. AFRINIC IRR (Michel Odou)

The presentation is available at: https://ripe71.ripe.net/presentations/122-afrinic_routing_registry.pdf

Version 1.0 has been in production since August 2014, version 2.0 is in testing phase
  • One advantage of this is that AFRINIC objects can be migrated from the RIPE Database
  • Route objects can only be created for AFRINIC registered inet objects.
  • "Boot camps" are being run to facilitate the migration of AFRINIC route objects back to AFRINIC
AFRINIC IRR homing project update (Tim Bruijnzeels, RIPE NCC)

The presentation is available at: https://ripe71.ripe.net/presentations/111-ripe71-afrinic-irr-home.pdf

Three step process
  1. Communicate
  2. After three months: Freeze in RIPE IRR (no new route objects allowed for AFRINIC inet objects)
  3. After another three months: Clean up objects (delete objects in RIPE Database and create locked objects in the AFRINIC RR)
  • In parallel explore how we deal with hybrid objects.

RV announced that he didn't object (applause). However there are operational concerns which must be monitored throughout the progress of the migration.

WW was concerned that we are fragmenting the data used to build network filters and this is increasing the fragility of the process.

Discussion to continue on the mailing list.

F. ROUTE object authorisation update (Job Snijders)

The presentation is available at: https://ripe71.ripe.net/presentations/176-route-object-ripe71.pdf

Expansion of Non-European networks results in the creation of RIPE autnum which is a duplicate of the alien one
  • There are four (at least) possible solutions to this and no obvious convergence
  • A proposal needs to be drawn up on how to proceed
  • Volunteers are needed: Marco, Erik.
  • AP71.2 [Marco, Erik, Job, Tim] To work on a method of cross authentication of autnum (possibly involving RPKI)

G. Control over associating objects for number blocks (William Sylvester)

The presentation is available at: https://ripe71.ripe.net/presentations/115-Control-over-associating-objects-for-number-blocks.pdf

Proposal is for a legacy inetnum holder to directly modify their objects
  • Needs further discussion on the mailing list.

It was also noted that in many cases the owner of a lower level object may not be known to the RIPE NCC and the appropriate approach would be for the legacy holders to sort things out and then come back to the RIPE Database.

The argument appears to be that deciding who is the holder of the resource is non trivial.

Athina Fragkouli, RIEP NCC,pointed out that the RIPE NCC has no certainty of the ownership of the resource without conducting their due diligence checks.
Trying to fix this without appropriate authority opens the RIPE NCC to liability for irreversible effects due to their actions. Conversation to be concluded offline

X. Heads up about recent discussions at db-wg mailing list

Ran out of time

Y. Input from other Working Groups and/or Task Forces

Ran out of time

Z. AOB

Ran out of time