RIPE 61

• content to the Chair of the working group.
• format to [email protected].

A. Administrative Matters

• Welcome
• select scribe (Nigel Titley)
• finalise agenda
• approval of minutes from previous WG meeting. Minutes have been published for some time. Accepted.
• review of action list (Nigel Titley)
  • AP59.6 [WW114] Send proposal for mnt-irt and (Dropped)
  • AP60.1 [DB-WG] Consider implications of ping-c attribute (See below, ongoing)
  • AP60.2 [RIPE NCC] Come up with suggestions for other troubleshooting attributes (Ongoing)

B. Geolocation data in whois (Richard L. B., BBN)

reference:meetings.apnic.net/__data/assets/pdf_file/0005/23486/Lepinski-APNIC-30-Geolocation-Registry.pdf

This is a suggestion to add geolocation information to the database (see presentation)
There are delays and no obvious procedures to update the various ad-hoc collections of geolocation data that exist.
Providing this should benefit everybody.
Adding a "location" attribute is one possible approach
There are privacy implications to this and maybe this means it should be managed by ISPs and not WHOIS
So, a better solution would be a "loc-server" attribute that points to a location server. There is already a standard for delivering this information in XML format. This allows different levels of authentication delivering different data to different requestors.
The downside is that new servers and procedures are needed to make this work.
Of course, none of this actually guarantees the accuracy of the data.
Questions to be answered are: is this actually a problem, are either of these solutions worth doing, would you contribute data for your network?
It was felt that there was definitely a demand for this.
It was pointed out that there are different WHOIS servers out there.
LACNIC pointed out that they already have a location attribute but it is hardly used (it provides latitude and longitude information).
Comments to the author.
Not an overwhelming interest from the room. But it might be worth mentioning on the mailing list.

C. Data Base Update (Paul P., RIPE NCC)
- See presentation
Still hunting for the source of egoQueries. Please can anyone who has some idea, please contact the RIPE NCC ping-c hasn't yet been implemented. There are questions to be answered:
check when added, periodic checking, which objects? It seems that RFC 5943 actually specifies inetnum and inet6num which answers the last question.

[AP61.1] [RIPE NCC] Implement a very basic RFC 5943 compliant addition to the database.

Much cleanup of ccTLDs. Of 43, 4 are still actively using it, 26 deleted, 13 no response. Chasing the remaining ones through CENTR.
Mirroring has been fixed. Recoded from scratch. All registries except Afrinic are now mirrored. Afrinic will follow shortly.
Much interesting work has been done and published on RIPE Labs.
Any questions, ideas or input to the mailing list.

D. Separation of Registry vs. User Data in the DB (Denis W., NCC)
- Prototype
- See presentation
Problem is that the registry data is mixed in with the resource holder data and incorrect resource holder data reflects on the data set as a whole.
Data will be seperated into two layers: fixed registration data (maintained by RIPE NCC), Resource holder data (data managed by the resource holder).
Users will need to change scripts used to parse query results where the result comes back as separated objects.
In the process of the code re-write it became apparent that there are holes in the implementation of various business rules.
A test server is available at whois-four.db.ripe.net.
Some reservations were expressed, especially as this moves the RIPE DB further away from RPSL. So it should probably be coordinated with the other
RIRs, especially with APNIC and AfriNIC who use something that is very close to the RIPE NCC one.


E. "IDN"ify the Resource Registry/Registries? (Piotr S., PolSl, PL)
- See presentation
This presention presented the case for adding IDN to registry data. At the moment, the inability to use non-ascii characters leads to confusion and annoyance.
Sometimes the difference is obvious but sometimes it is not.
A number of questions need answering: which code page should be used, could automatic conversion be considered, and should the whois client be able to ask for limited or full data?
There may be interoperability problems with other databases.
There seemed to be general approval although it was noted that there are many problems to be solved.

F. Better security for auth:? (Piotr S., PolSl, PL)
- skip SHA-1 and introduce SHA-2 as a replacement for MD5
Most objects use password authentication.
MD5 is not suitable for further use and objects are not well protected due to the weakness of MD5
The suggestion is to use stronger hash algorithms, skipping SHA-0 and SHA-1 and using SHA-2 and possibly GOST. In addition the suggestion is to mandate the RIPE NCC to add new algorithms as necessary.
Once this was done, remove support for MD5 over the course of 1 - 2 years.
It was pointed out that the MD5 hash function that we are using is not the basic function (it uses salt and is reiterated) and is more difficult to decrypt.
It might be better to invest the effort in encouraging users to move away from password protection and move to certificates.
Syncupdate cannot be used with certificates
[AP61.2][RIPE-NCC] Investigate what the next appropriate level of password hash should be.
[AP61.3][DB-WG] Community to think about where we should go from here (after passwords)

G. Feedback/status-check on APNIC "prop-079" (all)
- making the irt: object mandatory
- reference:http://www.apnic.net/policy/proposals/prop-079
-see also: 2010-08, 2010-09, 2010-10
http://www.ripe.net/ripe/policies/proposals/
Please watch this space. The proposals are on hold at the moment while the impact on procedures and the database are looked at.

H. Brief alert: ICANN's RT4-whois (WW144)

- reference:http://www.icann.org/en/reviews/affirmation/review-4-en.htm

WW144 has become involved with this, and although it is unlikely to have much impact on us (as it is mainly concerned with domain names), it may be that we can contribute.

Y. Input from other WGs and TFs
- IPv6: policy proposal 2010-06
This proposal covers registration requirements for IPv6 assignments in the database. It will eventually need looking at by this WG.

Z. AOB
It was noted the 2010-08 and 2010-09 will be redrafted with the database aspects removed
2010-10 has been withdrawn on the understanding that the whole matter will be looked at by an appropriate task force.