[db-wg] RIPE 72 minutes

Folks

Here is the first cut at the minutes.

Comments (and particularly complaints about missing/additional action 
points) to me

All the best

Nigel
-------------- next part --------------
Database WG RIPE 71 19th November 2015

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)
      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) (See presentation)
   . 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) (see presentation)
  . 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) (See presentation)
  . 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) (see presentation)
  . 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) (see presentation)
  . Three step process
    1. Communicate
    2. After 3 months: Freeze in RIPE IRR (no new route objects allowed for Afrinic inet objects)
    3. After another 3 months: Clean up objects (delete objects in RIPE 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) (see presentation)
  . 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) (see presentation)
  . 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 database.
    The argument appears to be that deciding who is the holder of the resource is non trivial.
    (Athina) 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