Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 56

RIPE Meeting:

56

Working Group:

Database

Status:

Final

Revision Number:

1

RIPE 56 Database Working Group Minutes Berlin - Thursday, 8 May. 16:00-17:30

A. Administrative Matters

  • Welcome
  • Select a scribe (Nigel T)
  • Finalise agenda
    Agenda accepted
  • Approval of Minutes from WG session at RIPE 55 (Approved)
  • Review of action list (Nigel T)
    [AP55.2] To be taken offline
    All the rest will be dealt with below

B. Database Update - Jos I. Boumans, RIPE NCC

Actions from previous meetings

AP54.3 Mandatory MNT-BY.
Code is completed but two issues which means that before can be deployed much more rigorous testing needed to be done.
Ongoing

AP54.7 rev-srv deprecation.
Needs a database schema change. Will be released at the same time as AP54.3.
Ongoing

AP54.4
White pages. New org-type and will be maintained by WG-Chairs.

AP54.6
Clean up unref'ed person objects.
Started. 400k remain. Same problem as AP54.3. Start by implementing AP54.4. Monitor object weekly from outside DB and remove if unreferenced for 3 weeks.
Ongoing

AP55.1
Add mnt-irt to LIRportal.
This is not possible at the moment. It has been added to the rewrite schedule for the portal which will take place late this year or early next.
Ongoing

Future of RIPE DB DB
Team would like to pause and reflect and decide on how the database should change to reflect current requirements.

  • DB Terms & Conditions
    Now clearly defined. RIPE NCC can now remove data as required by law. Discharges AP55.3. Stats Lots of pretty graphs. See presentation.
  • IRIS
    Very lightly used. Prototype code. Feature frozen. Suggestion to deprecate. It is suggested that there is much higher use in the domain area. DENIC are intending to release a client and server, but orientated to the domain side. Possibly sometime this year. The RIPE version just proxies to the RIPE database. There is less than 1 query per day. It was agreed that it should be deprecated.
  • RRCC (Routing registry Consistency Check)
    Suggestion to integrate with RIS and deprecate as standalone service. Agreed.
  • Mirroring RR
    No protocol, so breaks down when syntax changes. Attributes with no equivalents result in data being dropped. Only about 12% of queries are actually valid. 5% of valid queries are for route objects and so this question is being asked of the routing WG too. Proposal is to build a joint referral service. Replies would be in the format of the remote DB (which may be problematic). The point was raised that it is impossible to do CIDR type searches directly on the ARIN database and so the mirroring service is useful. A desire was expressed for a little more data on how frequently sync is lost (1 - 2 times a month) and how quickly it can be recovered (depends on the other registry). Some users of the service raised the point that returning results that are not in RPSL would be a problem. They suggested that this would be a far worse problem than returning stale data.

C. Follow-Ups

Task-Force on Data Protection Issues
Summary report will be presented tomorrow in the plenary

Contact Data Quality/Requirements Discussion
Nothing appropriate for the moment

Resource Certification Project
The point was raised that the CA-TF work was a focus for actions by lawful authority to remove items from the database. Would we want to record all such actions. This is properly the domain of the DP-TF and some progress on similar topics has already been made.

[AP56.1 DP-TF] To consider the action to be taken when legal authority requests the removal of data from the database, and in particular whether records of such actions should be recorded. It was noted that 2008-04 will result in more ROA data for the DB using data derived from the certification effort.

D. High Avalability SW Update for IRR - Yasuhiro Shirasaki, NTT

Using ripe-whois and our experimental syncronization trial

General enthusiam for the work done. The improvements in speed are partly due to the original code being some 7 years old. This gives further impetus to the RIPE DB team to be allowed time to think and reflect on the database re-write.

Y. Input from Other Working Groups and Task Forces

None

Z. A.O.B

None