Dear all,
this is the draft minutes of the Database-WG meeting(s) at the 17th RIPE
meeting.
Any input and comments welcome, especially from those being affected by
these things in one way or the other :-).
Best regards,
Wilfried.
-------------------- start of draft minutes --------------------
17th RIPE Meeting:
Draft minutes for the DB-Working-Group meeting 25.1.1993, Amsterdam.
-----------------------------------------------------------------------------
Due to the scheduling (and the un-avoidable overlap) of some WG meetings,
the items on the agenda were treated in a different order than originally
proposed. However the minutes follow the original ordering.
0. Opening, Scribe, Admin
The DB-WG meeting was opened and Ruediger Volk volunteered to take notes.
As a direct result of the preceding meeting of the Routing-WG and following
other discussions the proposed agenda was amended (DB statistics for
Domain-Object, maintainance of e-mail attribute and .forward files for
guarded objects, timing considerations for guarded objects and values,
aspects of ownership of objects and deletions and inter-dependancies).
1. New Databse software
1.1 . current status
Marten Terpstra gave a concise report on the current state of the "new"
database software. Due to timing constraints (and the lack of documentation)
there is still no official distribution of the "New DB Software". However it
has already been successfully installed at a couple of sites.
The slides for the presentation can be found in
ftp.ripe.net:ripe/presentations/ripe-m17-marten-DB.ps.Z
1.2 . experiences
No operational problems were mentioned. Operation of the software, including
the organizational environment, is going very smooth and was generally
appreciated.
1.3 . documentation (who, how, when, what)
Documentation is still missing. A new effort is needed and will be made early
February. It has to be taken into account, that Marten Terpstra will primarily
work on the PRIDE project, reducing his involvement with the DB software.
Action (Wilfried Woeber, NCC): produce the necessary documentation for the
new DB software.
2. RIPE-Handles
RIPE-Handles are urgently needed to make progress in the area of Database
Exchange. Several possible methods of assigning these handles were discussed.
the group reached consensus that the RIPE-Handles will be of the form
RIPE-XYZ9999.
It was decided that from the DB's point of view, there exists only ONE
handle: the RIPE-Handle. Thus this handle is stored in the person object
in the "nic-hdl:" attribute.
For the initial population/conversion of the current entries, the value of
the NIC-Handle will be taken and converted to a RIPE-Handle by appending the
string "-RIPE". E.g. the NIC-Handle for Wilfried Woeber (WW144) will be
converted to form the RIPE-Handle (WW144-RIPE). This conversion will be done
only once for the inital population. There will then be a short period, when
missing handles can be provided by means of "vanity-handles". After a
to-be-announced flag-day, RIPE-Handles will be required for any operation on
person objects in the Database. Any vanity handles used MUST be properly
registered with the NCC! The same syntax has already been adopted by the
JPNIC and the AUNIC.
*** Please note that during the discussion (by accident) we all were talking
about a prefix format ***
The NCC was mandated to circulate an updated proposal, including operational
aspects, and after a short review-process (e-mail), go ahead with the
implementation.
Action (NCC): update and re-circulate the RIPE-Handle proposal and then go
ahead with the implementation.
3. PRIDE - DB Interaction
Editorial comment: RIPE-81++ was treated in the Routing-WG.
Currently there is no real pending issue with regard to the interaction
between the PRIDE project and the RIPE-DB. After discussing possible future
modifications or additions to DB objects, the NCC was mandated to go ahead
and implement changes/additions to support the PRIDE project (like the hidden
flags/options), unless there is a direct influence on operational aspects or
changes to the user interface to the RIPE-DB.
4. Future needs
4.2 . Delete Operation vs Guarded Field interaction
Various aspects of implementation of guarded objects were reviewed.
With regard to possible "delete:" operation on network objects that are
tagged with a guarded AS-value, consensus was to automatically notify the
guardian of the AS-value. Changes to such objects do NOT generate a
notification message. This functionality can be achieved by using the
"notify:" attribute. The "notify:" attribute for an object is evaluated
before the update is made. The technical issues of RIPE-81 was treated in the
Routing-WG.
Generally the transaction of deleting an object must be described.
The document with the proposal for implementing guarded attributes is to be
updated and recirculated for comment (e-mail, 14 days comment period). Then
the NCC goes ahead with the implementation as soon as possible.
Action (NCC): update and re-circulate the Guarded Fields proposal and then go
ahead with the implementation.
4.3 . Phase-out of RIPE-60 stuff
Jean-Michel Jouanigot continues to coordinate the migration to the RIPE-81
functionality. Any technical issues treated in the Routing-WG.
4.4 . Tools
A proposal to have a certain kind of "template-mode" for checking and/or
updating database objects was discussed. Several possible ways of
implementing this were discussed (like a special flag for the whois-client,
an interactive method at the NCC, providing a full template for further
processing). Any solution proposed should be usable on most platforms.
Action (NCC): investigate and propose facilities for a "template-mode" to
support the maintaining database objects.
4.5 . Syntax checkers (distributed, and/or @ the NCC)
The need for syntax-checking facilites for objects was again stated. The NCC
was asked to look into providing this functionality and come up with a
proposal.
Action (NCC): Investigate and propose a syntax-checking facility for the new
database software.
5. New/Revised Objects
5.1 . CLNS Routing "dom-prefix:"
Henk Steenman provided an introduction to the current version of the proposal
to have a database object for CLNS Routing. The only technical amendment
discussed was to present the CLNP addresses in the format of
xx.xxxx.xxxx.xxxx (no trailing dots). The NCC may have to review the current
shell of scripts supporting the database operations for limitations in
line-length.
The NCC was mandated to go ahead with implementing this object after another
short round of review (e-mail) of Henk's updated specification.
Action (Henk Steenman): update and re-circulate the "dom-prefix:" proposal.
Action (NCC): implement the CLNS Routing Object.
>>>>>>>>>>>> I'm going to ask Henk to provide the (updated) proposal for the
presentations directory!?
5.2 . status of "connect:" and value "LOCAL"
Decision about the future of the "connect:" attribute for a Network Object
was postponed after full deployment of the RIPE-81 stuff. It is expected that
the "connect:" will be phased out and be replaced by a different mechanism
(community?). The "connect:" attribute is no longer mandatory.
5.3 . Domain Object
The status of the Domain Object was reviewed, prompted by the fact of poor
coverage in the database. Again the object was felt to be useful, although
currently there is little operational influence of registering (or NOT
registering) domains in the database. Consensus was to ask the DNS-WG to
review and maybe update the definition of the Domain Object.
Action (Francis Dupont): Have the DNS group review the Domain Object and come
up with either a recommendation for retirement or with an updated
functionality
5.4 . others
The "notify:" attribute is already implemented and is already used by the
database software.
The "maintainer:" attribute is already implemented but currently not used by
the databse software.
6. Exchange Format
6.1 . current status
No progress has been made due to the lack of RIPE-Handles. Can be progressed
after implementation of RIPE-Handles.
6.2 . recommendations for further action
As an aside - the group propsed to NOT enforce uniqueness of network names.
7. DB statistics (Domain-Object)
Having stistics about the DB coverage of domains was seen to be potentially
useful. Postponed to wait for the Domain Object review by the DNS-WG.
8. Maint. of e-mail: and .forward for guarded objects
After evaluating possible szenarios it was decided that an automatic
modification of either the "e-mail:" attribute of a guarded object or the
.forward file for the guardian's account is not desirable. Responsibility of
the maintainance remains with the guardians.
9. Timing considerations for guarded objects, values, secondary DBs
Some operational issues of implementing guarded fileds were reviewed. Aspects
discussed in more detail were:
- timing and interlock: Some mechanism must be set up by the NCC to allow for
checking the merge/update status of the current version of the database.
This should allow for an automatic delay of retrieving the DB for local use
and/or providing read-only copies. The NCC will come up with a technical
proposal how to do this.
- change control: in order to preserve the update history for databse objects
a structured scheme was proposed. This method preserves the "changed:"
attributes supplied by any manual update process. In addition to that any
automatic up-date and/or merge operation done by the database software
maintains a single related "changed:" attribute describing the "agent"
performing the modification. From a formal point of view, regular
maintainance and/or merge operations are NOT treated as update operations,
thus e.g. they do not trigger (automatic) notification messages.
Action (NCC): Propose and implement a mechanism to check the current state of
the database with regard to garbage-collection and merging of
guarding values.
Action (NCC): Propose and implement a mechanism to properly keep track of
individual updates of objects and automatic merge/modification
operations.
10. Deletions, Ownership of Objects, Interdependency
This was a more general discussion, focussing on issues of "ownership" of
objects, inter-dependency of various components and quality of the
information in the database.
>From a formal point of view, there was agreement that we should stick with
the concept that the responsibility for maintaining objects remains with the
owner of the object. From an operational point of view it was felt necessary
to perform automatic modifications to certain attributes of an objects. In
the long run this could eventually lead to splitting objects along the lines
of maintainance. This is for further discussion.
Concern was voiced that we do not have the concept of winding down the use of
methods, removing out-dated information and/or deleting objects, closing
guardian's accounts, etc. It was felt that there is a need to analyze,
discuss and document these issues. For the time being these aspects have to
be covered in individual documents describing certain procedures, in the
long run this should be an intrinsic part of the documentation.
The aspect of "sanity checking" the information in the databse was shortly
touched. Given the current shortage of manpower in the NCC and the important
changes to be implemented in the near future this issue was postponed.
Z. AOB
None.
-------------------- end of draft minutes --------------------
