From joao at ripe.net Mon Sep 3 17:14:40 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 3 Sep 2001 17:14:40 +0200 Subject: Removal of selected sets of contact information from the RIPE Database Message-ID: Dear all, (apologies for duplicates) This is a reminder notice regarding the process of removal of selected sets of contact information from the RIPE Database as initially announced in my mail of 21-8-2001. This phase of the process will affect all person and role objects that are either: - both un-maintained and unreferenced - unreferenced and maintained by maintainers related to registration of domain names in .de For further details about this process, visit the RIPE NCC's web site at http://www.ripe.net/ripencc/pub-services/db/orphaned.html or the "RIPE NCC Annoucements" section at http://www.ripe.net Best regards, Joao Damas Chief Technical Officer RIPE NCC From joao at ripe.net Tue Sep 11 17:50:10 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 11 Sep 2001 17:50:10 +0200 Subject: Reminder: Removal of selected sets of contact information from the RIPE Database Message-ID: Dear all, (apologies for duplicates) This message is a reminder of the ongoing process of removal of unreferenced contact information from the RIPE Database. We have updated the web page http://www.ripe.net/ripencc/pub-services/db/orphaned.html with a more up to date list of maintainer objects relevant to this process. I would like to use the opportunity to clarify an apparently confusing aspect of previous notes: If your person/role object already has a mnt-by attribute that references a maintainer object not contained in the list provided in the above mentioned web page, there is no need to add a reference to RIPE-NCC-PN-NONE-MNT. This maintainer has been created by the RIPE NCC with the sole purpose of facilitating a mechanism for people without maintainer objects to tag their person/role objects to avoid deletion. If you already have a proper maintainer object, DO NOT include RIPE-NCC-PN-NONE-MNT as this would lower your protection level. Best regards, Joao Damas RIPE NCC From mlelstv at xlink.net Thu Sep 13 14:21:05 2001 From: mlelstv at xlink.net (Michael van Elst) Date: Thu, 13 Sep 2001 14:21:05 +0200 Subject: Reminder: Removal of selected sets of contact information from the RIPE Database In-Reply-To: ; from Joao Luis Silva Damas on Tue, Sep 11, 2001 at 05:50:10PM +0200 References: Message-ID: <20010913142105.A22773@xlink.net> On Tue, Sep 11, 2001 at 05:50:10PM +0200, Joao Luis Silva Damas wrote: > Dear all, > > (apologies for duplicates) > > This message is a reminder of the ongoing process of removal of > unreferenced contact information from the RIPE Database. > > We have updated the web page > http://www.ripe.net/ripencc/pub-services/db/orphaned.html with a more > up to date list of maintainer objects relevant to this process. The page says: | 3.Due to the nature and the size of the data set involved, the RIPE NCC can | not publish a list of all the objects affected. and suggests to poll the status of the entries with a usual whois client. Due to the nature and size of the data set involved this requires a million queries to the RIPE database to avoid ambiguities with the very very likeley event of rapidly reassigned handles. I suggest to create a list of involved entries and pass it to the maintainer in question. -- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre \/ fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Peter Dressler ] From andrei at ripe.net Thu Sep 13 16:11:31 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 13 Sep 2001 16:11:31 +0200 Subject: Reminder: Removal of selected sets of contact information from the RIPE Database References: <20010913142105.A22773@xlink.net> Message-ID: <3BA0BE93.49A0409D@ripe.net> Dear Michael van Elst, (ripe-list is removed from the cc:) Michael van Elst wrote: > > On Tue, Sep 11, 2001 at 05:50:10PM +0200, Joao Luis Silva Damas wrote: > > Dear all, > > > > (apologies for duplicates) > > > > This message is a reminder of the ongoing process of removal of > > unreferenced contact information from the RIPE Database. > > > > We have updated the web page > > http://www.ripe.net/ripencc/pub-services/db/orphaned.html with a more > > up to date list of maintainer objects relevant to this process. > > The page says: > > | 3.Due to the nature and the size of the data set involved, the RIPE NCC can > | not publish a list of all the objects affected. > > and suggests to poll the status of the entries with a usual whois client. > > Due to the nature and size of the data set involved this requires a > million queries to the RIPE database to avoid ambiguities with the > very very likeley event of rapidly reassigned handles. > Could you please explain the problem? The proposed protection mechanism with the RIP-NCC-PN-NONE-MNT is targeted only at individuals who have unreferenced and unmaintained person objects and want to protect their objects in the database. It is not supposed to be used by a maintainer from the published list. > I suggest to create a list of involved entries and pass it to the > maintainer in question. > > -- > i.A. Michael van Elst / phone: +49 721 9652 330 > Xlink - Network Information Centre \/ fax: +49 721 9652 349 > Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ > D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net > [ KPNQwest Germany GmbH, Sitz Karlsruhe ] > [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Peter Dressler ] Regards, Andrei Robachevsky DB Group Manager RIPE NCC From mlelstv at xlink.net Thu Sep 13 16:46:22 2001 From: mlelstv at xlink.net (Michael van Elst) Date: Thu, 13 Sep 2001 16:46:22 +0200 Subject: Reminder: Removal of selected sets of contact information from the RIPE Database In-Reply-To: <3BA0BE93.49A0409D@ripe.net>; from Andrei Robachevsky on Thu, Sep 13, 2001 at 04:11:31PM +0200 References: <20010913142105.A22773@xlink.net> <3BA0BE93.49A0409D@ripe.net> Message-ID: <20010913164622.A24467@xlink.net> On Thu, Sep 13, 2001 at 04:11:31PM +0200, Andrei Robachevsky wrote: > Dear Michael van Elst, > > Could you please explain the problem? The proposed protection mechanism > with the RIP-NCC-PN-NONE-MNT is targeted only at individuals who have > unreferenced and unmaintained person objects and want to protect their > objects in the database. > > It is not supposed to be used by a maintainer from the published list. Sorry if there was a misunderstanding. It's not about protecting entries. I am responsible for a huge part of the to-be-deleted entries (XLINK-MNT) and I would really _welcome_ a list of the then deleted entries belonging to XLINK-MNT to synchronize this change with our own databases. It would be less of a problem if RIPE wouldn't re-assign handles. But as it is, our only way is to validate each and every database entry to find out what had been deleted. Greetings, -- i.A. Michael van Elst / phone: +49 721 9652 330 Xlink - Network Information Centre \/ fax: +49 721 9652 349 Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net [ KPNQwest Germany GmbH, Sitz Karlsruhe ] [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Peter Dressler ] From andrei at ripe.net Fri Sep 14 11:34:01 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Fri, 14 Sep 2001 11:34:01 +0200 Subject: Reminder: Removal of selected sets of contact information from the RIPE Database References: <20010913142105.A22773@xlink.net> <3BA0BE93.49A0409D@ripe.net> <20010913164622.A24467@xlink.net> Message-ID: <3BA1CF09.28639A04@ripe.net> Michael van Elst wrote: > > On Thu, Sep 13, 2001 at 04:11:31PM +0200, Andrei Robachevsky wrote: > > Dear Michael van Elst, > > > > Could you please explain the problem? The proposed protection mechanism > > with the RIP-NCC-PN-NONE-MNT is targeted only at individuals who have > > unreferenced and unmaintained person objects and want to protect their > > objects in the database. > > > > It is not supposed to be used by a maintainer from the published list. > > Sorry if there was a misunderstanding. It's not about protecting entries. > > I am responsible for a huge part of the to-be-deleted entries (XLINK-MNT) > and I would really _welcome_ a list of the then deleted entries belonging > to XLINK-MNT to synchronize this change with our own databases. > > It would be less of a problem if RIPE wouldn't re-assign handles. But > as it is, our only way is to validate each and every database entry > to find out what had been deleted. > We will try to help maintainers responsible for huge amount of contact information stored in the RIPE Database. If you feel you need such help, please contact ripe-dbm at ripe.net (with a copy to myself, andrei at ripe.net) to discuss your situation. Thanks, Andrei Robachevsky DB Group Manager RIPE NCC > Greetings, > -- > i.A. Michael van Elst / phone: +49 721 9652 330 > Xlink - Network Information Centre \/ fax: +49 721 9652 349 > Emmy-Noether-Strasse 9 /\ link http://nic.xlink.net/ > D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net > [ KPNQwest Germany GmbH, Sitz Karlsruhe ] > [ Amtsgericht Karlsruhe HRB 8161, Geschaeftsfuehrer: Peter Dressler ] From zeidler at kpnqwest.de Thu Sep 13 19:07:42 2001 From: zeidler at kpnqwest.de (Petra Zeidler) Date: Thu, 13 Sep 2001 19:07:42 +0200 Subject: on the question of 'right to maintainership' Message-ID: <20010913190742.A14315@kpnqwest.de> Dear all, I am herewith soliciting opinions and 'current practise' on the question of maintainership of inetnums. We are in the position of having several allocations that are infested with 'historical' PI assignments, i.e. address assignments that have been assigned before the advent of CIDR. My LIR (de.xlink) currently refuses to enter maintainers different from ours to inetnums from our allocation, due to less than happy experiences with different (even also LIR) maintainers in the past (when the user of the 'historical' PI left its new provider and renumbered they lost all interest in the inetnum and it took quite some time to get the object referring to the then long returned address space deleted). Some people seem to think that they have a right to maintainership to objects that are assigned to them; I cannot find any such rule in the LIR procedures, and also it would be a good question where that would stop .. has anybody assigned a PA /29 a right to maintain their own object? and if yes, how are the hostmasters responsible for an allocation supposed to keep their charge in order? After assignment, anything but the size of the range would be fair game, very fun especially in cases where a tech-c decides that the inetnum range is their personal property even though it has not been assigned to them personally (and that is by no means a rare occurrence). Of course both the crook and the misled are the exception, not the rule, but we -do- have maintainers in the first place because of them, and a rule ought to be based on something better than 'you look kind of trustworthy'. What's your position on the problem as such? And if you give third parties maintainership of inetnums in your allocation(s), under what rules do you do so? To any kind of inetnum? To anyone asking who has a maintainer object? And if you do so, do you still assign from that allocation(s)? kind regards, Petra Zeidler -- [A] KPNQwest Germany * Emmy-Noether-Strasse 9 * D-76131 Karlsruhe [T] +49 721 9652 215 [F] +49 721 9652 171 [E] petra.zeidler at kpnqwest.com [I] www.kpnqwest.de From daniel at karrenberg.net Mon Sep 17 09:10:31 2001 From: daniel at karrenberg.net (Daniel Karrenberg) Date: Mon, 17 Sep 2001 09:10:31 +0200 Subject: on the question of 'right to maintainership' In-Reply-To: <20010913190742.A14315@kpnqwest.de> Message-ID: <4.3.2.7.2.20010917085958.01cdcda0@localhost.ripe.net> [personal opinion, since I saw no replies yet and I think this deserves one] A LIR is responsible for the registration of address space assignments from address space allocations it receives from the RIPE NCC. From this alone it follows that a LIR may reserve the right to make changes to these registrations. Of course the LIR should be responsive to requests for changes. This does not mean that it has to make any change requested. Changes should be goverened by a local policy. Daniel PS: Technically speaking you can have multiple maintainers on an object that all have equal rights. So if you trust someone you can let them make their own changes while keeping the possibility to make changes yourself. The right notify options will make sure you know abut changes. Beware: Technically speaking one of these maintainers can remove the other, albeit not without the other noticing if notifications are configured right. From shane at ripe.net Wed Sep 19 17:39:23 2001 From: shane at ripe.net (Shane Kerr) Date: Wed, 19 Sep 2001 17:39:23 +0200 Subject: RIPE Whois Server version 3.0.2 Message-ID: <20010919173921.A341@x17.ripe.net> Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0.2 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release is intended both as a bug fix release, and also to offer much-improved ease of installation and configuration. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.0.2 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2-nocxref.tar.gz A patch for the 3.0.1 "nocxref" version is also available, if you already have that version, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.0.1-nocxref-3.0.2.gz If you have any more questions, please don't hesitate to contact . -- Shane Kerr RIPE NCC From asjl at lionra.net.nz Thu Sep 20 00:13:52 2001 From: asjl at lionra.net.nz (Andy Linton) Date: Thu, 20 Sep 2001 10:13:52 +1200 (NZST) Subject: RIPE Whois Server version 3.0.2 In-Reply-To: <20010919173921.A341@x17.ripe.net> Message-ID: <20010920095905.N6974-100000@cheviot.lionra.net.nz> On Wed, 19 Sep 2001, Shane Kerr wrote: > Dear Colleagues, > > [Apologies for multiple messages]. > > The RIPE NCC is pleased to announce the release of Version 3.0.2 of the > RIPE Whois server. This software is compliant with both RPSL > (RFC-2622) and RPS-Security (RFC-2725). > > This release is intended both as a bug fix release, and also to offer > much-improved ease of installation and configuration. > > Detailed release notes can be found at the following URL: > > ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.0.2 Here's a couple of minor changes needed to make FreeBSD compile "out of the box" on an APNIC FreeBSD system i.e. FreeBSD whois8.apnic.net 4.3-STABLE FreeBSD 4.3-STABLE #0: Fri Jul 20 14:17:28 EST 2001 root at whois8.apnic.net:/usr/src/sys/compile/DSF i386 As well as minor changes to the FreeBSD flags in 'build.sh' I had to add a LIBS definition to allow resolution of the CIPHER(3) calls for setkey, encrypt, des_setkey, des_cipher: *** build.sh Thu Sep 20 07:44:14 2001 --- build.sh.orig Thu Sep 20 08:02:14 2001 *************** *** 76,92 **** #export LIBS # FreeBSD 4.3, with additional software installed in /usr/local ! GLIBCONF=/usr/local/bin/glib-config ! MYSQLINC=/usr/local/include/mysql ! MYSQLLIB=/usr/local/lib/mysql ! MYSQLBIN=/usr/local/bin ! CCLIENTINC=/usr/local/include/c-client ! CCLIENTLIB=/usr/local/lib/c-client ! GPGCMD=/usr/local/bin/gpg ! CFLAGS="-I/usr/local/bind/include -L/usr/local/bind/lib" ! export CFLAGS ! LIBS="-lcipher" ! export LIBS # To use Solaris Workshop C, uncomment these lines #CC="ucbcc -xCC" --- 76,91 ---- #export LIBS # FreeBSD 4.3, with additional software installed in /usr/local ! #GLIBCONF=/usr/local/bin/glib-config ! #MYSQLINC=/usr/local/mysql/include/mysql ! #MYSQLLIB=/usr/local/mysql/lib/mysql ! #MYSQLBIN=/usr/local/mysql/bin ! #CCLIENTINC=/usr/local/include ! #CCLIENTLIB=/usr/local/lib ! #GPGCMD=/usr/local/bin/gpg ! #CFLAGS="-I/usr/local/include/bind -L/usr/local/lib" ! #export CFLAGS ! # To use Solaris Workshop C, uncomment these lines #CC="ucbcc -xCC" After this is done there's still a problem with the order in which libraries get called so I had to change Makefile.site.in: *** Makefile.site.in Thu Sep 20 08:00:04 2001 --- Makefile.site.in.orig Tue Sep 11 18:46:08 2001 *************** *** 54,58 **** CFLAGS = @CFLAGS@ -g $(INCLUDES) $(DEFINES) LFLAGS = @CFLAGS@ -g -L$(RIPLIBDIR) -L$(MYSQLLIBDIR) ! LIBS = $(ACLIBS) `$(GLIBCONF) --libs gthread` -lmysqlclient -lm $(CCLIENTLIBDIR)/c-client.a --- 54,58 ---- CFLAGS = @CFLAGS@ -g $(INCLUDES) $(DEFINES) LFLAGS = @CFLAGS@ -g -L$(RIPLIBDIR) -L$(MYSQLLIBDIR) ! LIBS = `$(GLIBCONF) --libs gthread` -lmysqlclient -lm $(ACLIBS) $(CCLIENTLIBDIR)/c-client.a Does this order break things for Linux and Solaris? From asjl at lionra.net.nz Thu Sep 20 00:27:59 2001 From: asjl at lionra.net.nz (Andy Linton) Date: Thu, 20 Sep 2001 10:27:59 +1200 (NZST) Subject: RIPE Whois Server version 3.0.2 In-Reply-To: <20010920095905.N6974-100000@cheviot.lionra.net.nz> Message-ID: <20010920102638.P6974-100000@cheviot.lionra.net.nz> On Thu, 20 Sep 2001, Andy Linton wrote: > Here's a couple of minor changes needed to make FreeBSD compile "out of > the box" on an APNIC FreeBSD system i.e. > > FreeBSD whois8.apnic.net 4.3-STABLE FreeBSD 4.3-STABLE #0: Fri Jul 20 > 14:17:28 EST 2001 root at whois8.apnic.net:/usr/src/sys/compile/DSF i386 > By the way the changes, I posted do provide a working whois_rip server! Congratulations to Shane and the other RIPE folk for making this absolutely the easiest install yet! From shane at ripe.net Wed Sep 19 17:39:23 2001 From: shane at ripe.net (shane at ripe.net) Date: Wed, 19 Sep 2001 17:39:23 +0200 Subject: RIPE Whois Server version 3.0.2 In-Reply-To: <20010919173921.A341@x17.ripe.net> References: <20010919173921.A341@x17.ripe.net> Message-ID: Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0.2 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release is intended both as a bug fix release, and also to offer much-improved ease of installation and configuration. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.0.2 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2-nocxref.tar.gz A patch for the 3.0.1 "nocxref" version is also available, if you already have that version, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.0.1-nocxref-3.0.2.gz If you have any more questions, please don't hesitate to contact . -- Shane Kerr RIPE NCC From fb at de.uu.net Thu Sep 20 12:16:03 2001 From: fb at de.uu.net (Frank Bohnsack) Date: Thu, 20 Sep 2001 12:16:03 +0200 (MET DST) Subject: permissions check Message-ID: dear community, since RIPE is using rfc-2725 it's sometimes not easy to find out if you have enough permissions to modify an object. often you try to update an object but your request has a typo, a missing password or something else. the request fails and many many people will become aware of your misstake. it would be very usefull if we could check our permissions before and a lot of confusions could have been avoided. current example: we need to create a lot of route objects for customer PI space. on the other hand, i see a security hole in this mechanism, because this would be an easy way to find unprotected objects. what is your opinion, could this be an option ? cheers frank -- Frank Bohnsack email fb at de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net From joao at ripe.net Fri Sep 21 10:37:07 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 21 Sep 2001 10:37:07 +0200 Subject: Deletion of person objects. Final reminder Message-ID: Dear all, (apologies for duplicates) Today is the 21st of September. As such, the RIPE NCC will proceed to delete the set of person/role objects detailed in my previous announcements from the RIPE Database. Please see the URL http://www.ripe.net/ripencc/pub-services/db/orphaned.html for information on the details of the objects to be deleted. The following is an outline of the process we will be using: 1. Stop updating the database on Friday, 21, at 18:00 CEST. 2. Remove all person objects according to the criteria: - maintained _only_ by DE domain resellers and not referenced - not maintained and not referenced This will take ~15 hours 3. Next day, on Saturday restart the server with the new database. 4. Resume the updates. As you can see, this process will result in period of a few hours during which UPDATE/ADDITION/DELETION messages sent to the RIPE Database will not be processed immediately, but rather stored for later processing. Queries will be serviced by our hot spare machine. Users will not notice any downtime on that part of the service. The length of the outage is directly related to the number of objects to be deleted (more than 2 million) and the need to use special processes to finalise the process in a reasonable time. Further to this deletion, and in order to avoid replication of the current situation after this deletion process, incoming messages containing person and role objects originating from domain name related activities will NOT be processed. The RIPE NCC will contact any source of such messages in order to clear any possible misunderstandings. Hoping to have informed you well, Joao Luis Silva Damas Chief Technical Officer RIPE NCC From joao at ripe.net Fri Sep 21 16:32:13 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 21 Sep 2001 16:32:13 +0200 Subject: [centr-dnr-forum] Re: Deletion of person objects. Final reminder In-Reply-To: <200109211401.QAA18876@valinor.de.uu.net> References: <200109211401.QAA18876@valinor.de.uu.net> Message-ID: If your "handle" is being used for IP registration our any IRR related function, it will be referenced from an already existing object in the RIPE Database and will therefore NOT be deleted. If your handle was only in use for domain (other that in-addr.arpa) registration purposes, then your contact information should be registered with the corresponding TLD administrator as it will be deleted from the RIPE Database. No new handles are being created in this process as only handles used for functions foreign to the RIPE Database will be deleted in the process later today. Hopes this clarifies the situation for you, if not, please contact me. Regards, Joao Damas RIPE NCC At 16:01 +0200 21/9/01, Andreas Wittkemper wrote: >Hi Joao, > > >> Further to this deletion, and in order to avoid replication of the >> current situation after this deletion process, incoming messages >> containing person and role objects originating from domain name >> related activities will NOT be processed. >> >> The RIPE NCC will contact any source of such messages in order to >> clear any possible misunderstandings. > > >Just for clarification. If a customer had a RIPE Handle which was >needed for the domain adminc, we won't get a new handle which we'll >use for a netassigment ? Considered that the old one would have been >deleted by tomorrow latest. > >regards, > > Andreas Wittkemper -- From aw at de.uu.net Fri Sep 21 16:01:54 2001 From: aw at de.uu.net (Andreas Wittkemper) Date: Fri, 21 Sep 2001 16:01:54 +0200 Subject: Deletion of person objects. Final reminder In-Reply-To: Your message of "Fri, 21 Sep 2001 10:37:07 +0200." Message-ID: <200109211401.QAA18876@valinor.de.uu.net> Hi Joao, > Further to this deletion, and in order to avoid replication of the > current situation after this deletion process, incoming messages > containing person and role objects originating from domain name > related activities will NOT be processed. > > The RIPE NCC will contact any source of such messages in order to > clear any possible misunderstandings. Just for clarification. If a customer had a RIPE Handle which was needed for the domain adminc, we won't get a new handle which we'll use for a netassigment ? Considered that the old one would have been deleted by tomorrow latest. regards, Andreas Wittkemper From joao at ripe.net Fri Sep 21 16:49:08 2001 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 21 Sep 2001 16:49:08 +0200 Subject: [centr-dnr-forum] Re: Deletion of person objects. Final reminder In-Reply-To: <200109211442.QAA19173@valinor.de.uu.net> References: <200109211442.QAA19173@valinor.de.uu.net> Message-ID: At 16:42 +0200 21/9/01, Andreas Wittkemper wrote: >The process of deletion itself is clear. I'm just wondering >about the consequences of your statement. > >> Further to this deletion, and in order to avoid replication of the >> current situation after this deletion process, incoming messages >> containing person and role objects originating from domain name >> related activities will NOT be processed. >> >> The RIPE NCC will contact any source of such messages in order to >> clear any possible misunderstandings. > >Are you going to check if the data of a new requested handle >were used before as a domainonly referenced handle ? >Would you block that and we couldn't request a new handle >with this specific data for an inetnum object ? No we will NOT block the creation of such handles. It doesn't matter whether the handle existed or not before as long as now it is used for IP related issues. What we will do is track the creation of significant amounts of unreferenced contact data. Ideally we would like to implement a regular clean up so that the situation does not build up to what we have now again. regards, Joao Damas RIPE NCC > >regards, > > Andreas Wittkemper > -- From aw at de.uu.net Fri Sep 21 16:42:19 2001 From: aw at de.uu.net (Andreas Wittkemper) Date: Fri, 21 Sep 2001 16:42:19 +0200 Subject: [centr-dnr-forum] Re: Deletion of person objects. Final reminder In-Reply-To: Your message of "Fri, 21 Sep 2001 16:32:13 +0200." Message-ID: <200109211442.QAA19173@valinor.de.uu.net> The process of deletion itself is clear. I'm just wondering about the consequences of your statement. > Further to this deletion, and in order to avoid replication of the > current situation after this deletion process, incoming messages > containing person and role objects originating from domain name > related activities will NOT be processed. > > The RIPE NCC will contact any source of such messages in order to > clear any possible misunderstandings. Are you going to check if the data of a new requested handle were used before as a domainonly referenced handle ? Would you block that and we couldn't request a new handle with this specific data for an inetnum object ? regards, Andreas Wittkemper > If your "handle" is being used for IP registration our any IRR > related function, it will be referenced from an already existing > object in the RIPE Database and will therefore NOT be deleted. > > If your handle was only in use for domain (other that in-addr.arpa) > registration purposes, then your contact information should be > registered with the corresponding TLD administrator as it will be > deleted from the RIPE Database. > > No new handles are being created in this process as only handles used > for functions foreign to the RIPE Database will be deleted in the > process later today. > > Hopes this clarifies the situation for you, if not, please contact me. > > Regards, > Joao Damas > RIPE NCC > > At 16:01 +0200 21/9/01, Andreas Wittkemper wrote: > >Hi Joao, > > > > > >> Further to this deletion, and in order to avoid replication of the > >> current situation after this deletion process, incoming messages > >> containing person and role objects originating from domain name > >> related activities will NOT be processed. > >> > >> The RIPE NCC will contact any source of such messages in order to > >> clear any possible misunderstandings. > > > > > >Just for clarification. If a customer had a RIPE Handle which was > >needed for the domain adminc, we won't get a new handle which we'll > >use for a netassigment ? Considered that the old one would have been > >deleted by tomorrow latest. > > > >regards, > > > > Andreas Wittkemper > > > From andrei at ripe.net Sun Sep 23 13:10:19 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Sun, 23 Sep 2001 13:10:19 +0200 Subject: Deletion of person objects. Final reminder References: Message-ID: <3BADC31B.BB3612FC@ripe.net> Dear all, This is just to notify you that the removal of the set of person objects has finished successfully. Almost 3 million person objects have been deleted from the RIPE Database. It took a bit longer than we expected, but everything went without problems. Sorry for inconvenience this caused. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC Joao Luis Silva Damas wrote: > > Dear all, > > (apologies for duplicates) > > Today is the 21st of September. > > As such, the RIPE NCC will proceed to delete the set of person/role > objects detailed in my previous announcements from the RIPE Database. > Please see the URL > http://www.ripe.net/ripencc/pub-services/db/orphaned.html for > information on the details of the objects to be deleted. > > The following is an outline of the process we will be using: > > 1. Stop updating the database on Friday, 21, at 18:00 CEST. > 2. Remove all person objects according to the criteria: > - maintained _only_ by DE domain resellers and not referenced > - not maintained and not referenced > This will take ~15 hours > 3. Next day, on Saturday restart the server with the new database. > 4. Resume the updates. > > As you can see, this process will result in period of a few hours > during which UPDATE/ADDITION/DELETION messages sent to the RIPE > Database will not be processed immediately, but rather stored for > later processing. > > Queries will be serviced by our hot spare machine. Users will not > notice any downtime on that part of the service. > > The length of the outage is directly related to the number of objects > to be deleted (more than 2 million) and the need to use special > processes to finalise the process in a reasonable time. > > Further to this deletion, and in order to avoid replication of the > current situation after this deletion process, incoming messages > containing person and role objects originating from domain name > related activities will NOT be processed. > > The RIPE NCC will contact any source of such messages in order to > clear any possible misunderstandings. > > Hoping to have informed you well, > > Joao Luis Silva Damas > Chief Technical Officer > RIPE NCC From shane at ripe.net Wed Sep 19 17:39:23 2001 From: shane at ripe.net (Shane Kerr) Date: Wed, 19 Sep 2001 17:39:23 +0200 Subject: RIPE Whois Server version 3.0.2 Message-ID: <20010919173921.A341@x17.ripe.net> Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0.2 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release is intended both as a bug fix release, and also to offer much-improved ease of installation and configuration. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.0.2 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2-nocxref.tar.gz A patch for the 3.0.1 "nocxref" version is also available, if you already have that version, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.0.1-nocxref-3.0.2.gz If you have any more questions, please don't hesitate to contact . -- Shane Kerr RIPE NCC . From andrei at ripe.net Wed Sep 26 11:17:28 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 26 Sep 2001 11:17:28 +0200 Subject: Re-homing of RAToolSet to RIPE NCC Message-ID: <3BB19D28.ECE873F3@ripe.net> Dear Colleagues, [sorry for duplicate messages] Following Cengiz Alaettinoglu's message on this subject on the ratoolset at isi.edu mailing list (please find the original message attached below) it is our pleasure to announce that RAToolSet project has moved from ISI to the RIPE NCC. Starting from now the RIPE NCC will take on support and development of these tools. As a part of this move, RAToolSet will be called IRRToolSet. A new web page http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html and a mailing list irrtoolset at ripe.net have been established. We have subscribed all of the members of ratoolset at isi.edu to this mailing list. The original list will be phased out, but will forward any email to the new address. If you would like to subscribe to the IRRToolSet mailing list, put the line "subscribe irrtoolset" in the body of the message to add your address to the list, and send it to majordomo at ripe.net. We rely on your feedback and hope to provide the level of support you received from Cengiz and the ISI team. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC -------------- next part -------------- An embedded message was scrubbed... From: Cengiz Alaettinoglu Subject: RAToolSet is re-homing Date: 25 Sep 2001 21:42:14 -0700 Size: 3129 URL: From nurani at ripe.net Fri Sep 28 19:48:41 2001 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 28 Sep 2001 19:48:41 +0200 (CEST) Subject: LIR-PARTITIONED proposal (originally LIR-ALLOCATED) Message-ID: LIR-PARTITIONED PROPOSAL ------------------------ Following James Aldridge's proposal below, here follows an implementation proposal by the RIPE NCC for a new status value in the RIPE Database. Background ----------- This proposal (originally named "LIR-ALLOCATED"was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 January 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.html) The full final proposal (15 January 2001) by Aldridge can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.html At the RIPE 38 meeting,(22-26 January 2001), the RIPE NCC accepted the action to implement this proposal. Motivation (as expressed by James Aldridge) -------------------------------------------- "For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s)." Proposed Name ------------- RIPE NCC proposes to use the term: "LIR-PARTITIONED" ("LIR-PARTITIONED PA" and "LIR-PARTITIONED PI") rather than "LIR-ALLOCATED", to clarify the use of this added database feature. As "LIR-ALLOCATED" could be misinterpreted as a policy feature, we believe that "LIR-PARTITIONED" is a more suitable term, not involving policy terminology, but merely describing a partition of the LIR's allocation. Database Objects affected ------------------------- Only inetnum objects may have the "LIR-PARTITIONED" status value. Usage ----- The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of lower-level objects representing assignments within the address space specified by the inetnum object with the status "LIR-PARTITIONED PA" OR "LIR-PARTITIONED PI". Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules: - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file) - The value of "LIR-PARTIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA". - The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI". Additional clarification ------------------------ This proposal addresses the added inetnum status value as proposed by James Aldridge. This is strictly a database feature, allowing LIRs to delegate maintenance within their allocations in the RIPE Database. An implementation of this proposal would not affect IP address allocation policy. It would not change the responsibility LIRs have for allocations and assignments held by them. Furthermore, it would not change the manner in which the RIPE NCC verifies allocation utilisation. Timeline -------- Before RIPE 41, January 2002. ---------------- As explained above, this implementation proposal only relates to the proposal outlined in this mail. We welcome the feedback from the LIR-WG and the DB-WG on the "LIR-PARTITIONED" proposal. However, recent comments on the lir-wg mailing list have indicated a wish among some members of the community for a more extensive change, allowing LIRs to sub-allocate IPv4 address space to subsidiaries or downstream ISPs. Such a change would be a rather significant change in current IPv4 address allocation policy, as it has an impact on the LIR's responsibility for its address space as well as the manner in which the RIPE NCC would verify utilisation. If the general feeling in the community is that the "LIR-PARTITIONED" proposal does not cover the LIRs' need, but a more significant change to current IP allocation policy is necessary, then I propose that this be discussed in detail in the LIR-WG. Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------*