- db-wg - mailman.ripe.net

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

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

07 Sep '93

Dear all, (and sorry for a possibly too wide distribution). We had some instances recently, where operations people were prompted by users to sort out connectivity problems to a given network that couldn't be reached. The most obvious thing to do is to look into the RIPE-DB, of course. The network(s) were registered, but further investigation revealed that the network(s) did not yet have full connectivity to the Internet. However the information in the connect: field of the network object contained strings like RIPE, NSF or EASI, but no indication about the more local situation. For the end-user, and most probably for a lot of operations people as well, it is definitely not obvious that the connect field is more or less just a (sometimes very misleading!) comment. Thus I propose to discuss and agree on a (RIPE) recommendation along the following lines, at least for registering new networks in the database: - The Local-IR registers the network with a (local/regional) network or service-provider string, but without using any misleading flags in the connect: field like RIPE, NSF, EASI... If -for whatever reason- commonly used strings are used, then the remarks: field should give a very clear indication about expected connection date(s) and service restrictions (like dial-up networks, e-mail only links...). - When the network is connected to a service provider to configure routing, (Reverse-)DNS, or services like e-mail, etc. the network should be tagged with a useful service-provider string. This "state" could and probably should be skipped for situations where full connectivity could be expected within a few days. Examples: ACONET or SURFNET for national academic networks, EUNET-DE for a EUnet connection, XLINK and the like Note: I'm not proposing to use the LOCAL tag, because this means that no connectivity to the outside world is wanted or intended at all! - Only after the point in time where there is really full connectivity, the usual strings like RIPE, NSF, etc. should be added to the connect: field, out-dated comments removed, DNS and AS-Number information added, and the like. In addition to that I propose to list the connect: strings in a kind of intuitive "local to global" sequence. Examples: "ACONET RIPE NSF" or "ARNES EMPB RIPE NSF" or "EUNET-XX RIPE" Thus we would end up with really useful information in the connect field, and maybe also with more complete database objects, because information is available for the second or last update phase that usually cannot be submitted when registering the network. Could I have your opinions and comments please? An example for a network in Western-Nowhere, that is connected to a regional net that gets connectivity throug ACOnet and EBONE would be: Phase-1 connect: WNWNET !while setting up the net !or eg. e-mail only conn Phase-2 connect: WNWNET ACONET RIPE !after adding... bdrygw-l: ACONET Phase-3 connect: WNWNET ACONET RIPE NSF !after registering NSF-conn. Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 436111 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 436111 170 NIC: WW144 -------------------------------------------------------------------------------

3 2

doc update for the (new) RIPE DB-Software
by Wilfried Woeber, UniVie/ACOnet 01 Sep '93

01 Sep '93

Dear DB-interested folks, according to action 15.11 on me from the 15th RIPE meeting, and as the beta test phase for the new DB-Software is making good progress, we have to agree on the structure, contents and production of new or updated documentation as well. Thus I ask all of you to contribute to this discussion on the DB-WG list. A copy of this is also sent to the Local-IR list FYI, however I propose to have the real discussion going on on th DB-WG list. Amongst other things, I think we should agree on - what is the intended audience for the doc? - what is a good structure? - who should contribute and how/when do we produce the paper(s) Regards, Wilfried. ------------------------------------------------------------------------------- Wilfried Woeber : Wilfried.Woeber(a)CC.UniVie.ac.at (Internet) Computer Center - ACOnet : Z00WWR01(a)AWIUNI11.BITNET (EARN) Vienna University : 29133::WOEBER (SPAN/HEPnet) Universitaetsstrasse 7 : Tel: +43 1 436111 355 A-1010 Vienna, Austria, Europe : Fax: +43 1 436111 170 NIC: WW144 -------------------------------------------------------------------------------

2 1

Authorisation and Notification of Changes
by Daniel Karrenberg 01 Sep '93

01 Sep '93

Folks, here is my long promised writeup on the "notify" and "maintainer" attributes. I hope it is clear enough. It will be discussed at the next RIPE meeting. Hopefully no substantive changes will be necessary. Suggestions on how to improve clarity are always welcome of course. Daniel Authorisation and Notification of Changes in the RIPE Database Daniel Karrenberg RIPE NCC ABSTRACT Two new attributes for all objects in the RIPE database are proposed in order to implement a generalised method for authorising changes and to notify interested parties of any changes made to a specific object. In addition the authorisation method provides a convenient way for distributed maintenance of the database. The Notify Attribute Each RIPE database object will have an optional attribute called notify. The value of the notify attribute is one valid RFC822 e-mail address. There can be multiple notify attributes. Whenever the object concerned is changed in the database a notification message will be sent to each e-mail addresses appearing in a notify attribute. This makes it straightforward to keep track of changes to specific objects and prevent changes from going unnoticed. Multiple notify attributes make it possible to notify a number of interested parties. This could be used to alert all contact persons for an object or the local contact per- sons as well as the relevant service provider. Although it may be tempting to put many notify attributes on database objects in order to notify everyone even remotely interested, this is not recommended. A very few key addresses should be sufficient. Prior to entering any mail address here, the explicit or implicit consent of the person responsible for that particular mailbox needs to be obtained. - 2 - The Maintainer Attribute Each RIPE database object will have an optional attribute called maintainer. The value of the maintainer attribute is a registered maintainer name. There can only be one main- tainer attribute per object. Whenever a change to the object concerned is attempted in a copy of the database the maintainer attribute of the current database object is examined. If there is no maintainer attribute or the maintainer name is authorised to make changes in the copy of the database the update proceeds causing the necessary notifications as per the notify attribute. If the maintainer name has no authorisation to change the local copy of the database, the update request is forwarded to the maintainer for processing. No notifications are per- formed in this case. The following data needs to be maintained locally about each maintainer: Maintainer name Authority none change whole database change only own objects Forwarding Info mail/RFC822-address other/address Authorisation none mail/RFC-822-address other/key Application 1: Regional Registries In order to align the InterNIC and RIPE databases it has been agreed that European objects will be maintained in Europe. The RIPE NCC will provide the data for these objects to the InterNIC for inclusion in their database without further processing. The RIPE NCC will refer all updates for non-European objects to the InternNIC and the InterNIC will refer all updates for European objects to the RIPE NCC for processing. This can be achieved by creating two maintainer names: - 3 - INTERNIC and RIPE-NCC and tagging all European objects with RIPE-NCC and vice versa. The tags can be phased in slowly, avoiding a flag day with the associated massive consistency problems. Over time all objects in the RIPE database would be thus tagged. Updates from third parties for objects with the maintainer attribute added can now be referred correctly. Updates from the other registry for objects it maintains can be accepted without further checking. Example 2: Local Registries Some European local registries keep their own copies of the database containing the objects within their area. This leads to consistency problems as updates can be sent both to the RIPE NCC and to the local registry. Referrals are per- formed by ad hoc methods. Frequently only one of the data- bases is updated and alignment needs to be done manually. By registering maintainer names for the local registries and tagging the appropriate objects this can be automated and made more reliable. The NCC would forward update requests for locally maintained objects to the local registry unless they come from that local registry itself. Example 3: Guarded Objects Some objects such as the autonomous-system object (see ripe-81) need to be protected against changes by anyone but a designated guardian since changes to these objects have a direct operational impact. By registering appropriate maintainer names for the guardi- ans and tagging the objects to be protected this functional- ity can be provided in a canonical way. Any change by third parties to such an object will not only be prevented but cause automatic notification of the guardian through the forwarding mechanism.

2 1

beta release new database software
by Marten Terpstra 20 Aug '93

20 Aug '93

People, I have made a distribution of the new software. It includes most of the stuff you would need for indexing and updating a RIPE like database. For those of you who have been playing with the 2 early releases, here are some of the changes: - minor change to key generation routine (to allow certain chars) - dbupdate can now be used as an email responder - more stuff made configurable, more configuration options - some general bug fixes - a bit more documentation (I know, still nowhere near perfect) You will need some familiarity with the RIPE database structure to get this stuff running without much hastle. I have tried making it into a read, install and run package, but it is not quite really. Please understand that it IS still beta, and there may well be bugs everywhere, and it may not be as configurable as you would like, but I'm working on that. I just wanted to get this thing out so that you could play with it a bit, and see if you like it. If you do not have some time to spare to install and try to understand it, I would advide not to get the stuff just yet, but wait for the first real release (expected some time around the RIPE meeting). This release does not understand guarded fields yet, all hooks are in, just some code missing. The indexer and whoisd have been tested by some people already and did not show any major bugs. The update mechanism is not tested too well yet, so try building some test databases first to see how that all works. Most of the working and installation is described in 2 files, INSTALL and README. README should explain enough to get you started, experiment after that. You can find the stuff on: ncc.ripe.net:dbase-beta/dbase-beta.tar.Z Directory dbase-beta is unreadable, but you CAN fetch the file and note that this is NOT on ftp.ripe.net. Oh, you need PERL to run all this stuff ... Enjoy, -Marten

1 0

RIPE Database beta-software trials ...
by Marten Terpstra 16 Aug '93

16 Aug '93

[Apologies for all who received this message on the dns-wg list already, that was obviously a mistake ... -Marten] Dear all, We finally have some beta software running at the NCC for the database, and we would like you to test some things. We have created an empty test RIPE database on ncc.ripe.net running with the new whois daemon. You can send in updates to: testdb(a)ripe.net It will be processed and incorporated in a test database running on ncc.ripe.net (also a whois daemon running on that database). You should receive a ack mail back (to the Reply-To field, or From: is no Reply-To field present) and you should be able to find it in the whois server immediately. Acks should be sent to you within minutes. You can also delete objects in that test database, by simply adding a delete: line to an object. So, person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: marten(a)ripe.net nic-hdl: MT2 changed: marten(a)ripe.net 930503 source: RIPE delete: just try and delete this thing should delete this object in the database, if all fields are the same as in the database. The ordering of fields does not matter, just as long as attributes with the same name are in the same order, ie in the object above you cannot change the place of two "address:" fields. Also the place of the delete field does not matter, it can be anywhere in the object. Updating should be very quick, ack mails should be sent to you within minutes. Please try some stuff and see what happens. Comments on the format of the ack mail are also appreciated. Currently verbose ack is default ie you get at least a one line ack per object you send in, and the full object if there were errors or warnings. If you send in objects with a source other than RIPE it should complain that this is an unknown source and should refuse the update. -Marten PS All requests are already properly logged so be careful with those deletes ;-) PPS The syntax checker for this test database is VERY strict, simply because there is no manual intervention from the NCC any longer. It may well be that existing objects in the real database are no longer accepted ;-)

1 0

RIPE database software beta sites needed
by RIPE Database Management 04 Aug '93

04 Aug '93

Folks, Finally parts of the new RIPE database software are ready for some beta testing. I would like a not too big number of sites/people that are willing to run some tests on the new software, and actually have some time to spend on this to make themselves known to me. I have created a new (temporary) mailing list <db-beta(a)ripe.net> which will deal with all the beta-testing on the software. That is where I will put details on where to get the software and will send bug fixes. If you are willing to participate in the beta testing, please send a mail to db-beta-request(a)ripe.net or simply reply to this message. If you just want to see what is going on with the beta testing, you are welcome to join the list as well. Just hope that not all of you will be just listening in ;-) Suggestions/comments welcome. -Marten PS Some people already indicated they wanted to join the list, so currently I have the following people on the db-beta list: Wilfried Woeber <Wilfried.Woeber(a)CC.UniVie.ac.at> # db-wg chairman Tony Bates <tony> Marten Terpstra <marten> GARR NIS <info(a)nis.garr.it>

1 0

Re: The addition of guarded fields
by farrache＠ccpnxt5.in2p3.fr 27 Jul '93

27 Jul '93

Marten, I think that the RIPE NCC have to split blocks. RIPE NCC is a neutral organisation that can do it without problems. If we do not agree on that, that means a very long procedure to update the guarded fields, and I believe that no service provider will want to rely on the efficiency of a NIC for its routing policy. So that mean that nobody will use those fields for routing, so the information may be completly out of date. But I agree with Blasco on one point, the maintainer of the block must be inform that the block has been splitted Gilles

3 2

Re: Unique NIC/RIPE/xxx-Handles
by scottw＠internic.net 27 Jul '93

27 Jul '93

If a centalized number is important we have completed and are testing software that will allow other NICs to get InterNIC handles for their users. Access to the InterNIC handle generator will be controled by the source address of the host requesting the handle. I strongly beleive that handle generation below the regional registry would be dangerous. To resurve a handle we only require the name and email address. Scott

1 0

The addition of guarded fields
by Marten Terpstra 27 Jul '93

27 Jul '93

People, I need your help on an implementation issue. I am working on the addition of guarded fields, and especially on the splitting of blocks in case some nets inside a block get different guarded fields than others. What I have implemented currently is that a block will be split into biggest possible parts containing the same guarded information, so for instance: inetnum: 193.252.0.0 - 193.252.254.0 netname: FRANCE-TELECOM-BLOCK-5 ... And then add an AS number (from guardian files) to network 1 and 2, and a different one to 3 and 4, and leave the rest as it is, will result in: *in: 193.252.0.0 *na: FR-TELECOM-BLOCK-5 ... *in: 193.252.1.0 - 193.252.2.0 *na: FR-TELECOM-BLOCK-5 *as: AS1104 ... *in: 193.252.3.0 - 193.252.4.0 *na: FR-TELECOM-BLOCK-5 *as: AS786 ... *in: 193.252.5.0 - 193.252.254.0 *na: FR-TELECOM-BLOCK-5 ... This procedure works nicely but I still have some problems with this: - its is VERY slow (and I do not know how to improve that) - I still do not like the idea of splitting up blocks that are managed by someone else - In oder to keep the database size under control, we should also implement generating blocks again from individual entries in the database, but then again I am fiddling with someone elses data, which I do not like at all ... Could we get some opinions ? -Marten

2 1

RE: The addition of guarded fields
by Wilfried Woeber, UniVie/ACOnet 27 Jul '93

27 Jul '93

>And then add an AS number (from guardian files) to network 1 and 2, and a >different one to 3 and 4, and leave the rest as it is, will result in: > >*in: 193.252.0.0 >*na: FR-TELECOM-BLOCK-5 >... > >*in: 193.252.1.0 - 193.252.2.0 >*na: FR-TELECOM-BLOCK-5 >*as: AS1104 >... > >*in: 193.252.3.0 - 193.252.4.0 >*na: FR-TELECOM-BLOCK-5 >*as: AS786 >... > >*in: 193.252.5.0 - 193.252.254.0 >*na: FR-TELECOM-BLOCK-5 >... And you end up with 3 separate *in: objects that share the same *na: I always thought this is illegal... But maybe I'm wrong. >This procedure works nicely but I still have some problems with this: > >- its is VERY slow (and I do not know how to improve that) >- I still do not like the idea of splitting up blocks that are managed by > someone else Well there are two sides to the game: -a you shouldn't mind changing someone else's data, if it is wellknown and it can be implemented in a very streightforward manner. I never regard my objects in the DB as my personal "hands off" property, but rather as shared info submitted to achieve a very well-defined and well-understood goal. -b when and if it is not easy to describe, understand and implement, and if the result would even possibly violate current rules, I'd propose to push the issue further down the tree to have it resolved. >- In oder to keep the database size under control, we should also implement > generating blocks again from individual entries in the database, but then > again I am fiddling with someone elses data, which I do not like at all ... I'd appreciate getting a message proposing recombination of entries, or even a pre-fabricated message(s) to accomplish this. Then I would generate or just check/update these things and submit them as an update. Once again, for me it wouldn't be a privacy issue, but rather I like to know that things are going to change. It could point me even to a local problem. Wilfried.

2 1

Re: The addition of guarded fields
by Marten Terpstra 27 Jul '93

27 Jul '93

Dave Morton <Dave.Morton(a)ecrc.de> writes * Marten, * No big help I know - this looks messy and a real nasty can of * worms. Mabye the db needs a whole new type of object for these * damm blocks, other than that I don't see any real way out ! ? * Dave Maybe you are right, but right now I would not have any idea how to do so. If have even been thinking of putting all the guarded fields in some other object, which has just the network number and the guarded fields, and no other information. by querying the database one would get the normal output and an extra object with the network number and all its guarded values. In this extra object, no blocks would be allowed ... -Marten PS CCed to routing and db-wg, because this may be a solution.

1 0

Re: Unique NIC/RIPE/xxx-Handles
by Duncan Rogerson 27 Jul '93

27 Jul '93

> handle: XXXXYYY(a)ncc.ripe.net .. > etc.? Or, if that might confuse NIC handles with email addresses, > replacing the @ with another character? I think having something that looks like an e-mail address is a bad idea, it's too confusing. Given that one of the aims of handles is (I think !) a more compact, shorthand form of referring to someone, the RIPE-DR222 idea sounds better to me - DR222(a)rs.internic.net is longer than my real name ! Dunc

1 0

Re: Unique NIC/RIPE/xxx-Handles
by Wilfried Woeber, UniVie/ACOnet 27 Jul '93

27 Jul '93

| * Given that one of the aims of handles is (I think !) a more | * compact, shorthand form of referring to someone, the RIPE-DR222 | * idea sounds better to me - DR222(a)rs.internic.net is longer than | * my real name ! | |I have to agree here. I think a nice syntax would be: | |<NIC>-XXXYYY | |where it is probably is too much hastle to ask InterNIC to redo all their |nic-hdls to have INTERNIC-XXXYYY, so they probably keep the handles without |the NIC. The others could be: | |RIPE-MT2 |APNIC-MT2 |... My original reasoning was something like: Keep the InterNIC-Handles as they are, ie. when there is no NIC-ID, then let's assume it is InterNIC. For the others, tag them. For the DataBase, store everything without a (external) tag with an (internal) InterNIC tag. Also, I think it is really not necessary - maybe not even useful? - for people to obtain more than one handle. However if someone is hit by that, or even wants it :-), we could probably live (DataBase-wise) with a definition of (REQUIRED, MULTIPLE, UNIQUE). (Marten: could the DB-SW digest this?) |Question is, to what level do we go down for the NIC ? Should we go down to | |DENIC-MT2 |JANET-MT2 | |I don;t think so. My sense of NIC for the handles should be the highest level |IP number authorities in the area .... (ie continents) I think the question is, by whom and where these handles are dished out. My personal preference is to have this done at the highest possible level, ie. RIPE-NCC, APNIC, etc... Unfortunately, until now there have not been any contributions to this aspects. Regards, Wilfried.

2 1

Re: Unique NIC/RIPE/xxx-Handles
by Duncan Rogerson 27 Jul '93

27 Jul '93

> Please remember that there are more than 2 NIC's handing out handles > and there will likely be more in the future. JPNIC (nic.ad.jp) > currently does so, as will (I suspect) the APNIC. Granted, it is So it makes sense to have a single handle: field and have the assigning agency identified by a prefix on the handle ? Dunc

2 1

Re: Unique NIC/RIPE/xxx-Handles
by Duncan Rogerson 26 Jul '93

26 Jul '93

> One of the ideas we talked about was to go to a structure like > > NIC-XY999 (derived from the current NIC-Handles by prepending NIC-) > RIPE-XY999 (newly assigned within the RIPE community) So you end up with data like : person: Duncan Rogerson . . handle: NIC-DR222 handle: RIPE-DR001 (assuming multiple handle: fields are permitted, to cope with people who for one reason or another have both types of handle). or person: A Person . . handle: RIPE-AP001 .. in the database ? Or should the name of the field distinguish between RIPE and NIC handles - ie the person object can have two fields, nic-hdl: and ripe-hdl: to cope with people who end up with a handle of each type. Dunc

2 1

Unique NIC/RIPE/xxx-Handles
by Wilfried Woeber, UniVie/ACOnet 23 Jul '93

23 Jul '93

Dear DB-folks, during the IETF we (Daniel K, Ruediger V and me) had a short ad-hoc meeting and identified some aspects of the RIPE-DB business that should be addressed and discussed. One of them, and quite urgently needed is to agree on structure and procedures to obtain unique handles for people who do not (yet) have NIC handles. One of the ideas we talked about was to go to a structure like NIC-XY999 (derived from the current NIC-Handles by prepending NIC-) RIPE-XY999 (newly assigned within the RIPE community) Reudiger even thought about adding even more structure like RIPE-Provider_ID-XY999, or RIPE-XY999-Provider_specific... The issue here is whether we want to have the Provider_ID as part of the hierarchy tree. My personal preference is the RIPE-XY999[-optional-Provider_specific...] format, the handle being unique without the Provider part. Another question is where and how to register/assign these handles. One possibility could be to have this as a service from and at the NCC, say assigned by some script. A Different approach would be to assign them somehow at the Local-IRs. Could you please comment on these? I'd like to have some form of consensus ready for approval at the next RIPE meeting. Best regards, Wilfried.

1 0

Re: EU.net and eu.net database entries
by RIPE NCC Staff 23 Jul '93

23 Jul '93

Piet.Beertema(a)mcsun.EU.net writes: * A day or so ago I submitted a new entry for the EU.net domain, * meant to be a change on the current entry. However, I denoted * it as "EU.net" (which is the official name) instead of eu.net. * Now it appears that the updating software saw this as a *new* * entry rather than an update, in other words it doesn't work * case-independent. On the other hand the database query s/w * does work case-independent, so "whois eu.net" now gives me * two entries... * Could you remove the old eu.net entry? I dare not submit a * change for it to get it deleted, in case the updating s/w * decides to start working case-independent in that case... Sorry Piet, old, old, old software ... The new software will take care of this, but I think the new software will change everything to lowercase. I have not written this part yet, have to put some thought in it though. Anyone in the database working group has any feeling how these should be dealt with ? From a programming point of view, handling everything lowercase is much easier, I do not really want to check every single combination of lower/uppercase before I update something ... Then again, after some thinking (I usually type faster than I think ;-) the indexing is done in lowercase, and key lookups are always normalized to lowercase before a lookup. So the real question is, should entries in the database be left untouched when it comes to upper/lowercase, or should all be normalized ? -Marten

2 1

Re: EU.net and eu.net database entries
by craig＠icm1.icp.net 23 Jul '93

23 Jul '93

> (I usually type faster than I think ;-) the indexing is done in lowercase, > and key lookups are always normalized to lowercase before a lookup. > > So the real question is, should entries in the database be left untouched > when it comes to upper/lowercase, or should all be normalized ? since all is normalized to lowercase before a lookup i think it is OK to have the database show things in capital letters as long as everyone knows all is treated as lowercase. summary: o view as is stored in the database o normalize before performing other operations on the database. craig

1 0