- db-wg - mailman.ripe.net

Re: NIC Handles
by Erik-Jan.Bos＠SURFnet.nl 30 Nov '93

30 Nov '93

Daniel, > This is the NCC's current thinking aout NIC handles. > This is a quick dump, so If you have questions, please ask. > Please comment! My 2 cents... > As decided at the last meeting we need to introduce unique handles in > order to deal with ambiguities in the RIPE database. Especially > accidental overwriting of persons will be a problem in the future with > more than 10000 persons in the database now. > > After some discussion with the InterNIC we have concluded that a > worldwide handle space is not realistic. In fact Australia has already > started with their own space. > > Therefore we propose to start issuing RIPE handles as soon as > technically feasible. Person handles will then be of the form > > XYZ123-INIC > ABC457-RIPE > .... > > Each physical person will eventually have one such handle only in order > to facilitate database exchanges between NICs and database maintenance. > > RIPE handles will be assigned by sending in a person entry to auto-dbm > with somethin like > > nic-hdl: assign > > which will cause the entry to be added with a new unique handle > assigned. If there are other persons with the same name their entries > will be returned as a check against multiple registrations. > > The NCC will *not* automatically assign handles to persons without > handles on a "flag day". Local registries or the persons themselvews > will have to do that. The reason for that is that all conflicts would > need to be resolved beforehand and all persons notified of the change. > This is too cumbersone, if not impossible. > > The NCC will flag possible conflicts present in the database today and > help resolve them by notifying everyone involved and by assigning > handles to all persons involved if necessary. > > In the future, handles will have to be used in the contact attributes > (tech-c, admin-c, zone-c) in order to maintain unambiguous references. > The recommended value for the contact attributes will be to list *both* > name and handle in order to guard against typos in handles. Name only > and handle only will also still be allowed. It might be necessary to > disallow name only at some point when the majority of persons have a > handle. A still open question is what to do with people residing in Europe having a InterNIC handle already. You surely want these people to have a RIPE handle as well, I presume. This, however, would mean that such a person has two handles, which is confusing. Possible solutions?: - flag these people and assign them a RIPE handle and reject the INIC handle. - leave the INIC handle as is, and use this inside the RIPE Data Base. - Live with the confusion of more than one handle per person. A totally different thing is that there are people in the data base more than once. I guess this is really hard to flag automatically, but this needs to be sorted out as well. __ Erik-Jan.

6 5

Re: dom-net tag under domain
by Tony Bates 30 Nov '93

30 Nov '93

Actually, you need a little more so you only get one occurence of a net per object. This should take care of that. while (<>) { chop; if(/^\s*$/) { %done = (); } if(/^di:/ || /^dom-net:/) { ($tmp,$value) = split (/\s+/, $_, 2); printf "%-10s", $tmp; @list = split(/\s+/,$value); foreach $j (0..$#list) { $net = &munge($list[$j]); if(!$done{$net}) { printf " %s", $net; } $done{$net} = 1; } print "\n"; next; } else { printf "%s\n", $_; } } sub munge { local($str) = @_; local($ind) = 0; local($val) = ""; local(@add) = split(/\./, $str); foreach $ind (0..$#add) { if ($add[0] < 128) { $val = "$add[0]".".0.0.0"; return $val; } if ($add[0] < 192) { $val = "$add[0]"."."."$add[1]".".0.0"; return $val; } if ($add[0] < 224) { $val = "$add[0]"."."."$add[1]"."."."$add[2]".".0"; return $val; } } } Hope this was of some help, --Tony.

1 0

dom-net tag under domain
by bonito＠nis.garr.it 30 Nov '93

30 Nov '93

Dear NCC people, I think that too strict sintax checking is applied in the case of the dom-net database field. An example follows. We are deploying technology to obsolete networks classes (A,B,C,...) and at the same time the RIPE database checking rules do not take into account the actual usage of dear old subnetworks? In practice very often a number of subnetworks of a class B network are used to host machines in a domain while other subnetworks are used to host machines of a different domain. This is common for large networks in a city. We would like the checking rules to be relaxed in this case. Could you please do that? ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- Forwarded message: > From giuliana Mon Nov 29 14:47:06 1993 > From: giuliana (Giuliana Tamorri) > Message-Id: <9311291347.AA07375(a)jolly.nis.garr.it> > Subject: > To: bonito (Antonio_Blasco Bonito) > Date: Mon, 29 Nov 93 14:47:04 MET > X-Mailer: ELM [version 2.3 PL11] > > domain: astro.it > x400-domain: c=it; admd=garr; prmd=astro; > org: astronet > admin-c: Leopoldo Benacchio > tech-c: Roberto Di Luca > postmaster: Roberto Di Luca > zone-c: Roberto Di Luca > nserver: 137.204.64.15 boas3.bo.astro.it > nserver: 192.12.192.5 dns.nis.garr.it > dom-net: 137.204.64.0 137.204.51.0 192.94.71.0 150.217.20.0 > dom-net: 143.167.30.0 147.162.26.0 130.192.100.0 140.105.72.0 > dom-net: 192.84.153.0 192.9.200.0 > remarks: national astronomical observatory network > changed: <DILUCA(a)ALMA02.CINECA.IT> 930602 > source: TEST > *ERROR*: syntax error in "dom-net" - illegal IP network number 137.204.64.0 > *ERROR*: syntax error in "dom-net" - illegal IP network number 143.167.30.0 >

3 6

Fundamental problem with mandatory field zone-c
by Andreas Schachtner 26 Nov '93

26 Nov '93

domain: AIC.DE descr: AIC Software GmbH descr: Muenchen admin-c: Gottfried Bartmuss tech-c: Gottfried Bartmuss source: RIPE *ERROR*: mandatory field "zone-c" missing *ERROR*: mandatory field "changed" missing ; <<>> DiG 2.0 <<>> @deins.informatik.uni-dortmund.de aic.de. any ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 1 ;; QUESTIONS: ;; aic.de, type = ANY, class = IN ;; ANSWERS: aic.de. 86400 MX 190 mail.Germany.EU.net. ;; ADDITIONAL RECORDS: mail.Germany.EU.net. 86400 A 192.76.144.65 ;; Sent 1 pkts, answer found in time: 18 msec ;; FROM: foobar to SERVER: deins.informatik.uni-dortmund.de 192.35.64.34 ;; WHEN: Fri Nov 26 11:42:36 1993 ;; MSG SIZE sent: 24 rcvd: 75 There is no zone for aic.de, thus there is no zone contact. Opinions ? Andreas Schachtner afs(a)Germany.EU.net === ____ === EUnet Deutschland GmbH === / / / ___ ___ _/_ === Emil-Figge-Str. 80 === /---- / / / / /___/ / === D-44227 Dortmund === /____ /___/ / / /___ / === ===== ===== Tel. +49 231 972 00 ===== Connecting Europe since 1982 ===== Fax +49 231 972 1111

6 6

Re: NIC Handles
by Erik-Jan.Bos＠SURFnet.nl 25 Nov '93

25 Nov '93

Andrew, > > A still open question is what to do with people residing in Europe having > > a InterNIC handle already. You surely want these people to have a RIPE > > handle as well, I presume. This, however, would mean that such a person > > has two handles, which is confusing. > > People should have just one handle; not two. Agreed. One person, one SSN. :-). > I think that the question that we are trying to solve is: > If someone does not have a handle of any sort and we (some > registry - like RIPE or the NIC) want to assign him one, how do > we assign him one such that the handle is unique? Sure. This is raised in the document Daniel submitted. I just raised two additional things: - people already having a INIC-handle - some people occur in the RIPE Data Base more than once If we feel this is outside the scope of the proposal, let's quit the issue. My personal opinion is that we need to address this as well. __ Erik-Jan. NIC-handle: EJB (or should it be EJB-RIPE).

1 0

Syntax errors in database
by Marten Terpstra 23 Nov '93

23 Nov '93

Folks, As promised at the last RIPE meeting, we have run a full syntax check on the complete database, and the results of that check are available for anonymous ftp. The files are split by object type, and contain only objects that generated a warning or error. If you have some time to maybe look at some of your info, please look in: ftp.ripe.net:ripe/dbase/errors/ If you have questions about errors/warnings found, please let us know. -Marten

1 0

Discrepancies between Merit and RIPE DB
by Laurent Joncheray 11 Nov '93

11 Nov '93

Here are the differences between the Merit and the RIPE databases: Number of entries: 3791 No difference: 608 (16%) Small diferences: 1354 (35%) Substrings: 968 (25%) Typos: 481 (12) Order: 78 (2%) Punctuation: 51 (1%) Abbreviations: 244 (6%) One Word only: 75 (1%) Differences: 1829 (48%) 100%: 277 (7%) 80%: 303 (7%) 60%: 335 (8%) 40%: 463 (12%) 20%: 451 (11%) A file with the list of addresses and differences is available on request. -- Laurent Joncheray, Merit Network Inc, 1071 Beal Avenue, E-Mail: lpj(a)merit.edu Ann Arbor, MI 48109, USA Phone: (313) 936 2065 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

1 0

discrepancies RIPE - InterNIC
by Laurent Joncheray 11 Nov '93

11 Nov '93

Thanks to the InterNIC folks, the InterNIC data relative to the Network numbers is available on a flat file on merit.edu. We ran a comparison between the InterNIC and the Merit data, and between the RIPE data and the InterNIC data. since RIPE is authoritative for the European information and the InterNIC is authoritative for everything else, it seems most important to address those discrepancies (RIPE/InterNIC). Here is the result of the first comparison between RIPE and InterNIC: (The data may be old for some networks, and our program may have some bugs... The result for the Merit/InterNIC data are not provided) Number of entries: 10423 Unregistered in NIC DB: 5298 (50%) No difference: 108 (1%) Small differences: 2047 (19%) Substrings: 1604 (15%) Typos: 510 (4%) Order: 356 (3%) Punctuation: 21 (0%) Abbreviations: 186 (1%) One Word only: 5 (0%) Differences: 2970 (28%) 100%: 758 (7%) 80%: 498 (4%) 60%: 494 (4%) 40%: 723 (6%) 20%: 497 (4%) Remarks: - 10423 represents the number of networks and blocks in the RIPE DB; each block is counted as 1 network. - The addresses for the RIPE networks are got from the 'Administrative Contact' entries. For 10423 networks, 224 do not have a administrative contact entry in the persons databases. In such a case we use the 'description' attribute to get the address. Some entries are duplicated in the person DB, which creates some strange addresses (e.g. 193.84.64.0 -> Alexandr Modry) - 'Unregistered in NIC DB' means the network is part of the RIPE block in the NIC BD, but does not have its own entry. - 'Substrings' means all the words of one address are on the second address (e.g. "Celisoft Data AB, Box 718, S-941 28 Piteaa, Sweden" and "Celisoft Data AB, Celisoft Data AB, BOX 718, S-941 28 PITEAA, SWEDEN") - The differences are given in percentage of number of different words. 100% means 80% to 100% of the word are differents. We also take into account the typos, abbreviations, punctuation, etc... which are not a 'difference' per se. - The program which compares the addresses takes about 20s for 10000 entries. The program which reads the InterNIC data and formats them for comparison takes about 20 minutes. We'd like to set up a plan with RIPE and the InterNIC to eliminate the discrepancies. Merit has a list of the 5298 networks without entry in the NIC DB and can provide a detailed list of the address differences for the other inconsistences. Do you all have any suggestions as to how we can proceed to resolve this problem? Laurent & Enke. PS: Could InterNIC provide your flat file periodicly? (once a week?) PS: Any comments are wellcome.

3 2

Re: A Question
by Daniel Karrenberg 03 Nov '93

03 Nov '93

Jack, sorry about that late reply. First I have been away and then swamped. The answer has been a little longer than expected. Thus I CC it to the relevant RIPE working groups too fort their information. Daniel > Haven't mailed for awhile. I hope everything is going well over the > pond. I was wondering if you could fill me in on a little RIPE > philosophy. Tall order. :-) If we keep it down to specifics ... > Right now, its my understanding that authorized users can > automatically update the ripe database. If that is correct, how do you > make sure that what the authorized user is telling you is the correct > information. The original RIPE DB authorisation scheme: "No authorisation but *very* good audit trails." Anyone can change anything in the database but it will be logged. True, if you are mailicious and really determined you can do things and we will not be able to trace you far. But we will know what was done when and from where and we will be able to take appropriate action. We have decided to cross that particular bridge when we get to it. Together with a very quick response to queries about update problems this has worked rather well. After three years of experience with now 38,000 objects in the database and just under 1000 updates on an average working day I can not recall more than about a dozen incidents of unintentional changes being made by third parties. All of those have been resolved rather quickly and none has been intentional or malicious. Since we are now starting to do routing registry functions which are critical to operations we are starting to introduce some authorisation for the routing policy elements in the database. Some objects will not be changeable at all but by an authorised guardian. Currently these are some deprecated objects nad the autonomous system and community objects. Additionally some attributes will be guarded. The most important is the "aut-sys" attribute of the network object which defines membership of a network in an AS. These attribute will not be updated or updatable via the normal method but via a totally separate authorised method by the guardians of the respective autonomous system. The authorisation method for this will be Unix login security in most cases. You can read more about all this in ripe-81 ripe-96 ripe-89 ripe-72 and others. > An example: > > Say I'm a mean guy and I want to register a net that I do not own, and > is currently not in the RIPE database, to myself before my competitor > has registered it. How do you make sure that I'm allowed to register > this new net in the database? We do not. But we keep track of registry assignments separately from the database. If someone claims a network and has no assignment from the appropriate registry (either the NCC or a local registry) then he looses. > The only way I can check this today is > to see if the internic has given the net out and if it is registered > to the apporpriate person sending in the database addition. Same thing here. > Now if I'm > a provider, I do not "own" this address so things get a little > confusing. Not at all. The registry has the obligation to keep a record of what they assigned separately from the database and to register networks in the RIPE database no less than 24h after assignment. So there will be a trace. Also a flag will be raised if such an assignment is made for a net already in the database. At the NCC we keep simple SCCS files (yes I am *that* old) for the register. Together with the database audit trail this is more than adequate to document who did what when. We also keep an archive of all registry mail messages and faxes (full-text indexed with WAIS). We also have a filing cabinet used for those old fashioned hardcopy requests. It is not too full yet so we can keep office supplies and other stuff in it as well. :-) If there is a conflict both the datbase audit trails and the register of the registry concerned will be examined. If there are conflicts the latter is most likely to be ruled authoritative. To date such a case still has to happen - apart from administrative snafus which *do* happen once in a while. Daniel

1 0

RE: DB Minutes
by Wilfried Woeber, UniVie/ACOnet 01 Oct '93

01 Oct '93

>I propose to add the text below to the DB minutes: Good idea. I think the example 2 should be corrected. See below. ---- |In case two or more guardians want to set an attribute |which can only have one value, the current state of the |attribute will not be changed and all guardians concerned will |be notified. | |Example: | |The aut-sys attribute of network 193.193.193.0 in the database is AS193. |AS4711 adds this network to his guardian file. At the next database cleanup |all guardian files will be examined. | | 1) if the AS193 guardian file still contains 193.193.193.0 a conflict | exists and the cuurent database state prevails: AS193 will remain | | 2) if 193.193.193.0 has been removed from the AS193 guardian file | no conflict exists and AS193 will be replaced by AS4711 ^^^^^^ |Similarly the aut-sys attribute will remain undefined if it is undefined |and two guardians add it simultaneouly. | |Since the cleanup runs every 24 hours guardians involved in a change should |coordinate their changes such that they are done in the same 24h period. | ---- >clear? Yes, Sir! :-) Wilfried.

2 1

DB Minutes
by Daniel Karrenberg 01 Oct '93

01 Oct '93

The routing wg posed the question "how will a conflict between two guardians be resolved?". To my recollection this was discussed briefly in the DB WG but not minuted (my fault). I propose to add the text below to the DB minutes: ---- In case two or more guardians want to set an attribute which can only have one value, the current state of the attribute will not be changed and all guardians concerned will be notified. Example: The aut-sys attribute of network 193.193.193.0 in the database is AS193. AS4711 adds this network to his guardian file. At the next database cleanup all guardian files will be examined. 1) if the AS193 guardian file still contains 193.193.193.0 a conflict exists and the cuurent database state prevails: AS193 will remain 2) if 193.193.193.0 has been removed from the AS193 guardian file no confluict exists and AS193 will be replaced by AS193 Similarly the aut-sys attribute will remain undefined if it is undefined and two guardians add it simultaneouly. Since the cleanup runs every 24 hours guardians involved in a change should coordinate their changes such that they are done in the same 24h period. ---- clear?

1 0

Database beta: Bug in enkeys.pl
by Daniel Karrenberg 28 Sep '93

28 Sep '93

Gabor Kiss <kissg(a)sztaki.hu> found a bug in enkeys.pl. His fix is included below. It has been incorporated in the beta release. Future announcements like this will only be made to the list <db-beta(a)ripe.net>. Be sure to get on this list if you use the beta release. Daniel *** /tmp/T0a09361 Tue Sep 28 17:40:00 1993 --- enkeys.pl Tue Sep 28 17:17:28 1993 *************** *** 1,9 **** # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.13 $ ! # $Author: marten $ ! # $Date: 1993/08/19 14:53:37 $ # require "misc.pl"; --- 1,9 ---- # enkeys - extract keys from entry # # $RCSfile: enkeys.pl,v $ ! # $Revision: 0.14 $ ! # $Author: dfk $ ! # $Date: 1993/09/28 16:16:57 $ # require "misc.pl"; *************** *** 39,45 **** $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); } --- 39,45 ---- $i = $#result; while ($i >= 0) { $result[$i] =~ tr/A-Z/a-z/; ! $result[$i] =~ tr/a-z0-9\-,\.'\///cd; if (length($result[$i])<2) { splice(@result, "$i", 1); }

1 0

Beta RIPE database software
by Marten Terpstra 27 Sep '93

27 Sep '93

folks, I have made a beta database distribution for you all, with the emphasis on BETA. I just packed all the sources and stuff together, documentation and manual pages have not been updated to include all the changes we made over the last weeks, so this is "as is". A "real" distribution will follow whenever I am back in November, or Daniel may make one before that. You can find it on: ncc.ripe.net:/dbase-beta/dbase-beta.tar.Z NOTE this is NOT on ftp.ripe.net. The directory dbase-beta is NOT readable, but the dist can be fetched anyway. Have fun, -Marten

2 1

Re: Obsoleting "connect"
by Wilfried Woeber, UniVie/ACOnet 24 Sep '93

24 Sep '93

Folks, sorry for being late to voice my opinion, but I'm again out of office. BTW, I'm glad that Helsinki University provides my with decent access to the Internet! *> I tend to agree with you here but before we change the database config to *> make connect optional I guess we should get the okay from the chair who *> will be coordinating the new definitions for the objects. * *I agree. It is my understanding that this approach was a general consensus, thus I propose to (immediately) proceed in this direction. *> Also, we can take it a step further in that if the connect field is there *> it is LOCAL (something to add to the syntax checker ;-(). * *I was thinking of a multi-step phase-in of the new policy, and that this *would be the natural next step. Or do we just jump into it with both feet *rigt away? Well, sometimes you have to jump, although in this case I would strongly advocate a step-by-step approach. I'd also like to keep the possibility of submitting objects with connect: attributes other than LOCAL, as long as we have not agreed on and implemented a decent replacement functionality. More so if the attribute is optional, I don't see the case for doing more syntax checking for an attribute that is about to go away. I include the relevant section of the DB-WG minutes FYI. I think the wording does reflect the proposed approach reasonably well: ---------- 6. DB usage conventions and recommendations Quite some time was spent to discuss the connect: attribute of the network object. It was agreed that the only well-defined value is LOCAL. This attribute should eventually be obsoleted. Later it was noted that it is currently mandatory and should be made optional after one round of mailing-list discussion. However, there is a need for the functionality, maybe the community: approach is the right way to go (eg. create community NSF). Still there is concern that some of the approaches that are obvious for "old hands in networking" are not necessarily useful for the end-users. Maybe the tools coming out of the PRIDE project can help to solve this problem. NCC to start the discussion with a rough proposal before the next meeting. ---------- Wilfried.

3 2

Guarded Objects are now better protected
by Daniel Karrenberg 24 Sep '93

24 Sep '93

Dear colleagues, A recent accident has caused us to protect the guarded objects in the database a little better before the maintainer attribute is fully implemented. Guarded objects can from now on only be updated thru the manual procedure which involves plausibility checking by NCC staff. The manual procedure uses the old mailbox ripe-dbm(a)ripe.net. Any updates for guarded objects sent to the auto-dbm(a)ripe.net mailbox will be refused with the error message: *ERROR*: guarded objects cannot be updated via automatic procedure If you get such an error, re-send the update to ripe-dbm. Once the maintainer attribute is implemented authorisation will be handled automatically. Daniel PS: We hope to have the update procedure for guarded *attributes* deployed next week.

1 0

Obsoleting "connect"
by Havard Eidnes 23 Sep '93

23 Sep '93

Hi, if my memory serves me well, I think the RIPE DB working group concluded to restrict the legal values for the "connect" field to only "LOCAL", and if wider connectivity for a net has been established to not use this attribute in the objects in the database. However, this is somewhat at odds with the current definition of the connect field in the inetnum template, where the attribute is mandatory. So what do you put in an object which has wider connectivity than internal to the "home" autonomous system? My proposal to progress this decision (as mentioned at the end of the RIPE meeting) is thus to initially demote the "connect" attribute from mandatory to optional, and later add stricter checks in the RIPE database software for the values of the connect attribute. Currently updates missing the connect field are being bounced (I know, I tried it while I was at the RIPE meeting :-) - Havard

1 0

Minutes RIPE #16, DB Working Group
by Wilfried Woeber, UniVie/ACOnet 22 Sep '93

22 Sep '93

Dear all, I just recently submitted the draft minutes for the DB-WG meeting (jointly produced by Daniel am me) to Anne. Any comments welcome! Wilfried. ---------------------------------------------------------------------- Report from the Database-WG Meeting at the 16th RIPE Meeting, Amsterdam ----------------------------------------------------------------------- 0. Additions to/modifications of the agenda The proposed agenda was accepted. 1. The new Database Software Marten Terpstra provided a detailed report on the current state of the DB-Software, both from a software point of view as well as from the deployment point of view. The slides for this presentation can be found in the presentations directory in the RIPE document store: ftp.ripe.net:ripe/presentations The new software is in production use since Friday September 10th and until now there have not been any major problems. During the discussion it was again stressed, that the current implementation is built to do syntax checks according to the object description and not according to common usage practice. The RIPE NCC welcomes suggestions as to where the syntax checking needs to be changed. Currently objects with illegal schema are deleted from the database. One of the things discussed was how to avoid a possibly large number of bounced submissions. One way of doing this is to obtain (part of) the new software to do the checking locally. The beta-version of the software is available, although it probably makes more sense to wait for the official software distribution which will provide a dedicated syntax-checker. A syntax checker daemon at the NCC was also suggested to remove the requirement to run the software locally. A template generator was suggested as well. This needs more discussion on the mailing list. The NCC has run a syntax check on the whole database and was asked to make the syntax error output available. Daniel Karrenberg gave an overview on the "Authorization and Notification of Changes in the RIPE-DB" proposal. It was decided to implement it as proposed. Proposals on how to better support the distribution of the update process are very welcome. The discussion of implementing "guarded attributes" revealed concern about the possibility to delete an object that has a guarded attribute. It was agreed that the implementation will not delete any object as long as guarded fields are present. This will force removal of guarded fields from the object before the delete operation is accepted. The database is NOT keeping track of "pending deletes", thus the delete request has to be submitted again after removal of the guarded attribute(s). The NCC will look into ways to notify guardians of failed deletes. The originator of the delete request will of course be notified. The procedure to convert existing information into guarded information (eg. aut-sys: for the network object) was agreed as follows: - the NCC moves the information from the database to the guardian files - initially the NCC is the guardian - as soon as possible, responsibility for the files is transferred to the real guardian(s) 2. Database (and Software) Documentation The documentation will be structured to consist of - Object Definitions and general background information, by WW and NCC and available before the end of 1993 - Software Documentation, provided by the NCC asap - Maintainer's Guide (for eg. the Local-IRs) additional input and support is expected from the Local-IRs and others - Secondary Server Guide additional input and support is expected from the Local-IRs and others The Objects Definition and the SW-Documentation get priority, in the listed order. 3. Unique Person Handles Given the growth of the database, it is urgent to distinguish person objects for people with the same name! After another round of thorough discussion it was decided that RIPE suggests a global scheme to the InterNIC. One of the possible solutions is to reserve a sub-range of the NIC handle space for RIPE allocation, eg. XY3000-XY5000. If this approach fails, then WW and the NCC will propose a unique identifier scheme for RIPE (aka "RIPE Handle"). 4. Objects Review and Proposals The proposed CLNS routing object (dom-prefix:) was presented by Henk Steenman and accepted. Some minor loose ends how to check for syntax and maybe semantics of the hexadecimal strings that are the CLNS address-prefixes have to be ironed out (Henk Steenman and Tony Bates). The long-standing proposal to build a "Resource Object" was formally withdrawn. Then the discussion moved on to agree on how to make a smooth transition from ripe-60 to the ripe-81 format to describe the routing. The steps are as follows: - as soon as the guarded fields are implemented, ripe-60 entries will no longer be accepted. - ripe-60 information is converted to ripe-81 format. - when there are no longer any operational dependencies then all ripe-60 data will be removed from the database. Jean-Michel Jouanigot is the focal point for the ripe-60 --> ripe-81 transition coordination. Also the gateway: field for the network objects was confirmed to be obsolete and can be removed from the databse. 5. DB Exchange format(s) and procedures The circulated document about the agreed interchange format was briefly reviewed. Everything seems to be in place to actually start exchanges with the InterNIC. There was consensus that this has a very high priority. Currently the recommendation is not to try to get the various databases in sync manually. 6. DB usage conventions and recommendations Quite some time was spent to discuss the connect: attribute of the network object. It was agreed that the only well-defined value is LOCAL. This attribute should eventually be obsoleted. Later it was noted that it is currently mandatory and should be made optional after one round of mailing-list discussion. However, there is a need for the functionality, maybe the community: approach is the right way to go (eg. create community NSF). Still there is concern that some of the approaches that are obvious for "old hands in networking" are not necessarily useful for the end-users. Maybe the tools coming out of the PRIDE project can help to solve this problem. NCC to start the discussion with a rough proposal before the next meeting. 7. whois++ by Peter Deutsch et.al. The whois++ project was briefly mentioned, although the DB group had too little information to actually discuss the issue. AOB It was mentioned that there is a need for new tools to support the Local-IRs. This needs more discussion on the e-mail list. Action-List: ------------ Action 16.?: NCC Put together a consolidated distribution of the new DB software, including a separate syntax checker for objects Action 16.?: Wilfried Woeber Start discussion on the DB mailing list on new tools needed, eg. template generator, syntax checker daemon at the NCC... Action 16.?: NCC Make the error reports form the DB syntax check publicly available Action 16.?: NCC Implement changes to DB procedures according to the proposal "Authorization and Notification of Changes in the RIPE-DB" by Daniel Karrenberg Action 16.?: NCC Implement changes to DB procedures for the guarded attributes according to the agreement Action 16.?: Wilfried Woeber and NCC Produce documentation about "Background, History and Object Definitions" for the new database software before the end of 1993 Action 16.?: NCC Produce "Software Documentation" for the new databse software asap Action 16.?: NCC To approach the InterNIC to agree on the use of a sub-range of the global NIC-Handle space for RIPE usage Action 16.?: Henk Steenman and NCC (Tony Bates) Implement the dom-prefix: object for CLNS routing, after tightening the syntax definition and semantics of the CLNS-address hexadecimal string Action 16.?: Jean-Michel Jouanigot To coordinate the transition from ripe-60 to ripe-81 format for routing description Action 16.?: NCC Try to actually get the synchronisation of the various databases going, using the recently agreed DB Exchange Format Action 16.?: NCC Start discussion on the mailing list by providing a first proposal how the functionality of the badly defined connect: attribute could be replaced (with the target group of the end-user in mind!) by using eg. community: and other forthcoming tools from the PRIDE project ----------------------------------------------------------------------

2 1

Slides of the RR status
by Tony Bates 20 Sep '93

20 Sep '93

please note - as asked the slides I presented at the Routing working group session of the status of the RIPE RR are available from ftp.ripe.net:ripe/presentations/ripe-m16-tony-RRSTATS.ps.Z plus various other slides of possible relevence (i.e plenary talks and Marten's database presentation). All presentations are in the ripe/presentations directory. --Tony. The following are already availabel from the 16th RIPE meeting. ripe-m16-dfk-NCC-REPORT.ps.Z ripe-m16-marten-DBDETAILS.ps.Z ripe-m16-marten-DBPLEN.ps.Z ripe-m16-tony-GISSREP.ps.Z ripe-m16-tony-PRIDE.ps.Z ripe-m16-tony-RRSTATS.ps.Z ripe-m16-tony-RSREP.ps.Z

1 0

Re: FYI: InterNIC/MERIT/RIPE database exchange format
by Berthold Paffrath 16 Sep '93

16 Sep '93

Hi Marten, I have just read the syntax carefully :-) Some observations, just to be compared with your own: <version> ::= WDB_version: <version_no> should perhaps be "WDB-version" for consistency with "inaddr-server" / "admin-c" / ... (but the tag labels are weird anyway) same argument for "as-sblk" and "as-eblk" <host> ::= 1[<host_data>] 1*[<contact>] 1[<update_information>] might be 1*[<contact>|<host_contact>] otherwise remove definition of <host_contact> / <coordinator> / <altpoc> <ntype_data> ::= Research | Defense | Government | Commercial add Educational <parentdom_type> ::= COM | EDU | ROOT | NET | ORG | GOV | US either any domain or any top level domain? <host_data> ::= 1[<hostname>] 1*[<ip_addr>] 0[<nic_handle>] 0*[<nickname>] 0[<cputype>] 0[<opsys>] 0[<protocols>] 0[<hostmail>] either 0*[<protocols>] or how else do you specify multiple protocols? <phone> ::= phne: <datum> phone numbers in North American or International notation? <update_information> ::= 1[<name_date>] 1[<location>] 1[<maintainer>] 0*[<update_notify>] 0[<op_type>] must be 0[<db_operation>] <security-contact> ::= secur-c: <email-address> | <nic-handle> is never used (was omitted from <contact>?) Berthold Paffrath

1 0

changed attitude to the proposed resource object
by Milan Sterba 13 Sep '93

13 Sep '93

Dear colleagues, After having confronted my old proposal for registering a new RIPE DB object describing network resources with the ongoing activities on network information discovery and uniform resource [locator,name, identifier ...] I have changed my views on the resources as objects registered in RIPE DB. My proposal was more aimed at registering servers (ftp, gopher, WWW, wais ...) rather than information about individual resources (single document, file, package, database access etc.) which is in fact what the users really need. Also the NCC registration procedures are not scaled for this type of task. Ther clear tendency now is towards automatic or semi-automatic resource registration procedures (archie and veronica can serve as examples). The resource indexing and registration seem to become a new type of network service which belongs more to network service providers rather than to the NCC. The role of the NCC rather be to help to coordinate this new type of services and maybe registrate and disseminate pointer information about network resource registration services in Eurooe. For the above reason I would like to withdraw my proposal for a resource object in RIPE DB. RIPE should probably keep an eye on recent evolutions in this field but probably shouldn't get directly involved with the resource registration process itself. Regards Milan Sterba P.S. Here are some references to documents which lead me to this decision : Weider, Chris : Resource transponders, March 1993 (internet draft - draft-ietf-iiir-transponders-00.txt) Berners-Lee, Tim : Uniform Resource Locators, July 1993 (internet draft - draft-ietf-uri-url-01.{txt,ps}) Weider, Chris, Deutsch, Peter : A Vision of an Integrated Internet Information Service (internet-draft - draft-ietf-iiir-vision-00.txt) -- BEWARE - MY TELEPHONE NUMBER HAS CHANGED !!!! ====================================================================== Prague University of Economics e-mail : Milan.Sterba(a)vse.cz Computing Center tel : +42 2 24 21 79 00 nam. W. Churchilla 4 home: +42 2 823 78 59 130 67 Praha 3 fax : +42 2 236 46 24 Czech republic =======================================================================

1 0

assign versus dbm in the new software
by Marten Terpstra 09 Sep '93

09 Sep '93

People, I have put the difference between assign and dbm in the new automatic aliases as well. We now have: auto-dbm - similar to ripe-dbm, but automatic auto-assign - similar to assign, ie network objects that are already present wil be bounced, persons can be updated though. This to allow for tech-c and admin-c that need to be updated with these network numbers to simply go through. deletes are accepted either way, but preferably though auto-dbm. The software also supports the LONGACK string in the subject line of the mail which indicates that you wish verbose output, ie at least a one line status per object. Objects with warnings or errors will always be returned. It seems we are almost ready for the cutover tomorrow. Be prepared for fast and different looking acknowledgements ;-) -Marten PS It may happen that tomorrow some of the additional features of a database update (such as the split version for anonymous ftp, the WAIS index, and the cisco access-lists) might be a bit later. We have to track all the stuff we currently have installed that has to do with the database, and transform them. Almost the full staff will be in on the weekend (RIPE preparation) to look after things in case it breaks (no of course it doesn;t)

1 0

Re: misleading use of the connect: field in inetnum: object
by Wilfried Woeber, UniVie/ACOnet 08 Sep '93

08 Sep '93

Hi Daniel, >the real problem with the "connect" attribute is that it still is the >badly defined kludge it has been from the start. I can say so because I >invented it. Today we have a well defined and agreed way of specifying >the information you want: It is called ripe-81 by the document fans and >"The Routing Registry" by afficionados. I had one and only one basic concern: when we put info into the DB, this info should HELP and not CONFUSE. I agree with you that "connect:" is maybe far from optimal. >In my opinion we should put our efforts in getting the RR populated >rather than trying to specify how to use an un-specifyable kludge. So now I've got another concern: populating the RR helps the "afficionados", but probably doesn't help the (end-)user in finding out what he/she can expect. I'd assume people are still thinking in terms of NORDUnet, NSF, RIPE and not in terms of ASxxx and ASyyy. And the basic issue remains - you can just as well put some string into the "as-*:" fields and still have only EARN-E-Mail connectivity... >The original plan was to keep connect alive with the only legal value of >LOCAL. Maybe we shouldn't even do this. An item for discussion at the RIPE >meeting! Definitely! And thanks for spending some minutes on it. Cheers, Wilfried.

5 4

FYI: InterNIC/MERIT/RIPE database exchange format
by Marten Terpstra 08 Sep '93

08 Sep '93

Please find below the exchange format as agreed with InterNIC, MERIT and RIPE. just for your information. -Marten WHOIS Database Transfer Parse Syntax 1.0 ------------------------------------ Note: Brackets [] enclose subrules, with a prefix indicating optionality and repetition as follows: "0[]" - optional "1[]" - required "0*[]" - none or any number "1*[]" - at least one --------------------------- LANGUAGE ---------------------------------- <file> ::= 1[<version>] 1*[<record>] 1[<eof>] <version> ::= WDB_version: <version_no> <version_no> ::= 1.0 <record> ::= <begin_data> <data> <begin_data> ::= --- <eof> ::= END OF FILE <data> ::= <network> | <domain> | <host> | <individual> | <as> <network> ::= 1[<network_data>] 1*[<contact>] 0*[<inaddr_server>] 1[<update_information>] <domain> ::= 1[<domain_data>] 1*[<dom_contact>] 0*[<dns_server>] 1[<update_information>] <as> ::= 1[<as_data>] 1*[<as_contact>] 1[<update_information>] <individual> ::= 1[<individual_data>] 1[<update_information>] <host> ::= 1[<host_data>] 1*[<contact>] 1[<update_information>] /******* network-specific information *******/ <network_data> :: = 1[<netip_type>] 1[<netname>] 0[<network_type>] 1[<activated>] 0[nic_handle] 1[<organization>] <netip_type> :: <netip_addr> | <netblk> <netip_addr> ::= ntnum: <datum> <netblk> ::= ntsblk: <datum> nteblk: <datum> <netname> ::= ntnam: <datum> <network_type> ::= ntype: <ntype_data> <ntype_data> ::= Research | Defense | Government | Commercial <inaddr_server> := inaddr-server: <host_key> /******* domain-specific information *******/ <domain_data> ::= 1[<dom_name>] 1[<parentdom>] 0[nic_handle] 1[<organization>] <parentdom> ::= pdom: <parentdom_type> <parentdom_type> ::= COM | EDU | ROOT | NET | ORG | GOV | US <dom_name> ::= dnam: <datum> <dom_contact> ::= <contact> | <zone_contact> <zone_contact> ::= zone-c: <email-address> | <nic_handle> <dns_server> := dns-server: <host_key> /******* as-specific information *******/ <as_data> :: = 1[<as_type>] 0[<as_name>] 0*[<asin>] 0*[<asout>] 0*[<asdefault>] 1[<activated>] 0[nic_handle] 1[<organization>] <as_type> :: <as_number> | <as_block> <as_number> ::= asnum: <datum> <as_block> ::= as_sblk: <datum> as_eblk: <datum> <as_name> ::= asname: <datum> <asin> ::= asin: <datum> <asout> ::= asout: <datum> <asdefault> ::= asdefault: <datum> <as_contact> ::= <contact> | <as_guardian> <as_guardian> ::= asguardian: <datum> /******* host-specific information *******/ <host_data> ::= 1[<hostname>] 1*[<ip_addr>] 0[nic_handle] 0*[<nickname>] 0[<cputype>] 0[<opsys>] 0[<protocols>] 0[<hostmail>] 1[<organization>] <hostname> ::= hname: <datum> <ip_addr> ::= ipaddr: <datum> <nickname> ::= nname: <datum> <cputype> ::= cpu: <datum> <opsys> ::= opsys: <datum> <protocols> ::= proto: <datum> <hostmail> ::= hmail: <datum> <host_contact> ::= <coordinator> | <altpoc> <coordinator> ::= coord: <datum> <altpoc> ::= altpoc: <datum> /******* individual-specific information *******/ <individual_data> ::= 1[<name>] 0[nic_handle] 1[<organization>] 1*[mailbox] 0*[<phone>] 0*[<fax>] <name> ::= <name_components> | <whole_name> <name_components> ::= 1[<last_name>] 1[<first_name>] 0[<middle_name>] 0[<name_suffix>] 0[title] <last_name> ::= lname: <datum> <first_name> ::= fname: <datum> <middle_name> ::= mname: <datum> <name_suffix> ::= nmsuff: <datum> <title> ::= ttle: <datum> <whole_name> ::= whname: <datum> <mailbox> ::= mbox: <datum> <phone> ::= phne: <datum> <fax> ::= fax: <datum> /******** update information *********/ <update_information>::= 1[<name_date>] 1[<location>] 1[<maintainer>] 0*[<update_notify>] 0[<op_type>] <name_date> ::= updt: <datum> <location> ::= source: <place> <place> ::= RIPE | MERIT | INIC | DNIC | ISI | ANIC <maintainer> ::= maint: <place> <update_notify> ::= updtnot: <datum> <db_operation> ::= operation: <op_typ> <op_type> ::= ADD | MODIFY | DELETE /********* common elements *********/ <organization> ::= 1[<org>] 0*[<address>] 1[<country>] <org> ::= org: <datum> <address> ::= addr: <datum> <country> ::= cntry: <datum> <contact> ::= <admin-contact> | <tech-contact> <activated> ::= actvd: <datum> <admin-contact> ::= admin-c: <email-address> | <nic_handle> <tech-contact> ::= tech-c: <email-address> | <nic_handle> <security-contact> ::= secur-c: <email-address> | <nic_handle> <host_key> ::= <datum> /*either nic handle or ip number*/ <nic_handle> ::= nichandl: <datum> <datum> ::= 1*[<alphanum>] NL --------------------- TAG FIELD SEMANTICS ------------------------------- /****** network-specific stuff ******/ ntnam: network name of network ntnum: registered IP network number [format: xxx.xxx.0.0 for class B xxx.xxx.xxx.0 for class C] ntsblk: registered IP network number - start nteblk: registered IP network number - end ntype: network type - one of R = Research D = Defense G = Government C = Commercial E = Educational actvd: Date in which the domain/network was initially registered [format: YYMMDD] inaddr-server: inaddress servers for the paticular network (either host ip address or hostname or nic handle ) /****** domain-specific stuff ******/ dnam: domain name of domain. pdom: parent domain of domain (ie. NIC.DDN.MIL is DDN) zone-c: zone contact (found in RFC 1032) (either mail-address or nic handle) dns-server: servers for that paticular domain (either host ip address or hostname or nic handle ) /****** asn-specific stuff ******/ asnum: as number as_sblk: as start number (of a block) as_eblk: end number (of a block) asin: accepted routes from other ASs (found in RIPE-81) asout: routes announced to other ASs (found in RIPE-81) asdefault: how default routing is handled (found in RIPE-81) asguardian: guardian of this AS /******** host-specific stuff ********/ hname: hostname of host nname: nickname(s) of host ipaddr: IP address of host cpu: cpu of host (found in RFC 1060) opsys: operating system of host (found in RFC 1060) proto: protocols supported by host (found in RFC 1060) hmail: role mailbox of host administator /***** individual-specific stuff *****/ lname: last name of individual fname: first name of individual mname: middle initial of individual nmsuf: name suffix of individual (ie JR., SR., ...) ttle: title or rank (Capt., Lord, ...) mbox: network mailbox of individual in internet format phne: phone number of individual fax: fax number of individual /****** common stuff *******/ nichandl: handle given by the NIC org: organization name addr: street address cntry: country source: originator of record (RIPE/MERIT/NIC) updt: updated information (who/when) [format: YYMMDD-HHMM userid] tech-c: technical coordinator of network/domain/host (found in RFC 1032) (either mail-address or nic handle) admin-c: administrative coordinator of network/domain/host (found in RFC 1032) (either mail-address or nic handle) secur-c: security coordinator of network/domain/host ----------------------- EXAMPLES --------------------------------- INDIVIDUAL: WDB_version: 1.0 --- lname:McColum fname:Robert mname:A nmsuf:Jr. ttle:Computer Developer Manager nichandl:RM584 org:Government Systems, Inc. addr:14200 Park Meadow Drive addr:Suite 200 addr:Chantilly, VA 22021 cntry:US mbox:bobm@NIC.DDN.MIL phne:(703) 802-8476 updt:911029-120500 STANB source:NIC END OF FILE ------------------------------------------------------------------------- NETWORK: This is a sample network record that has: 1) Peter Elford (PE33) is the tech contact. 3) JATZ.AARNET.EDU.AU (AARNET) (already registered) as inaddr-server 3) ANU.ANU.EDU.AU (ANU) (already registered) as inaddr-server 4) MUNNARI.OZ.AU as a new inaddr-server WDB_version: 1.0 --- ntnum:192.107.107.0 ntnam:AARN-DEV ntype:Research Nactvd:890203 org:Australian Academic and Research Network addr:P.O. Box 1142 addr:Canberra ACT 2601 cntry:AU tech-c:PE33 inaddr-server:AARNET inaddr-server:ANU inaddr-server:128.250.1.21 updt:910103-224721 STONED source:RIPE maint:RIPE --- hname:JATZ.AARNET.EDU.AU ipaddr:139.130.204.4 nichandl:AARNET cputype:SUN-4/60 opsys:UNIX protocols:UDP/DOMAIN org:University of Melbourne country: AU uptd:900706-105714 MACGOWAN source:NIC maint:NIC --- hname:ANU.ANU.EDU.AU ipaddr:130.56.4.1 nichandl:ANU cputype:MICROVAX-II opsys:ULTRIX protocols:UDP/DOMAIN org:University of Melbourne country: AU updt:900706-105714 MACGOWAN source:NIC maint:NIC --- hname:MUNNARI.OZ.AU ipaddr:128.250.1.21 cputype:SUN-4/260 opsys:UNIX protocols:UDP/DOMAIN org:University of Melbourne country: AU updt:900705-105714 MACGOWAN source:RIPE maint:NIC --- lname:Elford fname:Peter nichandl:PE33 org:Australian Vice Chancellors Committee addr:Churchill House addr:Northbourne Ave, Braddon addr:GPO Box 1142 addr:Canberra ACT 2601 cntry:AU mbox:p.elford@AARNET.EDU.AU updated:900705-105714 MARKK source:MERIT maint:NIC END OF FILE

1 0

Re: ** URGENT ** New database software at the NCC
by Wilfried Woeber, UniVie/ACOnet 08 Sep '93

08 Sep '93

Marten, >Just some explanation, the messages sent to assign are first checked to see >if they are already in the database, and currently bounced back to the NCC if >they are. I think what I will do is create something like auto-assign, which >has the same "on-the-fly" features as auto-dbm, but will only ADD new >objects, and bounce all objects that are already present. This would mean >that also contact people that are already present will not be updated when >sent to auto-assign. ...does this mean that we are no longer able to submit *updates* for person objects along with a new network object from the 193,194 address range? If this is the case, then I think we should generally go for a system where *all* objects *with the exception of objects for newly assigned networks* should go to the ripe-dbm mailbox. Wilfried.

1 0

** URGENT ** New database software at the NCC
by Marten Terpstra 08 Sep '93

08 Sep '93

Dear people, You have all probably heard that new RIPE database software has been written at the NCC. We are convinced that this software should be used as soon as possible at the NCC, because the current update procedure has had several changes made already to keep it running with the current size of both the database and the amount of updates we receive. Therefore, we have planned to start using the new software at the NCC this Friday September 10th, at 10 AM. The new software has some consequences for whois users and people that send in updates. These consequences have been listed below. Please read the document below carefully. If you have any questions or major objections, please contact me, Daniel or Tony. Cheers, Marten PS All updates sent to the new mail alias before Friday 10 AM will either bounce, or update some test database. These updates will NOT be incorporated in the real RIPE database. ----- Introduction The software for the RIPE database has recently been completely rewritten, and the new implementation will have some effects on the behaviour of the database software as compared to the software currently in use at the NCC. This document describes the impact the new RIPE database software will have on usage of the database and on updates to it. USER IMPACT With the new database software, there will be some changes in the bahaviour of the database whois server. These include: New -s flag The indexed database will still contain information from various sources. As before normally only the RIPE information will be shown. The flag for requesting information from all sources remains the same (-a), and a new flag will be introduced to specify one or more specific source (-s source). The RIPE whois client available from the RIPE document store has been modified to accept this flag. Recursive Lookups Limited to Source of Reference The "-a" flag, or asking for information from multiple sources will show a slightly different behaviour. The old software used to perform recursive lookups on ALL the selected sources. This means that a contact person referenced by a NIC entry would be looked ap and listed from ALL other sources. The new software will ONLY perform recursive lookups in the source where the reference was found. Consequence is that one does not get a mix and match of referenced information from various sources. All references are ONLY looked up in the source where they are referenced. This was done to limit output volume and user confusion. Strict Enforcement of Object Definitions The current database file has objects in it that do not conform to the official object definitions. The new whois server will only output the legal fields for such an object. So, it may be that a network object contains a zone-c attribute in the database file, but the whois server will never show this attribute, because it is not in the network object definition. An overview of the defined attributes per object can be found at the end of this document. UPDATE IMPACT There are a number of changes that will affect people sending in updates for the RIPE database. Real Time Updates The new database software works with on-the-fly updates. This means that accepted and acknowledged database updates will be visible immediately in the whois server running at the NCC. These changes will not be visible immediately in the FTPable database file maintained via the RIPE Document Store. Once a day -or night rather- an automatic "cleanup" procedure will run which generates the FTPable file and adds all the guarded attributes as specified in the guardian files maintained at the NCC. This means that the database available for anonymous FTP does not necessarily have the same information as the running database. Guarded attributes will not be changed using the normal update procedure, they will be added once a day, and remain unchanged until the next cleanup time. New Update Procedure A new mailbox will be installed for direct access to the new database software without RIPE NCC staff intervention. This means fast response times, but since the updates are not looked at by the staff, updates containing errors will be bounced just as fast. The new mailbox will be <auto-dbm(a)ripe.net>. The old mailboxes will remain, and the NCC staff will look at mails directed to one of these mailboxes and forward updates to the new update procedure, after some very basic checking. The NCC will NOT correct all syntax errors in updates sent to one of these mailboxes, but it might correct some obvious errors. As before all updates and acknowledgements will be logged at the NCC. This means that errors and "strange" updates can be tracked quite easily. Stronger Syntax Checking The syntax checking in the new software has been improved and strengthened. As with the old software, database objects that cause errors will be bounced, and NOT be incorporated in the database. Warning messages are usually used to indicate corrections that have been made to the object sent in. Objects with warnings WILL be incorporated in the database, with the changes made as indicated in the warning messages. In general error and warning messages are descriptive and will give some indication where an error or warning was generated. The new syntax checking has the following rules: Database objects that miss mandatory attributes will generate an error, and will be bounced. An overview of the defined attributes per object can be found at the end of this document. Objects that have attributes that are not defined in the object, will generate an error and will be bounced. Objects that have syntax errors in the values of the various attributes will generate an error, and will be bounced. Objects that have a date in the changed field that is prior to the date in the current database entry will generate an error and will be bounced. Guarded attributes in updates will be ignored other than generating a warning if the values do not match the current value in the database. Currently only the boundary gateway and routing privilege in the network object are guarded attributes. The aut-sys attribute in the network object will be turned into a guarded attribute as soon as possible. Deletions have been made more easy to perform. To delete an object, it is sufficient to send in that object plus a delete: attribute that describes why this object has to be removed from the database. Objects that need to be deleted, will NOT be checked for syntax, but must exactly match the object currently in the database, otherwise an error will be generated, and the object will not be removed from the database. The order of the different attributes in the updates is NO LONGER relevant for the match. The order of different lines in the same attribute is. The new syntax rules have been determined from the original object definitions. It may well be that some syntax rules have been made too strict, or are simply wrong. Please do not hesitate to contact us in these cases. The syntax is not fixed forever. Attribute definition per object as used by the new database software. inetnum object Mandatory: inetnum netname descr country admin-c tech-c connect changed source Optional: aut-sys (will be guarded asap) gateway (obsolete) nsf-in nsf-out (obsolete ?) routpr-l (guarded) bdrygw-l (guarded) remarks rev-srv person object Mandatory: person address phone changed source Optional: e-mail fax-no nic-hdl remarks domain object Mandatory: domain descr admin-c tech-c zone-c changed source Optional: dom-net nserver sub-dom remarks aut-num object Mandatory: aut-num descr admin-c tech-c changed source Optional: guardian as-in as-out default remarks bdry-gw and rout-pr will be obsolete in the near future.

2 2