From syuval at netvision.net.il Sun Dec 5 08:14:59 1999 From: syuval at netvision.net.il (Yuval Shchory) Date: Sun, 5 Dec 1999 09:14:59 +0200 Subject: Resent: Allocating a LIR an IP block per use Message-ID: <6D3354FF177DD211A6B60000F87ADD9E014B86A1@ntx.netvision.net.il> Hi all, We would like to request another IP block from RIPE, regardless of our current allocation (which we use for our day-to-day assignments to customers), in order to assign from this block only to customers using BGP. I would not want to assign BGP customers from our regular blocks, as it would create a need to subnet the BGP advertisements on these blocks. We would like to have a block pre-intended for such fragmentation. However, as far as I recall RIPE's procedure, one can request another IP allocation only after a certain percentage (50% AFAIR) of his allocation has been assigned. So - am I the only person thinking this is the correct way to do that? Is it possible to request a block for such usage, regardless of the current allocation's usage? Regards, --- Yuval Shchory Projects Manager NetVision's Corporate Technical Support Department eMail: syuval at netvision.net.il interFAX: 03-5480255 --- From syuval at netvision.net.il Sun Dec 5 13:49:58 1999 From: syuval at netvision.net.il (Yuval Shchory) Date: Sun, 5 Dec 1999 14:49:58 +0200 Subject: Resent: Allocating a LIR an IP block per use Message-ID: <6D3354FF177DD211A6B60000F87ADD9E014B86A9@ntx.netvision.net.il> Yes. That is exactly what I would like to do, but the problem is that I can't receive new allocation from RIPE unless my current is used to its half. What I would like to do is receive a new, large PI for BGP use, so it won't be mixed with my aggregateable /16s. I will be more than happy to hear from RIPE how this can be done. It might be that all I have to do is send a 141 with a remark - FOR BGP CUSTS and that would be it, but I'm not really sure. Regards, --- Yuval Shchory Projects Manager NetVision's Corporate Technical Support Department eMail: syuval at netvision.net.il interFAX: 03-5480255 --- > -----Original Message----- > From: Jules D Salter [mailto:jules at vas-net.net] > Sent: Sunday, December 05, 1999 2:46 PM > To: Yuval Shchory; lir-wg at ripe.net > Subject: Re: Resent: Allocating a LIR an IP block per use > > > Yuval, > > You could apply for PI (Provider Independant) address space. > But you would still need to fill out a RIPE-141 outlining how > you intend to use the address space. The other problem with PI > space, is that a lot of the backbones don't like routing it unless > you have a fairly large aggregate. > > The issues are raised in http://www.ripe.net/docs/ripe-127.html > > Joolsie > > Yuval Shchory wrote: > > > > Hi all, > > > > We would like to request another IP block from RIPE, > regardless of our > > current allocation (which we use for our day-to-day assignments to > > customers), in order to assign from this block only to > customers using BGP. > > I would not want to assign BGP customers from our regular > blocks, as it > > would create a need to subnet the BGP advertisements on > these blocks. We > > would like to have a block pre-intended for such fragmentation. > > > > However, as far as I recall RIPE's procedure, one can > request another IP > > allocation only after a certain percentage (50% AFAIR) of > his allocation has > > been assigned. > > > > So - am I the only person thinking this is the correct way > to do that? Is it > > possible to request a block for such usage, regardless of > the current > > allocation's usage? > > > > Regards, > > > > --- > > Yuval Shchory > > Projects Manager > > NetVision's Corporate Technical Support Department > > eMail: syuval at netvision.net.il > > interFAX: 03-5480255 > > --- > From sam at internext.fr Sun Dec 5 10:37:08 1999 From: sam at internext.fr (samir Koleilat) Date: Sun, 05 Dec 1999 10:37:08 +0100 Subject: Resent: Allocating a LIR an IP block per use References: <6D3354FF177DD211A6B60000F87ADD9E014B86A1@ntx.netvision.net.il> Message-ID: <384A3244.B6B97223@internext.fr> Bonjour, No you'r not the only one in this case, we have customers with AS number and we are ambarrassed they do not announce there IP because it's icluded in our total agregate IP space, we will be very happy to obtain 2 to 4 ( \23 or \22) for each of them according to there needs, maybe RIPE should help us to find a solution about this situation. Regards Yuval Shchory wrote: > > Hi all, > > We would like to request another IP block from RIPE, regardless of our > current allocation (which we use for our day-to-day assignments to > customers), in order to assign from this block only to customers using BGP. > I would not want to assign BGP customers from our regular blocks, as it > would create a need to subnet the BGP advertisements on these blocks. We > would like to have a block pre-intended for such fragmentation. > > However, as far as I recall RIPE's procedure, one can request another IP > allocation only after a certain percentage (50% AFAIR) of his allocation has > been assigned. > > So - am I the only person thinking this is the correct way to do that? Is it > possible to request a block for such usage, regardless of the current > allocation's usage? > > Regards, > > --- > Yuval Shchory > Projects Manager > NetVision's Corporate Technical Support Department > eMail: syuval at netvision.net.il > interFAX: 03-5480255 > --- -- Samir Koleilat InterneXt 54 Boulevard du Colonel Fabien 94200 Ivry sur SEINE + 33 1 45 15 14 50 http://www.internext.fr From jules at vas-net.net Sun Dec 5 13:45:56 1999 From: jules at vas-net.net (Jules D Salter) Date: Sun, 05 Dec 1999 12:45:56 +0000 Subject: Resent: Allocating a LIR an IP block per use References: <6D3354FF177DD211A6B60000F87ADD9E014B86A1@ntx.netvision.net.il> Message-ID: <384A5E84.7312D834@vas-net.net> Yuval, You could apply for PI (Provider Independant) address space. But you would still need to fill out a RIPE-141 outlining how you intend to use the address space. The other problem with PI space, is that a lot of the backbones don't like routing it unless you have a fairly large aggregate. The issues are raised in http://www.ripe.net/docs/ripe-127.html Joolsie Yuval Shchory wrote: > > Hi all, > > We would like to request another IP block from RIPE, regardless of our > current allocation (which we use for our day-to-day assignments to > customers), in order to assign from this block only to customers using BGP. > I would not want to assign BGP customers from our regular blocks, as it > would create a need to subnet the BGP advertisements on these blocks. We > would like to have a block pre-intended for such fragmentation. > > However, as far as I recall RIPE's procedure, one can request another IP > allocation only after a certain percentage (50% AFAIR) of his allocation has > been assigned. > > So - am I the only person thinking this is the correct way to do that? Is it > possible to request a block for such usage, regardless of the current > allocation's usage? > > Regards, > > --- > Yuval Shchory > Projects Manager > NetVision's Corporate Technical Support Department > eMail: syuval at netvision.net.il > interFAX: 03-5480255 > --- From robert-spam99 at ircnet.dk Sun Dec 5 16:41:32 1999 From: robert-spam99 at ircnet.dk (=?ISO-8859-1?Q?Robert_Martin-Leg=E8ne?=) Date: Sun, 5 Dec 1999 16:41:32 +0100 (CET) Subject: Resent: Allocating a LIR an IP block per use In-Reply-To: <6D3354FF177DD211A6B60000F87ADD9E014B86A9@ntx.netvision.net.il> Message-ID: On Sun, 5 Dec 1999, Yuval Shchory wrote: > What I would like to do is receive a new, large PI for BGP use, so it won't > be mixed with my aggregateable /16s. I will be more than happy to hear from > RIPE how this can be done. It might be that all I have to do is send a 141 > with a remark - FOR BGP CUSTS and that would be it, but I'm not really sure. You will not get your own block. RIPE has some PI address space that they give from. You will have to request RIPE directly, on behalf of your customer. But it has some disadvantages to use PI address space. Read the document that Jules referred to. -- Robert Martin-Leg?ne Hi! I'm a .signature virus! Copy me into your .signature to help me spread! From ula at ripn.net Mon Dec 6 10:02:58 1999 From: ula at ripn.net (Larisa A. Yurkina) Date: Mon, 6 Dec 1999 12:02:58 +0300 (MSK) Subject: Resent: Allocating a LIR an IP block per use In-Reply-To: <6D3354FF177DD211A6B60000F87ADD9E014B86A9@ntx.netvision.net.il> Message-ID: On Sun, 5 Dec 1999, Yuval Shchory wrote: > Yes. That is exactly what I would like to do, but the problem is that I > can't receive new allocation from RIPE unless my current is used to its > half. > > What I would like to do is receive a new, large PI for BGP use, so it won't > be mixed with my aggregateable /16s. I will be more than happy to hear from > RIPE how this can be done. It might be that all I have to do is send a 141 > with a remark - FOR BGP CUSTS and that would be it, but I'm not really sure. > Hi Yuval, just send ripe-141 status PI and see what happehs ;) But, try to avoide thinking about large PI block, you are going to get as large assignement as your customer really needs. Otherwise they would be proposed to become an LIR. Besides it would be better to give detailed explanation why PI is the only way for your customer in their situation. With respect, Larisa Yurkina --- RIPN Registry center ----- > > > > > Regards, > > --- > Yuval Shchory > Projects Manager > NetVision's Corporate Technical Support Department > eMail: syuval at netvision.net.il > interFAX: 03-5480255 > --- > > > > > -----Original Message----- > > From: Jules D Salter [mailto:jules at vas-net.net] > > Sent: Sunday, December 05, 1999 2:46 PM > > To: Yuval Shchory; lir-wg at ripe.net > > Subject: Re: Resent: Allocating a LIR an IP block per use > > > > > > Yuval, > > > > You could apply for PI (Provider Independant) address space. > > But you would still need to fill out a RIPE-141 outlining how > > you intend to use the address space. The other problem with PI > > space, is that a lot of the backbones don't like routing it unless > > you have a fairly large aggregate. > > > > The issues are raised in http://www.ripe.net/docs/ripe-127.html > > > > Joolsie > > > > Yuval Shchory wrote: > > > > > > Hi all, > > > > > > We would like to request another IP block from RIPE, > > regardless of our > > > current allocation (which we use for our day-to-day assignments to > > > customers), in order to assign from this block only to > > customers using BGP. > > > I would not want to assign BGP customers from our regular > > blocks, as it > > > would create a need to subnet the BGP advertisements on > > these blocks. We > > > would like to have a block pre-intended for such fragmentation. > > > > > > However, as far as I recall RIPE's procedure, one can > > request another IP > > > allocation only after a certain percentage (50% AFAIR) of > > his allocation has > > > been assigned. > > > > > > So - am I the only person thinking this is the correct way > > to do that? Is it > > > possible to request a block for such usage, regardless of > > the current > > > allocation's usage? > > > > > > Regards, > > > > > > --- > > > Yuval Shchory > > > Projects Manager > > > NetVision's Corporate Technical Support Department > > > eMail: syuval at netvision.net.il > > > interFAX: 03-5480255 > > > --- > > > From beri at EU.net Mon Dec 6 11:06:42 1999 From: beri at EU.net (Berislav Todorovic) Date: Mon, 6 Dec 1999 11:06:42 +0100 (CET) Subject: Resent: Allocating a LIR an IP block per use In-Reply-To: <384A3244.B6B97223@internext.fr> Message-ID: On Sun, 5 Dec 1999, samir Koleilat wrote: >> No you'r not the only one in this case, we have customers with AS >> number and we are ambarrassed they do not announce there IP because it's >> icluded in our total agregate IP space, we will be very happy to obtain >> 2 to 4 ( \23 or \22) for each of them according to there needs, maybe >> RIPE should help us to find a solution about this situation. Many small ISPs, sooner or later, want to become multi-homed and they meet with that problem. All of them usually want to run BGP even if they are assigned a small portion of address space. On the other hand, huge ISPs (e.g. Sprint) use to filter BGP announcements for prefix longer than a certain value (usually /19 or /20). Therefore, such multi-homed customers can have serious connectivity problems. The best approach for small BGP customers is to use NAT. See the slides on that at http://www.ietf.org/proceedings/98dec/slides/nat-multihome-98dec/. Regards, Beri -- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5333; Fax: (+3120) 622-4657 - --- Email: beri at EU.net From lmb at teuto.net Mon Dec 6 12:20:57 1999 From: lmb at teuto.net (Lars Marowsky-Bree) Date: Mon, 6 Dec 1999 12:20:57 +0100 Subject: Resent: Allocating a LIR an IP block per use In-Reply-To: ; from "Berislav Todorovic" on 1999-12-06T11:06:42 References: <384A3244.B6B97223@internext.fr> Message-ID: <19991206122057.C28179@pointer.teuto.de> On 1999-12-06T11:06:42, Berislav Todorovic said: > The best approach for small BGP customers is to use NAT. See the slides on > that at http://www.ietf.org/proceedings/98dec/slides/nat-multihome-98dec/. Which is a (serious?) waste of address space, since it requires at least two times the same assignment. On the other hand, it saves one ASN and one potential new buggy AS is kept away from the BGP4, so it probably evens out. On the other hand, NAT _is_ a _kludge_ for multihoming. But the ISP who really thinks his customer needs his own AS and is capable of setting it up (or having it setup for them) is probably also able to convince RIPE NCC they need PI... Sincerely, Lars Marowsky-Brie -- Lars Marowsky-Brie Network Management teuto.net Netzdienste GmbH From beri at EU.net Mon Dec 6 12:54:09 1999 From: beri at EU.net (Berislav Todorovic) Date: Mon, 6 Dec 1999 12:54:09 +0100 (CET) Subject: Resent: Allocating a LIR an IP block per use In-Reply-To: <19991206122057.C28179@pointer.teuto.de> Message-ID: On Mon, 6 Dec 1999, Lars Marowsky-Bree wrote: >> Which is a (serious?) waste of address space, since it requires at least two >> times the same assignment. On the other hand, it saves one ASN and one >> potential new buggy AS is kept away from the BGP4, so it probably evens out. Agree with that part, though everything depends on NAT implementation (the possibility of address reusage) and the size of the customer network. And yes - it doesn't provide all the benefits that BGP does. On the other hand, convincing RIPE NCC to provide PI addresses might even be much easier than convincing Sprint to remove their filters for such customer networks. The main reason Sprint uses to filter BGP announcments on /19 is the size of the routing table and a large amount of updates for small networks. Regards, Beri -- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5333; Fax: (+3120) 622-4657 - --- Email: beri at EU.net From syuval at netvision.net.il Mon Dec 6 15:21:57 1999 From: syuval at netvision.net.il (Yuval Shchory) Date: Mon, 6 Dec 1999 16:21:57 +0200 Subject: Resent: Allocating a LIR an IP block per use Message-ID: <6D3354FF177DD211A6B60000F87ADD9E014B86C2@ntx.netvision.net.il> Sorry to get everyone back to the course (well, the course I want to go through.... :-) - but my questions was not whether or not a small ISP / content provider should implement BGP. The issue is that currently I can't take part of my PI, which I divide into small PAs for my customers, and use it for PIs for my customers. However, I would like to have my own PI specially intended for fragmentation to PIs, not to PAs. The reason to difrentiate is that the net-work is diferent here. The maintenance is diferent (I don't really advertise the addresses using my AS, though I'm a transient for these addresses). If I'll have a larger block, it would be easier to maintain, easier to troubleshoot. Yes, I do understand that the issue these days is conservation. And yes, it is understood that our last allocation is not 80% assigned. However, we cannot take our last /16 and create smaller CIDRs! We think it is wise to diferentiate our BGP customers from our regular customers - and the differ would they be - the better. The best differentiation is provide the BGP customers with a diferent block. I'm sorry to add here the business issues, but I believe that a large chunk of the LIRs are ISPs, so some of them might find it interesting. Regards, --- Yuval Shchory Projects Manager NetVision's Corporate Technical Support Department eMail: syuval at netvision.net.il interFAX: 03-5480255 --- From stephenb at uk.uu.net Wed Dec 8 11:18:14 1999 From: stephenb at uk.uu.net (stephenb at uk.uu.net) Date: Wed, 8 Dec 1999 10:18:14 +0000 (GMT) Subject: No subject Message-ID: <199912081028.LAA23811@birch.ripe.net> A quick question does anyone have or know of any tools for checking for overlaps in the RIPE DB for a given range of addreses? -- ---------------------------------- E-Mail: stephenb at uk.uu.net Phone: +44 (0)1223 581051 Stephen Burley EMEA Registrar UUNET ---------------------------------- From beri at EU.net Wed Dec 8 12:12:15 1999 From: beri at EU.net (Berislav Todorovic) Date: Wed, 8 Dec 1999 12:12:15 +0100 (CET) Subject: your mail In-Reply-To: <199912081028.LAA23811@birch.ripe.net> Message-ID: On Wed, 8 Dec 1999 stephenb at uk.uu.net wrote: >> A quick question does anyone have or know of any tools for checking for >> overlaps in the RIPE DB for a given range of addreses? Well, I don't know of any tool that would provide a straightforward solution, but a script can be written to parse the output of the command (RIPE Whois client needed): "whois -M prefix/length | grep inetnum" and return all overlaps found. The script isn't so difficult to make. Regards, Beri -- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5333; Fax: (+3120) 622-4657 - --- Email: beri at EU.net From Denesh.Bhabuta at Level3.com Wed Dec 8 12:33:58 1999 From: Denesh.Bhabuta at Level3.com (Bhabuta, Denesh) Date: Wed, 8 Dec 1999 11:33:58 -0000 Subject: Message-ID: <6FA15EC018C1D211AA4C0008C70D033002C89D5F@l3londmail02.eu.l3.com> > A quick question does anyone have or know of any tools for > checking for > overlaps in the RIPE DB for a given range of addreses? The tool is called email. Send a request to RIPE and they will only be too happy to use their auditing software to send you the details of overlapping objects. :) Regards Denesh -- Denesh Bhabuta, AMISM European Internet Services Group Level (3) Communications Limited +44-20-7864-0498 ; denesh.bhabuta at level3.com From ripe-dbm at ripe.net Wed Dec 8 14:47:26 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Wed, 08 Dec 1999 14:47:26 +0100 Subject: No subject In-Reply-To: Your message of Wed, 08 Dec 1999 10:18:14 GMT. <199912081028.LAA23811@birch.ripe.net> References: <199912081028.LAA23811@birch.ripe.net> Message-ID: <199912081347.OAA03135@birch.ripe.net> Hi, As far as the RIPE NCC goes, our Hostmasters have a tool like that but it is dependent on our working environment, so it won't work outside the NCC. Please contact them and they will check the range(s) you are interested in. Regards, Marek Bukowy ____________________________ RIPE Database Administration. stephenb at uk.uu.net writes: * A quick question does anyone have or know of any tools for checking for * overlaps in the RIPE DB for a given range of addreses? * -- * ---------------------------------- * E-Mail: stephenb at uk.uu.net * Phone: +44 (0)1223 581051 * * * Stephen Burley * EMEA Registrar UUNET * ---------------------------------- * * From ripe-dbm at ripe.net Wed Dec 8 19:24:32 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Wed, 08 Dec 1999 19:24:32 +0100 Subject: Top 100 Maintainers List 19991208 Message-ID: <199912081824.TAA22936@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 XLINK-MNT 40675 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html 2 DENIC-P 39578 http://www.ripe.net/db/state/maintainers/DENIC-P.html 3 DK-DOMREG 7351 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html 4 ROKA-P 3058 http://www.ripe.net/db/state/maintainers/ROKA-P.html 5 DTAG-NIC 2938 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html 6 FR-NIC-MNT 2213 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html 7 SCHLUND-P 1740 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html 8 BO-DOMREG 1596 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html 9 ECCE-NOC 1562 http://www.ripe.net/db/state/maintainers/ECCE-NOC.html 10 NACAMAR-NOC 1508 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html 11 WWW-MNT 1275 http://www.ripe.net/db/state/maintainers/WWW-MNT.html 12 DREIMARK49-MNT 1125 http://www.ripe.net/db/state/maintainers/DREIMARK49-MNT.html 13 DENIC-N 1046 http://www.ripe.net/db/state/maintainers/DENIC-N.html 14 ABCAG-MNT 974 http://www.ripe.net/db/state/maintainers/ABCAG-MNT.html 15 AS1849-MNT 734 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html 16 HIGHSPEED-DOM 669 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html 17 ECORE-NET 642 http://www.ripe.net/db/state/maintainers/ECORE-NET.html 18 INTERNET-NOC 619 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html 19 SEKTORNET-MNT 570 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html 20 CSL-MNT 551 http://www.ripe.net/db/state/maintainers/CSL-MNT.html 21 DFN-NTFY 536 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html 22 DKNET-MNT 524 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html 23 NACAMAR-RES 478 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html 24 OLEANE-NOC 425 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html 25 DE-VOSS 416 http://www.ripe.net/db/state/maintainers/DE-VOSS.html 26 SDT-NOC 415 http://www.ripe.net/db/state/maintainers/SDT-NOC.html 27 GLOBAL-MNT 407 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html 28 TDK-MNT 384 http://www.ripe.net/db/state/maintainers/TDK-MNT.html 29 DIGITALWEB-MNT 371 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html 30 NACAMAR-POP 351 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html 31 IDNET-MNT 350 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html 32 RAIN-TRANSPAC 343 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html 33 IL-P 340 http://www.ripe.net/db/state/maintainers/IL-P.html 34 AS6678-MNT 332 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html 35 KNIPP-NOC-MNT 332 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html 36 AS1267-MNT 328 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html 37 RAK-NET 322 http://www.ripe.net/db/state/maintainers/RAK-NET.html 38 WESPE-MNT 319 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html 39 MARIDAN-P 317 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html 40 INX-MNT 308 http://www.ripe.net/db/state/maintainers/INX-MNT.html 41 NETCOLOGNE-MNT 302 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html 42 FR-EASYNET 296 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html 43 SL-CUS-MNT 273 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html 44 GIGABELL-MNT 272 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html 45 AS3233-MNT 270 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html 46 AS5617-MNT 270 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html 47 FREENAME-NOC 263 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html 48 AS1717-MNT 248 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html 49 TRMD-MNT 240 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html 50 EUROCONNECT 231 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html 51 MBT-MNT 227 http://www.ripe.net/db/state/maintainers/MBT-MNT.html 52 IMAGINET-NOC-MNT 224 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm 53 AS5427-MNT 219 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html 54 AS2120-MNT 211 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html 55 IBGNET 210 http://www.ripe.net/db/state/maintainers/IBGNET.html 56 IWAY-NOC 203 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html 57 NDH-P 202 http://www.ripe.net/db/state/maintainers/NDH-P.html 58 AS5378-MNT 200 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html 59 SKYNETBE-MNT 185 http://www.ripe.net/db/state/maintainers/SKYNETBE-MNT.html 60 AS2529-MNT 184 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html 61 NETTUNO 183 http://www.ripe.net/db/state/maintainers/NETTUNO.html 62 PRHO-GUARDIAN 179 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html 63 IT-NIC 177 http://www.ripe.net/db/state/maintainers/IT-NIC.html 64 ONE2ONE-MNT 177 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html 65 ROM-MIKNET 177 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html 66 EU-IBM-NIC-MNT2 171 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html 67 AS1241-MNT 167 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html 68 AS1899-MNT 166 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html 69 AS2871-MNT 147 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html 70 OMNILINK-MNT 147 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html 71 AS5551-MNT 141 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html 72 PSINET-UK-SYSADMIN 137 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h 73 ISTLD-MNT 134 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html 74 AS6721-MNT 132 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html 75 NNCC 131 http://www.ripe.net/db/state/maintainers/NNCC.html 76 DK-NIC 128 http://www.ripe.net/db/state/maintainers/DK-NIC.html 77 EVOSYS-MNT 121 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html 78 AS3292-MNT 115 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html 79 KDT-MNT 114 http://www.ripe.net/db/state/maintainers/KDT-MNT.html 80 SEICOM-MNT 114 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html 81 ISMA-MNT 113 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html 82 DNSNET-MNT 109 http://www.ripe.net/db/state/maintainers/DNSNET-MNT.html 83 ICMS-NOC-MAINTAINER 103 http://www.ripe.net/db/state/maintainers/ICMS-NOC-MAINTAINER. 84 ISB-MNT 103 http://www.ripe.net/db/state/maintainers/ISB-MNT.html 85 INETWIRE-MNT 101 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html 86 ROSNIIROS-MNT 101 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html 87 COMMPLEX-MNT 100 http://www.ripe.net/db/state/maintainers/COMMPLEX-MNT.html 88 MDA-Z 99 http://www.ripe.net/db/state/maintainers/MDA-Z.html 89 ODN-MNT 98 http://www.ripe.net/db/state/maintainers/ODN-MNT.html 90 PROFI-MNT 95 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html 91 ITNET-MNT 92 http://www.ripe.net/db/state/maintainers/ITNET-MNT.html 92 AS8875-MNT 88 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html 93 WEB4YOU-MNT 85 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html 94 SPACENET-P 84 http://www.ripe.net/db/state/maintainers/SPACENET-P.html 95 MAINT-AS3352 83 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html 96 TINET-NOC 83 http://www.ripe.net/db/state/maintainers/TINET-NOC.html 97 GARR-LIR 78 http://www.ripe.net/db/state/maintainers/GARR-LIR.html 98 CU-MNT 77 http://www.ripe.net/db/state/maintainers/CU-MNT.html 99 JIPS-NOSC 77 http://www.ripe.net/db/state/maintainers/JIPS-NOSC.html 100 OMC1-RIPE-MNT 77 http://www.ripe.net/db/state/maintainers/OMC1-RIPE-MNT.html From hank at att.net.il Wed Dec 8 11:47:09 1999 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 08 Dec 1999 12:47:09 +0200 Subject: In-Reply-To: <199912081028.LAA23811@birch.ripe.net> Message-ID: <3.0.5.32.19991208124709.007cac60@max.ibm.net.il> At 10:18 08/12/99 +0000, stephenb at uk.uu.net wrote: I use whois -R -m n.n.n.n/16 and then scan the overlaps. There may be better ways. -Hank >A quick question does anyone have or know of any tools for checking for >overlaps in the RIPE DB for a given range of addreses? >-- >---------------------------------- >E-Mail: stephenb at uk.uu.net >Phone: +44 (0)1223 581051 > > >Stephen Burley >EMEA Registrar UUNET >---------------------------------- > > From nurani at ripe.net Thu Dec 16 16:42:48 1999 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 16 Dec 1999 16:42:48 +0100 Subject: IP assignment for virtual webhosting Message-ID: <199912161542.QAA23600@x7.ripe.net> Dear LIR working group, We wish to thank you all for your constructive participation in the discussion regarding IP assignment for virtual webhosting. Your input has been valuable and contributive and we believe we now have a clear picture of the various views within the RIPE community. We will now, with your feedback, initiate a discussion with the other Regional Registries, ARIN and APNIC and will share the outcome with you as soon as some conclusions can be drawn. Thank you again for your participation. Kind regards, Nurani Nimpuno Registration Service Manager RIPE NCC From hph at sys.sol.no Sun Dec 19 21:10:23 1999 From: hph at sys.sol.no (Hans Petter Holen) Date: Sun, 19 Dec 1999 21:10:23 +0100 Subject: RIPE 34 LIR WG Draft Minutes 1.2 References: <199910111513.RAA17053@stovner.sys.sol.no> Message-ID: <002501bf4a5d$2e05a8c0$e406e1c3@dont.no> Hi, I have, hopefully, added the comments I got to version 1.0 of the draft minutes. Hans Petter Holen LIR WG Chair ----- RIPE 34 LIR-WG Minutes 1.2 Chair: Hans Petter Holen Scribe: Eamonn McGuiness Agenda 1. Admin scribe distribute participants list charter mailing lists 2. Additional agenda points 3. Introduction of the new Registration Service Manager, Nurani Nimpuno Meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Regional Internet Registries 6. The RIPE community policy making process (Mirjam Kuhne, RIPE NCC) Discussion: Is this well understood? 7. ICANN - ASO Current status, further work. Definition of the selection procedure for the address council 8. Auditing Results and experiences (Mirjam Kuhne, RIPE NCC) 9. Discuss an additonal value for inetnum status attribute (James Aldridge, EUnet) 10. PGP authentication of e-mails to and from hostmaster at ripe.net (Maldwyn Morris, RIPE NCC) 11. Release of rtt source code (Maldwyn Morris, RIPE NCC) 12. AOB 12.1 IPv6 policy matters (move to LIR WG?) 12.2 mnt-by from mandatory to optional (Wilfried Woeber, ACONET) 12.3 PI address assignments to end-users (Yuval Shchory, Netvision Ltd.) 12.4 DB support for multiple Domain objects 1. Admin Eamonn McGuiness volunteered to take notes. The participant list was circulated and signed by approximately 89 attendees. The Working group web pages and mailing list were pointed at: Mailing list: lir-wg at ripe.net Archive: http://www.ripe.net/mail-archives/lir-wg/index.html Web pages: http://www.ripe.net/wg/lir/index.html >From the web pages the following description of the woring group can be found: The Local IR working group deals with issues that concern Local Internet Registries. For example, Local IR operation, and the local implementation of RIPE policies and procedures are discussed here. There was consensus that we may need a better formulated charter stating that the LIR-WG is the open forum where RIPE policy is made. ACTION LIR-34.1 on Chair to suggest clarification of WG charter. 2. Agenda The agenda previously circulated to the lir-wg list, was approved and the following items were added to Any Other Business: Wilfried Woeber: RIPE NCC Auditing Activity Yuval Shchory: PI Assignments 3. Presentation of RIPE Hostmasters The new Registration Services Manager Nurani Nimpuno was introduced. Paula Caslav left the RIPE NCC to go back to the US. Also all hostmasters present at the meeting were introduced to the audience. 4. Actions All actions from RIPE 32 were done before RIPE 33. There were no additional action points from RIPE 33. The WG minutes (published as part of the plenary minutes) from RIPE 32 were approved. 5. Reports from the Regional Internet Registries 5.1. Report from the RIPE NCC Registration Services Activities (Mirjam Kuhne) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Some highlights of the developments since the last meeting: Beginning of the year almost 2 new members per calendar day. This has now slowed down, but is still higher than the last few years, approximately 1.5 new members per calendar day. Those new members tend to grow slower than members used to in the past. This means that the workload is not increasing proportionally to the number of new members. Due to automation and efficient procedures, there was no major staff increase even though the number of new members has grown. The RIPE NCC has started allocating IPv6 addresses, 6 sub-TLAs allocated so far, smooth start. The RIPE NCC proposes to change the procedures for reverse delegation such that only members can submit requests for reverse delegation. This would decrease the workload of the RIPE NCC and increase the quality of the DNS. This issue will further be discussed on the lir-wg mailing list to understand all aspects of such a change. This item was added to AOB for further discussion but due to time shortage it was concluded with the following action: ACTION LIR-34.2 on RIPE NCC to start discussion on changing the reverse delegation policies, and make sure all aspects of it are fully understood. The RIPE NCC is currently busy updating and improving the LIR Training Course material and delivery. This will be ready before the next RIPE Meeting. A few questions were raised after the presentation: Q: Is there a deadline for the change in procedure for reverse delegation? A: Before the end of the year: We are currently re-writing the inaddr robot and would like to implement this change at the same time. Comment: We need to think about the implications for address space originally assigned by last resort registries. Q: Test Traffic Measurement will be part of membership services in 2000. How will the RIPE NCC charge for it? A: It will be a different type of membership service than registration services, because the users are not necessarily the same. We are slowly moving TTM in this direction and need to further investigate an exact charging scheme for it. Q: Are all statistics shown during the presentation also visible on the web site and are they kept up to date? A: They will be stored on the web site as part of the presentation, but we will also put them on the statistics pages. ACTION LIR-34.3 RIPE NCC: store statistics on web site and keep them up to date. Q: Can we get support from the RIPE NCC for addresses that have been assigned by the InterNIC? A: Yes, you can, we currently provide administrative support for our members. We are also working on a more structural solution, so that the assignments are stored in the DB of the region the network is operated in, even if the addresses have been originally assigned by the InterNIC. We will also work together on a technical solution for a distributed reverse delegation. 5.2. Report from the APNIC (Kyoko Day) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Some highlights: IP distribution is growing in the region even though there was a dip due to the economic crisis in Asia. The growth during this year is mainly due growth in India and Australia. Priorities for the next period: review of the APNIC membership-charging scheme. Currently the categories Small, Medium, Large are self-determined (like the RIPE NCC charging scheme was before 1997). 5.3. Report from ARIN Unfortunately no one from ARIN could attend the Meeting. Mirjam Kuhne announces that ARIN will hold their AGM in October in conjunction with a first open policy meeting and the second meeting of ARIN WGs (18.10. - 20.10.1999) 5.4. Reports from other regions At the ICANN Meeting in Santiago in August ICANN welcomed the developments in Africa and Latin America. In Latin America various groups have been co-operating and form the LatinNIC, they proposed a draft paper, which they asked the existing RIRs to review. The Interim Board of the AfriNIC is currently reviewing proposals of potential AfriNIC hosts. 6. Policy Development in the RIPE community Mirjam Kuhne gave a presentation to describe how policy is developed in this region and how people can participate in this process. See http://www.ripe.net/meetings/ripe/ripe-34/pres/ for details. The process is simple, open to anyone and based on consensus. After Mirjams presentation, Hans Petter asked wether the WG felt that the process was open enough or if it needed to be changed to make it more open. Mark McFadden from CIX explicitely stated that the processes in RIPE are truely open and do not need to change. The WG Participants were in agreement that these are true open processes and that there is no need to change them. During the discussion that followed it became apparent that more effort must be spent to make the existence of RIPE known to the outside world and to clearly distinguish it from the RIPE NCC. A comment was made that the RIPE community and the RIPE NCC membership is mainly comprised of small ISPs and that the policies and guidelines are sometimes difficult to be implemented by larger ISPs. Hans Petter understands the concern, but has experienced that difficult or unusual cases were handled on a case by case bases usually solved in the end. The question was raised if there is a voting procedure to finalise agreements and policies? Hans Petter clarifies that there is normally general agreement and a voting procedure was not necessary. Someone thinks that people might be intimidated to speak up on the mailing list and that LIRs in particular might be afraid that their performance as LIR will be questions if they raise their opinion on the mailing list. Mirjam clarifies that the RIPE WG mailing lists are open and independent and not directly linked with the operations of the RIPE NCC and individual members. Maybe this needs to be made known more widely. ACTION LIR-34.4 on the Chair to form a Task Force to document and publish the current procedures for policy development. Volunteers to this task force were to contact the chair after the meeting. Further process will be: - announce the charter of the task force to the mailinglist - Interested parties may volunteer - A draft will be posted to lir-wg for discussion - A second draft will be based on that discussion - The document will be endorsed by consensus at RIPE 35 The outcome of this task force will be useful not only to the working group members but also externally to promote the openness of RIPE. 7. ICANN - ASO The LIR-WG needs to discuss and define the selection procedure for the RIPE region nominees of the ASO Address Council. The WG chair had asked Rob Blokzijl, the chair of RIPE, to chair this part of the discussion because the WG chair was among the nominees for the Address Council. This is the first time the RIPE community needs to define a procedure to select representatives to external bodies. This task is particularly difficult, because ICANN has introduced some time pressure: They would like to have ICANN directors elected by the beginning of October. As the ICANN directors are to be selected by the address council the address council needs to be selected at this very RIPE meeting. Therefor the carefully defined time schedules and deadline for the set up of the Address Council and the selection of the ICANN directors can not be followed. The RIPE community therefor needs to define an interim procedure for the initial set of Address Council members. In the time before the next RIPE meting the procedure needs to be revisited and refined. Each candidate submitted a paragraph to motivate why they think they are suitable for the Address Council. This has been made available on the RIPE Web pages and copied and distributed among the audience. 3 of the 8 nominees were present at the LIR-WG meeting. There was a discussion if the initial candidates should only serve one year or if they should be prepared to serve 1, 2 and 3 years as defined in the ASO MoU. The audience agrees that it would create instability if all members would change after one year and that they should serve 1, 2 and 3 years respectively. It was suggested that the address council at their own discretion may ask their seat to be reconfirmed by the procedures yet to be defined. This Q: Why was self-nomination was allowed. A: It is an open process, if a person believes he or she is a suitable candidate, why should he or she not nominate him or herself? Q: Can't we use the same procedure that is used for the RIPE NCC executive board? A: The problem is that the RIPE NCC membership is a clearly defined electorate, but in this case the electorate can not clearly be identified. The audience dismissed an e-mail selection process for many reasons. One was the time frame forced upon us, other being the too difficulty to verify correct votes. An attempt was made to find general criteria in order to make a possible pre-selection. Finally it was suggested to organise an open ballot at the plenary session. Gordon Lennox from DG-XIII, European Commission warned the WG not to fall into the trap of pure voting. He admires the open and transparent processes in the RIPE community and urges the audience to make sure to have some sort of consensus decision incorporated in the procedure, either before the voting or after to endorse the decision. ACTION LIR-34.5 on Rob Blokzijl to summarise this discussion and present it at the plenary session the following day. Several ideas for the final procedures were suggested: to look at USENET voting, the IETF procedures and the RIPE NCC Association procedures. These will be further discussed on the lir-wg list. ACTION LIR-34.6 on the Chair to form at task force to define final Address council selection procedure. 8. Auditing Activity at the RIPE NCC (Mirjam Kuhne) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Mirjam clarifies that this activity has been initiated by the LIR-WG in order to ensure fair distribution of address space. She shows statistics that have been derived after having performed this activity for more than a year now. In summary it can be noted that many LIRs are familiar with policies and procedures and apply them. One area of attention is the RIPE database. The RIPE NCC works together with LIRs to maintain and update the information in the database. There was some uncertainty regarding the role of the RIPE NCC member in this process. It was not clear to some attendees if the information provided by the end-user can or needs to be amended before passing on to the RIPE NCC. This is specifically related to documentation, which is provided in local language. After a short discussion it has been agreed that the RIPE NCC requires a certain set of documentation in English. It then depends on the service the LIR provides to their customers. Some LIRs may require their customers to provide the full set of documentation and in English, some LIR may just collect information from their customers (in the local language) and then amend and translate it if sent on to the RIPE NCC. ACTION LIR-34.7 on the RIPE NCC to document the audit procedure in more detail and to clarify the role of the NCC and the member during an audit process and what is expected from each party. 9. Additional value for the status attribute (James Aldridge) James suggests allowing for more hierarchy in the status attribute of the inetnum object. The rationale behind this is to allow "sub allocating" parts of a LIRs address blocks to "sub LIRs". This is important to large (multi national) ISPs. Also Wilfried Woeber is looking for additional values to indicate for instance returned address space that needs to be documented during transition to new. ACTION LIR-34.8 on James (and Wilfried) to write up a proposal and send it to the LIR-WG mailing list. 10. PGP authentication of mails to and from hostmaster at ripe.net (Maldwyn Morris, Software Manager RIPE NCC) The RIPE NCC would like to offer PGP authentication for mail sent to the hostmaster at ripe.net. In the first instance this will only be used for authentication, not for encryption. There is consensus in the WG that this would be a useful service. As other security mechanisms (e.g. in the RIPE DB) this will not be a requirement but optional. ACTION LIR-34.9 on RIPE NCC to proceed with plans to implement PGP as an option for hostmaster communication. 11. Release of rtt source code (Maldwyn Morris, Software Manager RIPE NCC) There is consensus in the LIR WG that the RIPE NCC may publish the source code of the rtt ticketing system software. ACTION LIR-34.10 on RIPE NCC Release source code to rtt due to demand. 12. Any Other Business 12.1 IPv6 policy matters In principle all address policy related matters should be handled in the LIR-WG. For this meeting the chair had decided not to include Ipv6 policy matters on the agenda, since the agenda already had possibly time-consuming items already. It was argued that participants interested in developing RIPE policy only should have to go to one working group. The chair agrees in principle, but also sees the advantages of keeping the policy discussions in the Ipv6 WG where Ipv6 expertise is sure to be present. It was questioned from the audience what the purpose of the Ipv6 WG would be if not to discuss Ipv6 policy. This was not made particularly clear, but a reference to the work division between the LIR-WG and the DB-WG was made: the policy discussions takes place in the LIR-WG while technical implementation details relating to the database takes place in the DB-WG and is implemented by the RIPE NCC. The chair feels it is premature to make a final decision on this, but senses coming consensus that LIR-WG should do policy development for IPv4 and IPv6. ACTION LIR-34.11 on Chair Discuss moving Ipv6 policy matters to lir-wg. 12.2 PI Assignments (Yuval Shchory) Eyal wonders if end-users who require PI address space should become RIPE NCC members themselves in order to obtain address space directly from the RIPE NCC. Mirjam clarifies that although it is discouraged to assign PI addresses to end-users it is possible if technically required. These assignments should not be made out of the PA range allocated to the LIR; the RIPE NCC will make these assignments from a separate range in order to avoid holes in the PA range of the LIR. The desire to obtain PI addresses is not a reason in itself to become a RIPE NCC member and to obtain a separate allocation from the RIPE NCC. There was also a clarification to why use of PI addresses is discouraged: this relates to the additional burden that individual route entries for end-users create on the global Internet. The RIPE policy in this area has thus been carefully worded to promote PA addresses and CIDR. It is also worth noting that certain big US providers do not accept fragments of PA addresses from peering partners (but may do so in transit agreements). 12.3 Reverse delegation process -> discussion on lir-wg to fully understand all implications This came up during Mirjams report. Since we had no time left to further discuss the aspects of this it was added to the action list to conclude this discussion on the mailinglist. (See action LIR-34.3) 12.4 DB support for multiple Domain objects Was not discussed. It was suggested to move the discussion to the db wg. Actions: Action Owner Status Description LIR-34.1 Chair Suggest clarification of WG charter LIR-34.2 WG Reverse delegation process -> discussion on lir-wg to fully understand all implications LIR-34.3 NCC Store statistics on web site and keep them up to date. LIR-34.4 Chair Form a task force for documenting the existing policy process LIR-34.5 RB suggest a selection procedure for the plenary LIR.34.6 Chair Form a task force to define final Address council selection procedure LIR-34.7 NCC Clarify LIR-RIR expectations in the audit process LIR-34.8 JA additional value for the inetnum "status" field LIR-34.9 NCC Proceed with plans to implement PGP as an option for hostmaster communication LIR-34.10 NCC Release source code to rtt due to demand LIR-34.11 WG Discuss moving IPv6 policy matters to lir-wg From hph at sys.sol.no Sun Dec 19 23:14:29 1999 From: hph at sys.sol.no (Hans Petter Holen) Date: Sun, 19 Dec 1999 23:14:29 +0100 Subject: Countdown to the next LIR Working Group meeting Message-ID: <004301bf4a6e$7af81580$e406e1c3@dont.no> Dear LIR WG, A new RIPE meeting is approaching and we have some important business to conduct. I have just posted the minutes from the last working group meeting to the list, with the comments I have received from the participants. The time since the last meeting has been particularly busy, partially because the company I work for has been bought by Infostream ASA, partially because several people left the company leaving me with the task of rebuilding the sales and marketing department. Things are now returning to normal, and I hope to have some more time to spend on RIPE and ICANN ASO business. The most important thing that has happened this autumn was the ICANN meeting in Los Angeles. The long version of what happened at that meeting can be found at the ICANN web site at http://cyber.law.harvard.edu/icann/la/archive/ The formal version, IE, the minutes from the Board meeting: http://www.icann.org/minutes/prelim-report-4nov99.htm The short version of what happened related to the Address Supporting Organisation, http://www.aso.icann.org according to my memory is: - The Address Council and the ASO directors met with some ICANN board members and staff to get aquatinted and have informal discussions on how to proceed with our work. - The Address Council had an open meeting, minutes can be found at: http://aso.icann.org/mailing-lists/aso-policy/9912/msg00000.html (The minutes from the previous phone conference can be found at: http://aso.icann.org/mailing-lists/aso-announce/9911/msg00000.html ) - The discussions on the ad Hoc committee turned into something that seems more acceptable to all parties. -I had the pleasure of presenting the status of the work done by the Address Council so far to the ICANN annual meeting. http://home.sol.no/~hph/ASO/ICANN%20ASO%20rapport%209911/ After this the address council as such has not done that much work, our eminent staff at the regionally registries are however driving the process forward and have been working to move things forward. The European part of the AC will thus meet with the RIPE NCC executive board next week to discuss how to proceed. There is however some items on the action lists that needs to be taken care of: LIR-34.4 Form a task force for documenting the existing policy process LIR.34.6 Form a task force to define final Address council selection procedure Sincerely, Hans Petter Holen Chair LIR-WG From ncc at ripe.net Mon Dec 20 18:44:29 1999 From: ncc at ripe.net (RIPE NCC Staff) Date: Mon, 20 Dec 1999 18:44:29 +0100 Subject: IPv6 Policy Document Review - Call for comments Message-ID: <199912201744.SAA20176@birch.ripe.net> Dear colleagues, In July 1999, the three Regional Internet Registries (APNIC, ARIN, and the RIPE NCC) released the "Provisional IPv6 Assignment and Allocation Policy Document" (see http://www.ripe.net/lir/registries/ipv6.html). These initial policies and procedures have been carefully discussed within the community before publishing them. A formal review of the document was scheduled to start in October 1999, so that early experiences of IPv6 operation and administration could be fully evaluated and any necessary amendments made. The RIPE NCC, together with the other RIRs, now calls for comments to assist in this first review. We would like you to re-visit this document and we invite you to make any comments you feel would be constructive to the development of the next version. In particular, the RIRs seek your comments on the following sections of the document: * 4.2.3.2 Multihomed Sites This section was left unwritten in the first release, as there was insufficient experience to draw on in formulating a policy. We encourage any members of the community who have operational experience or interest in IPv6 and multi-homing to contribute suggestions for this section. * 4.2.8 Allocations to NLA Registries * 4.3.1 Assignments to End-users Review of these two sections is sought from members of the community who have relevant operational experience. * Definition of 'transit provider' A definition for the above term was not included in the current document. Comments and suggestions for an appropriate definition are encouraged. Finally, we also encourage you to take a look at the "IPv6 sub-TLA Request Form" (http://www.ripe.net/docs/ripe-195.html) and provide any comments or suggestions for improvements. Discussion will take place on the IPv6-WG mailing list . If you prefer to submit any private comments, please do not hesitate to contact Nurani Nimpuno . We would like to receive comments before the end of January. Kind Regards, Nurani Nimpuno Manager Registration Services RIPE NCC From david at Qwest.com Tue Dec 21 00:57:31 1999 From: david at Qwest.com (David Kessens) Date: Mon, 20 Dec 1999 16:57:31 -0700 Subject: IPv6 Policy Document Review - Call for comments In-Reply-To: <199912201744.SAA20176@birch.ripe.net>; from RIPE NCC Staff on Mon, Dec 20, 1999 at 06:44:29PM +0100 References: <199912201744.SAA20176@birch.ripe.net> Message-ID: <19991220165731.C1689@Qwest.com> On Mon, Dec 20, 1999 at 06:44:29PM +0100, RIPE NCC Staff wrote: > > In July 1999, the three Regional Internet Registries (APNIC, ARIN, and > the RIPE NCC) released the "Provisional IPv6 Assignment and Allocation > Policy Document" (see http://www.ripe.net/lir/registries/ipv6.html). > These initial policies and procedures have been carefully discussed > within the community before publishing them. > > A formal review of the document was scheduled to start in October > 1999, so that early experiences of IPv6 operation and administration > could be fully evaluated and any necessary amendments made. I am definitely going to put this on the agenda of the IPv6 wg for the next meeting. I would like to encourage all people to make comments and suggestions on the ipv6-wg list. I am specifically looking for input from those of you who already received IPv6 address space. Thanks, David K. --- From ripe-dbm at ripe.net Tue Dec 21 19:30:12 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 21 Dec 1999 19:30:12 +0100 Subject: Top 100 Maintainers List 19991221 Message-ID: <199912211830.TAA24016@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 XLINK-MNT 42966 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html 2 DENIC-P 41589 http://www.ripe.net/db/state/maintainers/DENIC-P.html 3 DK-DOMREG 8004 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html 4 ROKA-P 3263 http://www.ripe.net/db/state/maintainers/ROKA-P.html 5 DTAG-NIC 3209 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html 6 SCHLUND-P 2372 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html 7 FR-NIC-MNT 2178 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html 8 BO-DOMREG 1626 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html 9 ECCE-NOC 1605 http://www.ripe.net/db/state/maintainers/ECCE-NOC.html 10 NACAMAR-NOC 1554 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html 11 DREIMARK49-MNT 1547 http://www.ripe.net/db/state/maintainers/DREIMARK49-MNT.html 12 WWW-MNT 1397 http://www.ripe.net/db/state/maintainers/WWW-MNT.html 13 ABCAG-MNT 1189 http://www.ripe.net/db/state/maintainers/ABCAG-MNT.html 14 DENIC-N 1043 http://www.ripe.net/db/state/maintainers/DENIC-N.html 15 AS1849-MNT 794 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html 16 HIGHSPEED-DOM 733 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html 17 ECORE-NET 703 http://www.ripe.net/db/state/maintainers/ECORE-NET.html 18 INTERNET-NOC 683 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html 19 SEKTORNET-MNT 570 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html 20 CSL-MNT 567 http://www.ripe.net/db/state/maintainers/CSL-MNT.html 21 DKNET-MNT 544 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html 22 DFN-NTFY 538 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html 23 NACAMAR-RES 491 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html 24 DE-VOSS 475 http://www.ripe.net/db/state/maintainers/DE-VOSS.html 25 GLOBAL-MNT 422 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html 26 SDT-NOC 421 http://www.ripe.net/db/state/maintainers/SDT-NOC.html 27 TDK-MNT 404 http://www.ripe.net/db/state/maintainers/TDK-MNT.html 28 DIGITALWEB-MNT 370 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html 29 RAK-NET 364 http://www.ripe.net/db/state/maintainers/RAK-NET.html 30 IDNET-MNT 357 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html 31 NACAMAR-POP 354 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html 32 RAIN-TRANSPAC 349 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html 33 KNIPP-NOC-MNT 343 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html 34 AS6678-MNT 332 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html 35 OLEANE-NOC 331 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html 36 IL-P 328 http://www.ripe.net/db/state/maintainers/IL-P.html 37 MARIDAN-P 328 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html 38 WESPE-MNT 325 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html 39 GIGABELL-MNT 324 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html 40 INX-MNT 318 http://www.ripe.net/db/state/maintainers/INX-MNT.html 41 FR-EASYNET 317 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html 42 NETCOLOGNE-MNT 311 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html 43 SL-CUS-MNT 293 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html 44 AS5617-MNT 277 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html 45 AS3233-MNT 275 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html 46 FREENAME-NOC 275 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html 47 TRMD-MNT 257 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html 48 AS1717-MNT 246 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html 49 MBT-MNT 233 http://www.ripe.net/db/state/maintainers/MBT-MNT.html 50 NETTUNO 232 http://www.ripe.net/db/state/maintainers/NETTUNO.html 51 EUROCONNECT 231 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html 52 IMAGINET-NOC-MNT 225 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm 53 AS5427-MNT 224 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html 54 AS5378-MNT 222 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html 55 NDH-P 214 http://www.ripe.net/db/state/maintainers/NDH-P.html 56 IBGNET 213 http://www.ripe.net/db/state/maintainers/IBGNET.html 57 AS2120-MNT 211 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html 58 AS2529-MNT 205 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html 59 PRHO-GUARDIAN 205 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html 60 IWAY-NOC 203 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html 61 DNSNET-MNT 195 http://www.ripe.net/db/state/maintainers/DNSNET-MNT.html 62 ONE2ONE-MNT 193 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html 63 ROM-MIKNET 186 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html 64 SKYNETBE-MNT 185 http://www.ripe.net/db/state/maintainers/SKYNETBE-MNT.html 65 IT-NIC 177 http://www.ripe.net/db/state/maintainers/IT-NIC.html 66 AS1241-MNT 168 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html 67 AS1899-MNT 167 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html 68 AS1267-MNT 165 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html 69 EU-IBM-NIC-MNT2 165 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html 70 AS2871-MNT 158 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html 71 KDT-MNT 154 http://www.ripe.net/db/state/maintainers/KDT-MNT.html 72 PSINET-UK-SYSADMIN 153 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h 73 OMNILINK-MNT 152 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html 74 AS5551-MNT 141 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html 75 ISTLD-MNT 138 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html 76 AS6721-MNT 136 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html 77 NNCC 133 http://www.ripe.net/db/state/maintainers/NNCC.html 78 EVOSYS-MNT 131 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html 79 DK-NIC 128 http://www.ripe.net/db/state/maintainers/DK-NIC.html 80 ICMS-NOC-MAINTAINER 126 http://www.ripe.net/db/state/maintainers/ICMS-NOC-MAINTAINER. 81 ISMA-MNT 117 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html 82 AS3292-MNT 115 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html 83 SEICOM-MNT 114 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html 84 INETWIRE-MNT 107 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html 85 PROFI-MNT 107 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html 86 COMMPLEX-MNT 105 http://www.ripe.net/db/state/maintainers/COMMPLEX-MNT.html 87 ISB-MNT 105 http://www.ripe.net/db/state/maintainers/ISB-MNT.html 88 MDA-Z 104 http://www.ripe.net/db/state/maintainers/MDA-Z.html 89 ROSNIIROS-MNT 100 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html 90 ITNET-MNT 98 http://www.ripe.net/db/state/maintainers/ITNET-MNT.html 91 ODN-MNT 96 http://www.ripe.net/db/state/maintainers/ODN-MNT.html 92 SPACENET-P 96 http://www.ripe.net/db/state/maintainers/SPACENET-P.html 93 XMS-MNT 94 http://www.ripe.net/db/state/maintainers/XMS-MNT.html 94 AS8875-MNT 90 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html 95 WEB4YOU-MNT 86 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html 96 VISCOMP-MNT 84 http://www.ripe.net/db/state/maintainers/VISCOMP-MNT.html 97 MAINT-AS3352 83 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html 98 OMC1-RIPE-MNT 83 http://www.ripe.net/db/state/maintainers/OMC1-RIPE-MNT.html 99 TINET-NOC 83 http://www.ripe.net/db/state/maintainers/TINET-NOC.html 100 CU-MNT 81 http://www.ripe.net/db/state/maintainers/CU-MNT.html From ripe-dbm at ripe.net Wed Dec 29 15:46:13 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Wed, 29 Dec 1999 15:46:13 +0100 Subject: Problems with the RIPE Database. Message-ID: <199912291446.PAA07824@birch.ripe.net> Dear Colleagues, This morning, the primary server for the RIPE Database had a serious hardware failure. Since that time, no updates of the RIPE Database have been possible. Queries are possible, but using the backup service. We are currently restoring the data. We must do this from backup tapes; thus, we do not expect to resume normal service until sometime between 2000 and 2200 GMT tonight. If you have sent updates, there is no need to send them again; they are being queued on another machine. We realise that this situation may cause you some inconvenience, but we are making every effort to fix it as quickly as possible. We are also investigating the subtle hardware failure that caused the original problem. If you have anymore questions, please contact . Regards, A. M. R. Magee _______________________ RIPE NCC Database Group From ripe-dbm at ripe.net Wed Dec 29 15:54:33 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Wed, 29 Dec 1999 15:54:33 +0100 Subject: Problems with the RIPE Database. Message-ID: <199912291454.PAA10118@birch.ripe.net> Dear Colleagues, This morning, the primary server for the RIPE Database had a serious hardware failure. Since that time, no updates of the RIPE Database have been possible. Queries are possible, but using the backup service. We are currently restoring the data. We must do this from backup tapes; thus, we do not expect to resume normal service until sometime between 2000 and 2200 GMT tonight. If you have sent updates, there is no need to send them again; they are being queued on another machine. We realise that this situation may cause you some inconvenience, but we are making every effort to fix it as quickly as possible. We are also investigating the subtle hardware failure that caused the original problem. If you have anymore questions, please contact . Regards, A. M. R. Magee _______________________ RIPE NCC Database Group