- db-wg - mailman.ripe.net

Number of domain objects in RIPE database
by RIPE NCC Staff 04 May '95

04 May '95

Action: 20.11 RIPE NCC To investigate (as time permits) distribution of the domain information in the RIPE database and to investigate a "private" approach for referrals. Dear working group members, Relating to Action Item 20.11 from the previous RIPE meeting I have been asked to produce and send out some statistics about the number of domain objects in the RIPE database. You will find them below. I hope they are self-explanatory. Regards, Roderik Muit RIPE NCC AT : 132 objects, 25 different second-level domains BE : 481 objects, 458 different second-level domains BG : 28 objects, 28 different second-level domains CH : 709 objects, 709 different second-level domains COM : 5 objects, 5 different second-level domains CS : 4 objects, 4 different second-level domains CZ : 276 objects, 276 different second-level domains DE : 1512 objects, 1510 different second-level domains DK : 219 objects, 219 different second-level domains EE : 5 objects, 3 different second-level domains ES : 1 objects, 1 different second-level domains FI : 166 objects, 165 different second-level domains FO : 13 objects, 13 different second-level domains FR : 878 objects, 869 different second-level domains GA : 2 objects, 2 different second-level domains GL : 2 objects, 2 different second-level domains GR : 6 objects, 6 different second-level domains HU : 260 objects, 259 different second-level domains IE : 10 objects, 10 different second-level domains IL : 270 objects, 7 different second-level domains IS : 63 objects, 52 different second-level domains IT : 713 objects, 487 different second-level domains LI : 5 objects, 5 different second-level domains LT : 60 objects, 60 different second-level domains LU : 6 objects, 6 different second-level domains LV : 2 objects, 2 different second-level domains NET : 13 objects, 12 different second-level domains NL : 1559 objects, 1558 different second-level domains NO : 936 objects, 771 different second-level domains PL : 7 objects, 4 different second-level domains PT : 105 objects, 105 different second-level domains RO : 1 objects, 1 different second-level domains RU : 1 objects, 1 different second-level domains SE : 7 objects, 7 different second-level domains SK : 165 objects, 165 different second-level domains SU : 4 objects, 4 different second-level domains TN : 3 objects, 3 different second-level domains TR : 6 objects, 3 different second-level domains UA : 3 objects, 2 different second-level domains UK : 20 objects, 3 different second-level domains YU : 7 objects, 7 different second-level domains 164: 1 reverse delegations 192: 22 reverse delegations 193: 297 reverse delegations 194: 105 reverse delegations

1 0

Draft agenda DB WG meeting at RIPE 21, Rome
by Wilfried Woeber, UniVie/ACOnet 03 May '95

03 May '95

The *draft* agenda for the DB-WG at RIPE 21 in Rome. As always, additons, comments, etc. welcome! Apologies if I missed something obvious... Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 21, Rome, IT ------------------------------------------------------ 0. Administrative stuff . who's taking the minutes? . WG-agenda 1. DB-SW review . new or proposed functionality . time-stamps . reverse links (for persons, at least) . distribution kit and integrating modifications . any loose ends? 2. Security . experiences with mail-from:, crypt-pw: . stronger authentication of updates (PGP?) 3. Review of beta test for RIPE-Handles . status 4. External interfaces . DB-exchange . first steps towards distributing the database 5. Input for and Review of objects . extensions for the router object (input from Mbone WG?) 6. AOB WW, 3.5.95 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

1 0

DNS vs. RIPE DB checking tool
by Havard Eidnes 12 Mar '95

12 Mar '95

Hi, as promised at the last RIPE meeting, please find below a copy of the perl script I have which checks for the consistency between what is registered in the RIPE database for the domains and what is registered in the DNS. Do note, this script does nothing more than report what it thinks is inconsistencies, you still need to sift through the error reports this script produces and fix any inconsistencies yourselves. This script relies on a number of conventions and is a bit picky about what needs to be in the RIPE database if it is to not complain too much. First, the script has to know which domains it should check. It performs this decision by "traversing" the domain objects in the RIPE database starting from the object for the top-level domain. If the object in question has at least one sub-dom: attbibute, my script assumes that all names registered in this domain should be registered in the RIPE database with it's own domain object. This way, you use the "sub-dom" attbiutes to span out a subset of the DNS hierarchy under a given top-level domain where administrative registration in the RIPE database is required for DNS registration. The script subsequently does zone transfers for the DNS domains corresponding to the domains which should be checked as decided above. When querying the RIPE database, the set of name server records for each domain is recorded, so that the script can compare these with what is registered in the DNS. This is one point where my script deviates slightly from or is slightly more strict than the RIPE-49 document, in that it 1) does not permit IP addresses in the nserver: attribute (since you do not delegate to an IP address in the DNS, this makes sense) 2) does not permit more than one word in each nserver: attribute This makes registration such as: nserver: aun.uninett.no / 129.241.1.99 illegal, and nserver: aun.uninett.no nserver: 129.241.1.99 would also be flagged as an error when compared to the DNS output. It is my beleif that the RIPE database does not adequatly support the registration of glue records (I do not think it needs to either), and putting the glue record information in together in the nserver: attribute is bad when seen from the database normalization and maintenance side. If a domain is registerd in the DNS with only MX information, my script demands that the corresponding registration in the RIPE database should contain the string "MX-only" in one of the remarks: attributes of the domain. Subsequently, what has been harvested via the RIPE database and what has been fetched from the DNS is compared, and any inconsistencies are reported. These are: 1) Check for domains registered in the RIPE database but not in the DNS, report these as errors 2) Check for domains registered in the DNS but not in the RIPE database, report these as errors 3) For delegated domains, report any inconsistencies between the set of nserver: attribute values and the NS records in the DNS 4) Check for domains with both MX and NS records in the DNS, report these as errors 5) Check that only domains marked in the RIPE database as "MX-only" really have an MX-only registration in the DNS. Lastly, this script depends on dig version 2.0 (forget the one which comes with BIND 4.9.3 -- the external interface changed for the worse, IMHO) and on a whois client which uses getopt() to parse it's arguments (so that I can use the '--' construct to separate the options and the arguments). If you have another version of whois than this, the fix should be trivial (at the top of "get_ripe_data". Note: the script creates a "cache file" with name cc.ripe-cache in the current directory containing all the domain objects without sub-dom attributes, so that multiple runs in quick succession can be a little faster (do however remember to remove any objects you sent in updates for, or remove the cache after substantial modifications). Well, other than this, read the script -- it's some 450 lines of simple straight-forward Perl code. - Håvard #!/local/bin/perl # $Id: domain-check.pl,v 1.7 1995/03/12 18:37:22 he Exp $ # # Perl script to check the consistency between what is registered in the # RIPE database and what is registered in the DNS for the domain objects # under a given domain. Missing pieces (i.e. inconsistencies) for either # registration is reported. # Pull in data for a given domain from the DNS using dig sub get_dns_data { local($domain) = @_; local($ns, $label, $zoneok); local($wildcard_label); $zoneok = 0; $ns = &get_primary_ns($domain); if (!defined($ns)) { &err("Could not get SOA for $domain\n"); return undef; } $digcmd = "dig @$ns $domain axfr +nodefname +pfset=0xa024"; $digcmd = $digcmd . " | tr '[A-Z]' '[a-z]' |"; open(dig, $digcmd) || return undef; while(<dig>) { chop; split; if ( $_[1] eq "in" ) { chop($_[0]); $label = $_[0]; $wildcard_label = 0; if ($label =~ /^\*\./) { $label = substr($label, 2); $wildcard_label = 1; } } else { if (( $_[1] eq "matching" && $_[0] eq ";" ) || ( $_[1] eq "received" && $_[0] eq ";;" && $_[3] eq "records" )) { $zoneok = 1; } next; } if ( $_[2] eq "a" ) { $dns_glued{$label} = 1; } elsif ( $_[2] eq "ns" ) { chop($_[3]); $dns_ns{$label} = $dns_ns{$label} . ":" . $_[3]; $dns_delegated{$label} = 1; $in_dns{$label} = 1; } elsif ( $_[2] eq "mx" ) { $dns_mx_domain{$label} = 1; if ($wildcard_label) { $dns_mx_wildcard{$label} = 1; } $in_dns{$label} = 1; } elsif ( $_[2] eq "cname" ) { $dns_cname{$label} = 1; } elsif ( $_[2] eq "soa" ) { # nothing to do, ignore } elsif ( $_[2] eq "hinfo" ) { # nothing to do, ignore } elsif ( $_[2] eq "wks" ) { # nothing to do, ignore } else { printf stderr "spurious data: $_\n"; } } close(dig); if ($zoneok) { return 1; } else { &err("No matching SOA record found from $ns\n"); return undef; } } sub get_primary_ns { local($domain) = @_; local($ns, $digcmd); $digcmd = "dig $domain soa +nodefname +aa +pfset=0xa020"; $digcmd = $digcmd . " | tr '[A-Z]' '[a-z]' |"; open(dig, $digcmd) || return undef; while(<dig>) { chop; split; if ( $_[1] eq "soa" ) { close(dig); return $_[2]; } } close(dig); return undef; } # Pull in any cached data from the RIPE database previously saved to disk # by get_ripe_data sub get_ripe_cached_data { local($domain) = @_; local($tag); open(cache, $ripe_cache_name) || return undef; while (<cache>) { tr/A-Z/a-z/; chop; split; chop($_[0]); $tag = $_[0]; if ( $tag eq "nserver" ) { $ripe_ns{$domain} = $ripe_ns{$domain} . ":" . $_[1]; if ( $#_ > 1 ) { &err("RIPE: more than one nserver on a line for $domain\n"); } } if ( $tag eq "domain" ) { $domain = $_[1]; $in_ripe_db{$domain} = 1; } if ( $tag eq "sub-dom" ) { shift; while ($subdom = shift) { $fqdn = $subdom . "." . $domain; push(domains_to_check, $fqdn); if ( ! $has_subdom{$domain} ) { $has_subdom{$domain} = 1; push(needs_dns_xfer, $domain); } } } if ( $tag eq "remarks" ) { if ( /mx-only/ ) { $ripe_mx_only{$domain} = 1; } } } close(cache); return 1; } # Pull in data for a given domain from the RIPE database using whois # Put received data in "ripe-cache" (append it). The assumption is that # get_ripe_data will not be called unless data isn't found in the cache. sub get_ripe_data { local($domain) = @_; local($tag, $subdom, $fqdn); local($do_cache) = 1; local(@entry, $s); $whoiscmd = "whois -h whois.ripe.net -- '-r '$domain |"; open(whois, $whoiscmd) || return undef; open(cache, ">>$ripe_cache_name") || undef $do_cache; while(<whois>) { if ( /No entries found for the selected source/ ) { close(whois); return undef; } if ($do_cache) { push(@entry, $_); } tr/A-Z/a-z/; chop; split; chop($_[0]); $tag = $_[0]; if ( $tag eq "nserver" ) { $ripe_ns{$domain} = $ripe_ns{$domain} . ":" . $_[1]; if ( $#_ > 1 ) { &err("RIPE: more than one nserver on a line for $domain\n"); } } if ( $tag eq "domain" ) { $in_ripe_db{$domain} = 1; } if ( $tag eq "sub-dom" ) { if ($do_cache) { close(cache); } undef $do_cache; # Do not cache entries with sub-dom entries shift; while ($subdom = shift) { $fqdn = $subdom . "." . $domain; push(domains_to_check, $fqdn); if ( ! $has_subdom{$domain} ) { $has_subdom{$domain} = 1; push(needs_dns_xfer, $domain); } } } if ( $tag eq "remarks" ) { if ( /mx-only/ ) { $ripe_mx_only{$domain} = 1; } } } close(whois); if ($do_cache) { while($s = shift(@entry)) { print cache $s; } close(cache); } return 1; } # Check existence of data in RIPE database for a given domain # (independent of sub-dom tree). Might as well use code above # which pulls in data from RIPE database entry (if it exists). sub in_ripe_db { local($domain) = @_; return &get_ripe_data($domain); } # Get all RIPE data (decending recursively through sub-dom) # for a given domain, noting registered sub-doms that do not have # their own entry in the RIPE database sub get_all_ripe_data { local($domain) = @_; local(@domains_to_check) = @_; &notify("Getting cached RIPE data for domain $domain:"); $ripe_cache_name = $domain . "." . "ripe-cache"; &get_ripe_cached_data($domain); &notify("\nGetting all RIPE DB data: "); while ($domain = shift(domains_to_check)) { if (! $in_ripe_db{$domain} ) { # Not already seen in cache &notify_progress(); if ( ! &get_ripe_data($domain) ) { &err("RIPE database entry missing for $domain\n"); } } } } # Pull inn all relevant data for doing a check. Decend through sub-dom # entries in the RIPE database and pull in data for the relevant DNS zones # as well. sub pull_in_data { local($domain) = @_; &get_all_ripe_data($domain); &notify("Getting corresponding DNS data\n"); while ( $domain = shift(needs_dns_xfer) ) { &notify("Getting zone data for $domain\n"); if (! &get_dns_data($domain) ) { &err("Zone transfer of $domain failed\n"); } } } # Perform an extensive consistency check between the data fetched from DNS # and those fetched from the RIPE database. In particular, check: # # 1) Check that all entries in the RIPE database are in the DNS and # vice versa; report inconsistencies. # # 2) Where entries exist in both RIPE and the DNS, check: # # a) for delegated domains, the set of NS records in DNS and those # registered in the RIPE nserver entries match up # # b) for domains with both NS and MX records in the DNS, report # this as an inconsistency # # c) for MX-only domains (in the DNS), check that the corresponding # entry in the RIPE database contains the remark "MX-only". sub do_consistency_check { &report_missing_ripe(); &report_missing_dns(); &report_ns_inconsistencies(); &report_inconsistent_domains(); &report_mx_comments(); } # Report entries in the DNS which do not exist in the RIPE database sub report_missing_ripe { local($domain); foreach $domain (keys %in_dns) { if ( ! $in_ripe_db{$domain} ) { if ( &in_ripe_db($domain) ) { &err("Missing as sub-dom in parent object: $domain\n"); } else { &err("Missing in RIPE db: $domain\n"); } $ignore{$domain} = 1; } } } # Report entries in the RIPE database missing in the DNS sub report_missing_dns { local($domain); foreach $domain (keys %in_ripe_db) { if ( ! $in_dns{$domain} ) { if ( ! $dns_cname{$domain} ) { &err("Missing in DNS: $domain\n"); $ignore{$domain} = 1; } } } } sub split_ns_list { local($ns_str) = @_; local(%array, @tmp, $elt); $ns_str =~ s/^://; @tmp = split(/[:]+/, $ns_str); while ($elt = shift(@tmp)) { $array{$elt} = 1; } return %array; } # Report inconsistencies between registered name servers DNS/RIPE sub report_ns_inconsistencies { local(%dns_nses, %ripe_nses); local($heading_written) = 0; local($domain, $ns); foreach $domain (keys %in_dns) { if ( ! $ignore{$domain} ) { %dns_nses = &split_ns_list($dns_ns{$domain}); %ripe_nses = &split_ns_list($ripe_ns{$domain}); foreach $ns (keys %dns_nses) { if ( ! $ripe_nses{$ns} ) { &err("Missing NS in RIPE for $domain: $ns\n"); } } foreach $ns (keys %ripe_nses) { if ( ! $dns_nses{$ns} ) { &err("Missing NS in DNS for $domain: $ns\n"); } } } } } # Report domains with both NS and MX records in the DNS # and domains in RIPE database with both nserver and remark: MX-only. sub report_inconsistent_domains { local($domain); foreach $domain (keys %in_dns) { if (defined($dns_ns{$domain}) && defined($dns_mx_domain{$domain})) { &err("Both MX and NS records for $domain in DNS\n"); } } foreach $domain (keys %in_ripe_db) { if (defined($ripe_mx_only{$domain}) && defined($ripe_ns{$domain})) { &err("Both nserver and remark: MX-only in RIPE db for $domain\n"); } } } # Report MX-only domains where RIPE entry doesn't contain remark "MX-only" # and MX-only domains in RIPE database which are fully delegated in DNS sub report_mx_comments { local($domain); foreach $domain (keys %in_dns) { if ($in_ripe_db{$domain}) { if ($dns_mx_domain{$domain}) { if (! $ripe_mx_only{$domain}) { &err("MX-domain in DNS, RIPE db not marked for $domain\n"); } } } } foreach $domain (keys %in_dns) { if ($dns_delegated{$domain}) { if ($ripe_mx_only{$domain}) { &err("MX-domain in RIPE, DNS fully delegated for $domain\n"); } } } } sub err { local(@args) = @_; if ($dot_written) { $dot_written = 0; printf stderr "\n"; } printf stderr @args; } sub notify { local(@args) = @_; if ($dot_written) { $dot_written = 0; printf stderr "\n"; } printf stderr @args; } sub notify_progress { printf stderr "."; $dot_written = 1; } $arg = $ARGV[0]; if (defined($arg) && ($arg =~ /^..$/)) { &pull_in_data($arg); &do_consistency_check(); } else { &err("usage: domain-check.pl cc\n"); &err("\twhere cc is a two-letter country code\n"); }

1 0

draft minutes, DB-WG, RIPE #20
by Wilfried Woeber, UniVie/ACOnet 07 Feb '95

07 Feb '95

Dear DB-WG and David! This is the draft of the minutes for the Database WG. Again many thanks to Andreas Knocke for providing me with the meeting notes in due time. David, I'd be grateful if you could do a spelling and sanity check on the text below. I'm writing too many minutes in a hurry these days :-( As always, any comments welcome. Best regards, Wilfried. PS: I'm off-line from 9.2.95 until 3.3.95, thus I'll be unable to respond to comments during the next 3 weeks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Minutes: RIPE #20, Database WG 1. Administrative stuff The agenda was agreed upon as proposed. Andreas Knocke (DE-NIC) volunteered to act as scribe for the meeting. 2. The "new" database software: review, future Report by Marten Terpstra: The new software had been announced at the RIPE 19 meeting in Lisboa. After being available for external testing it was put into production in October 1994. Since then some bugs were fixed and some (small) syntax checking features were added, users of the database should not have noticed the change - mostly. Recently the database was moved to a decicated (new) machine (Sparc/5, whois.ripe.net). As a general remark - Marten urged everybody to use the generic names for accessing the individual RIPE NCC services because a number of services (ftp, whois, www) have already been moved to different machines. Renumbering the RIPE network also required to renumber the machines. Documentation and future development of the software package shall be done by Daniel Karrenberg and David Kessens - due to the fact that Marten is leaving the RIPE NCC right after this meeting. Finally the official release will be available from ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.00.tar.gz Other aspects of general interest: Time stamps (as requested by Merit and agreed upon in Lisbon) have not yet been added. Maybe Merit is going to add that functionality. Still there should only be one common version of the software. Hashed comments (# starting after white space) are allowed in any object submitted to the database although comments are *not* stored in the databse itself. While there was some discussion of allowing "end-of-line comments" this was dropped to avoid breaking scripts. Still an empty line (only white-space) is required to separate objects from each other. 3. RIPE Handles RIPE Handles are necessary to uniquely identify person objects with identical names and are required for the exchange of information with other databases, e.g. the InterNIC. Handles created for use in the RIPE environment database are very similar to the well-known NIC-Handles but have the string "-RIPE" appended to make them unique amongst different registries. Given the more distributed model of operation, the APNIC is going to append the relevant ISO 3166 country codes for the same purpose. Unique RIPE Handles can be obtained by fingering whois.ripe.net: finger handle.XY(a)whois.ripe.net where XY is the initials of the person's name to have a handle assigned. E.g. to request a handle for a given John Doe just do: finger handle.jd(a)whois.ripe.net which returns something similar to: First free handle: JD5-RIPE Using this (interim) method of obtaining unique handles introduces a possible race condition. This is yet to be solved. There are still some loose ends when a person object is updated to get a handle field. Occasionally there may be duplicate person objects created. In this situation the out-dated object can be simply deleted. RIPE Handles are currently considered to be in field test. On a more general level it was proposed to investigate the legal aspects of storing person-related information in a publicly accessible database. 4. External interfaces The SWIP (Shared Whois Project) for exchanging information amongst the (Regional) Registries requires unique handles. The rwhois project (see RFC 1714) - Mark Kosters of InterNIC briefly reported on the resources available (he is working on it in his spare time). A final beta version might be available at the end of Q1 1995. 5. Review of objects and links Inverse lookups: Inverse lookup is very desirable easily to find out where all the references to a given object (persons, but maybe inetnum objects as well) are coming from. Action 20.DB1: on the RIPE NCC, to do an implementation analysis. "status:" attribute Geert Jan de Groot explained that this attribute was indeed required for keeping track of address assignments. Marten had agreed to implement it on the fly to support a new tool for NCC internal use. As implemented, the acceptable values for this attribute are "Delegated" "Assigned" (and "Reserved"). The little sketch below depicts the model: total delegated delegated assigned address to RIPE to local-IR to customer space 193/7 19?.*/16 I I I / I / I I / I / I / I I/ I/ I/ I I\ I\ I\ I I \ I \ I \ I I \ I \ I I I 6. Meta objects Contrary to the current recommendation the person object is "mis-"used by a couple of entities to describe role accounts and similar things. Daniel Karrenberg agreed that this can indeed be useful, even if he opposed this use in the past. However "admin-c" for an object still has to point to a real person object. Action 20.DB2: on HAvard Eidnes to write up a proposal with input from the Local-IR WG and the EOF (European Operators Forum) 7. Input fromt the DNS-WG: domain object In addition to a brief report on the decisions within the DNS-WG, Piet Beertema elaborated on the information scheme for keeping track of domains domains under the TLD ".nl" w2hich has been implemented. Piet intends to remove all objects other than the one for .nl itself. This proposal calls for a forwarding pointer in the RIPE-DB that links to the machine where the data is actually available (the name server for .nl). Questions discussed and issues arising from this proposal: - How can compatible schemas be maintained? With the updated domain object this can be achieved, although the representation for persons are different - tools have to "keep this in mind". - The referral mechanism . The rwhois package is not yet ready for production use and has to be extended for CIDRization (whois++ the same), . The RIPE DB software currently lacks the concept of forwarding queries (comparable to proxy forwarding in BIND) for forwarding to other whois servers. There was a general consensus that the domain object is a very good candidate for starting a pilot to distribute information to the environment where it is maintained. With regard to person objects, the allocation registry and the routing registry, the RIPE database should not be modified right now (production use and automatic configurations!). Action 20.DB3: on the RIPE NCC to investigate (as time permits) distribution of the domain information and to investigate a "private" approach for referrals. Havard Eidnes reported on a tool to check the primary zone file for .no against the registered domain objects. Action 20.DB4: on Havard Eidnes to publish this tool for the benefit of other top level registrars 8. AOB - any other business None, thus the WG meeting was closed. Z. Report on an out of band discussion for the minutes "An additional, informal BOF happened just before the lunch break - inheritance of authorisation was proposed and discussed for hierarchical objects which would resolve a common question: the authorisation of allocations from a delegated block and of the addition of subdomains within a registered top level domain." -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

1 0

test, please ignore
by Geert Jan de Groot 30 Jan '95

30 Jan '95

This is just a silly test. Please do not respond. Sit on your hands :-) Thank you! Geert Jan (trying to work out some pretty broken mailers in this world)

1 0

Draft agenda: Database-WG at RIPE 20
by Wilfried Woeber, UniVie/ACOnet 20 Jan '95

20 Jan '95

The following is the first attempt at a draft agenda for the DB-WG. Seems like there is no really "big" issue for this meeting and we even may end up spending less time in parallel sessions. Apologies if I missed something obvious, it's quite busy here at our end :-) Input very welcome. Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 20, 25-27 January 1995 ------------------------------------------------------ 0. Administrative stuff . who's taking the minutes? . WG-agenda 1. Short review: new DB-SW in production use . any open issues . bug fixes and formal release . time-stamps . any loose ends? 2. RIPE-Handles . status . formal introduction? 3. External interfaces . DB-exchange . rwhois . distributed domain object queries (Piet Beertema proposal) 4. Review of objects and links . domain object (amend or obsolete, input from DNS WG) . person object (semantics) and back-links (aka inverse recursion) . extensions for the router object (input from Mbone WG?) 5. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

1 0

Re: do we need a meeting of the DNS TF ?
by Wilfried Woeber, UniVie/ACOnet 18 Jan '95

18 Jan '95

Hallo Andreas! => Question is whether we want to overhaul the domain object, or just => approve the small changes discussed last week. If we just want the => small changes, I am sure we can do it in the db-wg (Wilfried?). If we => want other bigger changes, we'd probably need a dns-wg meeting. = =We probably should still do it - if possible - within the db-wg. =It's (just :-) another object and I think we should decide what's =it use and what's the future of each of its attributes. I think [ $ set /me /mode=piet.b # :-) ] I'm reluctant to drag this stuff (remaining in a state of being rare instead of well-done :-) into the DB-WG. Maybe I'm a bit too proud about the DB-folks, but I've got the impression recently that we managed to get various things and proposals discussed up to a useful point (by different means and methods) and then just put the finishing touch on top during the DB-WG meeting. Quite to the contrary, the DNS (-object stuff) is (and has been) tossed around for more than a year now, if I recall correctly. Listening to Piet's emontional announcement, I get the feeling that the DNS folks still have to make up their minds, one way or the other... If this indeed has happend, then a proposal for a changed object is welcome to be discussed withint the DB-WG. So, my proposal would be to actually convene a DNS group meeting (even with only this one agenda item) and to try to arrive at some kind of consensus or to completely dismiss this issue. Wilfried. PS: speaking as a plain USER and NOT speaking for the DB-WG, I'd rather have the DNS group dissolved than keeping it in the semi-paralysed state it is in these days :-( -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

2 1

Re: Domain object template
by Havard Eidnes 17 Jan '95

17 Jan '95

> > admin-c: The admin-c attribute contains the name or the NIC > > I suggest to make mandatory that the administrative contact > should reside on the site itself. Assume that people have outsourced > the 'technical stuff' of their network, then it is likely that the > technical contact is someone belonging to another company, and > it might be difficult to get in touch with the holder of the > domain itself because the address/phone number is different. This is actually a naming policy issue, and as such this decision may eventually rest with the administrator of each top-level domain. I do however agree that adhering to this practice is a very good idea indeed, and that we should strongly reocmmend it. > => the admin contact for domains is different from the admin > contact for networks. It is explicitely an administrative > person who can answer to questions about name property, > legal problems, etc... In fact I understand your problem > but I believe the change should be done in the network > template. That the network template is broken is no excuse for not doing it right in this document... But I'm sure I misunderstood what you are saying. > > nserver: The nserver attribute contains the list of > > nameservers for of this domain, primary first. The > > format is fully qualified domain name without > > trailing "." OR IP Address(es) of the nameserver. > > Only one server should be described per line. An > > example: > > > > nserver: iraun1.IRA.UKA.DE > > > > Status: optional, multiple lines allowed > > Can we please drop the possibility of allowing IP numbers here? Yes! I'm all for it. It has one disadvantage, though, in that required glue information which has to be inserted in the zone file doing the delegation currently has no place in the domain object. Personally I do not view this as a great loss, it should however be noted. > If one of the secondaries of your domain changes IP number, then > he has the nearly impossible task of finding all these outdated > references. Bind only allows hostnames here; I think it is a good > idea to restrict the database in the same way. Indeed. > Also, we might add 'the first nserver listed is the primary for the zone' > > => "primary first" is in the text. Hmm, if I'm not totally mistaken, the concept of primaries and secondaries is a BINDism, and the concepts are likely to vanish some time in the not too distant future. Thus, I'm a little reluctant to mandate this usage. > > dom-net: The dom-net attribute contains the list of IP net- > > Can someone please explain why it is useful to record this? > Seems that this info might get outdated quickly as it isn't > related to the domain _name_. > > => there is a loose binding between names and addresses. > This attribute can be used if someone'd like to describe it. > This attribute has been made optional then you use it only > if you like. This attribute is essentially unmaintainable and quite difficult to check for as well (think about unannounced networks with no hosts registered in the "externally" viewable DNS tree). I think it should go into the dustbin. - Havard

1 0

Announcement
by Piet Beertema 17 Jan '95

17 Jan '95

I've been following the recent umpteenth (...) discussion on the domain object in the RIPE database. I haven't commented on it though, since frankly I couldn't care less anymore. As NL domain registrar I have had - and am having - increasing problems with the *lot* of extra work caused by trying to keep the RIPE database up-to-date as far as .NL (primary) subdomains are concerned. For one thing, the - perceived or real, that has never become clear in all the discussions on the domain object - need to maintain information that is completely irrelevant for maintaining a domain administration is a hassle. But it's far more a nuisance that the RIPE database has "person" objects that in itself are an absolute kludge, in that they are invisibly related to in any other sense completely unrelated things like network objects and domain objects. The mere presence of these objects in the RIPE database gives the impression that RIPE is trying to keep sort of a worldwide phone directory, but then a "gambling" one: whether or not one will find a person in it is pure luck: you'll find it if the person happens (or happened!) to be related to a network or a domain object, otherwise not. A random generator would do about as well... The person object, because of its linking to different other objects, is also a nuisance in another respect: it calls for the need of "handles", where there is no such need whatsoever if the NL domain administration would be maintained completely seperate from the [setup of the] RIPE database. >From the above it should be clear that, as NL domain registrar, I'm sick and tired of all the extra work caused by the "feed" given to the RIPE database. I want to strongly emphasize here that there in NO OBLIGATION whatsoever for any [top level] domain registrar to "feed" the RIPE database and/or to keep the administration of the domain in accordance with or modeled after the RIPE database. What I'm saying below is therefore an OFFICIAL STATEMENT, and NOT a call for discussion. Included in it is an invitation to the RIPE NCC - as maintainers of the RIPE database and of the related software - and to the DB-WG, for a change in the setup of the database and software. I probably won't be far off if I'm saying that I think that I'm not the only [top level] domain registrar having problems like the ones described. I'm willing to illustrate and discuss on the forthcoming RIPE meeting the sort of problems that the current setup of the RIPE database is posing, even though I've done the same on previous RIPE meetings (albeit in the DNS-WG then). But it should be very clear that this will *not* lead to revoking the statement below and the actions announced in it. The time of endless discussions is really over. I have to "spit in the hands and get to work", without the work being hampered by external factors and matters of taste (which for a large part dominate the whole discussion on objects in the RIPE database). Piet ********************************************************************** * The NL naming authority is planning to change the setup of the * * NL domain administration, to make it possible to keep up with * * the ever increasing number of domain registrations, without an * * unnecessary amount of work posed by "external factors". * * Such an "external factor" is the regular feed of the RIPE whois * * database with complete .NL (primary) subdomain info, calling for * * the need of maintaining in said administration information that * * is not relevant for the purpose of said administration, but only * * for the "external factors". * * Because of the above mentioned change in setup, the information * * in the NL domain administration will no longer be compatible with * * the "domain objects" and "person objects" in the RIPE database. * * Feeding the RIPE database with said information will therefore * * stop. Thereafter anyone is free to enter .NL subdomain objects * * (in fact that's the case already, since there is no protection * * against entering such objects - only against changes), but it * * should be very clear that from the viewpoint of the NL domain * * registration such entries are NOT authoritative. * * * * The NL naming authority recognises the value of a whois service. * * Therefore the NL naming authority will make sure that a whois * * service for .NL (primary) subdomains will be provided, through * * a whois server [to be] set up by the NL naming authority. * * The NL naming authority at the same time recognises that the * * RIPE whois server is known worldwide and that people have come * * to rely on it. Therefore an invitation is enclosed below to the * * RIPE NCC - and to the DB-WG - for a change in the database and * * its software to make it possible that the "RIPE whois service" * * is maintained, with automatic referral of the NL domain info * * on requests for such info. * * * * As soon as the mentioned change of setup has been completed and * * the mentioned whois server made operational, all .NL subdomain * * objects will be removed from the RIPE database, leaving only a * * "minimised" entry for the NL top level domain itself, which will * * then look as follows: * * *dn: nl * * *de: Top level domain for the Netherlands * * *rm: Information about .NL (primary) subdomains can be * * *rm: obtained with "whois -h <server_name>.nl <domain>.nl" * * * * As mentioned above, here is an invitation for a change in the * * RIPE database/software to automate the referral to NL domain * * info on queries directed to the RIPE whois server. Described in * * RIPE database format, after the change of the database/software, * * the "minimised" entry for the NL top level domain would be: * * *td: nl * * *de: Top level domain for the Netherlands * * *ws: <server_name>.nl * * The "ts" attribute would signal this entry as a top level domain * * to the db/whois software, causing forwarding of the query to the * * listed whois server for both the top level domain itself and for * * any <domain>.nl query. This shouldn't sound unfamiliar: it's an * * almost complete analogon of DNS, with the exception that RIPE is * * not "delegating" any top level domain. * * This change/addition has been proposed to the RIPE NCC a couple * * of months ago already, but has met with no reaction whatsoever. * * This announcement is therefore also meant to evoke a reaction * * from the RIPE NCC on this issue/proposal. * * It is clear that the above construction introduces a completely * * new element in the RIPE database/software: an entry for a top * * level domain (NL) implicitly standing for subdomains (*.NL) of * * it. So it might not be trivial to implement it. Still we think * * the RIPE NCC people will be able to handle it. * * * * * * Signed: NL Naming Authority <hostmaster(a)cwi.nl> * ********************************************************************** For your information, I'm adding here what the NL domain administration will look like after the changes, in "RIPE database notation": *dn: <domain name> *on: <organisation's name> *cc: <Chamber of Commerce registration number> *ad: <organisation's location address> *) *ac: <admin-contact> *ph: <phone of admin-c> **) *em: <e-mail of admin-c> *tc: <tech-contact> *ph: <phone of tech-c> **) *em: <e-mail of tech-c> *st: <status> ("MX-only" or "delegated") *dr: <date of registration> *dc: <date of last change> There can be more than one tech-c. *) P.O. Box is *not* (since 1-1-95) accepted here. **) Fax number might be added, but the value of it seems next to zero, given that some 80% of all registered NL subdomains don't list a fax number of contact persons. That's all. An entry with all the really *necessary* information for the domain administration, without irrelevant bells and whistles. Things like nameservers are not included in an entry: that's information that belongs in and is entered in DNS, i.e. the NL zone file. If people feel the need to find that information, then there are plenty of tools (dig, nslookup, host) to find it in DNS. The *st field in the administration gives an indication of what can/should be expected there. If people are too lazy to query DNS, they're not interested in the information. Period. One note: some of the fields given above will not be presented on queries to the NL whois server; *cc is one of them, probably also *dr and *dc. Other fields may be added at any time, as need arises. It should be clear that the setup eliminates any need for a "handle". Sure enough, this change will also have the effect that there will be no more automatic "notification feedback" from the RIPE database in case the data of a person change. But that happens so rarely that I can live with that. Besides, changes pertaining to an NL (primary) subdomain *must* be sent to the NL registrar, not to RIPE.

1 0

Domain object template
by Marten Terpstra 11 Jan '95

11 Jan '95

Folks, Francis has made an update to the old domain object template. A draft version of his document is attached below. Please comment on this document, it should preferably be OK'ed at the coming RIPE meeting. This document is also available as: ftp://ftp.ripe.net/ripe/drafts/ripe-domain.{txt|ps} Cheers, -Marten RIPE Database Template for Domains Francis Dupont Document ID: ripe-049-bis Obsoletes: ripe-049 ABSTRACT This paper describes the format and syntax for the representation for Internet domains and associated contact persons in the RIPE database. 1. Introduction RIPE (Reseaux IP Europeens) coordinates TCP/IP networking for the research community in Europe. One of the activities of RIPE is to maintain a database of European IP networks, DNS domains and their contact persons along with various other kinds of network management infor- mation. This database content is public information for agreed Internet operational purposes. This supports NICs/NOCs all over Europe and beyond to perform their respective tasks. This document describes the format and syntax for Internet domain information and the closely related contact person information. Top, first and sensible level domains should be registered in the RIPE database. Each object in the database describes a single entity in the real world. This basic principle means that information about that entity should only be represented in the corresponding database object and not be repeated in other objects. Objects are described by attributes value pairs, one per line. Objects are separated by empty lines. An attribute that consists of multiple lines should have the attribute name repeated on consecutive lines. The information stored about domain UKA.DE consists of five objects, one domain object and four person objects and looks like this: ripe-049-bis.txt January, 1995 - 2 - domain: UKA.DE descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA descr: Am Fasanengarten 5 descr: D-7500 Karlsruhe, FRG admin-c: Werner Zorn tech-c: Michael Rotert tech-c: Klaus Becker tech-c: Arnold Nipper nserver: iraun1.IRA.UKA.DE iramu1.IRA.UKA.DE nserver: unido.Informatik.Uni-Dortmund.DE sub-dom: ira dom-net: 129.13.0.0 192.54.104.0 changed: nipper(a)ira.uka.de 910208 source: RIPE person: Werner Zorn address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 3981 fax-no: +49 721 699 284 e-mail: zorn(a)ira.uka.de changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE person: Michael Rotert address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 4221 fax-no: +49 721 699 284 e-mail: rotert(a)ira.uka.de nic-hdl: MR78 changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE person: Klaus Becker address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 3973 fax-no: +49 721 699 284 e-mail: becker(a)ira.uka.de changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE person: Arnold Nipper address: Universitaet Karlsruhe address: Informatikrechnerabteilung ripe-049-bis.txt January, 1995 - 3 - address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 4331 fax-no: +49 721 699 284 e-mail: nipper(a)ira.uka.de nic-hdl: AN45 changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE 1.1. How to access the Database ? The database is public information for agreed Internet operational purposes. It can be accessed via a whois server on host whois.ripe.net (tcp port 43). The whole database is also available via anonymous ftp from ftp.ripe.net as file ripe.db in directory ripe/dbase. There is also a compressed version of the database available in that same directory, as well as a version of the database in which the different objects have been collected in different files. This "split" version of the database can be found in the subdirectory split. 1.2. How to submit information to the database ? Database updates should be sent via electronic mail to auto-dbm(a)ripe.net Be sure to supply a person object [1] for each contact per- son mentioned in the network objects. Of course you need not supply person objects if they are already present in the database and the information is still correct. Updates sent in should only contain the objects that need to be updated. The mail is automatically parsed by software that cannot intercept any messages that may be in the mail. If an update needs human intervention, or you have general questions on the procedures, please refer to ripe- dbm(a)ripe.net. Currently no special authorisation is needed to create, modify or delete objects that describe persons or domain name space. However extensive audit trails of all changes are being kept. 2. Format and syntax of the domain object In a short summary below, the attribute column indicates the name of the attribute inside the object, the second column indicates whether this attribute is optional or mandatory, and the third column indicates whether this attribute can ripe-049-bis.txt January, 1995 - 4 - appear more than once per object: attribute optional/mandatory multiple/single domain: mandatory single descr: mandatory multiple admin-c: mandatory multiple tech-c: mandatory multiple zone-c: optional multiple nserver: optional multiple sub-dom: optional multiple dom-net: optional multiple remarks: optional multiple notify: optional multiple mnt-by: optional multiple changed: mandatory multiple source: mandatory single Below each of these attributes and their format and syntax are described in more detail, and examples are given. domain: The domain attribute contains the fully qualified domain name without trailing ".". Note that DNS names are case insensitive. An example: domain: UKA.DE Status: mandatory, only one line allowed descr: The descr attribute consists of a short description of the organization and location where this domain is used. The description can have multiple lines. It need not contain the full postal address as this is required in the contact person objects (see further in this document). Free text is allowed. An example: descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA Status: mandatory, multiple lines allowed admin-c: The admin-c attribute contains the name or the NIC handle of the administrative contact person. This is someone who will be contacted about administra- tive things such as domain registration etc. A NIC handle (if known) is preferred. Please do not use formal titles like 'Dr', 'Prof' or 'Sir'. Do not add full stops between names or initials. This value should be exactly the same as the attribute in the person object (see further below). More than one administrative contact person can be specified, by simply repeating the attribute. An ripe-049-bis.txt January, 1995 - 5 - example of both the NIC handle and normal name use: admin-c: Daniel Karrenberg or (preferred) admin-c: DK58 Status: mandatory, multiple lines allowed tech-c: The tech-c attribute contains the name or the NIC handle of the technical contact person. This is someone to be contacted for technical problems such as (mis)behavior of nameservers on the net etc. The format and syntax is the same as the admin-c attribute above. Status: mandatory, multiple lines allowed zone-c: The zone-c attribute contains the name of the zone contact for the domain. This is the person listed in the SOA record for the domain when the domain is a zone too (the same argument, not every domains are zones, applies to nserver attribute). The for- mat and syntax is the same as the admin-c attribute above. Status: optional, multiple lines allowed nserver: The nserver attribute contains the list of nameservers for of this domain, primary first. The format is fully qualified domain name without trailing "." OR IP Address(es) of the nameserver. Only one server should be described per line. An example: nserver: iraun1.IRA.UKA.DE Status: optional, multiple lines allowed sub-dom: The sub-dom attribute contains the list of sub- domains of the domain. The format is relative domain name to the domain (in order to keep the list compact). An example: sub-dom: ira Status: optional, multiple lines allowed dom-net: The dom-net attribute contains the list of IP net- works in this domain. The format is dotted quad including trailing 0s, extended formats defined in [1] for range of IP address space are allowed. An example: dom-net: 129.13.0.0 192.54.104.0 ripe-049-bis.txt January, 1995 - 6 - Status: optional, multiple lines allowed remarks: The remarks attribute contains any remarks about this domain that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it provides extra information to users of the database, and usage should be kept to a minimum. For format is like the description attribute free text. An exam- ple: remarks: MX record only Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifications of changes to this object should be send. This can be useful if more than one person manage the same object. A more detailed description can be found in [2]. The format is one RFC822 electronic mail address per line. Although multiple lines are allowed, usage should be kept to a minimum. An example: notify: operations(a)ripe.net Status: optional, multiple lines allowed mnt-by: The maintainer attribute contains a registered maintainer name. This attribute is used for author- isation of database update requests. It is described in more detail in [2]. The format is a registered maintainer name. An example: mnt-by: RIPE-DBM Status: optional, multiple lines allowed changed: The changed field contains information on who last changed this object, and when this change was made. The format is an RFC 822 electronic mail address of the person who made the change, and the date of change in YYMMDD format. Multiple lines are allowed and shows the update history of an object. An exam- ple: changed: marten(a)ripe.net 940328 Status: mandatory, multiple lines allowed source: The source contains a source of information. For the RIPE database, the value should always be "RIPE". This field is used to combine and exchange information between various database sources around ripe-049-bis.txt January, 1995 - 7 - the world. Fixed value: source: RIPE Status: mandatory, only one line allowed, fixed value 3. References [1] Lord, A., Terpstra, M., "RIPE Database Template for Networks and Persons", ripe-119, October 1994. [2] Karrenberg, D., Terpstra, M., "Authorisation and Notif- ication of Changes in the RIPE Database", ripe-120, October 1994. ripe-049-bis.txt January, 1995

4 4

Re: Domain object template
by Andreas.Knocke＠nic.de 11 Jan '95

11 Jan '95

Hello, a couple of additions to the discussion: > * Can we please drop the possibility of allowing IP numbers here? > * If one of the secondaries of your domain changes IP number, then > * he has the nearly impossible task of finding all these outdated > * references. Bind only allows hostnames here; I think it is a good > * idea to restrict the database in the same way. > * > * => IP numbers were allowed in the previous template then we need > * a general agreement before dropping this possibility... > > Perhaps we should try and completely overhaul the domain object? Why > would we go for small changes when we may need major changes? I somehow agree with the positions Geert Jan and Marten gave, a complete overhaul is probably needed and especially the nserver, IP-address idea was much discussed the last time at the RIPE meeting in Amsterdam (May 1994) with the idea that there is a much more useful place to store it - BIND ! On the other hand there is maybe one useful point to IP-numbers here, for a domain abc.zz with a set of nameservers ns1.abc.zz and ns2.abc.zz which have lost connectivity - a very bad situation, I agree - it might be helpful to find there IP addresses here as well, so I would propose to use it only for nserver within the specified domain. domain: ABC.zz descr: ABC company .... nserver: ns1.abc.zz 194.205.120.3 nserver: ns2.abc.zz 194.205.120.6 nserver: ns.domain.my nserver: foo.bar.com ... Giving the primary first is probably a good idea, but what about 'hidden' primaries. It is I think a common situation for organisation behind a dial-up connection administering there own nameserver (as given in the SOA) with only a set of secondaries published as NS-RR's. This cannot be documented - if one wants to - this way, but maybe with a useful remark: > * => there is a loose binding between names and addresses. > * This attribute can be used if someone'd like to describe it. > * This attribute has been made optional then you use it only > * if you like. > > Hmm, personally I'd bin the attribute..... I think that most of the attributes made optional instead of obsolete could be seen as a compromise we can agree upon as a transitional step until the complete overhaul - if not achieveable at this meeting ? > > admin-c: The admin-c attribute contains the name or the NIC > > I suggest to make mandatory that the administrative contact > should reside on the site itself. Assume that people have outsourced > the 'technical stuff' of their network, then it is likely that the > technical contact is someone belonging to another company, and > it might be difficult to get in touch with the holder of the > domain itself because the address/phone number is different. > > => the admin contact for domains is different from the admin > contact for networks. It is explicitely an administrative > person who can answer to questions about name property, > legal problems, etc... In fact I understand your problem > but I believe the change should be done in the network > template. I totally agree with Geert Jan here, the admin-c should be from the organisation using domain and should be changed if he no longer represents this organisation. I didn't follow the discussion but heard some rumors about mtv.com but this way might be a good start. You have to have the organisation's address and at least one phone number somewhere. Another but important aspect I think would be to find a better (more up to date) example, if it should convince and educate new registries. The current one contains a number of factional errors (I'll append the correct entry at the bottom of this posting) and some discrepancy to it's own explanation for instance the format of the change dates not in format YYMMDD. Finally with the handles and names as key values for person objects 1.2 could be reformulated. Before entering or updating person objects the database should be checked for existing entries which were created as references of other objects (inetnum,...). Care should be taken to keep them up to date, without generating duplicate entries one with and one without a handle. I did it a number of times myself when I started using handles so please don't take it as an accusation to anybody. On the other hand the advent of ripe handles gives us the proper way to create different objects for one person where necessary - e.g. if he has his own domain at home and supports a number of networks or anything else at work. -------------------------------------------------------------------------- domain: uka.de descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA descr: Am Fasanengarten 5, D-76128 Karlsruhe, Germany admin-c: WZ5-RIPE tech-c: KB49 tech-c: AN45 zone-c: KB49 nserver: iraun1.ira.uka.de nserver: iraux1.ira.uka.de nserver: ns.germany.eu.net nserver: ns.nic.de sub-dom: ira dom-net: 129.13.0.0 192.54.104.0 mnt-by: DE-DOM changed: nipper(a)ira.uka.de 910208 changed: knocke(a)nic.de 941121 source: RIPE person: Werner Zorn address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3981 fax-no: +49 721 699 284 e-mail: zorn(a)IRA.UKA.DE nic-hdl: WZ5-RIPE mnt-by: DENIC-P changed: dfk(a)cwi.nl 900411 changed: rv(a)Informatik.Uni-Dortmund.DE 930704 changed: knocke(a)nic.de 941121 source: RIPE person: Klaus Becker address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3973 fax-no: +49 721 699 284 e-mail: becker(a)ira.uka.de nic-hdl: KB49 mnt-by: DENIC-P changed: nipper(a)xlink.net 940406 changed: knocke(a)nic.de 941121 source: RIPE person: Arnold Nipper address: NTG Netzwerk und Telematic GmbH address: Geschaeftsbereich XLINK address: Vincenz-Priessnitz-Str. 3 address: D-76131 Karlsruhe address: Germany phone: +49 721 9652 0 fax-no: +49 721 9652 210 e-mail: nipper(a)xlink.net nic-hdl: AN45 changed: nipper(a)xlink.net 940616 source: RIPE

1 0

Re: Domain object template
by Dave Morton 11 Jan '95

11 Jan '95

All very good points - I agree with Geert. Dave

1 0

Re: "Dale S. Johnson": # Comment characters in templates
by Wilfried Woeber, UniVie/ACOnet 02 Dec '94

02 Dec '94

= * > which would be processed normally, ie the # lines ignored. They = * > would not end up in the database of course. = * = * > Any major showstoppers here? = * = * = * Well, no objections... this is really simple to implement, and may be = * very useful. = =It should be noted though that from that moment on "#" lines no longer =can be used to end an object. Two objects with only a "#" line between =them will be viewed as one, and will generate a syntax error. = =-Marten I agree that the proposed functionality to allow comments is useful. As to the aspect of separation of objects - well, I think with the invention of the password stuff and with the idea of grabbing the whois template output and writing scripts and the like, we should be asking whether just a blank line is the best way to separate objects... How about an "end: whatever string you like to put here" attribute to be equivalent to a blank line separating objects? Any hard feelings? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: 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 --------------------------------------------------------------------------

1 0

"Dale S. Johnson": # Comment characters in templates
by Marten Terpstra 29 Nov '94

29 Nov '94

Folks, Dale Johnson from MERIT brings up the issue of allowing "#" style comments in objects between attributes. From an implementation point of view this is *very* simple. Any major objections? The database sw would simply ignore them. Note that they would have to be on a line by themselves, NOT inside an attribute. An example would be: person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: PRIDE Project address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands # This is some comment phone: +31 20 592 5064 fax-no: +31 20 592 5090 e-mail: Marten.Terpstra(a)ripe.net nic-hdl: MT2 # And this as well notify: marten(a)ripe.net changed: marten(a)ripe.net 941128 source: RIPE which would be processed normally, ie the # lines ignored. They would not end up in the database of course. Any major showstoppers here? -Marten ------- Forwarded Message Date: Mon, 28 Nov 1994 14:49:50 -0500 From: "Dale S. Johnson" <dsj(a)merit.edu> To: Marten(a)ripe.net cc: Tony.Bates(a)ripe.net Subject: # Comment characters in templates Marten, What do you think of the idea of allowing #Comments in templates that are processed by auto-dbm? I bring this up privately because it seems like something that must have caused some discussion before if it isn't all ready implemented. The arguments are the same as for commenting programs: objects (especially aut-num objects) can be huge and complex now. Even if the comments aren't preserved in the storage and output formats, it would make lots of sense for people to keep comments in their original versions on their own machines, and not have to sed these out before they send them to auto-dbm. Is there all ready a history on this question? Or could it be done without discussion? Or if it needs discussion, what list would be appropriate? --Dale ------- End of Forwarded Message

3 3

Re: "Dale S. Johnson": # Comment characters in templates
by Marten Terpstra 29 Nov '94

29 Nov '94

David.Kessens(a)ripe.net writes * Hi Marten, * * I see no problems but is a '#' also allowed after a number of spaces : * * # This is a comment Yup, leading spaces are always ignored. * Do you check the attributes for '#' when sent in ? * Does this generate a warning ? Well, if there is a "#" type comment inside an attribute (ie somewhere inside the value of an attribute) this will generate a syntax error in most cases. Ie something like: person: Marten Terpstra address: ....... phone: +31 20 592 5065 # Preferred phone: +31 20 592 5064 # Backup would spefically NOT be allowed and would generate syntax errors for that attribute. Unless of course the syntax for an attribute allows # chars (I don't think there are any though). -Marten

1 0

RIPE Database Transition T2
by Marten Terpstra 17 Nov '94

17 Nov '94

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

1 0

Database transition step 1 completed
by Marten Terpstra 14 Oct '94

14 Oct '94

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

1 0

New Document available: ripe-123
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

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

1 0

New Document available: ripe-122
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

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

1 0

New Document available: ripe-121
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

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

1 0

New Document available: ripe-120
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

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

1 0

New Document available: ripe-119
by RIPE NCC Document Annoucement Service 06 Oct '94

06 Oct '94

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

1 0

DB-WG Draft minutes, Lisbon
by Wilfried Woeber, UniVie/ACOnet 03 Oct '94

03 Oct '94

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 --------------------------------------------------------------------------

1 0

RIPE Database playground
by Marten Terpstra 20 Sep '94

20 Sep '94

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

1 0

Document update
by Tony Bates 16 Sep '94

16 Sep '94

As agreed at the last RIPE meeting, we have made updates to the following documents and moved them to final draft to be released as RIPE documents on the 30th September. They are as follows RIPE-81++ --------- ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{ps,txt} Classless Representation ------------------------ ftp://ftp.ripe.net/ripe/drafts/clarep.{ps,txt} Authorization ------------- ftp://ftp.ripe.net/ripe/drafts/ripe-auth.{ps,txt} Transition Plan --------------- ftp://ftp.ripe.net/ripe/drafts/db-trans.{ps,txt} Inet-rtr object ---------------- ftp://ftp.ripe.net/ripe/drafts/inet-rtr.{ps,txt} Update to inetnum ----------------- ftp://ftp.ripe.net/ripe/drafts/ripe-inetnum.{ps,txt} Also, find the start of the experimental objects and attributes document for ripe-81++ extensions. ftp://ftp.ripe.net/ripe/drafts/experimental.{ps,txt} This is a placeholder for a more involved document to follow. Please make sure all comments are sent within two weeks. This message will also be sent to all AS and Community guardians. Apologies for any duplication but we want to make sure we reach all parties involved. --Tony, Marten and Daniel.

1 0