Folks
Here is the first cut at the minutes. Additions and corrections to me,
please
Nigel
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
