draft minutes RIPE-27 DB-WG (apologies for the delay.)

["Wilfried Woeber, UniVie/ACOnet" <]

  Dear DB-WG !

  Enclosed please find the draft minutes for the Dublin DB-WG meeting.

  I'm very grateful to Joachim and Ambrose for taking notes and for
  providing me with the transcript!
  
  As usual, comments welcome!
  Apologies for the delay in circulating that stuff.
  
  Wilfried.
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Woeber@localhost
  Computer Center - ACOnet       :  **** new PBX ! new phone/fax # ! ****
  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
 --------------------------------------------------------------------------


Minutes Database WG Session RIPE 27 Dublin
------------------------------------------

Chairman:     Wilfried Woeber (WW144)
Scribe:       Joachim Schmitz (JS395-RIPE), Ambrose Magee (AMRM1-RIPE)
Attenders:    12


1. Administrativa

   Joachim Schmitz took minutes, supported by Ambrose Magee who took over
   during the presentations by Joachim. The number of attenders was
   relatively low due to the BOF on Toplevel Domains held in parallel.

   The RIPE 26 minutes from the Database WG are not yet finished. However, a
   rather detailed summary is available and was already circulated.

   Earlier actions:

   Open actions were either completed or the relvant topic was on the
   agenda (referral mechanism, status: attribute)

2. New Functionality of the RIPE Database, Reports, Proposals

2.1 DB referral mechanism (Carol Orange)

   Carol Orange repeated the presentation she gave at the DNS WG session.
   She described a DNS referral mechanism for the RIPE DB. This was one of
   the open issues regarding the RIPE DB and got a high priority on the DB
   action list.  There was consensus in the DNS WG on adoption of the
   proposal by the RIPE NCC. Carol's presentation is available on the RIPE
   ftp server as

ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-referral.ps.gz

   Details of the discussion on the proposal in the DNS wg can be found in
   the DNS WG minutes.  Two points were raised during the disucssion in
   the DB WG:

   - Who might access data of an ISP which are probably partly confidential
     or behind a firewall? This problem is partly solved by mirroring the
     "public" part at RIPE, only.

   - It was noted that measures must be taken to prevent loops if the
     referral mechanism is also implemented at other databases.

   As in the DNS WG, the DB WG found the proposal of the RIPE NCC all right
   and asked the NCC to implement it in the RIPE DB.

2.2 RAWhoisd - Whoisd merging (Gerald Winters)

   In the past development of whois daemons diverged. Namely, the Whoisd by
   RIPE and RAWhoisd of the RA Project differ in many respects. A team with
   representatives from the RIPE NCC (Chris Fletcher, Carol Orange, Ambrose
   Maggee) and the RA team (David Kessens, Gerald Winters) was formed to
   collect input for a preproposal.

   One year ago, the RIPE whoisd was integrated by the RA team with the
   RAWhoisd. The reasons for this were:
   - the RIPE whoisd has an extended interface compared to simple whoisd
   - the RAWhoisd again extends the RIPE whoisd
   - the RAToolSet requires RAWhoisd

   Currently the transition from RIPE181 to RPSL occurs. This adds new
   requirements, and an integration of RIPE and RA was agreed upon. The
   advantages are:
   - the new integrated daemon is a benefit to European RAToolSet users
   - DB users see a consistent interface
   - an extended query interface exists

   Gerald then presented a suggestion for the interface:
   - it should be backward compatible with both whoisd
   - RAWhois commands blend with current RIPE protocol, and no "mode"
     switching is necessary
   - RAWhois should appear as a separate function call in the DB code
     distribution

   The interface might be implemented by adding a new flag to the current
   RIPE whois interface like
                               "-E <extended command>"
   for extended query options. Currently, there are less than 10 different
   extended commands.

   The flag blends well with the current RIPE whois protocol. The values
   of the flag parameter are passed through to the server without
   preprocessing, while old style queries still work.

   There was some discussion on this flag and how to use it. From the
   audience it was suggested that the whois client should be able to check
   which extended functions are available at a given server. Only then it
   can be used without additional manual tests by the user. In addition
   proper documentation of the extended functions is mandatory.

   For implementation of the interface, Gerald pointed out the following
   practical considerations:
   - RAWhois will appear as a function call in the RIPE code distribution
   - RIPE maintains its own code base and software decisions independently
   - Merit maintains the RAWhois module
   The integration of both interfaces was approved by the DB working group.

2.3 DB consistency (Carol Orange)

   Then Carol Orange presented a project plan on DB consistency. A copy of
   the presentation is available from the RIPE ftp server at

ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-dbcons.ps.gz

   In the talk she first gave a taxonomy of inconsistencies. They are mostly
   related to references and person objects. She identified two groups which
   are relevant to prevent inconsistencies: DB maintainers and DB users.
   Prevention measures are:
   - require NIC handles with persons
   - NIC handles are compulsory for references

   When deleting objects many more warnings especially regarding
   references are given. However, the DB software should *not* change
   objects by its own.

   The responsibility for changes remains completely with the data
   "owners". From the audience it was pointed out that, if a person object
   is deleted and there are still references to the corresponding NIC
   handle, the DB software must check also for references if looking for
   free NIC handles. Otherwise wrong references may be introduced.

   As additional measure users must be taught to use NIC handles, and to use
   role objects for references instead of persons in the contact attributes
   because they are more "stable".

   Besides person objects, role objects, and maintainers, a change for the
   inetnum objects was described as well: in the future the "status"
   attribute will be compulsory for inetnum objects. Moreover, a new class
   of "allocated" objects will be introduced based on already existing
   syntax elements, and simplifying the structure. These objects will all
   be managed by the RIPE NCC. However, this new class of objects might
   break existing tools like prtraceroute which reference inetnum objects.
   To find out whether problems may occur the RIPE NCC will inquire on the
   DB mailing list on tools which make use of inetnum objects.

   Finally, the RIPE NCC will initiate a major cleanup of the DB. This
   includes detection of inconsistencies, determination of the
   maintainers, urging them to clean up their objects, and education of
   the users. In this process several issues arise which were discussed in
   the DB working group:
   - How often shall reports be generated? There was no consistent agreement.
     Running checks too often is demanding, and may lessen awareness on the
     user's side. Weekly checks seem to be reasonable.
   - How large should reports be? They should be concise hitting on the spot.
   - How should they be presented? General consensus was that they should be
     presented on the web.
   - How public should the reports be displayed? The general feeling was that
     nobody should be offended by being displayed as bad netizen. Therefore,
     the reports shall not be actively distributed. However, to put a certain
     pressure on the lazy guys, data will be publicly available but must be
     actively fetched.
   - What if no maintainer can be found? A suggestion is to age corresponding
     objects. The open question is how to timestamp the objects to delete
     them after a certain time - the "changed" attribute is not relevant
     enough. Consensus was that the objects should not be left alone.
     However, a final decision is still pending.

   Special advice to the users will include:
   - checking their objects in general
   - replace names by NIC handles in references
   - replace the "notify" attribute by "mnt-by" attributes - this is done to
     avoid spurious mail addresses not linked to any object (mail addresses
     are the only value the notify attribute can take)

   All of the above is comprised in a project plan. In Q3/97 changes in
   the DB software will be implemented accordingly, and user advice shall
   be given on the web server. In Q4/97 the focus is on gathering of
   statistics and reports on the state of the DB. Further evaluation and
   extended plans will be prepared at the end of the year.

2.4 Security and Authentication (Joachim Schmitz)

   Joachim Schmitz gave a presentation on the topic of the RIPE DB and its
   security. It is available from the RIPE ftp server at

ftp://ftp.ripe.net/ripe/presentations/ripe-m27-jschmitz-dbsec.html

   This presentation was originally planned for the previous RIPE meeting
   but dropped due to time constraints. However, it covers a topic which
   comes up again and again: registry databases and security. Some of the
   concerns were already taken account of in the past, e.g. by introducing
   maintainers. A current item also is hierarchical authorisation. In
   addition to these active measures also passive elements like the AUP
   for the DB, or restricted read access were introduced. However, this is
   not enough. The awareness of all possible incidents must be raised, and
   the overall security be improved.  Some issues are a strong
   authentication (an inventory should be made), or arising from the
   distributed form of the DB.

   To get started on this important topic and to ensure progress, the
   chairmen of Routing WG and DB WG decided to initiate a task force. This
   task force shall collect information and define projects. Anybody who
   feels he/she may contribute is invited to participate in this task
   force. Currently, the idea is to try something informally around the
   IETF in Munich, and to have first results by RIPE 28.

   From the audience the question was posed whether certain attributes may
   be hidden in objects, e.g. phone numbers in a person object. However,
   this is also an important contact information. A solution might be to
   make such attributes optional, yet this is only possible to a certain
   extent.

   Another suggestion was to limit distribution of the information
   (especially to avoid spams or address dealers). There was no consensus
   on this question.  However, it is considered as a topic which should be
   dealt with in the security task force.

3. Input from other WGs

   There was some input from the DNS WG, detailed in the presentation by
   Carol Orange on the DB referral mechanism earlier in the meeting.

   In addition, Joachim Schmitz had some input from the Routing WG where new
   elements for authorisation with aut-num and route objects were introduced.

   Details are shown in 
   
http://www.ripe.net/wg/routing/r27-minutes.html

   The most important elements are:
   - Authorisation of route objects in aut-num objects
     An additional "mnt-route" attribute may be added to the aut-num objects.
     The value of this attribute is a valid maintainer. The function is to
     define who is allowed to add/change/delete route objects for the origin
     of the aut-num object.
   - Notification on overlapping route objects
     Notifications will be done on creation *and* deletion. Submitters are
     *always* notified in the success message (by a warning), others are
     only notified if requested. The request is defined by an additional
     "x-notify" ("cross notify") attribute which points to the maintainer
     of a route object. A cross checking within the IRR is proposed.
     The original idea was to put the "x-notify" attribute in the aut-num
     object allowing a consistent description of an AS. However,
     discussion in the audience revealed that it also makes sense to put
     it in the route object. A final decision could not be reached.

   The open issues will be discussed on the DB and Routing WG mailing lists.

4. AOB

   Carol Orange gave a presentation on the RIPE DB survey by the NCC. In
   this survey initiated by the DB WG on the previous RIPE meeting, the
   RIPE community was asked to set priorities for open issues with the DB
   software. Carol's presentation is available from the RIPE ftp server
   at:

ftp://ftp.ripe.net/ripe/presentations/ripe-m27-dbmaint.ps.gz

   There were 18 participants in the survey. The priority list resulting
   from this survey was circulated on the DB wg mailing list. Highest
   priorities were on DB consistency, and communication of the DB software
   to the user (email update feedback, notifications). A project plan of
   the RIPE NCC for consistency was already presented in this meeting.
   Moreover, the RIPE NCC implements more verbosity to the whois interface
   (options "-v", "-t", and "help"), improves contents of email feedback
   from updates, and supplies an "online" help for updates (mail to
   "auto-dbm@localhost" with subject "help")

   The presentation was continued with the DB software status report
   available at 

ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-dbupdate.ps.gz

   Some of the items were already dealt with in the action review at the
   beginning of the session. The sequence of items is determined from the
   DB survey. The presentation was closed with some statistics.

   Wilfried Woeber pointed out that thanks to Ambrose Magee who did a great
   job, a new version of the RIPE DB documentation is available as RIPE
   document RIPE-157.

Agenda
------

A.  Administrative stuff (W.Woeber, chair)
10min
        - volunteering of the scribe
        - WG-agenda bashing
        - handling of minutes and actions

B.  New functionality, proposals, reports
30min
        - Database Referral mechanism (Carol Orange)
        - rwhois compatibility (Gerald Winters)
        - Database consistency (Carol Orange)
        - Security and Authentication (Joachim Schmitz)

C.  DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC)
10min
        - operational changes (handles mandatory)
        - new functionality implemented and bugs fixed
        - documentation (current status, progress)
        - feedback from the users (DB WS usefulness?)

G.  General input from other WGs
10min
        - Hier. Authorisation and Notification in the RR (Routing WG)

Z.  AOB
        - RIPE database survey

Actions
-------

RIPE-NCC: To implement the referral mechanism for domain objects.

RIPE-NCC: To make DB consistency information publicly available (for
          information, no active distribution initially).
	  
RIPE-NCC: To implement the cross notification as soon as the technical
          details have been discussed and agreed.

WW, 16-Sep-1997 17:00
                                  # - # - #