RIPE 65

Wednesday, 26 September, 9:00 – 10:30

A. Administrative Matters

• Welcome
• Select scribe (Nigel Titley)
• Finalise agenda; no changes
• Approval of minutes from previous WG meeting(s). Due to delay on sending out the minutes we will leave another two weeks for approval.

• Review of action list:
• [AP 63.1] [WW144] Take up the issue of the RIPE NCC providing a geolocation proxy with the RIPE Chairman and see if this needs to go through the services WG, and also to ask the mailing list. Dealt with under section D below.
• [AP 63.3] [Dave Freedman] Raise issue of reverse lookup method for aut-num objects on the mailing list to find out if this was a desired feature. Not progressed, closed.

B. RIPE Database Update

Kaveh Ranjbar, RIPE NCC

See presentation.

An incident a few weeks ago resulted in one of the update servers being down for four hours on a Saturday. There is currently no automatic failover and the service was down until manually failed over.

Issues are now immediately reported on the services announcement web page.

Documentation is the first priority after the redeployment.

All queries are now handled by the new software. It is now fault tolerant and easier to maintain. The code will be made open source and will be shared with other RIRs.

Mail and sync updates are now received by the new code for the test database but the content is processed by the legacy code. Objects are being migrated one at a time.

Once the new code is fully in place this will clear the way for a data cleanup.

Proposal for new resource-org object to provide a link to a responsible organisation for all allocated/assigned objects

Question (Rob Evans) about cleanup of aut-num objects. Perhaps worth bringing back AP 63.3 to help cleanup.

Question (Leo Vegoda): Is the new resource-org object a replacement for the org object? No, this would be a new object which is "verified" by the RIPE NCC. It will be necessary to make this distinction obvious. A request to the WG to think about the requirements for this new object.

[AP65.1] [RIPE NCC] Liase with the community to start to develop requirements.

C. Stability of Interfaces/Output of Database Machinery

Rüdiger Volk, DTAG

No presentation.

Rüdiger noted that there had been instances where their heavy duty database access procedures had failed for one reason or another. Some had already been addressed by the RIPE NCC. However there have been cases where small changes have been made to the procedures that access the database which have caused production systems to fail. These are often in the comments and removing or changing them may cause problems. This should perhaps be discussed and documented before changing. The problem stems from the fact that the protocol is badly defined. This makes proper communication even more important.

He also noted that they had done some extensions to irrtools which they are close to releasing. He pointed out that more extensive server side processing may make it more difficult to make changes or features to tools.

D. Discussion: GeoLoc Data in the RIPE Database

Wilfried Woeber

No presentation.

There was an attempt to start a discussion on the mailing list on the use and implementation of the geolocation feature but no replies were received and there is a feel that this may not be as important as was made out. The proposal is to abandon this after an announcement to the mailing list. There seems to be no active involvement from the community on this.

There are currently approx 400 items with geoloc attributes which is a very small percentage. However it was not advertised and these are early days. Kaveh pointed out that he had received a lot of interest even if there was no activity on the mailing list.

Alex Band reiterated that we haven't raised any awareness of this and perhaps removal was a bit premature. Gathering information about what geoloc might be used for would hopefully raise more interest.

[AP65.2] [RIPE NCC] Try to raise more interest in the geolocation attribute having gathered more information from possible users, etc.

Some concern was raised from the audience that promotion of the geoloc feature might take priority over other RIPE NCC work.

E. History view of Database objects

Vesna Manojlovic, RIPE NCC

See demo.

A live demonstration of registration history. Especially interesting now that we have run out of IPv4 and it may be important to view how address space has been transferred over time.

The question is whether this view should be restricted to RIPE NCC members only. At the moment it is.

Concern was expressed from the audience (Shane Kerr) that there was an increasing tendency for the RIPE NCC to produce members-only services. Concern was also expressed about the data protection issue and the fact that mistakes might be visible for all time.

Concern was also expressed on what the position was of historical data once a contractual relationship between the member and the RIPE NCC has ceased.

An audience member felt that this data should be restricted to RIPE NCC members only for privacy reasons.

Heather Schiller noted that this facility was effectively available through the bulk whois mechanism but that this makes it much easier. This remark was corrected by the RIPE NCC who pointed out that bulk whois is cleansed of personal data.

Peter Koch felt that a data protection audit should be carried out before taking this further.

[AP65.3] [RIPE NCC] Investigate and report on the data protection issues.

F. Status update on IETF WEIRDS activities

Olaf Kolkman, NLnetLabs/IETF

Attempt to agree on a new "whois" protcol set and semantics

See presentation.

There will be a single protocol for both names and numbers. The number side is already working. The main work now is compile inventories of objects and attributes.

RIPE Database WG members are urged to read and contribute.

Some concern was expressed (Shane Kerr) that this is just the latest of many attempts to update the whois protocol and what confidence have we of it succeeding where others have failed.

It was felt that very good progress had been made on the number side and at least this shows signs of success even if the names side becomes mired.

Rüdiger Volk expressed concern that whois is not only used for registration data and is non-registration data in scope?

At the moment it isn't, but there is a possibility that this will happen especially if extension mechanisms are defined.

Y. Input from other Working Groups and/or Task Forces

Impact of 2011-06 implementation on the RIPE Database facilities.

Rüdiger Volk, WW144

This is close to implementation. Please check on this proposal and see if it likely to cause problems for you.

There was concern (Rüdiger Volk) that this proposal has been moved forward without reference to the DB-WG and this may cause considerable operational difficulty.

However, the policy has been around for 18 months and has actually been referenced on the DB-WG mailing list during that time.

Documentation will be produced before implementation.

[AP65.4] [RIPE NCC] Ensure that 2011-06 and its effects are fully documentated before implementation.

Z. AOB

No other items.