RIPE 60

A. Administrative Matters

• Welcome
• Select scribe (Nigel Titley)
• Finalise agenda
• Approval of minutes from previous WG meeting(s)
  
  • No comments. Minutes approved.
• Review of action list (Nigel Titley)
  
  • AP54.6 RIPE NCC Removal of orphan objects. Discharged (see below)
  • AP58.1 RIPE NCC Support of IPv6 in ASUSED. Discharged (see below)
  • AP59.1 RIPE NCC Reverse delegation safeguards. Discharged (see below)
  • AP59.2 Last notification of removal of orphan objects. Complete (see below)
  • AP59.3 Update reference manual complete. (Discharged)
  • AP59.4 Overtaken by events (RESTful query facility)
  • AP59.5 Overtaken by events (RESTful query facility)
  • AP59.6 No progress. Ongoing
  • AP59.7 Overtaken by events (RESTful query facility)

B. Data Base Update (Paul Palse, RIPE NCC)

Removal of unref'd contacts

• Now complete.
• Deletion is set to 90 days after first becoming unreferenced.

Operational Update

• Average queries per minute is over 8000 of which just over 1% comes in over IPv6.
• Mostly ad-hoc queries
• Updates average 36 per minute. 66% use sync, 30% email, 4% via web.
• EgoQueries: where an IP queries for its own address. Does anyone know what application this might be?

Activities of DB Group related to RIPE Labs

• RESTful web services query API. Now in prototype form on RIPE Labs.
• Please have a look at this and try it out. Comments are very welcome
• "Use Case" search. Returns a precise answer to a specific question.
• The only case available at the moment is related to abuse handling.

Registration data in the RIPE Database

• Important to hold accurate registry data.
• Much data is user supplied and some is low quality. This reflects on the whole dataset.
• Try and present a clear distinction between the registry and user data
• Changes should be minimised and so should impact on RIPE DB software
• Please return thoughts on this to the DB WG mailing list.

Some discussion took place on what questions are being asked of the DB and what responses are being returned. From a philosophical view there is a difference between the question "who is currently using this address space" and "to whom was it issued". Abuse tracking probably more concerns itself with the first of these questions.

C. New Database Query API in form of a RESTful Web Service

• Reference: https://labs.ripe.net/author/paul_p_/ripe-database-query-api-including-search/
• Covered by previous presentation

D. Brief review of discussions and (proposed) mechanisms supporting the management of abuse cases and incident handling (WW144, Chair)

• Reference: https://labs.ripe.net/author/paul_p_/find-abuse-handler-details-using-the-abuse-finder/
  Covered by previous presentation

Y. Input from other WGs and TFs

• Routing-WG: ping-c attribute proposal
  • This is a proposal to introduce a new attribute which could be used for fault finding. The ping-c would be an IP address which was guaranteed to respond to pings. The WG was asked to consider whether this would be useful. Would it be useful to have a check from the DB software when such
    an attribute is added to an object? Would it be useful to extend the functionality to add other services than just ping. Is there a danger of over engineering it before we even start?
  • It was noted that RPSL is fairly dated and the whole documentation environment around it needs to be updated.
  • Which object should it be added to: inet-num or route? It was noted that it would be fairly easy to bring up a test database with these suggested attributes.
  • [AP60.1 DB-WG] Discuss on mailing list and feed back to author.
  • [AP60.2 RIPE NCC] Think about what sort of facilities would be useful and make a proposal.

Z. AOB

No other items