RIPE 25

Please mail comments/suggestions on:

• content to the Chair of the working group.
• format to webmaster@ripe.net.

Minutes for the DB WG meeting
RIPE 25, Amsterdam, NL
**1st DRAFT**, 9-Oct-1996
Chair: Wilfried Woeber
Scribe: John Crain
Participants: 51 (according to the sign-up list)
A. Administrative stuff
John Crain offered to take notes. Thanks a lot, John!
The proposed agenda was agreed, including the following additional items:
- Input from the DNS-WG and
- Input from the Local-IR WG
both for agenda item Y. General input from other WGs and
- advisories: in aut-num: objects
for Z. AOB
B. DB-SW status report by the RIPE NCC
Carol Orange offered the report on the state of the RIPE Database and the
DB-SW. Version 2.0 of the software was released recently and put into
production at the NCC.
Important new features are:
- inverse lookup (whois -i)
- the package is now fully classless
- support for near real-time-shadowing
(As an aside, a DB-Workshop was offered on Monday morning.)
More details about the growth of the DB and the increase in the number of
objects, etc. were shown on the slides.
[ These slides are expected to become available soon ]
[ at ftp://ftp.ripe.net/ripe/presentations/ ]
Activities for the short term future are
- produce documentation
- fix any version 2.0 bugs
- try to improve consistency
In general, version 2.0 is found to run very well.
Sabine Dolderer reported on problems with the handling of old (invalid)
handles. This is one of the known problems. Sabine was asked to report the
problem to the ripe-dbm@ripe.net mailbox.
C. DB consistency and sanity checks
Is it worthwhile doing more sanity checking?
There was general consensus that the quality and consistency of the data in
the RIPE-DB should be improved. The group formally supports this activity
which is also part of the RIPE NCC Activity Plan for 1997.
A project has already been set up with the Free University of Amsterdam to
look at the consistency issues in general. Students may wish to interview
selected users.
The Local-IR staff and the users of the Routing Registry are expected to
contribute to this activity.
The group then identified a couple of obvious inconsistencies which should be
checked, either at the time of a transaction or on a regular basis. E.g.
- person/role objects being refered to no longer exists
- persons (multiple) with and without nic-hdls.
- person objects which are no longer referenced by any other object
(proposal to eventually remove these objects,
considering the age of the object)
- multiple route objects with different origin,
where there is obviously no trasnition and/or multi homing.
The various checks, when they get implemented eventually, should at least
generate warnings, both at the time of an update and on a regular basis.
The logistics (frequency, identifying the proper recipients for the
warnings, etc.) need more work.
The discussion of a potential reservation of some NIC-Handle types (like
AUTOxx-RIPE, ROLExx-RIPE, etc.) led to the conclusion
- that there is no need for special handling of role: objects
- and that AUTOxx-RIPE should be reserved to avoid confusion when
requesting automatic handle assignment with the AUTO-xx mechanism.
Niall O'Reilly suggested that the various registries should help with the
transistion process by changing old person objects that are (mis-)used to
define a role into correct role objects.
D. Inverse lookup discussion
Is automatic recursion still useful?
Just observed as a fact, quite a few people have aliases defined to disable
the automatic recursion for their environment.
However, for compatibility reasons and because most of the casual users are
expected to need the information provided by the recursion, the decision was
to stick with the current default (recursion is on by default, use -r flag to
disable it).
However, the behaviour of the software when doing an inverse lookup ("-i"
flag) is to be changed to imply "-r" (recursion disabled).
Discussion then moved on to find out wether inverse lookup should be allowed
for all attributes. Common feeling was that it is not necessary for all
attributes, but it might be useful to implement for a couple of additional
attributes. In order to find out about the real need, a discussion on the
DB-WG list should be started and the NCC was asked to look at the logs to
find out about "popular" failed queries.
Kurt Kayser asked about the software behaviour and the timing involved when a
"server running at low priority" message is issued.
This message is issued for general queries that (potentially) produce a large
number of hits. As long as the TCP connection is up, it's still working.
E. Documentation
Ambrose Magee was then introduced as the new primary maintainer of the DB-SW.
He reported on the proposed structure of the Documentation for the RIPE
Database objects, the usage and the software. The group endorsed the concept
with some minor proposals for improvement and stressed the importance of the
documentation, and in general, the importance of consolidation vs. new
functionality.
In particular, the proposal is to have a main document that is stable and a
set of appendices with things that may change or require more freequent
updates.
[ The slides are expected to become available soon ]
[ at ftp://ftp.ripe.net/ripe/presentations/ ]
One of the suggestins was to seperate the advanced sections (e.g. on how to
obtain the database etc.) from the general user documentation.
Nigel Titley proposed to start working with the sections on the whois client
and utilities and move that information to the beginning of the documentation
Bernhard Stockman asked for a list of all active objects (Index), including
definition of the syntax and the also the semantics.
Daniel again proposed to add that functionality to the software itself.
This is already on the consolidated wish-list, and to be implemented by
adding a whois -T with -v and possibly whois -T to report all objects.
whois -T is already available for listing the schema for an individual
object.
F. New functionality
Even thouogh there was some discussion on new functionality, like a URL:
attribute and amendments to a cgi script to provide access to the data via
html, it was stressed that for the time being consolidation should be the
priority instead of new functions.
The maintainers of the DB-SW were asked to maintain and publish the
"consolidated wish-list" and the "known bug list".
Y. General input from other WGs
DNS:
There was concern over potential conflicts between information in RIPE
Database and the TLD's internal databases.
Becuase of that potential conflict, some TLD administrators do not register
their secondaries in the RIPE DB. Referal to their database would be useful.
Daniel Karrenberg reported that this referal mechanism is already on the wish
list. No design work has been done yet.
There is a couple of potential implications, e.g. the idea to implement the
referral for other (all?) objects.
Guy Davis observed that it might be useful to do a more specific search on
hosts/domains for DNS.
Daniel Karrenberg was in favour of more specific, but has mixed feelings on
referral because of all the different whois initiatives within the Internet.
Thus he suggested to implement a quick fix for the top level domains only.
Janos Zsako thought that the referral should be implemented in the server not
in the client!
Wilfried Woeber observed that the referral approach can only be useful if
most TLD's are willing to supply an interface for whois. There was an
indication of considerable interest to offer access to the local TLD data.
Local-IR:
Mandatory attributes (as described in the regsistry procedures) should be
made mandatory in the database (enforced by the software).
In particular the status: attribute in inetnum: objects and the nic-hdl:
attribute in general should be made mandatory.
Of course, this implies a major clean-up of the database by the LIR's!
Daniel Karrenberg observed that initially this will only be applicable for
new objects. The clean-up will come later.
Kevin Hoadley asked for some time to implement the necessary changes to local
scripts and procedures. The following discussion led to a proposal to start
enforcing this on the 1st of January 1997.
A. Blasco Bonito asked about potential implications of making the 'status:'
attribute mandatory.
Carol Orange suggested to define an additional value for the status: (USED?)
to distinguish between address space allocations, assignments and usage.
A. Blasco Bonito's comment that
"The general attitude of LIR's who are large providers is to assign
to other smaller providers. These then distribute to their
customers."

prompted Daniel Karrenberg to state that
"If this is the case then they are not following the registration
policies."
A mandatory status: attribute has implications that have to be discussed
in more detail.
Z. AOB
Brian Renaud proposed to obsolete the advisory: attribute for aut-num: objects.
For 'route:' objects, these atrtributes should remain valid.
Ther was general agreement and the NCC was asked to implement that change.
Following up on a mail received from David Kessens, ther was a review of the
various mailing lists that dal with different aspects of the database
business.
These are:
DB-WG
DB-BETA
RRIMPL
Daniel Karrenberg described the scope of these lists and observed that all
three have their own specific use:
- DB-BETA is for people running new code.
- DB-WG is for architecture discussions
- RRIMPL has a wider scope
Bugs in the released version of the RIPE DB-SW should be submitted to
ripe-dbm@ripe.net
discussions about details of running new code should go to db-beta@ripe-net.
Sabine Dolderer observed that if there are two maintainers then the "weakest"
one is used.
Daniel Karrenberg pointed out that there is no hierarchy involved.
The software just scans all entries and tries to find a match. The first
match found is honored. This is in line with the current concept and design.
This is the correct behaviour as all maintainers are equally authorized. To
allow specific maintainer functions is at the moment beyond the functionality
of the DB.
Appendix: New actions
[The relative numbering is going to change to match the full meeting minutes]
Action (1) on Wilfried Woeber and Carol Orange,
To come up with a technical proposal for better DB consistency checking.
Action (2) on all WG members,
To think about implications of the proposed DB consistency checking and to
provide input.
Action (3) on RIPE NCC (Carol Orange, Daniel Karrenberg),
To report about the FUA findings (on DB consistency) at next ripe meeting.
Action (4) on RIPE NCC (Carol Orange, Daniel Karrenberg),
To document the approach to find and change references to person objects in
order to support migration to mandatory handles (using inverse look up and
"search and replace") and send it to the list.
Action (5) RIPE NCC (Ambrose Magee) (time allowing),
To implement the change that "whois -i ..." implies "whois -i -r ..."
Action (6a) on Wilfried Woeber,
To ask on the DB-WG mailing list about the need of improved inverse lookup
functionality (more attributes allowed for -i).
Action (6b) on Daniel Karrenberg,
To look at query logs for "failed" -i attempts.
Action (7) on Ripe NCC (Ambrose Magee),
Produce the RIPE-DB Documentation a.s.a.p. and according to the agreed
structure.
Action (8a) on RIPE NCC (Carol Orange),
Publish the "known bugs" list, on the Web or on the FTP-Server.
Action (8b) on RIPE NCC (Carol Orange),
Publish the "open issues" list (consolidated wishlist) on the Web or on the
FTP server.
Action (9) on RIPE NCC (Ambrose Magee, Carol Orange, Daniel Karrenberg),
To propose and implement (a.s.ap.) a referral mechanism for TLD domain:
objects (only).
Action (10) on Wilfried Woeber and the RIPE NCC,
To make a proposal on the technical and procedural requirements of making
the status: attribute for inetnum: objects mandatory.
Action (11) on RIPE NCC (Ambrose Magee),
To change the DB-SW to obsolete the advisory: attribute in aut-num: objects.
Action (12) on RIPE NCC (Ambrose Magee),
To add mailing lists with their descriptions to the database documents.