This is the draft minutes for the DB-WG meeting in Lisbon. My sincere thanks are due to Havard Eidnes for doing a particularly good job at taking notes. Any comments welcome! Best regards, Wilfried. -------------------------------------------------------------------------------- Draft Minutes from DB-WG meeting at the 19th RIPE meeting, Lisbon ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Opening Havard Eidnes volunteered to take the minutes. The proposed agenda item "review of DB-WG in the context of a changing RIPE" was moved to the end of the agenda. An item about "review of domain object for in-addr.arpa" was added. 2. The classless database Marten Terpstra from the RIPE NCC gave an orientation of what changes have been implemented and how this can be tested. The major changes are: - Change of representation of IP addresses and ranges in the database, as described in the draft "ripe-clarep" and "ripe-inetnum" documents. There are two new notations, classless prefix such as 192.0.0.0/8 and classless range (currently proposed as e.g. 192.3.2.0 > 192.3.3.255, this covers two class C networks). - Lookups in the new database will return the exact match if it exists, or the first less specific object. There are some options to control the matching: -L return all less specific entries -m return the direct more specific entry -M return all the more specific entries - The database itself has been split into individual files for each object type. - More new query options: -t <type> returns a template or form for the specified object type -T <type> return only objects of the specified type -F do a "fast and raw" return of data, i.e. no post-processing or pretty-printing -S do not add syntactic sugar (such as "accept", "from" etc. in AS object) A beta version of the database software is already up and running. It now consists of some 9000+ lines of Perl code. The software is still undergoing changes to acommodate the updated RIPE-81++ and to add authorization. There is a test server running at rijp.ripe.net which can be used for to become familiar with the bahaviour of the new code. A proposal was made to allow objects to be submitted to this test database, and Marten Terpstra agreed to set it up. These submitted changes will be removed from the database on a daily basis, as the data from the production database is pulled in. Current planning (as of the time of the RIPE meeting) calls for a move to using the new software in early October. The draft documents "ripe-clarep" and "ripe-inetnum" were approved. 3. Authorization Daniel Karrenberg from the RIPE NCC oriented about what changes are being proposed to improve (implement) authorization of updates in the RIPE database. This is being done by introducing: - A "maintainer" (mntner) object describing an entity responsible for a set of objects in the database, and where this maintainer wishes to secure his updates and prevent others from submitting changes to objects maintained by this maintainer going un-noticed. - New attributes: upd-to Send notifications of updates to this address mnt-nfy Basically same as "notify" auth Specifies authentication methods (in "mntner" object) - Authentication methods proposed: NONE no authentication (today's method :-) MAIL-FROM <regexp> update will only be accepted if mail containing a database update originates from an e-mail address matching the regular expression. CRYPT-PW <crypt-str> stores a crypted password, send a "password:" attribute (with the password in clear text) together with each update. A single maintainer can register more than one authentication method. Any individual object can be linked to more than one maintainer entity. The "password:" line(s) in update requests are not considered to be part of an object, thus no password will ever be forwarded by using the notify, mnt-nfy or similar attributes. A question was raised how one could be notified of the creation of new objects in the database. Guardians of communities and ASes will be notified when components are added/changed/removed. Notification will also be given when multiple "route" objects are registered with same key but different origins. However, the addition of a more specific route with a different origin than the immediate less specific route registered, the maintainer/guardian of the AS where the less specific route originates would probably not be notified (this was asked for). 4. inet-rtr (Internet Router) object There had been some recent input from the MBONE group; they wish to use this object to register details about IP multicast routers. However, the inet-rtr object is needed now by the PRIDE tools, so there was consensus that we should approve the doucment as it is. After some more discussions within the MBONE community a written proposal to extend the object is expected before the next RIPE meeting. 5. Database transition The RIPE NCC people summarized the transition issues when going from the old database to the new one. There will be changes in: - schema - procedures - user interface The WHOIS interface and the output from queries will have some changes (e.g. the classless representation is used instead of the old one). The guardian procedures will change; first there has to be an exact match between the entries in the guardian file and the entries in the database. The current database has been cross-checked with the current guardian files, and there are lots of conflicts in this area. When the new database software is put into production, the RIPE NCC will produce "problem" files in each guardian's home directory, and the guardians are strongly encouraged to clear these up before phase II of the database transition. The transition will happen by two "big bangs": B1 and B2. At B1: - the new classless database will be put into production - users of NLC will have to transition to using Merit's ALC program, as NLC will not be upgraded to support the new database. ALC functionality was described as being a superset of NLC. - Guarded objects can be updated under control of the new authorization mechanisms - The RIPE NCC will create prototype "mntner" objects in each guardian's home directory - The RIPE NCC will prepare new "inetnum" and "route" objects in each guardian's home directory Due to logistic concerns, between B1 and B2, updates for networks with allocation and routing information already split into separate objetcs (inetnum/route) will probably not be permitted. At B2: - complete transition to the new database Proposed time schedule: B1: early october B2: 4-6 weeks later The issue of how queries posed in the "old style" would be interpreted ensued -- the question is whether e.g. 128.39.0.0 should be interpreted as 128.39.0.0/32 or 128.39.0.0/16. In most cases the end result will be the same, since the immediate less specific object will be returned, although some expressed the opinion that the latter of the two interpretations would cause less confusion. The RIPE NCC held the opinion that /32 should be used, but apparently this needs to be discussed more. The database aspects of RIPE-81++ were approved (although the range notation may change). A proposal from the RIPE NCC to add "as-name" to the AS object was approved. 6. Domain object for in-addr.arpa Concern was expressed that with the advent of the classless database we may end up registering duplicate information, since the in-addr.arpa delegation hierarchy can now be implemented "properly" by use of the "inetnum" object. After a short discussion it was agreed that the RIPE NCC would review the opinions and come up with a new domain object proposal to cover this. 7. Time stamps in the database The people from Merit had expressed a desire to store more fine-grained time stapm information in the database, and had proposed to do this by adding hhmmss at the end of the "changed" attribute. This was hotly debated and contested from some parties, but there was consensus that there is a need to ensure that older updates stuck in mail queues would not be released later and overwrite more recent update requestss. To solve this, it was decided to add an optional sequence number to the "changed" attribute after the date string. This sequence number can, of course, be derived from local (at the origin of the update) hhmmss information. However, no time semantics of any form are implied. The people from Merit also wished to use this in some situations to produce a "consistency snapshot" of the database at a given time (in retrospect). Again it was contested whether the proposed simple mechanism would solve that issue. There will probably also be a separate new attribute called "stored" or "processed", which will record when the object was actually entered in the RIPE database (local time at the RIPE NCC). 8. RIPE handles This activity has been put on hold due to RIPE NCC overload. RIPE handles can be assigned on a case-by-case basis as the need arises. There are however too little resources available to carry this through together with the imminent database transition. 9. Ownership of objects This issue was overtaken by events, ref. the notify/maintainer changes. 10. Inverse recursion A query for added functionality had been raised; the trigger is the ability to pose a query like the following one: "give me all the objects where person XX is registered as a contact person". Marten Terpstra said this would probably take little time to add to the new database, and he would look into finding the extra time to do this. 11. Data exchange between IRs This has also been put on hold by the RIPE NCC, due to the lack of RIPE handles (see point 8). The advent of rwhois should improve this situation, and the entries for the blocks 193.* and 194.* will point at the whois server at the RIPE NCC. Otherwise a full merge of the databases (basically InterNIC and RIPE NCC) is difficult, since there are many conflicts between these databases outside of the 193.* and 194.* blocks, and who to "trust" in each case is uncertain. 12. CLNS routing registry Put on hold since the need for this is unclear, and the RIPE NCC do not have many resources to put into activity. There has also been a lack of input from the interested parties. Nevertheless, the functionality already implemented will be carried over to the new software and remain usable. 13. Review of DB-WG in the context of a changing RIPE The DB WG chairman expressed a desire to have the possibility to arrange at least a single non-parallel session during each RIPE meeting dedicated to the DB issues, since much of the work in other WGs touch on the DB. 14. AOB None. Meeting closed. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Wilfried.Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------