Database Working Group Minutes from RIPE 58

• content to the Chair of the working group.
  
• format to webmaster@ripe.net.

A. Administrative Matters

• Welcome
• Select scribe (Nigel Titley)
• Microphone etiquette and remote participation
• Finalise agenda (as below) - accepted.
• Approve minutes from RIPE 57 - approved.
• Review of action list

[AP54.3 RIPE NCC] Add MNT-by on Person/Role objects - Complete

[AP54.6 RIPE NCC] Clean up orphaned objects - Ongoing

[AP54.7 RIPE NCC] rev-srv deprecation- Complete

[AP55.1 RIPE NCC] Add mnt-irt to the LIRportal -Complete

[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 - Complete

[AP57.1 RIPE NCC] Implement ASPLAIN - Complete

B. Database Update (Paul Palse, RIPE NCC)

- including highlights from DP-TF

Proposal: No re-use of NIC handles. Initial characters can be specified. Sequence numbers will be generated by the RIPE NCC.

Please can we have input on the mailing list? There appeared to be no objections from the room, but this was not regarded as conclusive. It was observed that the benefit of the whois database is the public facing side.

Internal management issues are important but the complexity of the internal self referential design is starting to get out of hand. There is a convergence of activity across the RIRs and we should possibly look at liaison with other RIRs. An offer was received from APNIC. There were objections however that the self referential integrity was not over complicated.

Proposal: Request authorisation from maintainer to link person/role to an object managed by another maintainer

How useful is proxy access to the DB? There are 89 proxy agreements of which only 28 are active and 18 used it properly. Do we still need to provide it?

Proxy access is an unthrottled mechanism.

Support for the proxy mechanism was expressed within the room. It was felt we shouldn't remove it.

- progress on open actions on the NCC

See presentation on website.

• 54.3 Will be deployed shortly after RIPE 58
• 54.7 will be deployed shortly after RIPE 58
• 54.6, the cleaning up of orphaned objects is proceeding and will be complete by RIPE 59
• 54.7 Done on 25th March

All mirroring feeds will be migrated to a "personless" NRTM. RADB is 99.999% in sync with RIPE

New system architecture will be fully in place by RIPE 59. It gives zero data loss in the event of hardware failure.

For general stats and updates see the presentation.

Question: Were they any plans for ASUsed to support IPv6 addressing?

[AP59.1 RIPE NCC] Please check that ASUSED can support IPv6

Question: Will the maintainers of rev-srv attributes be notified of the change?
Answer: These are very old attributes. The rev-srv will be converted to a remark, the maintainers will not be contacted.

It was felt that although converting this data into remarks seems "unclean", it may have historical value.

C. Status Check for IRRToolSet (WW144)

- General Maintainance

It was felt that the IRRToolSet was not being actively maintained. A few people in the room are still using it. ISC have recently dropped maintainance of it and moved it to "maintained by the community".

There is a website with some patches and fixes. Check out the latest code. 32bit ASN support has been added as a patch. Not known whether this includes ASPLAIN.

It was noted that ISC did a poor job of maintaining it and never merged in patches supplied by the community. So this move may well improve matters.

Should the RIPE NCC act as a guide dog for the maintenance of this software? It was felt that someone needs to set some objectives, and circulate on the mailing list. At this point it may be apprpriate for RIPE NCC to give some help.

It was noted that RIPE NCC still provides some limited platform support but doesn't feel it apropriate to actively maintain it.

There are alternatives, with far less functionality, but IRRToolset may be too heavyweight for most users and an upgrade to other tools might be more appropriate use of resources.

We may well also need to add tools to support future security work and possibly that is a role for the RIPE NCC. Some effort will be needed to support the use of certificates in generating route filters. Generation of a parallel RKPI database is a quick way to get to this goal.

It was pointed out that RIPE NCC mentions the use of the tool in its training courses.

- ASPLAIN implementation
See above.

Y. Input from other WGs and TFs

- DNS: NCC about to remodel the reverse delegation robot

The NCC is working on an improvement to the system to generate reverse delegation objects and request reverse delegations. Zone files are generated from this data.

Please raise any issues with the RIPE NCC. They will be producing a document detailing what they propose to do and will circulate on both DNS and DB email lists. There are special problems with the robot which results in no errors being generated under certain conditions (delegation of a /24 where the /16 has already been delegated).

The updates are intended to harden the machinery and introduce the ability to integrate with DNSSEC. Other improvements will include the ability to specify which master to download zones from, provided the community can come up with changes to RPSL to allow this.

Z. A.O.B.

No AOB