[db-wg] Minutes from RIPE 70

Folks

Here is the first cut at the minutes. Additions and corrections to me, 
please

Nigel
-------------- next part --------------
Minutes of DB-WG, RIPE 70, 14th May 2015, Amsterdam

A. Administrative Matters
   . Welcome
   . Select scribe (Nigel)
   . Finalise agenda (V3 has been published, no additions)
   . approval of minutes from previous WG meeting(s)
   . review of action list (Nigel Titley)
      AP67.4 [WW144] Take the issue of geolocation to the RIPE NCC Services Working Group as it does not seem to be heavily used (subsumed into AP69.3)
      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. (Passed onto Anti-Abuse (Brian Nisbet) who will return it when done)
      AP67.6 [WW144] To bring to the attention of the Routing WG the fact that the routing data as recorded in the DB is generally very poor (Report by Alexander Azimov) (Discharged)
      AP68.1 [RIPE NCC] Remove the referral-by attribute (Discharged)
      AP69.1 [RIPE NCC] Produce a self contained document describing migration of the changed: attribute to the last-modified:/created: attributes (Ongoing)
      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)

B. Data Base Operational Update (Tim Bruijnzeels, RIPE NCC)
  See presentation.
  Release candidate environment has been deployed for some time and is used to do trial deployments for 2 weeks prior to release. There is a release notes page describing what is coming up.
  Five releases since last meeting of which only 3 have been deployed (one rolled back and another not deployed)
  A question was raised about the fact that 74% of email updates are authorised with clear text passwords and perhaps this should be deprecated, although it was noted that the value of the database entries was not particularly high and could be rolled back. It was also noted that many of these emails were TLS protected and single hop and the security issue is probably not serious.
  Would it be possible to not allow password authentication on creation of new maintainer objects?
  AP70.1 [All] Discuss deprecation of plain text passwords in email 


C. New DB-Software functionality (Tim Bruijnzeels, RIPE NCC)
   (See presentation)
    . referral-by deprecation
     - where are we now?
      referral-by is now optional and deprecated.
     - what are next steps (timeline)
      It will be removed by early July after a long period in the RC testbed.
    . from "changed:" to "last-modified:" / "created:"
     - where are we now?
      last-modified: is now added
     - what are next steps (timeline)
      changed: is about to be made optional (early July)
      it will be deprecated six weeks later (Mid August)
    . RIPE NCC to stop enforcing accurate organisation names in "descr:" attribute
      Only RIPE NCC can edit org: and org-name: of referenced non-RIPE organisations
      Once these entries are all sorted out the enforcement of descr: will cease
    . Improving Usability
      Work is being done to make the database easier to use
    . Business Rules
      A document describing the business rules will be published later this year.
    . Restrict usage of RIPE-NCC-RPSL-MNT
    . new MNTNER - RIPE-NCC-LEGACY-MNT
      This is added to legacy resources to ensure correctness of certain attributes
    . other aspects
      Adding shared maintainers on LIR organisation and allocations could clean up the business rules associated with updating organisation details and make it easier to update organisational details. 
      Choosing which maintainer to use is a decision that needs to be made. Perhaps a "default" maintainer with all LIR portal users on it.

  Comments from the room agreed with this. Publishing of the business rules will help users to decide if this is appropriate.
  Addng the maintainer on legacy resources means that it is not possible for a legacy owner can no longer delete sub-assignments. This was not believed to be the case. Taken offline.
  RV pointed out again that he needs more notice of releases in order to do appropriate planning and testing. 



D. Personalised authentication (Tim Bruijnzeels, RIPE NCC)
  (See presentation)
  This will allow one click creation of person objects
  Maintain credentials in one place.
  Allow better auditing.
  Done by extending person object to have multiple optional auth: attribute
  This will ultimately allow existing auth: sso references to be cleaned up
  Last auth: attribute should not be removed from a person object that is used in an authorisation context.

  Should this be extended to the role object as well? This would involve additional business rules but is technically possible.
  It would be useful to record what credential (maintainer) was used to make a particular change to an object and this change would facilitate this. RV was asked to raise this on the mailing list.


E. New proposals (Piotr Strzy?ewski)
   . UTF-8 in the DB
      Two suggestions: add to present attribues or add to complementary attributes
      Mostly positive feedback
        Could help with getting correct data for LEAs
        or could break everything?
        Bear in mind that the underlying transport may not be 8 bit clean
        The encoding needs to be specified.
        Note that searching is also impacted.
   . same INET(6)NUM objects with different status
      There is a problem that it is not possible to put two inet(6)num objects on the same space. This is particularly awkward for /22 allocations. Little feedback and one vote against. A possible approach would be to add multiple value for status field.       
   . cleanup some hacks with status values
      Examples ALLOCATED-BY-RIR
      No feedback so will ask RIPE NCC to come up with a suggestion
      AP70.2 [RIPE NCC] Come up with a proposal to fix this
   . make phone number optional in person objects
      Discussion to make more attributes options
      RFC2622 says this is mandatory. However we aren't compliant with it anyway
   . clean up historical "abuse-mailbox:" attributes
      It was noted that this should only be done once the use of the abuse-c: attribute is properly documented
      Should legacy holders add abuse-c:?

F. Orphaned Objects (William Sylvester)
  (See presentation)
  Some inetnum objects have no ability to maintain their own records due to data decay. 
  The proposal is to try and fix this.
  This particularly affects ERX holders and the suggestion is that if further discussion takes place on the ERX holders list then PS should relay it (without representing the ERX holders). It was suggested that we let this run for 6 months and see what emerges.
  It was pointed out that delaying this is delaying the cleanup of the database which is a Bad Thing.
  Caution was advised however as for legacy space we may not be certain about the ownership of a particular allocation or the conditions under which it may be used and the owners of the data are almost certainly not a part of this community.
  Some disagreement took place about the level of checking that was necessary in order to recover control over "orphaned" sub assignments. It was pointed out that there is a difference between leaf nodes and nodes higher up in the system.

G. Using RPKI for signing RPSL objects (Robert Kisteleki, RIPE NCC)
  (See presentation)
  This mechanism would allow you to use RPKI to sign RPSL objects
  It would not replace RPSS but would be used in combination with it.

H. "source: field for non RIPE address space" (Job Snijders)
  See presentation
  Extend the source: attribute to for example be RIPE-NONAUTH for objects for which RIPE is not authoritative.
  Many of these are for Afrinic and so we should have considerable patience while they get their RR in order.
  Much work needs to be done to determine the rules to be applied to such objects.

I. Use of the RIPE-NCC-RPSL-MNT maintainer
  See presentation
  The maintainer RIPE-NCC-RPSL-MNT has a well known password and is used in a number of DB objects
  This is actually to allow registration of alien objects but probably cannot be just ripped out.
  The proposal is to keep the maintainer to create objects but immediately they have been created remove the attribute.
  For existing objects it would be necessary to add an additional maintainer.

J. IRR Homing project
  See presentation
  Objects belong in the appropriate database and should be rehomed to where they belong.
  This would be done by a bulk migration followed by mirroring of the data for at least 12 months.
  Nice idea but this may well involve a new take on RPSL.
  Comments welcome on the mailing list.


Y. Input from other Working Groups and/or Task Forces
   . Cross-registry Authentication for IRR Data BoF (Job Snijders)
      See notes of the BoF (circulated on the mailing list)
      Feedback on the mailing list is welcomed

Z. AOB