From woeber at cc.univie.ac.at Mon Jun 3 14:39:50 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 03 Jun 2002 14:39:50 +0200 Subject: IPv6 policy and Supernational-LIRs Message-ID: <00A0EE94.FB07903E.9@cc.univie.ac.at> >On Thu, May 30, 2002 at 10:05:09AM +0200, Kurt Erik Lindqvist KPNQwest wrote: >[..] >> > Not all of the /32s might even necessarily be visible globally, upstream >> > could go through the /28. >> >> Well, in our case they would. Problem is that we do not have a /28. My >> point was to some extent that we should define this better. It's is a >> single LIR, but the question is what the allocation should be for routing >> purposes. I seem to be missing something here, because right now I cannot see a direct relationship between the fact that a LIR is a "regular" LIR or an aggregate LIR (multinational), or the size of the initial allocation (/35 vs /32 or /28) when we talk *routing table size*. I think the "load" comes from the *complexity*, all the rest is indeed a matter of a few bits... Wilfried. PS: and by the way, the current state of some "major" provider(s) here in Europe seem to suggest that most of those discussions tend to become mute pretty often these days ;-) From ncc at ripe.net Tue Jun 4 11:35:14 2002 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Tue, 04 Jun 2002 11:35:14 +0200 Subject: New Document available: RIPE-242 Message-ID: <200206040935.g549ZEA13731@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A New document is available from the RIPE document store. Ref: ripe-242 Title: Smallest RIPE NCC Allocation / Assignment Sizes Author: Joao Luis Silva Damas, Leo Vegoda Date: 4 June 2002 Format: PS=22198 TXT=2179 Obsoletes: ripe-222 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the size of the minimum and default allocations made by the RIPE NCC to Local Internet Registries (LIRs) and End Users from IPv4 and IPv6 CIDR blocks allocated to the RIPE NCC by the Internet Assigned Numbers Authority (IANA). Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-242.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-242.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-242 is not available from the WWW at this moment, but will be soon, at the following URL: http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html Kind Regards, RIPE NCC Webmaster From andre.stiphout at wcom.com Tue Jun 4 16:54:38 2002 From: andre.stiphout at wcom.com (Andre Stiphout) Date: Tue, 4 Jun 2002 14:54:38 +0000 Subject: new swamp ? Message-ID: <20020604145438.F25741@eunoc00.ams.ops.eu.uu.net> What is the position of the RIPE NCC/RIPE community on the address space of a SP that disappears from the net? Is there a clear statement somewhere describing that all of the SP PA-space needs to be returned within x months to RIPE? What we and other providers are seeing is that KPNQ customers want to retain their PA space if they move over; we would like them to renumber (of course :-) and as long as KPNQ as an entity is around we insist on it, in the usual timeframe. But in the case the pullups go, signifying the end of a network, and there is no clear RIPE policy behind this, I suspect not many providers will care about getting these customers renumbered if these customers feel they retain sufficient global connectivity. The net result is an increase of the size of the routing table. Is this detailed in the LIR contract or something and what is the value of that contract if the LIR disappears, but the customers find connectivity elsewhere? -- Thanks! Andr[alt-130] Stiphout - Mngr IP Core, Standards & Analysis WorldCom - Network Services - Data Technology - AS702 Ultima Ratio Regum - Louis XIV PGP Fingerprint C8 98 2D 73 5E 2A 11 01 41 C1 70 B7 95 9D 1A 4C From gert at space.net Tue Jun 4 17:10:36 2002 From: gert at space.net (Gert Doering) Date: Tue, 4 Jun 2002 17:10:36 +0200 Subject: new swamp ? In-Reply-To: <20020604145438.F25741@eunoc00.ams.ops.eu.uu.net>; from andre.stiphout@wcom.com on Tue, Jun 04, 2002 at 02:54:38PM +0000 References: <20020604145438.F25741@eunoc00.ams.ops.eu.uu.net> Message-ID: <20020604171036.R13918@Space.Net> hi, On Tue, Jun 04, 2002 at 02:54:38PM +0000, Andre Stiphout wrote: > What is the position of the RIPE NCC/RIPE community on the address space > of a SP that disappears from the net? Is there a clear statement > somewhere describing that all of the SP PA-space needs to be returned > within x months to RIPE? Good question. I don't know. "Usually" the LIR in question gets bought (so there is somebody who gets the allocation and is "responsible" for the PA now), but I don't know what happens if the LIR disappears completely. Of course we also urge customers to renumber :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jhma+ripe at mcvax.org Tue Jun 4 17:15:39 2002 From: jhma+ripe at mcvax.org (James Aldridge) Date: Tue, 04 Jun 2002 15:15:39 +0000 Subject: new swamp ? In-Reply-To: Message from Andre Stiphout of "Tue, 04 Jun 2002 14:54:38 GMT." <20020604145438.F25741@eunoc00.ams.ops.eu.uu.net> Message-ID: <200206041517.g54FHtA27567@birch.ripe.net> Andre Stiphout wrote: > But in the case the pullups go, signifying the end of a network, and > there is no clear RIPE policy behind this, I suspect not many providers > will care about getting these customers renumbered if these customers > feel they retain sufficient global connectivity. The net result is an > increase of the size of the routing table. > > Is this detailed in the LIR contract or something and what is the value > of that contract if the LIR disappears, but the customers find > connectivity elsewhere? I think that ripe-185 is pretty clear on registry colsures: | If the registry is closing as a Local IR, but will continue to provide | Internet connectivity to its customers as an ISP, the customers can continue | to use the address space already assigned to them. Assignments made by a | registry that is closed remain valid for as long as the original criteria | under which they were assigned remains valid. | | If the registry will no longer provide Internet connectivity to customers with | assigned address space, the assigned address space should be retrieved from | the users as they renumber. It is the Local IR's responsibility to help its | customers with renumbering. and | In general a period of 3 months should be allowed for the end user to complete | the transition to the new addresses. RFC 2008 "Implications of Various Address | Allocation Policies for Internet Routing" [Rekhter96a] recommends a grace | period of at least 30 days, and no longer than six months. For exceptional | cases, where the end user requests to keep both assignments for more than 6 | months, approval should be obtained for the proposed time frame from the RIPE | NCC. James (Co-chair RIPE LIR-WG) From neil at COLT.NET Tue Jun 4 17:02:52 2002 From: neil at COLT.NET (Neil J. McRae) Date: Tue, 4 Jun 2002 16:02:52 +0100 Subject: new swamp ? In-Reply-To: <20020604145438.F25741@eunoc00.ams.ops.eu.uu.net> Message-ID: We've told customers that we will accept /24 or more PA routes in the short term but in the longer term they need to renumber. Its alot of PA space though, and a real mess. Regards, Neil. -- Neil J. McRae - COLT neil at COLT.NET From jhma at mcvax.org Tue Jun 4 17:15:39 2002 From: jhma at mcvax.org (James Aldridge) Date: Tue, 04 Jun 2002 15:15:39 +0000 Subject: new swamp ? In-Reply-To: Message from Andre Stiphout of "Tue, 04 Jun 2002 14:54:38 GMT." <20020604145438.F25741@eunoc00.ams.ops.eu.uu.net> Message-ID: Andre Stiphout wrote: > But in the case the pullups go, signifying the end of a network, and > there is no clear RIPE policy behind this, I suspect not many providers > will care about getting these customers renumbered if these customers > feel they retain sufficient global connectivity. The net result is an > increase of the size of the routing table. > > Is this detailed in the LIR contract or something and what is the value > of that contract if the LIR disappears, but the customers find > connectivity elsewhere? I think that ripe-185 is pretty clear on registry colsures: | If the registry is closing as a Local IR, but will continue to provide | Internet connectivity to its customers as an ISP, the customers can continue | to use the address space already assigned to them. Assignments made by a | registry that is closed remain valid for as long as the original criteria | under which they were assigned remains valid. | | If the registry will no longer provide Internet connectivity to customers with | assigned address space, the assigned address space should be retrieved from | the users as they renumber. It is the Local IR's responsibility to help its | customers with renumbering. and | In general a period of 3 months should be allowed for the end user to complete | the transition to the new addresses. RFC 2008 "Implications of Various Address | Allocation Policies for Internet Routing" [Rekhter96a] recommends a grace | period of at least 30 days, and no longer than six months. For exceptional | cases, where the end user requests to keep both assignments for more than 6 | months, approval should be obtained for the proposed time frame from the RIPE | NCC. James (Co-chair RIPE LIR-WG) From bs at kpnqwest.ch Tue Jun 4 17:25:00 2002 From: bs at kpnqwest.ch (Bernard Steiner) Date: Tue, 04 Jun 2002 17:25:00 +0200 Subject: new swamp ? In-Reply-To: Message from Gert Doering of "Tue, 04 Jun 2002 17:10:36 +0200." <20020604171036.R13918@Space.Net> Message-ID: <200206041525.RAA93277@mail.kpnqwest.ch> Hi there, > On Tue, Jun 04, 2002 at 02:54:38PM +0000, Andre Stiphout wrote: > > What is the position of the RIPE NCC/RIPE community on the address space > > of a SP that disappears from the net? Is there a clear statement > > somewhere describing that all of the SP PA-space needs to be returned > > within x months to RIPE? > "Usually" the LIR in question gets bought (so there is somebody who > gets the allocation and is "responsible" for the PA now), but I don't > know what happens if the LIR disappears completely. The situation is a little more difficult than that because in this case LIR includes more than one autonomous system includes one or more legal entity So "buying the LIR" probably means buying the whole company, whereas buying a legal entity in some country does not buy the LIR (though there is hope to get the addresses out of the LIR in that case). It might be a good idea to create something like special PA space owned by RIPE (all things considered, that is the case anyway [check the /16... ahem...]) and let some customers run off with their >=/24 PA address space. However, that doesn't really help those customers with sub-/24 assignments. Bernard Steiner Connecting Europe 1982-2002, myself on the net since 1988 From kurtis at kpnqwest.net Tue Jun 4 17:29:15 2002 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Tue, 4 Jun 2002 17:29:15 +0200 (MEST) Subject: new swamp ? In-Reply-To: <20020604145438.F25741@eunoc00.ams.ops.eu.uu.net> Message-ID: > What we and other providers are seeing is that KPNQ customers want to > retain their PA space if they move over; we would like them to renumber > (of course :-) and as long as KPNQ as an entity is around we insist on > it, in the usual timeframe. view is that customers leaving KQ, will have to renumber. It is also not unlikely that some of the national operations will go on as seppearate units, and if then customers start taking adress space with them, this will be real new swamp... Best regards, - kurtis - From andre.stiphout at wcom.com Tue Jun 4 18:40:37 2002 From: andre.stiphout at wcom.com (Andre Stiphout) Date: Tue, 4 Jun 2002 16:40:37 +0000 Subject: new swamp ? In-Reply-To: <200206041517.g54FHtA27567@birch.ripe.net>; from jhma+ripe@mcvax.org on Tue, Jun 04, 2002 at 03:15:39PM +0000 References: <200206041517.g54FHtA27567@birch.ripe.net> Message-ID: <20020604164037.L25792@eunoc00.ams.ops.eu.uu.net> On Tue, Jun 04, 2002 at 03:15:39PM +0000, James Aldridge wrote: > Andre Stiphout wrote: > > But in the case the pullups go, signifying the end of a network, and > > there is no clear RIPE policy behind this, I suspect not many providers > > will care about getting these customers renumbered if these customers > > feel they retain sufficient global connectivity. The net result is an > > increase of the size of the routing table. > > > > Is this detailed in the LIR contract or something and what is the value > > of that contract if the LIR disappears, but the customers find > > connectivity elsewhere? > I think that ripe-185 is pretty clear on registry colsures: > | If the registry is closing as a Local IR, but will continue to provide > | Internet connectivity to its customers as an ISP, the customers can continue > | to use the address space already assigned to them. Assignments made by a > | registry that is closed remain valid for as long as the original criteria > | under which they were assigned remains valid. > | > | If the registry will no longer provide Internet connectivity to customers with > | assigned address space, the assigned address space should be retrieved from > | the users as they renumber. It is the Local IR's responsibility to help its > | customers with renumbering. > and > | In general a period of 3 months should be allowed for the end user to complete > | the transition to the new addresses. RFC 2008 "Implications of Various Address > | Allocation Policies for Internet Routing" [Rekhter96a] recommends a grace > | period of at least 30 days, and no longer than six months. For exceptional > | cases, where the end user requests to keep both assignments for more than 6 > | months, approval should be obtained for the proposed time frame from the RIPE > | NCC. > James > (Co-chair RIPE LIR-WG) Thanks, that is clear, but I'm worried that the LIR will no longer be around to effect that change, as Kurtis also indicates could happen, but in a different way. I guess the onus then falls on the LIRs that start announcing fragments of the original PA space. Will RIPE NCC track this to ensure that renumbering does happen? What I would like to see is that all SPs demand these customers, which I assume to be smaller than a /20, to renumber as some of you already indicated they will. This can only work across-the-board if RIPE NCC ensures that it does happen by chasing the LIRs in question (yes/no?). >From Hank's email just now we can deduce that the latter part is not likely to happen. Any comments from RIPE NCC how they see this evolving? regards, andre From hank at att.net.il Tue Jun 4 19:29:55 2002 From: hank at att.net.il (Hank Nussbacher) Date: Tue, 4 Jun 2002 20:29:55 +0300 (IDT) Subject: new swamp ? In-Reply-To: <200206041525.RAA93277@mail.kpnqwest.ch> Message-ID: On Tue, 4 Jun 2002, Bernard Steiner wrote: I have cases where I have told RIPE of deceased ISPs: http://www.ripe.net/perl/whois?-T+inetnum+212.77.128/19 http://www.ripe.net/perl/whois?-T+inetnum+195.3.128/17 http://www.ripe.net/perl/whois?-T+inetnum+195.8.192/19 These have been unannounced for at least 2 years now and RIPE hasn't seen fit to revoke or withdraw the IP ranges. I doubt the LIR has paid dues since they no longer exist. So I can imagine that KPNQwest space will languish in RIPE for a while (there are 4 KPNQwest entries listed at: http://www.ripe.net/ripencc/mem-services/general/allocs4.html countries: .at, .eu, .ee, and .it) I think if there is any company or organization who has been assigned the full /20 or /19 from KPNQwest (doubtful - but a possibility) and they want to move over to some other ISP - why not allow it? The routing table size won't increase by even one prefix. /24s should just renumber within 6 months. -Hank > Hi there, > > > On Tue, Jun 04, 2002 at 02:54:38PM +0000, Andre Stiphout wrote: > > > What is the position of the RIPE NCC/RIPE community on the address space > > > of a SP that disappears from the net? Is there a clear statement > > > somewhere describing that all of the SP PA-space needs to be returned > > > within x months to RIPE? > > "Usually" the LIR in question gets bought (so there is somebody who > > gets the allocation and is "responsible" for the PA now), but I don't > > know what happens if the LIR disappears completely. > > The situation is a little more difficult than that because in this case > LIR > includes more than one > autonomous system > includes one or more > legal entity > > So "buying the LIR" probably means buying the whole company, whereas buying > a legal entity in some country does not buy the LIR (though there is hope > to get the addresses out of the LIR in that case). > > It might be a good idea to create something like special PA space owned by RIPE > (all things considered, that is the case anyway [check the /16... ahem...]) > and let some customers run off with their >=/24 PA address space. > However, that doesn't really help those customers with sub-/24 assignments. > > Bernard Steiner > Connecting Europe 1982-2002, myself on the net since1988 > Hank Nussbacher From pekkas at netcore.fi Wed Jun 5 10:42:52 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 5 Jun 2002 11:42:52 +0300 (EEST) Subject: new swamp ? In-Reply-To: Message-ID: On Tue, 4 Jun 2002, Hank Nussbacher wrote: > since they no longer exist. So I can imagine that KPNQwest space will > languish in RIPE for a while (there are 4 KPNQwest entries listed at: > http://www.ripe.net/ripencc/mem-services/general/allocs4.html countries: > .at, .eu, .ee, and .it) Please also look for 'Eunet'. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From jhma+ripe at mcvax.org Wed Jun 5 10:56:51 2002 From: jhma+ripe at mcvax.org (James Aldridge) Date: Wed, 05 Jun 2002 08:56:51 +0000 Subject: new swamp ? In-Reply-To: Message from Pekka Savola of "Wed, 05 Jun 2002 11:42:52 +0300." Message-ID: Pekka Savola wrote: > On Tue, 4 Jun 2002, Hank Nussbacher wrote: > > since they no longer exist. So I can imagine that KPNQwest space will > > languish in RIPE for a while (there are 4 KPNQwest entries listed at: > > http://www.ripe.net/ripencc/mem-services/general/allocs4.html countries: > > .at, .eu, .ee, and .it) > > Please also look for 'Eunet'. Which adds cz, fi, and fr as parts of KPNQwest, other "eunet" registries only have historical connections. There's also xlink and about 11 ebone/gts registries. James From leo at ripe.net Wed Jun 5 15:20:01 2002 From: leo at ripe.net (leo vegoda) Date: Wed, 5 Jun 2002 15:20:01 +0200 Subject: new swamp ? In-Reply-To: <20020604164037.L25792@eunoc00.ams.ops.eu.uu.net> References: <200206041517.g54FHtA27567@birch.ripe.net> <20020604164037.L25792@eunoc00.ams.ops.eu.uu.net> Message-ID: <20020605132001.GA2000@ripe.net> Hello Andre, The policy on this issue has already been stated by James. On Tue, Jun 04, 2002 at 04:40:37PM +0000, Andre Stiphout wrote: Re: Re: new swamp ? [...] > I guess the onus then falls on the LIRs that start announcing fragments > of the original PA space. Will RIPE NCC track this to ensure that > renumbering does happen? The RIPE NCC has a procedure for tracking the return of address space from End Users to their old LIR when renumbering is agreed as part of a request for approval of an assignment. This responsibility is transferred to the new LIR when the assignment is approved using that LIR's Assignment Window. The RIPE NCC does not have any authority over the routing decisions taken by network operators. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From ddiaz at ripe.net Wed Jun 5 19:25:47 2002 From: ddiaz at ripe.net (Daniel Diaz) Date: Wed, 05 Jun 2002 19:25:47 +0200 Subject: KPNQwest ns.eu.net server. Message-ID: <200206051725.g55HPlA05396@birch.ripe.net> Dear all, Given the current situation of KPNQwest and the possibility of its services going offline sometime soon, the RIPE NCC in agreement with KPNQwest will be temporally hosting this server (ns.eu.net) in its premises. This is to avoid major problems in the Internet as this server is secondary for a large number of ccTLD's zones, and thousand other zones. We (AS3333) will be soon announcing the 192.16.202.0/24 prefix. Trusting that this is welcome news. Best regards. -- RIPE NCC -- Daniel.Diaz Operations Manager RIPE NCC From randy at psg.com Wed Jun 5 20:04:05 2002 From: randy at psg.com (Randy Bush) Date: Wed, 05 Jun 2002 11:04:05 -0700 Subject: KPNQwest ns.eu.net server. References: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: > Given the current situation of KPNQwest and the possibility > of its services going offline sometime soon, the RIPE NCC in > agreement with KPNQwest will be temporally hosting this > server (ns.eu.net) in its premises. nice emergency hack and sorry to whine. but i used them both to get diversity. when in less of a panic, please move it to moscow or something. randy From crain at icann.org Wed Jun 5 20:13:04 2002 From: crain at icann.org (John L Crain) Date: Wed, 05 Jun 2002 11:13:04 -0700 Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: <5.1.0.14.0.20020605110339.03b3bd10@127.0.0.1> Very welcome, Thanks for this Dani it gives everyone much more breathing space. I think this a fantastic effort on behalf of the NCC, the folks at eu.net and anyone else involved, they should all be applauded for it. A few logistical questions that may be relevant to those affected. Is there a projected time when this service may be discontinued? I can imagine that the RIPE NCC doesn't want to indefinitely run secondary for end sites? If not: This is in the same AS as ns.ripe.net. Is it also physically on the same infrastructure? What I guess I'm asking is: To what extent do those using both ns.ripe.net and ns.eu.net have redundancy between the two servers? JC At 07:25 PM 6/5/2002 +0200, Daniel Diaz wrote: >Dear all, > > >Given the current situation of KPNQwest and the possibility >of its services going offline sometime soon, the RIPE NCC in >agreement with KPNQwest will be temporally hosting this >server (ns.eu.net) in its premises. > >This is to avoid major problems in the Internet as this server >is secondary for a large number of ccTLD's zones, and thousand >other zones. > >We (AS3333) will be soon announcing the 192.16.202.0/24 prefix. > > >Trusting that this is welcome news. > >Best regards. > >-- >RIPE NCC > > >-- >Daniel.Diaz >Operations Manager >RIPE NCC From oppermann at tix.ch Wed Jun 5 20:16:14 2002 From: oppermann at tix.ch (Andre Oppermann) Date: Wed, 05 Jun 2002 20:16:14 +0200 Subject: KPNQwest ns.eu.net server. References: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: <3CFE556E.6D3D26CE@tix.ch> Daniel Diaz wrote: > > Dear all, > > Given the current situation of KPNQwest and the possibility > of its services going offline sometime soon, the RIPE NCC in > agreement with KPNQwest will be temporally hosting this > server (ns.eu.net) in its premises. > > This is to avoid major problems in the Internet as this server > is secondary for a large number of ccTLD's zones, and thousand > other zones. Just for a note: The server ccTLD.tix.ch is available for all ccTLD's to add/expand diversity in location again. It is currently a secondary for the .CH and .LI ccTLD's and it is connected directly to the Zurich/Switzerland Internet Exchange TIX (http://www.tix.ch). It has got plenty of spare capacity and very good connectivity via many upstreams. -- Andre Oppermann TIX Project Manager W: http://www.tix.ch E: oppermann at tix.ch From hank at att.net.il Wed Jun 5 22:18:07 2002 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 5 Jun 2002 23:18:07 +0300 (IDT) Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: On Wed, 5 Jun 2002, Daniel Diaz wrote: [cc list reduced to cut down noise] Should now be interesting to see how RIPE handles renumbering of this /24 within a 6 month period as per ripe-185. :-) ref: http://www.ripe.net/ripe/mail-archives/lir-wg/20020401-20020701/msg00228.html -Hank > > Dear all, > > > Given the current situation of KPNQwest and the possibility > of its services going offline sometime soon, the RIPE NCC in > agreement with KPNQwest will be temporally hosting this > server (ns.eu.net) in its premises. > > This is to avoid major problems in the Internet as this server > is secondary for a large number of ccTLD's zones, and thousand > other zones. > > We (AS3333) will be soon announcing the 192.16.202.0/24 prefix. > > > Trusting that this is welcome news. > > Best regards. > > -- > RIPE NCC > > > -- > Daniel.Diaz > Operations Manager > RIPE NCC > > From ddiaz at ripe.net Wed Jun 5 23:00:47 2002 From: ddiaz at ripe.net (Daniel Diaz) Date: Wed, 05 Jun 2002 23:00:47 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: Your message of Wed, 05 Jun 2002 11:13:04 PDT. <5.1.0.14.0.20020605110339.03b3bd10@127.0.0.1> References: <5.1.0.14.0.20020605110339.03b3bd10@127.0.0.1> Message-ID: <200206052100.g55L0lA23220@birch.ripe.net> (cutting the list to reduce the noise). Hi John, Thanks. John L Crain writes: * * This is in the same AS as ns.ripe.net. Is it also physically on the same * infrastructure? Basically yes. * What I guess I'm asking is: To what extent do those using both ns.ripe.net * and ns.eu.net have redundancy between the two servers? This is the reason Randy whines ;-). This is as I said *temporary*. During this interim, zones running in both servers would only get from it server redundancy. Regards. -- Daniel.Diaz RIPE NCC * JC * * * * At 07:25 PM 6/5/2002 +0200, Daniel Diaz wrote: * * >Dear all, * > * > * >Given the current situation of KPNQwest and the possibility * >of its services going offline sometime soon, the RIPE NCC in * >agreement with KPNQwest will be temporally hosting this * >server (ns.eu.net) in its premises. * > * >This is to avoid major problems in the Internet as this server * >is secondary for a large number of ccTLD's zones, and thousand * >other zones. * > * >We (AS3333) will be soon announcing the 192.16.202.0/24 prefix. * > * > * >Trusting that this is welcome news. * > * >Best regards. * > * >-- * >RIPE NCC * > * > * >-- * >Daniel.Diaz * >Operations Manager * >RIPE NCC * * From joao at ripe.net Thu Jun 6 01:08:46 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 6 Jun 2002 01:08:46 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: References: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: At 11:04 -0700 5/6/02, Randy Bush wrote: > > Given the current situation of KPNQwest and the possibility >> of its services going offline sometime soon, the RIPE NCC in >> agreement with KPNQwest will be temporally hosting this >> server (ns.eu.net) in its premises. > >nice emergency hack and sorry to whine. but i used them both >to get diversity. Hi Randy, there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both secondary. So we will definitely request those ccTLDs to look for a new host as soon as possible. The rest can take bit more time to think what they want to do since ns.eu.net will keep running. We are offering secondary service on ns.ripe.net for any ccTLD that we weren't sencodaring for, as are other people. The idea is not to have ns.eu.net running for ever, just to enable people to have time to take rational decisions, without the fear of having the server going away because of some unexpected turn of events. > >when in less of a panic, please move it to moscow or something. Panic? what panic? this is just common sense Joao >randy From czmok at gatel.net Thu Jun 6 01:29:37 2002 From: czmok at gatel.net (Jan-Ahrent Czmok) Date: Thu, 6 Jun 2002 01:29:37 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: References: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: <20020606012937.2c476312.czmok@gatel.net> On Thu, 6 Jun 2002 01:08:46 +0200 Joao Luis Silva Damas wrote: > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > Given the current situation of KPNQwest and the possibility > >> of its services going offline sometime soon, the RIPE NCC in > >> agreement with KPNQwest will be temporally hosting this > >> server (ns.eu.net) in its premises. > > > >nice emergency hack and sorry to whine. but i used them both > >to get diversity. > > Hi Randy, > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > secondary. So we will definitely request those ccTLDs to look for a > new host as soon as possible. Hi Randy, hi Joao, dear routing-wg, probably my Company (GATEL, AS13129) is able to host a secondary server for the ccTLDs. The question is rather what are the hardware "requirements" for the secondary server. We have sufficient bandwidth capacity available and rack space as well. > The rest can take bit more time to think what they want to do since > ns.eu.net will keep running. Well done ! Congrats for the good ideas and coordination work. > > We are offering secondary service on ns.ripe.net for any ccTLD that > we weren't sencodaring for, as are other people. > > The idea is not to have ns.eu.net running for ever, just to enable > people to have time to take rational decisions, without the fear of > having the server going away because of some unexpected turn of > events. > > > > >when in less of a panic, please move it to moscow or something. > > Panic? what panic? this is just common sense > right. it's not panic. --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok at gatel.de From dolderer at denic.de Thu Jun 6 09:43:32 2002 From: dolderer at denic.de (Sabine Dolderer/Denic) Date: Thu, 6 Jun 2002 09:43:32 +0200 Subject: KPNQwest ns.eu.net server. Message-ID: Hello, DENIC runs currently several secondarys (not only DE but also for some other TLDs) in different places worldwide. We are willing to offer secondary service for other ccTLDs. But there will be because of security/stability reasons a limit on the number of ccTLDs we want to run on a single machine. Sabine -- Sabine Dolderer DENIC eG Wiesenh?ttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer at denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 Jan-Ahrent Czmok An: Joao Luis Silva Damas lir-wg at ripe.net, tech-l at ams-ix.net, apops at lists.apnic.net, Gesendet von: nanog at merit.edu, apnic-talk at lists.apnic.net owner-lir-wg@ Thema: Re: KPNQwest ns.eu.net server. ripe.net 06.06.2002 01:29 PostedDate: 06.06.2002 01:29:37 $MessageID: <20020606012937.2c476312.czmok at gatel.net> From: owner-lir-wg at ripe.net SendTo: Joao Luis Silva Damas CopyTo: randy at psg.com;ddiaz at ripe.net;routing-wg at ripe.net;lir-wg at ripe.net;tech-l at ams-ix.net;apops at lists.apnic.net;nanog at merit.edu;apnic-talk at lists.apnic.net Subject: Re: KPNQwest ns.eu.net server. Received: from smtp.denic.de ([194.246.96.22]) by notes.denic.de (Lotus Domino Release 5.0.8) with ESMTP id 2002060601283597:15602 ; Thu, 6 Jun 2002 01:28:35 +0200 Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 +0200 Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 Delivered_To: lists-lir-wg-out at lists.ripe.net PRINCIPAL: Jan-Ahrent Czmok In_Reply_To: References: <200206051725.g55HPlA05396 at birch.ripe.net> Organization: Global Access Telecommunications Inc. $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; i386-debian-linux-gnu) X_Ncc_RegID: de.gatel MIME_Version: 1.0 Precedence: bulk X_Loop_Detect: RIPE NCC SMTPOriginator: owner-lir-wg at ripe.net RouteServers: CN=notes/O=Denic RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 DeliveredDate: 06.06.2002 01:28:38 DENICDOCOPENCOUNT: 1 $MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 BlindCopyTo: WebSubject: Re: KPNQwest ns.eu.net server. On Thu, 6 Jun 2002 01:08:46 +0200 Joao Luis Silva Damas wrote: > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > Given the current situation of KPNQwest and the possibility > >> of its services going offline sometime soon, the RIPE NCC in > >> agreement with KPNQwest will be temporally hosting this > >> server (ns.eu.net) in its premises. > > > >nice emergency hack and sorry to whine. but i used them both > >to get diversity. > > Hi Randy, > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > secondary. So we will definitely request those ccTLDs to look for a > new host as soon as possible. Hi Randy, hi Joao, dear routing-wg, probably my Company (GATEL, AS13129) is able to host a secondary server for the ccTLDs. The question is rather what are the hardware "requirements" for the secondary server. We have sufficient bandwidth capacity available and rack space as well. > The rest can take bit more time to think what they want to do since > ns.eu.net will keep running. Well done ! Congrats for the good ideas and coordination work. > > We are offering secondary service on ns.ripe.net for any ccTLD that > we weren't sencodaring for, as are other people. > > The idea is not to have ns.eu.net running for ever, just to enable > people to have time to take rational decisions, without the fear of > having the server going away because of some unexpected turn of > events. > > > > >when in less of a panic, please move it to moscow or something. > > Panic? what panic? this is just common sense > right. it's not panic. --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok at gatel.de From dani at intelideas.com Thu Jun 6 11:01:27 2002 From: dani at intelideas.com (Daniel Concepcion) Date: Thu, 6 Jun 2002 11:01:27 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: References: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: <200206061101.27288.dani@intelideas.com> Hi People, Here from Intelideas (AS12359) we are ready for hosting ccTLDs in our network. We are present in Espanix, Linx, Catnix and diverse upstreams. Our contact data: DNS: dns at intelideas.com DNS Master: Enrique Iglesias Rodriguez. (+34 917882517) regards, Daniel Intelideas On Thursday 06 June 2002 01:08, Joao Luis Silva Damas wrote: > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > Given the current situation of KPNQwest and the possibility > >> > >> of its services going offline sometime soon, the RIPE NCC in > >> agreement with KPNQwest will be temporally hosting this > >> server (ns.eu.net) in its premises. > > > >nice emergency hack and sorry to whine. but i used them both > >to get diversity. > > Hi Randy, > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > secondary. So we will definitely request those ccTLDs to look for a > new host as soon as possible. > The rest can take bit more time to think what they want to do since > ns.eu.net will keep running. > > We are offering secondary service on ns.ripe.net for any ccTLD that > we weren't sencodaring for, as are other people. > > The idea is not to have ns.eu.net running for ever, just to enable > people to have time to take rational decisions, without the fear of > having the server going away because of some unexpected turn of > events. > > >when in less of a panic, please move it to moscow or something. > > Panic? what panic? this is just common sense > > Joao > > >randy From jesper at skriver.dk Thu Jun 6 11:09:10 2002 From: jesper at skriver.dk (Jesper Skriver) Date: Thu, 6 Jun 2002 11:09:10 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206051725.g55HPlA05396@birch.ripe.net>; from ddiaz@ripe.net on Wed, Jun 05, 2002 at 07:25:47PM +0200 References: <200206051725.g55HPlA05396@birch.ripe.net> Message-ID: <20020606110910.F92741@skriver.dk> On Wed, Jun 05, 2002 at 07:25:47PM +0200, Daniel Diaz wrote: > Dear all, > > > Given the current situation of KPNQwest and the possibility of its > services going offline sometime soon, the RIPE NCC in agreement with > KPNQwest will be temporally hosting this server (ns.eu.net) in its > premises. > > This is to avoid major problems in the Internet as this server is > secondary for a large number of ccTLD's zones, and thousand other > zones. > > We (AS3333) will be soon announcing the 192.16.202.0/24 prefix. TDC is currently secondary for the dk TLD, if any other TLD need a secondary, please contact hostmaster at tele.dk and/or tgm at tdcinternet.dk best regards /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From neil at COLT.NET Thu Jun 6 15:59:22 2002 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 6 Jun 2002 14:59:22 +0100 Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206061101.27288.dani@intelideas.com> Message-ID: I suggest that if the RIPE need another provider that they take time and issue a proper RFI/P/Q through the European Journal. It does ask an interesting question over disaster recovery in situations like this. Regards, Neil. -- Neil J. McRae - COLT neil at COLT.NET From arnold.nipper at de-cix.net Thu Jun 6 16:07:09 2002 From: arnold.nipper at de-cix.net (Nipper, Arnold) Date: Thu, 6 Jun 2002 16:07:09 +0200 Subject: KPNQwest ns.eu.net server. References: Message-ID: <01a401c20d63$735bbab0$6590a8c0@notebook> As a lot of people are offering secondary services: may be it's a good idea to place infrastructural services at IXP. IXP seem to be more stable than any ISPs and often more neutral than ISPs. Comments? Arnold -- Arnold Nipper, DE-CIX, the German Internet Exchange email: arnold.nipper at de-cix.net mobile: +49 172 2650958 handle: an6695-ripe ----- Original Message ----- From: "Sabine Dolderer/Denic" To: "Jan-Ahrent Czmok" Cc: ; ; ; ; ; ; ; ; Sent: Thursday, June 06, 2002 9:43 AM Subject: Re: Re: KPNQwest ns.eu.net server. Hello, DENIC runs currently several secondarys (not only DE but also for some other TLDs) in different places worldwide. We are willing to offer secondary service for other ccTLDs. But there will be because of security/stability reasons a limit on the number of ccTLDs we want to run on a single machine. Sabine -- Sabine Dolderer DENIC eG Wiesenh?ttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer at denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 Jan-Ahrent Czmok An: Joao Luis Silva Damas lir-wg at ripe.net, tech-l at ams-ix.net, apops at lists.apnic.net, Gesendet von: nanog at merit.edu, apnic-talk at lists.apnic.net owner-lir-wg@ Thema: Re: KPNQwest ns.eu.net server. ripe.net 06.06.2002 01:29 PostedDate: 06.06.2002 01:29:37 $MessageID: <20020606012937.2c476312.czmok at gatel.net> From: owner-lir-wg at ripe.net SendTo: Joao Luis Silva Damas CopyTo: randy at psg.com;ddiaz at ripe.net;routing-wg at ripe.net;lir-wg at ripe.net;tech-l at ams- ix.net;apops at lists.apnic.net;nanog at merit.edu;apnic-talk at lists.apnic.net Subject: Re: KPNQwest ns.eu.net server. Received: from smtp.denic.de ([194.246.96.22]) by notes.denic.de (Lotus Domino Release 5.0.8) with ESMTP id 2002060601283597:15602 ; Thu, 6 Jun 2002 01:28:35 +0200 Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 +0200 Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 Delivered_To: lists-lir-wg-out at lists.ripe.net PRINCIPAL: Jan-Ahrent Czmok In_Reply_To: References: <200206051725.g55HPlA05396 at birch.ripe.net> Organization: Global Access Telecommunications Inc. $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; i386-debian-linux-gnu) X_Ncc_RegID: de.gatel MIME_Version: 1.0 Precedence: bulk X_Loop_Detect: RIPE NCC SMTPOriginator: owner-lir-wg at ripe.net RouteServers: CN=notes/O=Denic RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 DeliveredDate: 06.06.2002 01:28:38 DENICDOCOPENCOUNT: 1 $MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 BlindCopyTo: WebSubject: Re: KPNQwest ns.eu.net server. On Thu, 6 Jun 2002 01:08:46 +0200 Joao Luis Silva Damas wrote: > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > Given the current situation of KPNQwest and the possibility > >> of its services going offline sometime soon, the RIPE NCC in > >> agreement with KPNQwest will be temporally hosting this > >> server (ns.eu.net) in its premises. > > > >nice emergency hack and sorry to whine. but i used them both > >to get diversity. > > Hi Randy, > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > secondary. So we will definitely request those ccTLDs to look for a > new host as soon as possible. Hi Randy, hi Joao, dear routing-wg, probably my Company (GATEL, AS13129) is able to host a secondary server for the ccTLDs. The question is rather what are the hardware "requirements" for the secondary server. We have sufficient bandwidth capacity available and rack space as well. > The rest can take bit more time to think what they want to do since > ns.eu.net will keep running. Well done ! Congrats for the good ideas and coordination work. > > We are offering secondary service on ns.ripe.net for any ccTLD that > we weren't sencodaring for, as are other people. > > The idea is not to have ns.eu.net running for ever, just to enable > people to have time to take rational decisions, without the fear of > having the server going away because of some unexpected turn of > events. > > > > >when in less of a panic, please move it to moscow or something. > > Panic? what panic? this is just common sense > right. it's not panic. --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok at gatel.de From jared at puck.Nether.net Thu Jun 6 16:16:34 2002 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 6 Jun 2002 10:16:34 -0400 Subject: KPNQwest ns.eu.net server. In-Reply-To: <01a401c20d63$735bbab0$6590a8c0@notebook> References: <01a401c20d63$735bbab0$6590a8c0@notebook> Message-ID: <20020606141634.GC6350@puck.nether.net> While a good idea, not everyone can announce or reach the IX fabrics that they connect to or are out there. One solution to that problem is to have the IX operate a zeebra/gated/whatnot box (or router+machine combo) that announces a /24 and as part of connecting to the IX people are required to peer (and provide transit) for that /24 for the "good of the internet". This would allow everyone that connects to the IX to see the benifits of having a close (to their network that is) dns server as well as if my provider does not announce the DE-CIX, LINX, mae-e, mae-w, paix, nyiix, or whatever space to me, i can still reach a server placed at the IX via their network or via their peers/upstreams. - Jared http://puck.nether.net/dns/ (very rough ui) On Thu, Jun 06, 2002 at 04:07:09PM +0200, Nipper, Arnold wrote: > > As a lot of people are offering secondary services: may be it's a good idea > to place infrastructural services at IXP. IXP seem to be more stable than > any ISPs and often more neutral than ISPs. > > Comments? > > > Arnold > -- > Arnold Nipper, DE-CIX, the German Internet Exchange > email: arnold.nipper at de-cix.net > mobile: +49 172 2650958 > handle: an6695-ripe > > > ----- Original Message ----- > From: "Sabine Dolderer/Denic" > To: "Jan-Ahrent Czmok" > Cc: ; ; ; > ; ; ; ; > ; > Sent: Thursday, June 06, 2002 9:43 AM > Subject: Re: Re: KPNQwest ns.eu.net server. > > > > Hello, > > DENIC runs currently several secondarys (not only DE but also for some > other TLDs) in different places worldwide. We are willing to offer > secondary service for other ccTLDs. But there will be because of > security/stability reasons a limit on the number of ccTLDs we want to run > on a single machine. > > Sabine > > -- > Sabine Dolderer > DENIC eG > Wiesenh?ttenplatz 26 > D-60329 Frankfurt > > eMail: Sabine.Dolderer at denic.de > Fon: +49 69 27235 0 > Fax: +49 69 27235 235 > > > > Jan-Ahrent > Czmok An: Joao Luis Silva Damas > > ddiaz at ripe.net, routing-wg at ripe.net, > net> lir-wg at ripe.net, tech-l at ams-ix.net, > apops at lists.apnic.net, > Gesendet von: nanog at merit.edu, > apnic-talk at lists.apnic.net > owner-lir-wg@ Thema: Re: KPNQwest ns.eu.net > server. > ripe.net > > > 06.06.2002 > 01:29 > > > > > > > PostedDate: 06.06.2002 01:29:37 > $MessageID: <20020606012937.2c476312.czmok at gatel.net> > From: owner-lir-wg at ripe.net > SendTo: Joao Luis Silva Damas > CopyTo: > randy at psg.com;ddiaz at ripe.net;routing-wg at ripe.net;lir-wg at ripe.net;tech-l at ams- > ix.net;apops at lists.apnic.net;nanog at merit.edu;apnic-talk at lists.apnic.net > > Subject: Re: KPNQwest ns.eu.net server. > Received: from smtp.denic.de ([194.246.96.22]) by notes.denic.de > (Lotus Domino Release 5.0.8) with ESMTP id 2002060601283597:15602 > ; Thu, 6 Jun 2002 01:28:35 +0200 > Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by > smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 > +0200 > Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 > Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 > Delivered_To: lists-lir-wg-out at lists.ripe.net > PRINCIPAL: Jan-Ahrent Czmok > In_Reply_To: > References: <200206051725.g55HPlA05396 at birch.ripe.net> > > Organization: Global Access Telecommunications Inc. > $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; i386-debian-linux-gnu) > X_Ncc_RegID: de.gatel > MIME_Version: 1.0 > Precedence: bulk > X_Loop_Detect: RIPE NCC > SMTPOriginator: owner-lir-wg at ripe.net > RouteServers: CN=notes/O=Denic > RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 > DeliveredDate: 06.06.2002 01:28:38 > DENICDOCOPENCOUNT: 1 > $MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, > 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine > Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 > 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 > BlindCopyTo: > WebSubject: Re: KPNQwest ns.eu.net server. > > > On Thu, 6 Jun 2002 01:08:46 +0200 > Joao Luis Silva Damas wrote: > > > > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > > Given the current situation of KPNQwest and the possibility > > >> of its services going offline sometime soon, the RIPE NCC in > > >> agreement with KPNQwest will be temporally hosting this > > >> server (ns.eu.net) in its premises. > > > > > >nice emergency hack and sorry to whine. but i used them both > > >to get diversity. > > > > Hi Randy, > > > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > > secondary. So we will definitely request those ccTLDs to look for a > > new host as soon as possible. > > Hi Randy, hi Joao, dear routing-wg, > > probably my Company (GATEL, AS13129) is able to host a secondary > server for the ccTLDs. > > The question is rather what are the hardware "requirements" for the > secondary > server. > > We have sufficient bandwidth capacity available and rack space as well. > > > The rest can take bit more time to think what they want to do since > > ns.eu.net will keep running. > > Well done ! Congrats for the good ideas and coordination work. > > > > > We are offering secondary service on ns.ripe.net for any ccTLD that > > we weren't sencodaring for, as are other people. > > > > The idea is not to have ns.eu.net running for ever, just to enable > > people to have time to take rational decisions, without the fear of > > having the server going away because of some unexpected turn of > > events. > > > > > > > >when in less of a panic, please move it to moscow or something. > > > > Panic? what panic? this is just common sense > > > > right. it's not panic. > > --jan > > -- > Jan Ahrent Czmok - Senior Network Engineer - Access Networks > Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt > voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok at gatel.de > > > -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From gert at space.net Thu Jun 6 16:35:55 2002 From: gert at space.net (Gert Doering) Date: Thu, 6 Jun 2002 16:35:55 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: ; from neil@COLT.NET on Thu, Jun 06, 2002 at 02:59:22PM +0100 References: <200206061101.27288.dani@intelideas.com> Message-ID: <20020606163555.G13918@Space.Net> hi, On Thu, Jun 06, 2002 at 02:59:22PM +0100, Neil J. McRae wrote: > I suggest that if the RIPE need another provider that they > take time and issue a proper RFI/P/Q through the European > Journal. It does ask an interesting question over disaster > recovery in situations like this. Hmmm? As far as I can see, RIPE has enough providers. The problem is that the ccTLD secondary server hosted at KQ broke - which isn't RIPEs fault, and doesn't even host anything RIPE is master for (like ripe.net or the *.in-addr.arpa zones). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45201 (45114) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From dani at intelideas.com Thu Jun 6 16:24:40 2002 From: dani at intelideas.com (Daniel Concepcion) Date: Thu, 6 Jun 2002 16:24:40 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: References: Message-ID: <200206061624.40230.dani@intelideas.com> Yes Neil, It should be interesting to know the 'official' requirements/recommendations for ccTLD's hosting For example: diversity geographical, network needs, security needs, building environment., etc Regards, Daniel Intelideas On Thursday 06 June 2002 15:59, Neil J. McRae wrote: > I suggest that if the RIPE need another provider that they > take time and issue a proper RFI/P/Q through the European > Journal. It does ask an interesting question over disaster > recovery in situations like this. > > Regards, > Neil. From dani at intelideas.com Thu Jun 6 16:31:21 2002 From: dani at intelideas.com (Daniel Concepcion) Date: Thu, 6 Jun 2002 16:31:21 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: <01a401c20d63$735bbab0$6590a8c0@notebook> References: <01a401c20d63$735bbab0$6590a8c0@notebook> Message-ID: <200206061631.21845.dani@intelideas.com> Yes, but there is problem about the transit for the network of the IXP In my experience, some big providers only have the commercial view of internet. Really, if all the IXP members give some transit to the IXP for essential services, internet will be more robust. Daniel Intelideas On Thursday 06 June 2002 16:07, Nipper, Arnold wrote: > As a lot of people are offering secondary services: may be it's a good idea > to place infrastructural services at IXP. IXP seem to be more stable than > any ISPs and often more neutral than ISPs. > > Comments? > > > Arnold From rod at energis-ision.de Thu Jun 6 16:43:13 2002 From: rod at energis-ision.de (Robert Depenbrock) Date: Thu, 6 Jun 2002 16:43:13 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: <01a401c20d63$735bbab0$6590a8c0@notebook>; from arnold.nipper@de-cix.net on Thu, Jun 06, 2002 at 04:07:09PM +0200 References: <01a401c20d63$735bbab0$6590a8c0@notebook> Message-ID: <20020606164313.A15540@energis-ision.de> On Thu, Jun 06, 2002 at 04:07:09PM +0200, Nipper, Arnold wrote: > As a lot of people are offering secondary services: may be it's a good idea > to place infrastructural services at IXP. IXP seem to be more stable than > any ISPs and often more neutral than ISPs. > > Comments? > Good Idea ! A natural choice seems to be a safe place at a IX that is operated and owned by an independend Company or Organisation, so that Chapter 11 candidates not interfer with the service. In my opinion is the placement of root namkeserver at some IX a good and safe choice for the future. regards Robert Depenbrock -- Energis-ISION Robert Depenbrock SE Technical Consulting Harburger Schlossstr. 1 Hamburg - Germany robert.depenbrock at energis-ision.com http://www.energis-ision.com/ Tel.: +49-40-77175-263 From mansaxel at sunet.se Thu Jun 6 16:46:05 2002 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson?=) Date: Thu, 06 Jun 2002 16:46:05 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020606141634.GC6350@puck.nether.net> References: <01a401c20d63$735bbab0$6590a8c0@notebook> <20020606141634.GC6350@puck.nether.net> Message-ID: <203570000.1023374765@slimsixten.pilsnet.sunet.se> --On Thursday, June 06, 2002 10:16:34 -0400 Jared Mauch wrote: > While a good idea, not everyone can announce or reach the > IX fabrics that they connect to or are out there. > > One solution to that problem is to have the IX operate a > zeebra/gated/whatnot box (or router+machine combo) that > announces a /24 and as part of connecting to the IX people > are required to peer (and provide transit) for that /24 for > the "good of the internet". > > This would allow everyone that connects to the IX to see > the benifits of having a close (to their network that is) dns server > as well as if my provider does not announce the DE-CIX, LINX, mae-e, > mae-w, paix, nyiix, or whatever space to me, i can still reach a server > placed at the IX via their network or via their peers/upstreams. This is done in Sweden, by the exchange point company Netnod, . They have an AS of their own, which is free to peer with, in which a number of crucial services are located, for instance: * Root DNS server * COM/NET/ORG DNS server * DNS for a number of ccTLDs including Sweden. * NTP masters directly synchronised to swedish standard time * RIPE whois mirror. Some of these services are present at several Netnod IXen, notably ccTLD and NTP. It works, and gives excellent service levels. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. From arnold at nipper.de Thu Jun 6 16:55:44 2002 From: arnold at nipper.de (Arnold Nipper) Date: Thu, 6 Jun 2002 16:55:44 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206061631.21845.dani@intelideas.com> References: <01a401c20d63$735bbab0$6590a8c0@notebook> <200206061631.21845.dani@intelideas.com> Message-ID: <20020606165544.A2064@server.nipper.de> On Thu, Jun 06, 2002 at 04:31:21PM +0200, Daniel Concepcion wrote: > > > Yes, but there is problem about the transit for the network of the IXP > In my experience, some big providers only have the commercial view of > internet. If an IXP decides to offer infrastructural services then you have to buy upstream of course. > Really, if all the IXP members give some transit to the IXP for essential > services, internet will be more robust. > At least each IXP member would have direct connectivity to such infrastructural services (DNS, NTP, WHOIS, NNTP??) and thereby their customers would benefit from it. And an IXP should be in a good position to get upstream :-)) And for the commercials: these services are not for free of course. So bills for IXP members will drop not raise. -- Arnold From neil at COLT.NET Thu Jun 6 17:00:12 2002 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 6 Jun 2002 16:00:12 +0100 Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020606163555.G13918@Space.Net> Message-ID: Gert, > On Thu, Jun 06, 2002 at 02:59:22PM +0100, Neil J. McRae wrote: > > I suggest that if the RIPE need another provider that they > > take time and issue a proper RFI/P/Q through the European > > Journal. It does ask an interesting question over disaster > > recovery in situations like this. > > Hmmm? As far as I can see, RIPE has enough providers. The problem is > that the ccTLD secondary server hosted at KQ broke - which isn't RIPEs > fault, and doesn't even host anything RIPE is master for (like ripe.net > or the *.in-addr.arpa zones). > Hence why I said "if the RIPE need another provider". Note the part that has "if" in it. Regards, Neil. From steve at opaltelecom.co.uk Thu Jun 6 16:59:49 2002 From: steve at opaltelecom.co.uk (Stephen J. Wilcox) Date: Thu, 6 Jun 2002 15:59:49 +0100 (BST) Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020606141634.GC6350@puck.nether.net> Message-ID: Indeed, for example k.root-servers.net is hosted at LINX and is reachable globally by this kind of setup.. Steve On Thu, 6 Jun 2002, Jared Mauch wrote: > > While a good idea, not everyone can announce or reach the > IX fabrics that they connect to or are out there. > > One solution to that problem is to have the IX operate a > zeebra/gated/whatnot box (or router+machine combo) that > announces a /24 and as part of connecting to the IX people > are required to peer (and provide transit) for that /24 for > the "good of the internet". > > This would allow everyone that connects to the IX to see > the benifits of having a close (to their network that is) dns server > as well as if my provider does not announce the DE-CIX, LINX, mae-e, mae-w, > paix, nyiix, or whatever space to me, i can still reach a server > placed at the IX via their network or via their peers/upstreams. > > - Jared > > http://puck.nether.net/dns/ > (very rough ui) > > On Thu, Jun 06, 2002 at 04:07:09PM +0200, Nipper, Arnold wrote: > > > > As a lot of people are offering secondary services: may be it's a good idea > > to place infrastructural services at IXP. IXP seem to be more stable than > > any ISPs and often more neutral than ISPs. > > > > Comments? > > > > > > Arnold > > -- > > Arnold Nipper, DE-CIX, the German Internet Exchange > > email: arnold.nipper at de-cix.net > > mobile: +49 172 2650958 > > handle: an6695-ripe > > > > > > ----- Original Message ----- > > From: "Sabine Dolderer/Denic" > > To: "Jan-Ahrent Czmok" > > Cc: ; ; ; > > ; ; ; ; > > ; > > Sent: Thursday, June 06, 2002 9:43 AM > > Subject: Re: Re: KPNQwest ns.eu.net server. > > > > > > > > Hello, > > > > DENIC runs currently several secondarys (not only DE but also for some > > other TLDs) in different places worldwide. We are willing to offer > > secondary service for other ccTLDs. But there will be because of > > security/stability reasons a limit on the number of ccTLDs we want to run > > on a single machine. > > > > Sabine > > > > -- > > Sabine Dolderer > > DENIC eG > > Wiesenh?ttenplatz 26 > > D-60329 Frankfurt > > > > eMail: Sabine.Dolderer at denic.de > > Fon: +49 69 27235 0 > > Fax: +49 69 27235 235 > > > > > > > > Jan-Ahrent > > Czmok An: Joao Luis Silva Damas > > > > > ddiaz at ripe.net, routing-wg at ripe.net, > > net> lir-wg at ripe.net, tech-l at ams-ix.net, > > apops at lists.apnic.net, > > Gesendet von: nanog at merit.edu, > > apnic-talk at lists.apnic.net > > owner-lir-wg@ Thema: Re: KPNQwest ns.eu.net > > server. > > ripe.net > > > > > > 06.06.2002 > > 01:29 > > > > > > > > > > > > > > PostedDate: 06.06.2002 01:29:37 > > $MessageID: <20020606012937.2c476312.czmok at gatel.net> > > From: owner-lir-wg at ripe.net > > SendTo: Joao Luis Silva Damas > > CopyTo: > > randy at psg.com;ddiaz at ripe.net;routing-wg at ripe.net;lir-wg at ripe.net;tech-l at ams- > > ix.net;apops at lists.apnic.net;nanog at merit.edu;apnic-talk at lists.apnic.net > > > > Subject: Re: KPNQwest ns.eu.net server. > > Received: from smtp.denic.de ([194.246.96.22]) by notes.denic.de > > (Lotus Domino Release 5.0.8) with ESMTP id 2002060601283597:15602 > > ; Thu, 6 Jun 2002 01:28:35 +0200 > > Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by > > smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 > > +0200 > > Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 > > Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 > > Delivered_To: lists-lir-wg-out at lists.ripe.net > > PRINCIPAL: Jan-Ahrent Czmok > > In_Reply_To: > > References: <200206051725.g55HPlA05396 at birch.ripe.net> > > > > Organization: Global Access Telecommunications Inc. > > $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; i386-debian-linux-gnu) > > X_Ncc_RegID: de.gatel > > MIME_Version: 1.0 > > Precedence: bulk > > X_Loop_Detect: RIPE NCC > > SMTPOriginator: owner-lir-wg at ripe.net > > RouteServers: CN=notes/O=Denic > > RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 > > DeliveredDate: 06.06.2002 01:28:38 > > DENICDOCOPENCOUNT: 1 > > $MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, > > 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine > > Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 > > 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 > > BlindCopyTo: > > WebSubject: Re: KPNQwest ns.eu.net server. > > > > > > On Thu, 6 Jun 2002 01:08:46 +0200 > > Joao Luis Silva Damas wrote: > > > > > > > > At 11:04 -0700 5/6/02, Randy Bush wrote: > > > > > Given the current situation of KPNQwest and the possibility > > > >> of its services going offline sometime soon, the RIPE NCC in > > > >> agreement with KPNQwest will be temporally hosting this > > > >> server (ns.eu.net) in its premises. > > > > > > > >nice emergency hack and sorry to whine. but i used them both > > > >to get diversity. > > > > > > Hi Randy, > > > > > > there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both > > > secondary. So we will definitely request those ccTLDs to look for a > > > new host as soon as possible. > > > > Hi Randy, hi Joao, dear routing-wg, > > > > probably my Company (GATEL, AS13129) is able to host a secondary > > server for the ccTLDs. > > > > The question is rather what are the hardware "requirements" for the > > secondary > > server. > > > > We have sufficient bandwidth capacity available and rack space as well. > > > > > The rest can take bit more time to think what they want to do since > > > ns.eu.net will keep running. > > > > Well done ! Congrats for the good ideas and coordination work. > > > > > > > > We are offering secondary service on ns.ripe.net for any ccTLD that > > > we weren't sencodaring for, as are other people. > > > > > > The idea is not to have ns.eu.net running for ever, just to enable > > > people to have time to take rational decisions, without the fear of > > > having the server going away because of some unexpected turn of > > > events. > > > > > > > > > > >when in less of a panic, please move it to moscow or something. > > > > > > Panic? what panic? this is just common sense > > > > > > > right. it's not panic. > > > > --jan > > > > -- > > Jan Ahrent Czmok - Senior Network Engineer - Access Networks > > Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt > > voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok at gatel.de > > > > > > > > From ncc at ripe.net Thu Jun 6 18:00:01 2002 From: ncc at ripe.net (Paul Rendek) Date: Thu, 06 Jun 2002 18:00:01 +0200 Subject: ASO AC - Call for Nominations 2002 - RIPE NCC Service Region Message-ID: <5.1.0.14.2.20020606172130.02b67998@mailhost.ripe.net> Dear colleagues, We are pleased to announce a Call for Nominations to serve on the ASO Address Council(see below). In our effort to reach as many interested parties as possible you may receive multiple copies of this message. Please accept our apologies for this. The Call for Nominations for the ASO Address Council can also be found on our website at: http://www.ripe.net/ripencc/about/regional/icann.html Regards, Paul Rendek RIPE NCC Call for Nominations for Representatives to the ASO Address Council - RIPE NCC Service Region ---------------------------------------------------------- This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2002 one RIPE NCC service region Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. This document describes the functions of the ASO and the Address Council, as well as the nomination and selection process. If you are interested in nominating an individual, or if you are interested in submitting a self-nomination, please read this document carefully. 1. The Address Supporting Organisation --------------------------------------- The ASO was formed in August 1999 as a consensus-based advisory body within the ICANN framework through a Memorandum of Understanding (MoU) signed by the current Regional Internet Registries and ICANN. The ICANN Bylaws (http://www.icann.org/general/bylaws.htm#VI-A) assign to the ASO the responsibility for the development of global policies relating to the distribution and registration of Internet address space, inter-domain routing identifiers and that part of the DNS name space that is used to name these addresses and identifiers. More information about the ASO is available at: http://www.aso.icann.org 2. The Address Council - ---------------------- The ASO Address Council co-ordinates the process of policy development in areas within the responsibility of the ASO, according to procedures defined within the MoU and by the Address Council itself. Specifically, these include the hosting of an annual open General Assembly meeting and attending regular meetings either by teleconference or face-to-face, at which policy issues and submissions may be considered. The other major responsibility of the Address Council is the appointment of individuals to fill ASO seats on the ICANN Board of Directors, according to procedures defined within the MoU. More information on the Address Council is available at: http://www.aso.icann.org/ac/ 3. The Role of Members of the Address Council - --------------------------------------------- Each member of the Address Council is expected to serve for a period of 3 years. No member of the Address Council is entitled to any compensation from the ASO. No member of the Address Council can be indemnified by the ASO, nor can the ASO obtain insurance coverage relating to the liability of the actions of members of the Address Council. AC members do not represent any RIR, nor do they act as representatives of any other body. They are appointed in their individual capacity, and their membership cannot be proxied by any other individual or organisation. 4. Address Council Nominations Process - -------------------------------------- The term of Wilfried Woeber who has served as an Address Council member for the past three years will expire. One individual from the RIPE NCC service region will be selected to serve on the Address Council for a term of three years. The selection will be made through an open election process from the set of individuals who have been nominated within this process. Any individual may be nominated, with the exception of staff members of any Regional Internet Registry. Self-nominations are permitted. Nominations should be sent by email to by midnight CET on 9 August 2002. The information included with a nomination is to be submitted in English and should include: Name of Nominee: Country of residence: Organisation: Email Address: Postal Address: Biographical information: Motivation for nomination: Name of nominating individual: Organisation: Email Address: All nominees will be contacted via email to confirm their willingness to serve on the Address Council. If a nominee cannot be contacted via email, or does not respond, their nomination will not be confirmed and they will not be eligible for election to the Address Council. All confirmed nominations will be listed on the RIPE NCC web site after they are confirmed. All nominees will have the opportunity to submit a written statement in support of their nomination for publication on the web site. In addition, others may express support for nominated individuals simply by completing and submitting the nomination form provided above. 5. Address Council Selection Process - ------------------------------------ The process for the selection of a nominee to serve on the Address Council will involve an open election. The election process will be held during the plenary session of the RIPE 43 Meeting, 9-13 September 2002, in Rhodes, Greece. See the following URL for details about the selection procedure: http://www.ripe.net/ripe/wg/lir/adress_council-election.html More information about RIPE 43 is available at: http://www.ripe.net/ripe/meetings/current/ripe-43/ Important Dates: 9 August 2002 - deadline for Address Council nominations 26 August 2002 - deadline to post list of nominees on the RIPE NCC website 9-13 September 2002 - RIPE 43 Meeting, Rhodes, Greece From joao at ripe.net Thu Jun 6 18:28:31 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 6 Jun 2002 18:28:31 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020606163555.G13918@Space.Net> References: <200206061101.27288.dani@intelideas.com> <20020606163555.G13918@Space.Net> Message-ID: At 16:35 +0200 6/6/02, Gert Doering wrote: > >Hmmm? As far as I can see, RIPE has enough providers. The problem is >that the ccTLD secondary server hosted at KQ broke - ns.eu.net has not "broke". At least not yet. KPNQwest still has very competent people (and I would like to specifically thank Berislav Todorovic for embracing the idea of placing ns.eu.net outside KPNQwest to ensure stability and for all the support in actually doing it) The RIPE NCC doesn't currently need further support to operate the service, which is why we volunteered to do it, to provide a stable service until further steps are undertaken without the concern for the time period KPNQwest will be able to continue to operate. With time, since EUNet will not exist, ns.eu.net should also disappear (I am not quite sure the RIPE NCC would want to "own" the eu.net domain), but it should be after everyone has got time to think properly about a solution that suits them in the long term. Cheers, Joao From chrisy at flix.net Thu Jun 6 17:14:09 2002 From: chrisy at flix.net (Chrisy Luke) Date: Thu, 6 Jun 2002 16:14:09 +0100 Subject: KPNQwest ns.eu.net server. In-Reply-To: ; from steve@opaltelecom.co.uk on Thu, Jun 06, 2002 at 03:59:49PM +0100 References: <20020606141634.GC6350@puck.nether.net> Message-ID: <20020606161409.B52679@flix.net> Stephen J. Wilcox wrote (on Jun 06): > Indeed, for example k.root-servers.net is hosted at LINX and is reachable > globally by this kind of setup.. A few of LINXs' members also transit the services provided by LINX "for the good of the community" - ie, at zero cost. That includes k.root. I don't mind doing it. I wouldn't mind for others either. Chris. -- From david.conrad at nominum.com Thu Jun 6 17:59:58 2002 From: david.conrad at nominum.com (David Conrad) Date: Thu, 06 Jun 2002 08:59:58 -0700 Subject: KPNQwest ns.eu.net server. In-Reply-To: <01a401c20d63$735bbab0$6590a8c0@notebook> Message-ID: Hi, Just as a (potentially self-serving, apologies if this offends) aside, there are several companies that specialize in DNS hosting out there. The one that I'm most familiar with (Nominum's), co-locates our equipment at IXPs, has an open peering policy (of course), and has multiple (paid) transit providers. We decided upon this approach for exactly the reasons you indicate: they tend to be both more stable and more neutral than ISPs. We also believe locating at IXPs can reduce latency and improve performance. We were already providing secondary for one of the TLDs affected by ns.eu.net going away and would, of course, be happy to provide services to others. Rgds, -drc On 6/6/02 7:07 AM, "Nipper, Arnold" wrote: > > As a lot of people are offering secondary services: may be it's a good idea > to place infrastructural services at IXP. IXP seem to be more stable than > any ISPs and often more neutral than ISPs. > > Comments? > > > Arnold > -- > Arnold Nipper, DE-CIX, the German Internet Exchange > email: arnold.nipper at de-cix.net > mobile: +49 172 2650958 > handle: an6695-ripe > > > ----- Original Message ----- > From: "Sabine Dolderer/Denic" > To: "Jan-Ahrent Czmok" > Cc: ; ; ; > ; ; ; ; > ; > Sent: Thursday, June 06, 2002 9:43 AM > Subject: Re: Re: KPNQwest ns.eu.net server. > > > > Hello, > > DENIC runs currently several secondarys (not only DE but also for some > other TLDs) in different places worldwide. We are willing to offer > secondary service for other ccTLDs. But there will be because of > security/stability reasons a limit on the number of ccTLDs we want to run > on a single machine. > > Sabine > > -- > Sabine Dolderer > DENIC eG > Wiesenh?ttenplatz 26 > D-60329 Frankfurt > > eMail: Sabine.Dolderer at denic.de > Fon: +49 69 27235 0 > Fax: +49 69 27235 235 > > > > Jan-Ahrent > Czmok An: Joao Luis Silva Damas > > ddiaz at ripe.net, routing-wg at ripe.net, > net> lir-wg at ripe.net, tech-l at ams-ix.net, > apops at lists.apnic.net, > Gesendet von: nanog at merit.edu, > apnic-talk at lists.apnic.net > owner-lir-wg@ Thema: Re: KPNQwest ns.eu.net > server. > ripe.net > > > 06.06.2002 > 01:29 > > > > > > > PostedDate: 06.06.2002 01:29:37 > $MessageID: <20020606012937.2c476312.czmok at gatel.net> > From: owner-lir-wg at ripe.net > SendTo: Joao Luis Silva Damas > CopyTo: > randy at psg.com;ddiaz at ripe.net;routing-wg at ripe.net;lir-wg at ripe.net;tech-l at ams- > ix.net;apops at lists.apnic.net;nanog at merit.edu;apnic-talk at lists.apnic.net > > Subject: Re: KPNQwest ns.eu.net server. > Received: from smtp.denic.de ([194.246.96.22]) by notes.denic.de > (Lotus Domino Release 5.0.8) with ESMTP id 2002060601283597:15602 > ; Thu, 6 Jun 2002 01:28:35 +0200 > Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by > smtp.denic.de with smtp id 17FkCg-0004uX-00; Thu, 6 Jun 2002 01:28:34 > +0200 > Received: (qmail 11455 invoked by alias); 5 Jun 2002 23:28:15 -0000 > Received: (qmail 11452 invoked by uid 66); 5 Jun 2002 23:28:15 -0000 > Delivered_To: lists-lir-wg-out at lists.ripe.net > PRINCIPAL: Jan-Ahrent Czmok > In_Reply_To: > References: <200206051725.g55HPlA05396 at birch.ripe.net> > > Organization: Global Access Telecommunications Inc. > $Mailer: Sylpheed version 0.7.6claws16 (GTK+ 1.2.10; i386-debian-linux-gnu) > X_Ncc_RegID: de.gatel > MIME_Version: 1.0 > Precedence: bulk > X_Loop_Detect: RIPE NCC > SMTPOriginator: owner-lir-wg at ripe.net > RouteServers: CN=notes/O=Denic > RouteTimes: 06.06.2002 01:28:36-06.06.2002 01:28:38 > DeliveredDate: 06.06.2002 01:28:38 > DENICDOCOPENCOUNT: 1 > $MIMETrack: Itemize by SMTP Server on notes/Denic(Release 5.0.8 |June 18, > 2001) at 06.06.2002 01:28:36;MIME-CD by Notes Client on Sabine > Dolderer/Denic(Release 5.0.6a |January 17, 2001) at 06.06.2002 > 09:32:28;MIME-CD complete at 06.06.2002 09:32:28 > BlindCopyTo: > WebSubject: Re: KPNQwest ns.eu.net server. > > > On Thu, 6 Jun 2002 01:08:46 +0200 > Joao Luis Silva Damas wrote: > >> >> At 11:04 -0700 5/6/02, Randy Bush wrote: >>>> Given the current situation of KPNQwest and the possibility >>>> of its services going offline sometime soon, the RIPE NCC in >>>> agreement with KPNQwest will be temporally hosting this >>>> server (ns.eu.net) in its premises. >>> >>> nice emergency hack and sorry to whine. but i used them both >>> to get diversity. >> >> Hi Randy, >> >> there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both >> secondary. So we will definitely request those ccTLDs to look for a >> new host as soon as possible. > > Hi Randy, hi Joao, dear routing-wg, > > probably my Company (GATEL, AS13129) is able to host a secondary > server for the ccTLDs. > > The question is rather what are the hardware "requirements" for the > secondary > server. > > We have sufficient bandwidth capacity available and rack space as well. > >> The rest can take bit more time to think what they want to do since >> ns.eu.net will keep running. > > Well done ! Congrats for the good ideas and coordination work. > >> >> We are offering secondary service on ns.ripe.net for any ccTLD that >> we weren't sencodaring for, as are other people. >> >> The idea is not to have ns.eu.net running for ever, just to enable >> people to have time to take rational decisions, without the fear of >> having the server going away because of some unexpected turn of >> events. >> >>> >>> when in less of a panic, please move it to moscow or something. >> >> Panic? what panic? this is just common sense >> > > right. it's not panic. > > --jan > > -- > Jan Ahrent Czmok - Senior Network Engineer - Access Networks > Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt > voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok at gatel.de > > > > From john at sackheads.org Thu Jun 6 19:28:18 2002 From: john at sackheads.org (John Payne) Date: Thu, 6 Jun 2002 10:28:18 -0700 Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206061624.40230.dani@intelideas.com> References: <200206061624.40230.dani@intelideas.com> Message-ID: <20020606172818.GW74005@haybaler.sackheads.org> On Thu, Jun 06, 2002 at 04:24:40PM +0200, Daniel Concepcion wrote: > > Yes Neil, > > It should be interesting to know the 'official' requirements/recommendations > for ccTLD's hosting > For example: diversity geographical, network needs, security needs, building > environment., etc I've only been able to find a best practise guideline that specifies that the nameserver be online 24/7. (http://www.wwtld.org/ongoing/bestpractices/BestPractice_10Mar2001.html) I found it interesting to note that a significant number of cctld servers ignore the suggestions for root-servers in BCP40/RFC2870... "Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful." and leave recursion enabled on the ccTLD servers (2.5) - the old ns.eu.net was one of these, I believe RIPE have done the right thing with the new one. What is even more disturbing is that there is a non-zero number of ccTLD servers that are still cache poisonable. From phk at critter.freebsd.dk Thu Jun 6 17:16:41 2002 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 06 Jun 2002 17:16:41 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: Your message of "Thu, 06 Jun 2002 16:24:40 +0200." <200206061624.40230.dani@intelideas.com> Message-ID: <4016.1023376601@critter.freebsd.dk> In message <200206061624.40230.dani at intelideas.com>, Daniel Concepcion writes: >Yes Neil, > >It should be interesting to know the 'official' requirements/recommendations >for ccTLD's hosting >For example: diversity geographical, network needs, security needs, building >environment., etc The offcial requirements are: "No matter what, one of the servers will answer you." How you design and implement to that requirement, is your choice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From smb at research.att.com Thu Jun 6 20:12:36 2002 From: smb at research.att.com (Steven M. Bellovin) Date: Thu, 06 Jun 2002 14:12:36 -0400 Subject: KPNQwest ns.eu.net server. Message-ID: <20020606181237.DE1C27B4B@berkshire.research.att.com> In message <200206061624.40230.dani at intelideas.com>, Daniel Concepcion writes: > >Yes Neil, > >It should be interesting to know the 'official' requirements/recommendations >for ccTLD's hosting >For example: diversity geographical, network needs, security needs, building >environment., etc > I don't know of any official requirements. But RFCs 2182 and 2870 offer good guidance. (Some of 2870 is root zone-specific, but most of it would apply to a ccTLD server.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From john at sackheads.org Thu Jun 6 20:26:59 2002 From: john at sackheads.org (John Payne) Date: Thu, 6 Jun 2002 11:26:59 -0700 Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020606181237.DE1C27B4B@berkshire.research.att.com> References: <20020606181237.DE1C27B4B@berkshire.research.att.com> Message-ID: <20020606182659.GC74005@haybaler.sackheads.org> On Thu, Jun 06, 2002 at 02:12:36PM -0400, Steven M. Bellovin wrote: > > In message <200206061624.40230.dani at intelideas.com>, Daniel Concepcion writes: > > > >Yes Neil, > > > >It should be interesting to know the 'official' requirements/recommendations > >for ccTLD's hosting > >For example: diversity geographical, network needs, security needs, building > >environment., etc > > > > I don't know of any official requirements. But RFCs 2182 and 2870 > offer good guidance. (Some of 2870 is root zone-specific, but most of > it would apply to a ccTLD server.) Unfortunately most of the ccTLD nameserver operators ignore 2870 (including one of the authors...) From bmanning at karoshi.com Thu Jun 6 21:53:49 2002 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Thu, 6 Jun 2002 19:53:49 +0000 (UCT) Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020606181237.DE1C27B4B@berkshire.research.att.com> from "Steven M. Bellovin" at Jun 06, 2002 02:12:36 PM Message-ID: <200206061953.TAA01835@vacation.karoshi.com> > > > In message <200206061624.40230.dani at intelideas.com>, Daniel Concepcion writes: > > > >Yes Neil, > > > >It should be interesting to know the 'official' requirements/recommendations > >for ccTLD's hosting > >For example: diversity geographical, network needs, security needs, building > >environment., etc > > > > I don't know of any official requirements. But RFCs 2182 and 2870 > offer good guidance. (Some of 2870 is root zone-specific, but most of > it would apply to a ccTLD server.) > > --Steve Bellovin, http://www.research.att.com/~smb (me) It is perhaps instructive to note that when RFC 2870 was written, (most of) the roots also hosted COM,NET,ORG. Considered properly, RFC 2870 is more targeted toward gTLD servers. ccTLDs have a moderately different focus, while root servers are distinct from either in their requirements. --bill From john at sackheads.org Fri Jun 7 04:52:03 2002 From: john at sackheads.org (John Payne) Date: Thu, 6 Jun 2002 19:52:03 -0700 Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206061953.TAA01835@vacation.karoshi.com> References: <20020606181237.DE1C27B4B@berkshire.research.att.com> <200206061953.TAA01835@vacation.karoshi.com> Message-ID: <20020607025203.GK74005@haybaler.sackheads.org> On Thu, Jun 06, 2002 at 07:53:49PM +0000, bmanning at karoshi.com wrote: ... > > I don't know of any official requirements. But RFCs 2182 and 2870 > > offer good guidance. (Some of 2870 is root zone-specific, but most of > > it would apply to a ccTLD server.) > > > > --Steve Bellovin, http://www.research.att.com/~smb (me) > > It is perhaps instructive to note that when RFC 2870 was written, (most of) > the roots also hosted COM,NET,ORG. Considered properly, RFC 2870 is > more targeted toward gTLD servers. ccTLDs have a moderately different > focus, while root servers are distinct from either in their requirements. So how does the operation of gTLD servers differ from ccTLD servers, other than perhaps more focus on geographical diversity? From bmanning at karoshi.com Fri Jun 7 05:17:51 2002 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Fri, 7 Jun 2002 03:17:51 +0000 (UCT) Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020607025203.GK74005@haybaler.sackheads.org> from "John Payne" at Jun 06, 2002 07:52:03 PM Message-ID: <200206070317.DAA02461@vacation.karoshi.com> > > On Thu, Jun 06, 2002 at 07:53:49PM +0000, bmanning at karoshi.com wrote: > ... > > > I don't know of any official requirements. But RFCs 2182 and 2870 > > > offer good guidance. (Some of 2870 is root zone-specific, but most of > > > it would apply to a ccTLD server.) > > > > > > --Steve Bellovin, http://www.research.att.com/~smb (me) > > > > It is perhaps instructive to note that when RFC 2870 was written, (most of) > > the roots also hosted COM,NET,ORG. Considered properly, RFC 2870 is > > more targeted toward gTLD servers. ccTLDs have a moderately different > > focus, while root servers are distinct from either in their requirements. > > So how does the operation of gTLD servers differ from ccTLD servers, other > than perhaps more focus on geographical diversity? > number and distributions of registrations, legacy considerations that may reflect on legal issues, local policy issues that off the top of my head. .com vs .um -- for example. --bill From john at sackheads.org Fri Jun 7 07:21:21 2002 From: john at sackheads.org (John Payne) Date: Thu, 6 Jun 2002 22:21:21 -0700 Subject: KPNQwest ns.eu.net server. In-Reply-To: <200206070317.DAA02461@vacation.karoshi.com> References: <20020607025203.GK74005@haybaler.sackheads.org> <200206070317.DAA02461@vacation.karoshi.com> Message-ID: <20020607052121.GN74005@haybaler.sackheads.org> On Fri, Jun 07, 2002 at 03:17:51AM +0000, bmanning at karoshi.com wrote: ... > > So how does the operation of gTLD servers differ from ccTLD servers, other > > than perhaps more focus on geographical diversity? > > > > number and distributions of registrations, legacy considerations > that may reflect on legal issues, local policy issues > that off the top of my head. > > .com vs .um -- for example. number and distribution of registrations maybe - that comes down to number and sizing of servers and geography/network diversity, the others are at best operational concerns for the backend, not for the "frontend" DNS servers. Taking RFC 2870, why wouldn't all of section 2 and most of section 3 and section 4 be applicable to both gTLD and ccTLD servers (changing root zone and IANA as appropriate)? From ncc at ripe.net Thu Jun 6 18:00:01 2002 From: ncc at ripe.net (ncc at ripe.net) Date: Thu, 06 Jun 2002 18:00:01 +0200 Subject: ASO AC - Call for Nominations 2002 - RIPE NCC Service Region In-Reply-To: <5.1.0.14.2.20020606172130.02b67998@mailhost.ripe.net> References: <5.1.0.14.2.20020606172130.02b67998@mailhost.ripe.net> Message-ID: Dear colleagues, We are pleased to announce a Call for Nominations to serve on the ASO Address Council(see below). In our effort to reach as many interested parties as possible you may receive multiple copies of this message. Please accept our apologies for this. The Call for Nominations for the ASO Address Council can also be found on our website at: http://www.ripe.net/ripencc/about/regional/icann.html Regards, Paul Rendek RIPE NCC Call for Nominations for Representatives to the ASO Address Council - RIPE NCC Service Region ---------------------------------------------------------- This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2002 one RIPE NCC service region Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. This document describes the functions of the ASO and the Address Council, as well as the nomination and selection process. If you are interested in nominating an individual, or if you are interested in submitting a self-nomination, please read this document carefully. 1. The Address Supporting Organisation --------------------------------------- The ASO was formed in August 1999 as a consensus-based advisory body within the ICANN framework through a Memorandum of Understanding (MoU) signed by the current Regional Internet Registries and ICANN. The ICANN Bylaws (http://www.icann.org/general/bylaws.htm#VI-A) assign to the ASO the responsibility for the development of global policies relating to the distribution and registration of Internet address space, inter-domain routing identifiers and that part of the DNS name space that is used to name these addresses and identifiers. More information about the ASO is available at: http://www.aso.icann.org 2. The Address Council - ---------------------- The ASO Address Council co-ordinates the process of policy development in areas within the responsibility of the ASO, according to procedures defined within the MoU and by the Address Council itself. Specifically, these include the hosting of an annual open General Assembly meeting and attending regular meetings either by teleconference or face-to-face, at which policy issues and submissions may be considered. The other major responsibility of the Address Council is the appointment of individuals to fill ASO seats on the ICANN Board of Directors, according to procedures defined within the MoU. More information on the Address Council is available at: http://www.aso.icann.org/ac/ 3. The Role of Members of the Address Council - --------------------------------------------- Each member of the Address Council is expected to serve for a period of 3 years. No member of the Address Council is entitled to any compensation from the ASO. No member of the Address Council can be indemnified by the ASO, nor can the ASO obtain insurance coverage relating to the liability of the actions of members of the Address Council. AC members do not represent any RIR, nor do they act as representatives of any other body. They are appointed in their individual capacity, and their membership cannot be proxied by any other individual or organisation. 4. Address Council Nominations Process - -------------------------------------- The term of Wilfried Woeber who has served as an Address Council member for the past three years will expire. One individual from the RIPE NCC service region will be selected to serve on the Address Council for a term of three years. The selection will be made through an open election process from the set of individuals who have been nominated within this process. Any individual may be nominated, with the exception of staff members of any Regional Internet Registry. Self-nominations are permitted. Nominations should be sent by email to by midnight CET on 9 August 2002. The information included with a nomination is to be submitted in English and should include: Name of Nominee: Country of residence: Organisation: Email Address: Postal Address: Biographical information: Motivation for nomination: Name of nominating individual: Organisation: Email Address: All nominees will be contacted via email to confirm their willingness to serve on the Address Council. If a nominee cannot be contacted via email, or does not respond, their nomination will not be confirmed and they will not be eligible for election to the Address Council. All confirmed nominations will be listed on the RIPE NCC web site after they are confirmed. All nominees will have the opportunity to submit a written statement in support of their nomination for publication on the web site. In addition, others may express support for nominated individuals simply by completing and submitting the nomination form provided above. 5. Address Council Selection Process - ------------------------------------ The process for the selection of a nominee to serve on the Address Council will involve an open election. The election process will be held during the plenary session of the RIPE 43 Meeting, 9-13 September 2002, in Rhodes, Greece. See the following URL for details about the selection procedure: http://www.ripe.net/ripe/wg/lir/adress_council-election.html More information about RIPE 43 is available at: http://www.ripe.net/ripe/meetings/current/ripe-43/ Important Dates: 9 August 2002 - deadline for Address Council nominations 26 August 2002 - deadline to post list of nominees on the RIPE NCC website 9-13 September 2002 - RIPE 43 Meeting, Rhodes, Greece From dolderer at denic.de Fri Jun 7 09:51:11 2002 From: dolderer at denic.de (Sabine Dolderer/Denic) Date: Fri, 7 Jun 2002 09:51:11 +0200 Subject: KPNQwest ns.eu.net server. Message-ID: Hello Arnold, On 06.06.2002 16:55 Arnold Nipper wrote: > > On Thu, Jun 06, 2002 at 04:31:21PM +0200, Daniel Concepcion wrote: > > > > > > Yes, but there is problem about the transit for the network of the IXP > > In my experience, some big providers only have the commercial view of > > internet. > > If an IXP decides to offer infrastructural services then you have to buy > upstream of course. > > > Really, if all the IXP members give some transit to the IXP for essential > > services, internet will be more robust. > > > > At least each IXP member would have direct connectivity to such > infrastructural services (DNS, NTP, WHOIS, NNTP??) and thereby their > customers would benefit from it. I agree that IXPs would be very gould locations as they offer network diversity, but there is one question still open and that is who will be the one running the and monitoring the server. And we at DENIC have seen in the last years an increasing demand in running the servics by ourself as only then we have the complete control and information about statistics, network attacks, performance ... There is a project within CENTR where we try to share secondary services on one host with the advantage for all geting these informations. (And yes we are still working to connect to DECIX ;-) ) Sabine > > And an IXP should be in a good position to get upstream :-)) And for > the commercials: these services are not for free of course. So bills > for IXP members will drop not raise. > > > -- Arnold > > -- Sabine Dolderer DENIC eG Wiesenh?ttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer at denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 From kurtis at kurtis.pp.se Fri Jun 7 09:58:46 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 07 Jun 2002 09:58:46 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: <203570000.1023374765@slimsixten.pilsnet.sunet.se> References: <01a401c20d63$735bbab0$6590a8c0@notebook> <20020606141634.GC6350@puck.nether.net> <203570000.1023374765@slimsixten.pilsnet.sunet.se> Message-ID: <50420410.1023443925@LTP012682.kpnqwest.com> > . They have an AS of their own, which is free to > peer with, in which a number of crucial services are located, for ...as long as you provide transit for free. Which I don't see why you wouldn't. Even Tier-1 providers (and ex- such..:) ) do this. Best regards, - kurtis - From arnold.nipper at de-cix.net Fri Jun 7 10:22:27 2002 From: arnold.nipper at de-cix.net (Arnold Nipper) Date: Fri, 7 Jun 2002 10:22:27 +0200 Subject: KPNQwest ns.eu.net server. In-Reply-To: References: Message-ID: <20020607102226.A5280@gateway.nipper.de> Hallo Sabine, lange nichts gehoert ... On Fri, Jun 07, 2002 at 09:51:11AM +0200, Sabine Dolderer/Denic wrote: > > > > At least each IXP member would have direct connectivity to such > > infrastructural services (DNS, NTP, WHOIS, NNTP??) and thereby their > > customers would benefit from it. > > I agree that IXPs would be very gould locations as they offer network > diversity, but there is one question still open and that is who will be the > one running the and monitoring the server. And we at DENIC have seen in the > last years an increasing demand in running the servics by ourself as only > then we have the complete control and information about statistics, network > attacks, performance ... > Keep it simple ... the IXPs (e.g. Euro-IX) could/should provide the basis. I.e. taking care for excellent colo, sufficient connectivity, one-stop-shop etc. Interested parties would install the services by themselves and would be responsible to run them. Parties could be CENTR, DE-NIC, ICANN, EUxxx and so on. I would like to know more about the CENTR sss iniative. Whom should I contact? Arnold -- Arnold Nipper Email: arnold.nipper at de-cix.net DE-CIX, The German Internet Exchange Mobile: +49 172 2650958 From bmanning at karoshi.com Fri Jun 7 14:18:19 2002 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Fri, 7 Jun 2002 12:18:19 +0000 (UCT) Subject: KPNQwest ns.eu.net server. In-Reply-To: <20020607052121.GN74005@haybaler.sackheads.org> from "John Payne" at Jun 06, 2002 10:21:21 PM Message-ID: <200206071218.MAA02823@vacation.karoshi.com> > number and distribution of registrations maybe - that comes down to number > and sizing of servers and geography/network diversity, the others are at best > operational concerns for the backend, not for the "frontend" DNS servers. backend/frontend? > Taking RFC 2870, why wouldn't all of section 2 and most of section 3 and > section 4 be applicable to both gTLD and ccTLD servers (changing root zone > and IANA as appropriate)? sure, you could take those sections as a starting point. But why stop at TLDs? Why not make this applicable to -ALL- dns servers? The problem we tried to tackle with RFC 2010, and apparently not well considered by the authors of RFC 2870 is the difficulty of segmenting system availabilty from operations. So to clarify, are you talking about the server operations or are you talking about availability of the zone? RFC 2870 muddies the waters here. You seem to be leaning toward ensuring availablity. RFC 2010 attempted to make the distinction. gTLD servers, today, have an operational requirement to run on 64bit hardware. Few if any ccTLDs have that as a requirement. The root servers may not see that requirement until 2038 or so... In any case, RFC 2870 is getting long in the tooth and From Valdis.Kletnieks at vt.edu Fri Jun 7 14:36:21 2002 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 07 Jun 2002 08:36:21 -0400 Subject: KPNQwest ns.eu.net server. In-Reply-To: Your message of "Fri, 07 Jun 2002 12:18:19 -0000." <200206071218.MAA02823@vacation.karoshi.com> References: <200206071218.MAA02823@vacation.karoshi.com> Message-ID: <200206071236.g57CaLSA002941@turing-police.cc.vt.edu> On Fri, 07 Jun 2002 12:18:19 -0000, bmanning at karoshi.com said: > sure, you could take those sections as a starting point. But why > stop at TLDs? Why not make this applicable to -ALL- dns servers? Mighty fine pharmaceuticals you got there. ;) I'd settle for a requirement that dns servers have *basic* configuration correct - I mean, is it *that* hard to avoid lame delegations and typos in the SOA or NS records? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ehall at ehsco.com Fri Jun 7 18:06:29 2002 From: ehall at ehsco.com (Eric A. Hall) Date: Fri, 07 Jun 2002 11:06:29 -0500 Subject: KPNQwest ns.eu.net server. References: <200206071218.MAA02823@vacation.karoshi.com> <200206071236.g57CaLSA002941@turing-police.cc.vt.edu> Message-ID: <3D00DA05.87751EBE@ehsco.com> Valdis.Kletnieks at vt.edu wrote: > I mean, is it *that* hard to avoid lame delegations and typos in > the SOA or NS records? apparently -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From arif.oktay at telekom.gov.tr Mon Jun 10 10:48:54 2002 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Mon, 10 Jun 2002 11:48:54 +0300 Subject: updating route object Message-ID: <5.1.0.14.0.20020610114530.01db86a0@mail.telekom.gov.tr> Hi, I receive following error from db when I try to update a route object. I provide proper authorization schema. Can anybody help me about this problem ? Regards, arif Hierarchical authorisation failed, request forwarded to maintainer. ------------------------ Arif OKTAY Tel:+90 312 5551922 Fax:+90 312 5551959 ------------------------ ... TYLER And, now it's gone. JACK All gone. --------------------------------------- Fight Club --- From lir-wg at FreiNet.de Mon Jun 10 15:18:07 2002 From: lir-wg at FreiNet.de (Alexander Bochmann) Date: Mon, 10 Jun 2002 15:18:07 +0200 Subject: COLT Telecom and the RIPE DB copyright Message-ID: <20020610151807.E1308@freinet.de> Hi, today we received two mailings from COLT Telekom, addressed to "2i Distribution & Solution, Offenburg" and "2i Distribution & Solution, Loerrach und Waldshut" We changed our company name about 4 years ago, and these two strings do only appear in the RIPE database for two old networks we previously used as XLINK PoP. I have heard from others (and from some of our customers) that they got the same mailing, also destined to addresses that have obviously been retrieved from the RIPE DB (the content of the mailing is targeted to KPNQwest Germany customers who are urged to change to COLT). I think the RIPE DB copyright is quite clear on the use of it's data for advertizing purposes. Yet I never heard of an occasion where RIPE actively enforced the copyright. Nevertheless, this seems to be a case of a quite wide spread abuse - anybode else here who recieved this or a similar mailing from COLT and would like to see RIPE take action? Regards, A. Bochmann From andrei at ripe.net Mon Jun 10 15:19:32 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 10 Jun 2002 15:19:32 +0200 Subject: updating route object References: <5.1.0.14.0.20020610114530.01db86a0@mail.telekom.gov.tr> Message-ID: <3D04A764.5030302@ripe.net> Dear Arif, Arif OKTAY wrote: > > Hi, > > I receive following error from db when I try to update a route object. I > provide > proper authorization schema. Can anybody help me about this problem ? > Could you please send more detailed information (time of the update, the object you were trying to update) to the database administrator at ripe-dbm at ripe.net? > Regards, > arif > Thanks, Andrei Robachevsky DB Group RIPE NCC > > Hierarchical authorisation failed, request forwarded to maintainer. > > > > ------------------------ > Arif OKTAY > Tel:+90 312 5551922 > Fax:+90 312 5551959 > ------------------------ > ... > TYLER > And, now it's gone. > JACK > All gone. > --------------------------------------- Fight Club --- From ripe-dbm at ripe.net Mon Jun 10 15:21:00 2002 From: ripe-dbm at ripe.net (RIPE NCC Staff) Date: Mon, 10 Jun 2002 15:21:00 +0200 Subject: updating route object Message-ID: <200206101321.g5ADL0E20850@x9.ripe.net> Dear Arif, The authentication mechanism for routes in RPSL specification is quite different than that of v2 software which we used prior to April 23, 2001. In the new authentication scheme, also the authorisation from aut-num object mentioned in 'origin' attribute of the route must be satisfied. If the authorisation from that aut-num object fails or the aut-num object does not exist, than the creation of the route object is rejected. Please see a graphical representation of this at http://www.ripe.net/ripencc/faq/database/qa4.html#5 Also please see RFC2725, page 36 for this (ftp://ftp.ripe.net/rfc/rfc2725.txt). RIPE Database Reference Manual is available at http://www.ripe.net/ripe/docs/databaseref-manual.html Please contact us at ripe-dbm at ripe.net with more details and we will help you to find the solution. Regards, Katie Petrusha _____________________________ RIPE Database Administration. Original message follows: ------------------------ > X-Recipient: > Delivered-To: lists-lir-wg-out at lists.ripe.net > X-Sender: arif.oktay at mail.telekom.gov.tr > X-Mailer: QUALCOMM Windows Eudora Version 5.1 > Date: Mon, 10 Jun 2002 11:48:54 +0300 > To: lir-wg at ripe.net > From: Arif OKTAY > Subject: updating route object > Precedence: bulk > X-Loop-Detect: RIPE NCC > > > Hi, > > I receive following error from db when I try to update a route object. I > provide > proper authorization schema. Can anybody help me about this problem ? > > Regards, > arif > > > Hierarchical authorisation failed, request forwarded to maintainer. > > > > ------------------------ > Arif OKTAY > Tel:+90 312 5551922 > Fax:+90 312 5551959 > ------------------------ > ... > TYLER > And, now it's gone. > JACK > All gone. > --------------------------------------- Fight Club --- -- Shane Kerr RIPE NCC From ncc at ripe.net Mon Jun 10 15:36:33 2002 From: ncc at ripe.net (Paul Rendek) Date: Mon, 10 Jun 2002 15:36:33 +0200 Subject: New Draft in-addr.arpa Policy Document for Review Message-ID: <5.1.0.14.2.20020610153554.00ad9db0@mailhost.ripe.net> Dear LIRs, We are pleased to announce the availability of the new draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC Service Region" document. The draft document can be found in the text to follow and is also available on the RIPE NCC website at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documents/ The deadline for comments and suggestions is Monday, 24 June 2002. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. All comments and suggestions should be sent to . Regards, Paul Rendek RIPE NCC === Draft: Policy for reverse address delegation under in-addr.arpa in the RIPE NCC service region Author(s): Document ID: TBA Date: June 2002 Obsoletes: [insert doc #] Abstract This document describes the policy for reverse delegation of IPv4 assignments and allocations in the RIPE NCC service region. Table of Contents 1.0 Introduction 2.0 Obtaining Delegation of an in-addr.arpa Sub-zone 3.0 Reverse Delegation for Provider Aggregatable (PA) Address Space 4.0 Reverse Delegation for Provider Independent (PI) Address Space 5.0 Duration of the Reverse Delegation 1 Introduction The RIPE NCC provides, as part of its services, the necessary support to enable the reverse resolution of IPv4 addresses into domain names. This service is implemented under the in-addr subdomain described in the "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"[RFC3172] document. Delegations for IPv4 addresses contained in allocations made by the RIPE NCC (reverse delegations) are made by the RIPE NCC to the Local Internet Registries (LIRs) and further by the LIRs to ISPs or end users. 2 Obtaining delegation of an in-addr.arpa sub-zone The RIPE NCC will only accept requests for reverse delegation under in-addr.arpa from LIRs. End users must send their requests to the LIR from which they obtained the addresses, or in the case of Provider Independent addresses, to any of the LIRs of their choice.A list of LIRs can be found at: http://www.ripe.net/ripencc/mem-services/general/indices/index.html The procedure for requesting the delegation of zones under in-addr.arpa is published at: http://www.ripe.net/reverse Advice on configuring name servers is available in "Common DNS operational and Configuration Errors" [RFC1912] 3 Reverse delegation for Provider Aggregatable (PA) address space The RIPE NCC accepts requests for reverse delegation solely for address space that has been registered by the LIR as assigned to end users in the RIPE Whois Database. The RIPE NCC will only make delegations on 8-bit boundaries (/16 or /24), though multiple delegations may be requested to cover CIDR blocks bigger than a /24. LIRs should maintain DNS resource records for address space assigned to end users from their own address space, even if the user obtains connectivity from a different LIR. 4 Reverse delegation for Provider Independent (PI) address space The RIPE NCC will reverse delegate a zone of in-addr.arpa to an end user that has been assigned PI space. However, the request must be sent to the RIPE NCC via an LIR, as described above. For delegations of address blocks smaller than a /24 the method described in "Classless IN-ADDR.ARPA delegation"[RFC2317] will be used. 5 Duration of the reverse delegation Provision of reverse delegation services by the RIPE NCC is a membership service. As such, the RIPE NCC will only accept requests for delegation and modifications of delegations from LIRs that are up-to-date with regard to their membership duties. LIRs should provide reverse delegation corresponding to an assignment during the complete validity period of the assignment. -- END From Marcus.Ruchti at colt.de Mon Jun 10 15:57:54 2002 From: Marcus.Ruchti at colt.de (Marcus.Ruchti at colt.de) Date: Mon, 10 Jun 2002 15:57:54 +0200 Subject: ALLOCATED UNSPECIFIED ??? Message-ID: Hello, we've problems with creating a route object for the network 193.102.74.0/24. Sony Europe is our customer and told us, this network is their PI space, but the status for the whole IP block is ALLOCATED UNSPECIFIED ! What does this mean an how can I create (or who) a route object for this network ? Thanks, Marcus inetnum: 193.96.0.0 - 193.103.255.255 netname: DE-EUNET-193-96-193-103 descr: ALLOCATED BLOCK descr: Provider Local Registry descr: UUNET/DE country: DE admin-c: HE15-RIPE tech-c: HE15-RIPE status: ALLOCATED UNSPECIFIED notify: robot at de.uu.net notify: hostmaster at de.uu.net mnt-by: RIPE-NCC-HM-MNT mnt-lower: UUNETDE-I changed: od at Germany.EU.net 19970220 changed: od at de.uu.net 19971119 changed: hostmaster at de.uu.net 19980120 changed: od at de.uu.net 19990123 changed: hostmaster at ripe.net 19990309 changed: hostmaster at ripe.net 19990817 changed: hostmaster at ripe.net 19990818 changed: hostmaster at ripe.net 20020510 changed: hostmaster at ripe.net 20020522 source: RIPE inetnum: 193.102.74.0 - 193.102.74.255 netname: SONY-STC descr: Sony Europe GmbH, STC country: DE admin-c: VM1-RIPE tech-c: PB4313-RIPE tech-c: MV1843-RIPE mnt-by: RIPE-NCC-NONE-MNT changed: ip at Germany.EU.net 19940726 changed: mn at Germany.EU.net 19940802 changed: ripe-dbm at ripe.net 19990706 changed: ripe-dbm at ripe.net 20000225 source: RIPE route: 193.96.0.0/13 descr: UUNETDE-AGG-193.96 origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: mz at de.uu.net 20011123 source: RIPE From neil at COLT.NET Mon Jun 10 15:33:08 2002 From: neil at COLT.NET (Neil J. McRae) Date: Mon, 10 Jun 2002 14:33:08 +0100 Subject: COLT Telecom and the RIPE DB copyright In-Reply-To: <20020610151807.E1308@freinet.de> Message-ID: Can you forward me the messages directly and I'll ensure that whoever did this +never+ does anything so stupid every again. My sincerest apologies on behalf of COLT. Regards, Neil. -- Neil J. McRae - COLT neil at COLT.NET > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Alexander Bochmann > Sent: 10 June 2002 14:18 > To: lir-wg at ripe.net > Subject: COLT Telecom and the RIPE DB copyright > > > Hi, > > today we received two mailings from COLT Telekom, > addressed to > > "2i Distribution & Solution, Offenburg" and > "2i Distribution & Solution, Loerrach und Waldshut" > > We changed our company name about 4 years ago, and > these two strings do only appear in the RIPE database > for two old networks we previously used as XLINK PoP. > > I have heard from others (and from some of our customers) > that they got the same mailing, also destined to addresses > that have obviously been retrieved from the RIPE DB (the > content of the mailing is targeted to KPNQwest Germany > customers who are urged to change to COLT). > > I think the RIPE DB copyright is quite clear on > the use of it's data for advertizing purposes. Yet I > never heard of an occasion where RIPE actively enforced > the copyright. > > Nevertheless, this seems to be a case of a quite wide > spread abuse - anybode else here who recieved this or a > similar mailing from COLT and would like to see RIPE > take action? > > Regards, > > A. Bochmann > > From marcel at slowthinkers.net Mon Jun 10 20:06:44 2002 From: marcel at slowthinkers.net (Anne Marcel Roorda) Date: Mon, 10 Jun 2002 20:06:44 +0200 Subject: ALLOCATED UNSPECIFIED ??? In-Reply-To: Your message of "Mon, 10 Jun 2002 15:57:54 +0200." Message-ID: <200206101806.g5AI6j986632@spamtrap.slowthinkers.net> Hi Marcus, inetnum: 193.96.0.0 - 193.103.255.255 netname: DE-EUNET-193-96-193-103 admin-c: HE15-RIPE tech-c: HE15-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: UUNETDE-I role: Hostmaster UUNET Deutschland e-mail: hostmaster at de.uu.net nic-hdl: HE15-RIPE Please contact hostmaster at de.uu.net if they have not yet contacted you directly. ALLOCATED means that the block has been given to a LIR for further assignment. UNSPECIFIED means that the LIR may either do PI or PA assignments from this block (or is a legacy allocation). All INETNUM objects that do not have a status: line should be treated as ASSIGNED PI. From ripe-238: 3.6.5 Protection of route object space The route object creation must satisfy several authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or, if no applicable route object is found, then an inetnum. Finally the creation must be authorised by the maintainer of the route object itself referenced by the "mnt-by:" attribute of the object. When checking for prefix authorisation, an exact route object prefix match is checked for first. If there is no exact match, then a longest prefix match that is less specific than the prefix is searched for. If the route prefix search fails, then a search is performed for an inetnum object that exactly matches the prefix or for the most specific inetnum object that is less specific than the route object submission. The aut-num object used for authentication checks is referenced by the "origin:" attribute of the route object. A route object must pass authorisation from both the referenced aut-num object and the route or inetnum object. Authorisation shall be tested using the maintainer(s) referenced in the "mnt-routes:" attribute(s) first. If that check fails, the "mnt-lower:" attributes are checked. If that check fails, the "mnt-by:" attributes are used for the authorisation check. Regards, - marcel In message , Marc us.Ruchti at colt.de writes: > Hello, > > we've problems with creating a route object for > the network 193.102.74.0/24. > Sony Europe is our customer and told us, > this network is their PI space, but the status for the whole > IP block is ALLOCATED UNSPECIFIED ! > What does this mean an how can I create (or who) > a route object for this network ? From zeidler at kpnqwest.de Mon Jun 10 16:50:55 2002 From: zeidler at kpnqwest.de (Petra Zeidler) Date: Mon, 10 Jun 2002 16:50:55 +0200 Subject: COLT Telecom and the RIPE DB copyright In-Reply-To: ; from Neil J. McRae on Mon, Jun 10, 2002 at 02:33:08PM +0100 References: <20020610151807.E1308@freinet.de> Message-ID: <20020610165055.A3019@kpnqwest.de> Hi, Thus wrote Neil J. McRae (neil at COLT.NET): > Can you forward me the messages directly and I'll ensure > that whoever did this +never+ does anything so stupid every > again. My sincerest apologies on behalf of COLT. I received such in paper mail, obviously "Xlink - IT technical services" didn't match "KPNQwest" in the instigators program. The address even contained the remarks line from my handle. The letter was signed by Horst Enzelmueller, CEO, and Peter Metz, sales director. kind regards, Petra Zeidler (who's really got other stuff to mind than sales *censored* antics currently). -- [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 marcus at ri.st Tue Jun 11 09:57:27 2002 From: marcus at ri.st (Marcus Rist) Date: Tue, 11 Jun 2002 09:57:27 +0200 Subject: ALLOCATED UNSPECIFIED ??? In-Reply-To: ; from Marcus.Ruchti@colt.de on Mon, Jun 10, 2002 at 03:57:54PM +0200 References: Message-ID: <20020611095727.A1864@c3po.netplace.de> Hi, Marcus.Ruchti at colt.de wrote To lir-wg at ripe.net: > we've problems with creating a route object for > the network 193.102.74.0/24. > Sony Europe is our customer and told us, > this network is their PI space, but the status for the whole > IP block is ALLOCATED UNSPECIFIED ! > What does this mean an how can I create (or who) > a route object for this network ? This has nothing to do with PI vs. PA vs. UNSPECIFIED. To establish an route-object in the RIPE-db you have to fullfill the following maintainers: - the maintainer of the inetnum - the maintainer of the AS number referenced in the route-object as origin - the maintainer of a less specific route-object (if there is any) Maintainers for route-objects are always checked in the order mnt-routes, mnt-lower, mnt-by. In your concrete case this would mean you have to fullfill RIPE-NCC-NONE-MNT (inetnum), DE-COLT-MNT (AS9126) and UUNET-MNT (193.96.0.0/13). I don't know how this is possible to achieve. IMHO the only possibility is to get an route-object entered by RIPE hostmaster who can overwrite the authorisations needed. I would like to hear an official statement from RIPE about this, if this is the only way to go and what the procedure should look like. -Marcus -- Marcus Rist From dr at cluenet.de Tue Jun 11 12:03:46 2002 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 11 Jun 2002 12:03:46 +0200 Subject: ALLOCATED UNSPECIFIED ??? In-Reply-To: <20020611095727.A1864@c3po.netplace.de>; from marcus@ri.st on Tue, Jun 11, 2002 at 09:57:27AM +0200 References: <20020611095727.A1864@c3po.netplace.de> Message-ID: <20020611120346.A2561@homebase.cluenet.de> On Tue, Jun 11, 2002 at 09:57:27AM +0200, Marcus Rist wrote: > In your concrete case this would mean you have to fullfill > RIPE-NCC-NONE-MNT (inetnum), DE-COLT-MNT (AS9126) and UUNET-MNT > (193.96.0.0/13). > > I don't know how this is possible to achieve. Colt signs their request with their PGP key, sending the mail to UUnet instead of auto-dbm. UUnet then signs the Colt request with their key and send it to auto-dbm. Caveat: never tested that, but I was told it should work. Regards, Daniel From joao at ripe.net Tue Jun 11 15:09:27 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 11 Jun 2002 15:09:27 +0200 Subject: ALLOCATED UNSPECIFIED ??? In-Reply-To: <20020611120346.A2561@homebase.cluenet.de> References: <20020611095727.A1864@c3po.netplace.de> <20020611120346.A2561@homebase.cluenet.de> Message-ID: At 12:03 +0200 11/6/02, Daniel Roesen wrote: >On Tue, Jun 11, 2002 at 09:57:27AM +0200, Marcus Rist wrote: >> In your concrete case this would mean you have to fullfill >> RIPE-NCC-NONE-MNT (inetnum), DE-COLT-MNT (AS9126) and UUNET-MNT >> (193.96.0.0/13). >> >> I don't know how this is possible to achieve. > >Colt signs their request with their PGP key, sending the mail to >UUnet instead of auto-dbm. UUnet then signs the Colt request with their >key and send it to auto-dbm. Caveat: never tested that, but I was told >it should work. This is correct. The authorization model of the RIPE DB is rps-auth (rfc2725). It provides a means of ensuring not only proper authentication (normal maintainers as before) but also provides a means to have proper authorization (when creating a new route, did the owner of the AS allow to put them down as origin AS, and did the holder of the address space allow the AS holder to announce the prefix?) PGP is the best suited way of doing this. MAIL-FROM fails because an email can only have one from address. Passwords have the little problem that, since the password is sent in cleartext in the update, you would disclose your password to someone else when co-signing an update. So if you need to do co-signing the advise is to use PGP in your maintainers Regards Joao Damas RIPE NCC > >Regards, >Daniel From arif.oktay at telekom.gov.tr Wed Jun 12 09:06:41 2002 From: arif.oktay at telekom.gov.tr (Arif OKTAY) Date: Wed, 12 Jun 2002 10:06:41 +0300 Subject: response time for RIPE-NCC-HM-MNT Message-ID: <5.1.0.14.0.20020612100154.01d63410@mail.telekom.gov.tr> Hi all, I'm waiting for an update via RIPE-NCC-HM-MNT. What's the response time for RIPE-NCC-HM-MNT operations ? Are the requests for this maintainer delivered to the normal hostmaster que or do they have different que and processing order ? I'll be happy if someone can inform me. Regards, arif ao189-ripe ------------------------ Arif OKTAY Tel:+90 312 5551922 Fax:+90 312 5551959 ------------------------ JACK (V.O.) When deep space exploration ramps up, it will be corporations that name everything. The IBM Stellar Sphere. The Philip Morris Galaxy. Planet Starbucks. --------------------------------------- Fight Club --- From Daniel.Karrenberg at ripe.net Wed Jun 12 09:11:55 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 12 Jun 2002 09:11:55 +0200 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: <5.1.0.14.2.20020612135731.0258b5e0@localhost> References: Message-ID: <4.3.2.7.2.20020612090705.025acd78@localhost.ripe.net> At 06:00 AM 6/12/2002, Geoff Huston wrote: >However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. When these attributes were created, those particular words were in deemed both descriptive and clear. Maybe the language concerned has shifted underneath in the meantime ;-). As a native speaker of one of its dialects, would you make a suggestion for improvement? Daniel From leo at ripe.net Wed Jun 12 09:56:06 2002 From: leo at ripe.net (leo vegoda) Date: Wed, 12 Jun 2002 09:56:06 +0200 Subject: response time for RIPE-NCC-HM-MNT In-Reply-To: <5.1.0.14.0.20020612100154.01d63410@mail.telekom.gov.tr> References: <5.1.0.14.0.20020612100154.01d63410@mail.telekom.gov.tr> Message-ID: <20020612075605.GA17389@ripe.net> Dear Arif, On Wed, Jun 12, 2002 at 10:06:41AM +0300, Arif OKTAY wrote: Re: response time for RIPE-NCC-HM-MNT [...] > I'm waiting for an update via RIPE-NCC-HM-MNT. What's the response time for > RIPE-NCC-HM-MNT operations ? Are the requests for this maintainer delivered > to the normal hostmaster que or do they have different que and processing > order ? I'll be happy if someone can inform me. Changes that need to be made to objects maintained by RIPE-NCC-HM-MNT should be sent to . Requests received by are prioritised. We try to asses the urgency of a request and deal with them accordingly. Your request has been received and will be dealt with shortly. Kind Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From michel at arneill-py.sacramento.ca.us Wed Jun 12 05:12:02 2002 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 11 Jun 2002 20:12:02 -0700 Subject: [apnic-talk] Status field for inet6num objects Message-ID: <2B81403386729140A3A899A8B39B046405E0F2@server2000.arneill-py.sacramento.ca.us> > Anne Lord wrote: > There is no PI in IPv6. > This can't be said often enough. We are working on two new types of v6 addresses that are neither PA nor PI for multihoming. Please keep in mind that PA does not provide enough functionality; if no multihoming protocol is released in a timely manner you will inevitably have PI, or whatever you want to call everyone becoming a LIR. Michel. From gih at telstra.net Wed Jun 12 06:00:50 2002 From: gih at telstra.net (Geoff Huston) Date: Wed, 12 Jun 2002 14:00:50 +1000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: References: Message-ID: <5.1.0.14.2.20020612135731.0258b5e0@localhost> >To clarify, the values that APNIC would prefer to use are: > >ALLOCATED PORTABLE >ALLOCATED NON-PORTABLE >ASSIGNED PORTABLE >ASSIGNED NON-PORTABLE > >As I mentioned before, these values would be consistent with those in >IPv4 (which take effect in August when the migration to version 3 of the >RIPE database is complete). > >Comments? I would be in favour of this clarity in the field regarding PORTABLE and NON_PORTABLE. However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. regards, Geoff From anne at apnic.net Wed Jun 12 02:35:36 2002 From: anne at apnic.net (Anne Lord) Date: Wed, 12 Jun 2002 10:35:36 +1000 (EST) Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: Message-ID: hi Robert, > There is no PI in IPv6. > This can't be said often enough. What is an IPv6 IX assignment? > > With the values suggested: > > > > RIR-allocated > > LIR-allocated > > Assigned > > > > this does not seem possible anymore. > > Right. It is not necessary. I think the distinction is important - it is very useful to be able to label address space as portable or non portable (or PI PA for RIPE) especially as we still encounter many that think that all address space is portable. > > To clarify, the values that APNIC would prefer to use are: > > > > ALLOCATED PORTABLE > > ALLOCATED NON-PORTABLE > > ASSIGNED PORTABLE > > ASSIGNED NON-PORTABLE > > This does not take into account that there are no portable addresses, what is an allocation from an RIR to you as an LIR? > and that there is an additional level "LIR-allocated" which IPv4 does > not have. In IPv4 this is something we plan to discuss with the community in the future as feedback to APNIC indicates that there is a requirement for it. cheers, Anne -- > I like the original proposal of not having the status generated > automatically, and giving them a meaning clearly reflected in the > name. > > Robert > From anne at apnic.net Wed Jun 12 02:11:34 2002 From: anne at apnic.net (Anne Lord) Date: Wed, 12 Jun 2002 10:11:34 +1000 (EST) Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: Message-ID: Hi Joao, Many thanks for your posting. We have had some discussions at the Secretariat about the proposed values and have the following comments (see below): On Fri, 31 May 2002, Joao Luis Silva Damas wrote: > [** Mail posted to both APNIC and RIPE lists in the hopes of trying > to find a solution suitable for all users of RIPE or RIPE-derived > software **] > > Dear all, > > the inet6num, like the inetnum object, has a field named "status" > which stores some information about the nature or position of a block > of addresses in the delegation chain, from the RIR through to the end > user. > > Currently, the status field for inet6num object is generated by the > Database software based on the size of the address block and its > possible values are: > > o TLA > o SubTLA > o NLA > o SLA > > This notation has been deprecated and it is time to adapt the database. > > Discussions on this matter have identified the usefulness of having > the capability to distinguish between allocations made by the RIR, > allocations made by an LIR or their customers and assignments to end > users. > > As such, we propose to modify the "status" attribute of the inet6num > object to be: > > a) not-generated. This means users must assign a value to the status > attribute when creating the object, just as in the inetnum object > > b) have the following possible values: > RIR-allocated > LIR-allocated > Assigned It would seem desirable to us to go for consistency with the values used in IPv4 in the status field, since intrinsically they are the same arent they? (or are we missing something?) This would also seem to make strong sense from a user perspective in terms of ease of use. In addition, I seem to remember (as in ripe-127?) the main reason for introducing the "status" field, was to assist in the identification of address space as PA or PI. With the values suggested: RIR-allocated LIR-allocated Assigned this does not seem possible anymore. The only complication as far as I can see is that the APNIC and RIPE db's differ slightly on terminology used, but since this can be accommodated in IPv4, then it shouldnt be a problem in IPv6 right? To clarify, the values that APNIC would prefer to use are: ALLOCATED PORTABLE ALLOCATED NON-PORTABLE ASSIGNED PORTABLE ASSIGNED NON-PORTABLE As I mentioned before, these values would be consistent with those in IPv4 (which take effect in August when the migration to version 3 of the RIPE database is complete). Comments? cheers, Anne -- > to be used according to the following set of rules: > > The RIR-allocated status can only be used in objects representing > allocations created directly by the RIR. > > The LIR-allocated status can be used by LIRs and their customers to > represent blocks of addresses that are not assigned to specific end > users. There can be several levels of objects with this status. > > The Assigned status must be used in objects representing > assignments to end users (households, companies, enterprises, etc) > > We hope that with this modification the information in the Database > will more accurately describe the registration of IPv6 address space. > > A possible transition to the new values could be: > > 1) RIRs modify status fields for allocations > 2) Any new objects and modifications to existing ones must have a > value for the status field corresponding to the ones described above. > Otherwise the update will fail. > 3) RIRs contact LIRs to have the status of assignments and > sub-allocations updated. > > Best > regards, > Joao Damas > RIPE NCC > * APNIC-TALK: General APNIC Discussion List * > * To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic.net * > From Robert.Kiessling at de.easynet.net Wed Jun 12 03:30:54 2002 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: 12 Jun 2002 01:30:54 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: References: Message-ID: Anne Lord writes: > In addition, I seem to remember (as in ripe-127?) the main reason for > introducing the "status" field, was to assist in the identification of > address space as PA or PI. There is no PI in IPv6. This can't be said often enough. > With the values suggested: > > RIR-allocated > LIR-allocated > Assigned > > this does not seem possible anymore. Right. It is not necessary. > To clarify, the values that APNIC would prefer to use are: > > ALLOCATED PORTABLE > ALLOCATED NON-PORTABLE > ASSIGNED PORTABLE > ASSIGNED NON-PORTABLE This does not take into account that there are no portable addresses, and that there is an additional level "LIR-allocated" which IPv4 does not have. I like the original proposal of not having the status generated automatically, and giving them a meaning clearly reflected in the name. Robert From nigel at titley.com Wed Jun 12 12:45:46 2002 From: nigel at titley.com (Nigel Titley) Date: 12 Jun 2002 10:45:46 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: <4.3.2.7.2.20020612090705.025acd78@localhost.ripe.net> References: <4.3.2.7.2.20020612090705.025acd78@localhost.ripe.net> Message-ID: <1023878746.1157.43.camel@magrat> On Wed, 2002-06-12 at 07:11, Daniel Karrenberg wrote: > At 06:00 AM 6/12/2002, Geoff Huston wrote: > >However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. > > When these attributes were created, those particular words were in deemed both descriptive and clear. > Maybe the language concerned has shifted underneath in the meantime ;-). > As a native speaker of one of its dialects, would you make a suggestion for improvement? Well actually as a native speaker of (another) of its dialects, I've never considered the distinction of ALLOCATED and ASSIGNED to be other than subtle. I'd much prefer DELEGATED and ASSIGNED or some such. This may be a matter of taste however. Nigel From Guy.Davies at telindus.co.uk Wed Jun 12 11:56:48 2002 From: Guy.Davies at telindus.co.uk (Guy Davies) Date: Wed, 12 Jun 2002 10:56:48 +0100 Subject: [apnic-talk] Status field for inet6num objects Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Nigel Titley [mailto:nigel at titley.com] > > On Wed, 2002-06-12 at 07:11, Daniel Karrenberg wrote: > > At 06:00 AM 6/12/2002, Geoff Huston wrote: > > >However, the distinction between "ALLOCATED" and > "ASSIGNED" is perhaps a bit subtle. > > > > When these attributes were created, those particular words > were in deemed both descriptive and clear. > > Maybe the language concerned has shifted underneath in the > meantime ;-). > > As a native speaker of one of its dialects, would you make > a suggestion for improvement? > > Well actually as a native speaker of (another) of its dialects, > I've never considered the distinction of ALLOCATED and ASSIGNED to > be other than subtle. I'd much prefer DELEGATED and ASSIGNED or > some such. This may be a matter of taste however. I tend to agree with Nigel, although I'd go for something even plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know they're a bit verbose but they're absolutely clear ;-) It also makes clear that addresses assigned to an LIR in the role of END-USER are exactly that. That way, an individual who is struggling with English as a second language (or even their first language ;-) can be absolutely clear of the status of a range of addresses. Just my two pence... Regards, Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPQca4I3dwu/Ss2PCEQJv6ACeMa1ZbnoN3P7r6VaBANGPa1yXN9UAoMLQ cJpgKn6FvDPmyD1X02WLXJF3 =yl1x -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. From Daniel.Karrenberg at ripe.net Wed Jun 12 13:15:51 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 12 Jun 2002 13:15:51 +0200 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: Message-ID: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> At 11:56 AM 6/12/2002, Guy Davies wrote: >I tend to agree with Nigel, although I'd go for something even >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know >they're a bit verbose but they're absolutely clear ;-) It also makes >clear that addresses assigned to an LIR in the role of END-USER are >exactly that. That way, an individual who is struggling with English >as a second language (or even their first language ;-) can be >absolutely clear of the status of a range of addresses. This is an excellent idea. However I would use ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. That way we clarify the subtle difference while maintaining consistency with existing documentation. (If I remember correctly the term DELEGATED was suggested at the time, but not used because of its usage in the DNS context as well as the connotation of total transfer of authority over the resource which is not quite the case.) Daniel From nigel at titley.com Wed Jun 12 14:23:15 2002 From: nigel at titley.com (Nigel Titley) Date: 12 Jun 2002 12:23:15 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> References: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> Message-ID: <1023884595.1157.83.camel@magrat> On Wed, 2002-06-12 at 11:15, Daniel Karrenberg wrote: > At 11:56 AM 6/12/2002, Guy Davies wrote: > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. I'd be happy with this too. Mind you, it goes against the usual principle of introduce-confusing-jargon-in-order-to-ensure-job-security. > (If I remember correctly the term DELEGATED was suggested at the time, > but not used because of its usage in the DNS context as well as > the connotation of total transfer of authority over the resource which > is not quite the case.) Well, a delegation can be withdrawn, and surely people aren't sufficiently stupid to confuse DNS delegation and address delegation.... However, I'm quite happy to agree with the consensus in this case. From nigel at titley.com Wed Jun 12 14:54:41 2002 From: nigel at titley.com (Nigel Titley) Date: 12 Jun 2002 12:54:41 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: References: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> Message-ID: <1023886482.2098.91.camel@magrat> On Wed, 2002-06-12 at 13:00, Robert Kiessling wrote: > Daniel Karrenberg writes: > > > This is an excellent idea. However I would use > > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > > That way we clarify the subtle difference while > > maintaining consistency with existing documentation. > > This is still missing a status for allocations done by LIRs to someone Don't you mean assignments? :-) > who is neither LIR nor end user ("NLA"). Examples? (I'm probably just being stupid) From kevin.bates at bt.com Wed Jun 12 13:55:26 2002 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Wed, 12 Jun 2002 12:55:26 +0100 Subject: [apnic-talk] Status field for inet6num objects Message-ID: seems better but not perfect - the important thing is to get all databases looking the same and using the same terms? strictly speaking it is not "ASSIGNED-TO-END-USER" its "ASSIGNED-TO-SUBNET-USER" for example it could be part of a DHCP dial up pool and thus only " leased" for the duration of that connexion. > At 11:56 AM 6/12/2002, Guy Davies wrote: > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. > > (If I remember correctly the term DELEGATED was suggested at the time, > but not used because of its usage in the DNS context as well as > the connotation of total transfer of authority over the resource which > is not quite the case.) > > Daniel From pekkas at netcore.fi Wed Jun 12 14:06:15 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 12 Jun 2002 15:06:15 +0300 (EEST) Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: <1023886482.2098.91.camel@magrat> Message-ID: On 12 Jun 2002, Nigel Titley wrote: > On Wed, 2002-06-12 at 13:00, Robert Kiessling wrote: > > Daniel Karrenberg writes: > > > > > This is an excellent idea. However I would use > > > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > > > That way we clarify the subtle difference while > > > maintaining consistency with existing documentation. > > > > This is still missing a status for allocations done by LIRs to someone > > Don't you mean assignments? :-) > > > who is neither LIR nor end user ("NLA"). > > Examples? (I'm probably just being stupid) Small ISP which has neither resources or the need to be a LIR. (One that might need, say, /40 with HD80%) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Robert.Kiessling at de.easynet.net Wed Jun 12 15:00:17 2002 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: 12 Jun 2002 13:00:17 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> References: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> Message-ID: Daniel Karrenberg writes: > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. This is still missing a status for allocations done by LIRs to someone who is neither LIR nor end user ("NLA"). Robert From gih at telstra.net Wed Jun 12 14:02:52 2002 From: gih at telstra.net (Geoff Huston) Date: Wed, 12 Jun 2002 22:02:52 +1000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: Message-ID: <5.1.0.14.2.20020612215940.02a0d0f0@kahuna.telstra.net> >I tend to agree with Nigel, although I'd go for something even >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know >they're a bit verbose but they're absolutely clear ;-) It also makes >clear that addresses assigned to an LIR in the role of END-USER are >exactly that. That way, an individual who is struggling with English >as a second language (or even their first language ;-) can be >absolutely clear of the status of a range of addresses. For me these two phrases, DELEGATED-TO-LIR and ASSIGNED-TO-END-USER, hit the spot precisely! excellent suggestion Guy! Is it appropriate to request consideration of these terms as replacements for ASSIGNED and ALLOCATED? Geoff From Robert.Kiessling at de.easynet.net Wed Jun 12 15:09:15 2002 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: 12 Jun 2002 13:09:15 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: References: Message-ID: Anne Lord writes: > What is an IPv6 IX assignment? An assignment done by directly RIR from a non-routed block. Nothing very special or warranting a special attribute value for it, IMHO. > I think the distinction is important - it is very useful to be able to > label address space as portable or non portable (or PI PA for RIPE) especially > as we still encounter many that think that all address space is portable. Which are portable assignments? I can only possibly see IX assignments and the root server block. > > > To clarify, the values that APNIC would prefer to use are: > > > > > > ALLOCATED PORTABLE > > > ALLOCATED NON-PORTABLE > > > ASSIGNED PORTABLE > > > ASSIGNED NON-PORTABLE > > > > This does not take into account that there are no portable addresses, > > what is an allocation from an RIR to you as an LIR? A block from which non-portable addresses are assigned or allocated by the LIR, thus "ALLOCATED NON-PORTABLE". Which "ALLOCATED PORTABLE" blocks do you see? How would you distinguish an allocation from RIR to LIR from that of a LIR to some provider ("NLA")? Robert From Robert.Kiessling at de.easynet.net Wed Jun 12 15:17:52 2002 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: 12 Jun 2002 13:17:52 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: <1023886482.2098.91.camel@magrat> References: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> <1023886482.2098.91.camel@magrat> Message-ID: Nigel Titley writes: > > This is still missing a status for allocations done by LIRs to someone > > Don't you mean assignments? :-) No. > > who is neither LIR nor end user ("NLA"). > > Examples? (I'm probably just being stupid) 5.3 of the 2002-04-25 draft: "LIR-to-ISP allocation". LIRs are free to suballocate the allocation they got from a RIR. Such a suballocation is neither an assignment nor a RIR-allocation, so should get a separate status attribute (as found in the original proposal). Robert From gih at telstra.net Wed Jun 12 14:08:59 2002 From: gih at telstra.net (Geoff Huston) Date: Wed, 12 Jun 2002 22:08:59 +1000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: Message-ID: <5.1.0.14.2.20020612220637.02a0ce30@kahuna.telstra.net> > > This is an excellent idea. However I would use > > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > > That way we clarify the subtle difference while > > maintaining consistency with existing documentation. > > > > (If I remember correctly the term DELEGATED was suggested at the time, > > but not used because of its usage in the DNS context as well as > > the connotation of total transfer of authority over the resource which > > is not quite the case.) To me "DELEGATED-TO-LIR" makes sense, as it infers that the process of further delegation can be used with sub-blocks and/or atomic units can be "ASSIGNED-TO-END-USERs with the inference that no further sub assignments are anticipated. Geoff From bmanning at ISI.EDU Wed Jun 12 14:21:01 2002 From: bmanning at ISI.EDU (Bill Manning) Date: Wed, 12 Jun 2002 05:21:01 -0700 (PDT) Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: from "kevin.bates@bt.com" at "Jun 12, 2 12:55:26 pm" Message-ID: <200206121221.g5CCL1X27564@boreas.isi.edu> is it just me? for me, I know that my customers have at least two levels of downstream, BEFORE the address hits the end user. And I have an upstream... I think that there is not enough granularity in the proposal. I'd be happier with two pointers, allocated-from (my upstream) delegated-to (my downstream) % % % seems better but not perfect - the important thing is to get all databases % looking the same and using the same terms? % % strictly speaking it is not "ASSIGNED-TO-END-USER" its % "ASSIGNED-TO-SUBNET-USER" for example it could be part of a DHCP dial up % pool and thus only " leased" for the duration of that connexion. % % % % > At 11:56 AM 6/12/2002, Guy Davies wrote: % > >I tend to agree with Nigel, although I'd go for something even % > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know % > >they're a bit verbose but they're absolutely clear ;-) It also makes % > >clear that addresses assigned to an LIR in the role of END-USER are % > >exactly that. That way, an individual who is struggling with English % > >as a second language (or even their first language ;-) can be % > >absolutely clear of the status of a range of addresses. % > % > This is an excellent idea. However I would use % > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. % > That way we clarify the subtle difference while % > maintaining consistency with existing documentation. % > % > (If I remember correctly the term DELEGATED was suggested at the time, % > but not used because of its usage in the DNS context as well as % > the connotation of total transfer of authority over the resource which % > is not quite the case.) % > % > Daniel % -- --bill From nigel at titley.com Wed Jun 12 15:55:22 2002 From: nigel at titley.com (Nigel Titley) Date: 12 Jun 2002 13:55:22 +0000 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: References: <4.3.2.7.2.20020612130955.02704a80@localhost.ripe.net> <1023886482.2098.91.camel@magrat> Message-ID: <1023890122.1157.96.camel@magrat> On Wed, 2002-06-12 at 13:17, Robert Kiessling wrote: > Nigel Titley writes: > > > > This is still missing a status for allocations done by LIRs to someone > > > > Don't you mean assignments? :-) > > No. > > > > who is neither LIR nor end user ("NLA"). > > > > Examples? (I'm probably just being stupid) > > 5.3 of the 2002-04-25 draft: "LIR-to-ISP allocation". LIRs are free to > suballocate the allocation they got from a RIR. Such a suballocation > is neither an assignment nor a RIR-allocation, so should get a > separate status attribute (as found in the original proposal). Apologies. I forgot the thread originated in an IPv6 context, and since then it has ended up copied to the world and his wife. To which end I've trimmed the Cc: Nigel From randy at psg.com Wed Jun 12 17:12:22 2002 From: randy at psg.com (Randy Bush) Date: Wed, 12 Jun 2002 08:12:22 -0700 Subject: [apnic-talk] Status field for inet6num objects References: <4.3.2.7.2.20020612090705.025acd78@localhost.ripe.net> <1023878746.1157.43.camel@magrat> Message-ID: "LEASED" From bmanning at ISI.EDU Wed Jun 12 17:32:57 2002 From: bmanning at ISI.EDU (Bill Manning) Date: Wed, 12 Jun 2002 08:32:57 -0700 (PDT) Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: from Randy Bush at "Jun 12, 2 08:12:22 am" Message-ID: <200206121532.g5CFWvK04737@boreas.isi.edu> "LEASED" has has interesting legal ramifications in some jurisdictions. In the ARIN region, council has advised against using that term. -- --bill From anne at apnic.net Thu Jun 13 08:21:27 2002 From: anne at apnic.net (Anne Lord) Date: Thu, 13 Jun 2002 16:21:27 +1000 (EST) Subject: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num objects In-Reply-To: Message-ID: > > What is an IPv6 IX assignment? > > An assignment done by directly RIR from a non-routed block. Nothing The policy language (as far as i could tell) does not state non-routability as an explicit condition of these assignments - it is up to individual ISPs to determine routablility. (But ok it is likely they wont be routed). > very special or warranting a special attribute value for it, IMHO. APNIC has not yet implemented values for the status attribute for IPv4, but whatever values we do implement, we would like to have some consistency in the terminology between IPv4 and IPv6 - that doesnt mean we have to use all the values from the set of potential values for both IPv4 and IPv6, but from a user perspective it does seem to make sense to have the same wording especially as we are *about* to introduce this attribute. For RIPE it might be different - you guys have been using the 'status' attribute for a while. We do therefore have some flexibility in the terminology we choose for IPv4 and IPv6 therefore and can hopefully arrive at terminology that suits everyones needs. The end goal for us is to be able to identify portable and non-portable address space. This might have more emphasis in v4 and i would argue, is not redundant in IPv6. My question is, does indicating the assigning/ allocating body, convey enough information ie. RIR-assigned, LIR assigned. Does that tell you that the former is portable, and the latter non-portable? Likewise for allocated, where the RIR-Allocated is a portable block, and the LIR-allocated is non-portable? 'Delegated' has been suggested here as a replacement for 'Allocated' and seems to have some favour. I had previously thought that the term 'delegated' could mean 'allocated' *or* 'assigned'??? But maybe this isnt the case...? for those in favour of using Delegated instead of allocated, are you talking just w.r.t the database or in wider usage throughout our documentation. If you use it just in the database, then it could be confusing - and if we change the documentation, then this is a much bigger issue of course. Allocation and assign do have definitions - could these be improved to clarify the meaning? Or does 'delegate' simply convey a much clearer intention with the address space? allocate - Allocated address space is address space that is distributed to IRs for the purpose of subsequent distribution by them assign - Assigned address space is address space that is delegated to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. > > I think the distinction is important - it is very useful to be able to > > label address space as portable or non portable (or PI PA for RIPE) especially > > as we still encounter many that think that all address space is portable. > > Which are portable assignments? I can only possibly see IX assignments > and the root server block. In IPv4 portable assignments are being made by the RIRs. In the ARIN region they have a policy for 'critical infrastructure' that applies to IPv4 that may well apply to IPv6 which encompasses a bigger set that the above mentioned (ccTLD's, Root name servers etc). The AP region is yet to discuss this further. > > > > To clarify, the values that APNIC would prefer to use are: > > > > > > > > ALLOCATED PORTABLE > > > > ALLOCATED NON-PORTABLE > > > > ASSIGNED PORTABLE > > > > ASSIGNED NON-PORTABLE > > > > > > This does not take into account that there are no portable addresses, > > > > what is an allocation from an RIR to you as an LIR? > > A block from which non-portable addresses are assigned or allocated by > the LIR, thus "ALLOCATED NON-PORTABLE". But what is the block itself? > Which "ALLOCATED PORTABLE" blocks do you see? > > How would you distinguish an allocation from RIR to LIR from that of a > LIR to some provider ("NLA")? The former is a portable block. the latter is a non-portable block. Allocated portable, and allocated non-portable. the assignments made from each are non-portable. Anne -- > From s.willing at mops.net Thu Jun 13 11:00:10 2002 From: s.willing at mops.net (Sebastian Willing) Date: Thu, 13 Jun 2002 11:00:10 +0200 (CEST) Subject: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num In-Reply-To: from "Anne Lord" at Jun 13, 2002 04:21:27 PM Message-ID: <200206130900.LAA18652@mara.mops.net> Hello! What about RESERVED-FOR-RIR RESERVED-FOR-LIR USED-BY-LIR USED-BY-ENDUSER USED-SPECIAL while the last one is reserved for IXs and root-servers. There may be another step between LIR and ENDUSER: RESERVED-FOR-ISP | RESERVED-FOR-NLA USED-BY-ISP | USED-BY-NLA BTW: If a subnet is used - does it matter who is using it? Just my 2 Ct. Sebastian Willing, mopSys GmbH -- ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing at mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************ From Sam.Wilson at ed.ac.uk Thu Jun 13 10:02:08 2002 From: Sam.Wilson at ed.ac.uk (Sam.Wilson at ed.ac.uk) Date: 13 Jun 2002 10:02:08 BST Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: Your message <200206121532.g5CFWvK04737@boreas.isi.edu> Message-ID: <200206130902.KAA19657@holyrood.ed.ac.uk> > "LEASED" has has interesting legal ramifications in some jurisdictions. > In the ARIN region, council has advised against using that term. It also has technical connotations - DHCP address leases at least - which may not be appropriate in this context. Sam Wilson Network Services Division Computing Services, The University of Edinburgh Edinburgh, Scotland, UK From Michael.Dillon at radianz.com Thu Jun 13 11:42:42 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 13 Jun 2002 10:42:42 +0100 Subject: [apnic-talk] Status field for inet6num objects Message-ID: >For me these two phrases, DELEGATED-TO-LIR and >ASSIGNED-TO-END-USER, hit the spot precisely! >excellent suggestion Guy! >Is it appropriate to request consideration of these terms as replacements >for ASSIGNED and ALLOCATED? Wouldn't it be a good idea to standardize the terminology with ARIN and others? In that case, the term LIR would be considered obscure and meaningless. Since all LIRs are service providers of some sort, either ISPs or an internal network service provider, I think that a standard terminology should try to use generic terms. That would mean either DELEGATED-TO-SVC-PROVIDER or DELEGATED-TO-NSP if you like acronyms (Network Service Provider). In any case, because the distinction between "allocated" and "assigned" has been unclear in the past and because there is a significant shift in terminology from "allocated" to "delegated" this change should be incorporated in an informational RFC. This document would help in clarifying that there is indeed a difference between the two states of an address block and would also help in promoting the use of this terminology amongst the community that deal with IP address delegations and assignments. DELEGATED-TO-NSP and ASSIGNED-TO-USER are two terms that would be clear worldwide. Michael Dillon Network Product Engineering Radianz From leo at ripe.net Thu Jun 13 11:52:00 2002 From: leo at ripe.net (leo vegoda) Date: Thu, 13 Jun 2002 11:52:00 +0200 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: References: Message-ID: <20020613095159.GA13185@ripe.net> On Thu, Jun 13, 2002 at 10:42:42AM +0100, Michael.Dillon at radianz.com wrote: Re: RE: [apnic-talk] Status field for inet6num objects [...] > Wouldn't it be a good idea to standardize the terminology with ARIN and > others? Section two of the IPv6 policy document is the "Definitions" section. It defines RIR, NIR, LIR, ASN, Allocation and Assignment among other things. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From Michael.Dillon at radianz.com Thu Jun 13 11:54:50 2002 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 13 Jun 2002 10:54:50 +0100 Subject: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num objects Message-ID: >Allocation and assign do have definitions - could these be improved >to clarify the meaning? Or does 'delegate' simply convey a much >clearer intention with the address space? Delegation is clearer for two reasons. Firstly, it implies that the the delegator is passing on some responsibility for the address space. The organization receiving a delegation is responsible for managing and administering the addresses. In the case of an assignment, this is less true. For instance, ISPs regularly reassign addresses after a customer disconnects and everyone seems to understand that addresses assignments are controlled by the assigner and can be withdrawn. The second reason has more to do with psychology. Because the terms "allocation" and "assignment" are similar in meaning and visually similar, they are easily confused by a lot of people. They both begin with "a" followed by a double consonant and end with a latin suffix. Of course, clear definitions are always a good thing as well. Michael Dillon Network Product Engineering Radianz From gert at space.net Thu Jun 13 12:14:03 2002 From: gert at space.net (Gert Doering) Date: Thu, 13 Jun 2002 12:14:03 +0200 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: ; from Michael.Dillon@radianz.com on Thu, Jun 13, 2002 at 10:42:42AM +0100 References: Message-ID: <20020613121403.G13918@Space.Net> Hi, On Thu, Jun 13, 2002 at 10:42:42AM +0100, Michael.Dillon at radianz.com wrote: > DELEGATED-TO-NSP and ASSIGNED-TO-USER are two terms that would be clear > worldwide. A LIR is something different from "just a network service provider". Actually, a LIR is pretty well-defined (as is RIR), and maybe some effort should be invested to use *that* terminology world-wide, instead of inventing new terms for everything to completely confuse matters. Ditto for ALLOCATED and ASSIGNED - renaming those doesn't really solve anything (and overlooks the multi-hierarchy problem Robert has already mentioned). We would need at least "DELEGATED-TO-LIR", "SUB-DELEGATED", and "ASSIGNED-TO-USER", but again I see no significant improvement as compared to (well-documented) "ALLOCATED", "SUB-ALLOCATED" and "ASSIGNED" values. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46204 (45201) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From peter.galbavy at knowtion.net Thu Jun 13 17:26:16 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 13 Jun 2002 16:26:16 +0100 Subject: Am I the only one who can't pay their fees ? Message-ID: <00ba01c212ee$a91160c0$7dcb87d4@n3.uk.knowtion.net> I have now faxed my credit card payment form to RIPE on three ocassions to two different numbers and today I get my suspension notice. Am I the only one that appears to be at the sharp end of this potential incompetence or are other having problems with financially sensitive data / faxes going missing at RIPE ? I still think that the focus on non-core activities within RIPE is wrong, and these types of administrative problems only help reinforce my view. rgds, -- Peter Galbavy From mally at ripe.net Thu Jun 13 17:44:58 2002 From: mally at ripe.net (Mally Mclane) Date: Thu, 13 Jun 2002 17:44:58 +0200 Subject: Am I the only one who can't pay their fees ? In-Reply-To: <00ba01c212ee$a91160c0$7dcb87d4@n3.uk.knowtion.net> Message-ID: Dear Colleagues, > I have now faxed my credit card payment form to RIPE on three ocassions to > two different numbers and today I get my suspension notice. Am I the only > one that appears to be at the sharp end of this potential incompetence or > are other having problems with financially sensitive data / faxes going > missing at RIPE ? > RIPE NCC Operations have contacted Peter to solve his fax problems. Regards, Mally Mclane RIPE NCC Operations From John.Sweeting at teleglobe.com Thu Jun 13 17:45:47 2002 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Thu, 13 Jun 2002 11:45:47 -0400 Subject: Am I the only one who can't pay their fees ? Message-ID: <170E5E7779BCD3118C2A0008C7F40C1904DD392B@usresms03.teleglobe.com> We are having the same problems. -----Original Message----- From: Peter Galbavy [mailto:peter.galbavy at knowtion.net] Sent: Thursday, June 13, 2002 11:26 AM To: lir-wg at ripe.net Subject: Am I the only one who can't pay their fees ? I have now faxed my credit card payment form to RIPE on three ocassions to two different numbers and today I get my suspension notice. Am I the only one that appears to be at the sharp end of this potential incompetence or are other having problems with financially sensitive data / faxes going missing at RIPE ? I still think that the focus on non-core activities within RIPE is wrong, and these types of administrative problems only help reinforce my view. rgds, -- Peter Galbavy From peter.galbavy at knowtion.net Thu Jun 13 17:55:07 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 13 Jun 2002 16:55:07 +0100 Subject: Am I the only one who can't pay their fees ? References: Message-ID: <00d201c212f2$b1142bf0$7dcb87d4@n3.uk.knowtion.net> > RIPE NCC Operations have contacted Peter to solve his fax problems. I am somewhat puzzled by the phrase 'solve his fax problems'. I have very few other fax issues so I would suggest, as politely as my mood will allow, that these are potential RIPE fax / administrative 'problems'. Peter From mally at ripe.net Thu Jun 13 18:27:16 2002 From: mally at ripe.net (Mally Mclane) Date: Thu, 13 Jun 2002 18:27:16 +0200 Subject: Am I the only one who can't pay their fees ? In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C1904DD392B@usresms03.teleglobe.com> Message-ID: Dear Colleagues, On 13/6/02 17:45, "Sweeting, John" wrote: > We are having the same problems. If any of you are having problems with faxing the RIPE NCC (or indeed any other *technical* issue), please contact ops at ripe.net directly. If your issue is not a technical one, please consult our list of mailboxes at: http://www.ripe.net/ripencc/about/contact.html Regards, Mally Mclane RIPE NCC Operations > -----Original Message----- > From: Peter Galbavy [mailto:peter.galbavy at knowtion.net] > Sent: Thursday, June 13, 2002 11:26 AM > To: lir-wg at ripe.net > Subject: Am I the only one who can't pay their fees ? > > > I have now faxed my credit card payment form to RIPE on three ocassions to > two different numbers and today I get my suspension notice. Am I the only > one that appears to be at the sharp end of this potential incompetence or > are other having problems with financially sensitive data / faxes going > missing at RIPE ? > > I still think that the focus on non-core activities within RIPE is wrong, > and these types of administrative problems only help reinforce my view. > > rgds, > -- > Peter Galbavy > > From david at IPRG.nokia.com Thu Jun 13 22:57:49 2002 From: david at IPRG.nokia.com (David Kessens) Date: Thu, 13 Jun 2002 13:57:49 -0700 Subject: [apnic-talk] Status field for inet6num objects In-Reply-To: <5.1.0.14.2.20020612215940.02a0d0f0@kahuna.telstra.net>; from gih@telstra.net on Wed, Jun 12, 2002 at 10:02:52PM +1000 References: <5.1.0.14.2.20020612215940.02a0d0f0@kahuna.telstra.net> Message-ID: <20020613135749.E16716@iprg.nokia.com> Geoff, On Wed, Jun 12, 2002 at 10:02:52PM +1000, Geoff Huston wrote: > > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > For me these two phrases, DELEGATED-TO-LIR and > ASSIGNED-TO-END-USER, hit the spot precisely! > > excellent suggestion Guy! > > Is it appropriate to request consideration of these terms as replacements > for ASSIGNED and ALLOCATED? I would like to second such a request. ASSIGNED and ALLOCATED seem to be confusing terms, even for the professionals in this business. David K. --- From peter.galbavy at knowtion.net Fri Jun 14 10:38:20 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 14 Jun 2002 09:38:20 +0100 Subject: Am I the only one who can't pay their fees ? References: Message-ID: <001201c2137e$d6b490c0$2728a8c0@carpenter> > I couldn't agree more. Neil, we agree ? When was the last time ? :-) For those who do not our (cough) background... peter From neil at COLT.NET Fri Jun 14 10:21:41 2002 From: neil at COLT.NET (Neil J. McRae) Date: Fri, 14 Jun 2002 09:21:41 +0100 Subject: Am I the only one who can't pay their fees ? In-Reply-To: <00ba01c212ee$a91160c0$7dcb87d4@n3.uk.knowtion.net> Message-ID: > I still think that the focus on non-core activities within RIPE is wrong, > and these types of administrative problems only help reinforce my view. I couldn't agree more. From webmaster at ripe.net Fri Jun 14 12:26:15 2002 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Fri, 14 Jun 2002 12:26:15 +0200 Subject: New Document available: RIPE-234 Message-ID: <200206141026.g5EAQFA20037@birch.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A set of new documents is available from the RIPE Document Store: IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region (ripe-234) IPv4 First Allocation Request Form (ripe-235) Supporting Notes for the IPv4 First Allocation Request Form (ripe-236) New Values of the "status:" Attribute for Inetnum Objects (LIR-PARTITIONED) (ripe-239) IPv4 Additional Allocation Request Form (ripe-240) Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR (ripe-241) Autonomous System (AS) Number Assignment Policies and Procedures (ripe-245) Short content description ------------------------- This set of IPv4 policy documents replaces the now obsolete ripe-185 (European Internet Registry Policies and Procedures). Additionally, we have created specific forms for Local Internet Registries to request a first allocation and additional allocations. Accessing the RIPE document store --------------------------------- All documents are on-line at the following URLs: http://www.ripe.net/ripe/docs/ipv4-policies.html http://www.ripe.net/ripe/docs/first-allocation.html http://www.ripe.net/ripe/docs/first-allocation-support.html http://www.ripe.net/ripe/docs/lir-partitioned.html http://www.ripe.net/ripe/docs/add-allocation.html http://www.ripe.net/ripe/docs/mergers.html http://www.ripe.net/ripe/docs/asn-assignment.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs/. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-234.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-234.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-235.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-235.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-236.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-236.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-239.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-239.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-240.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-240.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-241.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-241.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-245.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-245.txt plain text version Kind Regards, RIPE NCC Document Announcement Service From neil at COLT.NET Fri Jun 14 11:05:57 2002 From: neil at COLT.NET (Neil J. McRae) Date: Fri, 14 Jun 2002 10:05:57 +0100 Subject: Am I the only one who can't pay their fees ? In-Reply-To: <001201c2137e$d6b490c0$2728a8c0@carpenter> Message-ID: Yeah I seem to remeber the last disagreement was about whos round it was :-) Neil. -- Neil J. McRae - COLT neil at COLT.NET > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Peter Galbavy > Sent: 14 June 2002 09:38 > To: Neil J. McRae; lir-wg at ripe.net > Subject: Re: Am I the only one who can't pay their fees ? > > > > I couldn't agree more. > > Neil, we agree ? When was the last time ? > > :-) For those who do not our (cough) background... > > peter > > From peter.galbavy at knowtion.net Fri Jun 14 12:42:20 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 14 Jun 2002 11:42:20 +0100 Subject: Am I the only one who can't pay their fees ? References: <00ba01c212ee$a91160c0$7dcb87d4@n3.uk.knowtion.net> Message-ID: <000e01c21390$298efbd0$2728a8c0@carpenter> I found the page: https://www.ripe.net/cgi-bin/regpayment and entered my details. I got error for both the invoice number and my e-mail address. Double checked both. Are people implementing these systems truly that poor that 'peter.galbavy at knowtion.net' comes back as an invalid e-mail address ? And if the online payment system was implemented after my invoice was issued then the correct UI thing to do is to say 'sorry, payment for this invoice is not available via this page, please contact the NCC' etc. I am getting pissed off now for two reasons - one, as far as RIPE is concerned this appears to be 100% mny fault and two, they build systems that have never appeared to have been tested. I saved to HTML output for any interested... Peter ----- Original Message ----- From: "Peter Galbavy" To: Sent: Thursday, June 13, 2002 4:26 PM Subject: Am I the only one who can't pay their fees ? > I have now faxed my credit card payment form to RIPE on three ocassions to > two different numbers and today I get my suspension notice. Am I the only > one that appears to be at the sharp end of this potential incompetence or > are other having problems with financially sensitive data / faxes going > missing at RIPE ? > > I still think that the focus on non-core activities within RIPE is wrong, > and these types of administrative problems only help reinforce my view. > > rgds, > -- > Peter Galbavy > > > From peter.galbavy at knowtion.net Fri Jun 14 12:54:36 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Fri, 14 Jun 2002 11:54:36 +0100 Subject: Am I the only one who can't pay their fees ? References: <00ba01c212ee$a91160c0$7dcb87d4@n3.uk.knowtion.net> <000e01c21390$298efbd0$2728a8c0@carpenter> Message-ID: <002201c21391$e06709f0$2728a8c0@carpenter> No. I can't believe this. No. I am on the phone right now to someone in billing department - sorry I am not good at spelling Dutch names - and wait for it... THEY GOT MY ORIGINAL FAX IN JANUARY. WTF ? Apparently the form did not have an expiry date or an e-mail address on it. I don't think I would have been that stupid, but hey - I might have been busy servicing clients and just signed whatever my accountant sent me before faxing it through... In the meanwhile they are capable of sending three reminders but are not able to contact me via a dozen different e-mail addresses, and not once mention that they actually have a fax but that there is information missing. Instead I get half truths about missing faxes and the like. I am really, really, really pissed with the NCC at the moment. I hope my public outburst may raise enough of a fuss in-house so that someone pulls their finger out and does something to fix problems for other members. To the management at the NCC: Stop trying to prove that you have done everything perfect at all times, and instead try seeing your incompetence from a busy (small) LIR point of view. Peter From axel at ripe.net Fri Jun 14 16:01:09 2002 From: axel at ripe.net (Axel Pawlik) Date: Fri, 14 Jun 2002 16:01:09 +0200 Subject: [lir-wg] Concerns about billing procedures at RIPE NCC Message-ID: <5.1.1.5.2.20020614155536.01addea8@localhost> Dear all, regarding today's concern about billing at the RIPE NCC, and the related procedures, I have spent some time this afternoon to look into the matter. What I have found gives not raise to concern about procedures, or the privacy of member's data at the RIPE NCC. It might be possible, though, to remove some slack from the timeline of the payment process. It is our goal to make administrative procedures as efficient and inobtrusive as possible. To assist us in this undertaking, please ensure that your billing data you send is as complete as possible. Should you have any questions or concerns in this aspect, do not hesitate to contact either me, or the RIPE NCC's controller, Jochem de Ruig (jochem at ripe.net), directly. kind regards, Axel Pawlik Managing Director, RIPE NCC From hank at att.net.il Mon Jun 17 14:34:48 2002 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 17 Jun 2002 15:34:48 +0300 Subject: [lir-wg] Re: New Document available: RIPE-234 In-Reply-To: <200206141026.g5EAQFA20037@birch.ripe.net> Message-ID: <5.1.0.14.2.20020617153122.05432b90@max.att.net.il> At 12:26 PM 14-06-02 +0200, RIPE NCC Document Announcement Service wrote: >New/Revised RIPE Document Announcement >-------------------------------------- >A set of new documents is available from the RIPE Document Store: > >IPv4 Address Allocation and Assignment Policies in the RIPE NCC >Service Region (ripe-234) > >IPv4 First Allocation Request Form (ripe-235) > >Supporting Notes for the IPv4 First Allocation Request Form (ripe-236) > >New Values of the "status:" Attribute for Inetnum Objects >(LIR-PARTITIONED) (ripe-239) > >IPv4 Additional Allocation Request Form (ripe-240) > >Mergers, Acquisitions, Takeovers and Closures of Organisations >Operating an LIR (ripe-241) Rather amazing that not a word in this document about ASN handling. Just IP handling. >Autonomous System (AS) Number Assignment Policies and Procedures >(ripe-245) Section 1.2 "Returning an ASN" should be expanded and included in ripe-241. -Hank >Short content description ------------------------- > >This set of IPv4 policy documents replaces the now obsolete ripe-185 >(European Internet Registry Policies and Procedures). > >Additionally, we have created specific forms for Local Internet >Registries to request a first allocation and additional allocations. > > > >Accessing the RIPE document store >--------------------------------- >All documents are on-line at the following URLs: > > > http://www.ripe.net/ripe/docs/ipv4-policies.html > http://www.ripe.net/ripe/docs/first-allocation.html > http://www.ripe.net/ripe/docs/first-allocation-support.html > http://www.ripe.net/ripe/docs/lir-partitioned.html > http://www.ripe.net/ripe/docs/add-allocation.html > http://www.ripe.net/ripe/docs/mergers.html > http://www.ripe.net/ripe/docs/asn-assignment.html > > >The RIPE document store is also available via anonymous FTP to >ftp.ripe.net, in the directory ripe/docs/. >The URLs for the new documents on the FTP-server are: > > ftp://ftp.ripe.net/ripe/docs/ripe-234.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-234.txt plain text version > ftp://ftp.ripe.net/ripe/docs/ripe-235.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-235.txt plain text version > ftp://ftp.ripe.net/ripe/docs/ripe-236.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-236.txt plain text version > ftp://ftp.ripe.net/ripe/docs/ripe-239.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-239.txt plain text version > ftp://ftp.ripe.net/ripe/docs/ripe-240.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-240.txt plain text version > ftp://ftp.ripe.net/ripe/docs/ripe-241.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-241.txt plain text version > ftp://ftp.ripe.net/ripe/docs/ripe-245.ps PostScript version > ftp://ftp.ripe.net/ripe/docs/ripe-245.txt plain text version > >Kind Regards, > >RIPE NCC Document Announcement Service From thinman at clp.cw.net Mon Jun 17 20:07:31 2002 From: thinman at clp.cw.net (Tanya Hinman) Date: Mon, 17 Jun 2002 14:07:31 -0400 Subject: [lir-wg] Wait Queue Message-ID: Why is the wait queue even longer than it was before the last RIPE Meeting? I thought the general consensus was to get the waiting issue resolved??? 24 days for an ASN request is a bit long. Tanya From leo at ripe.net Tue Jun 18 17:02:02 2002 From: leo at ripe.net (leo vegoda) Date: Tue, 18 Jun 2002 17:02:02 +0200 Subject: [lir-wg] Wait Queue In-Reply-To: References: Message-ID: <20020618150202.GA8252@ripe.net> Hello, On Mon, Jun 17, 2002 at 02:07:31PM -0400, Tanya Hinman wrote: Re: [lir-wg] Wait Queue > > Why is the wait queue even longer than it was before the last RIPE Meeting? > I thought the general consensus was to get the waiting issue resolved??? 24 > days for an ASN request is a bit long. The 24 days wait mentioned above looks very unusual. The response time to IP and AS requests is about a week at the moment. Messages sent to the mailbox can take a little longer to be answered. However, we do try to asses the urgency of messages sent there and prioritise them accordingly. I have contacted Tanya off-list and we will resolve this issue with her. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From anne at apnic.net Thu Jun 20 08:31:49 2002 From: anne at apnic.net (Anne Lord) Date: Thu, 20 Jun 2002 16:31:49 +1000 (EST) Subject: [lir-wg] RE: [apnic-talk] Status field for inet6num objects In-Reply-To: <5.1.0.14.2.20020612215940.02a0d0f0@kahuna.telstra.net> Message-ID: Hi Geoff, > For me these two phrases, DELEGATED-TO-LIR and > ASSIGNED-TO-END-USER, hit the spot precisely! > > excellent suggestion Guy! > > Is it appropriate to request consideration of these terms as replacements > for ASSIGNED and ALLOCATED? The terms in the database in connection with this attribute are used to reflect the existing policy environment. If you wish to change the terms, then the appropriate place to do that (in the AP region) is the Address Policy SIG. You are very welcome to make a proposal there. cheers, Anne -- From pwilson at apnic.net Thu Jun 20 09:27:43 2002 From: pwilson at apnic.net (Paul Wilson) Date: Thu, 20 Jun 2002 17:27:43 +1000 Subject: [lir-wg] RE: [apnic-talk] Status field for inet6num objects In-Reply-To: <5.1.0.14.2.20020612215940.02a0d0f0@kahuna.telstra.net> Message-ID: <63B9746D4A92BF498D78584958F537E3016F98@lotus.exchange> Hi Geoff and all, (speaking for APNIC here) While policy changes are always possible, I'd like to point out that the terms "Allocation" and "Assignment" are well defined within the APNIC policy framework, and those definitions reflect meanings which have been fairly well agreed for some time (at least since the publication of RFC2050). The terms are very widely used throughout APNIC policy, training and other documentation, and in a manner which is consistent with the definitions. As for "Delegation", this term is used more loosely in various documents, and as a general term for transferring responsibility for address space, through *either* allocation or assignment. We sometimes use the word "distribution" with the same meaning. You can see RFC2050 for examples of both. Dictionary definitions are interesting, and while I would like as much consistency as possible with them, I'd also argue that these terms now have a life of their own and a legitimacy within our own specific context. Unless there is a very good reason to replace the term "allocate" with "delegate" as proposed, we should bear in mind that the cost of making this change would be very substantial, and may well outweigh the benefits. Regards, ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3858 3100/99 > -----Original Message----- > From: owner-apnic-talk at lists.apnic.net > [mailto:owner-apnic-talk at lists.apnic.net] On Behalf Of Geoff Huston > Sent: Wednesday, June 12, 2002 10:03 PM > To: Guy Davies; 'Nigel Titley'; Daniel Karrenberg > Cc: Anne Lord; Joao Luis Silva Damas; ipv6-wg at ripe.net; > lir-wg at ripe.net; db-wg at ripe.net; sig-db at lists.apnic.net; > sig-policy at lists.apnic.net; apnic-talk at lists.apnic.net > Subject: RE: [apnic-talk] Status field for inet6num objects > > > > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > > For me these two phrases, DELEGATED-TO-LIR and > ASSIGNED-TO-END-USER, hit the spot precisely! > > excellent suggestion Guy! > > Is it appropriate to request consideration of these terms as > replacements > for ASSIGNED and ALLOCATED? > > > Geoff > > > * APNIC-TALK: General APNIC Discussion List * > * To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic.net * > From ncc at ripe.net Thu Jun 20 12:14:22 2002 From: ncc at ripe.net (Paul Rendek) Date: Thu, 20 Jun 2002 12:14:22 +0200 Subject: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder Message-ID: <5.1.0.14.2.20020620115146.02b55988@mailhost.ripe.net> Dear Colleagues, This is a reminder that the deadline for comments and suggestions for the draft in-addr policy document is set for Monday, 24 June 2002. The new draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC Service Region" document can be found on our website at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documents/ All comments and suggestions should be sent to . Regards, Paul Rendek RIPE NCC From hank at att.net.il Thu Jun 20 14:31:50 2002 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 20 Jun 2002 15:31:50 +0300 Subject: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder In-Reply-To: <5.1.0.14.2.20020620115146.02b55988@mailhost.ripe.net> Message-ID: <5.1.0.14.2.20020620152819.00ff7958@max.att.net.il> At 12:14 PM 20-06-02 +0200, Paul Rendek wrote: Why not add in a section for historic ARIN allocations? I know there is thought about harmonizing this procedure but in the interim until all the parts get finalized why not add in a section that states that RIPE will act as an intermediary to ARIN for historic allocations. Right now, when I approach ARIN they tell me to go to RIPE. RIPE does it as an "unofficial service", whereby it takes my SWIP template and passes it onward to ARIN, who then do the change requested. This usually takes 2-4 weeks. I think some text should be added about this - even if it states "to be changed shortly". -Hank >Dear Colleagues, > >This is a reminder that the deadline for comments and suggestions for the >draft in-addr policy document is set for Monday, 24 June 2002. The new >draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC >Service Region" document can be found on our website at: > >http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documents/ > >All comments and suggestions should be sent to . > >Regards, > >Paul Rendek >RIPE NCC From leo at ripe.net Thu Jun 20 20:19:41 2002 From: leo at ripe.net (leo vegoda) Date: Thu, 20 Jun 2002 20:19:41 +0200 Subject: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder In-Reply-To: <5.1.0.14.2.20020620152819.00ff7958@max.att.net.il> References: <5.1.0.14.2.20020620115146.02b55988@mailhost.ripe.net> <5.1.0.14.2.20020620152819.00ff7958@max.att.net.il> Message-ID: <20020620181940.GA28951@ripe.net> Hi Hank, On Thu, Jun 20, 2002 at 03:31:50PM +0300, Hank Nussbacher wrote: Re: Re: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder > At 12:14 PM 20-06-02 +0200, Paul Rendek wrote: > > Why not add in a section for historic ARIN allocations? I know there is > thought about harmonizing this procedure but in the interim until all the > parts get finalized why not add in a section that states that RIPE will act > as an intermediary to ARIN for historic allocations. Right now, when I > approach ARIN they tell me to go to RIPE. RIPE does it as an "unofficial > service", whereby it takes my SWIP template and passes it onward to ARIN, > who then do the change requested. This usually takes 2-4 weeks. I think > some text should be added about this - even if it states "to be changed > shortly". Thanks for your input. What you are describing is a procedure. This draft documents policy only. Any questions about the RIPE NCC helping with reverse delegations of pre-RIR address space should be sent to . Where help will be given on a case-by-case basis. Best regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From zsako at banknet.net Mon Jun 24 11:32:21 2002 From: zsako at banknet.net (Janos Zsako) Date: Mon, 24 Jun 2002 11:32:21 +0200 (MET DST) Subject: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder Message-ID: <200206240932.LAA13841@banknet.banknet.net> > From owner-lir-wg at ripe.net Thu Jun 20 12:15:28 2002 > From: Paul Rendek Dear all, > This is a reminder that the deadline for comments and suggestions for the > draft in-addr policy document is set for Monday, 24 June 2002. The new > draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC > Service Region" document can be found on our website at: > > http://www.ripe.net/ripencc/mem-services/registration/policies/draft-documents/ > > All comments and suggestions should be sent to . I would have a short question and a suggestion for clarification. 1. Is the last paragraph of 3.0 not superfluous in the light of the last paragraph of 5.0? 3.0: "LIRs should maintain DNS resource records for address space assigned to End Users from their own address space, even if the user obtains connectivity from a different LIR." 5.0: "LIRs should provide reverse delegation corresponding to an assignment during the complete validity period of the assignment." I mean that my understanding is that for 3.0 there are two cases: the end-user either _changes_ its provider, in which case they will have to renumber, and during renumbering their assignment is valid, i.e. the old LIR has to provide reverse DNS according to 5.0 during renumbering, or the end-user becomes multi-homed, therefore they will keep the old address space for which they obviously will need reverse DNS (on the long run) that the old LIR is again supposed to provide, based on 5.0. Am I missing something? 2. I think the intent of first paragraph of 3.0 is to accept a reverse delegation of an address block as soon as there is ANY address space assigned from it (i.e not ALL has to be assigned prior to reverse delegation), assuming that the whole block has been allocated to that LIR (this is relevant only for /16s). Therfore I suggest something like: "The RIPE NCC accepts requests for reverse delegation solely for address space that HAD BEEN ALLOCATED TO THE REQUESTING LIR AND AT LEAST ONE PORTION OF WHICH has been registered by the LIR as assigned to End Users in the RIPE Whois Database." (You will probably find a better word than "portion" to describe this). Best regards, Janos From webmaster at ripe.net Thu Jun 27 21:24:33 2002 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 27 Jun 2002 21:24:33 +0200 Subject: [lir-wg] New IPv6 Documents available Message-ID: <200206271924.g5RJOXA28029@birch.ripe.net> New/Revised RIPE Document Announcement, apologies for multiple e-mails. -------------------------------------- Revised/new documents available from the RIPE document store. Ref: ripe-246 Title: IPv6 Address Allocation and Assignment Policy Author: ARIN, APNIC, RIPE NCC Date: 27 June 2002 Format: PS= 812450 TXT=31632 Obsoletes: ripe-196 Ref: ripe-247 Title: Initial IPv6 Allocation Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=16615 TXT=4226 Obsoletes: ripe-195 Ref: ripe-248 Title: Supporting Notes to the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=28439 TXT=12788 Ref: ripe-249 Title: IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=16477 TXT=4126 Ref: ripe-250 Title: Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=34008 TXT=15211 Short content description ------------------------- This set of IPv6 documents define registry policies for the assignment and allocation of globally-unique IPv6 addresses to Internet ServiceProviders (ISPs) and other organisations. The core document: "IPv6 Address Allocation and Assignment Policy" (ripe-246) obsoletes the "Provisional IPv6 assignment and allocation policy document" (ripe-196). It was developed through joint discussions among the APNIC, ARIN and RIPE communities. The other documents support the policy document, and provide Local Internet Registries with request forms for IPv6 address space. Supporting notes for the request forms can be found in the supporting notes documents. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW at the following URLs: "IPv6 Address Allocation and Assignment Policy" (ripe-246) is available at: http://www.ripe.net/ripe/docs/ipv6policy.html "Initial IPv6 Allocation Request Form in the RIPE NCC Service Region" (ripe-247) is available at: http://www.ripe.net/ripe/docs/ipv6-initial.html "Supporting Notes for the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region" (ripe-248) is available at: http://www.ripe.net/ripe/docs/ipv6-supp-initial.html "IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region" (ripe-249) is available at: http://www.ripe.net/ripe/docs/ipv6-assignment-request.html "Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region" (ripe-250) is available at: http://www.ripe.net/ripe/docs/ipv6-supp-assignment.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-246.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-246.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version Kind Regards, RIPE NCC Document Announcement Service From leo at ripe.net Fri Jun 28 11:17:24 2002 From: leo at ripe.net (leo vegoda) Date: Fri, 28 Jun 2002 11:17:24 +0200 Subject: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder In-Reply-To: <200206240932.LAA13841@banknet.banknet.net> References: <200206240932.LAA13841@banknet.banknet.net> Message-ID: <20020628091723.GA30947@ripe.net> On Mon, Jun 24, 2002 at 11:32:21AM +0200, Janos Zsako wrote: Re: Re: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder [...] > I would have a short question and a suggestion for clarification. > > 1. Is the last paragraph of 3.0 not superfluous in the light of the last > paragraph of 5.0? > > 3.0: "LIRs should maintain DNS resource records for address space assigned > to End Users from their own address space, even if the user obtains > connectivity from a different LIR." > > 5.0: "LIRs should provide reverse delegation corresponding to an assignment > during the complete validity period of the assignment." Good point. We'll make the change. [...] > 2. I think the intent of first paragraph of 3.0 is to accept a reverse > delegation of an address block as soon as there is ANY address space > assigned from it (i.e not ALL has to be assigned prior to reverse > delegation), assuming that the whole block has been allocated to that > LIR (this is relevant only for /16s). Therfore I suggest something like: > > "The RIPE NCC accepts requests for reverse delegation solely for address > space that HAD BEEN ALLOCATED TO THE REQUESTING LIR AND AT LEAST ONE PORTION > OF WHICH has been registered by the LIR as assigned to End Users in the RIPE > Whois Database." > > (You will probably find a better word than "portion" to describe this). Good point. We will incorporate a suitable change. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager