RIPE 69

Thursday, 6 November 2014, 16:00-17:30
Co-Chairs: Nigel Titley, Wilfried Woeber
Scribe: Nigel Titley
Status: Approved

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 three weeks until approval
• 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:
https://ripe69.ripe.net/presentations/117-Chair-procedure.pdf

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. RIPE Database Operational Update (Tim B., RIPE NCC) [~10 min]

See presentation:
https://ripe69.ripe.net/presentations/123-ripe69-db-wg-update.pdf

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 online 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 RIPE Database Software Functionality (proposed, test, deployment) (Tim B. RIPE NCC) [~35 min]

See presentation:
https://ripe69.ripe.net/presentations/124-ripe69-db-wg-new-functionality.pdf

• “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 five 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:

https://ripe69.ripe.net/presentations/125-ripe69-db-wg-pers-auth.pdf

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:

https://ripe69.ripe.net/presentations/143-ripe69-db-wg-mntner-reset.pdf

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:

https://ripe69.ripe.net/presentations/160-db_wg_jobsnijders_reviving.pdf

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 RIPE Database?

This appears to be an issue with the data providers who can't be bothered to provide the data in the RIPE 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 Database.