[db-wg] Draft minutes of RIPE 67 meeting

Please find draft minutes of the DB-WG meeting held in Athens today.

Comments, complaint, misrepresentations etc, to me

Nigel
-------------- next part --------------
MInutes of the Database WG - RIPE 67 - Athens

A. 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 DB-WG mailing list for discussion. Complete (See Item B)
      AP66.3 [RIPE NCC] Raise the proposal for single sign-on authentication on the DB-WG mailing list for discussion. Complete (See Item B)
      AP66.4 [Piotr, NT13, WW144] To raise the issue of internationalisation with the NCC service working group chairs and also on the DB-wg mailing list
      AP66.5 [RIPE NCC] to check that all systems are UTF8 ready. Complete (See Item C)

B. Data Base Update (Denis.W., Johan.Ã?., RIPE NCC)
   See presentation
   - operational report
      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 DB
      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.
      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 DB software update process

      - All scheduled changes must be announced appropriately (including sufficient information to allow users to assess the risk posed by the software change) at least a 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 NCC-services WG (RIPE 68) includes a session on the operational aspects of running the database.

   - Documentation
      It needs a major update. Very difficult to search and not necessarily all available in one place. The DB team will work with the Comms team 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 DB is compliant technically 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.
      4 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 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 WGs

D. Common Format for GeoLoc data (Zoltan Sz., Google)
   See presentation
   - 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 NCC-services WG 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 WG

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 WG to sort out.
   AP67.5 [WW144] To check that the Anti-Abuse WG has properly specified both what should be done with mail that is sent to the abuse contact and (possibly) its format.

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

   - A note from Alexander Azimov who has done 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 WG
   AP67.6 [WW144] To bring this to the notice of the Routing WG.