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

Re: AS number revokes
by Sabrina Wilmot 01 Mar '02

01 Mar '02

"Stephen Burley" <stephenb(a)uk.uu.net> writes: * Thankyou. Where is this documented? Hi Stephen, Please have a look at document RIPE-185 "European Internet Registry Policies and Procedures, http://www.ripe.net/ripe/docs/ir-policies-procedures.html#toc75 [..] Technical Details Current assignment guidelines require a network to be multihomed for an AS number to be assigned. When a registry applies for an ASN, it needs to submit the routing policy of the Autonomous System that requires an AS number. ... 7.2.Returning an AS Number If an oranisation has an AS number that is no longer in use, it can be returned to the public pool of AS numbers by sending a message to <hostmaster(a)ripe.net>, it can then be re-assigned to another autonomous system by the RIPE NCC. [..] By sending out messages asking if an AS number is in use (multihomed) or not the RIPE NCC makes sure this policy is applied. As mentioned in my previous message if it turns out that an AS number appears not to be in use after being assigned for almost a year (or more) the LIR should consider to return it. Regards, Sabrina Wilmot -- o------------------------------------------o | Sabrina Wilmot sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o * > Hi, * > * > "Stephen Burley" <stephenb(a)uk.uu.net> writes: * > * Hi * > * I am a bit concerned about an email we recieved threatening the * > * revokation of an assigned AS number if it did not appear to be used. It * > * concerns me for a number of reasons. * > * * > * 1. Our customer has had problems with other providers and there own * network, * > * which has postponed the intended use of the AS for quite a few month, * all * > * due to things out of their and our control. * > * > This can always happen and we do ask several times for information before * > mentioning the option of returning an assigned AS number which appears not * > to be in use. The first time we ask is 6 months after the assignment. * > * > * 2. If you do revoke it then the customer may suddenly get things fixed * and * > * start using the AS as intended but in the meantime you assign it to * another * > * customer and the problems ensue. If you do not assign it why whould you * ask * > * for it back? * > * > If you do not use it why should you keep it? :) * > Our intention is to make sure AS numbers are used and not wasted. * > * > We send several reminders asking about the status and this process is * > taking a couple of months. If you are not able to start using the AS * > number after a long time we ask you to return it. To date the RIPE NCC * > Hostmasters could always find an agreement with the LIRs to return AS * > numbers that appeared not to be in use. * > * > We do reassign returned AS numbers *not* straight away but after a certain * > time period ("sleeping time") and ... * > * > * 3. Just because an AS does not appear in the looking glass does not * mean * > * that its not being used in situation which does not mean it does not * need to * > * be announced at any looking glass. * > * > ... we do not only use the Looiking Glass to find the number of peers. We * look * > back in time at least on several days using 'asiuse' - publicly know as * the * > RIS Database, from New Projects. * > * > * Please could you clarify this situation? * > * * > * Regards * > * Stephen Burley * > * UUNET EMEA Hostmaster * > * SB855-RIPE * > * * > * > * > Regards, * > * > Sabrina Wilmot * > * > -- * > * > o------------------------------------------o * > | Sabrina Wilmot sabrina(a)ripe.net | * > | Registration Services Operations Manager | * > | | * > | RIPE NCC tel +31 20 535 4444 | * > | www.ripe.net fax +31 20 535 4445 | * > o------------------------------------------o * > * > *

5 4

Fwd: Do not remember this
by Katri 28 Feb '02

28 Feb '02

Hello! I partly agree with Stephen. I actually didn´t find the notify to hm-dbm-msgs(a)ripe.net really useful, but it´s not the point. I would also like to know why it was decided by RIPE NCC without first announcing it at the mailinglist. Are you planning other changes that we might want to know about? Regards Katri Tele2/Swipnet IP Registry Local Internet Registry __________________________________________________________ Tele2/SWIPnet Tel: 08 5626 40 08 Box 62 Fax: 08 5626 42 10 164 94 Kista Email: ip(a)swip.net SWIP-RIPE SWIPNET-LIR-MNT __________________________________________________________ >Delivered-To: lists-lir-wg-out(a)lists.ripe.net >From: "Stephen Burley" <stephenb(a)uk.uu.net> >To: <lir-wg(a)ripe.net> >Subject: Do not remember this >Date: Thu, 28 Feb 2002 12:11:57 -0000 >X-Mailer: Microsoft Outlook Express 6.00.2600.0000 >Sender: owner-lir-wg(a)ripe.net >X-Loop-Detect: RIPE NCC > >Hi > I am a little concerned with the email we recieved today (copied below >in part). This was sent to the community and enforced without any reason why >or justification or even a dicussion as the the change in working practice. >As the NCC work for the benefit of the RIPE community i would have thought >this sort of change in working practice would have to be agreed with the >community before the announcment went out. I may have missed the discussion >on the list and if so i am sorry but i still would think it manners to >explain why. I for one found this functionality very useful. > >Regards, >Stephen Burley >UUNET EMEA Hostmaster >SB855-ripe > > >[PLEASE FORWARD THIS TO YOUR LOCAL INTERNET REGISTRY CONTACT] > >Dear Colleague, > >This email is to inform you that the RIPE NCC no longer updates >its internal record for your Local Internet Registry contacts >based on the tech-c or admin-c changes you make within your role >object. Therefore we ask you to remove the line >'notify: hm-dbm-msgs(a)ripe.net' from your role object:

1 0

Do not remember this
by Stephen Burley 28 Feb '02

28 Feb '02

Hi I am a little concerned with the email we recieved today (copied below in part). This was sent to the community and enforced without any reason why or justification or even a dicussion as the the change in working practice. As the NCC work for the benefit of the RIPE community i would have thought this sort of change in working practice would have to be agreed with the community before the announcment went out. I may have missed the discussion on the list and if so i am sorry but i still would think it manners to explain why. I for one found this functionality very useful. Regards, Stephen Burley UUNET EMEA Hostmaster SB855-ripe [PLEASE FORWARD THIS TO YOUR LOCAL INTERNET REGISTRY CONTACT] Dear Colleague, This email is to inform you that the RIPE NCC no longer updates its internal record for your Local Internet Registry contacts based on the tech-c or admin-c changes you make within your role object. Therefore we ask you to remove the line 'notify: hm-dbm-msgs(a)ripe.net' from your role object:

1 0

Re: AS number revokes
by Sabrina Wilmot 28 Feb '02

28 Feb '02

Hi, "Stephen Burley" <stephenb(a)uk.uu.net> writes: * Hi * I am a bit concerned about an email we recieved threatening the * revokation of an assigned AS number if it did not appear to be used. It * concerns me for a number of reasons. * * 1. Our customer has had problems with other providers and there own network, * which has postponed the intended use of the AS for quite a few month, all * due to things out of their and our control. This can always happen and we do ask several times for information before mentioning the option of returning an assigned AS number which appears not to be in use. The first time we ask is 6 months after the assignment. * 2. If you do revoke it then the customer may suddenly get things fixed and * start using the AS as intended but in the meantime you assign it to another * customer and the problems ensue. If you do not assign it why whould you ask * for it back? If you do not use it why should you keep it? :) Our intention is to make sure AS numbers are used and not wasted. We send several reminders asking about the status and this process is taking a couple of months. If you are not able to start using the AS number after a long time we ask you to return it. To date the RIPE NCC Hostmasters could always find an agreement with the LIRs to return AS numbers that appeared not to be in use. We do reassign returned AS numbers *not* straight away but after a certain time period ("sleeping time") and ... * 3. Just because an AS does not appear in the looking glass does not mean * that its not being used in situation which does not mean it does not need to * be announced at any looking glass. ... we do not only use the Looiking Glass to find the number of peers. We look back in time at least on several days using 'asiuse' - publicly know as the RIS Database, from New Projects. * Please could you clarify this situation? * * Regards * Stephen Burley * UUNET EMEA Hostmaster * SB855-RIPE * Regards, Sabrina Wilmot -- o------------------------------------------o | Sabrina Wilmot sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

2 1

AS number revokes
by Stephen Burley 27 Feb '02

27 Feb '02

Hi I am a bit concerned about an email we recieved threatening the revokation of an assigned AS number if it did not appear to be used. It concerns me for a number of reasons. 1. Our customer has had problems with other providers and there own network, which has postponed the intended use of the AS for quite a few month, all due to things out of their and our control. 2. If you do revoke it then the customer may suddenly get things fixed and start using the AS as intended but in the meantime you assign it to another customer and the problems ensue. If you do not assign it why whould you ask for it back? 3. Just because an AS does not appear in the looking glass does not mean that its not being used in situation which does not mean it does not need to be announced at any looking glass. Please could you clarify this situation? Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE

2 2

New Time Schedule for new IPv4 Policy Document
by Mirjam Kuehne 19 Feb '02

19 Feb '02

Dear Colleagues, As announced earlier the comment/suggestion period for the latest review of the "IPv4 Address Policies in the RIPE NCC Service Region" document has pasted. We are happy to announce that useful feedback was received and we are currently revising the document accordingly. Unfortunately, the deadline for publishing the revised draft set for 7 February 2002 has not been reached. As a result this will slightly change the time schedule published for the revision process. The RIPE NCC will publish the revised draft of the document to the ripe-185bis(a)ripe.net list by 1 March 2002 for the next revision period. Regards, Mirjam Kuehne RIPE NCC

1 0

AW: RIPE-230
by Koepp, Karsten 18 Feb '02

18 Feb '02

Hi Alan, I have not seen anybody answering. The changes in RIPE-230 have been discussed last year on this list. I objected to the initial allocation criterion as well, but was nearly alone and I admit, had no better proposal. Nowadays when becoming a LIR, you have to multi-home one of your upstream's PA space before you reach the /22 limit, or you request PI from RIPE (I have not done this, but this would be my proposal). <SNIP> > So: > De-aggregating our /20 is not an option. Some providers filter. No, that's the only solution I can see. Nobody is filtering on allocation boundaries, because partition is the only way to multi-home. RIPE-230 aims at *conservation* of IP space. Aggregation will suffer. You should request additional ASNs and assign (or have assigned) multiples of /24 to each of your PoPs/networks. Does this help? Karsten > > Taking the same set of suppliers, de-aggregating to them and > having our > upstream announce our aggregated block is not an option because of our > footprint and our desire to be open in terms of suppliers. > > So to go forward we need to: > > 1. Register as an LIR at a country level (as we, as a single LIR > do not qualify for multiple PA assignments under current assignment > policy, even though this would be administratively easier for us) > > *OR* > > 2. leased line connectivity (and no, not a tunnel across multiple > AS's!!) between each country which simply introduces another > POF, another > cost overhead and increases the possibility of blackholing > parts of your > AS if an inter-country link fails. (remembering that our > advantage is we > have all these carriers on our doorstep aka ODF) > > Justifying a /22 for immediate use is well, not possible. > Customers won't wait to be provisioned until you have enough > of them to > use a /22 immediately. > > Last year we applied to RIPE for LIR status and it was granted. > If this were still last year I'd do the same at a country level. > > However now RIPE-230 prevents this.... > > > > Possible (to bounce around) solutions are: > > Use other quantitative methods for approving LIR > status, i.e. what resources/capital investment will an LIR > put into to > ensuring their growth over a period. > > aka 'the put your money where your mouth is' metric. > && > Remove 3.2 from RIPE-230. > > *OR* > > Allow a PA allocation of /21 and Remove 3.2 from RIPE-230 > <lowers risk of waste should LIR be slow to reach > expectations, also as > the PA space exists in a LAN/MAN environment moving to /20 > announcement later is trivial, no real migration.> > > *OR* > > Allow LIR to use PI space for locally colocated customers > provided they > are in a situation to pull the plug. (service operator) - > > (possible flamebait, do we want more prefix's with less > un-utilized space > *or* less prefix's with higher un-utilized space in the short term? -- > also migrating enterprise hosting clients from PI to PA later is hell, > I imagine many will take the easy route and not bother until > sufficiently > pressured by RIPE/community.) > > Would appreciate a constructive dialog on how this can be > achieved. > > With Thanks. > Alan. > > > >

3 2

Important information on coming RIPE Meeting
by RIPE NCC Meeting Registration 14 Feb '02

14 Feb '02

Dear Colleagues, RIPE 42 will take place from 29 April - 3 May 2002 at the Grand Hotel Krasnapolsky in Amsterdam, the Netherlands. The registration for RIPE 42 will open on 18 February 2002. Outside the RIPE Meeting there are extra activities in Amsterdam during this week. These are: 29th April: Queen's Night Amsterdam In the evening there will be celebrations all over the center with bands playing in the streets. 30th April: Queen's Day Amsterdam Our Queen Beatrix will celebrate her 64th birthday on this day. Amsterdam will be turned into one big street fair. You will find bands playing on several corners and there will be an open market throughout Amsterdam. This happening will start at 11.00 hour in the morning and officially ends at 02.00 hour. The traffic situation will change slightly on the 30th April as the streets of Amsterdam will be used for the open market. Here are some helpful travel hints: Taxi from the airport to the hotel: All taxis are able to reach any hotel in the Amsterdam, including the Krasnapolsky. Tram from Central Station: This will not be possible and we advise you to walk from Central Station to the hotel. It is a 10 minute walk. There will be no trams running on the 30th April from 9.00 - 18.00 hour. By car: Please park your car in the Transferium at the Arena (ringroad Amsterdam Exit: Transferium). This is highly recommended. For further information please see <http://www.amsterdam.nl/e_tourism/toamsterdampark+ride.html#p+rvoorz0001> In the afternoon there will be celebrations throughout the city of Amsterdam. There will be approximately 800.000 people covering the streets of Amsterdam. To assist you in finding your accommodation in Amsterdam, we have blocked rooms at several hotels **, ***,**** and *****. If you prefer a stay in the Hotel Krasnapolsky, please fill in the form <http://www.ripe.net/ripe/meetings/current/ripe-42/krasform.html> and fax this to the hotel. If you prefer a stay in a different hotel, please fill in the form <http://www.ripe.net/ripe/meetings/current/ripe-42/amsterdam-hotel.html> or <http://www.ripe.net/ripe/meetings/current/ripe-42/amsterdam-hotel.pdf> and fax this to the hotel. This bookingservice will give you a discount up to 40%. If you have any problems making your arrangements or if you have any questions, please do not hesitate to contact us at <meeting(a)ripe.net>. With kind regards, Asha Raghoebarsing Meeting Coordinator ------- End of Forwarded Message

1 0

New Document available: RIPE-238
by RIPE NCC Document Announcement Service 13 Feb '02

13 Feb '02

[Apologies for duplicate mails] New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-238 Title: RIPE Database Reference Manual Author: Joao Luis Silva Damas, Andrei Robachevsky Date: 6 February 2002 Format: PS=277479 TXT=124400 Obsoletes: ripe-223 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document is an updated version of the "RIPE Database reference manual" (ripe-223). It describes the functionality of version 3.0 of the RIPE Database that uses the Routing Policy Specification Language to represent all Database objects. It also implements the Routing Policy System Security (RPSS) to provide authorisation mechanisms to enable a higher level of security for Internet Routing Registries (IRR). 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-238.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-238.txt plain text version You can also access the RIPE documents in HTML format via WWW. The RIPE Database reference manual is available from the WWW at the following URL: http://www.ripe.net/ripe/docs/databaseref-manual.html

1 0

New RIPE Database features
by Andrei Robachevsky 07 Feb '02

07 Feb '02

Dear colleagues, [ Apologies for multiple messages ] The new features of the RIPE Database requested by the community are now available in "beta version" on our TEST whois server (http://www.ripe.net/ripencc/pub-services/db/testdb.html). The new features are: - the "irt" object (please see my previous announcement at http://www/ripe/mail-archives/db-wg/current/msg00012.html) - the new "status:" value of the inetnum object "LIR-PARTITIONED PA/PI" (please see the original proposal at http://www/ripe/mail-archives/db-wg/20010701-20020101/msg00090.html). You may try these features by - sending your updates to test-dbm(a)ripe.net; - querying the test-whois.ripe.net, port 43. The new version of the software is under heavy testing now and will be put into production shortly after the RIPE meeting. Your comments are appreciated. You may contact the development team directly at dbrip(a)ripe.net. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 4