From adrian.pauling at bt.com Tue Aug 1 11:50:57 2000 From: adrian.pauling at bt.com (adrian.pauling at bt.com) Date: Tue, 1 Aug 2000 10:50:57 +0100 Subject: X-NCC RegID: UK.BTENT - Enterprise Registry Address Assignment Po licy Message-ID: <27EDC2145E42D211AD9600606DD5EC1D086F847A@mbrpb1nt02.mww.bt.com> Dear Hostmasters / LIRwg, I seek clarification on policy with respect to Enterprise Registry assignments, and have two fundamental areas for debate. Area 1: Enterprise vs. ISP LIR Assignment for non-ISP LIR Revenue Generation As an Enterprise Registry, should we be assigning IP addresses to Web Server Farms, which are part of the owning Corporate but not part of the ISP operation (ISP LIR, not the associated Enterprise LIR) ? At the IP level, web hosting server farm group are not revenue generating for the ISP operation, and they do not resell IP services as they only host web pages. They are revenue generating for the Corporate though. I believe they're paying commercial public rates to the ISP operation for their Internet connection. Initially the ISP LIR rejected an assignment request as the web hosting operation seems to be from the Corporate. Hence, they're requesting an assignment from the Enterprise LIR. The reverseDNS for the Enterprise is operated independently of the ISP operation. Should an Enterprise Registry assign the addresses? Area 2: Enterprise vs. ISP LIR Assignments for Corporate Pilots and Trials As the Enterprise LIR, we are often asked to assign addresses for pilots & trials of new technologies from teams within the Corporate Group. Such pilots and trials often become commercial revenue generating upon successful completion. At this stage the Enterprise address space ends up on a commercial service. Should the commercial service re-address upon successful completion ( causing operational costs and product launch difficulties ) using assignments from the ISP LIR? Do we transfer IP assignments from Enterprise LIR to ISP LIR registries? Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling at bt.com * +44 19 2685 1992 / +44 78 0290 4877 British Telecommunications plc Registered Office 81 Newgate Street London EC1A 7AJ Registered in England no 1800000 From Alessandro.Pelosi at swisscom-italy.com Tue Aug 1 16:23:24 2000 From: Alessandro.Pelosi at swisscom-italy.com (Alessandro.Pelosi at swisscom-italy.com) Date: Tue, 1 Aug 2000 16:23:24 +0200 Subject: R: X-NCC RegID: UK.BTENT - Enterprise Registry Address Assignment Po licy Message-ID: Dear Sirs, According to me It is better to assign to any company asking a space in your server farm a little pool of addresses, this because it happend that spam complaints or such stuff arrived to the hostmaster of the server farm instead to the owner of the server. On second hand, if we behave like this, there's always the possibility to know who is the user of these addresses consulting the RIPE database. Alessandro Pelosi Swisscom Spa -----Messaggio originale----- Da: adrian.pauling at bt.com [mailto:adrian.pauling at bt.com] Inviato: marted? 1 agosto 2000 11.51 A: hostmaster at ripe.net; lir-wg at ripe.net Cc: kevin.bates at bt.com; mark.glover at bt.com Oggetto: X-NCC RegID: UK.BTENT - Enterprise Registry Address Assignment Po licy Dear Hostmasters / LIRwg, I seek clarification on policy with respect to Enterprise Registry assignments, and have two fundamental areas for debate. Area 1: Enterprise vs. ISP LIR Assignment for non-ISP LIR Revenue Generation As an Enterprise Registry, should we be assigning IP addresses to Web Server Farms, which are part of the owning Corporate but not part of the ISP operation (ISP LIR, not the associated Enterprise LIR) ? At the IP level, web hosting server farm group are not revenue generating for the ISP operation, and they do not resell IP services as they only host web pages. They are revenue generating for the Corporate though. I believe they're paying commercial public rates to the ISP operation for their Internet connection. Initially the ISP LIR rejected an assignment request as the web hosting operation seems to be from the Corporate. Hence, they're requesting an assignment from the Enterprise LIR. The reverseDNS for the Enterprise is operated independently of the ISP operation. Should an Enterprise Registry assign the addresses? Area 2: Enterprise vs. ISP LIR Assignments for Corporate Pilots and Trials As the Enterprise LIR, we are often asked to assign addresses for pilots & trials of new technologies from teams within the Corporate Group. Such pilots and trials often become commercial revenue generating upon successful completion. At this stage the Enterprise address space ends up on a commercial service. Should the commercial service re-address upon successful completion ( causing operational costs and product launch difficulties ) using assignments from the ISP LIR? Do we transfer IP assignments from Enterprise LIR to ISP LIR registries? Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling at bt.com * +44 19 2685 1992 / +44 78 0290 4877 British Telecommunications plc Registered Office 81 Newgate Street London EC1A 7AJ Registered in England no 1800000 From ncc at ripe.net Mon Aug 7 16:09:36 2000 From: ncc at ripe.net (RIPE NCC Staff) Date: Mon, 07 Aug 2000 16:09:36 +0200 Subject: Call for Nominations - ASO Address Council Message-ID: <200008071409.QAA11257@birch.ripe.net> Call for Nominations for Representatives to the ASO Address Council - RIPE NCC Region Dear colleagues, This is a call for nominations of individuals from the RIPE NCC region to serve on the ASO Address Council. During November 2000, one RIPE NCC 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 processes. If you are interested in nominating an individual, or if you are interested in being nominated as a member of the Address Council, 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 (the first of which was held in Budapest in May 2000) 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. The terms of appointment of the current initial AC members were staggered terms of 1, 2 and 3 years to allow one third of the Address Council to be replaced in each subsequent year. 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 Sabine Jaume who has served as an initial AC member for the past year has expired. One individual from the RIPE NCC 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 any staff member of any Regional Internet Registry. Self-nominations are permitted. Nominations should be sent by email to , by midnight CET on 30 September 2000. The information included with the nomination is to be 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, then 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 selection of the nominee to serve on the Address Council will involve an open election. Due to the 90 day lead time needed for a call for nominations prior to a RIPE NCC region policy meeting, the selection process will not be held at the RIPE 37 meeting, 12-15 September 2000, in Amsterdam. Two selection processes have been proposed. The first follows the voting process outlined in the MoU. The selection procedure would take place at the RIPE 38 meeting in January 2001 in Amsterdam. The second process currently being discussed involves implementing an electronic voting procedure as it would allow for more participation in the selection process and could bring the process forward. This procedure would be discussed prior to the RIPE 37 meeting and announced in the LIR-WG meeting. Hans Petter Holen, LIR-WG Chair, will initiate discussions about this procedure on the lir-wg mailing list. Important Dates: 30 September 2000 - deadline for Address Council nominations Regards, Hans Petter Holen From willy at lighthouseservers.com Tue Aug 8 17:32:34 2000 From: willy at lighthouseservers.com (Willy Calderon) Date: Tue, 8 Aug 2000 16:32:34 +0100 (BST) Subject: delays Message-ID: Has anyone else noticed any delays with RIPE's working wait queue? Anything out of the ordinary, that is. I've sent hostmaster at ripe.net a query on 10th July and have yet to get an initial response from them despite their claims that response times was up to two weeks. I've followed up on this initial query, but to no avail. ---- Willy Calderon Provisioning Group LighthouseServers +44(0)117 908 2463 From joao at ripe.net Tue Aug 8 17:59:31 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 8 Aug 2000 17:59:31 +0200 Subject: delays In-Reply-To: References: Message-ID: Hello, I don't currently see any unopened tickets older than 26th of July. Could you provide a ticket number so that we can investigate the matter further? Joao Damas Head of External Services RIPE NCC At 16:32 +0100 8/8/00, Willy Calderon wrote: >Has anyone else noticed any delays with RIPE's working wait queue? >Anything out of the ordinary, that is. I've sent hostmaster at ripe.net a >query on 10th July and have yet to get an initial response from them >despite their claims that response times was up to two weeks. > >I've followed up on this initial query, but to no avail. > >---- >Willy Calderon >Provisioning Group >LighthouseServers >+44(0)117 908 2463 From ed at decaen.com Tue Aug 8 18:33:06 2000 From: ed at decaen.com (Emmanuel DECAEN) Date: Tue, 8 Aug 2000 18:33:06 +0200 Subject: delays In-Reply-To: Message-ID: <000901c00156$54fa9f20$0a01a8c0@dynetcom.fr> Willy, I've noticed, that there is a 12 day delay for a NEW LIR creation. This delay is fine for me. For example: http://www.ripe.net/cgi-bin/rttquery?ticnum=NCC%232000073875&.submit=Submit+ Query -- Emmanuel DECAEN > -----Message d'origine----- > De: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]De la part de > Willy Calderon > Date: mardi 8 ao?t 2000 17:33 > ?: lir-wg at ripe.net > Objet: delays > > > Has anyone else noticed any delays with RIPE's working wait queue? > Anything out of the ordinary, that is. I've sent hostmaster at ripe.net a > query on 10th July and have yet to get an initial response from them > despite their claims that response times was up to two weeks. > > I've followed up on this initial query, but to no avail. > > ---- > Willy Calderon > Provisioning Group > LighthouseServers > +44(0)117 908 2463 > > From mally at energis-squared.com Tue Aug 8 18:03:19 2000 From: mally at energis-squared.com (Mally Mclane) Date: Tue, 8 Aug 2000 17:03:19 +0100 Subject: delays Message-ID: <6BF1C330AF53D311BE5D00508B09081004C333D4@PLANET01> Joao, I cannot recall my ticket number, but I sent in a query about the RIPE email system and never got a reply. I 've just got back from Mexico for 2 weeks, so that was before the 26th. regards, mally mclane =>senior hostmaster =>for Energis Squared, Leeds, UK =>mally at energis-squared.com <> www.energis-squared.com =>t: +44(0)1132076624 <> m: +44(0)7787100695 > -----Original Message----- > From: Joao Luis Silva Damas [mailto:joao at ripe.net] > Sent: Tuesday, August 08, 2000 5:00 PM > To: Willy Calderon; lir-wg at ripe.net > Subject: Re: delays > > > Hello, > > I don't currently see any unopened tickets older than 26th of July. > > Could you provide a ticket number so that we can investigate the > matter further? > > Joao Damas > Head of External Services > RIPE NCC > > At 16:32 +0100 8/8/00, Willy Calderon wrote: > >Has anyone else noticed any delays with RIPE's working wait queue? > >Anything out of the ordinary, that is. I've sent > hostmaster at ripe.net a > >query on 10th July and have yet to get an initial response from them > >despite their claims that response times was up to two weeks. > > > >I've followed up on this initial query, but to no avail. > > > >---- > >Willy Calderon > >Provisioning Group > >LighthouseServers > >+44(0)117 908 2463 > From hank at att.net.il Wed Aug 9 11:17:11 2000 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 09 Aug 2000 11:17:11 +0200 Subject: RIPE-160 Message-ID: <4.3.2.7.2.20000809111146.00b0d100@max.ibm.net.il> 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 From joao at ripe.net Wed Aug 9 10:57:10 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 9 Aug 2000 10:57:10 +0200 Subject: delays In-Reply-To: <6BF1C330AF53D311BE5D00508B09081004C333D4@PLANET01> References: <6BF1C330AF53D311BE5D00508B09081004C333D4@PLANET01> Message-ID: To Willy Calderon: We have not received any requests from the registry you are registered with during 2000. Please give us some more information. When and where to did you send your request? Off the list if you want. to Mally Mclane: I believe your issue has been answered by a hostmaster. I wish you the best of lucks with MS Exchange. Joao From hank at att.net.il Wed Aug 9 12:27:04 2000 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 09 Aug 2000 12:27:04 +0200 Subject: Fwd: Re: RIPE-160 Message-ID: <4.3.2.7.2.20000809122354.00abedf0@max.ibm.net.il> I wonder what others feel about this. Such an important prinicipal should be in the RIPE-173; do others feel the same? -Hank > > >It's in RIPE-185: > > > > > > > > > > > >Confidentiality > > > > > > Information collected by a registry in the registration process must > be kept > > > in strict confidence. It is to be used for registration purposes only. > > > It must > > > be transmitted only to higher level registries and/or IANA upon request, > > > but will not be transmitted to any other party unless explicitly > requested > > > in writing by the end user. > > > > Thanks, but that applies more to LIRs than to RIPE. It should be in > > RIPE-160 explicited stated. > >I took it to apply to Registries, whether they be LIRs or RIRs (or the PIR). > >If you feel it should be more clear please feel free to ask for the document >phrasing to be changed on the list. > >Regards, > >-- >leo vegoda >RIPE NCC From willy at lighthouseservers.com Wed Aug 9 12:17:19 2000 From: willy at lighthouseservers.com (Willy Calderon) Date: Wed, 9 Aug 2000 11:17:19 +0100 (BST) Subject: delays In-Reply-To: <013a01c001ea$dbfc6460$b702cfc2@redlands.uk1.vbc.net> Message-ID: > To Willy Calderon: > > We have not received any requests from the registry you are > registered with during 2000. Please give us some more information. > When and where to did you send your request? Off the list if you want. We sent RIPE(hostmaster at ripe.net) an application on July 10 at 16:58. To expedite this what should we do, send it again? From joao at ripe.net Wed Aug 9 12:34:43 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 9 Aug 2000 12:34:43 +0200 Subject: delays In-Reply-To: References: Message-ID: Did you get a ticket number? Could you give it to us? We can't see any ticket from you with that date? May be it's better to continue this off the list, so as not to bother everyone else? Joao At 11:17 +0100 9/8/00, Willy Calderon wrote: > > To Willy Calderon: >> >> We have not received any requests from the registry you are >> registered with during 2000. Please give us some more information. >> When and where to did you send your request? Off the list if you want. > > >We sent RIPE(hostmaster at ripe.net) an application on July 10 at 16:58. To >expedite this what should we do, send it again? From hank at att.net.il Wed Aug 9 13:42:38 2000 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 09 Aug 2000 13:42:38 +0200 Subject: delays In-Reply-To: References: <013a01c001ea$dbfc6460$b702cfc2@redlands.uk1.vbc.net> Message-ID: <4.3.2.7.2.20000809134119.00ab5950@max.ibm.net.il> At 11:17 09/08/00 +0100, Willy Calderon wrote: To be a new LIR you send the form to: new-lir at ripe.net Once you have a regid, you need to include that in all emails to hostmaster so your email doesn't enter the "slow" queue as yours appears to have. Read the docs. -Hank > > To Willy Calderon: > > > > We have not received any requests from the registry you are > > registered with during 2000. Please give us some more information. > > When and where to did you send your request? Off the list if you want. > > >We sent RIPE(hostmaster at ripe.net) an application on July 10 at 16:58. To >expedite this what should we do, send it again? From skals at cybercity.dk Wed Aug 9 13:28:00 2000 From: skals at cybercity.dk (Simon Skals) Date: Wed, 09 Aug 2000 13:28:00 +0200 Subject: delays In-Reply-To: <4.3.2.7.2.20000809134119.00ab5950@max.ibm.net.il> References: <013a01c001ea$dbfc6460$b702cfc2@redlands.uk1.vbc.net> Message-ID: <4.3.2.20000809132723.00f35c30@www4.cybercity.dk> It seems Hank Nussbacher wrote: >Read the docs. Agreed. Let's keep individual user support out of this forum. Cheers, -- Simon Skals From woeber at cc.univie.ac.at Wed Aug 9 17:22:30 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 09 Aug 2000 17:22:30 MET-DST Subject: Fwd: Re: RIPE-160 Message-ID: <009EE5AE.DCAE5A50.9@cc.univie.ac.at> >Subject: Fwd: Re: RIPE-160 > >I wonder what others feel about this. Such an important prinicipal should >be in the RIPE-173; do others feel the same? > >-Hank A couple of observations... Hank, I guess you do have a particular suggestion? If yes, please put it forward for discussion. Or do you really intend to start a discussion about feelings :-? Some of the stuff in the excerpt as attached below might benefit from a more precise definition: - when we talk about registry business, we're talking Local-IRs and the RIPE _NCC_. - "RIPE" is the term used for referring to the loosely defined european region's "internet constituency". RIPE does not in itself or directly deal with registry transactions, but it does have influence on the definition of address distribution _policiy_. - what is the meaning of "PIR"? > > >It's in RIPE-185: > > > > > > > > > > > >Confidentiality > > > > > > Information collected by a registry in the registration process must > be kept > > > in strict confidence. It is to be used for registration purposes only. > > > It must > > > be transmitted only to higher level registries and/or IANA upon request, > > > but will not be transmitted to any other party unless explicitly > requested > > > in writing by the end user. > > > > Thanks, but that applies more to LIRs than to RIPE. It should be in > > RIPE-160 explicited stated. > >I took it to apply to Registries, whether they be LIRs or RIRs (or the PIR). > >If you feel it should be more clear please feel free to ask for the document >phrasing to be changed on the list. > >Regards, > >-- >leo vegoda >RIPE NCC Best regards, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From woeber at cc.univie.ac.at Wed Aug 9 18:01:23 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 09 Aug 2000 18:01:23 MET-DST Subject: Fwd: Re: RIPE-160 Message-ID: <009EE5B4.4B041A80.17@cc.univie.ac.at> => - what is the meaning of "PIR"? = =I used that TLA to refer to Planetary IR. Ahhhh :-) -WW From leo at ripe.net Wed Aug 9 17:43:52 2000 From: leo at ripe.net (leo vegoda) Date: Wed, 9 Aug 2000 17:43:52 +0200 Subject: Fwd: Re: RIPE-160 In-Reply-To: <009EE5AE.DCAE5A50.9@cc.univie.ac.at>; from Wilfried Woeber, UniVie/ACOnet on Wed, Aug 09, 2000 at 05:22:30PM +0000 References: <009EE5AE.DCAE5A50.9@cc.univie.ac.at> Message-ID: <20000809174352.J104@ripe.net> On Wed, Aug 09, 2000 at 05:22:30PM +0000, in message <009EE5AE.DCAE5A50.9 at cc.univie.ac.at>, Wilfried Woeber, UniVie/ACOnet (woeber at cc.univie.ac.at) wrote: Re: RE: Fwd: Re: RIPE-160 [...] > - what is the meaning of "PIR"? I used that TLA to refer to Planetary IR. Best regards, -- leo vegoda RIPE NCC From axel.pawlik at ripe.net Mon Aug 14 14:47:23 2000 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Mon, 14 Aug 2000 14:47:23 +0200 Subject: RIPE-160 In-Reply-To: <4.3.2.7.2.20000809111146.00b0d100@max.ibm.net.il> Message-ID: <4.3.2.7.2.20000814143628.055d8e60@localhost> At 11:17 00/08/09, Hank Nussbacher wrote: >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? Dear Hank, indeed, after having reviewed a number of documents involved, I agree that a broad confidentiality statement should be included in the Terms & Conditions, RIPE-173, to warrant higher visibility. Confidentiality is mentioned in RIPE-185, http://www/ripe/docs/ripe-185.html#toc69, though, which is part of the Standard Service Agreement. Thank you for pointing this out. cheers, Axel From herbert at hostit.be Mon Aug 14 17:44:41 2000 From: herbert at hostit.be (Herbert Baerten) Date: Mon, 14 Aug 2000 17:44:41 +0200 Subject: New AS request in another country Message-ID: 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 From hph at online.no Tue Aug 15 00:11:47 2000 From: hph at online.no (Hans Petter Holen) Date: Tue, 15 Aug 2000 00:11:47 +0200 Subject: New AS request in another country References: Message-ID: <000c01c0063c$a9e90900$e7a6fea9@hph> > 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. You can apply for AS numbers as long as you meet the criteria set for this. As far as I remember the networks need to have distinct routing policies and be multihomet with more than two networks for this to be necessary. > Can LIR xx.foo request a new allocation and a new ASN for use by the new > daughter? Yes. > 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 ? As far as I can see the only reason you would want to do this would be if you require yy.foo to operate its own address registry. And even then you may not need to do that. -hph From ryan at on-line-finance.net Mon Aug 14 17:48:36 2000 From: ryan at on-line-finance.net (Ryan O`Connell) Date: Mon, 14 Aug 2000 16:48:36 +0100 (BST) Subject: New AS request in another country In-Reply-To: Message-ID: On 14-Aug-2000 Herbert Baerten wrote: > 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 ? A new AS number can be requested by anyone (via any LIR) for any use where there is a seperate routing policy. So, as long as yy.foo has a different rouing policy to xx.foo, it is eligable for another AS number via the original LIR. -- Ryan O'Connell - On:Line Finance IT Department - NOC/Support Voice Line: +44 1932 235320 How do you sleep? How do you last the night and keep the dogs at bay? How do you feel when you close your eyes, and try and drift away? Does it feel any better now? Does it mean anymore When the angel of death comes knock, knocking, And banging at your door? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From joao at ripe.net Tue Aug 15 11:01:42 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 15 Aug 2000 11:01:42 +0200 Subject: New AS request in another country In-Reply-To: References: Message-ID: Hello, I would just like to stress the fact that the crucial point in requesting an AS is the existence of a routing policy comprising a set of prefixes and not the administrative side of things. Section 5 of rfc1930 and section 7 of ripe185 are good references to decide when to request an AS number. The RIPE NCC issues AS numbers to LIRs that need them according to the above documents. Joao Damas Head of External Services RIPE NCC At 17:44 +0200 14/8/00, Herbert Baerten wrote: >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 From andrius at andrius.org Tue Aug 15 15:24:09 2000 From: andrius at andrius.org (Andrius Kasparavicius) Date: Tue, 15 Aug 2000 11:24:09 -0200 (GMT+2) Subject: New AS request in another country In-Reply-To: Message-ID: On Tue, 15 Aug 2000, Joao Luis Silva Damas wrote: > The RIPE NCC issues AS numbers to LIRs that need them according to > the above documents. is there any ASN assingment cost? ------------------------- Kasparavicius Andrius ________________________________________________________________________ http://www.andrius.org ICQ:17701001 tel.: +370 87 25630 nick: Casper AND-RIPE AND-6BONE From joao at ripe.net Tue Aug 15 11:40:16 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 15 Aug 2000 11:40:16 +0200 Subject: New AS request in another country In-Reply-To: References: Message-ID: Assignement of ASNs is part of the membership services of the RIPE NCC. Members pay an annual membership fee. There is no additional cost for ASNs requests or any other type of membership services. Joao At 11:24 -0200 15/8/00, Andrius Kasparavicius wrote: >On Tue, 15 Aug 2000, Joao Luis Silva Damas wrote: > >> The RIPE NCC issues AS numbers to LIRs that need them according to >> the above documents. > > is there any ASN assingment cost? > > ------------------------- > Kasparavicius Andrius >________________________________________________________________________ >http://www.andrius.org ICQ:17701001 tel.: +370 87 25630 nick: Casper >AND-RIPE AND-6BONE From joao at ripe.net Tue Aug 15 11:51:02 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 15 Aug 2000 11:51:02 +0200 Subject: New AS request in another country Message-ID: 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 From herbert at hostit.be Wed Aug 16 09:37:39 2000 From: herbert at hostit.be (Herbert Baerten) Date: Wed, 16 Aug 2000 09:37:39 +0200 Subject: New AS request in another country In-Reply-To: Message-ID: > > 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. So, if the new company does not yet have any address space, it can request its ASN via an existing LIR... but if the new AS wants to announce anything, it will either - have to start up its own LIR (which includes getting a /20 allocation), or - have to request a /20 or larger assignment from an existing LIR, in order to get an 'announcable' prefix, right (i.e. one that will not be filtered out anywhere)? kind regards, Herbert -- Herbert Baerten HB5351 HostIT Network Manager NCC9166-RIPE From rd at mediascape.de Wed Aug 16 09:39:54 2000 From: rd at mediascape.de (Robert Depenbrock) Date: Wed, 16 Aug 2000 09:39:54 +0200 Subject: New AS request in another country In-Reply-To: ; from Herbert Baerten on Wed, Aug 16, 2000 at 09:37:39AM +0200 References: Message-ID: <20000816093954.A22261@heartofgold.mediascape.de> On Wed, Aug 16, 2000 at 09:37:39AM +0200, Herbert Baerten wrote: Hi ! > - have to request a /20 or larger assignment from an existing LIR, > in order to get an 'announcable' prefix, right (i.e. one that will not be > filtered out anywhere)? > Some older LIR?s out there have PA assignments in PI space (194,193,192). They can assign that customer also smaller prefixes. regards Robert Depenbrock -- Sen. Network Engineer - "Jeder Tag ist ein LinuxTag" mediascape communications AG Weidestrasse 122a - 22083 Hamburg - Germany email : rd at mediascape.de (RD-RIPE) From beri at EU.net Wed Aug 16 09:49:51 2000 From: beri at EU.net (Berislav Todorovic) Date: Wed, 16 Aug 2000 09:49:51 +0200 (CEST) Subject: New AS request in another country In-Reply-To: Message-ID: On Wed, 16 Aug 2000, Herbert Baerten wrote: >> - have to start up its own LIR (which includes getting a /20 allocation), And some additional money, of course ... >> - have to request a /20 or larger assignment from an existing LIR, >> in order to get an 'announcable' prefix, right (i.e. one that will not be >> filtered out anywhere)? Well, not the "assignment", becuase the assignment can't have subassignments. 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. From AS Y they will announce 172.16.240/20 and everything will be fine. Of course, everything would be much more elegant if RIPE NCC finally implemented the additional SUB-ALLOCATED PA/PI status attribute, that was proposed by James Aldridge long ago, adopted by the LIR working group and passed to the DB WG for implementation. With such a scheme the LIR xx.foo would simply make a sub-allocation of 172.16.240/20, register it normally in the RIPE Database, give it SUB-ALLOCATED PA status, so the whole picture would look more proper and clean. Regards, Beri -- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5457; Fax: (+3120) 622-4657 - --- Email: beri at EU.net; Mobile: (+31651) 333-641 From herbert at hostit.be Wed Aug 16 10:23:13 2000 From: herbert at hostit.be (Herbert Baerten) Date: Wed, 16 Aug 2000 10:23:13 +0200 Subject: New AS request in another country In-Reply-To: Message-ID: > 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 I see your point in general, however in our particular case xx.foo only has 1 allocation, a /19. In theory it could split that and announce one /20 from one AS and the other /20 from its new AS. But then the LIR gets in trouble when one of the /20s fills up much faster than the other... it won't get a new allocation to use for the filled-up AS since its original /19 allocation is not yet full? So even in general, it seems risky to me to have a LIR splitting its open allocation between different ASs? Herbert From neil at COLT.NET Wed Aug 16 10:21:00 2000 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 16 Aug 2000 09:21:00 +0100 (BST) Subject: New AS request in another country In-Reply-To: from Herbert Baerten at "Aug 16, 2000 10:23:13 am" Message-ID: <200008160821.JAA05246@NetBSD.noc.COLT.NET> > I see your point in general, however in our particular case xx.foo only has > 1 allocation, a /19. In theory it could split that and announce one /20 from > one AS and the other /20 from its new AS. > But then the LIR gets in trouble when one of the /20s fills up much faster > than the other... it won't get a new allocation to use for the filled-up AS > since its original /19 allocation is not yet full? This is exactly why we have a registery in each country. > So even in general, it seems risky to me to have a LIR splitting its open > allocation between different ASs? I'd say so. Regards, Neil. From joao at ripe.net Wed Aug 16 12:23:40 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 16 Aug 2000 12:23:40 +0200 Subject: New AS request in another country In-Reply-To: References: Message-ID: Hello, At 9:49 +0200 16/8/00, Berislav Todorovic wrote: >On Wed, 16 Aug 2000, Herbert Baerten wrote: > > >Of course, everything would be much more elegant if RIPE NCC finally >implemented the additional SUB-ALLOCATED PA/PI status attribute, that was >proposed by James Aldridge long ago, adopted by the LIR working group and >passed to the DB WG for implementation. With such a scheme the LIR xx.foo >would simply make a sub-allocation of 172.16.240/20, register it normally >in the RIPE Database, give it SUB-ALLOCATED PA status, so the whole >picture would look more proper and clean. I've been trying to find the consensus your paragraph above describes by looking in the list archives and the minutes of the two working groups and I have failed so far. I've seen a proposal from James Aldridge from January this year, but failed to see responses to it or to see any mention of it in the db-wg or any word of its adoption. If we have missed the conclusion of this discussion, please point me to where I can find this. regards, Joao Damas RIPE NCC >Regards, >Beri > >-- >----- ___ Berislav Todorovic, Network Engineer >---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) >--- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL >-- /___ /___// //___ /_ ---- Phone: (+3120) 530-5457; Fax: (+3120) 622-4657 >- --- Email: beri at EU.net; Mobile: (+31651) 333-641 From kmk at saunalahti.fi Wed Aug 16 12:29:10 2000 From: kmk at saunalahti.fi (=?ISO-8859-1?Q?Kai_Kein=E4nen?=) Date: Wed, 16 Aug 2000 13:29:10 +0300 (EET DST) Subject: New AS request in another country In-Reply-To: <200008160841.LAA01347@telakka.saunalahti.fi> Message-ID: 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 at 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 From beri at EU.net Wed Aug 16 12:39:42 2000 From: beri at EU.net (Berislav Todorovic) Date: Wed, 16 Aug 2000 12:39:42 +0200 (CEST) Subject: New AS request in another country In-Reply-To: Message-ID: On Wed, 16 Aug 2000, Joao Luis Silva Damas wrote: >> >implemented the additional SUB-ALLOCATED PA/PI status attribute, >> >> I've been trying to find the consensus your paragraph above describes >> by looking in the list archives and the minutes of the two working >> groups and I have failed so far. I've seen a proposal from James >> Aldridge from January this year, but failed to see responses to it or >> to see any mention of it in the db-wg or any word of its adoption. James, can you, please, give more light on this issue? Regards, Beri -- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5457; Fax: (+3120) 622-4657 - --- Email: beri at EU.net; Mobile: (+31651) 333-641 From stephenb at uk.uu.net Wed Aug 16 16:08:50 2000 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 16 Aug 2000 14:08:50 +0000 Subject: New AS request in another country References: Message-ID: <399AA072.A4FDA7B1@uk.uu.net> > (The alternative would be to change policies to allow a LIR to have > several open allocations when the open allocations would be under Or as we have done and i am sure others have too open a differant LIR for each seperate block that is large enough to warrant its own routing policy. Remember the minimum allocation for an LIR now is a /20. Regards, -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------ From hank at att.net.il Thu Aug 17 08:24:47 2000 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 17 Aug 2000 08:24:47 +0200 Subject: RIPE-160 In-Reply-To: <4.3.2.7.2.20000814143628.055d8e60@localhost> References: <4.3.2.7.2.20000809111146.00b0d100@max.ibm.net.il> Message-ID: <4.3.2.7.2.20000817082437.00b15aa0@max.ibm.net.il> At 14:47 14/08/00 +0200, Axel Pawlik wrote: Thanks!! -Hank >At 11:17 00/08/09, Hank Nussbacher wrote: >>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? > >Dear Hank, > >indeed, after having reviewed a number of documents involved, >I agree that a broad confidentiality statement should be >included in the Terms & Conditions, RIPE-173, to warrant >higher visibility. > >Confidentiality is mentioned in RIPE-185, >http://www/ripe/docs/ripe-185.html#toc69, though, which is >part of the Standard Service Agreement. > >Thank you for pointing this out. > >cheers, Axel From afrench at via-net-works.com Thu Aug 17 12:17:57 2000 From: afrench at via-net-works.com (Alex French) Date: Thu, 17 Aug 2000 11:17:57 +0100 Subject: ccTLD data moving from RIPE db Message-ID: <4.3.2.7.0.20000817111440.00b49360@212.169.63.1> 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, From woeber at cc.univie.ac.at Thu Aug 17 14:54:10 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 17 Aug 2000 14:54:10 MET-DST Subject: ccTLD data moving from RIPE db Message-ID: <009EEBE3.76BD8000.12@cc.univie.ac.at> [ editorial: I think this should move from lir-wg at ripe.net to db-wg at 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 at 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 From afrench at via-net-works.com Thu Aug 17 15:13:28 2000 From: afrench at via-net-works.com (Alex French) Date: Thu, 17 Aug 2000 14:13:28 +0100 Subject: ccTLD data moving from RIPE db In-Reply-To: <6BF1C330AF53D311BE5D00508B09081004C339F7@PLANET01> Message-ID: <4.3.2.7.0.20000817141041.00b15390@212.169.63.1> At 13:39 17/08/00, Mally Mclane wrote: > > 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. The DPA does *not* prevent this. That's the official story promulgated by the IEDR, and is widely accepted as complete tripe by the Irish Internet community. To start with, the DPA refers only to individuals, while most .ie domains are held by companies. Further, the DPA does not prevent *authorized* disclosure. The IEDR would simply have to make disclosure of this data a condition of registration, and allow an "opt out". Thirdly, the IEDR give out this information freely by email. Thanks, Alex. Alex French Consultant, Technical Services E: afrench at via-net-works.com VIA NET.WORKS, Inc. T: +353 86 818 8118 From mally at energis-squared.com Thu Aug 17 14:39:54 2000 From: mally at energis-squared.com (Mally Mclane) Date: Thu, 17 Aug 2000 13:39:54 +0100 Subject: ccTLD data moving from RIPE db Message-ID: <6BF1C330AF53D311BE5D00508B09081004C339F7@PLANET01> > 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 at energis-squared.com <> www.energis-squared.com =>t: +44(0)1132076624 <> m: +44(0)7787100695 From joshua at roughtrade.net Fri Aug 18 20:54:42 2000 From: joshua at roughtrade.net (Joshua Goodall) Date: Fri, 18 Aug 2000 20:54:42 +0200 (CEST) Subject: lame delegations In-Reply-To: Message-ID: (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 at interxion.com ]--------------- joshua at 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 at 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." > > From joshua at roughtrade.net Fri Aug 18 21:26:37 2000 From: joshua at roughtrade.net (Joshua Goodall) Date: Fri, 18 Aug 2000 21:26:37 +0200 (CEST) Subject: lame delegations In-Reply-To: <200008181856.OAA10267@Iodine.Mlink.NET> Message-ID: On Fri, 18 Aug 2000, Phillip Vandry wrote: > Why not this? > > Registrars only accept to create a glue record if there already exists > a PTR entry for the requested address that points to the right name. > > -Phil off the top of my head, I'd say a) DNS is very spoofable b) there's a catch-22; for sensible management, most LIR's create reverse delegations at RIPE using the FQHN of their nameservers. Without the host-record glue already in place, resolvers won't be able to find that PTR record. c) not everyone wants the reverse to match the forward (is this an RFC violation? I hope not :)). d) this doesn't help the original problem where outdated glue blocks the creation of correct glue. J From andrius at andrius.org Sat Aug 19 22:31:17 2000 From: andrius at andrius.org (Andrius Kasparavicius) Date: Sat, 19 Aug 2000 18:31:17 -0200 (GMT+2) Subject: IP addresses Message-ID: 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 From vandry at Mlink.NET Fri Aug 18 20:56:25 2000 From: vandry at Mlink.NET (Phillip Vandry) Date: Fri, 18 Aug 2000 14:56:25 -0400 (EDT) Subject: lame delegations In-Reply-To: Your message of "Fri, 18 Aug 2000 20:54:42 EDT." Message-ID: <200008181856.OAA10267@Iodine.Mlink.NET> Why not this? Registrars only accept to create a glue record if there already exists a PTR entry for the requested address that points to the right name. -Phil > 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. From dredd at megacity.org Fri Aug 18 21:12:17 2000 From: dredd at megacity.org (Derek J. Balling) Date: Fri, 18 Aug 2000 12:12:17 -0700 Subject: lame delegations In-Reply-To: <200008181856.OAA10267@Iodine.Mlink.NET> References: <200008181856.OAA10267@Iodine.Mlink.NET> Message-ID: that's great at creation time, but what about when Customer-A leaves ISP-A to go to ISP-B, but doesn't bring his host records along with him? ISP-A needs the ability to say "Attention $REGISTRAR, $HOSTNAME is no longer valid, as evidenced by the current lack of a PTR record. Please remove it". The lack of a PTR record covers the case where PTR and host-record may not match so someone impersonates ISP-A asking the host name be destroyed. The PTR record has to completely not exist. Of course, this is a great idea, but can we actually get it implemented by the relevant agencies? ;-) D At 2:56 PM -0400 8/18/00, Phillip Vandry wrote: >Why not this? > >Registrars only accept to create a glue record if there already exists >a PTR entry for the requested address that points to the right name. > >-Phil > >> 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. From vandry at TZoNE.ORG Fri Aug 18 21:17:14 2000 From: vandry at TZoNE.ORG (Phillip Vandry) Date: Fri, 18 Aug 2000 15:17:14 -0400 (EDT) Subject: lame delegations In-Reply-To: Your message of "Fri, 18 Aug 2000 12:12:17 EDT." Message-ID: <200008181917.PAA10400@Iodine.Mlink.NET> > ISP-A needs the ability to say "Attention $REGISTRAR, $HOSTNAME is no > longer valid, as evidenced by the current lack of a PTR record. > Please remove it". Indeed. Insist on a true NXDOMAIN response to authorize removing of the record, so that records cannot be removed due to nameservers having technical problems. > Of course, this is a great idea, but can we actually get it > implemented by the relevant agencies? ;-) I think it has the best chance, because at least it does not require coordination between agencies! -Phil From maldwyn at ripe.net Tue Aug 29 16:37:07 2000 From: maldwyn at ripe.net (Maldwyn Morris) Date: Tue, 29 Aug 2000 16:37:07 +0200 Subject: ANNOUNCEMENT: Second Public Beta Release of Asused Message-ID: <200008291437.QAA05501@birch.ripe.net> 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 at ripe.net Software Manager RIPE NCC From hostmaster at mediaways.net Wed Aug 30 16:23:39 2000 From: hostmaster at mediaways.net (mediaWays Hostmaster) Date: Wed, 30 Aug 2000 16:23:39 +0200 Subject: ripe-db question Message-ID: <20000830142340.20828.qmail@demdwu24.mediaways.net> 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 at mediaways.net From nils at work.de Wed Aug 30 16:38:49 2000 From: nils at work.de (Nils Jeppe) Date: Wed, 30 Aug 2000 16:38:49 +0200 (CEST) Subject: ripe-db question In-Reply-To: <20000830142340.20828.qmail@demdwu24.mediaways.net> Message-ID: On Wed, 30 Aug 2000, mediaWays Hostmaster wrote: > Webserver wich are reached by every online user first) > for every user by his language. Wouldn't it be much easier to just use the language setting of the user's browser? I think this even makes MUCH more sense than assuming just because a user is in, say, Denmark, doesn't mean he would prefer danish.... Nils - ----------------------------------------------------------------- - n at work Internet Informationssysteme GmbH Tel +49 40 23880900 Spaldingstrasse 160d Fax +49 40 23880929 20097 Hamburg, Germany http://www.work.de/ From vos at telenor.cz Wed Aug 30 17:05:52 2000 From: vos at telenor.cz (Vitaly Osipov) Date: Wed, 30 Aug 2000 17:05:52 +0200 Subject: ripe-db question References: <20000830142340.20828.qmail@demdwu24.mediaways.net> Message-ID: <018701c01293$ca83c660$dec92f86@int1.telenor.cz> Hi, > 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? actually this is not very difficult task - you can write a script which will make a whois on all /24 netblocks from RIPE allocated space (if I am not mistaken, there are about 200 000 such netblocks - it could take some days, not more). You probably do not need to query smaller netblocks because AFAIK blocks inside one /24 block are not delegated to different countries. Then after simple sorting by "country" field you get your database (but see below) > > 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. If this is the only need of your client - then it will be better to write simple script which analises headers sent by browser when requesting a homepage - there are header "Accept-language" which allows you ho decide what is the user's language priority. Also please note that localized browsers very often set that "Accept-language" to the language of operating system. Regards, Vitaly Osipov > > We are grateful for each assistance. > > Kind regards, > _____________________________ > Stephan Mankopf > Networks/Backbone > +49 5241 80 88729 > stephan.mankopf at mediaways.net > > > > From hostmaster at mediaways.net Wed Aug 30 17:22:05 2000 From: hostmaster at mediaways.net (mediaWays Hostmaster) Date: Wed, 30 Aug 2000 17:22:05 +0200 Subject: ripe-db question In-Reply-To: Your message of "Wed, 30 Aug 2000 16:38:49 +0200." Message-ID: <20000830152205.23815.qmail@demdwu24.mediaways.net> Hi, In message , Nils Jeppe writes: > On Wed, 30 Aug 2000, mediaWays Hostmaster wrote: > > > Webserver wich are reached by every online user first) > > for every user by his language. > > Wouldn't it be much easier to just use the language setting of the user's > browser? I think this even makes MUCH more sense than assuming just > because a user is in, say, Denmark, doesn't mean he would prefer > danish.... yes of course, but the Online-Service is worldwide and there are several countries where English or spanish is spoken (as an Example). Every site includes state-specific informations. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf at mediaways.net > > > > Nils > > > > - ----------------------------------------------------------------- - > n at work Internet Informationssysteme GmbH Tel +49 40 23880900 > Spaldingstrasse 160d Fax +49 40 23880929 > 20097 Hamburg, Germany http://www.work.de/ > > From Stefan.Gasteiger at Gendorf.de Wed Aug 30 17:19:15 2000 From: Stefan.Gasteiger at Gendorf.de (Stefan.Gasteiger at Gendorf.de) Date: Wed, 30 Aug 2000 17:19:15 +0200 Subject: ripe-db question Message-ID: <4185051FE012D411A98B0008C7337A2ED08381@ATLANTIS> 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 at gendorf.de > -----Original Message----- > From: mediaWays Hostmaster [mailto:hostmaster at mediaways.net] > Sent: Wednesday, August 30, 2000 4:24 PM > To: lir-wg at ripe.net; db-wg at 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 at mediaways.net > > > > > From andrei at ripe.net Wed Aug 30 18:09:35 2000 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 30 Aug 2000 18:09:35 +0200 Subject: ripe-db question References: <20000830152205.23815.qmail@demdwu24.mediaways.net> Message-ID: <39AD31BF.F6A9BE0D@ripe.net> Dear Stephan Mankopf, mediaWays Hostmaster wrote: > > Hi, > > In message , Nils > Jeppe writes: > > On Wed, 30 Aug 2000, mediaWays Hostmaster wrote: > > > > > Webserver wich are reached by every online user first) > > > for every user by his language. > > > > Wouldn't it be much easier to just use the language setting of the user's > > browser? I think this even makes MUCH more sense than assuming just > > because a user is in, say, Denmark, doesn't mean he would prefer > > danish.... > > yes of course, but the Online-Service is worldwide and there > are several countries where English or spanish is spoken (as an Example). > Every site includes state-specific informations. > If there is no better solution for you then retrieving country code information from the inetnum objects, I would suggest that you write to to discuss this problem. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC > Kind regards, > _____________________________ > Stephan Mankopf > Networks/Backbone > +49 5241 80 88729 > stephan.mankopf at mediaways.net > > > > > > > > > Nils > > > > > > > > - ----------------------------------------------------------------- - > > n at work Internet Informationssysteme GmbH Tel +49 40 23880900 > > Spaldingstrasse 160d Fax +49 40 23880929 > > 20097 Hamburg, Germany http://www.work.de/ > > > > -- From feico.dillema at invenia.no Wed Aug 30 18:49:57 2000 From: feico.dillema at invenia.no (Feico Dillema) Date: Wed, 30 Aug 2000 18:49:57 +0200 Subject: Address Space Waiting Time... Message-ID: <20000830184957.G13005@dillema.net> 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. From amar at telia.net Wed Aug 30 18:04:34 2000 From: amar at telia.net (Amar) Date: Wed, 30 Aug 2000 18:04:34 +0200 Subject: Address Space Waiting Time... References: <20000830184957.G13005@dillema.net> Message-ID: <39AD3092.38B49D9A@telia.net> Feico Dillema wrote: > > 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... panic. Be prepared with some Prozac if it gets ugly. -- amar From storch at infra.net Wed Aug 30 17:33:45 2000 From: storch at infra.net (Christian Storch) Date: Wed, 30 Aug 2000 17:33:45 +0200 Subject: ripe-db question Message-ID: <01C012A8.734BB140@kleopatra.m.INFRA.NET> 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 at infra.NET //========================== -----Original Message----- From: mediaWays Hostmaster [SMTP:hostmaster at mediaways.net] Sent: Wednesday, August 30, 2000 4:24 PM To: lir-wg at ripe.net; db-wg at 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 at mediaways.net From netmaster at space.net Wed Aug 30 17:34:38 2000 From: netmaster at space.net (Gert Doering, Netmaster) Date: Wed, 30 Aug 2000 17:34:38 +0200 Subject: ripe-db question In-Reply-To: <018701c01293$ca83c660$dec92f86@int1.telenor.cz>; from vos@telenor.cz on Wed, Aug 30, 2000 at 05:05:52PM +0200 References: <20000830142340.20828.qmail@demdwu24.mediaways.net> <018701c01293$ca83c660$dec92f86@int1.telenor.cz> Message-ID: <20000830173438.H22921@Space.Net> Hi, On Wed, Aug 30, 2000 at 05:05:52PM +0200, Vitaly Osipov wrote: > > Is there any chance to get it per whois/some > > application or do we buy some part of whois-db from ripe? > > actually this is not very difficult task - you can write a script which will > make a whois on all /24 netblocks from RIPE allocated space Ugh. Just do "whois -r -M 192.0.0.0/8" and process that, instead of overloading the RIPE server with n times 2^16 queries... Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From vos at telenor.cz Wed Aug 30 17:53:49 2000 From: vos at telenor.cz (Vitaly Osipov) Date: Wed, 30 Aug 2000 17:53:49 +0200 Subject: ripe-db question References: <20000830142340.20828.qmail@demdwu24.mediaways.net> <018701c01293$ca83c660$dec92f86@int1.telenor.cz> <20000830173438.H22921@Space.Net> Message-ID: <01ab01c0129a$7d911ea0$dec92f86@int1.telenor.cz> > Hi, > > On Wed, Aug 30, 2000 at 05:05:52PM +0200, Vitaly Osipov wrote: > > > Is there any chance to get it per whois/some > > > application or do we buy some part of whois-db from ripe? > > > > actually this is not very difficult task - you can write a script which will > > make a whois on all /24 netblocks from RIPE allocated space > > Ugh. Just do "whois -r -M 192.0.0.0/8" and process that, instead of > overloading the RIPE server with n times 2^16 queries... I doubt it will reply anytime soon for such a request - it has some prioritizing of task etc... and anyway you should ask for 193.0.0.0/8, 194.0.0.0/8, 195.0.0.0/8, 163.something/xx and small part of 192.0.0.0/8 Vitaly. > > Gert Doering > -- NetMaster > -- > SpaceNet GmbH Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 From hank at att.net.il Thu Aug 31 07:45:42 2000 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 31 Aug 2000 07:45:42 +0200 Subject: Address Space Waiting Time... In-Reply-To: <20000830184957.G13005@dillema.net> Message-ID: <4.3.2.7.2.20000831074303.00ac94c0@max.ibm.net.il> At 18:49 30/08/00 +0200, Feico Dillema wrote: >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. See the admin flowchart: http://www.ripe.net/ripencc/new-mem/flowchart.html Once you get the administrative part out of the way, you can then start on the IP allocations as detailed in the flowchart at: http://www.ripe.net/ripencc/new-mem/flowchart2.html Generally, you should leave anywhere from 2-4 months to complete the entire process, IMHO. If you haven't, then you are toast. -Hank From willy at lighthouseservers.com Thu Aug 31 10:04:18 2000 From: willy at lighthouseservers.com (Willy Calderon) Date: Thu, 31 Aug 2000 09:04:18 +0100 (BST) Subject: ASN wait time Message-ID: 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 From Brent_Frere at ses-astra.com Thu Aug 31 10:57:22 2000 From: Brent_Frere at ses-astra.com (Brent_Frere at ses-astra.com) Date: Thu, 31 Aug 2000 11:57:22 +0300 Subject: ripe-db question Message-ID: 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 at ses-astra.com URL: http://www.ses-astra.com "mediaWays Hostmaster" To: lir-wg at ripe.net, db-wg at ripe.net Subject: ripe-db question Sent by: owner-lir-wg at 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 at mediaways.net From hostmaster at mediaways.net Thu Aug 31 11:20:15 2000 From: hostmaster at mediaways.net (mediaWays Hostmaster) Date: Thu, 31 Aug 2000 11:20:15 +0200 Subject: ripe-db question In-Reply-To: Your message of "Thu, 31 Aug 2000 11:57:22 +0300." Message-ID: <20000831092015.15759.qmail@demdwu24.mediaways.net> Hi, for me by now we could cut this discussion on lir-wg. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf at mediaways.net ... In message , Brent_Frer e at ses-astra.com writes: > > 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 at ses-astra.com > URL: http://www.ses-astra.com > > > > > "mediaWays > > Hostmaster" To: lir-wg at ripe.net, db-wg at ri >pe.net > > aways.net> Subject: ripe-db question > > Sent by: > > owner-lir-wg at 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 at mediaways.net > > > > > > > > > From hank at att.net.il Thu Aug 31 12:42:46 2000 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 31 Aug 2000 12:42:46 +0200 Subject: ASN wait time In-Reply-To: Message-ID: <4.3.2.7.2.20000831123604.00ae1cb0@max.ibm.net.il> 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 From beri at EU.net Thu Aug 31 12:27:55 2000 From: beri at EU.net (Berislav Todorovic) Date: Thu, 31 Aug 2000 12:27:55 +0200 (CEST) Subject: SLA's needed !!! (Was: Re: ASN wait time) In-Reply-To: Message-ID: On Thu, 31 Aug 2000, Willy Calderon wrote: >> 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? Well, I must say - yes, it happened a couple of times we waited 7-14 days for the initial response. All later responses are getting on daily or hourly basis. A lot of times customers get angry, ask whether we can escalate the problem to anyone within RIPE NCC. Let's be honest: I think NCC people provide really great job for all of us and I understand they have an enormous workload and chronic lack of human resources. However, they should also understand us. The time when NCC provided service mostly to academic community is over. The brave new ISP world now asks for SLA's, escalation procedures, penalties for delays ... And yes - most ISPs usually don't have enough staff as well. Finally - we all contribute to NCC services and expect to get what we paid for. 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). Sorry if this sounds rude, but please understand our position: some of us have to pay large penalties to our customers if we delay with their installations. And IP/AS requests are usually showstoppers ... :-( Just my 0.02 cents. ;-) 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 at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From jorma.mellin at teliafi.net Thu Aug 31 12:50:17 2000 From: jorma.mellin at teliafi.net (Jorma Mellin) Date: Thu, 31 Aug 2000 13:50:17 +0300 Subject: SLA's needed !!! (Was: Re: ASN wait time) Message-ID: <200008311051.MAA10128@birch.ripe.net> >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 at teliafi.net Development Manager ; CCIE#4185 Telia Finland Inc, Network Services From md at linux.it Thu Aug 31 12:38:18 2000 From: md at linux.it (Marco d'Itri) Date: Thu, 31 Aug 2000 12:38:18 +0200 Subject: ripe-db question In-Reply-To: <20000830173438.H22921@Space.Net>; from netmaster@space.net on Wed, Aug 30, 2000 at 05:34:38PM +0200 References: <20000830142340.20828.qmail@demdwu24.mediaways.net> <018701c01293$ca83c660$dec92f86@int1.telenor.cz> <20000830173438.H22921@Space.Net> Message-ID: <20000831123818.C401@wonderland.linux.it> On Aug 30, "Gert Doering, Netmaster" wrote: >Ugh. Just do "whois -r -M 192.0.0.0/8" and process that, instead of >overloading the RIPE server with n times 2^16 queries... Just download the databse dump from ftp.ripe.net, then... -- ciao, Marco From beri at EU.net Thu Aug 31 13:23:28 2000 From: beri at EU.net (Berislav Todorovic) Date: Thu, 31 Aug 2000 13:23:28 +0200 (CEST) Subject: SLA's needed !!! (Was: Re: ASN wait time) In-Reply-To: <200008311051.MAA10128@birch.ripe.net> Message-ID: On Thu, 31 Aug 2000, Jorma Mellin wrote: >> 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. True ... But I didn't mean ALL of us need to define SLA's! Aside of standard LIR categories (small, medium etc.) we can define different classes of 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.). Does this sound better? ;-) 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 at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From Robert.Kiessling at de.easynet.net Thu Aug 31 13:12:00 2000 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: Thu, 31 Aug 2000 13:12:00 +0200 (MEST) Subject: SLA's needed !!! In-Reply-To: <200008311051.MAA10128@birch.ripe.net> References: <200008311051.MAA10128@birch.ripe.net> Message-ID: <14766.15744.529751.646868@doncamillo.local.easynet.de> [delays] What about a more pragmatic solution: simplify the assignment procedure? E.g. we had a request for 8192 addresses. In this request, there was a subnet with 64 addresses marked as "reserved". There was subsequent discussion in several emails about those 0.8% of the total request which are mostly irrelevant for address space comsumption. This kind of evaluation is detached from reality. We all know that such a network cannot be planned two years ahead. At the time a new assignment is due, maybe in a year or so, the usage will be different from the requested one. But the honest solution to say "this is our rough plan and expected usage, but details may vary" is not allowed. What's the result of this strict bureaocratic way of handling things? Only that assignment requests are streamlined to RIPE guidelines, but not that address space is conserved. IMHO, introducing a bit of flexibility would not hurt the overall goal, but instead reduce workload on both RIPE and ISPs. Robert From jorma.mellin at teliafi.net Thu Aug 31 13:51:15 2000 From: jorma.mellin at teliafi.net (Jorma Mellin) Date: Thu, 31 Aug 2000 14:51:15 +0300 Subject: SLA's needed !!! (Was: Re: ASN wait time) Message-ID: <200008311152.NAA28468@birch.ripe.net> >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 From woeber at cc.univie.ac.at Thu Aug 31 14:37:50 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 31 Aug 2000 14:37:50 MET-DST Subject: SLA's needed !!! (Was: Re: ASN wait time) Message-ID: <009EF6E1.80BB29F0.7@cc.univie.ac.at> >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... 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... -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ula at ripn.net Thu Aug 31 14:41:27 2000 From: ula at ripn.net (Larisa A. Yurkina) Date: Thu, 31 Aug 2000 16:41:27 +0400 (MSD) Subject: SLA's needed !!! (Was: Re: ASN wait time) In-Reply-To: <200008311152.NAA28468@birch.ripe.net> Message-ID: On Thu, 31 Aug 2000, Jorma Mellin wrote: > >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? Perhaps it would be best to use those people who are doing hostmaster's job at their places? To form special organizations joining a number of LIRs, hire well trained and exprienced hostmasters authorized to make assignements from LIR's blocks; requests for new allocations send to RIPE NCC with reports. The remuneration should make n% of the service fee. > > 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 > > With respect, Larisa Yurkina --- RIPN Registry center ----- From marco at sara.nl Thu Aug 31 16:31:27 2000 From: marco at sara.nl (Marco Davids) Date: Thu, 31 Aug 2000 16:31:27 +0200 (MET DST) Subject: Is this normal behaviour? Message-ID: 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 From beri at EU.net Thu Aug 31 23:50:31 2000 From: beri at EU.net (Berislav Todorovic) Date: Thu, 31 Aug 2000 23:50:31 +0200 (CEST) Subject: IP allocs on the NAPs/IXs Message-ID: 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 at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----