db-wg
Threads by month
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1997 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1996 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1995 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1994 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1993 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1992 -----
- December
- November
- October
January 1994
- 5 participants
- 4 discussions
Please find enclosed a DRAFT copy of a document describing the Guarded Field
procedure. This gives details of both the process for updating guardian files
as well as how conflicts are handled.
The current status is that the software is in final beta test and all the
auto-generated "AS" accounts/files have been generated (see doc for more
details).
Our plan is to turn the "guarded field" software on in the database on
February 7th. There will be a short introduction for both the paper and
implementation given in the routing working group session at next weeks
RIPE meeting.
All comments welcome. We plan to agree and close this document at the RIPE
meeting.
See you next week.
--Tony.
Support of Guarded fields within the RIPE Database
* DRAFT *
Tony Bates
Document-ID: ripe-1nn
1. Introduction
The RIPE database contains several significant attributes which make
it well suited for use as part of operational procedures and confi-
guration. Most significantly are the attributes which make up the
RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely
the "aut-sys" and "comm-list" attributes. For these attributes to
be of use to service providers they must be:
o Properly authorised.
o Efficient for both maintainers of the attributes and the main-
tainers of the whole database.
This document describes an overview of the RIPE database attributes
which are guarded, the procedure for updating these guarded attri-
butes and the general use of "guarded" fields within the RIPE data-
base.
2. The Database Guarded Attributes
All the guarded attributes currently supported in the RIPE database
are contained within the "inetnum" or network object. However, the
association corresponds to their relevant guarded database objects.
If we look at a simple example this becomes clear:
inetnum: 192.87.45.0
netname: RIPE-NCC
descr: RIPE Network Coordination Centre
descr: Amsterdam, Netherlands
country: NL
admin-c: Daniel Karrenberg
tech-c: Marten Terpstra
connect: RIPE NSF WCW
aut-sys: AS1104
ripe-1nn.txt January 19, 1994
- 2 -
comm-list: SURFNET
ias-int: 192.87.45.80 AS1104
ias-int: 192.87.45.6 AS2122
ias-int: 192.87.45.254 AS2600
rev-srv: ns.ripe.net
rev-srv: ns.eu.net
notify: ops(a)ripe.net
changed: tony(a)ripe.net 940110
source: RIPE
This shows that the RIPE-NCC network belongs to autonomous system
1104 and is in a community known as SURFNET. This is valuable infor-
mation that could easily be used for example for routing policy pur-
poses (as well as other operational uses). Currently support for the
following set of guarded attributes is implemented:
aut-sys
The "aut-sys" attribute has a direct mapping to "aut-num"
objects as defined in RIPE-81. That is the Autonomous System
(AS) that the network number is a part of. As defined in RIPE-
81, a network can only belong to one AS and hence the "aut-sys"
attribute can only contain one AS number. The syntax of the
"aut-sys" attribute is:
AS<positive integer between 1 and 65535> (1). i.e. AS1104
comm-list
The "comm-list" attribute has a direct mapping to "community"
objects as defined in RIPE-81. A network can belong to more
than one community. The syntax of "comm-list" is:
Multiple text strings which cannot start with "AS" or any of
the <routing policy expression> KEYWORDS defined in RIPE-81.
routpr-l (2)
The "routpr-l" attribute has a direct mapping to "rout-pr"
objects as defined in RIPE-60 [4]. Networks can belong to more
than one routing privilege. The list of networks within a rout-
ing privilege represents the group of networks accepted/allowed
by a set of routers described by the information in the "rout-
pr" object. The syntax for "routpr-l" is as follows:
Multiple text strings representing the routing privilege.
_________________________
(1) This represents a change from RIPE-50 [3] where
the "aut-sys" attribute was defined to be a positive
integer only, not containing the string "AS" at the
start. This change has been made to be consistent with
the "aut-num" object syntax.
ripe-1nn.txt January 19, 1994
- 3 -
bdrygw-l
The "bdrygw-l" attribute has a direct mapping to "bdry-gw"
objects as defined in RIPE-60 [4]. Networks can belong to more
than one boundary gateway. The list of networks within a boun-
dary gateway represents the group of networks advertised by a
set of routers described by the information in the "bdry-gw"
object.
The syntax for "bdrygw-l" is as follows:
Multiple text strings representing the boundary gateways iden-
tification.
As these attributes are tightly coupled to their associated objects
it makes sense for these attributes to be updated not by the network
maintainer but by the maintainer of the referenced object(s). The
basic premise behind this is that these attributes should be used
for various operational procedures such as setting routing policy,
accounting and so on. For these attributes to be used by network
operators for day to day operations they need to be guarded in such
a way that can be trusted and are guaranteed to be unique - with any
conflicts quickly and easily resolved. The procedure for achieving
this is detailed below.
3. The Basic Procedure
For each of the guarded attributes detailed above, a list of all
networks having this attribute is kept separately from the general
database itself. These lists (also called `guarded files') will be
maintained and be served as the `only' source of membership informa-
tion used in the database. Normal database updates `never' change
these attributes. If an update includes such an attribute and a
discrepancy between the values in the update and those in the data-
base is found, a diagnostic message will be sent to the originator
of the update and the guarded value(s) will not be affected. The
attributes as defined in these files are incorporated in the data-
base once a day. To ensure proper control and authorisation, these
lists will be maintained at the RIPE NCC on the same machine that
contains the RIPE database. The "guardians" of the corresponding
database objects will have to maintain their own guarded files. The
guardians are provided with individually assigned login accounts at
the RIPE NCC. The guardians can themselves decide in what manner
they want to update their file. The NCC will offer interactive
logins, ftp logins or any other means that might be deemed useful.
_________________________
(2) It should be noted that both "routpr-l" and
"bdrygw-l" attributes have been agreed to be phased out
in preference of the "aut-sys" and "comm-list" attri-
butes as soon as the `guarded field' mechanism is in
place.
ripe-1nn.txt January 19, 1994
- 4 -
3.1. Some Details
As stated each guardian will be issued with an account on the cen-
tral NCC machine known as `guardian.ripe.net'. This account will
contain a `restricted' environment which will allow the guardian of
the relevant object to update their associated guardian file (3).
Wherever possible the account name issued to the guardian will be
the same as the object name.
For example, the guardian of the AS1104 aut-num object will receive
an account known as "AS1104". With each guardian account the
corresponding file will be parsed at each update run (once a day).
This file will contain the list on networks associated with the
object. See appendix A for details of the format and syntax of the
guardian files.
A tool will also be provided within the restricted environment to
syntax check the guarded file to avoid against possible typos and
errors.
With each account, an electronic mail address (this is a mandatory
attribute for all guarded objects) will be used by the NCC and data-
base software. To make this flexible for the guardian a ".forward"
file with the account which can be change when required. This will
mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to
correct guardian.
3.2. How does it work ?
For each of the guarded files found on `guardian.ripe.net' the data-
base software will load any guarded attribute value(s) for the net-
work object(s) listed in the guarded file. This will take place at
the same time as the database is garbage collected (currently at
0500 MET). If a conflict is found (i.e if more than one entry exists
for an attribute which can only contain one entry, currently only
"aut-sys" contains this property), the current value will remain
unchanged and all guardians involved in the conflict will be sent an
electronic mail message informing them of the conflict. See Appendix
B for an example.
If no conflict is found the attribute will be updated with the
guarded value.
Correspondingly, to remove a guarded attribute just remove the net-
work entry from the relevant guarded file and it will be deleted at
the next update run. To be notified of this delete the "notify"
attribute should be used.
_________________________
(3) As stated, the mechanism for updating the guardi-
an file will initially be by interactive login or file
transfer. However, this doesn't preclude other mechan-
isms in the future.
ripe-1nn.txt January 19, 1994
- 5 -
If a guardian file contains an entry which is not in the database
then the guardian will be notified as part of the conflict handling
procedure.
If an update is sent to the database software using another mechan-
ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri-
bute, this will not be allowed to change the guarded attribute. If
the value of the attribute is the same as what is currently
registered in the database then no warnings will be given. However,
if the update contains a value for a guarded attribute that is dif-
ferent to that registered in the database, a warning will be sent to
the originator and the guarded value will remain unchanged.
Although the guarded process will run once a day as part of the
database garbage collection procedure it will also be possible to,
"on request to the NCC", run an emergency guarded update process for
a particular guarded object.
4. Getting it started
As this is a new (and much needed, especially for the "aut-sys"
attribute) mechanism, a degree of `bootstrapping' is needed to make
it easier for network providers and IRs to transition to using the
guarded file procedure. The NCC has built an automated generation
scheme for attributes that are known to be in use (currently, this
means AS numbers). For all the AS numbers seen to be routed in
Europe, accounts for the guardians have already been put in place
having the guardian's mailbox point to a mailbox at the RIPE NCC.
For these ASs currently guarded files are generated on a daily basis
by analyzing European full routing tables. This means there could
(and almost certainly will) be some conflicts within the generated
guardian files.
As soon as the account is handed over, the auto-generation for that
guardian account stops and the mailbox is changed to the correct
guardian mailbox. Guardians can of course make use of the auto-
generated guarded files if they wish to check against their own
records. From the moment of `hand-over' it is now the guardians
responsibility to make sure their associated network(s) get the
correct guarded attributes by listing them in the guarded files.
The advantage of having this `bootstrap' method is that it will
allow population of the guarded "aut-sys" attribute to take place
immediately this functionality is enabled in the RIPE database
software. It also acts as an incentive for networks operators and
local IR's to transition to the guarded file procedure as soon as
possible.
5. Conclusion
The update procedure as detailed above has the following advantages:
o Authorisation of adding/deleting is guaranteed.
ripe-1nn.txt January 19, 1994
- 6 -
o No need for mailing back and forth of authorisation messages.
o Simple procedure for both database maintainers and guardians.
o Guardians keep full control of their attribute.
It allows for the addition of any number of guarded attributes in
the future. It describes a simple but effective procedure for main-
taining the guarded files whilst not precluding alternate mechanisms
in the future.
6. References
[1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P.,
Terpstra, M., "Representation of IP Routing Policies in the
RIPE Database", RIPE-81, February 1993.
[2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in
the RIPE Routing Registry", RIPE-103, December 1993.
[3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50,
April 1992.
[4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992.
ripe-1nn.txt January 19, 1994
- 7 -
Appendix A - Format of Guardian Files.
We propose to keep the file format as simple as possible. The name
of the file is identical to the name of guarded object. The format
used within the file is kept simple. It allows lines to be either
comments or the actual object entry that is to be guarded. A comment
must contain either a semi-colon (;) or hash (#) at the beginning of
the comment line. The object name entries must be exactly the same
as they are in the database. Currently, the only object containing
guarded attributes is the "inetnum" object so the file can contain
either the `well-known' dotted quad network notation or RIPE dotted
quad range notation. Here is a simple example of what the AS1104
guarded file would look like. The file would be stored in the home
directory of the AS1104 account on guardian.ripe.net and be called
AS1104 (told you it was simple). It would contain something like the
following:
#
# File : AS1104
#
; An alternate comment format
;
; This file was updated jan.dijkstra(a)gouda.nl
; on 940109
;
192.16.183.0
192.16.185.0 - 192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0
Empty lines in the file are also ignored but you are encouraged to
keep the file as concise as possible.
As stated above, a tool known as `checkguard' will be available to
make it simple to check the syntax of the guarded file.
ripe-1nn.txt January 19, 1994
- 8 -
Appendix B - Example of conflict handling
If a conflict occurs (e.g. by listing the same network number in
more han one AS guarded file), then each of the guardians involved
will be notified on the conflict by electronic mail. Let's look at a
simple example. Suppose the guardians for AS1104 and AS2122 update
their relevant guardian files and create a conflict by having the
same network in them. For this example he network in question is
"192.16.183.0". Here is the AS1104 guardian file:
#
192.16.183.0
192.16.185.0
192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0
And here is the AS2122 guardian file:
#
192.16.183.0
193.0.0.0 - 193.0.7.0
As you can see "192.16.183.0 exists in both files.
At update time the following mails are generated. Firstly, to the
guardian of AS2122.
Date: Fri, 14 Jan 1994 13:22:43 +0100
Message-Id: <9401141222.AA07125(a)ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net>
Subject: Guarded attributes conflicts found
To: as2122(a)ripe.net
Dear Guardian,
One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.
Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.
Kind Regards,
RIPE Database Conflict Department
------
"192.16.183.0" also appears in guardian files: AS1104
And similarly to the AS1104 guardian.
ripe-1nn.txt January 19, 1994
- 9 -
Date: Fri, 14 Jan 1994 13:22:42 +0100
Message-Id: <9401141222.AA07121(a)ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net>
Subject: Guarded attributes conflicts found
To: as1104(a)ripe.net
Dear Guardian,
One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.
Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.
Kind Regards,
RIPE Database Conflict Department
------
"192.16.183.0" also appears in guardian files: AS2122
>From this you can see conflict can be quickly and easily resolved,
assuming good collaboration between the guardians. The existing
database entry will of course not be changed with regard to the
guarded attribute) as long as there exists a conflict.
ripe-1nn.txt January 19, 1994
3
4
21 Jan '94
Here is the proposal for the CLNS routing domain object for the RIPE
datase as will be presented next tuesday during the DB workgroup meeting.
This version is almost similar as the one presented at a previous
RIPE meeting.
The main differences are a new attribute "dom-name", an introduction
describing shortly why such an object is desired and an appendix that
gives a very short comment on the breakdown of NSAP's for some
commonly used AFI's.
- Henk Steenman
SARA, NIC
--------------------- CUT HERE ---------------------------------------------
CLNS routing-domain object for the
RIPE database
Version 1.2
Jan 1994
Henk Steenman
Henk_Steenman(a)sara.nl
+31 20 5928038
CLNS routing-domain object Page 2
Introduction.
____________
In the RARE lower layer technology work group for CLNS it was recognised that
in order to coordinate routing between CLNS routing domains a central registry
for such domains was necessary.
At a meeting of the work group at the 27 IETF in Amsterdam it was decided to
write a registry specification. At this meeting the RIPE NCC offered to extend
their database for IP domains/networks with CLNS related objects if a sound
proposal came forward.
Below a description of a database object for CLNS routing domains is defined.
The object can be used to describe some general information of a CLNS routing
domain such as NSAP prefix, name, description and responsible persons. It can
also be used to describe routing policies in a manner comparable to that for
IP domains ( AS's ) as defined in the paper RIPE 81 [1].
The attributes describing routing policy are intended to be set-up such that
routing tables for static inter-domain routing can be derived from them or
excisting routing can be checked against the described policy.
It is desired that tools are made to serve these tasks.
It is understood that the object as described below is subject to change when
CLNS routing developes. An example of this could be the future availability of
IDRP for dynamic inter-domain routing.
In an appendix, some generally used combinations of the Authority and Format
Identifier (AFI) and the Initial Domain Identifier (IDI) are shown.
CLNS routing-domain object Page 3
Object Description
_________________
dom-prefix:
Defines an unique routing domain, characterised by a
NSAP prefix , within a certain prefix hierarchy.
Example:
dom-prefix: 39528f1100
dom-name:
String representing the routing domain.
Format: Text string.
Example:
dom-name: SURFnet-CLNS
descr:
Description of the organisation and place of its location
Format is equal to the descr attribute as defined for IP
autonomous systems in [1].
bis:
Format : < bis NET > < dom-prefix >
NET of boundary intermediate system to between two
domains
Example: SURFnet BIS for EuropaNet
bis: 39528f1100100020000000000100000c0429b400 39528f1103
CLNS routing-domain object Page 4
dom-in:
Description of accepted routing domain prefixes, from
other domain BIS. Analogue to "as-in" in [1].
Format:< dom-prefix > < cost> <routing policy expression >
For every BIS you peer with, there should be such an entry
<dom-prefix> is the routing domain prefix where the BIS
you peer with belongs to.
<cost> is a relative cost to discriminate between different
routes to the same domain. The lowest cost gives the most
preferred route.
<routing policy expression > can be expressed in the
following way's
1: list of "dom-prefixes"
Example:
dom-in: 39528f1103 100 39124F 470005
2: KEYWORD
Only one keyword for the moment
ANY - accept everything you get announced.
3: A logical expression of 1 and/or 2.
The following operators should be defined
AND
OR
NOT
Parenthesis are used to group rules.
Example:
dom-in: 39528f1103 ANY AND NOT 39756f
Accept all announcements from EMPB BIS except for the
Switzerland routing domain.
CLNS routing-domain object Page 5
dom-out:
Routing domain prefixes announced to other BIS'.
Analogue to the "as-out' tag in [1].
Format : < dom-prefix > <routing policy expression >
<dom-prefix> is the routing domain prefix where the BIS
you peer with belongs to.
<routing policy expression > As defined with the dom-in
tag.
Example:
dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910
Advertise to Europanet the SURFnet-CLNS routing
domain but not the PTT-Research routing domain.
default:
Indication how default routing is done
default: < dom-prefix> <cost>
<dom-prefix> again is the prefix of the domain where the
BIS peer is in.
<cost> indicates which default path is preferred. In a
static routing environment this doesn't make sense.
Example:
default: 39528f1103 10
Default everything is routed to 39528f1103
CLNS routing-domain object Page 6
admin-c:
Administrative contact.
Format equal to admin-c in [1].
tech-c:
Technical contact
Format equal to tech-c in [1].
guardian:
e-mail and/or postal address of domain guardian.
Analogue to AS guardian in [1].
source:
Source of the information.
Equal to source field in [1].
remark:
remarks or comments
Equal to remark field in [1]
changed:
Who and when of last change.
Equal to change field in [1].
CLNS routing-domain object Page 7
Example:
_________
dom-prefix: 39528f1100
descr: SURFnet-CLNS domain.
bis: 39528f1100100020000000000100000c0429b400 39528f1103
dom-in: 39528f1103 100 ANY AND NOT 39528f1100000910
dom-in: 39528f1100000910 100 39528f1100000910
dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910
dom-out: 39528f1100000910 39528f1100
default: 39528f1103 10
admin-c: Victor Reijs
tech-c: Henk Steenman
guardian: domain-guardian(a)surfnet.nl
source: RIPE
changed: henk(a)sara.nl 930716
SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one,
39528f1100000910, which is PTT-research that is connected to both EMPB
and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix.
SURFnet announces to EMPB, 39528f1100 but not 39528f1100000910.
To PTT-research only 39528f1100 is announced.
Translated to static routing; on the SURFnet BIS connected to PTT-
research, there is a static route to 39528f1100000910. And on the SURFnet
BIS connected to EMPB there is a static route to all other
know prefixes. On both the PTT-reserach and EMPB BIS's connected
to SURFnet there is a static route to 39528f1100.
^L
^L
CLNS routing-domain object Page 8
Appendix A.
___________
Definition of NSAP structure is defined in OSI 8348 Ad2 [2].
In general:
NSAP's are always an integer number of octets where the AFI is always one
octet and the IDI is always an integer number of octets.
NSAP's are hierarchical structured and once the AFI is decided upon,
structuring of the rest of the NSAP is up to authorities down the tree.
Two common AFI are 47 and 39 and can be described by some general rules.
AFI: 39
Describes that the following two octets are the ISO DCC country codes. Since
these codes are always described by three digits, padding with an "f" is
necessary to complete the 2 octets. Further structure is done by the authority
for each country and there is no general rule.
AFI: 47
IDI: 4 defines OSINET.
Followed by a two byte organisation identifier.
IDI: 5 defines US-GOSIP
Version 1 defines a two byte organisation identifier.
Version 2 defines a one byte data format identifier,
a two byte zero field
a three byte administrative authority
a two byte routing domain id.
^L
^L
CLNS routing-domain object Page 9
References
__________
[1] :
RIPE-81, Representation of IP routing Policies in the RIPE database,
Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and
Marten Terpstra, Feb. 1993
[2] :
Network Services Definition, Addendum 2, covering Network Layer Addressing.
1
0
Dear all,
this is the first draft of the agenda for the up-coming meeting of the
RIPE DB-WG in Amsterdam.
Comments, additions, modification requests welcome!
See you in Amsterdam,
Wilfried.
--------------------------------------------------------------------------------
ripe-17.940119-a
Draft agenda for the DB-Working-Group at RIPE-17, Amsterdam.
------------------------------------------------------------
0. Opening, Scribe, Admin
1. New Databse Software
. current status
. experiences
. documentation (who, how, when, what)
- object definition and background
- software documentation
- maintainer's guide for Local-IRs
- secondary server's guide
2. RIPE-Handles
3. PRIDE - RIPE-DB Interaction (if any)
4. Future needs
. Guardians, operational aspects
. Delete Operation vs Guarded Filed interaction
(unless treated in the Presentation in the Routing Group)
. Phase-out of RIPE-60 stuff
(unless treated in the Presentation in the Routing Group)
. Tools
. Syntax checkers (distributed, and/or @ the NCC)
5. New/Revised Objects
. CLNS Routing "dom-prefix:"
. status of "connect:" and value "LOCAL"
. status of "notify:"
. others
6. Exchange Format
. current status
. recommendations for further action
Z. AOB
-------------------------------------------------------------------------------
Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet)
Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN)
Vienna University : 29133::WOEBER (SPAN/HEPnet)
Universitaetsstrasse 7 : Tel: +43 1 4065822 355
A-1010 Vienna, Austria, Europe : Fax: +43 1 4065822 170 NIC: WW144
-------------------------------------------------------------------------------
1
0
Folks,
here is an update of what has happened with the database software over
the last few months:
- options have been added to whoisd (some you may have already seen):
-r do NOT lookup referenced objects
-F do fast lookup, in short format, without reformatting
(implies -r)
-V faciltates version numbers to be logged in queries
this is used to identify prtraceroute and prcheck
queries. For instance, prtraceroute is logged with
-Vpt0.32 at the moment, where "pt" stands for
prtraceroute and 0.32 is the version of prtraceroute
used. This option is internal to special tools that
use the database, and should NOT be used on command
line.
-k keepalive. This option will keep the connection
between client and server open after a query. Also
this option is ONLY used in tools that need a number
of queries fast after one another (like prtraceroute)
All the options (except the -V and -k) are available in the
latest ripe whois client: ftp.ripe.net:tools/ripe-whois.tar.Z
Please note that these options will NOT work with other whois
servers, and only work with the latest beta whoisd.
- the "notify" attribute as defined in ripe-096 has been implemented.
The database has accepted "notify" and "maintainer" already for some
months, but now the functionality of "notify" has been added last
week. The functionality of "maintainer" is not implemented yet. You
are welcome to use "notify" but please do not go mad on it.
- the guarded stuff has (finally) been implemented, and is currently
under heavy test at the NCC. It includes all the things needed to
implement ripe-81 guarded attributes, including conflict handling and
all other things needed. A document describing the procedures is being
written (at this moment actually) and will be ready soon.
- many many many small and big bugs have been reported and fixed. Most
modules of the software have had some 5-10 fixes each, and the main
programs like whoisd have had some 20 fixes. Many of these bugs were
nasty little programming errors that appear in only some
circumstances, and were thus hard to find. Also, many things have
changed to speed things up a bit more.
- the software is unfortunately still beta, simply because there are
too many changes made every day. Once the guarded attributes have been
debugged and the documentation written ;-( it will be an official
release.
- Some stats, taken out of the quarterly report December 93 (which
will be published this week):
(All stats over Oct, Nov and Dec 1993)
queries: 177,423
e-mail messages with updates processed: 3,575
number of objects processed from these e-mails: 42,767
number of networks in database: 29,646
number of persons in database: 13,238
number of domains in database: 2,339
number of AS in the database: 224
More info of course at the RIPE meeting. If you have any questions
about the database (from general to very specific) please send me a
mail. See you in 11 days.
-Marten
1
0