DB-WG Draft minutes, Lisbon

["Wilfried Woeber, UniVie/ACOnet" <]

  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@localhost
  Computer Center - ACOnet       :  
  Vienna University              :  Tel: +43 1 4065822 355
  Universitaetsstrasse 7         :  Fax: +43 1 4065822 170
  A-1010 Vienna, Austria, Europe :  NIC: WW144
 --------------------------------------------------------------------------