This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
Who should do entries in RIPE database?
- Previous message (by thread): Who should do entries in RIPE database?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
woeber at cc.univie.ac.at
Fri Oct 31 16:54:13 CET 1997
Folks, thanks for bringing this up for discussion! >The other point is to prevent the RIPE database from further pollution. >There should be some settings to guarantee this. What is your opinion: >should I post my suggestions just to 'lir-wg at ripe.net'and 'db-wg@ >ripe.net' or in addition also to 'local-ir at ripe.net'? I'll try to summarize from my point of view (both as DB-WG chair, Local-IR rep and of course as a dumb user :-) We have long since worked from the assumption that the "owner" of an object is responsible for it's on-going maintenance. We have always felt, that tigthening the rules too much would have a negative impact on all parties' willingness to register (at all) or to perform updates regularly. Then we introduced measures to protect *existing* objects by limiting the sources where updates (+ deletes :-) are accepted from (maintainer mechanism). This is particularly relevant for the IP Registry and for the Routing Registry. The next step has been protection of hierarchies in the object space with the mnt-lower mechanism, in particular for the Domain-Registry. Right now the Routing-WG and the NCC are working on the implementation of cross-notification for the routing registry. All of these mechanism can by now (or very soon) be used to ascertain a useful level of security and update control, including the referenced objects. This leaves us with two major weaknesses - or features: - A considerable percentage of the objects is not yet protected by the mechanisms which are readily available, and "tightening" the ropes requires a more careful approach by the various registries - leading to more work, in the end. In particular if we think about "owning" and protecting the person objects as referenced by data for the various registries.... - Nothing is there to prevent *any* party to put e.g. person objects into the DB. (And I certainly appreciate that myself!) Also, I suppose some other types of objects can be put into the DB without problems, unless they are in dircet conflict with one of the well-managed object spaces for a particular registry. This leaves us with a legacy of entries from the "Dark Ages" of DB deployment and with the on-going pollution of object space by way of "user error". This aspect is being addressed by the DB-Consistency Project. We work towards offering mechanisms to identify inconsistencies as described by a "catalogue of frequent problems" as well as by coming up with the logistics to repair these deficiencies. Again, to be successful, the registries shall be required to spend (considerable?) effort to participate in that activity. So what can be done on top of that to improve the situation? - We can offer improved mechaisms to deal with identification and authentication: this is on the agenda for the DB-Security Task Force. - We can try to improve the user interface. In particular to help the end-users to avoid the popular crimes like putting in just another person object as soon as there's a new reference: We (the AT-TLD administration) are in the process of designing and prototyping an interactive interface that should prevent most of these incidents. We're in contact with the NCC to determine the usefulness of that approach. Please stay tuned. - Last but not least we could think about "closing" the DB for public, that is anonymous, update or registration of objects. I think *that* would require *very* careful consideration, discussion, and establishing a broad consensus across (all of) the RIPE-WGs. I'd also expect considerable impact on activities like RIDE. But it is certainly not impossible to get that discussion going. Although (wearing no hat at all right now :-) I do not see a pressing need right now - taking into account that we have a set of mechanisms in the works to improve the situation. Comments and input welcome! Apologies for the lengthy speech... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 --------------------------------------------------------------------------
- Previous message (by thread): Who should do entries in RIPE database?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]