August 2000 - lir-wg - mailman.ripe.net

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

Draft Agenda LIR-WG 37
by Hans Petter Holen 12 Sep '00

12 Sep '00

1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 35 minutes actions 5. Reports from the Registries RIPE NCC APNIC ARIN ICANN Status of the Latin and AFRI NiCs 6. Report from the address council 7. Presentations of candidates for the AC election 8. Status of the ICANN ad Hoc group 9. Report from the 17th of may Task Force 11. AOB.

1 2

ANNOUNCEMENT: Second Public Beta Release of Asused
by Maldwyn Morris 08 Sep '00

08 Sep '00

Hi, The RIPE NCC are pleased to announce the release of a second public beta version of Asused. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The main changes have been to tidy the code and to merge the code ( and version number ) for our internal tool with that of the public version. The only part missing from the public version is now that which performs checks using information that is proprietary to our members. We have also fixed some bugs in the software found by internal and external users: * Free space at the beginning of an allocation was not handled correctly * Some overlapping assignments were being missed. * Assigned address space was not always calculated correctly. * Overlaps caused more than 100% usage. Thanks for the bug reports. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.5.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. We are keen to receive your feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn(a)ripe.net Software Manager RIPE NCC

1 1

Address Space Waiting Time...
by Feico Dillema 04 Sep '00

04 Sep '00

Hello, I filed a first request for address space for a new LIR about a week ago. Ticket number is NCC#2000085969 and it's still in the waiting queue. Can any of you give me a hint on what the average queuing time is at the moment? My boss is getting a bit nervous as it is on the critical path for meeting some deadlines, and I'd like to be able to tell him whether he can relax or should panic... Thanks, Feico.

3 3

RE: ripe-db question
by Christian Storch 02 Sep '00

02 Sep '00

Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. - Perhaps that page could solve your question. regards, Christian //========================== // Christian Storch // InfraNet AG // Niederlassung Muenchen // Hansastr. 136 // D-81373 Muenchen // phone: +49 89 743523-55 // fax: +49 89 743523-23 // E-mail: storch(a)infra.NET //========================== -----Original Message----- From: mediaWays Hostmaster [SMTP:hostmaster@mediaways.net] Sent: Wednesday, August 30, 2000 4:24 PM To: lir-wg(a)ripe.net; db-wg(a)ripe.net Subject: ripe-db question Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

2 1

ripe-db question
by mediaWays Hostmaster 02 Sep '00

02 Sep '00

Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

7 8

Is this normal behaviour?
by Marco Davids 01 Sep '00

01 Sep '00

Hello, A routine check on as-macro AS-EURONET on the RIPE-database returned an unexpected result. The same check on the RADB whoisd (whois.raddb.net) however, returned the expected result together with two unexpected ones. Investigation learned us that someone deleted an unprotected as-macro on the RIPE-database. It seems it is fixed now. But what I would like to know is to what extend the several whois databases a synchronised, in other words; how reliable is the information retrieved from it? And... is the as-set object supposed to be unique or not? -- Marco Davids / SARA - Academic Computing Services Amsterdam Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt

7 7

IP allocs on the NAPs/IXs
by Berislav Todorovic 31 Aug '00

31 Aug '00

Hello, Apologies if this is a FAQ, but I really didn't find any site that contains a list of IP address allocations/assignments for various Internet exchange points worldwide. Is there any list of NAP addresses available? Such a thing would be useful to filter out leaking NAP address announcements from peers. Thanks in advance for any information! Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

1 0

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Wilfried Woeber, UniVie/ACOnet 31 Aug '00

31 Aug '00

>Subj: RE: SLA's needed !!! (Was: Re: ASN wait time) IMHO, it's "fairly" simple to get this problem under control: Assumptions: - the RIPE NCC is working for it's members and for the common good of the (european) Internet (providers, and thus, indiretly users). - RIPE and the RIPE NCC's Members define and approve (by providing the NCC's funding) the rules which govern the distribution of Internet Resources, as implemented on a day-to-day basis by the hostmasters. Requirement: (under the assumption - to be verified - that indeed there is still a performance problem at the NCC) - get the community to review the usefulness and the boundary conditions of the existing policy framework. - get the community to review the allocation of resources to the NCC to implement these policies. - get the NCC to implement an *internal* feedback loop which breaks the vicious circle of (sometimes perceived as unilaterally) tightening operational rules (with good intentions, indeed!) when the additional resources are not available to cope with the additional workload. I'd say that many (all?) of those things are being worked on already, in one way or another. Although the positive effects of those efforts might still not be obvious to the community at large... <Rant> Thinking in terms of money is not a useful approach here, for many reasons as already given during the discussion and some others, too, because what you/we (the customers) really want to obtain is _fast_ *and* _fair_ access to (sometimes perceived as limited) Internet Resources. I guess most of us are not interested in the first place to save money or to spend additional money when doing so wouldn't have any positive systematic impact on the resolution of the underlying problem... </Rant> -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Jorma Mellin 31 Aug '00

31 Aug '00

>service. So, if a LIR decides to have an SLA-bound agreement, it will pay N >times more (N may be even 10 or 20) than a standard contribution fee, but >will get guaranteed service. If RIPE NCC fails to provide service to those >registries, they would pay penalties, which would be automatically deduced >from the LIR contribution fee. > >All other registries should pay normal fees and get normal class of service >(not SLA bound, no penalties for delays etc.). I't doesn't sound too good, because in that model you can use money to obtain better service. So that model is going to hurt the LIR's who are not willing or able to pay. I know my employer can easily afford to pay to get the service we want, but somehow it doesn't sound right when we are talking about a resource (IP addr. space) what should be divided among users as equally as possible. But, if every LIR would agree to pay a small amount if service is running smoothly then we are all at the same level. And it doesn't require an application to keep track who has what SLA. So far I haven't hear a fact that the long delays are caused by lack of human resources. It has beeing an assumption so far. If it really is a manpower problem how many people we do need more and how much money it takes to hire and train them? BTW, I have handled the problem with queues so that we do not make any exact promices to our customers that they can have numbers an a given date. More or less we explain that there is a process behind all this and it is there because of a reason. 99% of them are happy with that. Problems usually start when too optimistic promices are beeing made (by someone not familiar with the process). Jorma

2 1

RE: SLA's needed !!! (Was: Re: ASN wait time)
by Jorma Mellin 31 Aug '00

31 Aug '00

>Therefore, personally, I think it's time for us to start thinking how to set >up SLA's between LIRs and RIPE NCC: let's define strict time boundaries for >the first and later hostmaster answers to an IP/AS request. It doesn't matter >whether it is 5, 7 or 14 days - but let's define them and abide by them. Also, >an escalation procedure within RIPE NCC is needed (who to contact should a >request get not processed - e.g. Registration services manager and higher), >determine what happens should RIPE NCC fail to process a request within >specified time (e.g. deduce XXX EUR from next year contribution fee for each >day of delay). That doesn't clear the problem. The lack of resources don't vanish if issues are escalated to managers and such. Or if they do vanish we have a problem with work-moral within hostmasters. There is a risk with this suggestion that service-time (SLA) would be different for different LIR's, and the LIR whose hostmaster yells out load will get serviced first. If we reduce the annual contribution fee when a request is not served within the SLA, we are only making things worse. RIPE NCC will then have even less money to correct the problem. Maybe we should try to give somekind of carrot to NCC. If IP/ASN request is served less than 5 working days give 100EUR extra contribution, if it is served in less than 2 working days give 200EUR. This is also an equal method, you cannot use money to buy SLA's. Jorma ---------------------------------------------------------- jorma.mellin(a)teliafi.net Development Manager ; CCIE#4185 Telia Finland Inc, Network Services

3 2

Re: ASN wait time
by Hank Nussbacher 31 Aug '00

31 Aug '00

At 09:04 31/08/00 +0100, Willy Calderon wrote: Yes, I got hit by this last week after having filed over 80 ASN requests with no problem. Fortunately, we require a signed fax on letterhead from the requestor stating the 2 peers as well as other details. Even so, we have had about 5 cases of organizations either never announcing the ASN or reverting to being single homed. We continue to chase after those that do not use their ASN properly and have returned a few ASN to RIPE in the past and have 2-3 in the return process now as well. I would imagine that sites that do not require a signed document from a VP level or higher from the company asking for the ASN will incur an even higher rate than the 6% we have of troublemakers. I know that RIPE has started to scan the major peering sites to see if ASNs assigned are indeed multihomed (we have been doing that for the past 2 years - on a quarterly basis for all ASN's assigned) and I guess they are finding too many not being used, so they have toughened their ASN assignment policies. ASNs are also a finite resource - just like a /19. -Hank >Good morning, > >We filed a request for an AS Number several weeks ago. Ticket number is >NCC#2000085127. Having finally receiving initial response from RIPE late >last week, we were then asked to provide contact details for the ISP that >we had placed in our application. The reason being that RIPE would be >contacting them in their time to confirm that they will accept peering and >allow our PA space. Presumably this will take another few weeks for them >to verify that indeed our application was accurate and said ISP has agreed >to accept our peering details. As this is urgent, I'm quite concerned >whether or not this is the norm now at RIPE. > >Has this happened to anyone else? That is, has their ASN application >been needlessly delayed like this? > >Thanks, > >Willy Calderon

1 0

ASN wait time
by Willy Calderon 31 Aug '00

31 Aug '00

Good morning, We filed a request for an AS Number several weeks ago. Ticket number is NCC#2000085127. Having finally receiving initial response from RIPE late last week, we were then asked to provide contact details for the ISP that we had placed in our application. The reason being that RIPE would be contacting them in their time to confirm that they will accept peering and allow our PA space. Presumably this will take another few weeks for them to verify that indeed our application was accurate and said ISP has agreed to accept our peering details. As this is urgent, I'm quite concerned whether or not this is the norm now at RIPE. Has this happened to anyone else? That is, has their ASN application been needlessly delayed like this? Thanks, Willy Calderon

2 1

Re: ripe-db question
by Brent_Frere＠ses-astra.com 31 Aug '00

31 Aug '00

We (SES, Societe Europeene des Satellites, operator of Astra satellite system) assign IP addresses to end-customers who are using our Internet access by satellite. The only geographic limit we are sure about them is that they are in the Astra satellite system footprint... Footprint is visible at http://www.ses-astra.com/multimedia/bbi So I think this might slighly change your statistics if you count all them as Luxembourg citizens... Brent Frere, SES (Astra) Chateau de Bezdorf L-6815 Betzdorf Grand-Duchy of Luxembourg General phone: +352-710.725-1 Direct phone: +352-710.725-401 E-mail: bfrere(a)ses-astra.com URL: http://www.ses-astra.com "mediaWays Hostmaster" To: lir-wg(a)ripe.net, db-wg(a)ripe.net <hostmaster@medi cc: aways.net> Subject: ripe-db question Sent by: owner-lir-wg@rip e.net 08/30/00 05:23 PM Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

2 1

RE: ripe-db question
by Stefan.Gasteiger＠Gendorf.de 30 Aug '00

30 Aug '00

You should use MIME content negotiation for this purpose. Have a look at: http://www.apache.org/docs/mod/mod_mime.html#multipleext Stefan Gasteiger SG5599-RIPE I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger(a)gendorf.de > -----Original Message----- > From: mediaWays Hostmaster [mailto:hostmaster@mediaways.net] > Sent: Wednesday, August 30, 2000 4:24 PM > To: lir-wg(a)ripe.net; db-wg(a)ripe.net > Subject: ripe-db question > > > Hi, > > some strange question: > we need a complete list of assigned IP-Addresses > in the european part of ripe region sort by country > for a customer. > Is there any chance to get it per whois/some > application or do we buy some part of whois-db from ripe? > > The background is that a Online-Service needs this part > of information to display the right website (on his top-level > Webserver wich are reached by every online user first) > for every user by his language. > > We are grateful for each assistance. > > Kind regards, > _____________________________ > Stephan Mankopf > Networks/Backbone > +49 5241 80 88729 > stephan.mankopf(a)mediaways.net > > > > >

1 0

IP addresses
by Andrius Kasparavicius 19 Aug '00

19 Aug '00

hello, maybe somewhere is information about how many IP addresses is used as network and broadcast address today? How many addresses is unused yet? When has been created IPv4? ------------------------- Kasparavicius Andrius ________________________________________________________________________ http://www.andrius.org ICQ:17701001 tel.: +370 87 25630 nick: Casper AND-RIPE AND-6BONE

1 0

Re: lame delegations
by Joshua Goodall 18 Aug '00

18 Aug '00

(cross-cc'd to the RIPE LIR working group list for potential interest/comment) I suspect that solving this correctly would depend on the ICANN DNSO recognising the authentication mechanisms of the databases of the RIR's under the ICANN ASO (RIPE, ARIN, APNIC). Unfortunately, no-one thought of this problem when they let registrars inject host records. The only way to verify automatically that a host record is allowed from a given netblock is to use the same authentication mechanisms that (say) RIPE do for reverse delegations. I doubt that the RIR databases would take the strain of continuous lookups in that fashion. Futhermore, the RIPE database only defines password and PGP access controls for the LIR allocated space, not the assigned space used by nameserver operators. (no need to speculate upon the hazards of mail-from authentication). One possible solution, probably even manageable is that the DNSO/NSI Registry accepts host updates (or even just withdrawals) from an automated RIR system that can be triggered by correctly authenticated LIR maintainers, in the way that in-addr mappings already are. This satisfies the point-of-control requirements, and could probably be implemented without a change to the existing RRP. I don't know whether the situation arises often enough to motivate such a solution, but I would bet a (small) amount of money on some scriptkiddie reading this thread and trying it out for their dubious kicks. (you may guess correctly that I'm more familiar with RIPE systems than ARIN/APNIC :)) -[ Joshua Goodall ]----------------------------------------------- -[ IP Systems Architect ]---------------- Cook, Geek, Lover ------ -[ joshuag(a)interxion.com ]--------------- joshua(a)roughtrade.net -- On Fri, 18 Aug 2000, John O Comeau wrote: > > Obviously I didn't make it clear what is the problem in my previous post. > So far I got the following 2 replies: > > "The NIC should allow for dummy [default] nameservers and allow the > technical contact of a nameserver to remove his or her nameservers from a > domain without requiring an administrative ack." > > Yes, but we are not the technical nor the admin contact for these domains; > we just provide the IPs. What I propose is that the tech or admin contact > of the NETBLOCK has authority to delete the host registration by virtue of > the IP being his. > > "If the IP's are allocated to you, what's it matter where your old > customer still points their NS? Just remove the old customer from all of > your db's and reallocate your IP's elsewhere." > > We've been doing precisely that, and that's where the problem comes in. > The new customer cannot register his nameservers because the IP is already > registered as a nameserver. Then he complains, we look like idiots, and we > have to give him other IPs to use. > > jcomeau(a)world.std.com aka John Otis Lene Comeau > Home page: http://world.std.com/~jcomeau/ > Disclaimer: Don't risk anything of value based on free advice. > "Anybody can do the difficult stuff. Call me when it's impossible." > >

4 4

RE: ccTLD data moving from RIPE db
by Wilfried Woeber, UniVie/ACOnet 17 Aug '00

17 Aug '00

[ editorial: I think this should move from lir-wg(a)ripe.net to db-wg(a)ripe.net So, for any follow-up, please use db-wg and remove lir-wg. Thanks. ] Alex, >Then today I got a mail from the .IE domain registry, asking me to remove >entries from the RIPE DB for some .ie domains I have. The RIPE NCC, or the RIPE community never had any authority over the ccTLD name tree in the RIPE-DB. The individual sub-trees were (some still are) managed by the respective TLDs. So, from that point of view, the request in itself is probably valid. > So far so good, >except that the .ie domain registry does not have a functional whois >database to which we can move this data. If I comply, the data will no >longer be accessible from any whois databse. Well, not necessarily so. What "we" (the people and groups involved to migrate the name sub-trees to dedicated registries, maintined by the TLDs) had in mind was to preserve the "single point of entry" for the RIPE region to query domain names. To that end, the DB software was extended to support a referral mechanism. Assuming that this technology is deployed, you could still send your query to whois.ripe.net and the software would try to find a referred-to server which is authoritative for the name-tree. The RIPE server would then forward the request and send the answer back to the client. Quite a few TLD registries, which already have moved away from using the RIPE DataBase have completed that setup. Others are in the process of fixing migration problems. Other, obviously, have decided to _not_ use that option. Sigh. I'm still working with the RIPE NCC's DB group and CENTR to fixing deployment problems related to the referral mechanism. A couple of days ago, a summary page has become available on CENTR's server: http://www.centr.org/technical/ripe-db.html >Is this therefore a valid request? > >Thanks, Best regards Wilfried (DB-WG chair) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The strange thing about common sense is that it is so uncommon. Buddah

1 0

RE: ccTLD data moving from RIPE db
by Mally Mclane 17 Aug '00

17 Aug '00

> I followed with some interest the debate in this list > regarding ccTLD data > being removed from the RIPE db for .de. > > Then today I got a mail from the .IE domain registry, asking > me to remove > entries from the RIPE DB for some .ie domains I have. So far so good, > except that the .ie domain registry does not have a functional whois > database to which we can move this data. If I comply, the > data will no > longer be accessible from any whois databse. > I would assume that since the Irish Government Data Protection Act prvents .ie informatio n from being accessed, this is indeed a valid request. regards, mally mclane =>senior hostmaster =>for Energis Squared, Leeds, UK =>mally(a)energis-squared.com <> www.energis-squared.com =>t: +44(0)1132076624 <> m: +44(0)7787100695

2 1

ccTLD data moving from RIPE db
by Alex French 17 Aug '00

17 Aug '00

Hi all, I followed with some interest the debate in this list regarding ccTLD data being removed from the RIPE db for .de. Then today I got a mail from the .IE domain registry, asking me to remove entries from the RIPE DB for some .ie domains I have. So far so good, except that the .ie domain registry does not have a functional whois database to which we can move this data. If I comply, the data will no longer be accessible from any whois databse. Is this therefore a valid request? Thanks,

1 0

RIPE-160
by Hank Nussbacher 17 Aug '00

17 Aug '00

While reviewing RIPE-160: http://www.ripe.net/ripe/docs/ripe-160.html for a customer, the customer asked me "Where does it state that RIPE will keep all the information provided confidential? The info provided in the RIPE-160 - form as well as RIPE-141 has very confidentail info." I reviewed as well http://www.ripe.net/ripe/docs/ripe-173.html - The General Terms and Conditions and no place does it state that the information provided by the new LIR will be treated in confidentiality. I must be missing it among the various RIPE docs. Please point me to the correct one. Thanks, Hank

2 2

Re: New AS request in another country
by Kai Keinänen 16 Aug '00

16 Aug '00

On Wed, 16 Aug 2000, Berislav Todorovic wrote: > A rather better approach is to try to plan address space assignment within > the current allocation smarter. Say, if xx.foo was allocated 172.16/16 in the > past and it wants to start its business in the country YY, then they may > "reserve" a small /20 within that allocation (say 172.16.240/20) and start > assigning addresses to YY customers from that /20, while using the rest of > the /16 for XX customers. This is rather difficult for the new registries who do not have many /16:s of free address space. This is due to the requirement of 80% fill-up of an allocation before a new allocation can be obtained. Basically, dividing a /16 into a /17 and 8 per-country /20:s would be optimal from the routing point of view: the /16 could be presented as an aggregate to transit or to non-European peers. However, if business grows at different speeds in different countries, and one is only able to allocate /21 in half of the countries, the fill-up ratio will remain at 75%, making it impossible to get a new allocation and forcing a renumbering. Thus, it seems that the current policies force one to register several LIRs, and to request distinct non-aggregatable address spaces. This leads to explosion of routing tables. Is this really what we want? (The alternative would be to change policies to allow a LIR to have several open allocations when the open allocations would be under different routing policies.) - Kai Keindnen Saunalahti Oyj -- Kai Keinanen >>>^<<< GSM: +358 456 700 100 Technology Director /$\ mail: PL 96, 33721 Tampere SAUNALAHTI OYJ, Finland | | email: Kai.Keinanen(a)saunalahti.fi .88.744/7.88.744/7.88.744/7.88.oOOOo.88.744/7.88.744/7.88.744/7.88.744/7.8

2 1

Re: New AS request in another country
by Joao Luis Silva Damas 16 Aug '00

16 Aug '00

I just realized I left part of the original message unaddressed. > Can LIR xx.foo request a new allocation and a new ASN for use by the new > daughter? For IP allocations, you must have a second LIR. One LIR can only have one open IPv4 allocation at one given time. Joao

5 7

New AS request in another country
by Herbert Baerten 15 Aug '00

15 Aug '00

Dear colleagues, after reading various related RIPE documents, the following question is still not clear to me: suppose a company Foo.xx in country X (operating a LIR xx.foo) wants to start up a daughter company in country Y, where it will need a new AS. Can LIR xx.foo request a new allocation and a new ASN for use by the new daughter? or Does it need to establish a legal entity in country Y, start up a new LIR yy.foo, and have yy.foo request a new allocation and ASN ? tia! kind regards, Herbert -- Herbert Baerten HB5351 HostIT Network Manager NCC9166-RIPE

5 5

Re: Fwd: Re: RIPE-160
by Wilfried Woeber, UniVie/ACOnet 09 Aug '00

09 Aug '00

=> - what is the meaning of "PIR"? = =I used that TLA to refer to Planetary IR. Ahhhh :-) -WW

1 0