This is the updated minutes of the RIPE-23, Jan.96, DB-WG meeting. Corrections submitted by David Kessens wrt "network updates" and "security" have been included. Best regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ 0. Administrative stuff Kurt Kayser, ECRC, volunteered to take notes. The WG meeting was split into two sessions - part 1 to deal with currnt topic, problems and ideas - part 2 the more traditional stuff The proposed WG-agenda was accepted. 1. Databases and registries B. Manning's review of the 192.0.0.0/8 address range prompted a brief discussion of where the authoritative information should be maintained. The general feeling was that networks used in Europe should be documented in the RIPE-DB. [ A comment was received after the WG-meeting to ask the Internic (and other registries?) to expand the standard referral text ("The InterNIC Registration Services Host contains...") to include pointers to the RIPE-DB and maybe other registry sources. ] From the user's point of view it would be very convenient to send updates to a "local" database and have the software forward the message(s) to the appropriate database(s) according to the source: attribute. Currently the RIPE-NCC holds copies of the following databases: RA, MCI, APNIC, CA*Net - but NOT the InterNIC. While things are to improve with the introduction of the shadow-dbs, mirror copies are always sort of out-dated by definition. RIPE intends to have a 10min delay. Other problems identified: - uniqueness of names / keys across different databases - lookup and processing of entries from more than one DB (e.g. evaluate AS-Macros from different DB...) -> minority problem for the time being. - quality control on information, . like duplicate entries alert, . automatic handle assignment, . semantics for more than one person object for a given individual . Registry ID information is maintained manually, this might change by building links to objects in the public database. 2. User interface(s) - access to the data in a more clever (selective) way by WAIS and/or WWW. A. Blasco Bonito and Paolo Bevilacqua have a test-version available for a WWW interface that supports logical AND and OR of keys. - whois "help" gives on-line documentation hypertext version being considered - An on-line survey form is available via the RIPE-NCC web pages, you are invited to use it to describe your wishes for access to data kept at the RIPE-NCC. - RADB/Merit has a web interface for queries and updates, although this obviously works for auth: NONE or MAIL-FROM only - proposal: put a pointer to whois "help" into ripe-104++ 3. Authorization and Security DFK reports that development work is on the action list (PGP facilities to be integrated) but there is still a severe lack of resources. Additional help is needed to make real progress, because design work is necessary first. Th Key management would most probably be done according to the Merit approach. We might benefit from (Euro-)CERT activities? In more general terms, if we want to see development progress faster than in the past, then we have to come up with clearly defined needs and a proposal for a devlopment project with additional resources. 4. DB-SW report David Kessens offered the traditional database software report. The slides can be obtained from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DB-REPORT.ps.gz Another set of slides for the In-Addr-Check handling is available from ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DNS-INADDRCHECK.ps.gz - beta version V1.1 that allows (close to) real-time mirroring is available. At the time of writing these minutes (4-MAR-1996) the distribution is at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.1beta2.tar.gz - requests to run a mirror copy are to be sent to ripe-dbm@ripe.net - other changes include . support for the BSD DB package . a password controlled mechanism to overrule normal security mechanisms (e.g. for adding maintainers and the like) . "network updates" are now fully supported by the RIPE-DB SW. Fully supported means: "If your address is in the RIPE-DB access list" However, this is a very powerful method and currently does not provide enough data for the logs to track down problems. For further study, before being made available to the community at large. . less memory consumption In conjunction with the mirror capability, the software has to keep track of individual object creations and updates. The mechanism that is currently used is not suitable for long-term consistency (because the sequntially increasing values are expected to suffer from wrap-around, eventually). Thus a stored: attribute was proposed and accepted. stored: <NEW | UPD> <Date> <Time> <Serial> Inclusion of the authorisation method used and the source of the update was then asked for. DFK is going to circulate a detailed proposal. In general the NCC proposes to use a keyword based mechanism on the subject: line of DB update messages to request special processing. This should eventually obsolete the multiple e-mail addresses, like auto-assign@ripe.net, which are not widely known and their use is not always properly enforced. 5. Hierarchical authorization Implementation of hierarchical authorization is initially planned for . domain name space . IP-Address-Ranges for registries . origin AS for routes Moving the description of the hierarchy and the transactions allowed at a particular level to a maintainer object was preferred over an alternate method of using a scope: attribute. 6. Handles, Object review Eventually the assignment of NIC-Handles (more precisely: RIPE handles) is being implemented. David shall circulate a propsal about the logic and the semantics to the mailing list. Reverse lookup (for person objects, at least) is being worked on. The country: attribute is being redefined to allow multiple lines with multiple values, to better reflect the real scope of an entity (like address blocks from a regional registry, AS numbers, etc.) The Role: or NOC: object needs more thought and detailed definition. There is still some uncertainty whether a full-blown new object (with a handle) is really needed, or whether the person object can be extended. Input was received from Michael H. Behringer that proposed a common format for describing contact information, coverage and emergency preocedures. This object is to be re-visited on the mailing list and a decision about implementation is being sought on the list. The proposal for an extension of the inet-rtr: object was briefly discussed. The original intent was to allow for a description of Mbone routers. However, extending the concept could be very useful for describing all sorts of peerings, like Mbone, IP-over-IP, IPnG, and the like. Due to the fact that there is already a couple of tools which read the peer: attributes, it might be wise to not change the peer: attribute as currently defined (but to eventually make it obsolete) and to invent a new attribute with the peering protocol ID as the first element, the address as the second element and then the specific information. To be discussed in more detail on the mailing list. url: it was agreed to add a new (optional) attribute to all objects to allow for inclusion of URLs. The details to be worked out after some more tests. Format could either be plain HTML or general URI syntax. 7. Input from other WGs Already covered (see inet-rtr: for Mbone) 8. AOB None. Meeting closed. ________________________________________________________________________________ List of new actions: Daniel Karrenberg: To circulate a detailed proposal for the stored: attribute. David Kessens: To circulate a detailed proposal for the automatic handle assignement. Wilfried Woeber, Michael H. Behringer: To initiated discussion on the mailing list about the need and possible format for a role: or noc: object. Wilfried Woeber: To initiated discussion on the mailing list about the extension of the inet-rtr: object. WW, 21.3.96