Skip to main content

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

RIPE 67

Draft Minutes from Database WG - RIPE 67
Thursday, 17 October, 11:00 – 12:30
WG Chairs: Wilfried Woeber, Nigel Titley, Ulf Kieber
Scribe: Nigel Titley

Administrative Matters

Welcome

  • Select scribe (Nigel Titley)
  • Finalise agenda
  • Approval of minutes from previous WG meeting (Approved)
  • Review of action list (Nigel Titley)
    • AP66.1 [RIPE NCC] to return to the community for clarification of design goals for dummification. Complete (See Item B)
    • AP66.2 [RIPE NCC] Raise the proposal for changing auth requirements for route object changes on the Database Working Group mailing list for discussion. Complete (See Item B)
    • AP66.3 [RIPE NCC] Raise the proposal for single sign-on authentication on the Database Working Group mailing list for discussion. Complete (See Item B)
    • AP66.4 [Piotr, NT13, WW144] To raise the issue of internationalisation with the RIPE NCC Services working group chairs and also on the Database Working Group mailing list
    • AP66.5 [RIPE NCC] to check that all systems are UTF8 ready. Complete (See Item C)

B. Database Update - Denis Walker and Johan Ãhlen, RIPE NCC)

The presentation is available online at:
https://ripe67.ripe.net/presentations/321-DB_WG_Presentation_rev_7.pdf


Operational Report
The RIPE Database has been rewritten in Java. Now 2500 unit and integration test and 1500 end to end tests. Previously there were none. Currently about 430 queries per second

Software Release Management and TEST Database
Proper release management system now in place and being tuned. Main improvement is to add real data to the test system. Major releases which will encompass feature development and will include a test period. Minor releases will be bug fix only and will have an immediate deployment.
The TEST Database code is open source and the code base is on Github. Users are now contributing to code. You can run a local instance for experimentation.
      
Rudiger Volk made a short presentation on minimum requirements for the RIPE Database software update process. The presentation is available online at:
https://ripe67.ripe.net/presentations/320-rv-RIPE-DB-requirements.pdf
Points included:

  • All scheduled changes must be announced appropriately (including sufficient information to allow users to assess the risk posed by the software change) at least one week in advance
  • Unscheduled changes must be announced as soon as possible (this would not generally be post-factum)
  • Unscheduled changes must not happen unless to fix bugs with operational impact
  • AP67.1 [RIPE NCC] Report on known bugs in the RIPE Database
  • AP67.2 [RIPE NCC] Implement changes as already announced to the release process and monitor feedback from community.
  • AP67.3 [WW144] To ensure that the next RIPE NCC Services Working Group (RIPE 68) includes a session on the operational aspects of running the RIPE Database.


Documentation
The RIPE Database documentation needs a major update. It is difficult to search and not necessarily all available in one place. The Database Team will work with the Communications Department to make this more useful.

Survey

  • Scored well in the survey but several points raised: difficult to use (to start with) and also it would be useful to allow bulk updates.
  • Work will be done to improve the UI over the next few months


Resiliency
Hot node is now online in Stockholm. The database is the first service that has been made available.

Action Points

  • AP66.1 See presentation
  • AP66.2 Done. No comments received.
  • AP66.3 Ongoing. See presentation
  • AP66.5 The database is technically compliant but needs clarification on policy


Things "in the pipeline"

  • RDAP is now available in beta
  • Metadata tags can now be added by the software (not by the use, yet) Can be shown in queries and can be filtered on.
  • The four other RIRs' databases are mirrored based on their delegated stats. Extra query flag can be used to find the one authoritative entry
  • Can now do dry-run: test which does all tests but stops short of updating the object
  • Added "--diff-versions" to history query to allow tracking of changes over time easily.
  • All notification messages now show a diff output and a complete new object
  • "--valid-syntax" filters out of query output objects that would fail current syntax checks
  • RESTful API is now fully integrated and production quality
  • Standardised IPv6 representation
  • Major review of RIPE Database Query and Update manuals


Unresolved Features

  • Replace static information such as (0/0) with more useful return
  • Flag to request personal data. Some objections to the idea of changing the default. Need more feedback.
  • Blocking query behaviour currently blocks all or nothing. It is proposed to only block personal data objects when the limit is reached. NIC handles will be returned. Need feedback.


Upcoming Features

  • Simplify authorisation for route creation. Allow two partial authorised submission to be combined by the database to make a complete submission.
  • "via" attributes will be put up on the test database
  • Simplified UI for adding abuse-c in bulk through the portal
  • Single Sign-on. Not moved forward yet. Implementation plan will be sent out shortly.

C. UTF-8 transparency in the Registry

 Functionality and/or restrictions by components
 Policy or business logic interactions
 Coordination/input with/from other Working Groups.

D. Common Format for GeoLoc data- Zoltan Szamonek, Google

The presentation is available online at:
https://ripe67.ripe.net/presentations/324-self-published-geo_RIPE67.pdf

Existing system used by Google to allow network providers to publish geo data.
Allows rapid updates especially for networks that move around.
It was noted from the floor that prefixes are much easier to handle than address ranges.
It was noted that there are already mechanisms to allow the registration of geolocation data.

  • AP67.4 [WW144] Take the issue of geolocation to the RIPE NCC Services Working Group as it does not seem to be heavily used.

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

Presentation on infrastructure GeoLoc by the RIPE NCC in MAT Working Group.

Z. AOB

Abuse information (RV) One thing that is still missing is documentation to suggest what information should be sent to the abuse-c contact and what the abuse contact should expect. Response from the RIPE NCC is that this has been specifically discussed and the Abuse Contact management task force specifically decided not to be prescriptive. This is really an issue for the Anti-Abuse Working Group to sort out.

  • AP67.5 [WW144] 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.


Note to the Working Groupthat the question of Working Group chair appointment and retirement is being considered by the Working Group Chairs' collective and that input from the Working Group is very welcome

A note from Alexander Azimov who has completed an analysis of route policy data and found it to be generally very poor. He asked whether we should be verifying or deleting this data. It was suggested that this should be referred to the Routing Working Group

  • AP67.6 [WW144] To bring this to the attention of the Routing Working Group.