- db-wg - mailman.ripe.net

Novel NetMail users
by Denis Walker 10 Nov '03

10 Nov '03

Dear Colleagues, In the process of testing mail clients for s/mime compatibility I am trying to install Novell NetMail on our linux test box running RedHat 8.0. I have no previous knowledge at all about this product. I have tried several times to install it and can never get past a window asking for the Administrator user name and password. I have included the log of what I did below. Any help from users of this mail client would be very much appreciated. Regards Denis Walker RIPE NCC Software Engineering Department. [root@linux setup]# ./nds-install %% Welcome to the installation of Novell eDirectory 8.7.0 %% The Novell eDirectory (8.7.0) for Linux End User License Agreement will now be displayed. %% Please read the agreement carefully before accepting the terms. %% Press ENTER to continue. %% Do you accept the terms of the Novell eDirectory (8.7.0) license agreement '[y/n/q] ? 'y %% List of Novell eDirectory (8.7.0) components available to install %% 1 Novell eDirectory Server %% 2 Novell eDirectory Administration Utilities %% 3 Management Console for Novell eDirectory (ConsoleOne) %% Select the components you wish to install [?, q] : 1,2,3 %% Enter the path to License File (.nfk): /var %% License file Copied. %% Adding packages... Preparing... ########################################### [100%] 1:NDSmasv ########################################### [100%] Preparing... ########################################### [100%] 1:NDSbase ########################################### [100%] Preparing... ########################################### [100%] 1:NLDAPsdk ########################################### [100%] Preparing... ########################################### [100%] 1:NLDAPbase ########################################### [100%] Preparing... ########################################### [100%] 1:NDScommon ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLpkis ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLpkia ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLpkit ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLsas ########################################### [100%] Preparing... ########################################### [100%] 1:ntls ########################################### [100%] Preparing... ########################################### [100%] 1:NDSserv ########################################### [100%] Preparing... ########################################### [100%] 1:NDSrepair ########################################### [100%] Preparing... ########################################### [100%] 1:NDSimon ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLsnmp ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLsubag ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLnmas ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLembox ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLlmgnt ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLstlog ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLxis ########################################### [100%] Preparing... ########################################### [100%] 1:NOVLice ########################################### [100%] Preparing... ########################################### [100%] 1:NDSdxevnt ########################################### [100%] %% Installing ConsoleOne.... The following is a list of languages that are available to install. 1 English 2 French 3 All Select the languages you wish to install [?,q]: 1 The following are all the available snapins you can choose to install 0 NONE 1 ICE Snapin 2 Index Manager Snapin 3 LDAP Snapin 4 SLP Snapin 5 WAN Manager Snapin 6 PKI Snapin 7 Filtered Replica Snapin 8 All Select the snapin(s) you wish to install [?,q]: 8 Do you wish to install Java Runtime Environment [y,n,q] ? y OpenSLP rpm " openslp-1.0.11-0.fdr.6.rh80 " is already installed. NDSslp will not be installed. %% Adding package IBMJava2-JRE ... Preparing... ########################################### [100%] 1:IBMJava2-JRE ########################################### [100%] %% NDSbase package is already installed. %% NDScommon package is already installed. %% NLDAPsdk package is already installed. %% NLDAPbase package is already installed. %% NOVLxis package is already installed. %% NOVLlmgnt package is already installed. %% NOVLice package is already installed. %% NOVLsas package is already installed. %% NOVLpkia package is already installed. %% NOVLpkis package is already installed. %% Adding package NOVLc1 ... error: Failed dependencies: NDSslp is needed by NOVLc1-1.3.4-1 %% ERROR: Failed to add NOVLc1 (NOVLc1) package. %% Installation of packages failed, not all packages were installed. ucd-snmp package is not installed on your system. Please ensure that you install this package before using any SNMP related features of Novell eDirectory (8.7.0) . Please refer to the admin_guide.pdf for more details. %% Novell eDirectory Server packages successfully installed. %% Novell eDirectory Administration Utilities packages successfully installed. %% Use "ndsconfig" to configure Novell eDirectory Server. %% Please update following environment variables to use LDAP tools from Novell - PATH=/usr/ldaptools/bin:$PATH MANPATH=/usr/ldaptools/man:$MANPATH %% Please go through ../readme.txt carefully before using the product. [root@linux setup]# [root@linux setup]# rpm -i /home/test-receiver/novel/Linux/ConsoleOne/NDSslp-8. 7.0-1.i386.rpm Starting NDS SLP services... Done [root@linux setup]# ./nds-install %% Welcome to the installation of Novell eDirectory 8.7.0 %% The Novell eDirectory (8.7.0) for Linux End User License Agreement will now be displayed. %% Please read the agreement carefully before accepting the terms. %% Press ENTER to continue. %% Do you accept the terms of the Novell eDirectory (8.7.0) license agreement '[y/n/q] ? 'y %% List of Novell eDirectory (8.7.0) components available to install %% 1 Novell eDirectory Server %% 2 Novell eDirectory Administration Utilities %% 3 Management Console for Novell eDirectory (ConsoleOne) %% Select the components you wish to install [?, q] : 1,2,3 %% Enter the path to License File (.nfk): /var %% License file Copied. %% Adding packages... NDSmasv is already installed NDSbase is already installed NLDAPsdk is already installed NLDAPbase is already installed NDScommon is already installed NOVLpkis is already installed NOVLpkia is already installed NOVLpkit is already installed NOVLsas is already installed ntls is already installed NDSserv is already installed NDSrepair is already installed NDSimon is already installed NOVLsnmp is already installed NOVLsubag is already installed NOVLnmas is already installed NOVLembox is already installed NOVLlmgnt is already installed NOVLstlog is already installed NOVLxis is already installed NOVLice is already installed NDSdxevnt is already installed %% Installing ConsoleOne.... The following is a list of languages that are available to install. 1 English 2 French 3 All Select the languages you wish to install [?,q]: 1 The following are all the available snapins you can choose to install 0 NONE 1 ICE Snapin 2 Index Manager Snapin 3 LDAP Snapin 4 SLP Snapin 5 WAN Manager Snapin 6 PKI Snapin 7 Filtered Replica Snapin 8 All Select the snapin(s) you wish to install [?,q]: 8 OpenSLP rpm " openslp-1.0.11-0.fdr.6.rh80 " is already installed. NDSslp will not be installed. %% NDSbase package is already installed. %% NDScommon package is already installed. %% NLDAPsdk package is already installed. %% NLDAPbase package is already installed. %% NOVLxis package is already installed. %% NOVLlmgnt package is already installed. %% NOVLice package is already installed. %% NOVLsas package is already installed. %% NOVLpkia package is already installed. %% NOVLpkis package is already installed. %% Adding package NOVLc1 ... Preparing... ########################################### [100%] 1:NOVLc1 ########################################### [100%] %% Adding package NDSsice ... Preparing... ########################################### [100%] 1:NDSsice ########################################### [100%] %% Adding package NDSsimgr ... Preparing... ########################################### [100%] 1:NDSsimgr ########################################### [100%] %% Adding package NDSsldap ... Preparing... ########################################### [100%] 1:NDSsldap ########################################### [100%] %% Adding package NDSsslp ... Preparing... ########################################### [100%] 1:NDSsslp ########################################### [100%] %% Adding package NDSswan ... Preparing... ########################################### [100%] 1:NDSswan ########################################### [100%] %% Adding package NDSspki ... Preparing... ########################################### [100%] 1:NDSspki ########################################### [100%] %% Adding package NDSsfrep ... Preparing... ########################################### [100%] 1:NDSsfrep ########################################### [100%] %% ConsoleOne Successfully Installed. %% Execute /usr/ConsoleOne/bin/ConsoleOne to run ConsoleOne %% Snapins Successfully Installed. ucd-snmp package is not installed on your system. Please ensure that you install this package before using any SNMP related features of Novell eDirectory (8.7.0) . Please refer to the admin_guide.pdf for more details. %% Novell eDirectory Server packages successfully installed. %% Novell eDirectory Administration Utilities packages successfully installed. %% Use "ndsconfig" to configure Novell eDirectory Server. %% Please update following environment variables to use LDAP tools from Novell - PATH=/usr/ldaptools/bin:$PATH MANPATH=/usr/ldaptools/man:$MANPATH %% Please go through ../readme.txt carefully before using the product. [root@linux setup]# ndsconfig new -t DW_TREE -o 80 -O 443 -a admin.DW Enter the password for admin.DW: Re-enter the password for admin.DW: Enter server context[org]:dw Starting the service 'ndsd'... Done. Configuring eDirectory with following parameters Admin name = admin.DW Tree name = DW_TREE Server Context = dw dibdir path = /var/nds/dib Searching for Duplicate Tree Name in the network. Please wait... Installing Novell eDirectory Server ... Novell eDirectory Server successfully installed on this system. Extending schema... For more details view schema extension logfile: /var/nds/schema.log Schema extended successfully. Configuring SAS service ... Successfully configured SAS service Nov 10 16:56:22 Could not set the preferred server LINUX Configuring LDAP Server with default SSL CertificateDNS certificate Done Restarting ndsd to load the tree key Stopping the service 'ndsd'... Done. Starting the service 'ndsd'... Done. [root@linux setup]# ps -ef | grep ndsd root 27255 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27257 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27258 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27259 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27260 1 9 16:53 ? 00:00:30 /usr/sbin/ndsd root 27261 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27262 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27263 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27264 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27265 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27266 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27267 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27268 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27269 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27270 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27272 1 10 16:53 ? 00:00:32 /usr/sbin/ndsd root 27273 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27275 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27277 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27278 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27279 1 0 16:53 ? 00:00:00 /usr/sbin/ndsd root 27314 1 0 16:54 ? 00:00:00 /usr/sbin/ndsd root 27315 1 0 16:54 ? 00:00:00 /usr/sbin/ndsd root 27430 7667 0 16:58 pts/0 00:00:00 grep ndsd [root@linux novel]# ./pinstall.lin To accept this license agreement, please enter 'Y': y Pervasive not found. Installing it now! Pervasive SQL server 2000 installed. Now installing NetMail 3.1. Please wait while nimsext loads Nov 10 17:04:39 Could not set the preferred server LINUX At this point it asks me to: ************************************************************** Login as the administrator Administrator name: Password: ************************************************************** I enter the user name admin.DW and password that I thought I had set up with the ndsconfig and I get ************************************************************** Login failed, try again? -Yes No ************************************************************** I do not have any other user name and password for an administrator. I tried entering the root password for the linux system and that did not work either. If I select No then it goes into a loop as below and I have to kill it. Assigning Pervasive rights Your installation is now complete. Thank you for using NetMail 3.1! The NetMail team. Starting NetMail Starting NetMail: [root@linux novel]# Nov 10 17:12:56 Could not set the preferred server LINUX DDB: Logged in with 'Public' identity. Functionality may be limited. (This message is OK if the schema has not been extended yet) [root@linux novel]# No agents configured Module rBåÿ¿sZBrB¬åÿ¿Äq(@Pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ died. Restarting. Starting: rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ Load Error: No such file or directory Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ @ did not load Module rbåÿ¿szbrb¬åÿ¿Äq(@pæÿ¿ýÿÿÌåÿ¿"q'@ýÿÿÜåÿ¿oq'@lÞ @ýÿÿ æÿ¿oq'@lÞ [test-receiver@linux init.d]$ ps -ef | grep ims root 27799 1 0 17:13 ? 00:00:00 /usr/local/nims/bin/ims kill -9 27799

1 0

Should the "e-mail" attribute be mandatory for the "person" object?
by Thor Kottelin 07 Nov '03

07 Nov '03

Folks, Email is the preferred communication medium when troubleshooting internetworking problems. Time and time again, "inetnum" objects with no valid email address cause grief. In the absence of relevant "e-mail" attributes, desperate administrators sometimes send mail to addresses found in "changed" and "notify" attributes. Sometimes the only option left is resorting to telephone calls, regardless of the expenses, time differences and language barriers often involved. I would therefore like to suggest making the "e-mail" attribute mandatory for the "person" object. If this isn't acceptable, then maybe at least one of the "person" or "role" objects referred to by an "inetnum" object should carry an "e-mail" attribute. Additionally, in order to enhance address validity, I would like to suggest performing some kind of validation on these "e-mail" attribute values - perhaps simple syntax checking, or maybe even full round-trip SMTP testing, or something in between. Your comments, please. Thor -- http://thorweb.anta.net/

5 7

Maintenance on RIPE Whois Server, 10 November 2003
by DB-News 07 Nov '03

07 Nov '03

Dear Colleagues, [apologies for duplicate messages] Next Monday, 10 November 2003, we need to perform a maintenance work on the RIPE Whois Server to replace a faulty piece of hardware. During the maintenance work, - Whois Database updates will be stopped, - all update mails to <auto-dbm(a)ripe.net> will be queued to be processed later, - Webupdate and syncupdate interfaces will be unavailable, - The whois queries will _not_ be interrupted. The maintenance work will start at 12:00 UTC (13:00 Amsterdam time) on 10 November 2003 and expected to last 2 to 3 hours. We apologise for the convenience caused. Please do not hesitate to contact <ripe-dbm(a)ripe.net> for any questions. Best regards, -- Engin Gunduz RIPE NCC

1 0

RE: [db-wg] Should the "e-mail" attribute be mandatory for the "p erson" object?
by Titley, Nigel 03 Nov '03

03 Nov '03

Thor Kottelin wrote: > Folks, > > Email is the preferred communication medium when troubleshooting > internetworking problems. Time and time again, "inetnum" > objects with no > valid email address cause grief. In the absence of relevant "e-mail" > attributes, desperate administrators sometimes send mail to > addresses found > in "changed" and "notify" attributes. Sometimes the only > option left is > resorting to telephone calls, regardless of the expenses, > time differences > and language barriers often involved. The argument against making the email attribute mandatory has always been the bootstrapping problem... In the olden days (defined by my children as "when Daddy was young") it was genuinely possible for a person in the RIPE database to not actually have an email address during the setting up phase of a LIR. I would however agree with Thor, that this circumstance no longer exists. Anyone can get a temporary email address, hotmail via the local cybercafe, if nothing else, to tide them over the bootstrapping period. > > I would therefore like to suggest making the "e-mail" > attribute mandatory > for the "person" object. If this isn't acceptable, then maybe > at least one > of the "person" or "role" objects referred to by an "inetnum" > object should > carry an "e-mail" attribute. Additionally, in order to enhance address > validity, I would like to suggest performing some kind of > validation on > these "e-mail" attribute values - perhaps simple syntax > checking, or maybe > even full round-trip SMTP testing, or something in between. > > Your comments, please. > > Thor ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. **********************************************************************

1 0

Change of Country entries in the database
by Christoph Mohr 23 Oct '03

23 Oct '03

Dear colleagues of the RIPE NCC database group! I'm using the RIPE whois database in its bulk version ripe.db.inetnum for statistical uses while evaluating the netflow data of our border routers. What I'm much interested in is the origin of an IP address which I get by the country entry of the respective inetnum block of the database. Therefore, I'm always a bit confused about the many addresses which are located in the Netherlands. Since I prefer large inetnum blocks for reasons of performance of my software, I often use entries of many C blocks which are registered for the RIPE NCC with the country entry NL. In the meantime, I already corrected the country entries of some inetnums in my own local copy of the database but this is just a workaround which isn't really satisfying. So I would like to suggest the change of the country entry of - at least - the following inetnum blocks (only inetnum, netname and country entries): inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK country: NL proposed country: EU # Country is really world wide inetnum: 10.0.0.0 - 10.255.255.255 netname: IANA-ABLK-RESERVED1 country: NL proposed country: EU # Country is really world wide inetnum: 145.224.0.0 - 145.254.255.255 netname: RIPE-NCC-145 country: NL proposed country: EU # Country is really world wide inetnum: 145.0.0.0 - 145.127.255.255 netname: RIPE-NL country: NL proposed country: EU inetnum: 147.233.0.0 - 147.237.255.255 netname: RIPE-ISRAELB-NET country: NL proposed country: EU [or IL] inetnum: 149.132.0.0 - 149.134.255.255 netname: RIPE-149-BLK country: NL proposed country: EU inetnum: 149.202.0.0 - 149.204.255.255 netname: RIPE-149-202-BLK country: NL proposed country: EU inetnum: 149.221.0.0 - 149.250.255.255 netname: EU-ZZ-990225 country: NL proposed country: DE inetnum: 149.206.0.0 - 149.251.255.255 netname: RIPE-149-206-BLK country: NL proposed country: EU inetnum: 163.156.0.0 - 163.175.255.255 netname: NETBLK-RIPE-B country: NL proposed country: EU inetnum: 164.128.0.0 - 164.143.255.255 netname: NETBLK-RIPE-B-128 country: NL proposed country: EU inetnum: 164.0.0.0 - 164.40.255.255 netname: RIPE-164-BLK country: NL proposed country: EU inetnum: 172.16.0.0 - 172.31.255.255 netname: IANA-BBLK-RESERVED1 country: NL proposed country: EU # Country is really world wide inetnum: 192.168.0.0 - 192.168.255.255 netname: IANA-CBLK-RESERVED1 country: NL proposed country: EU # Country is really world wide With the entry 'EU # Country is really world wide' I'm referring to an invention of the RIPE NCC due to the ERX project. You created in 2003 the following inetnums: inetnum: 141.0.0.0 - 141.255.255.255 netname: EU-ZZ-141 country: EU # Country is really world wide inetnum: 151.0.0.0 - 151.255.255.255 netname: EU-ZZ-151 country: EU # Country is really world wide inetnum: 188.0.0.0 - 188.255.255.255 netname: EU-ZZ-188 country: EU # Country is really world wide Better would be nevertheless the creation of let's say 'ZZ' or 'WW' for worldwide use, but if you put in exactly 'EU # Country is really world wide', this will be easily been parsed by Perl. I think that this is a good solution, since it doesn't make sense to put in NL for the whole IPv4 address space for example or for let's say RIPE-ISRAELB-NET. The fact that anybody in the Netherlands has to deal with the related range is clearly reflected by the contact persons or roles which is CREW-RIPE or something like that and which is situated in NL. I'm looking forward to hear your opinion. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----

11 16

Prototype release of RPSLng IRRToolSet
by Katie Petrusha 23 Oct '03

23 Oct '03

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC is pleased to announce version 4.8.1 prototype release of IRRToolSet. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used on the Internet. The prototype of IRRToolSet implements the Internet Draft Document draft-blunk-rpslng-01 (http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt). The prototype release contains peval, rpslcheck and RtConfig that already work with a new dictionary (you can also try the Web prototype for peval and RtConfig). Currently work is in progess to make other tools RPSLng compatible. More details can be found at: http://www.ripe.net/db/irrtoolset Please contact irrtoolset(a)ripe.net for any comments. -- Best regards, Katie Petrusha RIPE NCC

1 0

Re: [db-wg] Change of Country entries in the database
by Wilfried Woeber, UniVie/ACOnet 23 Oct '03

23 Oct '03

Leo, >Hank Nussbacher <hank(a)att.net.il> wrote: > >[...] > >>I wouldn't make it optional > >What is the benefit of having it as a mandatory attribute? > >Regards, I can't see any at first glance (rather stuff being optional tends to get omitted anyway :-) > >-- >leo vegoda >RIPE NCC >Registration Services Manager My admin question would be: is there any internal machinery @ the NCC which assumes the presence (and "correctness") of that attribute? Wilfried.

1 0

Re: [db-wg] Change of Country entries in the database
by Hank Nussbacher 10 Oct '03

10 Oct '03

At 11:26 AM 09-10-03 +0200, Peter Koch wrote: >Hank Nussbacher wrote: > > > PS I think the country code should 00 for whole world since as countries > > split - who knows if ZZ or any two letters will be used in the future. > >ZZ is fine. ISO 3166-1 has reserved code points for exactly this purpose. >See >http://www.iso.ch/iso/en/prods-services/iso3166ma/10faq/frequently-asked-qu… Ya learn something new every day. Thanks, -Hank >"EU" is not on this list, but it's on a - meanwhile non-public - separate list >and will not be assigned. Different topic :-) > >-Peter

4 3

Fw: FAILED:
by benhadjira 06 Oct '03

06 Oct '03

Dear sir We have tried several times to add inetnum to the data-base, but unfortunetely this is the error message we received every time . Could you please give us some help & advices on how to do it ? Thanking you in advance Mourad Techni-communication -------Original Message------- From: ripe-dbm(a)ripe.net Date: samedi 4 octobre 2003 10:34:28 To: benhadjira(a)techni-communication.com Subject: FAILED: > From: benhadjira(a)techni-communication.com > Subject: > Date: Sat, 04 Oct 2003 05:34:19 -0400 > Reply-To: benhadjira(a)techni-communication.com > Message-ID: <04df532f66b14c6c874ce4e412db3b3d(a)techni-communication.com> SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 1 Modify: 0 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Create FAILED: [inetnum] 217.29.219.0 - 217.29.219.255 ***Error: Authorisation failed ***Info: Syntax check passed inetnum: 217.29.219.0 - 217.29.219.255 netname: Techni-communication descr: Techni-Communication - customer SEI.NET country: DZ admin-c: MA1973-ripe tech-c: BM1974-RIPE status: LIR-PARTITIONED PA mnt-by: BM-MNT mnt-lower: BM-MNT mnt-routes: TACHYON-EU-MNT changed: benhadjira(a)techni-communication.com 20031004 source: RIPE ***Info: Authorisation for parent [inetnum] 217.29.208.0 - 217.29.223.255 using mnt-lower: not authenticated by: BM-MNT ***Info: Authorisation for [inetnum] 217.29.219.0 - 217.29.219.255 using mnt-by: not authenticated by: BM-MNT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following paragraph(s) do not look like objects and were NOT PROCESSED: -------------------------------------------------------------------- mail2web.com - Check your email from the web at http://mail2web.com. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net> .

2 1

Reverse DNS Restructuring Project
by Olaf M. Kolkman 01 Oct '03

01 Oct '03

Dear Colleagues, I have just posted a proposal about the restructuring of the reverse DNS setup to the ncc-services-wg mailing list. I'd like to point out that this proposal has relevance to both the dns-wg and db-wg. You can find the proposal on http://www.ripe.net/reverse/proposal.html Please provide your feedback on the ncc-services-wg mailing list. With excuses for the cross-post, -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

1 0

Looking for good way to find blocks allocated directly by ripe
by william＠elan.net 27 Sep '03

27 Sep '03

Hi, I'd like to find what is the best way to determine if particular inetnum was allocated directly by RIPE, this would include all blocks allocated to LIRs, all blocks allocated to large organizations and blocks allocated as small PI blocks. Currently I have come with the following way to do it - first find all inetnum objects listed as "ALLOCATED PI" with network name starting as "EU-ZZ", this find all PI space; then discard all "ASSIGNED PA" blocks except those within range of previously found "ALLOCATED PI" blocks and also discard "ALLOCATED PI" and "LIR-PARTITIONED PA" blocks. >From reminder the netblocks totally within another inetnum are discarded as well as "superblocks" listed under RIPE name. I'd like to find if you think doing it this way would leave any blocks out or include too many larger block then direct RIPE allocations. Doing it the way I described above, already produced some data available at http://www.completewhois.com/bogons/data/allocated-cidr-ripe_main.txt and non-allocated space is at http://www.completewhois.com/bogons/data/bogons-cidr-ripe_main.txt I'd like to verify validity of this data and the process I used, especially considering that I see number of errors, for example there are several blocks > /24 listed as allocated (but I did not think RIPE did any direct allocations or assignemsns of size > /24), for example: 193.58.0.64/26 193.164.232.192/26 193.201.147.0/26 193.201.148.64/26 193.243.183.0/26 193.254.0.64/26 194.1.127.128/26 194.9.166.0/26 194.149.71.128/26 194.153.156.0/26 194.180.159.128/26 194.180.226.192/26 194.246.39.0/26 194.246.39.128/26 195.35.104.64/26 -- William Leibzon Elan Networks william(a)elan.net

3 3

Organisation Object Proposal, version 3
by DB-News 22 Sep '03

22 Sep '03

Dear Colleagues, [apologies for duplicate messages] After the discussions we had in the RIPE 46 Meeting and in the WG mailing lists, we have incorporated agreed modifications into organisation object proposal, which you can find below. This is the Version 3 of the proposal. You can find the first version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html the second version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html and a summary of discussions on the second version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00213.html Thank you very much for your input on the issue. Best regards, -- Engin Gunduz RIPE NCC Database Group ============================================================ An organisation object in the RIPE Database -------------------------------------------- 1. Motivation ------------------- Currently the RIPE Database stores two main types of contact information: person and role objects. The person and role objects provide a way to contact people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, autonomous systems, and domain names). However, none of these provide an easy way of mapping resources to a particular organisation. A user must first find an object containing contact information for that organisation. Then, assuming all of the organisation's objects refer to this contact information, the user must perform an inverse query to obtain a list of objects referencing the specified person or role. This indirect process can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation is seen as a useful addition to the RIPE Database. This document is a proposal for an organisation object in the RIPE Database and the necessary database functionality. 2. The organisation object ----------------------- The organisation object provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the RIPE Database. The organisation object is identified by a unique ID specified in the "organisation:" attribute which is the primary key. An organisation object can be referenced from other objects using an "org:" attribute. All objects associated with a particular organisation ID can be retrieved by performing an "inverse query" for this ID used in the "org:" attribute of database objects. Following is a template for the proposed organisation object and an example. All attributes except the "ref-nfy:", "mnt-ref:", "organisation:", "org-name:", "org-type:" and "org:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 3. New attributes ---------------------- "organisation:" Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example: ORG-RT34-RIPE Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part. Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object. The organisation ID cannot be reused. If an organisation ID was used in the past by an organisation object and then deleted, this ID cannot be used in new organisation objects. The auto-generation of organisation IDs and preventing reuse of them simplifies the external references. Note that when an organisation changes name, the "org-name:" can be modified accordingly. There is no need to change the organisation ID. "org-name:" Specifies the name of the organisation that this organisation object represents in the whois database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. "org-type:" Specifies the type of the organisation. The possible values are 'IANA' for Internet Assigned Numbers Authority, 'RIR' for Regional Internet Registries, 'NIR' for National Internet Registries, 'LIR' for Local Internet Registries, and 'NON-REGISTRY' for all other organisations. "ref-nfy:" Specifies the e-mail address to be notified when a reference to the organisation object is added or removed. An e-mail address as defined in RFC 2822. "mnt-ref:" Specifies the maintainer objects that are entitled to add references to the organisation object from other objects. "country:" Specifies the two-letter ISO3166 country code of the country where this organisation resides. "address:" Specifies the address of the organisation. This is a free-text attribute. "org:" May be included in any object type. It points to an existing organisation object representing the entity that holds the resource, in the cases where the whois DB object represents an Internet resource. In other objects, it can be used to specify the business relations. The value of this attribute is the ID of the organisation object. It is mandatory in the inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects. "org:" attribute is single-valued in the inetnum, inet6num and aut-num objects, and it is multi-valued all other objects. The "org:" attribute is used to specify the holder of a resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in them. In other objects, it specifies business relations (like in a person object, where it can be used to specify whom the person works for) it can be multiple (in the person object example, a person might work for several companies). 4. Authorisation checks ---------------------------------- When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object. When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks: - from one of the maintainers in the "mnt-ref:" attributes of the organisation object - from one of the maintainers in the "mnt-by:" attributes of the object being updated 5. Query changes ---------------- If a whois query returns an object with an "org:" attribute, the organisation object mentioned in this attribute is also appended to the query results. This behaviour can be disabled by using the '-r' flag in the query. 6. Examples ------------ A basic organisation object: organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE notify: ripe-mailbox(a)example-org.net ref-nfy: ripe-mailbox(a)example-org.net mnt-ref: EXAMPLE-MNT mnt-by: EXAMPLE-MNT changed: someguy(a)example-org.net 20030121 source: RIPE A network that references an organisation object: inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE status: ALLOCATED-BY-RIR PORTABLE mnt-by: EXAMPLE-MNT mnt-lower: EXAMPLE-MNT changed: someguy(a)example-org.net 20030122 source: RIPE A query for this inetnum object: % whois 192.168.86.251 inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE person: John Example nic-hdl: JE1-RIPE [...] source: RIPE person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE

1 0

Re: AW: [local-ir@ripe.net]Proposed change of "mnt-lower:" behaviour: procedure and timelines
by Katie Petrusha 18 Sep '03

18 Sep '03

On Thu, Sep 18, 2003 at 01:36:16PM +0200, Bornhorst, Ludger wrote: Dear Ludger, > > To solve this problem, allocation objects have to be modified to include a > > "mnt-lower" attribute. We have applied certain heuristics to determine the most > > suitable maintainer for an allocation. If there is no maintainer, a new > > maintainer will be generated. > > in the case of PA allocations I agree with you, to include a "mnt-lower" > attribute to all PA allocation objects. > > But what about PI Allocations? In order to create an appropriate route object > for PI addresses, it is necessary to update (not create!) the ASSIGNED PI- > inetnum with a mnt-routes attribute etc. to get through the authorization > for the route object creation. The proposed change in the behaviour won't affect the updates of the existing objects. It affects only the _creation_ of more-specific inetnums (inet6nums, domains). > Is it guaranteed, that we can perform ASSIGNED PI-inetnum updates in the future? Yes, as long as the update is authorised by "mnt-by:" of the object itself. Hopefully this answers your question. > > regards > Lu > > Ludger Bornhorst > ______________________________________________________________________ > > Deutsche Telekom AG > T-Com Headquarters > Network Information Center > Ammerlander Heerstr. 138, D-26129 Oldenburg Hotline > +49 441 234 4581 (phone) +49 800 3301180 > +49 441 234 4589 (fax) +49 800 3301179 > ludger.bornhorst(a)telekom.de (mail) dk.call-center(a)telekom.de > -- Katie Petrusha Database Group RIPE NCC

1 0

Proposed change of "mnt-lower:" behaviour: procedure and timelines
by Katie Petrusha 18 Sep '03

18 Sep '03

[Apologies for duplicate messages] Dear colleagues, In March 2003, the RIPE NCC circulated the proposal to change the behaviour of the "mnt-lower:" attribute in inetnum, inet6num and domain objects. Currently, if the "mnt-lower" attribute of a parent object is absent, anybody can create more-specific objects. The goal is to change this behaviour to a more secure Routing Policy System Security (RPSS) style scheme. In RPSS, objects use "mnt-lower:" to specify a maintainer which has the ability to authorise the creation of more-specific objects. If a "mnt-lower:" attribute is not present, then the "mnt-by:" of the less-specific object is used. A similar scheme is already used for route object creation ("mnt-routes:" attribute). As inetnum objects representing allocations are maintained by the RIPE NCC, deployment of this scheme may not allow LIRs to create assignments from their allocation if the LIR does not have a "mnt-lower:" attribute pointing to the LIR's maintainer. To solve this problem, allocation objects have to be modified to include a "mnt-lower" attribute. We have applied certain heuristics to determine the most suitable maintainer for an allocation. If there is no maintainer, a new maintainer will be generated. Details about project assumptions and heuristics were presented at RIPE 46: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-allocatio… The initial proposal was sent in March 2003: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00033.html The RIPE NCC suggests the following implementation plan: Step 1. Distribute this plan for approval. Time: 2 weeks Step 2. Notify contacts whose allocations need to be modified Wait for feedback and people making updates themselves Time: 1 month Step 3. RIPE NCC will check all affected allocations again and update the ones still requiring modification, generating necessary maintainers and notifying contacts. Time: 1 day Step 4. Passwords for generated maintainers made available through the LIR Portal. Wrong modifications can be corrected through the LIR Portal as well. Time: 1 day Step 5. Deploy the change in the RIPE Whois Database Software to support new scheme. Time: to be announced Any suggestions or comments on this plan are welcome. If your allocation doesn't have a "mnt-lower:" attribute, we encourage you to update it as soon as possible through the LIR portal. If you don't have a "mnt-lower:" after this proposal has been implemented, you won't be able to create any new assignments for your allocations. We believe that this change will be beneficial for all RIPE Whois Database users and we hope the migration will go as smoothly as possible. Thanks for your co-operation. Katie Petrusha Database Group RIPE NCC

1 0

Re: SUCCESS: Bulk deletion of /24 detail
by Niall O'Reilly 15 Sep '03

15 Sep '03

[Input to DB-WG] Flagging this result as 'SUCCESS' is unhelpful. I regard this as a bug, and a silly one too. [Question to ripe-dbm] So how am I supposed to delete redundant objects and keep the DB clean ? Best Niall O'Reilly On Friday, Sep 12, 2003, at 08:26 Europe/Dublin, ripe-dbm(a)ripe.net wrote: > > >> From: "Niall O'Reilly" <Niall.oReilly(a)ucd.ie> >> Subject: Bulk deletion of /24 detail >> Date: Fri, 12 Sep 2003 08:26:41 +0100 >> Reply-To: Niall.oReilly(a)ucd.ie >> Message-ID: <7484C0E0-E4F2-11D7-A9BD-000393DA759C(a)ucd.ie> > > > SUMMARY OF UPDATE: > > Number of objects found: 0 > Number of objects processed successfully: 0 > Create: 0 > Modify: 0 > Delete: 0 > No Operation: 0 > Number of objects processed with errors: 0 > Create: 0 > Modify: 0 > Delete: 0 > Syntax Errors: 0 > > > DETAILED EXPLANATION: > > > ***Warning: Invalid keyword(s) found: Bulk, deletion, of, /24, detail > ***Warning: All keywords were ignored > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following paragraph(s) do not look like objects > and were NOT PROCESSED: > > inetnum: 193.1.128.0 - 193.1.128.255 > netname: UCD-193-1-128-19-128 > delete: aggregated into UCD-193-1-128-19 > > inetnum: 193.1.129.0 - 193.1.129.255 > netname: UCD-193-1-128-19-129 > delete: aggregated into UCD-193-1-128-19 > > inetnum: 193.1.130.0 - 193.1.130.255 > netname: UCD-193-1-128-19-130 > delete: aggregated into UCD-193-1-128-19 > > inetnum: 193.1.131.0 - 193.1.131.255 > netname: UCD-193-1-128-19-131 > delete: aggregated into UCD-193-1-128-19 > > inetnum: 193.1.133.0 - 193.1.133.255 > netname: UCD-193-1-128-19-133 > delete: aggregated into UCD-193-1-128-19 > > inetnum: 193.1.137.0 - 193.1.137.255 > netname: UCD-OLDBAR-LHS > delete: aggregated into UCD-193-1-128-19 > > inetnum: 193.1.138.0 - 193.1.138.255 > netname: UCD-OLDBAR-RHS > delete: aggregated into UCD-193-1-128-19 > > inetnum: 193.1.139.0 - 193.1.139.255 > netname: UCD-MICROSTORE > delete: aggregated into UCD-193-1-128-19 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For assistance or clarification please contact: > RIPE Database Administration <ripe-dbm(a)ripe.net> > >

4 6

Minutes for the RIPE 46 meeting Database Working Group Sessions
by Can Bican 12 Sep '03

12 Sep '03

Dear Colleagues, Here are the minutes for the two sessions of the Database Working Group in RIPE 46. Please let me know if they need additions or corrections. Best Regards, -- Can Bican DB Group RIPE NCC

1 1

Re: [db-wg] Re: NCC#2003094280 SUCCESS: Bulk deletion of /24 detail
by Janos Zsako 12 Sep '03

12 Sep '03

> From db-wg-admin(a)ripe.net Fri Sep 12 11:15:10 2003 Dear all, > Regarding the SUCCESS reply it was a decision that we made when we re-structured > dbupdate that we only reported FAILUE if we detected an error. If there is no > error we report SUCCESS. This means that SUCCESS is now returned for a blank > update message, a message where none of the objects are recognised (as in your > case) and when no operation is performed because the submitted object is > identical to the one currently in the database. > > It would not be difficult to change this behaviour if it is generally felt that > the current scheme is mis-leading. Perhaps we can have some opinions about this > from other users on the db-wg mailing list. As input for the WG, here is the relevant part of the private mail I sent to Niall: ----- Begin Included Message ----- My understanding is that the parser did not find any object, i.e. any task to be performed, therefore it did not flag any error, so the whole mail was processed with "sucess"... I admit this is definitely misleading, so it may be useful to treat this as a special case (i.e. the case of an empty mail that has a warning). [In case you submit several objects or tasks, one of which at least is correct and you also have ignored objects due to wrong syntax, the result SUCCESS is less misleading in my view, as at least the correct task was performed with success...] ----- End Included Message ----- In other words, do not flag with SUCCESS an empty message. I recommend to flag it with something like UNKNOWN. Janos

1 0

Re: NCC#2003092385 [db-wg] uodate failure
by Wilfried Woeber, UniVie/ACOnet 09 Sep '03

09 Sep '03

Hi Randy, thanks for bringing this up! [ the "keyword noise" had me confused too, a short while ago :-( ] I am wondering whether "inline" error messages are such a good idea? I guess there's a good chance that they remain in the updated and re-sent message. That could give us another set of failure modes. _I_ would probably go for a more descriptive error message at the end, including the _attribute_ that made the reference, _and_ the _string_ used as a reference. -WW ______________________________________________________________________ From: Randy Bush <randy(a)psg.com> To: RIPE Database Administration <ripe-dbm(a)ripe.net> CC: db-wg(a)ripe.net Subject: Re: NCC#2003092385 [db-wg] uodate failure Date: Mon, 8 Sep 2003 06:07:48 -0700 btw, to be very clear, and as a once-upon-a-time compiler hacker who would have been severely excoriated for poor diagnostic reporting, what i would have liked to have received would be something along the lines of Modify FAILED: [aut-num] AS3130 ***Info: Authorisation passed ***Info: Syntax check passed aut-num: AS3130 as-name: RGNET-3130 descr: RGnet/PSGnet admin-c: RB366 ^ unknown object referenced tech-c: RB366 ^ unknown object referenced import: from AS1239 accept ANY import: from AS2914 accept ANY import: from AS3927 accept AS3927 import: from AS3970 accept AS3970 import: from AS4128 accept AS4128 import: from AS101 accept AS-PNW-GIGAPOP import: from AS11726 accept AS-ACUMEN import: from AS12111 accept AS-OEN import: from AS16713 accept AS-NOANET-PEERING import: from AS2044 accept AS2044 import: from AS3491 accept AS-CAIS import: from AS4513 accept AS-GLOBIX import: from AS4565 accept AS-EPOCH import: from AS6456 accept AS6456 import: from AS7610 accept AS-SINGAREN import: from AS8075 accept AS8075 export: to AS1239 announce AS-RGNET export: to AS2914 announce AS-RGNET export: to AS3927 announce ANY export: to AS3970 announce ANY export: to AS4128 announce ANY export: to AS101 announce AS-RGNET export: to AS11726 announce AS-RGNET export: to AS12111 announce AS-RGNET export: to AS16713 announce AS-RGNET export: to AS2044 announce AS-RGNET export: to AS3491 announce AS-RGNET export: to AS4513 announce AS-RGNET export: to AS4565 announce AS-RGNET export: to AS6456 announce AS-RGNET export: to AS7610 announce AS-RGNET export: to AS8075 announce AS-RGNET notify: rw(a)rg.net mnt-by: MAINT-RGNET changed: randy(a)psg.com 20030905 source: RIPE ***Info: Authorisation for [aut-num] AS3130 using mnt-by: authenticated by: MAINT-RGNET randy --------------------------------------------------------------------------------

4 3

Re: NCC#2003092385 [db-wg] uodate failure
by Denis Walker 08 Sep '03

08 Sep '03

"Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> writes: * Hi Randy, * * thanks for bringing this up! * [ the "keyword noise" had me confused too, a short while ago :-( ] I think we assumed that people would associate 'keywords' with those words in the subject line of a mail message or entered separately with the web updates form. Perhaps we need to add something to the message to make it more clear. * * I am wondering whether "inline" error messages are such a good idea? * I guess there's a good chance that they remain in the updated and * re-sent message. That could give us another set of failure modes. * * _I_ would probably go for a more descriptive error message at the end, * including the _attribute_ that made the reference, _and_ the _string_ * used as a reference. This is the way we have planned to do it and the code has already been written for the dbupdate part. But these error messages originate in the server back end code where all referential integrity checks are performed. It is on our 'ToDo' list to review this section of the code. cheers denis * * -WW * ______________________________________________________________________ * * From: Randy Bush <randy(a)psg.com> * To: RIPE Database Administration <ripe-dbm(a)ripe.net> * CC: db-wg(a)ripe.net * Subject: Re: NCC#2003092385 [db-wg] uodate failure * Date: Mon, 8 Sep 2003 06:07:48 -0700 * * btw, to be very clear, and as a once-upon-a-time compiler hacker * who would have been severely excoriated for poor diagnostic * reporting, what i would have liked to have received would be * something along the lines of * * Modify FAILED: [aut-num] AS3130 * ***Info: Authorisation passed * ***Info: Syntax check passed * * aut-num: AS3130 * as-name: RGNET-3130 * descr: RGnet/PSGnet * admin-c: RB366 * ^ unknown object referenced * tech-c: RB366 * ^ unknown object referenced * import: from AS1239 accept ANY * import: from AS2914 accept ANY * import: from AS3927 accept AS3927 * import: from AS3970 accept AS3970 * import: from AS4128 accept AS4128 * import: from AS101 accept AS-PNW-GIGAPOP * import: from AS11726 accept AS-ACUMEN * import: from AS12111 accept AS-OEN * import: from AS16713 accept AS-NOANET-PEERING * import: from AS2044 accept AS2044 * import: from AS3491 accept AS-CAIS * import: from AS4513 accept AS-GLOBIX * import: from AS4565 accept AS-EPOCH * import: from AS6456 accept AS6456 * import: from AS7610 accept AS-SINGAREN * import: from AS8075 accept AS8075 * export: to AS1239 announce AS-RGNET * export: to AS2914 announce AS-RGNET * export: to AS3927 announce ANY * export: to AS3970 announce ANY * export: to AS4128 announce ANY * export: to AS101 announce AS-RGNET * export: to AS11726 announce AS-RGNET * export: to AS12111 announce AS-RGNET * export: to AS16713 announce AS-RGNET * export: to AS2044 announce AS-RGNET * export: to AS3491 announce AS-RGNET * export: to AS4513 announce AS-RGNET * export: to AS4565 announce AS-RGNET * export: to AS6456 announce AS-RGNET * export: to AS7610 announce AS-RGNET * export: to AS8075 announce AS-RGNET * notify: rw(a)rg.net * mnt-by: MAINT-RGNET * changed: randy(a)psg.com 20030905 * source: RIPE * * ***Info: Authorisation for [aut-num] AS3130 * using mnt-by: * authenticated by: MAINT-RGNET * * randy * * ---------------------------------------------------------------------------- * ---- *

1 0

Re: [db-wg] Re: "changed:" attribute
by Denis Walker 08 Sep '03

08 Sep '03

Steve Atkins <steve(a)blighty.com> writes: * On Mon, Sep 08, 2003 at 03:21:20PM +0100, Rodney Tillotson wrote: * > 2. * > > Secondly, the query users do not really know what "changed:" attribute * > > means. ... most users and automated tools pick anything that resembles * > > an email address in the whois query result and send them abuse * > > complaints. * > * > The question here is about external presentation; who sees "changed:", * > what they are looking for when they see it, what they think it means * > and what they do with it. * > * > * > The anti-spam WG is preparing a broad proposal, but one early thought * > is to provide different database views for the different classes of * > user. Casual users looking for contact information in the default * > output are an important class, probably not the most well-informed or * > patient, and it may be worth suppressing "changed:" in the view they * > get. This applies whatever decisions we make about the internal * > behaviour or the way LIRs will use the attribute. * * That seems like a good idea. Many casual users of the RIPE database do * not query it directly, rather through a small number of web-based * gateways. Would it be worth asking the owners of those gateways * to filter out the changed field now, to see what effect that has? But then someone will realise the changed lines are missing and think we are hiding something. So they will write a tool to show them and give them even more significance. cheers denis * * Cheers, * Steve *

2 1

The New "organisation object" Proposal
by DB-News 08 Sep '03

08 Sep '03

Dear Colleagues, [apologies for duplicate messages] Following discussions at the RIPE NCC about a new Whois Database object, the organisation object, we have modified the previous proposal that you can find at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html The main changes from the previous proposal are: - a "country:" attribute is added. - "org-type:" and "org-name:" attributes are added, and "organisation:" attribute is now a NIC handle, which will be automatically assigned during the creation of the object. The motivation for this is explained in Section 3 of the proposal. - Hierarchical names can be removed, mainly for simplicity. - Differing query results on the whois server introduced in section 5. According to this, the relevant organisation objects are appended to the query results (because the organisation that holds the resource is at least as important as the person/role objects mentioned in the resource object). Please let us know your comments and concerns about the new proposal attached to this mail. Thanks for your time and best regards, -- Engin Gunduz RIPE NCC Database Group An organisation object in the RIPE Database -------------------------------------------- 1. Motivation ------------------- Currently the RIPE Database stores two main types of contact information: person and role objects. The person and role objects provide a way to contact people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, autonomous systems, and domain names). However, none of these provide an easy way of mapping resources to a particular organisation. A user must first find an object containing contact information for that organisation. Then, assuming all of the organisation's objects refer to this contact information, the user must perform an inverse query to obtain a list of objects referencing the specified person or role. This indirect process can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation is seen as a useful addition to the RIPE Database. This document is a proposal for an organisation object in the RIPE Database and the necessary database functionality. 2. The organisation object ----------------------- The organisation object provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the RIPE Database. The organisation object is identified by a unique ID specified in the "organisation:" attribute which is the primary key. An organisation object can be referenced from other types of objects using an "org:" attribute. All objects associated with a particular organisation can be retrieved by performing an "inverse query" for the organisation's ID (handle) used in the "org:" attribute of database objects. Following is a template for the proposed organisation object and an example. All attributes except the "ref-nfy:", "organisation:", "org-name:" and "org-type:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 3. New attributes ---------------------- "organisation:" Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example: ORG-RT34-RIPE Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part. Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object. The organisation ID cannot be reused. If an organisation ID was used in the past by an organisation object and then deleted, this ID cannot be used in new organisation objects. The auto-generation of organisation IDs and preventing reuse of them simplifies the external references. Note that when an organisation changes name, the "org-name:" can be modified accordingly. There is no need to change the organisation ID. "org-name:" Specifies the name of the organisation that this organisation object represents in the whois database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. "org-type:" Specifies the type of the organisation. The possible values are 'IANA' for Internet Assigned Numbers Authority, 'RIR' for Regional Internet Registries, 'NIR' for National Internet Registries, 'LIR' for Local Internet Registries, and 'NON-REGISTRY' for all other organisations. "ref-nfy:" Specifies the e-mail address to be notified when a reference to the organisation object is added or removed. An e-mail address as defined in RFC 2822. [This functionality is used in the "irt-nfy:". The name of this attribute is more neutral allowing reuse in other object types.] "country:" Specifies the two-letter ISO3166 country code of the country where this organisation resides. "address:" Specifies the address of the organisation. This is a free-text attribute. "org:" May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects. 4. Authorisation checks ---------------------------------- When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object. When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks: - from one of the maintainers of the organisation object - from one of the maintainers of the object being updated 5. Query changes ---------------- If a whois query returns an object with an "org:" attribute, the organisation object mentioned in this attribute is also appended to the query results. This behaviour can be disabled by using the '-r' flag in the query. 6. Examples ------------ A basic organisation object: organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. city: Amsterdam country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE notify: ripe-mailbox(a)example-org.net ref-nfy: ripe-mailbox(a)example-org.net mnt-by: EXAMPLE-MNT changed: someguy(a)example-org.net 20030121 source: RIPE A network that references an organisation object: inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE status: ALLOCATED-BY-RIR PORTABLE mnt-by: EXAMPLE-MNT mnt-lower: EXAMPLE-MNT changed: someguy(a)example-org.net 20030122 source: RIPE A query for this inetnum object: % whois 192.168.86.251 inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE person: John Example nic-hdl: JE1-RIPE [...] source: RIPE person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE

17 35

Re: NCC#2003092385 [db-wg] uodate failure
by RIPE Database Administration 08 Sep '03

08 Sep '03

Dear Randy, I've sent the answer in the morning, strangely it didn't reach you. Please find it below. If you have any more questions, please contact <ripe-dbm(a)ripe.net>. Regards, Katie Petrusha ____________________________ RIPE Database Administration. From: RIPE Database Administration <ripe-dbm(a)ripe.net> To: Randy Bush <randy(a)psg.com> FCC: cur Subject: Re: NCC#2003091799 FAILED: as3130 Reply-To: ripe-dbm(a)ripe.net Date: Mon, 08 Sep 2003 10:43:51 +0200 Dear Randy, At the moment person/role object with nic-handle RB366 doesn't exist in the RIPEDatabase, therefore you can't reference it from any other object. However RB366-ARIN exists and seems to be yours, maybe you meant to use that one? If you have any more questions, please contact <ripe-dbm(a)ripe.net>. Regards, Katie Petrusha ____________________________ RIPE Database Administration. Original message follows: ------------------------ no answer from ripe-dbm(a)ripe.net, so figured to ask here. what did i do wrongly? (original was pgp wrapped) To: randy(a)psg.com Subject: FAILED: as3130 Date: Fri, 5 Sep 2003 23:08:42 +0200 (MEST) > From: Randy Bush <randy(a)psg.com> > Subject: as3130 > Date: Fri, 5 Sep 2003 14:08:25 -0700 > Reply-To: randy(a)psg.com > Message-ID: <E19vNog-0004bn-CN(a)ran.psg.com> SUMMARY OF UPDATE: Number of objects found: 1 Number of objects processed successfully: 0 Create: 0 Modify: 0 Delete: 0 No Operation: 0 Number of objects processed with errors: 1 Create: 0 Modify: 1 Delete: 0 Syntax Errors: 0 DETAILED EXPLANATION: ***Warning: Invalid keyword(s) found: as3130 ***Warning: All keywords were ignored ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following object(s) were found to have ERRORS: --- Modify FAILED: [aut-num] AS3130 ***Info: Authorisation passed ***Info: Syntax check passed aut-num: AS3130 as-name: RGNET-3130 descr: RGnet/PSGnet admin-c: RB366 tech-c: RB366 import: from AS1239 accept ANY import: from AS2914 accept ANY import: from AS3927 accept AS3927 import: from AS3970 accept AS3970 import: from AS4128 accept AS4128 import: from AS101 accept AS-PNW-GIGAPOP import: from AS11726 accept AS-ACUMEN import: from AS12111 accept AS-OEN import: from AS16713 accept AS-NOANET-PEERING import: from AS2044 accept AS2044 import: from AS3491 accept AS-CAIS import: from AS4513 accept AS-GLOBIX import: from AS4565 accept AS-EPOCH import: from AS6456 accept AS6456 import: from AS7610 accept AS-SINGAREN import: from AS8075 accept AS8075 export: to AS1239 announce AS-RGNET export: to AS2914 announce AS-RGNET export: to AS3927 announce ANY export: to AS3970 announce ANY export: to AS4128 announce ANY export: to AS101 announce AS-RGNET export: to AS11726 announce AS-RGNET export: to AS12111 announce AS-RGNET export: to AS16713 announce AS-RGNET export: to AS2044 announce AS-RGNET export: to AS3491 announce AS-RGNET export: to AS4513 announce AS-RGNET export: to AS4565 announce AS-RGNET export: to AS6456 announce AS-RGNET export: to AS7610 announce AS-RGNET export: to AS8075 announce AS-RGNET notify: rw(a)rg.net mnt-by: MAINT-RGNET changed: randy(a)psg.com 20030905 source: RIPE ***Error: Unknown object referenced ***Info: Authorisation for [aut-num] AS3130 using mnt-by: authenticated by: MAINT-RGNET ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For assistance or clarification please contact: RIPE Database Administration <ripe-dbm(a)ripe.net>

6 7

Suggestion for more user-friendly auto-dbm behaviour
by Niall O'Reilly 08 Sep '03

08 Sep '03

After a long period of not dealing with the RIPE database, I'm getting around to some overdue housekeeping. I've been surprised at how unfriendly the interface is. The following suggestions arise from this experience. First suggestion ... > ***Warning: Invalid keyword(s) found: Update > ***Warning: All keywords were ignored It could be more clearly put, that this refers only to the 'Subject' line. Why not replace the text, "All keywords were ignored" with "Entire subject line was ignored". Second suggestion ... > ***Error: Required attribute "netname" is missing > ***Error: Required attribute "country" is missing > ***Error: Required attribute "status" is missing > ***Error: Required attribute "mnt-by" is missing I didn't wish to modify any of these just now. Why not proceed as follows: 1. Load (partial) object from transaction. 2. Retrieve matching object (if any) from database. 3. Perform go/no-go tests (authorization, validity ...) 4. Merge transaction with what was retrieved (may be null). 5. Perform any completeness/self-consistency tests. 6. Commit update unless errors were found. 7. Notify parties involved. That should be worth at least EUR 0.02! I'll send on the invoice. 8-) Niall O'Reilly

1 0

summary of organisation object discussions
by Engin Gunduz 08 Sep '03

08 Sep '03

Dear Colleagues, [apologies for duplicate messages, and for having misspelled ncc-services-wg(a)ripe.net in the previous posting] I'd like to summarise the discussions took place in the last two weeks in the working group mailing lists after the publication of the organisation object proposal ( http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html ) and after the presentation in the DB-WG session last week in RIPE 46 Meeting ( http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-organisat… ). 1. "org:" attribute mandatory or optional in aut-num objects? The proposal mentioned above specified "org:" attribute in aut-num objects to be mandatory. However, often LIRs request an ASN for their customers and the RIPE NCC does not have enough information for them to fill in an organisation object completely. Rather than putting invalid information on the whois database, the RIPE NCC thinks it is better to make "org:" attribute optional in aut-nums. 2. "org:" attribute multi- or single-valued? The proposal specified "org:" attribute single-valued in all objects. During the discussions in the DB WG, commentors from the audience stated that in some cases a person object works for more than one companies, thus one might want to put multiple "org:" attributes in his/her person object. Similar reasoning could apply to other object types as well. However, the "org:" object specifies the holder of an Internet resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in these objects. For the rest of the objects, we propose to modify the rule so it can be multi-valued. 3. addition of "mnt-ref:" attribute. The proposal suggested the use of "mnt-by:" attribute for both authorisation of modification of the organisation object and the authorisation of adding a reference to the organisation object from other objects. This has a shortcoming when the organisation object is protected by an entity other than the organisation itself (for example, an LIR, whose organisation object is protected by the RIPE NCC). We would propose to introduce mandatory "mnt-ref:" attribute to control the references to the organisation object, while "mnt-by:" protects the organisation object itself, as usual. 4. "org:" attribute in the organisation object itself. The proposal suggested the use of "org:" attribute in non-organisation objects. I think it could be used in organisation objects as well, to indicate business relations like being a dependent company to another one. 5. "business-id:" attribute. It was suggested to add an attribute to specify the national organisation number or VAT number or a similar ID of the organisation. While we see the point in this, we feel it needs some more discussion. It can be added to the organisation object after its introduction. 6. changing the meaning of '-r' flag. The proposal suggested that, when a query returns an object with an "org:" attribute, the organisation objects mentioned in this attribute be appended to the query results. This behaviour can be changed by using '-r' flag in the query. This idea was based on the fact that the "org:" attribute is at least as relevant to the resource as the "admin-c:", "tech-c:" and "zone-c:" attributes as contact information. Thus, if we return person/role objects mentioned in the query results, we should also return the organisation objects. Basically, the proposed behaviour maintains the consistency. During the discussions it was proposed to change the default behaviour of whois server, and change the meaning of '-r' flag, so that - the server does not 'expand' "admin-c:", "tech-c:" and "zone-c:" attributes, nor "org:" attribute by default, - and it expands them only when '-r' flag is used. This can separately be discussed, however, I think this is out of the scope of organisation object. I hope I did not miss any other issues. If these points are OK, we will prepare another proposal for organisation object and publish it. Best regards, -- Engin Gunduz RIPE NCC Database Group

1 0

summary of organisation object discussions
by Engin Gunduz 08 Sep '03

08 Sep '03

Dear Colleagues, I'd like to summarise the discussions took place in the last two weeks in the working group mailing lists after the publication of the organisation object proposal ( http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html ) and after the presentation in the DB-WG session last week in RIPE 46 Meeting ( http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-organisat… ). 1. "org:" attribute mandatory or optional in aut-num objects? The proposal mentioned above specified "org:" attribute in aut-num objects to be mandatory. However, often LIRs request an ASN for their customers and the RIPE NCC does not have enough information for them to fill in an organisation object completely. Rather than putting invalid information on the whois database, the RIPE NCC thinks it is better to make "org:" attribute optional in aut-nums. 2. "org:" attribute multi- or single-valued? The proposal specified "org:" attribute single-valued in all objects. During the discussions in the DB WG, commentors from the audience stated that in some cases a person object works for more than one companies, thus one might want to put multiple "org:" attributes in his/her person object. Similar reasoning could apply to other object types as well. However, the "org:" object specifies the holder of an Internet resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in these objects. For the rest of the objects, we propose to modify the rule so it can be multi-valued. 3. addition of "mnt-ref:" attribute. The proposal suggested the use of "mnt-by:" attribute for both authorisation of modification of the organisation object and the authorisation of adding a reference to the organisation object from other objects. This has a shortcoming when the organisation object is protected by an entity other than the organisation itself (for example, an LIR, whose organisation object is protected by the RIPE NCC). We would propose to introduce mandatory "mnt-ref:" attribute to control the references to the organisation object, while "mnt-by:" protects the organisation object itself, as usual. 4. "org:" attribute in the organisation object itself. The proposal suggested the use of "org:" attribute in non-organisation objects. I think it could be used in organisation objects as well, to indicate business relations like being a dependent company to another one. 5. "business-id:" attribute. It was suggested to add an attribute to specify the national organisation number or VAT number or a similar ID of the organisation. While we see the point in this, we feel it needs some more discussion. It can be added to the organisation object after its introduction. 6. changing the meaning of '-r' flag. The proposal suggested that, when a query returns an object with an "org:" attribute, the organisation objects mentioned in this attribute be appended to the query results. This behaviour can be changed by using '-r' flag in the query. This idea was based on the fact that the "org:" attribute is at least as relevant to the resource as the "admin-c:", "tech-c:" and "zone-c:" attributes as contact information. Thus, if we return person/role objects mentioned in the query results, we should also return the organisation objects. Basically, the proposed behaviour maintains the consistency. During the discussions it was proposed to change the default behaviour of whois server, and change the meaning of '-r' flag, so that - the server does not 'expand' "admin-c:", "tech-c:" and "zone-c:" attributes, nor "org:" attribute by default, - and it expands them only when '-r' flag is used. This can separately be discussed, however, I think this is out of the scope of organisation object. I hope I did not miss any other issues. If these points are OK, we will prepare another proposal for organisation object and publish it. Best regards, -- Engin Gunduz RIPE NCC Database Group

1 0