You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
62 |
Working Group: |
Database |
Status: |
Final |
Revision Number: |
1 |
A. Administrative Matters
Presentations from this session are available at:
http://ripe62.ripe.net/programme/meeting-plan/database
B. ACM-TF status report (Brian Nisbet)
See presentation
The ACM-TF will in future report back to the AA-WG.
Two meetings have been held so far and more are planned. The basic
requirements are to have a single
point of contact which can be easily accessed
Feedback and input are still welcomed.
C. Data Base Update (Database Group, RIPE NCC)
See presentation(s)
Query uptime is very close to 100%
AP57.2 (Cleanup of forward domain data) is nearly complete. Should be finished by RIPE 63.
AP59.1 is complete (Reverse Delegation safeguards) This is now completed and you can no longer create hierarchies of reverse delegations
AP61.1 (pingable attribute) was completed on 21st Feb and the pingable: attribute is now available.
AP61.2 (Alternative password hash) SHA2 can be done. Proposal has been sent to mailing list. Discussion to follow.
Geolocation prototype is being developed on RIPE Labs. Content providers are very interested as it means they can deliver appropriate content. It will probably be based on adding location data to inet[6]num objects
New improved RIPE database search forms were demonstrated including a new global search facility.
An improved facility for creating and modifying objects was also demonstrated.
A question on geolocation was received. Are any ISPs interested in this (as opposed to content providers). It seems that no LIRs have been contacted, only content providers. The opinion was expressed that this is an issue between the end user and the content provider and not the ISP.
It was noted that geolocation requests had been received from LIRs who get reused blocks and thevarious ad hoc databases return the wrong location.
It was also noted the there is an issue of liability for the accuracy of the geolocation information.
This should probably be investigated.
The question was raised about who should pay for the provision of the data.
[AP62.1] [RIPE NCC] to send proposal on geolocation to mailing list to open discussion
A question was raised about the RESTFUL API. Is this intended to replace whois or to run in parallel?
Certainly for the moment, they will run in parallel.
D. Revisiting Attributes in the Domain: Object (Peter Koch, DENIC)
See presentation
With the domain object now becoming vestigial many of its attributes are now unnecessary
sub-dom: rather vague documentation and not properly used. Needed?
dom-net: list of IP networks in domain. No sense at all now. Needed?
nserver: optional but should now be mandatory
mnt-lower: no shadow objects so unnecessary
[AP62.2] [RIPE NCC] Examine use of these attributes, contact users, discuss and do cleanup
E. Request: Secure Channel to Access Registry Data (Martin Millnert, Shane Kerr)
See presentation
This proposes the use of TLS for whois data. This would provide confidentiality ofqueries, data integrity and proof of origin. No changes to RIPE database.
This is much simpler than a RESTFUL API and requires less code modification
Code changes are in fact minimal.
It was suggested that maybe this is an opportunity to update whois and use it as a means to encourage IRIS, but the feeling was that a lot of scripts use whois and this could be useful.
[AP62.3] [RIPE NCC] Investigate how much effort this would take (including getting an official port assigned).
F. Follow-On: MD5 to be replaced by SHA2 (Discussion (all))
The general idea is to replace MD5 with a newer algorithm. There seems to be opposition on the mailing list although support in the room at RIPE 61. There is also likely to be opposition to
moving away from passwords and towards certificates. 50% of updates still use clear text passwords.
The alternative is to remove the password from the whois output, but this isn't a great solution as historic data is still available and passwords will not be changed.
It was noted that passwords are generally the last resort for access and probably can't be removed altogether.
[AP62.4] [RIPE NCC] Do some analysis on the relative numbers of objects secured by passwords.
G. brief report: ICANN's RT4-whois (WW144)
Several organisations are thinking about how to move whois into the modern world (internationalisation)
The existing protocol does not allow for this. Please read up on this and bring comments to the mailing list. Should we exhume the corpse of IRIS?
H. Do we need a "whois" protocol? (WW144)
See above.
I. Input from other WGs and TFs
DNS: dash-notation changes for revDNS
Noted and no objections
[AP62.5] [RIPE NCC] Implement the dash-notation changes for reverse DNS as proposed on the mailing list
Z. AOB
Should we record sponsoring LIR in the Resource registry?
Would this be a good idea?
This is definitely mainly under the purview of the AA-WG and we will await their action.
An opinion was expressed that anything that helps to attach a resource to an associated LIR would be useful. It was noted that some organisations might object to the publication of what might be commercial information.
Consensus in the room seemed to be to make the information available but that it should be taken to the mailing list for further discussion.