Folks
I'm a bit late in sending these minutes out, for which I apologise.
Please rapidly get any comments back to me.
Thanks
Nigel
Minutes for DB-WG at RIPE 69, November 2014
A. Administrative Matters [~10 min]
. Welcome
. select scribe (thanks to Nigel for volunteering again!)
. finalise agenda
No additional agenda items
. approval of minutes from previous WG meeting(s)
Minutes. Circulated only very recently so will hold for 3 weeks until
approving.
. review of action list
AP67.4 [WW144] Take the issue of geolocation to the RIPE NCC Services
Working Group as it does not seem to be heavily used. (Ongoing)
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. (Ongoing)
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) (Ongoing)
AP68.1 [RIPE NCC] Remove the referral-by attribute (In progress)
B. Working Group Management (Nigel T.) [~10 min]
. chair replacement procedure
See presentation
Procedure accepted
. WW144 to resign
Thanks to Wilfried for all his years service.
. new DB-WG Co-Chairs to take over at the end of session
Job and Piotr
C. Data Base Operational Update (Tim B., RIPE NCC) [~10 min]
See presentation.
All open issues are tracked on Github
Release Candidate environment is available for at least two weeks prior
to release so that full testing may take place.
Documentation is on line and is tied to each release.
RIPE Academy is providing DB training
Abuse-c cleanup is well advanced
Question: will one of the abuse contact finders be abandoned
once this exercise is complete?
Answer: no for the RIPE NCC region we will only check the
abuse-c but the two tools can be merged.
Question: When will API keys be authenticated by the system
Answer: It is on the agenda but we are waiting for guidance
from the WG
D. New DB-Software functionality (Tim B. RIPE NCC) [~35 min]
(proposed, test, deployment)
See presentation
. referral-by deprecation
- (based on deprecation guidelines)
- present time table for 'referral-by'
Removal in three phases over 4 months
. from "changed:" to "last-modified:" / "created:"
- explain new attr., examples,
- timeline for implementation
Three phases over 5 months.
Comments (RV) was that such changes should be written down formally in
advance.
Response was that this has been extensively discussed on the mailing
list and the details have been available for months.
RIPE NCC noted that it would be relatively easy to produce such a
document.
[AP69.1][RIPE NCC] Come forward with a self contained document
describing the migration
of the changed: attribute to the last-modified:/created: attributes
proposal
Another question was asked about objects in the database which have no
changed: lines, what date was it created? The response was that
the relevant data will be pulled from the database and added to the
object.
RV asked that there was some syntactic markup to separate system added
attributes from user added attributes. It was pointed out that the
-t flag already tells you this. RV responded that this wasn't enough.
It was asked whether all the attributes of auto-generated objects
should be marked as such. It was agreed to discuss this on the mailing list.
It was suggested that whatever history is available might be
incorporated, including data from ERX and other registries. It was agreed to
discuss
in the mailing list
[AP69.2][RIPE NCC] Come up with some straw man proposals for doing this
E. Personalised authentication? (Tim B. RIPE NCC, all) [~5 min]
See presentation
More detailed proposal following requests on the list and at the last
meeting
WG feedback is needed about how to do this.
The proposal is to add person authorisation using a Single Sign On
authentication.
Maintainers are also difficult and non-intuitive
Suggestion is to use roles everywhere. The advantage is that this is
consistent and it is easy to see who is who
An alternative is to have optional persons in maintainer objects
There will be an issue with migrating existing maintainer objects. Any
migration mechanism should ideally be capable of automation.
Existing tools can be relatively easily modified to check all possible
authentication methods.
Suggestions were presented on how the migration to using roles could be
semi-automatically handled.
All comments gratefully received.
Adding optional persons to maintainers could be easier to migrate.
Discussion needs to take place on the WG
Some comments on the perceived complexity of the maintainer object took
place and it was suggested that some good
concise documents on the maintainer object might help. It was agreed
that it would not be a good thing to take away the maintainer object.
F. Maintainer Password resets? (Tim B. RIPE NCC, all) [~5 min]
See presentation
25% of all ripe-dbm requests are password resets
Rather than removing all authentication RIPE NCC is now adding SSO auto
and allowing the member to get access that way instead.
G. "reviving" the WG, active participation (Job S.) [~10 min]
See presentation
Participation in the group has dropped off in the last 12 months. Why
has this happened?
Response from RV was that the database is in reasonable shape and is
heavily used in production. The fact that
it doesn't need a lot of modification is actually a strength.
It was noted that database accuracy is very important and maybe the WG
should be thinking about how to improve
accuracy of the data.
It was noted that some of the changes proposed were taking place far
too quickly for large organisations to follow.
It was pointed out by the RIPE NCC training group that many users only
use the database 2 - 3 times a year and find it difficult
to keep current. Rapid changes would make this even more difficult.
A call was made for IPAM developers to use the RIPE DB API and
Softlayer responded that they used it extensively. The RIPE NCC
said that they were very happy to work with anyone using the DB to
improve it and improve the interface into it.
Y. Input from other Working Groups and/or Task Forces
RV pointed out that the Abuse WG really needs to provide proper
documentation on the Abuse-C attribute and he suggested that
it should be made optional until such documentation is produced. It was
agreed that this should be chased with the Anti-Abuse. It was pointed out that
Anti-abuse TF decided that the abuse-c should come first and the
population of it should come second.
A representative from the Routing WG noted that it is easy for
"foreign" prefixes to be entered into the database and these can be used for
various
nefarious purposes. It was suggested that such foreign prefixes should
be validated using RPKI. It was asked that the routing WG should
come back to the DB mailing list with this request.
Z. AOB
Geolocation.
Tim Robinson from TXRX communication, saying that he has problems with
getting his IP blocks recognised as being from the UK.
JS agreed with the problem statement. There isn't a global source of
accurate geolocation data. Should we make it easier to consume the
geolocation data already in the DB?
This appears to be an issue with the data providers who can't be
bothered to provide the data in the database.
It was pointed out that browsers generally have a very good idea of
location and language and this is a more appropriate source of
location data than the database.
[AP69.3][RIPE NCC] To examine and report on possible solutions to
improving geolocation data in the RIPE DB
