From bs at eunet.ch Fri Mar 2 14:08:06 2001 From: bs at eunet.ch (Bernard Steiner) Date: Fri, 02 Mar 2001 14:08:06 +0100 Subject: Adding nic handles to contact objects without one In-Reply-To: Your message of "Fri, 26 Feb 1999 17:09:02 +0100." <199902261609.RAA03687@x41.ripe.net> Message-ID: <200103021308.OAA01910@eunet.ch> Folks, > "Eamonn" writes: > * I'd like to know what exactly are the advantages (and to whom) to > * adding a nic-hdl to person objects which don't already have one ? > I think there are benefits for everyone. The database becomes more coherent, > ambiguity between different people with the same name disappears (especially > if as you say below, references by name are then substituted by references to > NIC Handles). This is a non-advantage because > RIPE NCC can do it if users wish to. Of course this can only be done for > references by name corresponding to names that are unique in the database, > otherwise we wouldn't know who to assign the object to and we shouldn't. the existing ambiguity will *not* disappear. > * Then you have the problem where these people created a new person > * object for themselves when nic-hdls became mandatory and left their > * old person object for dead. How will you overcome these old person > * objects ? Let me also point out that there appear to exist (inetnum) objects that reference non-existing person objects. If a new person object is created such that the name happens to match, that person will then inherit the reference. This may or may not be intentional (e.g. replacing a person object with a role object where the new role object has the same handle as the old person object :-) On the other hand, just because someone who used to have something to do with an inetnum in (say) Norway and another Person with the same name but from (say) Switzerland appears in the database, if the .no guy's person record got deleted, then the .ch guy has nothing to do with the .no inetnums. Even as of now, I cannot delete old person objects in cases where names are referenced and objects with the same name are still in the database :-( What I am getting at is that if you add handles to all person objects and then update the references from person names to handles, the effect is not necessarily correct. You cannot make a non-consistent database consistent by automatic measures. Just my ECU 0.02 Greetings Bernard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 460 bytes Desc: not available URL: From hph at online.no Fri Mar 2 10:55:36 2001 From: hph at online.no (Hans Petter Holen) Date: Fri, 2 Mar 2001 10:55:36 +0100 Subject: Refuse een assignment because it 'cannot' be routed? References: Message-ID: <006501c0a2fe$ff7a6c60$0b00000a@hph> > the government (RIPE) RIPE is not a government. RIPE sets policies based on consensus among its participants, it does not make laws based on majority votes. I do have sympathy with your problem, but I think a better way would be to educate the ISP in question why the product you suggest would increase their sales and improve customer satisfaction. Another side of this coin is that the current policies puts a strong emphasis on the use of dynamic IP addresses for mass-market products. -hph From plu at cw.net Thu Mar 1 19:04:14 2001 From: plu at cw.net (Lu, Ping) Date: Thu, 01 Mar 2001 13:04:14 -0500 Subject: RIPE: last call for comments RPSL transition Message-ID: Hi, Joachim, We had a lively discussion about the RPSL transition during the RIPE-38 meeting. Well, if we can't fight them then the best thing to do is to join them. With the company's support behind us, we (Cable & Wireless Global) as a legacy LIR (used to be MCI) would like to work with RIPE to help the RPSL transition. CW will adopt a similar schedule as RIPE's to transform our Routing Registry into the new RPSL format. This will probably make all the mirroring LIRs' job much easier and hopefully all the downstream ISPs happier (only the RPSL format to deal with). So GO FOR IT. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: SchmitzJo at aol.com [mailto:SchmitzJo at aol.com] > Sent: Friday, February 16, 2001 6:46 PM > To: routing-wg at ripe.net; db-wg at ripe.net; lir-wg at ripe.net; > local-ir at ripe.net > Cc: andrei at ripe.net; joao at ripe.net; hph at a.sol.no; > woeber at cc.univie.ac.at; schmitzjo at aol.com > Subject: RIPE: last call for comments RPSL transition > Importance: Low > > > Hello all, > > as you are aware, we are preparing the migration of the RIPE database > software to support and deploy the new RPSL format. The required steps > have been discussed in depth on various occassions (for references, > see end of mail). > > We are now preparing the most important step, really > transitioning from > old > RIPE-181 to new RPSL format: > > proposed transition date is 23-Apr-2001. > > This step, once taken, will not be reversed. The majority of the user > community takes a neutral role, while some want an earlier, > and a few a > later > date for migration. During the joint session of Routing and DB WG at > RIPE38, > the chairmen of both WGs were tasked to file a last call for > comments on > that > date, in particular whether there are serious, unresolvable > technical or > operational problems which would benefit from a slightly > longer warning > period. > > According to consensus at the session: If you are convinced that the > transition date as proposed would lead to significant operational > problems, please explain and justify why within the next 2 weeks: > > deadline for transition comments: 1-Mar-2001 > > Only well founded reasoning (including an educated guess > about the time > and resources required to resolve the issue) shall be accepted by the > community in order to consider postponing the transition. > > With the discussion about the migration going on for quite > some time, and > information available from various places, we do not expect a > delay, but > we would want to give everybody a last opportunity to comment. > > To summarize the dates, we are looking at: > > o 23-Apr-2001: switching to the RPSL database > - All objects are automatically converted to RPSL format > - Queries return RPSL only > - Mirroring follows new format and rules at > whois.ripe.net, port 4444 > - RPSL formatted updates can be submitted to auto-rpsl at ripe.net > - RIPE-181 updates are still accepted at auto-dbm at ripe.net, > but are autmatically converted to RPSL > - RFC2725 (Routing Policy Security System) rules apply throughout > > o 14-May-2001: exchanging mail addresses for submitting > RIPE181 and RPSL- > formatted updates > - auto-dbm at ripe.net only accepts RPSL updates > - RIPE-181 updates are still possible but now go to > auto-181 at ripe.net > and are automatically converted to RPSL (again, > RFC2725 rules apply > here as well) > > o 15-Oct-2001: RIPE-181 updates are no longer accepted > > For further reading, please refer to the migration web page > http://www.ripe.net/rpsl > or for the discussion during the joint session of the DB/Routing WGs > please review the minutes. > > For technical specifications of RPSL please refer to > - rfc2622: "Routing Policy Specification Language (RPSL)" > Status: PROPOSED STANDARD, > - rfc2650: "Using RPSL in Practice" > Status: INFORMATIONAL > - rfc2725: "Routing Policy System Security" > Status: PROPOSED STANDARD > > Thanks a lot - the RIPE NCC and the chairmen of > Routing: Joachim Schmitz > DB: Wilfried Woeber > LIR: Hans Peter Holen > > From marcel at eu.uu.net Thu Mar 1 20:53:53 2001 From: marcel at eu.uu.net (Anne Marcel Roorda) Date: Thu, 01 Mar 2001 19:53:53 +0000 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Your message of "Wed, 28 Feb 2001 14:03:18 +0100." <009F8517.AACFE69E.14@cc.univie.ac.at> Message-ID: > To continue that (cute | silly | pick-your-choice) analogy... > > => I only want a fixed frontdoor (1 fixed IP address), but I am trying to for ce > => my landlord into letting me have it without paying tripple rent, by asking > => the government (RIPE) to give me a building permission to install more > => doors. Not because I want more doors, but to keep the landlord from moving > => my single door every day :) > => > = > =Hi, > = > = Hmm... this analogy isn't correct. RIPE is not the government in this. > =RIPE, or your local LIR can give you a door (address assignment), but > =you still need to get a permit from the local counsil to place it > =(Getting your service provider to actually route it). > = > =One of the things your local LIR may require before selling you a door > =is having a permit. Buying the door somewhere else (RIPE) does not > =automagically entitle you to a permit. > > ...what we are seeing in reality, though, is something like the > "government" (the RIPE NCC) coming back with a question about the > colour and style of the door. > And - depending on your answer - either going ahead issuing a > _permanent_ permit for e.g. an Ethernet- or leased-line-style door > ("static"), but limiting the validity of the permit for an xDSL- style > or dial-up door to as long as you, or someone from your family, happens > stay at home ("dynamic"). As soon as you go to work, or even worse - > take a couple of days off, duhh!!! - you have to submit another > application for installing a door. Hi, As I said before, RIPE is not the government in this. The permit mentioned in the example above is the willingnes of your provider to actually route the traffic to you. If you can convince your provider's LIR to allocate you some IP space, _AND_ you can convince them to route it to you then RIPE won't object as long as the proper forms have been filled in. Using dynamic IP space for residential dial up users makes sence for most appications. Giving every computer out there a static IP address even though it's turned off, or not connected to the internet 98% of the time just doesn't make sence. > > And, the "government", suggests to the manufaturers of the doors (and/or > to the landlord), to give you a call on the phone every, say, 8 hours, > to confirm that you haven't left for shopping (physicly) or turned to > RTFM (virtually/mentally logging off). > > That's exactly what happens to me, back home, with my ADSL link being > dropped every 8 hours by the ISP *on purpose*, because the NCC sort of > "suggests" to the ISPs to use dial-up ratio mechanisms for 24x7 xDSL, > flat rate billing. > > Very clever, indeed, in particular when someone tries to do stuff that > is security-aware. Like what? Almost anything is possible from behind a dynamic IP address. If you want to run services then get a commercial account from your provider, or find a provider that will allocate you static IP space. - marcel From panigl at cc.univie.ac.at Thu Mar 1 19:55:00 2001 From: panigl at cc.univie.ac.at (Christian Panigl, ACOnet/VIX/UniVie) Date: Thu, 01 Mar 2001 19:55:00 +0100 Subject: RIPE: last call for comments RPSL transition Message-ID: <009F8611.F6CF0598.15@cc.univie.ac.at> Hi Joachim, well I'd say go for it. But let me kindly ask for the following thingies: since the RIPE-NCC is now in charge of the maintenance of the RAtoolset please make sure that there's a release available (specifically RTconfig) which is fully compatible with the RIPE RPSL server by mid of March 2001 latest. It appears that this might be available already (since Feb20 ?), however, the link to "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is broken. In addition, any clear links to concise How2do documents on RAToolSet and RtConfig would be appreciated. Thanks and kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl at CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- --- From plu at cw.net Thu Mar 1 19:04:14 2001 From: plu at cw.net (plu at cw.net) Date: Thu, 01 Mar 2001 19:04:14 +0100 Subject: RIPE: last call for comments RPSL transition In-Reply-To: References: Message-ID: Hi, Joachim, We had a lively discussion about the RPSL transition during the RIPE-38 meeting. Well, if we can't fight them then the best thing to do is to join them. With the company's support behind us, we (Cable & Wireless Global) as a legacy LIR (used to be MCI) would like to work with RIPE to help the RPSL transition. CW will adopt a similar schedule as RIPE's to transform our Routing Registry into the new RPSL format. This will probably make all the mirroring LIRs' job much easier and hopefully all the downstream ISPs happier (only the RPSL format to deal with). So GO FOR IT. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu at cw.net >> -----Original Message----- >> From: SchmitzJo at aol.com [mailto:SchmitzJo at aol.com] >> Sent: Friday, February 16, 2001 6:46 PM >> To: routing-wg at ripe.net; db-wg at ripe.net; lir-wg at ripe.net; >> local-ir at ripe.net >> Cc: andrei at ripe.net; joao at ripe.net; hph at a.sol.no; >> woeber at cc.univie.ac.at; schmitzjo at aol.com >> Subject: RIPE: last call for comments RPSL transition >> Importance: Low >> >> >> Hello all, >> >> as you are aware, we are preparing the migration of the RIPE database >> software to support and deploy the new RPSL format. The required steps >> have been discussed in depth on various occassions (for references, >> see end of mail). >> >> We are now preparing the most important step, really >> transitioning from >> old >> RIPE-181 to new RPSL format: >> >> proposed transition date is 23-Apr-2001. >> >> This step, once taken, will not be reversed. The majority of the user >> community takes a neutral role, while some want an earlier, >> and a few a >> later >> date for migration. During the joint session of Routing and DB WG at >> RIPE38, >> the chairmen of both WGs were tasked to file a last call for >> comments on >> that >> date, in particular whether there are serious, unresolvable >> technical or >> operational problems which would benefit from a slightly >> longer warning >> period. >> >> According to consensus at the session: If you are convinced that the >> transition date as proposed would lead to significant operational >> problems, please explain and justify why within the next 2 weeks: >> >> deadline for transition comments: 1-Mar-2001 >> >> Only well founded reasoning (including an educated guess >> about the time >> and resources required to resolve the issue) shall be accepted by the >> community in order to consider postponing the transition. >> >> With the discussion about the migration going on for quite >> some time, and >> information available from various places, we do not expect a >> delay, but >> we would want to give everybody a last opportunity to comment. >> >> To summarize the dates, we are looking at: >> >> o 23-Apr-2001: switching to the RPSL database >> - All objects are automatically converted to RPSL format >> - Queries return RPSL only >> - Mirroring follows new format and rules at >> whois.ripe.net, port 4444 >> - RPSL formatted updates can be submitted to auto-rpsl at ripe.net >> - RIPE-181 updates are still accepted at auto-dbm at ripe.net, >> but are autmatically converted to RPSL >> - RFC2725 (Routing Policy Security System) rules apply throughout >> >> o 14-May-2001: exchanging mail addresses for submitting >> RIPE181 and RPSL- >> formatted updates >> - auto-dbm at ripe.net only accepts RPSL updates >> - RIPE-181 updates are still possible but now go to >> auto-181 at ripe.net >> and are automatically converted to RPSL (again, >> RFC2725 rules apply >> here as well) >> >> o 15-Oct-2001: RIPE-181 updates are no longer accepted >> >> For further reading, please refer to the migration web page >> http://www.ripe.net/rpsl >> or for the discussion during the joint session of the DB/Routing WGs >> please review the minutes. >> >> For technical specifications of RPSL please refer to >> - rfc2622: "Routing Policy Specification Language (RPSL)" >> Status: PROPOSED STANDARD, >> - rfc2650: "Using RPSL in Practice" >> Status: INFORMATIONAL >> - rfc2725: "Routing Policy System Security" >> Status: PROPOSED STANDARD >> >> Thanks a lot - the RIPE NCC and the chairmen of >> Routing: Joachim Schmitz >> DB: Wilfried Woeber >> LIR: Hans Peter Holen >> >> From panigl at cc.univie.ac.at Thu Mar 1 19:55:00 2001 From: panigl at cc.univie.ac.at (panigl at cc.univie.ac.at) Date: Thu, 01 Mar 2001 19:55:00 +0100 Subject: RIPE: last call for comments RPSL transition In-Reply-To: <009F8611.F6CF0598.15@cc.univie.ac.at> References: <009F8611.F6CF0598.15@cc.univie.ac.at> Message-ID: Hi Joachim, well I'd say go for it. But let me kindly ask for the following thingies: since the RIPE-NCC is now in charge of the maintenance of the RAtoolset please make sure that there's a release available (specifically RTconfig) which is fully compatible with the RIPE RPSL server by mid of March 2001 latest. It appears that this might be available already (since Feb20 ?), however, the link to "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is broken. In addition, any clear links to concise How2do documents on RAToolSet and RtConfig would be appreciated. Thanks and kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl at CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- --- From herbert.baerten at hostit.be Fri Mar 2 16:19:42 2001 From: herbert.baerten at hostit.be (Herbert Baerten) Date: Fri, 2 Mar 2001 16:19:42 +0100 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Message-ID: > > Very clever, indeed, in particular when someone tries to do stuff that > > is security-aware. > > Like what? Almost anything is possible from behind a dynamic > IP address. I want to connect, from home, to a server behind my company's firewall. The firewall only allows connections based on source ip address. Our firewall admin cannot be persuaded to open it up for the whole /19 or whatever my isp uses for its dhcp pool. > If you want to run services then get a commercial account from > your provider, or find a provider that will allocate you static > IP space. This is the problem that caused me to start this discussion: in my area there is no broadband (cable/dsl) provider offering static ip for a reasonable price. If I get a 'commercial' account I need to pay 4(!) times as much as I would for a 'noncommercial' account *per month*; I do not consider this reasonable, even if it does include a bunch of other things I do not want (router etc.). So by posting here, I hoped to find some arguments to use in convincing the ISPs in my area. Regulation from RIPE [NCC] would have been nice... alas. Suggestions are still welcome :) Have a nice weekend, Herbert From SchmitzJo at aol.com Fri Mar 2 18:44:48 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Fri, 2 Mar 2001 12:44:48 EST Subject: RIPE: last call for comments RPSL transition Message-ID: <7e.119bea28.27d13610@aol.com> Dear Ping Lu, you wrote: > We had a lively discussion about the RPSL transition during the RIPE-38 > meeting. This is correct, and I very much appreciate the input you provided during our joint working group session. > Well, if we can't fight them then the best thing to do is to join them. Do I need to be worried now? I never considered this to be a fight ;-) > With the company's support behind us, we (Cable & Wireless Global) as a > legacy LIR (used to be MCI) > would like to work with RIPE to help the RPSL transition. > > CW will adopt a similar schedule as RIPE's to transform our Routing Registry > into the new RPSL format. > This will probably make all the mirroring LIRs' job much easier and > hopefully all the downstream ISPs happier (only the RPSL format to deal > with). > > So GO FOR IT. I welcome your approval. I believe I do not exaggerate stating that you can count on the support from the RIPE community and the NCC in particular in the transition effort. Thanks Joachim --- JS395-RIPE -- standard disclaimer --- From SchmitzJo at aol.com Fri Mar 2 19:08:56 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Fri, 2 Mar 2001 13:08:56 EST Subject: RIPE: last call for comments RPSL transition Message-ID: <15.10890414.27d13bb8@aol.com> Dear Christian, you wrote: > well I'd say go for it. Thank you for your support. > But let me kindly ask for the following thingies: > > since the RIPE-NCC is now in charge of the maintenance of the RAtoolset > please make sure that there's a release available (specifically > RTconfig) which is fully compatible with the RIPE RPSL server by mid of > March 2001 latest. I believe that this request is more than legitimate, and that the NCC is hearing you very well - after all it is in all our interest to have this running. > > It appears that this might be available already (since Feb20 ?), > however, the link to > > "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is > broken. This is currently worked on, as I hear. > > In addition, any clear links to concise How2do documents on RAToolSet > and RtConfig would be appreciated. On the one hand, I think the best source for that still is http://www.isi.edu/ra/RAToolSet/ On the other hand, we will have a tutorial on the RAToolSet during RIPE39. This has been confirmed by now, and I believe that additional documentation will become available around it. Thanks Joachim --- JS395-RIPE -- standard disclaimer --- From marcel at eu.uu.net Mon Mar 5 18:42:11 2001 From: marcel at eu.uu.net (Anne Marcel Roorda) Date: Mon, 05 Mar 2001 17:42:11 +0000 Subject: Refuse een assignment because it 'cannot' be routed? In-Reply-To: Your message of "Fri, 02 Mar 2001 16:19:42 +0100." Message-ID: > > > > > > Very clever, indeed, in particular when someone tries to do stuff that > > > is security-aware. > > > > Like what? Almost anything is possible from behind a dynamic > > IP address. > > I want to connect, from home, to a server behind my company's firewall. The > firewall only allows connections based on source ip address. > Our firewall admin cannot be persuaded to open it up for the whole /19 or > whatever my isp uses for its dhcp pool. > Hi, And rightly so. Opening up a secure server to an IP number outside of your direct sphere of influence is asking for trouble, and leads to security nightmares. I'm surprised he'd be willing to open it up to a /32 from outside. > > > If you want to run services then get a commercial account from > > your provider, or find a provider that will allocate you static > > IP space. > > This is the problem that caused me to start this discussion: in my area > there is no broadband (cable/dsl) provider offering static ip for a > reasonable price. If I get a 'commercial' account I need to pay 4(!) times > as much as I would for a 'noncommercial' account *per month*; I do not > consider this reasonable, even if it does include a bunch of other things I > do not want (router etc.). > > So by posting here, I hoped to find some arguments to use in convincing the > ISPs in my area. Regulation from RIPE [NCC] would have been nice... alas. This would seem like a clasic case of the wrong solution for a simple problem. > > Suggestions are still welcome :) There are a lot of VPN products out there, some better then others. Setting up a jump host outside the firewall may also be a sollution to your problems. I suggest that you contact your local security officer for possible sollutions. Regards, - marcel From SchmitzJo at aol.com Mon Mar 5 19:57:14 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Mon, 5 Mar 2001 13:57:14 EST Subject: RIPE RPSL transition date set! Message-ID: <20.12d8c25d.27d53b8a@aol.com> Hello all, following up on our last call for comments on the RPSL transition for the RIPE database, we did not receive any mails or information which may have delayed the transition. In contrast, we received a set of supportive mails. Accordingly, the transition to RPSL will now follow the outlined dates: o 23-Apr-2001: switching to the RPSL database *** now set *** - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl at ripe.net - RIPE-181 updates are still accepted at auto-dbm at ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL-formatted updates - auto-dbm at ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181 at ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl We will continue to update you prior to the dates detailed above. Thanks - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen From SchmitzJo at aol.com Mon Mar 5 19:57:14 2001 From: SchmitzJo at aol.com (SchmitzJo at aol.com) Date: Mon, 05 Mar 2001 19:57:14 +0100 Subject: RIPE RPSL transition date set! In-Reply-To: <20.12d8c25d.27d53b8a@aol.com> References: <20.12d8c25d.27d53b8a@aol.com> Message-ID: Hello all, following up on our last call for comments on the RPSL transition for the RIPE database, we did not receive any mails or information which may have delayed the transition. In contrast, we received a set of supportive mails. Accordingly, the transition to RPSL will now follow the outlined dates: o 23-Apr-2001: switching to the RPSL database *** now set *** - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl at ripe.net - RIPE-181 updates are still accepted at auto-dbm at ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL-formatted updates - auto-dbm at ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181 at ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl We will continue to update you prior to the dates detailed above. Thanks - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen From djp at djp.net Tue Mar 6 16:17:36 2001 From: djp at djp.net (Dave Pratt) Date: Tue, 6 Mar 2001 16:17:36 +0100 (MET) Subject: IP Management Tool - Minimum Requirements In-Reply-To: <20010226162625.A55934@sirius-cybernetics-corporation.com> Message-ID: Hiya all, I would like to see some capability for reservation/hierarchy/delegation in such a tool. For example at Viag Interkom we have small ranges loosly reserved to each of 10 or so locations. These loose reservations can be aggregated and only exceptions need to be announced to all routers in our network. From our experience I would say that up to about 30% of an allocation can be reserved with current IPv4 policies, but that could be less depending on the likely assignment types. the reservation can be later shrunk if necessary (not yet needed). Typically a single /24 per site is used for small assignments. If a reservation gets full, another is made - two route announcements are better than no aggregation. Despite this reservation we are able fairly easily to reach the 80% utilisation required from RIPE for further allocations. Hierarchy/reservation is also very important in networks where addresses are in somewhat greater supply (RFC1918 and maybe IPv6). I have moderate perl experience and, after my left upper arm heals from a double fracture last Thursday :) , I may be able to help with some coding. Dave Pratt Viag Interkom From Tramnitz at t-online.de Tue Mar 20 15:21:00 2001 From: Tramnitz at t-online.de (Tramnitz at t-online.de) Date: 20 Mar 2001 14:21 GMT Subject: FW: LIR Registration Message-ID: <14fN0v-1oJ6QqC@fwd07.sul.t-online.com> I sent the mail below to ncc at ripe.net and didnt get an answer up to now, so I'm wondering if anyone in this list may help or could give us some notes. tia >>>>>>>>>>>>>>>>>>>>>>>> Dear Ladies and Gentlemen, we plan to become LIR in the very near future and have some questions concerning registration and status issues. Currently we deploy VPN-connections over WANs and the internet for customers, including centralized internet-gateway and hosting services. As we grow, the needs of our customers grow exponentially, forcing us to provide redundant internet-access at our internet-gateway and hosting location here in Berlin. For this need, we plan to connect to (in the first step) two upstream providers and get an fully internet-routable addressblock. As you state in Ripe-Document 142 the use of PI-address-space in an AS would be suitable for this, but as you say in the same document you do not guarentee the ability to route this address-space in the whole internet. But exactly this guarantee is what we need to provide our customers the service-level-agreements they expect. So we can't only use this PI-address-space but instead become LIR and get our own allocated address space in an order of magnitude that is routed in the internet. Our question is now, what is the real difference between enterprise LIR and small provider LIR? We do not plan to assign customers address-space besides RFC1819 nets for LAN-2-LAN connections through VPNs but only assign addresses for hosting, housing and VPN-Connections through the internet. The second question is, if we would get *at all* an addressblock /19 if we cant show up a plan that we will use an certain amount of this address in e.g. 48 months which will be true in our current considerations. Sincerely, Christian Tramnitz From denesh at cyberstrider.net Tue Mar 20 16:59:43 2001 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Tue, 20 Mar 2001 15:59:43 +0000 Subject: FW: LIR Registration In-Reply-To: <14fN0v-1oJ6QqC@fwd07.sul.t-online.com> Message-ID: <5.0.2.1.2.20010320155654.02f318f8@mail.own.cyberstrider.net> At 14:21 20/03/2001, Tramnitz at t-online.de wrote: >Our question is now, what is the real difference between enterprise >LIR >and small provider LIR? We do not plan to assign customers >address-space How do you plan to do a VPN service for customers if you do not plan on assigning addresses for a service to them? Enterprise address space is basically where you assign addresses to your own self. >The second question is, if we would get *at all* an addressblock >/19 if we cant show up a plan that we will use an certain amount of >this >address in e.g. 48 months which will be true in our current >considerations. You will initially get a /20 - and when you start filling this, and as you mention you will grow quickly (expecting a /19 usage in two years time) then there is no reason why you should not get an extra /20. Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions From guy at sirius-cybernetics-corporation.com Thu Mar 22 13:26:20 2001 From: guy at sirius-cybernetics-corporation.com (Guy Vegoda) Date: Thu, 22 Mar 2001 12:26:20 +0000 Subject: IMPT Message-ID: <20010322122620.A29074@sirius-cybernetics-corporation.com> OK, lets get this IP tool sorted out quicky. I'm gonna set a deadline of Friday 30th of March for anyone who cares to send in their minimal requirements. After this, we will move on to specification for exactly two weeks. At the end of this period, those who wish to volunteer to do any coding will have a window to do so, and within this group, dicussions about implimentation will begin. Sorry if this seems a little bossy; it is. I just know that unless somebody gives it a kick start, this thing will fade into oblivion. There's no reason why it should do this as it could be so good. I am officially asking Mal to please repost the current requirements back up on this list. All those who would like to change, insert or delete a requirement, can then email with their changes. If you want something in, say so, and why, explicitly.. If you just say "Well, it might be nice if...", then it wont get stuck in. We need concrete, minimal requirements, that the working group can vote on. Hope this sparks some interest, Looking forward to hearing from people, Thanks everyone very much, Guy -- Guy Vegoda \ guy at vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell) From maldwyn at ripe.net Thu Mar 22 16:25:17 2001 From: maldwyn at ripe.net (Maldwyn Morris) Date: Thu, 22 Mar 2001 16:25:17 +0100 Subject: IP Management Tool - Minimum Requirements Message-ID: <3946.985274717@ripe.net> Hello everyone, Guy wrote: > > I am officially asking Mal to please repost the > current requirements back up on this list. [...] Happy to oblige. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Hi, Following a presentation of an IP Management Tool by Guy Vegoda at the last RIPE Meeting Tools BOF, interest was expressed in the development of an Open Source version of such a tool and I agreed to use the lirwg list to try and draw up Requirements for this. Hopefully this can be refined into something that we can then begin writing Specifications for. Please remember that these are *Requirements* - i.e. what the users want the tool to do. Please confine remarks to this area and avoid mixing in the *Specifications* - i.e. how those requirements will be met - which we will come to, in good time. It should also be emphasised that we would at this stage like to concentrate on _minimum_ requirements for a simple tool, such that it would be useful to a large number of LIRs. I think we can use these Minimum Requirements to produce something that may or may not include more advanced features as well, knowing that we would at least have covered the basic needs. Comments on this process and the document are most welcome, and we would also like a good name. Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in drawing up this document, and especially to Guy for presenting his tool. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Minimum Requirements for an IP Management Tool ---------------------------------------------- 0. Introduction Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 [1]. This document is an attempt to specify the minimum requirements for a similar tool, with the aim of producing an Open Source version for anyone who wants to use it. Below, I address 1. General Points about the project, 2. The Requirements themselves, 3. External Constraint that must be considered, and 4. A list of References. 1. General Points Name: Let's use IPMT ( IP Management Tool ) as a placeholder for now. Users: We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC' [phew]. We will call one of these people a 'LIRHostmaster' and their organisation an 'LIR'. It may also be useful to other people in other organisations to do other things, but that will not influence the requirements. Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Requirements General functionality: IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 allocations. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 assignments. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should allow the LIRHostmasters to receive requests for IPV4 assignments from the customers of their LIR and allow them to process them. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. User Interface: LIRHostmasters should be able to conveniently access IPMT functions from a wide range of Desktop Operating Systems, possibly including non-modern, non-Unix-like ones. A GUI interface is the minimal acceptable convenience level. A less-convenient interface to IPMT for more complex functions and administration is acceptable. 3. External constraints The RIPE NCC only accepts requests for new IPv4 Assignments and Allocations via email to hostmaster at ripe.net and replies only via email [4]. IPV4 Assignment requests must be in RIPE 141 format [5]. Requests for new IPV4 Allocations have no special format. LIRHostmasters handle customer requests for Assignments via telephone, email and web pages. IPMT must have access to the RIPE DB [6] or a local mirror thereof. 4. References [1] http://www/ripe/meetings/archive/ripe-38/index.html [2] http://www.gnu.org/copyleft/lesser.html [3] http://www.gnu.org/copyleft/gpl.html [4] http://www.ripe.net/ripencc/mem-services/registration/status.html [5] http://www.ripe.net/ripe/docs/ripe-141.html [6] http://www.ripe.net/ripencc/pub-services/db/ From hph at online.no Thu Mar 29 00:57:26 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 29 Mar 2001 00:57:26 +0200 Subject: Management of the working group References: <12772179.980325707779.JavaMail.webmail2@wm-java2.fg.online.no> Message-ID: <003201c0b7da$7576fe20$0500000a@hph> Dear lir-wg, We need to wrap up and conclude this process. I suggest the following: - As there was no substatial comments to the overall otuline of this process, we should go ahead, but discuss the details at the next meeting. - As this is a procedure for the lir-wg, an open forum, where RIPE NCC association membership have not been a prerequisite to participate, influence or vote I do not find it appropriate to include suggestions that either specifies how many votes pr LIR. - I have taken the liberty to keep the original formulation, to be confirmed by consensus at the meeting, which is equivalent to the way we elect AC members (we dont' realy need different procedures for such simmilar elections) - I have added a 5th clause on how we bring this procedure into operation, which would in my opinion take care of Frode Greisens concern, but would also make it clear that if elected at one meeting, you serve as chair until the next election. I therefor suggest that we get to the real issue here: nominations. | My proposal is as following: | 1) Open nominations on the lir-wg mailinglist | 2) Optional discussion and support statements | | 3) Election of chair and 1-2 co chairs at the next lir-wg | meeting in Bologna. | | 3b) The election to be performed either open ballot or | by secret ballot if demanded by one or more | participants at the meeting | | 3c) The election to be confirmed by consensus by the wg | after the election result have been duly counted by a | counting team from the audience. | | 4) That we perform such an election annualy to ensure the | community support to the wg chairs. 5) This procedure will be ut into effect when 5a) The terms of the chair and co chairs expire 5b) A number of 10 participants in the lir-wg representing diverse interests (not from the same LIR or Organisation demand so on the lir-wg mailinglist. Best Regards, Hans Petter Holen lir-wg chair From hph at online.no Thu Mar 29 01:40:36 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 29 Mar 2001 01:40:36 +0200 Subject: Call for agenda items & draft agenda Message-ID: <004201c0b7e0$7deb8c00$0500000a@hph> Dear WG, I would like to bring to your attention the upcoming working group meeting in Bologna, likely to be on Wed May 2nd. Please suggest agenda items that needs to be discussed to the mailinglist. Draft Agenda 1.Admin - scribe, participant list, charter, mailing-lists 2.Agenda 3.RIPE 38 minutes & actions 4.Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. 17th of May Task force - goal reached or what to do next ? 6. Report from The ASO: AC happenings and GA 7.Closure of the ICANN ad Hoc Group on numbering 8.Election of WG Chair and co-chair Actions from last meeting: 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes 37.1 WG Further discuss restoring the transparency 37.2 NCC Incorporate IESG/IAB proposal into IPv6 policy 37.3 M17 Work with the RIPE NCC to implement suggestions From hph at online.no Thu Mar 29 01:46:24 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 29 Mar 2001 01:46:24 +0200 Subject: Call for nominations for lir-wg chair and co-chairs References: <12772179.980325707779.JavaMail.webmail2@wm-java2.fg.online.no> <003201c0b7da$7576fe20$0500000a@hph> Message-ID: <004f01c0b7e1$4f9085d0$0500000a@hph> With reference to my previous mails on the topic Subject: Re: Management of the working group I hereby call for nominations to wg-chair and co-chairs. Please nominate yourself to lir-wg at ripe.net. If nominated by somebody else, the candidate needs to accept the nomination. Nominations accepted all the way until the election at the next meeting. Best Regards, Hans Petter Holen lir-wg Chair From stephenb at uk.uu.net Thu Mar 29 16:00:23 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 29 Mar 2001 14:00:23 +0000 Subject: New Proposal Message-ID: <3AC33FF7.CC19D3EB@uk.uu.net> Hi I would like to here your comments on the following proposal. After being in an audit and getting a list as long as my arm of broken objects in the DB it turned out that the majority of the objects where pre RIPE and not subject to the same checks. I therefore propose that all inetnums without a status (being pre-RIPE there is no status) should be marked with a new status of PR (Pre RIPE) and therefore be ignored by an audit tool. Also all other objects prior to ripe should be flagged so as to be ingnored in an audit, making it much easier to see what really needs fixing. Your thoughts and comments please. -- ------------------------------------------------------------------------ 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 ncc at ripe.net Thu Mar 29 15:49:50 2001 From: ncc at ripe.net (RIPE NCC Staff) Date: Thu, 29 Mar 2001 15:49:50 +0200 Subject: Routing Workshop Message-ID: <200103291349.PAA29911@office.ripe.net> CALL FOR APPLICATIONS Routing Workshop, Amsterdam, The Netherlands, 7-11 May 2001 Dear Colleagues, A Routing Workshop will be provided for RIPE NCC staff on 7-11 May 2001 in Amsterdam, The Netherlands by Cisco Systems. This is a call for applications for 14 places still available in the workshop. This workshop will be provided free of charge and includes lunches. PLEASE NOTE: Travel and accommodation are not provided or reimbursed. Who should Attend: The target audience for this course is persons in the ISP community with a basic familiarity of Cisco Systems equipment. This is a technical workshop and most suitable for those persons who are now or will soon be building or operating a wide area TCP/IP base Internet Service Provider (ISP) network or Internet eXchange Point (IXP) with international and/or multi-provider connectivity. Prerequisites: Cisco IOS fundamentals; user level UNIX and possibly some system administration and; some use of network design, preferably TCP/IP based. * Preference for this course will be given to those individuals that come from developing countries (i.e. Central Europe, Central Asia, Africa and The Middle East) Cisco Systems will select 14 participants to attend the tutorial based on the information provided in the application form enclosed below. WORKSHOP SCOPE: --------------- - Techniques for design, set-up, and operation of a metropolitan, regional or national ISP backbone network. This includes advanced OSPF, BGP4 and policy based routing. - IOS Essentials every ISP should be doing. The hidden secrets that all key NSPs have been using for years but not telling anyone (ie: competitive advantage. - Techniques for multiple connections to the Internet (multihoming), including connections to IXPs, NSP and transoceanic Internet links. - Techniques for the design, set-up and operation of a metropolitan, regional or national IXPs - Techniques to achieve optimal performance and configuration from a Cisco backbone router. This includes routing scalability, network design and configuration techniques. - Examples from a case study from successful ISPs who are making use of many of the workshop techniques. COURSE LOCATION: --------------- The course will take place at The Groot Industrieele Club, Dam 27, Amsterdam, The Netherlands The instructors for the Workshop will be Philip Smith and Duncan Rogerson. IMPORTANT DATES: --------------- * The deadline for application submissions: 11 April 2001. * Acceptance notification to selected candidates: 16 April 2001 * Routing Workshop - 7-11 May 2001 For further information about the Cisco ISP workshop please contact: Joao Silva Damas Chief Technical Officer RIPE NCC E-mail: joao at ripe.net ====== ROUTING WORKSHOP - APPLICATION FORM * Please submit your application form by email to with the following text as the subject: Routing Workshop First Name: Last Name: Nationality: Contact Information: - postal address: - Tel/Fax number: - email address: CV detailing ISP experience [max 200 words]: ====== From stephenb at uk.uu.net Thu Mar 29 17:45:48 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 29 Mar 2001 15:45:48 +0000 Subject: New Proposal References: <3AC33FF7.CC19D3EB@uk.uu.net> <20010329161457.I3676@Space.Net> Message-ID: <3AC358AC.40F65C45@uk.uu.net> "Gert Doering, Netmaster" wrote: > > Hi, > > On Thu, Mar 29, 2001 at 02:00:23PM +0000, Stephen Burley wrote: > > and not subject to the same checks. I therefore propose that all > > inetnums without a status (being pre-RIPE there is no status) should be > > marked with a new status of PR (Pre RIPE) and therefore be ignored by an > > audit tool. Also all other objects prior to ripe should be flagged so as > > to be ingnored in an audit, making it much easier to see what really > > needs fixing. > > I see your reasoning - but shouldn't all those "Pre RIPE" be fixed some > day? The sooner, the better? > > So for the sake of database quality, I'd vote against your proposal. Yes, > it generates work, and more so for the "good guys" (who have been around > for ages), but I consider it as important to get rid of the old cruft, > or make sure the database entries are correct. But how can you apply RIPE rules to the objects when the objects existed before the rules applied. Surley this would be a way of fixing the porblem? We can not retroactivly apply rules when the rules did not apply so they should be marked as special in some way, to exempt them from the current ruleset. How can you fix them when they do not need fixing as they are not broke, and saying they are broke because they do not fit our criteria now, does not make them broke. I would rather they be marked as exempt, then we can fix them by ignoring them in various processes or including them in special cases. > > Gert Doering > -- NetMaster > -- > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 -- ------------------------------------------------------------------------ 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 zsako at banknet.net Thu Mar 29 16:33:23 2001 From: zsako at banknet.net (Janos Zsako) Date: Thu, 29 Mar 2001 16:33:23 +0200 (MET DST) Subject: New Proposal Message-ID: <200103291433.QAA12092@banknet.banknet.net> > From owner-lir-wg at ripe.net Thu Mar 29 14:42:22 2001 > From: Stephen Burley Stephen, > I would like to here your comments on the following proposal. After > being in an audit and getting a list as long as my arm of broken objects > in the DB it turned out that the majority of the objects where pre RIPE > and not subject to the same checks. I therefore propose that all > inetnums without a status (being pre-RIPE there is no status) should be > marked with a new status of PR (Pre RIPE) and therefore be ignored by an > audit tool. Also all other objects prior to ripe should be flagged so as > to be ingnored in an audit, making it much easier to see what really > needs fixing. I think the idea of marking such inetnums is very good. I am just wondering whether "no status" really means "pre RIPE". I suspect it is not the case, as Daniel's document was discussed on the mailing list in May 1995 (and is dated 30 June 0995), while RIPE NCC did perform allocations much earlier as far as I remember. So my point is that the term "pre RIPE" may be misleading. What about "status: UK"? (UK for UnKnown :)) ) Janos From stephenb at uk.uu.net Thu Mar 29 18:01:08 2001 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 29 Mar 2001 16:01:08 +0000 Subject: New Proposal References: <200103291433.QAA12092@banknet.banknet.net> Message-ID: <3AC35C44.7737EFDF@uk.uu.net> Janos Zsako wrote: > > > From owner-lir-wg at ripe.net Thu Mar 29 14:42:22 2001 > > From: Stephen Burley > > Stephen, > > > I would like to here your comments on the following proposal. After > > being in an audit and getting a list as long as my arm of broken objects > > in the DB it turned out that the majority of the objects where pre RIPE > > and not subject to the same checks. I therefore propose that all > > inetnums without a status (being pre-RIPE there is no status) should be > > marked with a new status of PR (Pre RIPE) and therefore be ignored by an > > audit tool. Also all other objects prior to ripe should be flagged so as > > to be ingnored in an audit, making it much easier to see what really > > needs fixing. > > I think the idea of marking such inetnums is very good. > > I am just wondering whether "no status" really means "pre RIPE". > I suspect it is not the case, as Daniel's document was discussed > on the mailing list in May 1995 (and is dated 30 June 0995), while > RIPE NCC did perform allocations much earlier as far as I remember. But in a classful enviroment. I agree "no status" does not always mean pre-RIPE but "no status" and an intial date before RIPE interaction does. (Date to be decided by the community) > > So my point is that the term "pre RIPE" may be misleading. > > What about "status: UK"? (UK for UnKnown :)) ) UK = United Kingdom What about CA = Classful Allocation > > Janos -- ------------------------------------------------------------------------ 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 zsako at banknet.net Thu Mar 29 17:02:44 2001 From: zsako at banknet.net (Janos Zsako) Date: Thu, 29 Mar 2001 17:02:44 +0200 (MET DST) Subject: New Proposal Message-ID: <200103291502.RAA12388@banknet.banknet.net> > From owner-lir-wg at ripe.net Thu Mar 29 16:39:45 2001 > To: Janos Zsako Stephen, > > I am just wondering whether "no status" really means "pre RIPE". > > I suspect it is not the case, as Daniel's document was discussed > > on the mailing list in May 1995 (and is dated 30 June 0995), while > > RIPE NCC did perform allocations much earlier as far as I remember. > > But in a classful enviroment. Correct. > > So my point is that the term "pre RIPE" may be misleading. > > > > What about "status: UK"? (UK for UnKnown :)) ) > > UK = United Kingdom Sure, this is why I put the smiley there. > What about CA = Classful Allocation Yes, this may be the right term, although it is not strictly related to this (if inetnum has status attribute it does not mean it is a classless allocation or assignment as classful allocations and assignments continued for another year or so after ripe-127 was published). "No status" means pre-ripe-136, dated May 1996 (as this is the document that made the status attribute mandatory) and classless assignments did start only after ripe-136 indeed, as far as I remember. Janos From chapuis at ip-plus.net Thu Mar 29 17:45:49 2001 From: chapuis at ip-plus.net (Andre Chapuis) Date: Thu, 29 Mar 2001 17:45:49 +0200 Subject: New Proposal References: <3AC33FF7.CC19D3EB@uk.uu.net> Message-ID: <044b01c0b867$547e9ce0$1d57fea9@ipplus.net> Hi Stephen, I did it in the last 2 months: adding ASSIGNED PI to every block is not a big job, and at least the audit tool will produce no errors, except for the asm window, which in my opinion should be set to infinite for these Allocated Unspecified blocks. Andr? ----- Original Message ----- From: "Stephen Burley" To: Sent: Thursday, March 29, 2001 4:00 PM Subject: New Proposal Hi I would like to here your comments on the following proposal. After being in an audit and getting a list as long as my arm of broken objects in the DB it turned out that the majority of the objects where pre RIPE and not subject to the same checks. I therefore propose that all inetnums without a status (being pre-RIPE there is no status) should be marked with a new status of PR (Pre RIPE) and therefore be ignored by an audit tool. Also all other objects prior to ripe should be flagged so as to be ingnored in an audit, making it much easier to see what really needs fixing. Your thoughts and comments please. -- ------------------------------------------------------------------------ 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 andrei at ripe.net Thu Mar 29 18:09:41 2001 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 29 Mar 2001 18:09:41 +0200 Subject: Another issue related to the migration Message-ID: <3AC35E45.2A2659CA@ripe.net> Dear Colleagues, [Apologies for duplicate messages] One issue related to RIPE-181 to RPSL migration escaped our attention and has not been discussed. It is related to reserved prefixes that cannot appear in object names according to RPSL specification (RFC2622) which says: "Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names." Unfortunately "as-name:" attribute is an object name in RPSL and we have 133 aut-num objects with as-name starting with reserved 'AS-' prefix. Our suggestion how to deal with these objects is: 1. Send a message to the maintainers of these objects asking them to change the name to avoid conflict with RPSL specification. 2. Give two-week notice period after which ripe-dbm will convert non compliant as-names using the following mapping: AS-ASNAME -> AS_ASNAME. This is more a "cosmetic" change as as-name is not even a lookup key in the RIPE Database. Your comments and suggestions are appreciated. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC From michael.hallgren at teleglobe.com Thu Mar 29 18:25:00 2001 From: michael.hallgren at teleglobe.com (Hallgren, Michael) Date: Thu, 29 Mar 2001 17:25:00 +0100 Subject: Another issue related to the migration Message-ID: Hi, > > > Dear Colleagues, [...] > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. Yes. Agree. Been hinting customers to trash/modify such names prior to migration date - not knowing whether or not such conflict would be treated auto-magically... Regards Michael > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC > -- Michael Hallgren, Eng., Teleglobe, MH2198-RIPE From hph at online.no Thu Mar 29 18:55:50 2001 From: hph at online.no (Hans Petter Holen) Date: Thu, 29 Mar 2001 18:55:50 +0200 Subject: New Proposal References: <3AC33FF7.CC19D3EB@uk.uu.net> Message-ID: <003801c0b871$1c1ea700$0500000a@hph> ----- Original Message ----- From: "Stephen Burley" To: Sent: Thursday, March 29, 2001 4:00 PM Subject: New Proposal | I therefore propose that all | inetnums without a status (being pre-RIPE there is no status) should be | marked with a new status of PR (Pre RIPE) Good idea. | and therefore be ignored by an | audit tool. Also all other objects prior to ripe should be flagged so as | to be ingnored in an audit, making it much easier to see what really | needs fixing. At least for a while, while we launch a community effort to clean up this information in a way that makes it auditable (perhaps under somewhat different rules than objects entered under newer policies) -hph From neil at COLT.NET Thu Mar 29 15:25:10 2001 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 29 Mar 2001 14:25:10 +0100 (BST) Subject: New Proposal In-Reply-To: <3AC33FF7.CC19D3EB@uk.uu.net> from Stephen Burley at "Mar 29, 2001 02:00:23 pm" Message-ID: <200103291325.OAA19123@NetBSD.noc.COLT.NET> > Hi > I would like to here your comments on the following proposal. After > being in an audit and getting a list as long as my arm of broken objects > in the DB it turned out that the majority of the objects where pre RIPE > and not subject to the same checks. I therefore propose that all > inetnums without a status (being pre-RIPE there is no status) should be > marked with a new status of PR (Pre RIPE) and therefore be ignored by an > audit tool. Also all other objects prior to ripe should be flagged so as > to be ingnored in an audit, making it much easier to see what really > needs fixing. > I'd agree with this. Neil. From netmaster at space.net Thu Mar 29 16:14:57 2001 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 29 Mar 2001 16:14:57 +0200 Subject: New Proposal In-Reply-To: <3AC33FF7.CC19D3EB@uk.uu.net>; from stephenb@uk.uu.net on Thu, Mar 29, 2001 at 02:00:23PM +0000 References: <3AC33FF7.CC19D3EB@uk.uu.net> Message-ID: <20010329161457.I3676@Space.Net> Hi, On Thu, Mar 29, 2001 at 02:00:23PM +0000, Stephen Burley wrote: > and not subject to the same checks. I therefore propose that all > inetnums without a status (being pre-RIPE there is no status) should be > marked with a new status of PR (Pre RIPE) and therefore be ignored by an > audit tool. Also all other objects prior to ripe should be flagged so as > to be ingnored in an audit, making it much easier to see what really > needs fixing. I see your reasoning - but shouldn't all those "Pre RIPE" be fixed some day? The sooner, the better? So for the sake of database quality, I'd vote against your proposal. Yes, it generates work, and more so for the "good guys" (who have been around for ages), but I consider it as important to get rid of the old cruft, or make sure the database entries are correct. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jhma at KPNQwest.net Thu Mar 29 17:22:41 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Thu, 29 Mar 2001 17:22:41 +0200 Subject: Call for nominations for lir-wg chair and co-chairs In-Reply-To: Your message of "Thu, 29 Mar 2001 01:46:24 +0200." <004f01c0b7e1$4f9085d0$0500000a@hph> Message-ID: <200103291522.RAA18926@aegir.EU.net> "Hans Petter Holen" wrote: > With reference to my previous mails on the topic > Subject: Re: Management of the working group > I hereby call for nominations to wg-chair and co-chairs. > > Please nominate yourself to lir-wg at ripe.net. > > If nominated by somebody else, the candidate needs to > accept the nomination. I'd like to nominate Hans Petter Holen for wg-chair. James From phil.duffen at uk.easynet.net Thu Mar 29 17:13:07 2001 From: phil.duffen at uk.easynet.net (Phil Duffen) Date: Thu, 29 Mar 2001 16:13:07 +0100 Subject: New Proposal In-Reply-To: <200103291433.QAA12092@banknet.banknet.net>; from zsako@banknet.net on Thu, Mar 29, 2001 at 04:33:23PM +0200 References: <200103291433.QAA12092@banknet.banknet.net> Message-ID: <20010329161307.E54724@pavilion.net> On Thu, Mar 29, 2001 at 04:33:23PM +0200, Janos Zsako wrote: > > What about "status: UK"? (UK for UnKnown :)) ) > > Janos UK - United Kingdom -- ------------------------------------------------------- P h i l D u f f e n S y s t e m s M a n a g e r t e l +44 (0)845 333 5000 f a x +44 (0)845 333 5001 e - m a i l phil.duffen at uk.easynet.net ------------------------------------------------------- From jhma at KPNQwest.net Thu Mar 29 18:05:54 2001 From: jhma at KPNQwest.net (James Aldridge) Date: Thu, 29 Mar 2001 18:05:54 +0200 Subject: New Proposal In-Reply-To: Your message of "Thu, 29 Mar 2001 16:01:08 -0000." <3AC35C44.7737EFDF@uk.uu.net> Message-ID: <200103291605.SAA19169@aegir.EU.net> > > UK = United Kingdom > > What about CA = Classful Allocation CA = Canada ;-) For allocations we've already got 'PA', 'PI' and 'UNSPECIFIED' but only 'PA' or 'PI' for assignments. Why not use the "missing" combination 'ASSIGNED UNSPECIFIED' to "document past allocations with assignments of both types or unknown type"? For most purposes this would have to be treated as being the same as 'ASSIGNED PI' but would allow documentation of such historical entries where it's needed. James From plu at cw.net Thu Mar 29 19:37:34 2001 From: plu at cw.net (Lu, Ping) Date: Thu, 29 Mar 2001 12:37:34 -0500 Subject: Another issue related to the migration Message-ID: Andrei, The existing ripe2rpsl tool will automatically translate "AS-" to "ASN-" for the aut-num object and I think "ASN-" is more meaningful than "AS_". Best Regards. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Andrei Robachevsky [mailto:andrei at ripe.net] > Sent: Thursday, March 29, 2001 11:10 AM > To: db-wg at ripe.net; routing-wg at ripe.net; Migration TF; lir-wg at ripe.net > Subject: Another issue related to the migration > > > Dear Colleagues, > > [Apologies for duplicate messages] > > One issue related to RIPE-181 to RPSL migration escaped our > attention and has > not been discussed. It is related to reserved prefixes that > cannot appear in > object names according to RPSL specification (RFC2622) which says: > > "Names starting with certain prefixes are reserved for > certain object types. > Names starting with "as-" are reserved for as set names. > Names starting with > "rs-" are reserved for route set names. Names starting with > "rtrs-" are > reserved for router set names. Names starting with "fltr-" > are reserved for > filter set names. Names starting with "prng-" are reserved > for peering set > names." > > Unfortunately "as-name:" attribute is an object name in RPSL > and we have 133 > aut-num objects with as-name starting with reserved 'AS-' prefix. > > Our suggestion how to deal with these objects is: > > 1. Send a message to the maintainers of these objects asking > them to change the > name to avoid conflict with RPSL specification. > 2. Give two-week notice period after which ripe-dbm will > convert non compliant > as-names using the following mapping: AS-ASNAME -> AS_ASNAME. > > This is more a "cosmetic" change as as-name is not even a > lookup key in the RIPE > Database. > > Your comments and suggestions are appreciated. > > Best regards, > > > Andrei Robachevsky > DB Group Manager > RIPE NCC > From db-news at ripe.net Fri Mar 30 12:39:57 2001 From: db-news at ripe.net (DB-News) Date: Fri, 30 Mar 2001 12:39:57 +0200 Subject: RIPE Database Software V3.0 compliance test. Message-ID: <200103301039.MAA29575@office.ripe.net> Dear Colleagues, If you have software that works with RIPE Database Software, then you should make sure that it works with Version 3.0, which will be put into production next month. Compliance tests are available at: http://www.ripe.net/ripencc/pub-services/db/rpsl/usercl.html More information about Version 3.0 of the RIPE Database Software and how it will affect you is available at: http://www.ripe.net/rpsl/ If you have any questions, please contact . Regards, A. M. R. Magee -------------- Database Group RIPE NCC