Dear all,
Apologies for this wide distribution but I think it is important
enough.
This is a reminder that coming Monday the 21st of November, the second
and last step of the RIPE database transition will take place. This
transition is the transition from network number objects that hold all
policy information, to route objects that contain all this
information.
For more detailed info on what exactly will change and how, please
read ripe-123 which is available as:
ftp://ftp.ripe.net/ripe/docs/ripe-123.{txt|ps}
Especially section 5 explains forthe various RIPE database user groups
what is going to change.
-Marten
Dear all,
I am pleased to say that the first step of the RIPE database
transition has been succesfully completed yesterday. Up till now, one
minor and one major bug have been found and fixed and the database
seems stable.
Those who daily ftp the ripe database from ftp.ripe.net may have
found that it was not there this morning. This was a simple typo in
one of my scripts and has been fixed. The ftpable files (the complete
database in ripe/dbase/ripe.db and the split versions in
ripe/dbase/split) are currently generated at around 5:30 (AM for the
US folks ;-) Dutch time, which is currently UTC+1. All database files
ara available as uncompressed and compressed (both normal compress and
gzip) versions. The generation time can be changed if you think there
is a need (earlier, not later).
Those who run a secondary copy of the database may find that the
latest ftpable database takes much longer to index. This is because
the database now includes large provider blocks, and the old software
is not good at handling large blocks. The current plan is to have a
beta release of the software (with some documentation on the changes)
ready this weekend, so you can pick up this software and use it to
index the RIPE database. This version will have all of the classless
and other features as per the database transition plan (T1).
As far as conflicts/problems in the guardian files are concerned, most
of them have been resolved. There are some 15 guardian files left with
problems. These guardians will be approached to correct these
problems.
If you have questions/comments/bugs, please report to me personally,
or to any of the above lists if you think they are interesting for a
larger audience.
Regards,
-Marten
New/Revised RIPE Document Announcement
--------------------------------------
A revised/new document is available from the RIPE document store.
Ref: ripe-123
Title: RIPE Database Transition Plan
Author: Tony Bates, Daniel Karrenberg, Marten Terpstra
Date: 3 October 1994
Format: PS=70350 TXT=35083
Obsoletes:
Obsoleted by:
Updates:
Updated by:
Old:
Short content description
-------------------------
This document guves full details of the transition plan for the new proposed
RIPE database and routing registry objects. Please make sure you are aware of
the details in the document including the actual dates.
FTP Access
----------
All RIPE documents and Internet RFC`s are available via anonymous FTP
from host ftp.ripe.net. Type "ftp ftp.ripe.net".
Login with username "anonymous" supplying your email address as the
password. After logging in, type "cd ripe/docs/" followed
by the command "get filename".
The relevant filenames for this document are:
ripe-123.txt for the ASCII version
ripe-123.ps for the PostScript version
Electronic Mail Retrieval of Documents
--------------------------------------
Documents can also be retrieved from the RIPE document store using a
mail server program. For more information on how to use the program,
send email to: mail-server(a)ripe.net with "send HELP" in the body text.
RIPE NCC Interactive Information Server
---------------------------------------
Type "telnet info.ripe.net". This is a menu driven service allows
the document store to be browsed. After reading documents you are
prompted as to whether you would like to receive an email copy of the
document you have just read. If you would, you simply enter your email
address and the document will be mailed to you.
Below are details of alternative methods of access.
Gopher Access
-------------
The same documents are available via a "gopher" server at
"gopher gopher.ripe.net".
WAIS Access
-----------
There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index
for RIPE documents "ripe-docs.src"
WWW Access
----------
For those who wish to add this home page at the RIPE NCC to their own
customized home pages, it can be accessed as:
http://www.ripe.net
MIME Mail Reader
----------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the RIPE document by
FTP or mail server.
SEND ripe/docs/ripe-123.txt
New/Revised RIPE Document Announcement
--------------------------------------
A revised/new document is available from the RIPE document store.
Ref: ripe-122
Title: Specifying an `Internet Router' in the Routing Registry
Author: Tony Bates
Date: 3 October 1994
Format: PS=37970 TXT=14242
Obsoletes:
Obsoleted by:
Updates:
Updated by:
Old:
Short content description
-------------------------
This document specifies a simple object for detailing Internet routers with the
RIPE routing registry.
FTP Access
----------
All RIPE documents and Internet RFC`s are available via anonymous FTP
from host ftp.ripe.net. Type "ftp ftp.ripe.net".
Login with username "anonymous" supplying your email address as the
password. After logging in, type "cd ripe/docs/" followed
by the command "get filename".
The relevant filenames for this document are:
ripe-122.txt for the ASCII version
ripe-122.ps for the PostScript version
Electronic Mail Retrieval of Documents
--------------------------------------
Documents can also be retrieved from the RIPE document store using a
mail server program. For more information on how to use the program,
send email to: mail-server(a)ripe.net with "send HELP" in the body text.
RIPE NCC Interactive Information Server
---------------------------------------
Type "telnet info.ripe.net". This is a menu driven service allows
the document store to be browsed. After reading documents you are
prompted as to whether you would like to receive an email copy of the
document you have just read. If you would, you simply enter your email
address and the document will be mailed to you.
Below are details of alternative methods of access.
Gopher Access
-------------
The same documents are available via a "gopher" server at
"gopher gopher.ripe.net".
WAIS Access
-----------
There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index
for RIPE documents "ripe-docs.src"
WWW Access
----------
For those who wish to add this home page at the RIPE NCC to their own
customized home pages, it can be accessed as:
http://www.ripe.net
MIME Mail Reader
----------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the RIPE document by
FTP or mail server.
SEND ripe/docs/ripe-122.txt
New/Revised RIPE Document Announcement
--------------------------------------
A revised/new document is available from the RIPE document store.
Ref: ripe-121
Title: Support for Classless Internet Addresses in the RIPE Database
Author: Tony Bates, Daniel Karrenberg, Marten Terpstra
Date: 3 October 1994
Format: PS=36698 TXT=14177
Obsoletes:
Obsoleted by:
Updates:
Updated by:
Old:
Short content description
-------------------------
This document details the added support for classless Internet addresses in the
RIPE database. It details the change in representation and handling of database
objects.
FTP Access
----------
All RIPE documents and Internet RFC`s are available via anonymous FTP
from host ftp.ripe.net. Type "ftp ftp.ripe.net".
Login with username "anonymous" supplying your email address as the
password. After logging in, type "cd ripe/docs/" followed
by the command "get filename".
The relevant filenames for this document are:
ripe-121.txt for the ASCII version
ripe-121.ps for the PostScript version
Electronic Mail Retrieval of Documents
--------------------------------------
Documents can also be retrieved from the RIPE document store using a
mail server program. For more information on how to use the program,
send email to: mail-server(a)ripe.net with "send HELP" in the body text.
RIPE NCC Interactive Information Server
---------------------------------------
Type "telnet info.ripe.net". This is a menu driven service allows
the document store to be browsed. After reading documents you are
prompted as to whether you would like to receive an email copy of the
document you have just read. If you would, you simply enter your email
address and the document will be mailed to you.
Below are details of alternative methods of access.
Gopher Access
-------------
The same documents are available via a "gopher" server at
"gopher gopher.ripe.net".
WAIS Access
-----------
There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index
for RIPE documents "ripe-docs.src"
WWW Access
----------
For those who wish to add this home page at the RIPE NCC to their own
customized home pages, it can be accessed as:
http://www.ripe.net
MIME Mail Reader
----------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the RIPE document by
FTP or mail server.
SEND ripe/docs/ripe-121.txt
New/Revised RIPE Document Announcement
--------------------------------------
A revised/new document is available from the RIPE document store.
Ref: ripe-120
Title: Authorisation and Notification of Changes in the RIPE Database
Author: Daniel Karrenberg, Marten Terpstra
Date: 3 October 1994
Format: PS=50496 TXT=28655
Obsoletes: ripe-096
Obsoleted by:
Updates:
Updated by:
Old:
Short content description
-------------------------
This document represents a major change in the way authorisation and
notification of changes and updates in the RIPE database will be done in the
future.
FTP Access
----------
All RIPE documents and Internet RFC`s are available via anonymous FTP
from host ftp.ripe.net. Type "ftp ftp.ripe.net".
Login with username "anonymous" supplying your email address as the
password. After logging in, type "cd ripe/docs/" followed
by the command "get filename".
The relevant filenames for this document are:
ripe-120.txt for the ASCII version
ripe-120.ps for the PostScript version
Electronic Mail Retrieval of Documents
--------------------------------------
Documents can also be retrieved from the RIPE document store using a
mail server program. For more information on how to use the program,
send email to: mail-server(a)ripe.net with "send HELP" in the body text.
RIPE NCC Interactive Information Server
---------------------------------------
Type "telnet info.ripe.net". This is a menu driven service allows
the document store to be browsed. After reading documents you are
prompted as to whether you would like to receive an email copy of the
document you have just read. If you would, you simply enter your email
address and the document will be mailed to you.
Below are details of alternative methods of access.
Gopher Access
-------------
The same documents are available via a "gopher" server at
"gopher gopher.ripe.net".
WAIS Access
-----------
There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index
for RIPE documents "ripe-docs.src"
WWW Access
----------
For those who wish to add this home page at the RIPE NCC to their own
customized home pages, it can be accessed as:
http://www.ripe.net
MIME Mail Reader
----------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the RIPE document by
FTP or mail server.
SEND ripe/docs/ripe-120.txt
New/Revised RIPE Document Announcement
--------------------------------------
A revised/new document is available from the RIPE document store.
Ref: ripe-119
Title: RIPE Database Template for Networks and Persons
Author: Anne Lord, Marten Tersptra
Date: 3 October 1994
Format: PS=46506 TXT=21385
Obsoletes: ripe-050
Obsoleted by:
Updates:
Updated by:
Old:
Short content description
-------------------------
This document is an update to the network object for the RIPE database.
FTP Access
----------
All RIPE documents and Internet RFC`s are available via anonymous FTP
from host ftp.ripe.net. Type "ftp ftp.ripe.net".
Login with username "anonymous" supplying your email address as the
password. After logging in, type "cd ripe/docs/" followed
by the command "get filename".
The relevant filenames for this document are:
ripe-119.txt for the ASCII version
ripe-119.ps for the PostScript version
Electronic Mail Retrieval of Documents
--------------------------------------
Documents can also be retrieved from the RIPE document store using a
mail server program. For more information on how to use the program,
send email to: mail-server(a)ripe.net with "send HELP" in the body text.
RIPE NCC Interactive Information Server
---------------------------------------
Type "telnet info.ripe.net". This is a menu driven service allows
the document store to be browsed. After reading documents you are
prompted as to whether you would like to receive an email copy of the
document you have just read. If you would, you simply enter your email
address and the document will be mailed to you.
Below are details of alternative methods of access.
Gopher Access
-------------
The same documents are available via a "gopher" server at
"gopher gopher.ripe.net".
WAIS Access
-----------
There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index
for RIPE documents "ripe-docs.src"
WWW Access
----------
For those who wish to add this home page at the RIPE NCC to their own
customized home pages, it can be accessed as:
http://www.ripe.net
MIME Mail Reader
----------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the RIPE document by
FTP or mail server.
SEND ripe/docs/ripe-119.txt
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(a)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
--------------------------------------------------------------------------
Folks,
As requested at the last RIPE meeting, I have setup a test database
for you all to use and get some feeling of how all this works.
Some details:
- the "inetnum" and "route" objects (new format, ie after the split)
will be regenerated every night, and will overwrite any
changes/additions you may have sent in.
- all other objects remain in the test database
- the address to send test data to is:
test-dbm(a)ripe.net
- there is a whois server running on this database on machine
"bwhois.ripe.net", normal whois port 43.
- most of the functionaility of ripe-81++, authorisation, inet-rtr and
all other docs presented at the RIPE meeting has been implemented.
- there are a few things that still need implementation, try:
"whois -h bwhois.ripe.net help" for help and open issues.
- Bugs/Questions please to me directly (or ripe-dbm), or to the list if you
think it is important enough.
- most unix type clients will understand extra options (see the help
for a complete list) as:
% whois -h bwhois.ripe.net -- -L key
or
% whois -h bwhois.ripe.net "-L key"
I will send a similar mail to the local-ir list and all guardians
later this week or early next week, you are the first ones to have a
go at it.
Go!
-Marten
