RIPE 53

RIPE Meeting: 53
Working Group: Database
Status: Final
Revision Number: 1

RIPE 53 Database Working Group Minutes
Amsterdam, Friday 6 October 9:00-10:30

A. Administrative Matters

  • scribe (Nigel T. and RIPE NCC)
  • agenda (approved)
  • approval of minutes from RIPE52 (approval of minutes)
  • review of action list
  • "remote participation" coordination (if needed)

50.1 WW144
Take proposal to make the country attribute optional and multiple for inetnum and inet6num objects to the mailing list. Close and properly reformulate [AP53.1]

51.2 RIPE NCC
Check gnupgp compatibility before release of dated PGP signing functionality. Ongoing

51.5 ALL
Check and see if there are any other missing IRIS attributes that are needed for the RIPE community. This should be on the whole community who should now be checking the IRIS server. Complete

51.8 RIPE NCC To properly implement DB behaviour to always return irt: object on address queries, if it exists. Still ongoing but nearly complete

51.9 RIPE NCC
To contact a subset of the spam tool writers and make sure that they are aware of the change in behaviour as required by AP51.8. Ongoing

52.1 WW144
Put out a call for a task force to help the RIPE NCC in the task of updating the RIPE DB to comply with relevant Data Protection legislation. See presentation. Complete. See presentation

52.2 RIPE NCC
To send their proposal to support enum delegations, using the nserver: attribute, to the WG-DB and DNS-DB mailing lists. Complete.

52.3 WW144+NT13
To reformulate irt: proposal and post to DB-WG mailing list. Complete

52.4 RIPE NCC
To produce statistics showing how many objects are only protected by CRYPT-PW. Complete

52.5 RIPE NCC
To produce a proposal, with timescales, for removing CRYPT-PW WW144 and circulate to the mailing list. Complete. See presentation. Peter Koch

B. Data Base Update (N.N., RIPE NCC)

See presentation.

Check the irt: query behaviour. Note that the web query form implements the new behaviour. Note that circa 600 queries are received daily. There is no way to cover the ASN space at present.

ASN32 is coming and we will need to make changes in RPSL syntax. Approximately 10 objects and 41 attributes are affected.

Total query rate is much the same as normal.

Getting started document has been published. Please let NCC know if you find it useful.

Operations and support is mostly business as usual.

Forming a new database group and recruiting manager.

A note was asked about getting client software upgraded to accept the new ASN32 syntax. irrToolsets are being updated. However Geoff Huston pointed out that if you are running ASN16 then the behaviour of the irrToolset will have to take this into account.

[AP53.2 RIPE NCC]
To check and point out this requirement to various software developers: including but not limited to irrtoolset, quagga etc.

[AP53.3 RIPE NCC]
To make sure that if there is a "flag day" for ASN32 behaviour then the planning and introduction for this is done properly and advertised appropriately.

It is important to decide whether the ASN16 to ASN32 translation takes place in the client or database. The general feeling was that tools are going to break anyway so we may as well fix them. The breakage will happen slowly however which is proably manageable. The default allocations will continue to be ASN16 and those who ask for ASN32 must expect problems initially.

[AP53.4 WW144]
Alert Routing WG about the implications of the ASN16 to ASN32 transition on tools.

C. Task-Force on Data Protection Issues (Jochen d. R. RIPE NCC)

See presentation.

Depending on the local Data Protection laws, ISPs may be required to build notification into their contracts that details may be registered in the RIPE DB.

Mirroring outside the EU has been frozen (no new mirrors accepted at the moment)

The Data Protection Task Force has not yet been set up, but will be.

A set of items to be considered and actions required has been proposed.

The charter has been published (see presentation).

Volunteers please send an email to Jochem and copied to Wilfried.

D. Proposal to retire CRYPT-PW (Peter K., denic.de + WW144)

See presentation.

Still 3500 maintainer objects which use only CRYPT-PW.

CRYPT-PW much too weak. Explicit warnings seem to be falling on deaf ears. Adverse publicity could be quite damaging in the event of a serious hack. 2 month phase out plan. 1 month notification then 1 month while creation of new CRYPT-PW authentication is rejected, warnings when updating objects that contain CRYPT-PW, finally inform contacts and public again. After that CRYPT-PW authenication schemes will be deleted and maintainers where that was the only authentication method will be locked and released manually by the RIPE NCC on application. It was decided to start phase 1 now. Phase 2 will be extended as necessary to account for the end of the year hiatus.

E. Review irt: e-mail/abuse-mailbox (Philippe B., CyberAbuse)

This concerns some email on the list. The proposal was to make it easier for the maintainers of tools by always returning an abuse mailbox wherever it may be found.

We have to decide what direction to follow and decide how to populate the database with appropriate abuse addresses. We don't even know whether the database is the right place to store this information.

The address policy working group has considered this and will talk to their mailing list. We should really start to think about the overall strategy rather than nibbling away at the problem.

F. Update on the Poetry Object (Nigel T.)

See presentation.

Y. Input from other WGs

ENUM-WG: on (new?) organisation type for Database Object

The is the type of the ORG object. The proposal is to change the type NON-REGISTRY to OTHER. The DB WG has no objection.

[AP53.5 WW144]Wait for the formal consensus of the ENUM WG and then ask the RIPE NCC to make the change.

Z. AOB