From andrei at ripe.net Thu Feb 7 12:55:08 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 07 Feb 2002 12:55:08 +0100 Subject: New RIPE Database features References: <3C430A73.3030607@ripe.net> Message-ID: <3C626B1C.3040107@ripe.net> Dear Colleagues, [ Apologies for multiple messages ] A new version of the RIPE Database software was put into production today, Thursday 7 February, at 9:00 UTC. It implements the new features I was referring to in my mail of 14 January. Also, some parts of the code were re-implemented, mainly regarding object parsing and syntax checks. The updated documentation describing these changes will be published soon. In case you experience problems with the new database system, please do not hesitate to contact ripe-dbm at ripe.net or the development team at dbrip at ripe.net. Kind regards, Andrei Robachevsky DB Group Manager RIPE NCC Andrei Robachevsky wrote: [...] > The new features are: > > - the "irt" object (please see my previous announcement at > http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00011.html) > - the new "status:" value of the inetnum object "LIR-PARTITIONED PA/PI" > (please see the original proposal at > http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00090.html). > [...] From andrei at ripe.net Thu Feb 7 12:55:08 2002 From: andrei at ripe.net (andrei at ripe.net) Date: Thu, 07 Feb 2002 12:55:08 +0100 Subject: New RIPE Database features In-Reply-To: <3C626B1C.3040107@ripe.net> References: <3C430A73.3030607@ripe.net> <3C626B1C.3040107@ripe.net> Message-ID: Dear Colleagues, [ Apologies for multiple messages ] A new version of the RIPE Database software was put into production today, Thursday 7 February, at 9:00 UTC. It implements the new features I was referring to in my mail of 14 January. Also, some parts of the code were re-implemented, mainly regarding object parsing and syntax checks. The updated documentation describing these changes will be published soon. In case you experience problems with the new database system, please do not hesitate to contact ripe-dbm at ripe.net or the development team at dbrip at ripe.net. Kind regards, Andrei Robachevsky DB Group Manager RIPE NCC Andrei Robachevsky wrote: [...] >> The new features are: >> >> - the "irt" object (please see my previous announcement at >> http://www.ripe.net/ripe/mail-archives/db-wg/current/msg00011.html) >> - the new "status:" value of the inetnum object "LIR-PARTITIONED >PA/PI" >> (please see the original proposal at >> >http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00090.html). >> > [...] From Karsten.Koepp at lambdanet.net Mon Feb 11 12:18:05 2002 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Mon, 11 Feb 2002 12:18:05 +0100 Subject: AW: RIPE-230 Message-ID: <39F27E3F569FD4119EF200508BAF85B90268D382@CCGNT30> 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). > 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 > 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. > > > > From gert at space.net Tue Feb 12 16:59:15 2002 From: gert at space.net (Gert Doering) Date: Tue, 12 Feb 2002 16:59:15 +0100 Subject: RIPE-230 In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90268D382@CCGNT30>; from Karsten.Koepp@lambdanet.net on Mon, Feb 11, 2002 at 12:18:05PM +0100 References: <39F27E3F569FD4119EF200508BAF85B90268D382@CCGNT30> Message-ID: <20020212165915.V56841@Space.Net> Hi, On Mon, Feb 11, 2002 at 12:18:05PM +0100, Koepp, Karsten wrote: > 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. Be warned: some people *do* filter on allocation boundaries. PA-holes will work anyway (due to the aggregate getting the traffic "near" the final location, and then the more-specific are used), but completely deaggregating might not be a overly good idea. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71887 (71770) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From ncc at ripe.net Wed Feb 13 13:30:35 2002 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Wed, 13 Feb 2002 13:30:35 +0100 Subject: New Document available: RIPE-238 Message-ID: <200202131230.g1DCUaO06349@birch.ripe.net> [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 From meeting at ripe.net Thu Feb 14 13:49:16 2002 From: meeting at ripe.net (RIPE NCC Meeting Registration) Date: Thu, 14 Feb 2002 13:49:16 +0100 Subject: Important information on coming RIPE Meeting Message-ID: <200202141249.g1ECnHO07437@birch.ripe.net> 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 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 and fax this to the hotel. If you prefer a stay in a different hotel, please fill in the form or 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 . With kind regards, Asha Raghoebarsing Meeting Coordinator ------- End of Forwarded Message From simon at limmat.switch.ch Mon Feb 18 11:05:23 2002 From: simon at limmat.switch.ch (Simon Leinen) Date: 18 Feb 2002 11:05:23 +0100 Subject: AW: RIPE-230 In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90268D382@CCGNT30> References: <39F27E3F569FD4119EF200508BAF85B90268D382@CCGNT30> Message-ID: >>>>> "kk" == Koepp, Karsten writes: >> 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. [...] As someone else noticed, this isn't true; some providers do filter out prefixes smaller (=longer) than the minimum RIR allocations. So make sure that you still announce the /20 so that people who don't carry the more-specifics can reach you. -- Simon Leinen simon at babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized. From ncc at ripe.net Tue Feb 19 17:03:54 2002 From: ncc at ripe.net (Mirjam Kuehne) Date: Tue, 19 Feb 2002 17:03:54 +0100 Subject: New Time Schedule for new IPv4 Policy Document Message-ID: <5.0.0.25.2.20020219170101.02d9ab98@localhost> 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 at ripe.net list by 1 March 2002 for the next revision period. Regards, Mirjam Kuehne RIPE NCC From stephenb at uk.uu.net Tue Feb 26 15:21:26 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 26 Feb 2002 14:21:26 -0000 Subject: AS number revokes Message-ID: <06e101c1bed0$dfd49310$2e04bf3e@eu.frd.uu.net> 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 From hank at att.net.il Tue Feb 26 19:47:19 2002 From: hank at att.net.il (Hank Nussbacher) Date: Tue, 26 Feb 2002 20:47:19 +0200 (IST) Subject: AS number revokes In-Reply-To: <06e101c1bed0$dfd49310$2e04bf3e@eu.frd.uu.net> Message-ID: On Tue, 26 Feb 2002, Stephen Burley wrote: We aggressively followup on ASN assignments and have returned already 10 ASNs over the past 2 years: http://www.isoc.org.il/ipolicy.html We give ASN holders two months to achieve multihoming but understand that problems do occur and always act leniently. But we find that many multihomers either go bankrupt, or can no longer afford the luxury of multihoming so they drop one line. When we catch them (we scan multiple IXs looking for the announcements), we give them an email warning, then a registered letter warning and only after *at least* 2 months (and usually around 4 months) do we revoke the ASN. In the case you specify below, I ask for faxed letters from their upstream providers proving the problems and a date by which they say the problems will be fixed. But we usually don't run into such problems anymore since the ASN requestor has to sign on to: http://www.isoc.org.il/ip-nets-rules.html and rule 6 states: Multihoming implies that you will be talking BGP to at least two other BGP peers and they will be announcing your block of IP nets with your ASN as the source of those nets. Note: the process of finding 2 ISPs to do BGP and to agree on a contract, as well as installing a Cisco router to handle BGP with large routing tables and to do the entire setup takes a while. If you have not started the process - you will not meet the 2 month deadline. It is therefore best to send in this application well after having started the process with the two ISPs and having installed the proper router. Perhaps it is time for everyone to be a bit more aggressive when handing out ASNs since it is a far more finite resource than IP address space. -Hank > 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 > Hank Nussbacher From stephenb at uk.uu.net Wed Feb 27 13:06:20 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 27 Feb 2002 12:06:20 -0000 Subject: AS number revokes References: Message-ID: <083801c1bf87$2ace7c30$2e04bf3e@eu.frd.uu.net> Thanks Hank but realy would like RIPE's policy on this any one in the NCC care to comment? > > 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 > > > > Hank Nussbacher > > From sabrina at ripe.net Wed Feb 27 18:25:31 2002 From: sabrina at ripe.net (Sabrina Wilmot) Date: Wed, 27 Feb 2002 18:25:31 +0100 Subject: AS number revokes In-Reply-To: Message from "Stephen Burley" of "Tue, 26 Feb 2002 14:21:26 GMT." <06e101c1bed0$dfd49310$2e04bf3e@eu.frd.uu.net> Message-ID: <200202271725.g1RHPmD10475@birch.ripe.net> Hi, "Stephen Burley" 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 at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o From stephenb at uk.uu.net Thu Feb 28 11:25:34 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 28 Feb 2002 10:25:34 -0000 Subject: AS number revokes References: <200202271725.g1RHPmD10475@birch.ripe.net> Message-ID: <0a0001c1c042$41856400$2e04bf3e@eu.frd.uu.net> Thankyou. Where is this documented? > Hi, > > "Stephen Burley" 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 at ripe.net | > | Registration Services Operations Manager | > | | > | RIPE NCC tel +31 20 535 4444 | > | www.ripe.net fax +31 20 535 4445 | > o------------------------------------------o > > From stephenb at uk.uu.net Thu Feb 28 13:11:57 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 28 Feb 2002 12:11:57 -0000 Subject: Do not remember this Message-ID: <0a4d01c1c051$1e23a120$2e04bf3e@eu.frd.uu.net> 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 at ripe.net' from your role object: From sabrina at ripe.net Thu Feb 28 14:51:38 2002 From: sabrina at ripe.net (Sabrina Wilmot) Date: Thu, 28 Feb 2002 14:51:38 +0100 Subject: AS number revokes In-Reply-To: Message from "Stephen Burley" of "Thu, 28 Feb 2002 10:25:34 GMT." <0a0001c1c042$41856400$2e04bf3e@eu.frd.uu.net> Message-ID: <200202281351.g1SDpsv03816@birch.ripe.net> "Stephen Burley" 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 , 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 at 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" 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 at ripe.net | * > | Registration Services Operations Manager | * > | | * > | RIPE NCC tel +31 20 535 4444 | * > | www.ripe.net fax +31 20 535 4445 | * > o------------------------------------------o * > * > * From katri at swip.net Thu Feb 28 16:06:04 2002 From: katri at swip.net (Katri) Date: Thu, 28 Feb 2002 16:06:04 +0100 Subject: Fwd: Do not remember this Message-ID: <5.1.0.14.0.20020228155344.00b63b20@pop.swip.net> Hello! I partly agree with Stephen. I actually didn?t find the notify to hm-dbm-msgs at 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 at swip.net SWIP-RIPE SWIPNET-LIR-MNT __________________________________________________________ >Delivered-To: lists-lir-wg-out at lists.ripe.net >From: "Stephen Burley" >To: >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 at 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 at ripe.net' from your role object: From stephenb at uk.uu.net Thu Feb 28 16:56:13 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 28 Feb 2002 15:56:13 -0000 Subject: AS number revokes References: <200202281351.g1SDpsv03816@birch.ripe.net> <20020228152840.K4497@magrat.titley.com> Message-ID: <0b6601c1c070$72b502a0$2e04bf3e@eu.frd.uu.net> ----- Original Message ----- From: "Nigel Titley" To: Cc: "Stephen Burley" ; Sent: Thursday, February 28, 2002 3:28 PM Subject: Re: AS number revokes > On Thu, Feb 28, 2002 at 02:51:38PM +0100, Sabrina Wilmot wrote: > > > > "Stephen Burley" 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 , it > > can then be re-assigned to another autonomous system by the RIPE NCC. > > [..] > > There is a considerable difference between "it can be returned" and "it must be returned". > > The former is what RIPE-185 says, the latter is what the RIPE NCC seems to be > applying. > > > > > > > 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. > > I grant this, but there is a difference between considering the return of > the AS (which we should all do as good netizens), and the RIPE NCC forcing > its return. Agreed this was what i was looking for in the documentation and it is not there. > > Or am I completely off base? > > Nigel > > > > > Regards, > > > > Sabrina Wilmot > > -- > > > > o------------------------------------------o > > | Sabrina Wilmot sabrina at 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" 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 at ripe.net | > > * > | Registration Services Operations Manager | > > * > | | > > * > | RIPE NCC tel +31 20 535 4444 | > > * > | www.ripe.net fax +31 20 535 4445 | > > * > o------------------------------------------o > > * > > > * > > > * > > > > > > > > -- From he at uninett.no Thu Feb 28 17:33:35 2002 From: he at uninett.no (Havard Eidnes) Date: Thu, 28 Feb 2002 17:33:35 +0100 (CET) Subject: AS number revokes In-Reply-To: <0b6601c1c070$72b502a0$2e04bf3e@eu.frd.uu.net> References: <200202281351.g1SDpsv03816@birch.ripe.net> <20020228152840.K4497@magrat.titley.com> <0b6601c1c070$72b502a0$2e04bf3e@eu.frd.uu.net> Message-ID: <20020228.173335.104791398.he@uninett.no> > > I grant this, but there is a difference between considering the > > return of the AS (which we should all do as good netizens), and > > the RIPE NCC forcing its return. > > Agreed this was what i was looking for in the documentation and it > is not there. Right. There's a difference between "can", "should" and "must". ...and... can we please trim down the responses so that needless cruft in the replies are not included? Regards, - H?vard From nigel at packetexchange.net Thu Feb 28 16:28:40 2002 From: nigel at packetexchange.net (Nigel Titley) Date: Thu, 28 Feb 2002 15:28:40 +0000 Subject: AS number revokes In-Reply-To: <200202281351.g1SDpsv03816@birch.ripe.net>; from sabrina@ripe.net on Thu, Feb 28, 2002 at 02:51:38PM +0100 References: <200202281351.g1SDpsv03816@birch.ripe.net> Message-ID: <20020228152840.K4497@magrat.titley.com> On Thu, Feb 28, 2002 at 02:51:38PM +0100, Sabrina Wilmot wrote: > > "Stephen Burley" 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 , it > can then be re-assigned to another autonomous system by the RIPE NCC. > [..] There is a considerable difference between "it can be returned" and "it must be returned". The former is what RIPE-185 says, the latter is what the RIPE NCC seems to be applying. > > > 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. I grant this, but there is a difference between considering the return of the AS (which we should all do as good netizens), and the RIPE NCC forcing its return. Or am I completely off base? Nigel > > Regards, > > Sabrina Wilmot > -- > > o------------------------------------------o > | Sabrina Wilmot sabrina at 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" 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 at ripe.net | > * > | Registration Services Operations Manager | > * > | | > * > | RIPE NCC tel +31 20 535 4444 | > * > | www.ripe.net fax +31 20 535 4445 | > * > o------------------------------------------o > * > > * > > * > > > --