June 2002 - lir-wg - mailman.ripe.net

Re: Re: KPNQwest ns.eu.net server.
by Sabine Dolderer/Denic 07 Jun '02

07 Jun '02

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(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235 Jan-Ahrent Czmok An: Joao Luis Silva Damas <joao(a)ripe.net> <czmok@gatel. Kopie: randy(a)psg.com, ddiaz(a)ripe.net, routing-wg(a)ripe.net, net> lir-wg(a)ripe.net, tech-l(a)ams-ix.net, apops(a)lists.apnic.net, Gesendet von: nanog(a)merit.edu, apnic-talk(a)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(a)gatel.net> From: owner-lir-wg(a)ripe.net SendTo: Joao Luis Silva Damas <joao(a)ripe.net> CopyTo: randy@psg.com;ddiaz@ripe.net;routing-wg@ripe.net;lir-wg@ripe.net;tech-l@ams-ix.net;apops@lists.apnic.net;nanog@merit.edu;apnic-talk@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(a)lists.ripe.net PRINCIPAL: Jan-Ahrent Czmok <czmok(a)gatel.net> In_Reply_To: <p05111700b92449b9ddee(a)[193.0.1.81]> References: <200206051725.g55HPlA05396(a)birch.ripe.net> <E17Ff8f-0003So-00(a)roam.psg.com> <p05111700b92449b9ddee(a)[193.0.1.81]> 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(a)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 <joao(a)ripe.net> 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(a)gatel.de

11 10

ASO AC - Call for Nominations 2002 - RIPE NCC Service Region
by Paul Rendek 06 Jun '02

06 Jun '02

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 <nominations(a)ripe.net> 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

2 1

KPNQwest ns.eu.net server.
by Daniel Diaz 06 Jun '02

06 Jun '02

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

13 16

Re: new swamp ?
by James Aldridge 05 Jun '02

05 Jun '02

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)

3 2

Re: new swamp ?
by James Aldridge 05 Jun '02

05 Jun '02

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

1 0

Re: new swamp ?
by Bernard Steiner 05 Jun '02

05 Jun '02

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

3 2

new swamp ?
by Andre Stiphout 04 Jun '02

04 Jun '02

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

4 3

Re: new swamp ?
by James Aldridge 04 Jun '02

04 Jun '02

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)

1 0

New Document available: RIPE-242
by RIPE NCC Document Announcement Service 04 Jun '02

04 Jun '02

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

1 0

Re: IPv6 policy and Supernational-LIRs
by Wilfried Woeber, UniVie/ACOnet 03 Jun '02

03 Jun '02

>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 ;-)

1 0