From kurtis at kurtis.pp.se Thu Aug 1 09:47:38 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 01 Aug 2002 09:47:38 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020731155138.GA3592@ripe.net> References: <20020731155138.GA3592@ripe.net> Message-ID: <29770000.1028188058@laptop.kurtis.pp.se> IMHO : > 1. Should the RIPE NCC check whether Autonomous System Numbers > it has assigned become multi-homed within six months? If you > would like us to do this, the RIPE NCC proposes to do so by > looking at routing policies registered in the Routing Registry. yes, AND to real announcements. > 2. Should the policy be changed so that AS numbers not in use > can be reclaimed? If there is consensus on this we propose > to reclaim AS numbers of networks not multi-homed after six > months. Well, maybe a bot more stepwise approach. Say you check after three and six months. Each time asking for an explanation. If no valid one is given (for some definition of valid) reclaim it. If after 9 months, the AS is still not mulithomed, reclaim. Month spacing may be argued. Best regards, - kurtis - From wtremmel at vianetworks.com Thu Aug 1 09:53:20 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Thu, 1 Aug 2002 09:53:20 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020731155138.GA3592@ripe.net> Message-ID: > 1. Should the RIPE NCC check whether Autonomous System Numbers > it has assigned become multi-homed within six months? If you > would like us to do this, the RIPE NCC proposes to do so by > looking at routing policies registered in the Routing Registry. yes. > > 2. Should the policy be changed so that AS numbers not in use > can be reclaimed? If there is consensus on this we propose > to reclaim AS numbers of networks not multi-homed after six > months. yes best regards, Wolfgang From peter.galbavy at knowtion.net Thu Aug 1 10:09:21 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 1 Aug 2002 09:09:21 +0100 Subject: [lir-wg] AS Number Policy - continued References: <5.1.0.14.2.20020801081728.01013e58@max.att.net.il> Message-ID: <014201c23932$beb05390$2728a8c0@carpenter> > >2. Should the policy be changed so that AS numbers not in use > > can be reclaimed? If there is consensus on this we propose > > to reclaim AS numbers of networks not multi-homed after six > > months. Sorry - i accidentally deleted the original mail, so I am replying to a reply. Point 2 above asks one question and then proposes an answer to something completely different. I *know* that this discussion has gone on, but I still state that an *unused* AS is not the same as one which is not *multihomed*. Point 2 is a very political-debate type of question / answer. Can we please have some clarity and definitions instead ? Peter From av at nethead.de Thu Aug 1 10:03:25 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 01 Aug 2002 10:03:25 +0200 Subject: [lir-wg] AS Number Policy - continued References: <20020731155138.GA3592@ripe.net> <29770000.1028188058@laptop.kurtis.pp.se> Message-ID: <3D48EB4D.C63309F8@nethead.de> Kurt Erik Lindqvist wrote: > > IMHO : > > > 1. Should the RIPE NCC check whether Autonomous System Numbers > > it has assigned become multi-homed within six months? If you > > would like us to do this, the RIPE NCC proposes to do so by > > looking at routing policies registered in the Routing Registry. > > yes, AND to real announcements. i second that. > > 2. Should the policy be changed so that AS numbers not in use > > can be reclaimed? If there is consensus on this we propose > > to reclaim AS numbers of networks not multi-homed after six > > months. I suggest revoking as-numbers from isps not using their as number for a period of 12 months. I personally know some isps which _never_ used the as-number assigned to them. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From hank at att.net.il Thu Aug 1 07:18:12 2002 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 01 Aug 2002 08:18:12 +0300 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020731155138.GA3592@ripe.net> Message-ID: <5.1.0.14.2.20020801081728.01013e58@max.att.net.il> At 05:51 PM 31-07-02 +0200, leo vegoda wrote: >Dear Colleagues, > >Thank you for your comments on my initial questions and the >wide ranging discussion that took place. > >I would like to continue this discussion by asking two more >questions: > >1. Should the RIPE NCC check whether Autonomous System Numbers > it has assigned become multi-homed within six months? If you Yes. > would like us to do this, the RIPE NCC proposes to do so by > looking at routing policies registered in the Routing Registry. Or any other method agreed upon. >2. Should the policy be changed so that AS numbers not in use > can be reclaimed? If there is consensus on this we propose > to reclaim AS numbers of networks not multi-homed after six > months. Yes. -Hank >Kind regards, > >-- >leo vegoda >RIPE NCC >Registration Services From s.willing at mops.net Thu Aug 1 11:38:19 2002 From: s.willing at mops.net (Sebastian Willing) Date: Thu, 1 Aug 2002 11:38:19 +0200 (CEST) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <3D48EB4D.C63309F8@nethead.de> from "Arnd Vehling" at Aug 01, 2002 10:03:25 AM Message-ID: <200208010938.LAA11546@mara.mops.net> Hello! Arnd Vehling wrote: [...] > > > 2. Should the policy be changed so that AS numbers not in use > > > can be reclaimed? If there is consensus on this we propose > > > to reclaim AS numbers of networks not multi-homed after six > > > months. > > I suggest revoking as-numbers from isps not using their as number for > a period of 12 months. > > I personally know some isps which _never_ used the as-number assigned > to them. I'ld suggest to first use all AS-# allocated to RIPE. Then re-use the AS-# which has the oldest revoke-date (but only if this date is older than one year or so). Sebastian -- ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing at mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************ From ripe-ml at cyberstrider.net Thu Aug 1 11:44:13 2002 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Thu, 1 Aug 2002 10:44:13 +0100 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <014201c23932$beb05390$2728a8c0@carpenter> Message-ID: <20020801082248.GJ1431@cyberstrider.net> On Thu, Aug 01, 2002 at 09:09:21AM +0100, Peter Galbavy wrote: > I *know* that this discussion has gone on, but I still state that an > *unused* AS is not the same as one which is not *multihomed*. Agreed. Denesh -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net Nominet PAB Member ; co-Chair RIPE LIR-WG From denesh at cyberstrider.net Thu Aug 1 10:22:48 2002 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Thu, 1 Aug 2002 09:22:48 +0100 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <014201c23932$beb05390$2728a8c0@carpenter> References: <5.1.0.14.2.20020801081728.01013e58@max.att.net.il> <014201c23932$beb05390$2728a8c0@carpenter> Message-ID: <20020801082248.GJ1431@cyberstrider.net> On Thu, Aug 01, 2002 at 09:09:21AM +0100, Peter Galbavy wrote: > I *know* that this discussion has gone on, but I still state that an > *unused* AS is not the same as one which is not *multihomed*. Agreed. Denesh -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net Nominet PAB Member ; co-Chair RIPE LIR-WG From av at nethead.de Thu Aug 1 14:38:16 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 01 Aug 2002 14:38:16 +0200 Subject: [lir-wg] AS Number Policy - continued References: <200208010938.LAA11546@mara.mops.net> Message-ID: <3D492BB8.E9585F2D@nethead.de> Sebastian Willing wrote: > > I'ld suggest to first use all AS-# allocated to RIPE. Then re-use the AS-# > which has the oldest revoke-date (but only if this date is older than one year > or so). Thats an good suggestion too. I dont know if this is out-of-scope of this discussion, but i would suggest that a LIR, which applies for an AS-Num, should be required to fax a written peering agreement signed by at least 2 upstream-providers. This should reduce the the number of initialy unused as-nos somewhat. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From peter.galbavy at knowtion.net Thu Aug 1 14:44:07 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 1 Aug 2002 13:44:07 +0100 Subject: [lir-wg] AS Number Policy - continued References: <200208010938.LAA11546@mara.mops.net> <3D492BB8.E9585F2D@nethead.de> Message-ID: <01e801c23959$20c1ce80$2728a8c0@carpenter> > I dont know if this is out-of-scope of this discussion, but i would suggest > that a LIR, which applies for an AS-Num, should be required to fax a written > peering agreement signed by at least 2 upstream-providers. Erm, I suspect that the regulatory organisation might get interested in this kind of policy. And why peering, most upstream services are not 'peering' but paid for transit. You say that my business should depend on the 'kindness' of my service provider filling in a form ? In general, small providers are in a better position to buy BGP transit services when they already >have< and AS and IP space. If you go to a large upstream they will try to cross-sell you away from BGP transit in order to lock you in to themselves. Peter From s.willing at mops.net Thu Aug 1 14:51:42 2002 From: s.willing at mops.net (Sebastian Willing) Date: Thu, 1 Aug 2002 14:51:42 +0200 (CEST) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <3D492BB8.E9585F2D@nethead.de> from "Arnd Vehling" at Aug 01, 2002 02:38:16 PM Message-ID: <200208011251.OAA23308@mara.mops.net> Hello! Arnd Vehling wrote: [...] > I dont know if this is out-of-scope of this discussion, but i would suggest > that a LIR, which applies for an AS-Num, should be required to fax a written > peering agreement signed by at least 2 upstream-providers. > > This should reduce the the number of initialy unused as-nos somewhat. When starting as a LIR, you don't always have your upstreams. When we applied for LIR status we had two upstreams handy, with signed contracts and everything. At the time we finally got our AS, one of the upstreams was no longer existent. Today, providers, LIRs and upstreams come and go so fast. To keep the administrative overhead small, I'ld suggest to let the new AS- owner show at least two agreements within "x" month after the assignment of the AS-# only if there are less than two verified peerings. I'ld see a verified peering as a record in both AS's whois-entry _and_ seen on the RIPE BGP-router (or on some other "neutral" point, like EP routers). Sebastian -- ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing at mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************ From av at nethead.de Thu Aug 1 14:57:32 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 01 Aug 2002 14:57:32 +0200 Subject: [lir-wg] AS Number Policy - continued References: <200208011251.OAA23308@mara.mops.net> Message-ID: <3D49303C.943621B3@nethead.de> Hi, Sebastian Willing wrote: > When starting as a LIR, you don't always have your upstreams. When we applied > for LIR status we had two upstreams handy, with signed contracts and everything. > At the time we finally got our AS, one of the upstreams was no longer existent. > Today, providers, LIRs and upstreams come and go so fast. Sure, becoming a LIR and obtaining an AS-Number are two very different things. You dont need to be a LIR to get an AS-Number. You can apply for an AS-Number as soon as you have routeable ip-space and 2 upstreams for BGP4 peering. (Please correct me if they did change that recently) > To keep the administrative overhead small, I'ld suggest to let the new AS- > owner show at least two agreements within "x" month after the assignment of > the AS-# only if there are less than two verified peerings. I'ld see a > verified peering as a record in both AS's whois-entry _and_ seen on the RIPE > BGP-router (or on some other "neutral" point, like EP routers). If the RIPE will check for active announcements of AS-Nums there is no real need for a written proof for the BGP4-upstreams, thats right. But IMO, the rquirement of a written verification will cut down the number of as-numbers which will get revoked later on. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From woeber at cc.univie.ac.at Thu Aug 1 15:07:55 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Aug 2002 15:07:55 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <00A11CF5.ADA3EA1A.11@cc.univie.ac.at> >Sure, becoming a LIR and obtaining an AS-Number are two very different things. >You dont need to be a LIR to get an AS-Number. You can apply for an AS-Number >as soon as you have routeable ip-space and 2 upstreams for BGP4 peering. >(Please correct me if they did change that recently) > To keep the administrative overhead small, I'ld suggest to let the new AS- > owner show at least two agreements within "x" month after the assignment of > the AS-# only if there are less than two verified peerings. I'ld see a > verified peering as a record in both AS's whois-entry _and_ seen on the RIPE > BGP-router (or on some other "neutral" point, like EP routers). ripe-227 (asnrequestform), issued 1 Octboer 2001 requires an "X-NCC-RegID:" I do not recall when exactly the NCC stopped to work on ((PI-)IP-Adress and AS Number) requests from Non-LIRs. It's been a while :-) Wilfried. From peter.galbavy at knowtion.net Thu Aug 1 15:00:23 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 1 Aug 2002 14:00:23 +0100 Subject: [lir-wg] AS Number Policy - continued References: <200208010938.LAA11546@mara.mops.net> <3D492BB8.E9585F2D@nethead.de> <01e801c23959$20c1ce80$2728a8c0@carpenter> <3D492EDC.6A759940@nethead.de> Message-ID: <020001c2395b$664aa3d0$2728a8c0@carpenter> > Doesnt your business depend on your upstreams signing contracts about > transit with you and providing the agreed service? If an ISP sells > transit to you he will also be able to sign a simple form stating that you > will have a BGP4 Session with him. Therefore i dont c where the requirement > of a signed "bgp4 session with transit" agreement will have a bad impact > on business. Most contracts are commercially confidential and also sensitive. I do not expect either myself of my customers or suppliers to provide this to RIPE 'just because'. Also, we should collectively remember that each country the RIPE operates in may have different legal requirements and regulatory frameworks. Most of the EU is similar, but as an anecdote, I believe RIPE still requires a 'chamber of commerce' certificate ? That only makes sense in the Netherlands and maybe a couple of other countries. In the UK, for example, there is no legal requirement to register as a 'company' before trading - you just get on with it. Try to convince a hidebound beaurocrat stuck in a small office on Singel that though. Why should RIPE dictate my local business decisions ? Peter From av at nethead.de Thu Aug 1 15:19:11 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 01 Aug 2002 15:19:11 +0200 Subject: [lir-wg] AS Number Policy - continued References: <200208010938.LAA11546@mara.mops.net> <3D492BB8.E9585F2D@nethead.de> <01e801c23959$20c1ce80$2728a8c0@carpenter> <3D492EDC.6A759940@nethead.de> <020001c2395b$664aa3d0$2728a8c0@carpenter> Message-ID: <3D49354F.B016FAD1@nethead.de> Hi, Peter Galbavy wrote: > Most contracts are commercially confidential and also sensitive. I do not > expect either myself of my customers or suppliers to provide this to RIPE > 'just because'. Me neither. I never said that anyone should copies of the contracts to the RIPE. I did mean a simple form like: ----------- 8< ----------------- 8< -------------------- 8< --------------- Lir: eu.newlir Will receive ip-transit and BGP4-Peering from the follwing ISPs within X Months: ISP-A ISP-B Signature Signature --------- ---------- ----------- 8< ----------------- 8< -------------------- 8< --------------- I hope you get what i mean. > Also, we should collectively remember that each country the RIPE operates in > may have different legal requirements and regulatory frameworks. Most of the > EU is similar, but as an anecdote, I believe RIPE still requires a 'chamber > of commerce' certificate ? As far as i remember they require _some_ formal writtem paper about the jurisdictional existance of a company which wants to become a LIR. The "chamber of commerce" certificate is AFAIK not neccessary. You can even get away without any certificate i think. > [..] Try to convince a hidebound beaurocrat stuck in a small office on Singel > that though. Why should RIPE dictate my local business decisions ? I fail to c where this really hinders your business. On the other hand i can really understand that you want to keep the formal, bureaucratic stuff like signed forms low :) This proposal just came out of my experiences while working with or for various ISPs in Europe where i often noticed that ISPs obtained AS-Nums allthough they didnt needed them then, and most of them dont use them today. All they hear is that the AS-Number supply is limted, AS-Numbers are for free => and they are out to get one => Results in unused AS-Numbers. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From av at nethead.de Thu Aug 1 15:23:19 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 01 Aug 2002 15:23:19 +0200 Subject: [lir-wg] AS Number Policy - continued References: <00A11CF5.ADA3EA1A.11@cc.univie.ac.at> Message-ID: <3D493647.EB09FDFC@nethead.de> "Wilfried Woeber, UniVie/ACOnet" wrote: > Arnd Vehling wrote > >Sure, becoming a LIR and obtaining an AS-Number are two very different things. > >You dont need to be a LIR to get an AS-Number. You can apply for an AS-Number > >as soon as you have routeable ip-space and 2 upstreams for BGP4 peering. > >(Please correct me if they did change that recently) > > ripe-227 (asnrequestform), > issued 1 Octboer 2001 > requires an "X-NCC-RegID:" > > I do not recall when exactly the NCC stopped to work on ((PI-)IP-Adress > and AS Number) requests from Non-LIRs. It's been a while :-) This means you can only send in an asn-request if youre LIR, thats right, but i did send in several asn-requests on behalf of customers when i worked for a german ISP from 96-98. There is no relation between getting an AS-Num and beeing a LIR AFAIK. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From thinman at clp.cw.net Thu Aug 1 14:59:18 2002 From: thinman at clp.cw.net (Tanya Hinman) Date: Thu, 1 Aug 2002 08:59:18 -0400 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020731155138.GA3592@ripe.net> Message-ID: >1. Should the RIPE NCC check whether Autonomous System Numbers it has assigned become multi-homed within six months? If you would like us to do this, the RIPE NCC proposes to do so by looking at routing policies registered in the Routing Registry. Yes >2. Should the policy be changed so that AS numbers not in use can be reclaimed? If there is consensus on this we propose to reclaim AS numbers of networks not multi-homed after six months. If we contact our customers and they have not started using the ASN but do intend to use it at a specified time, then we should check back with them and verify that they start using it at that time. Of course there should be a limit to the time period. The ASN should be reclaimed if it is found that the company does not intend to use them within the next six months (1 year total). This will decrease the workload on the RIPE NCC as well as the company or LIR requesting the ASN in the event that the ASN is reclaimed but the customer did have plans to use it within the year. Many companies' plans are constantly changing and projects are postponed, thus making it difficult to reclaim ASN's within everyone else's timeframe. Regards, Tanya From av at nethead.de Thu Aug 1 14:51:40 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 01 Aug 2002 14:51:40 +0200 Subject: [lir-wg] AS Number Policy - continued References: <200208010938.LAA11546@mara.mops.net> <3D492BB8.E9585F2D@nethead.de> <01e801c23959$20c1ce80$2728a8c0@carpenter> Message-ID: <3D492EDC.6A759940@nethead.de> Peter Galbavy wrote: > > > I dont know if this is out-of-scope of this discussion, but i would > suggest > > that a LIR, which applies for an AS-Num, should be required to fax a > written > > peering agreement signed by at least 2 upstream-providers. > > Erm, I suspect that the regulatory organisation might get interested in this > kind of policy. And why peering, most upstream services are not 'peering' > but paid for transit. I menat that in the traditional meaning of a BGP4-Session. But youre right, its a transit agreement. > You say that my business should depend on the > 'kindness' of my service provider filling in a form ? Doesnt your business depend on your upstreams signing contracts about transit with you and providing the agreed service? If an ISP sells transit to you he will also be able to sign a simple form stating that you will have a BGP4 Session with him. Therefore i dont c where the requirement of a signed "bgp4 session with transit" agreement will have a bad impact on business. > In general, small > providers are in a better position to buy BGP transit services when they > already >have< and AS and IP space. If you go to a large upstream they will > try to cross-sell you away from BGP transit in order to lock you in to > themselves. Sure, the bug upstream dont want you to become an independant AS. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From ripe-ml at cyberstrider.net Thu Aug 1 15:38:07 2002 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Thu, 1 Aug 2002 14:38:07 +0100 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <3D492BB8.E9585F2D@nethead.de> References: <200208010938.LAA11546@mara.mops.net> <3D492BB8.E9585F2D@nethead.de> Message-ID: <20020801133807.GB17218@cyberstrider.net> On Thu, Aug 01, 2002 at 02:38:16PM +0200, Arnd Vehling wrote: > I dont know if this is out-of-scope of this discussion, but i would suggest > that a LIR, which applies for an AS-Num, should be required to fax a written > peering agreement signed by at least 2 upstream-providers. I am not so sure about this. There are many business plans which require the operations to be set up before going to get the 'peering' arrangements done. In these cases, who to multihome/BGP-peer with has not been decided, even though it is in the plans to do so as soon as possible. In addition, there are certain peers who do not require any contract or signed document. -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net Nominet PAB Member ; co-Chair RIPE LIR-WG From ripe-ml at cyberstrider.net Thu Aug 1 15:41:31 2002 From: ripe-ml at cyberstrider.net (Denesh Bhabuta) Date: Thu, 1 Aug 2002 14:41:31 +0100 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <00A11CF5.ADA3EA1A.11@cc.univie.ac.at> References: <00A11CF5.ADA3EA1A.11@cc.univie.ac.at> Message-ID: <20020801134131.GC17218@cyberstrider.net> On Thu, Aug 01, 2002 at 03:07:55PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > I do not recall when exactly the NCC stopped to work on ((PI-)IP-Adress > and AS Number) requests from Non-LIRs. It's been a while :-) One has always been able to apply for an AS number without being a LIR - one just needs to have the application handled via an existing LIR -- Denesh Bhabuta Cyberstrider Limited - www.cyberstrider.net Aexiomus Limited - www.aexiomus.net Nominet PAB Member ; co-Chair RIPE LIR-WG From peter.galbavy at knowtion.net Thu Aug 1 15:49:37 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 1 Aug 2002 14:49:37 +0100 Subject: [lir-wg] AS Number Policy - continued References: <200208010938.LAA11546@mara.mops.net> <3D492BB8.E9585F2D@nethead.de> <20020801133807.GB17218@cyberstrider.net> Message-ID: <021b01c23962$471e46e0$2728a8c0@carpenter> > In addition, there are certain peers who do not require any contract > or signed document. Like me, for example. Peter From av at nethead.de Thu Aug 1 15:52:18 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 01 Aug 2002 15:52:18 +0200 Subject: [lir-wg] AS Number Policy - continued References: <200208010938.LAA11546@mara.mops.net> <3D492BB8.E9585F2D@nethead.de> <20020801133807.GB17218@cyberstrider.net> <021b01c23962$471e46e0$2728a8c0@carpenter> Message-ID: <3D493D12.4ACF5EC1@nethead.de> Peter Galbavy wrote: > > > In addition, there are certain peers who do not require any contract > > or signed document. > > Like me, for example. As i said: I dont want anybody to send in _contracts_. I just thought it would be a good idea to require a _simple_form_ with signatures of at least 2 upstreams because this will cut down the number of unused AS-Nums before they are delegated. Therefore cutting down RIPEs work recollecting them. But i see that most of you are not very fond of this idea :) regards, Arnd -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 K?ln Fax : +49 221 8809212 From dr at cluenet.de Thu Aug 1 16:00:48 2002 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 1 Aug 2002 16:00:48 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <200208011251.OAA23308@mara.mops.net>; from s.willing@mops.net on Thu, Aug 01, 2002 at 02:51:42PM +0200 References: <3D492BB8.E9585F2D@nethead.de> <200208011251.OAA23308@mara.mops.net> Message-ID: <20020801160048.A13760@homebase.cluenet.de> On Thu, Aug 01, 2002 at 02:51:42PM +0200, Sebastian Willing wrote: > the AS-# only if there are less than two verified peerings. I'ld see a > verified peering as a record in both AS's whois-entry _and_ seen on the RIPE > BGP-router (or on some other "neutral" point, like EP routers). The latter (BGP announcement verification) is simply not doable. We already discussed that in length. Regards, Daniel From woeber at cc.univie.ac.at Thu Aug 1 16:34:09 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Aug 2002 16:34:09 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <00A11D01.B97C069A.2@cc.univie.ac.at> >On Thu, Aug 01, 2002 at 03:07:55PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: >> I do not recall when exactly the NCC stopped to work on ((PI-)IP-Adress >> and AS Number) requests from Non-LIRs. It's been a while :-) > >One has always been able to apply for an AS number without being a >LIR - one just needs to have the application handled via an existing >LIR Correct! Which gets us closer to the core: I'd expect the NCC to start bothering the _LIRs_ (if they are still in business :-). Without having a clear mutual understanding of what the procedure would look like, who would have to endure all the finger- pointing and who would have to foot the bill (well the answer is obvious to me ;-) it is premature to ask for a YES or NO to "policy". Btw. I have already asked for an estimate about the number of ASs being available for recycling, and for a guestimate on the extension of the 16bit AS number version's lifetime. I am not aware of any data or discussion, but I might have missed it. >-- >Denesh Bhabuta >Cyberstrider Limited - www.cyberstrider.net >Aexiomus Limited - www.aexiomus.net >Nominet PAB Member ; co-Chair RIPE LIR-WG _________________________________:_____________________________________ 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 Thu Aug 1 16:51:52 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Aug 2002 16:51:52 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <00A11D04.32FEFB1A.9@cc.univie.ac.at> Dear Leo! >I would like to continue this discussion by asking two more >questions: > >1. Should the RIPE NCC check whether Autonomous System Numbers > it has assigned become multi-homed within six months? If you > would like us to do this, the RIPE NCC proposes to do so by > looking at routing policies registered in the Routing Registry. NO, because the method proposed in your Q (and those discussed in this context on the mailng list) is not going to provide reliable data. I am prepared to answer YES, - if this is done for statistical reasons ONLY, - and any data getting published carries an appropriate "fuzziness disclaimer" (tbd). >2. Should the policy be changed so that AS numbers not in use > can be reclaimed? If there is consensus on this we propose > to reclaim AS numbers of networks not multi-homed after six > months. NO. With the qualification that I am more than willing to change that to a YES as soon as - we have an agreed definition of "not in use", - and we have agreed on the procedures (and the cost for verification) to check, plus the impact on the performance of the Hostmaster Role. >Kind regards, > >-- >leo vegoda >RIPE NCC >Registration Services 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 thinman at clp.cw.net Thu Aug 1 17:10:56 2002 From: thinman at clp.cw.net (Tanya Hinman) Date: Thu, 1 Aug 2002 11:10:56 -0400 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <00A11D04.32FEFB1A.9@cc.univie.ac.at> Message-ID: Wilfried, What would you suggest for a definition of "not in use"? I agree that we do need to define "not in use". Tanya -----Original Message----- From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of Wilfried Woeber, UniVie/ACOnet Sent: Thursday, August 01, 2002 10:52 AM To: lir-wg at ripe.net Cc: woeber at cc.univie.ac.at Subject: Re: [lir-wg] AS Number Policy - continued Dear Leo! >I would like to continue this discussion by asking two more >questions: > >1. Should the RIPE NCC check whether Autonomous System Numbers > it has assigned become multi-homed within six months? If you > would like us to do this, the RIPE NCC proposes to do so by > looking at routing policies registered in the Routing Registry. NO, because the method proposed in your Q (and those discussed in this context on the mailng list) is not going to provide reliable data. I am prepared to answer YES, - if this is done for statistical reasons ONLY, - and any data getting published carries an appropriate "fuzziness disclaimer" (tbd). >2. Should the policy be changed so that AS numbers not in use > can be reclaimed? If there is consensus on this we propose > to reclaim AS numbers of networks not multi-homed after six > months. NO. With the qualification that I am more than willing to change that to a YES as soon as - we have an agreed definition of "not in use", - and we have agreed on the procedures (and the cost for verification) to check, plus the impact on the performance of the Hostmaster Role. >Kind regards, > >-- >leo vegoda >RIPE NCC >Registration Services 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 Thu Aug 1 17:55:24 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 01 Aug 2002 17:55:24 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <00A11D0D.131FDE0A.3@cc.univie.ac.at> Tanya, >What would you suggest for a definition of "not in use"? 1st attempt (formally): "For an extended period of time [a] not used for the unique identification of one or more routing processes and/or relationships, on any EGP speaking device. No intent to used the AS number for any such purpose within an extended period of time [b]." [a] period t.b.d. by the community, but not shorter than 6 month [b] period t.b.d. by the community, but not shorter than 12 month 2nd attempt (down to earth approach :-) "Not used at all, no intent to use, simply sitting on as desk; or the entity no longer being aware of it's AS# holdership." >I agree that we do need to define "not in use". :-) And by the way I agree that the community should _encourage_ recycling of AS numbers! >Tanya Wwilfried. From PLu at cw.net Thu Aug 1 18:01:50 2002 From: PLu at cw.net (Lu, Ping) Date: Thu, 1 Aug 2002 12:01:50 -0400 Subject: [lir-wg] AS Number Policy - continued Message-ID: Yes, RIPE should definitely reclaim unused ASN but how is the question. 1. Global routing table is not complete due to various reasons discussed before 2. Whois database could be out-of-date ( If I didn't return the ASN by myself, I probably won't delete my aut-num object as well). 3. Multi-home doesn't mean Multi-LIR. Most tier-1 ISPs have more than one ASN and there are definitely some end-users connect to two ASNs but under one company. 4. Is RIPE doing this free-of-charge or the paying LIR will expense this. By saying this, I am thinking maybe ASN should be renewed with an annual fee ? Euro 50 or wait $50 is cheaper now :) Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber at cc.univie.ac.at] > Sent: Thursday, August 01, 2002 10:52 AM > To: lir-wg at ripe.net > Cc: woeber at cc.univie.ac.at > Subject: Re: [lir-wg] AS Number Policy - continued > > > Dear Leo! > > >I would like to continue this discussion by asking two more > >questions: > > > >1. Should the RIPE NCC check whether Autonomous System Numbers > > it has assigned become multi-homed within six months? If you > > would like us to do this, the RIPE NCC proposes to do so by > > looking at routing policies registered in the Routing Registry. > > NO, > > because the method proposed in your Q (and those discussed in this > context on the mailng list) is not going to provide reliable data. > > I am prepared to answer YES, > - if this is done for statistical reasons ONLY, > - and any data getting published carries an appropriate > "fuzziness disclaimer" (tbd). > > >2. Should the policy be changed so that AS numbers not in use > > can be reclaimed? If there is consensus on this we propose > > to reclaim AS numbers of networks not multi-homed after six > > months. > > NO. > > With the qualification that > I am more than willing to change that to a YES > as soon as > - we have an agreed definition of "not in use", > - and we have agreed on the procedures (and the cost for > verification) > to check, plus the impact on the performance of the > Hostmaster Role. > > >Kind regards, > > > >-- > >leo vegoda > >RIPE NCC > >Registration Services > > 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 john at chagres.net Thu Aug 1 22:00:57 2002 From: john at chagres.net (John M. Brown) Date: Thu, 1 Aug 2002 14:00:57 -0600 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <3D492BB8.E9585F2D@nethead.de> Message-ID: <001501c23996$3f89fa80$f9ecdfd8@laptoy> peering seperate from transit?? and a AS used for peering, may not be viewable at a looking glass > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net] On > Behalf Of Arnd Vehling > Sent: Thursday, August 01, 2002 6:38 AM > To: s.willing at mops.net > Cc: lir-wg at ripe.net > Subject: Re: [lir-wg] AS Number Policy - continued > > > > Sebastian Willing wrote: > > > > I'ld suggest to first use all AS-# allocated to RIPE. Then > re-use the > > AS-# which has the oldest revoke-date (but only if this > date is older > > than one year or so). > > Thats an good suggestion too. > > I dont know if this is out-of-scope of this discussion, but i > would suggest that a LIR, which applies for an AS-Num, should > be required to fax a written peering agreement signed by at > least 2 upstream-providers. > > This should reduce the the number of initialy unused as-nos somewhat. > > best regards, > > Arnd > -- > NetHead Network Design and Security > Arnd Vehling av at nethead.De > Gummersbacherstr. 27 Phone: +49 221 8809210 > 50679 K?ln Fax : +49 221 8809212 > From kurtis at kurtis.pp.se Fri Aug 2 12:38:15 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 02 Aug 2002 12:38:15 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020801160048.A13760@homebase.cluenet.de> References: <3D492BB8.E9585F2D@nethead.de> <200208011251.OAA23308@mara.mops.net> <20020801160048.A13760@homebase.cluenet.de> Message-ID: <97230000.1028284695@laptop.kurtis.pp.se> > On Thu, Aug 01, 2002 at 02:51:42PM +0200, Sebastian Willing wrote: >> the AS-# only if there are less than two verified peerings. I'ld see a >> verified peering as a record in both AS's whois-entry _and_ seen on the >> RIPE BGP-router (or on some other "neutral" point, like EP routers). > > The latter (BGP announcement verification) is simply not doable. > We already discussed that in length. We did but I do not recall that beeing the conclusion..:) Anyway, I think that everyone have suggested to do both with a OR in between. Basically just claiming that "yes I do peer at backwater-IX with Farm-IP and Countryside Networks and I don't get transit from anywhere" should not be enouhg. RIPE should be able to verify that this is true. - kurtis - - kurtis - From kurtis at kurtis.pp.se Fri Aug 2 13:10:22 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 02 Aug 2002 13:10:22 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <00A11D0D.131FDE0A.3@cc.univie.ac.at> References: <00A11D0D.131FDE0A.3@cc.univie.ac.at> Message-ID: <228020000.1028286622@laptop.kurtis.pp.se> >> What would you suggest for a definition of "not in use"? > > 1st attempt (formally): > > "For an extended period of time [a] > not used for the unique identification of one or more routing > processes and/or relationships, on any EGP speaking device. > No intent to used the AS number for any such purpose within > an extended period of time [b]." > > [a] period t.b.d. by the community, but not shorter than 6 month > [b] period t.b.d. by the community, but not shorter than 12 month I like this, but couldn't we refrase the last sentence to be "The intent is to start using the AS-number within [b] period of time, if that proves to not have been the case at [b] the AS-number will be revoked." Basically if they have no intent to use it for [b] we might revoke it immediatly. But what if that is "their" intent but it still does not happen? Best regards, - kurtis - From woeber at cc.univie.ac.at Fri Aug 2 13:44:54 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 02 Aug 2002 13:44:54 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <00A11DB3.3EE8CDCA.3@cc.univie.ac.at> Not really important, but just to avoid being counted as agreeing :-) >Anyway, I think that everyone have suggested to do both with a OR in >between. ...no objection against the OR, but the result of the OR should not be the _only_ input to a decision process. It would be an efficient mechanism to be used _in support_ of continued AS# holdership, though. >Basically just claiming that "yes I do peer at backwater-IX with >Farm-IP and Countryside Networks and I don't get transit from anywhere" >should not be enouhg. I disagree. >RIPE should be able to verify that this is true. Some nit-picking... RIPE (the community): I don't think so - other than having access to some publicly accessible documentation, e.g. in the Routing Registry. The NCC: maybe, if and when we can agree on the criteria, and the cost for verification vs. the result. >- kurtis - Wilfried. From av at nethead.de Fri Aug 2 14:14:23 2002 From: av at nethead.de (Arnd Vehling) Date: Fri, 02 Aug 2002 14:14:23 +0200 Subject: [lir-wg] AS Number Policy - continued References: <3D492BB8.E9585F2D@nethead.de> <200208011251.OAA23308@mara.mops.net> <20020801160048.A13760@homebase.cluenet.de> <97230000.1028284695@laptop.kurtis.pp.se> Message-ID: <3D4A779F.9C734DA0@nethead.de> Kurt Erik Lindqvist wrote: > Anyway, I think that everyone have suggested to do both with a OR in > between. Basically just claiming that "yes I do peer at backwater-IX with > Farm-IP and Countryside Networks and I don't get transit from anywhere" > should not be enouhg. RIPE should be able to verify that this is true. Agreed! -- Arnd From kurtis at kurtis.pp.se Fri Aug 2 14:45:45 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 02 Aug 2002 14:45:45 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <00A11DB3.3EE8CDCA.3@cc.univie.ac.at> References: <00A11DB3.3EE8CDCA.3@cc.univie.ac.at> Message-ID: <214260000.1028292345@laptop.kurtis.pp.se> > Not really important, but just to avoid being counted as agreeing :-) Horrible thought? :) >> Anyway, I think that everyone have suggested to do both with a OR in >> between. > > ...no objection against the OR, but the result of the OR should not be > the _only_ input to a decision process. It would be an efficient > mechanism to be used _in support_ of continued AS# holdership, though. Agreed. OTH, this discussion to me was for new AS assignments that are not yet used. Which is somewhat easier to deal with than with existing AS:es. AS286 beeing an example that is announced but the question is if we can consider it "as in use" ? >> Basically just claiming that "yes I do peer at backwater-IX with >> Farm-IP and Countryside Networks and I don't get transit from anywhere" >> should not be enouhg. > > I disagree. I read this as you mean that RIPE NCC shoudl trust the word of the AS number holder? >> RIPE should be able to verify that this is true. > > Some nit-picking... > > RIPE (the community): I don't think so - other than having access to > some publicly accessible documentation, e.g. in the Routing Registry. My mistake. I ment the RIPE NCC. > The NCC: maybe, if and when we can agree on the criteria, > and the cost for verification vs. the result. Well, if we consider the RIPE db OR announced (or both - which is what it is supposed to be if the latter is true) it's not that hard. First, a requirement to register the AS number policy to keep it would be a easy task. Basically RIPE could then check assigned AS:es to registred. Still, the object does not have to be upto-date or actually reflecting anything. Second, as I belive there is so few assigned AS:es that never make it to the global routing tabele, I would like to define a few points of checks. These could even be route servers and this could be included in the automation. It could also be from the view of the test-traffic boxes. Best regards, - kurtis - From woeber at cc.univie.ac.at Fri Aug 2 15:24:53 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 02 Aug 2002 15:24:53 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <00A11DC1.36940CDA.5@cc.univie.ac.at> >> Not really important, but just to avoid being counted as agreeing :-) > >Horrible thought? :) No :-) >>> Anyway, I think that everyone have suggested to do both with a OR in >>> between. >> >> ...no objection against the OR, but the result of the OR should not be >> the _only_ input to a decision process. It would be an efficient >> mechanism to be used _in support_ of continued AS# holdership, though. > >Agreed. OTH, this discussion to me was for new AS assignments that are not >yet used. Which is somewhat easier to deal with than with existing AS:es. >AS286 beeing an example that is announced but the question is if we can >consider it "as in use" ? True. But to me it was not obvious yet, which "subset" of existing AS#s we are talking about, and whether the procedure would be pro-active only or post-factum as well. >>> Basically just claiming that "yes I do peer at backwater-IX with >>> Farm-IP and Countryside Networks and I don't get transit from anywhere" >>> should not be enouhg. >> >> I disagree. > >I read this as you mean that RIPE NCC shoudl trust the word of the AS >number holder? Yes. Please see below. >>> RIPE should be able to verify that this is true. >> >> Some nit-picking... >> >> RIPE (the community): I don't think so - other than having access to >> some publicly accessible documentation, e.g. in the Routing Registry. > >My mistake. I ment the RIPE NCC. I was reading it that way, too. But my experience with talking to people who for whatever reason get hold of these messages, and do not necessarily have the "implicit" mindset get mixed up easily. >> The NCC: maybe, if and when we can agree on the criteria, >> and the cost for verification vs. the result. > >Well, if we consider the RIPE db OR announced (or both - which is what it >is supposed to be if the latter is true) it's not that hard. First, a >requirement to register the AS number policy to keep it would be a easy >task. ...and would actually, sort of through the backdoor, help to achieve better population of the Routing Registry. As you state, the quality of the data is a different issue, I agree. And defining the proper place for a registration is another "minor" technical issue (Q: portability of AS numbers amongst RIR service areas?). But we could give it a try... >Basically RIPE could then check assigned AS:es to registred. Still, >the object does not have to be upto-date or actually reflecting anything. Correct. >Second, as I belive there is so few assigned AS:es that never make it to >the global routing tabele, I would like to define a few points of checks. >These could even be route servers and this could be included in the >automation. It could also be from the view of the test-traffic boxes. I think we've been there: there is some chance that you cannot see those beasts from those places. Thus my claim (see above) that a statement of use (format to be discusssed) should be enough. For me it's a matter of the "10/90 rule": the cost of achieving 90% of your goal is 10%, doing the remainnig 10% is going to cost you 90%... >Best regards, > >- kurtis - Cheers, Wilfried. From hank at att.net.il Fri Aug 2 16:07:50 2002 From: hank at att.net.il (Hank Nussbacher) Date: Fri, 2 Aug 2002 17:07:50 +0300 (IDT) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <214260000.1028292345@laptop.kurtis.pp.se> Message-ID: On Fri, 2 Aug 2002, Kurt Erik Lindqvist wrote: > Agreed. OTH, this discussion to me was for new AS assignments that are not > yet used. Which is somewhat easier to deal with than with existing AS:es. > AS286 beeing an example that is announced but the question is if we can > consider it "as in use" ? > Yes. If it appears in your BGP tables it is in use. We cannot go and look deeper. Many more cases of ASNs appearing in the RIPE DB and not appearing in any BGP announcement for the past year. Easy targets - no complications. > > - kurtis - Hank From kurtis at kurtis.pp.se Fri Aug 2 16:18:17 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 02 Aug 2002 16:18:17 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: References: Message-ID: <439310000.1028297897@laptop.kurtis.pp.se> > look deeper. Many more cases of ASNs appearing in the RIPE DB and not > appearing in any BGP announcement for the past year. Easy targets - no > complications. It would be really interesting to be able to get a full report of a full bgp table match against the RIPE db and see how many there really are and, try and dig into why. Hmm, Jhma, now that you are at RIPE NCC....couldn't we have the routing analasys pages extended?..:) - kurtis - From kurtis at kurtis.pp.se Fri Aug 2 16:29:38 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 02 Aug 2002 16:29:38 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <00A11DC1.36940CDA.5@cc.univie.ac.at> References: <00A11DC1.36940CDA.5@cc.univie.ac.at> Message-ID: <462210000.1028298578@laptop.kurtis.pp.se> >> Agreed. OTH, this discussion to me was for new AS assignments that are >> not yet used. Which is somewhat easier to deal with than with existing >> AS:es. AS286 beeing an example that is announced but the question is if >> we can consider it "as in use" ? > > True. But to me it was not obvious yet, which "subset" of existing AS#s > we are talking about, and whether the procedure would be pro-active only > or post-factum as well. Well, I think you have a valid point in that if we should start with this, we might as well do it post-factum as well. Problem then is that we need to automate this. And that will a task for the RIPE NCC, and require resources. So, I think for the distinction to make sense - we should first try and figure out how large the "current" problem is. See my previous posting, I think we need a comparison of the RIPE DB to a full BGP table. then we could pick a few AS:es and try and analys them. >>> The NCC: maybe, if and when we can agree on the criteria, >>> and the cost for verification vs. the result. >> >> Well, if we consider the RIPE db OR announced (or both - which is what >> it is supposed to be if the latter is true) it's not that hard. First, >> a requirement to register the AS number policy to keep it would be a >> easy task. > > ...and would actually, sort of through the backdoor, help to achieve > better population of the Routing Registry. As you state, the quality of > the data is a different issue, I agree. Yes. Actually I would suggest that we would make this a requirement for keeping and acquireing an AS. This would require a policy change though I guess and some tools to verify. See above. > And defining the proper place for a registration is another "minor" > technical issue > (Q: portability of AS numbers amongst RIR service areas?). > But we could give it a try... Well, portably I guess is an issue anyway as the database refer to each other (or do they only do that if there is no match? I am not really into the whois data...). >> Second, as I belive there is so few assigned AS:es that never make it to >> the global routing tabele, I would like to define a few points of >> checks. These could even be route servers and this could be included in >> the automation. It could also be from the view of the test-traffic >> boxes. > > I think we've been there: there is some chance that you cannot see > those beasts from those places. Thus my claim (see above) that a > statement of use (format to be discusssed) should be enough. If we take a few steps back in the discussion - we said (well at least I did..:) ) that a ISP would be contacted after [a] time and asked if they had used the AS. If not they would be given [b] time (unless they had come to the conclusion they did not needed it or could meet the timeline) to correct this. I would suggest that after [a] time they are required to make a statement along the suggested lines of : - Upstream - Peers - etc. Perhaps as with the current IP space useage form (after just having filled in one and trying to get it approved I am sure that is enough to scare most people away anyway...:) ). However, I suggest that then, after [b] time they need to prove that this is now in use. Why? Well, if we assume that [a] is six months and [b] is six months, they have had a year. In that time they should have got whatever they needed the AS for up and running. > For me it's a matter of the "10/90 rule": the cost of achieving 90% of > your goal is 10%, doing the remainnig 10% is going to cost you 90%... Agreed, but it is also a question of how the cost really is. Compared to work we (well, the RIPE NCC) spend on IP space, some mechanisms here shouldn't matter to much... - kurtis - From hank at att.net.il Fri Aug 2 17:39:39 2002 From: hank at att.net.il (Hank Nussbacher) Date: Fri, 2 Aug 2002 18:39:39 +0300 (IDT) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <439310000.1028297897@laptop.kurtis.pp.se> Message-ID: On Fri, 2 Aug 2002, Kurt Erik Lindqvist wrote: > > > look deeper.Many more cases of ASNs appearing in the RIPE DB and not > > appearing in any BGP announcement for the past year.Easy targets - no > > complications. > > > It would be really interesting to be able to get a full report of a full > bgp table match against the RIPE db and see how many there really are and, > try and dig into why. Start with: http://www.ris.ripe.net/cgi-bin/asinuse.cgi and select 3 months. -Hank > > Hmm, Jhma, now that you are at RIPE NCC....couldn't we have the routing > analasys pages extended?..:) > > - kurtis - > From thinman at clp.cw.net Fri Aug 2 16:58:11 2002 From: thinman at clp.cw.net (Tanya Hinman) Date: Fri, 2 Aug 2002 10:58:11 -0400 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: Message-ID: >Start with: >http://www.ris.ripe.net/cgi-bin/asinuse.cgi >and select 3 months. Are you suggesting that RIPE use this tool and have it updated to include 6 months or even 1 year? Tanya From kurtis at kurtis.pp.se Fri Aug 2 18:15:00 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 02 Aug 2002 18:15:00 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: References: Message-ID: <39320000.1028304900@laptop.kurtis.pp.se> --On Friday, August 02, 2002 18:39:39 +0300 Hank Nussbacher wrote: > Start with: > http://www.ris.ripe.net/cgi-bin/asinuse.cgi > and select 3 months. This is not really what I had in mind though. I wanted a listing of AS:es assigned, but not in the routing table. Here I already need to know the AS number. But yes, it's the starting point. Best regards, - kurtis - From dr at cluenet.de Fri Aug 2 18:44:24 2002 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 2 Aug 2002 18:44:24 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <214260000.1028292345@laptop.kurtis.pp.se>; from kurtis@kurtis.pp.se on Fri, Aug 02, 2002 at 02:45:45PM +0200 References: <00A11DB3.3EE8CDCA.3@cc.univie.ac.at> <214260000.1028292345@laptop.kurtis.pp.se> Message-ID: <20020802184424.A12568@homebase.cluenet.de> On Fri, Aug 02, 2002 at 02:45:45PM +0200, Kurt Erik Lindqvist wrote: > Well, if we consider the RIPE db OR announced (or both - which is what it > is supposed to be if the latter is true) it's not that hard. First, a > requirement to register the AS number policy to keep it would be a easy > task. Basically RIPE could then check assigned AS:es to registred. Still, > the object does not have to be upto-date or actually reflecting anything. > Second, as I belive there is so few assigned AS:es that never make it to > the global routing tabele, I would like to define a few points of checks. > These could even be route servers and this could be included in the > automation. It could also be from the view of the test-traffic boxes. Kurt, no BGP table check whatsoever can verify very valid setups like the one I described a few weeks back. (AS702 backup uplink using 702:80 community). What should the ASN holder do to prove the existance of this backup upstream? Take down their main link? Regards, Daniel From woeber at cc.univie.ac.at Fri Aug 2 19:30:05 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 02 Aug 2002 19:30:05 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <00A11DE3.77FF360A.1@cc.univie.ac.at> Hi Kurtis, >> And defining the proper place for a registration is another "minor" >> technical issue >> (Q: portability of AS numbers amongst RIR service areas?). >> But we could give it a try... > >Well, portably I guess is an issue anyway as the database refer to each >other (or do they only do that if there is no match? I am not really into >the whois data...). I am not aware of any (real) implementation of RPS-Dist yet... So - no, not really (a nice research topic in itself!). I was simply picking some "random" numbers here: > wripe as1855 % This is the RIPE Whois server. % The objects are in RPSL format. % Please visit http://www.ripe.net/rpsl for more information. % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html as-block: AS1 - AS1876 descr: ARIN ASN block remarks: These AS numbers are further assigned by ARIN remarks: to ARIN members and end-users in the ARIN region admin-c: ARIN1-RIPE tech-c: ARIN1-RIPE mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-NONE-MNT changed: ripe-dbm at ripe.net 20010423 source: RIPE role: American Registry for Internet Numbers address: ARIN, see http://www.arin.net admin-c: ARIN1-RIPE tech-c: ARIN1-RIPE nic-hdl: ARIN1-RIPE remarks: For more information on ARIN assigned blocks, connect remarks: to ARIN's whois database, whois.arin.net. mnt-by: RIPE-NCC-MNT changed: ripe-dbm at ripe.net 20010508 source: RIPE > warin 1855 Bolt, Beranek and Newman, Inc. (ASN-DISN-PILOTNET1) 150 Cambridge Park Drive Cambridge, MA 02140 US Autonomous System Name: DISN-PILOTNET1 Autonomous System Number: 1855 Coordinator: Wojcik, Jane H. (JHW19-ARIN) jwojcik at MEDIA.MIT.EDU (617) 253-0325 Record last updated on 27-May-1992. Database last updated on 1-Aug-2002 20:00:38 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. > wripe as1755 % This is the RIPE Whois server. % The objects are in RPSL format. % Please visit http://www.ripe.net/rpsl for more information. % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html as-block: AS1 - AS1876 descr: ARIN ASN block remarks: These AS numbers are further assigned by ARIN remarks: to ARIN members and end-users in the ARIN region admin-c: ARIN1-RIPE tech-c: ARIN1-RIPE mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-NONE-MNT changed: ripe-dbm at ripe.net 20010423 source: RIPE aut-num: AS1755 as-name: AS1755 descr: Ebone Transit Core import: from AS1 accept ANY import: from AS109 accept AS109 [ ...... ] # [ ...... ] # half a mile of routing policy and communities :-) [ ...... ] # mnt-by: AS1755-MNT mnt-lower: AS1755-MNT changed: bart-apps at ebone.net 20020702 source: RIPE > warin 1755 Ebone Consortium (ASN-EBONE-INTERNAL) STUPI Box 9129 S-102 72 Stockholm SE Autonomous System Name: EBONE-INTERNAL Autonomous System Number: 1755 Record last updated on 19-Feb-1992. Database last updated on 1-Aug-2002 20:00:38 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. And while "we" RIPE DB do have a referral mechanism in place for _domains_, .... ;-) And I think both ARIN and APNIC are working on a ("central", similar to the RIPE Region's) routing registry, but it may still be a long way... Cheers, Wilfried. From kurtis at kurtis.pp.se Fri Aug 2 21:08:18 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Fri, 02 Aug 2002 21:08:18 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <00A11DE3.77FF360A.1@cc.univie.ac.at> References: <00A11DE3.77FF360A.1@cc.univie.ac.at> Message-ID: <21450000.1028315297@laptop.kurtis.pp.se> >>> And defining the proper place for a registration is another "minor" >>> technical issue >>> (Q: portability of AS numbers amongst RIR service areas?). >>> But we could give it a try... >> >> Well, portably I guess is an issue anyway as the database refer to each >> other (or do they only do that if there is no match? I am not really >> into the whois data...). > > I am not aware of any (real) implementation of RPS-Dist yet... > > So - no, not really (a nice research topic in itself!). > I was simply picking some "random" numbers here: This ofcourse brings up a non-technical question. Should a AS owner be allowed to transfer it to another RIR? I don't see a reason why not (actually I see tons of reasons why they should). It will however create a real problem for the databases, and more or less eliminates the current "referal by allocation block" answers as we have today. But this is more a database implementation problem, or even a data registration problem. My vote would be to remove the "referal" objects (if they even are objects). There are clients that will search each of the databases anyway. I am not really into the DB-WG work, or the history of this, but somehow I would assume that data mirroring is the easiest (for some definition of easy) solution. Just like we have the -RIPE for contacts, I could see something simliare for AS-numbers. And yes - I do realise it's a bit more to it than that. > aut-num: AS1755 > as-name: AS1755 > descr: Ebone Transit Core > import: from AS1 accept ANY > import: from AS109 accept AS109 > [ ...... ] # > [ ...... ] # half a mile of routing policy and communities :-) > [ ...... ] # > mnt-by: AS1755-MNT > mnt-lower: AS1755-MNT > changed: bart-apps at ebone.net 20020702 > source: RIPE Certain people should update their objects..:) > And while "we" RIPE DB do have a referral mechanism in place for > _domains_, .... ;-) > > And I think both ARIN and APNIC are working on a ("central", similar to > the RIPE Region's) routing registry, but it may still be a long way... WEll, routing registry is one thing - just "copying" the objects or at least the owner would be a great start. We don't need to copy all of the RPSL data neccessarily (although that would be a good step too...:) ), but at least the current data in the ARIN and APNIC AS objects. - kurtis - From kurtis at kurtis.pp.se Mon Aug 5 08:36:01 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 05 Aug 2002 08:36:01 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020802184424.A12568@homebase.cluenet.de> References: <00A11DB3.3EE8CDCA.3@cc.univie.ac.at> <214260000.1028292345@laptop.kurtis.pp.se> <20020802184424.A12568@homebase.cluenet.de> Message-ID: <49070000.1028529360@laptop.kurtis.pp.se> > Kurt, no BGP table check whatsoever can verify very valid setups like > the one I described a few weeks back. (AS702 backup uplink using 702:80 > community). What should the ASN holder do to prove the existance of > this backup upstream? Take down their main link? No, if there are cases that are not visible in the global routing table, notifying RIPE NCC as to why not would be good enough. At least IMHO. - kurtis - From hank at att.net.il Sat Aug 3 21:06:41 2002 From: hank at att.net.il (Hank Nussbacher) Date: Sat, 3 Aug 2002 22:06:41 +0300 (IDT) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020802184424.A12568@homebase.cluenet.de> Message-ID: On Fri, 2 Aug 2002, Daniel Roesen wrote: > On Fri, Aug 02, 2002 at 02:45:45PM +0200, Kurt Erik Lindqvist wrote: > > Well, if we consider the RIPE db OR announced (or both - which is what it > > is supposed to be if the latter is true) it's not that hard. First, a > > requirement to register the ASnumber policy to keep it would be a easy > > task. Basically RIPE could then check assigned AS:es to registred. Still, > > the object does not have to be upto-date or actually reflecting anything. > > Second, as I belive there is so few assigned AS:es that never make it to > > the global routing tabele, I would like to define a few points of checks. > > These could even be route servers and this could be included in the > > automation. It could also be from the view of the test-traffic boxes. > > Kurt, noBGP table check whatsoever can verify very valid setups like > the one I described a few weeks back. (AS702 backup uplink using 702:80 > community). What should the ASN holder do to prove the existance of > this backup upstream? Take down their main link? > Contingent BGP announcements are valid. Our view should not be to hurt ISPs. If one comes along and says he is doing a backup link and can bring documentation from his backup upstream, it is up to RIPE to verify it and accept it. Not impossible. > > Regards, > Daniel > Hank Nussbacher From hank at att.net.il Sat Aug 3 21:31:23 2002 From: hank at att.net.il (Hank Nussbacher) Date: Sat, 3 Aug 2002 22:31:23 +0300 (IDT) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: Message-ID: On Fri, 2 Aug 2002, Tanya Hinman wrote: Imagine an automated RIPE process that cycles thru all allocated RIPE ASNs, checks RIS and sends out emails to the mntner and to the LIR that requested the ASN. > > >Start with: > >http://www.ris.ripe.net/cgi-bin/asinuse.cgi > >and select 3 months. > > Are you suggesting that RIPE use this tool and have it updated to include 6 > months or even 1 year? > > Tanya > Hank Nussbacher From bruce.campbell at ripe.net Mon Aug 5 13:07:35 2002 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Mon, 5 Aug 2002 13:07:35 +0200 (CEST) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <39320000.1028304900@laptop.kurtis.pp.se> Message-ID: On Fri, 2 Aug 2002, Kurt Erik Lindqvist wrote: > --On Friday, August 02, 2002 18:39:39 +0300 Hank Nussbacher > wrote: > > http://www.ris.ripe.net/cgi-bin/asinuse.cgi > > This is not really what I had in mind though. I wanted a listing of AS:es > assigned, but not in the routing table. Here I already need to know the AS > number. But yes, it's the starting point. Interested parties may find the files in ftp://ftp.ripe.net/ripe/stats/ to be useful. Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security From stephenb at uk.uu.net Mon Aug 5 13:19:14 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Mon, 5 Aug 2002 12:19:14 +0100 Subject: [lir-wg] Webcasting Meetings Message-ID: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> Hi I am formaly asking that if not RIPE 43 then all future meetings will be webcast so that all memebers who want to attend can attend the meeting. Otherwise this is by no means an equal opportunity meeing to attend and is only open to those who can get their expenses justified for holiday destinations with the express intention of going to the meeting, which lets face it in the current climate is nigh impossible. Its not that i do not appreciate the venues or that the meetings are not the place to go, its just getting harder to get to them. I wish to see a broader section of the community contributing to the RIPE process which is unique and a fine foundation for the RIPE community to come together, its just that the coming together is much harder for most now. Otherwise the only views expressed and heard are those of the people who can attend physicaly which is not the majority so limiting the scope and participation of the community at large. Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE From mjrobinson at genuity.net Mon Aug 5 13:34:57 2002 From: mjrobinson at genuity.net (Matthew J Robinson) Date: Mon, 05 Aug 2002 12:34:57 +0100 Subject: [lir-wg] Webcasting Meetings In-Reply-To: Your message of "Mon, 05 Aug 2002 12:19:14 BST." <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> Message-ID: Hi all, I'd like to lend my support to this proposal. At it's simplest this is a few people with a few web cams and a bit of multicast support from a couple of networks. I'm fairly sure I can get some support from the multicast people on our network. Any one definately going that has a webcam and would be prepared to run a trial? I'll offer what help I can. I admit to knowing little about webcam software but I can route packets ;-) Matthew > Hi > I am formaly asking that if not RIPE 43 then all future meetings will be > webcast so that all memebers who want to attend can attend the meeting. > Otherwise this is by no means an equal opportunity meeing to attend and is > only open to those who can get their expenses justified for holiday > destinations with the express intention of going to the meeting, which lets > face it in the current climate is nigh impossible. Its not that i do not > appreciate the venues or that the meetings are not the place to go, its just > getting harder to get to them. > I wish to see a broader section of the community contributing to the > RIPE process which is unique and a fine foundation for the RIPE community to > come together, its just that the coming together is much harder for most > now. Otherwise the only views expressed and heard are those of the people > who can attend physicaly which is not the majority so limiting the scope and > participation of the community at large. > > Regards, > > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > > From wilson.mehringer at cablecom.ch Mon Aug 5 14:46:52 2002 From: wilson.mehringer at cablecom.ch (Wilson Mehringer) Date: Mon, 05 Aug 2002 14:46:52 +0200 Subject: Antw: Re: [lir-wg] Webcasting Meetings Message-ID: Hi, I would also like to support this proposal. It sounds like a call for democracy..on-site or online. It goes without saying that there is a business element to these meetings and a good number of attendees/companies will opt for the webcasts. Nothing against business....as long as it is ethical. Wilson >>> Matthew J Robinson 05.08.2002 13:34 >>> Hi all, I'd like to lend my support to this proposal. At it's simplest this is a few people with a few web cams and a bit of multicast support from a couple of networks. I'm fairly sure I can get some support from the multicast people on our network. Any one definately going that has a webcam and would be prepared to run a trial? I'll offer what help I can. I admit to knowing little about webcam software but I can route packets ;-) Matthew > Hi > I am formaly asking that if not RIPE 43 then all future meetings will be > webcast so that all memebers who want to attend can attend the meeting. > Otherwise this is by no means an equal opportunity meeing to attend and is > only open to those who can get their expenses justified for holiday > destinations with the express intention of going to the meeting, which lets > face it in the current climate is nigh impossible. Its not that i do not > appreciate the venues or that the meetings are not the place to go, its just > getting harder to get to them. > I wish to see a broader section of the community contributing to the > RIPE process which is unique and a fine foundation for the RIPE community to > come together, its just that the coming together is much harder for most > now. Otherwise the only views expressed and heard are those of the people > who can attend physicaly which is not the majority so limiting the scope and > participation of the community at large. > > Regards, > > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > > From s.willing at mops.net Mon Aug 5 14:52:13 2002 From: s.willing at mops.net (Sebastian Willing) Date: Mon, 5 Aug 2002 14:52:13 +0200 (CEST) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: from "Bruce Campbell" at Aug 05, 2002 01:07:35 PM Message-ID: <200208051252.OAA22851@mara.mops.net> Hello all, some of you asked for numbers, here are some: I wrote a little script on the weekend, which looks for unused and singlehomed ASs within the routing tables of some specified routers. I gave it our routers and some public route servers/looking glasses and it produced the following results (which should be treated as figures, not as absolut and correct numbers!): ASs allocated to RIPE: 6016 ASs unassigned: 616 ASs singlehomed: 224 ASs unused: 1526 I used data from saturday and today. I'll be happy to send the script to everyone who requests (via PM, please!) and I'ld also give my result files to NCC. MfG / Regards, S.Willing, mopSys GmbH ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing at mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************ From kurtis at kurtis.pp.se Mon Aug 5 15:17:31 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 05 Aug 2002 15:17:31 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <200208051252.OAA22851@mara.mops.net> References: <200208051252.OAA22851@mara.mops.net> Message-ID: <2549650000.1028553451@laptop.kurtis.pp.se> --On Monday, August 05, 2002 14:52:13 +0200 Sebastian Willing wrote: > ASs allocated to RIPE: 6016 > ASs unassigned: 616 > ASs singlehomed: 224 > ASs unused: 1526 Sebastian, this is a good excersie! However, if we really have 25% of the AS:es assigned to RIPE not visible in the Global routing table, I think we have a problem.... - kurtis - From s.willing at mops.net Mon Aug 5 15:35:05 2002 From: s.willing at mops.net (Sebastian Willing) Date: Mon, 5 Aug 2002 15:35:05 +0200 (CEST) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <2549650000.1028553451@laptop.kurtis.pp.se> from "Kurt Erik Lindqvist" at Aug 05, 2002 03:17:31 PM Message-ID: <200208051335.PAA25976@mara.mops.net> Kurt, Kurt Erik Lindqvist wrote: > > > > --On Monday, August 05, 2002 14:52:13 +0200 Sebastian Willing > wrote: > > > ASs allocated to RIPE: 6016 > > ASs unassigned: 616 > > ASs singlehomed: 224 > > ASs unused: 1526 > > > Sebastian, this is a good excersie! > > However, if we really have 25% of the AS:es assigned to RIPE not visible in > the Global routing table, I think we have a problem.... I used limited data for the analysis. I think, if we could incorperate information from some EP's route servers, the results would change. If someone could/would like to send me a full "sh ip bgp paths" - log from an EP's route server, I'ld be happy to re-run the analysis and post the updated numbers. AND: I collected the data only two times with only two or three days difference. If RIPE would run the tool regulary (each week or so) on their routers and some route-servers of EP's (no need to make them public, just give RIPE some kind of very limited access), we'ld have better results. But I still think, we'ld be over 1000 unused ASs, and I don't think, that many of them are younger than a year. MfG / Regards, S.Willing, mopSys GmbH ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing at mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************ From oliver at bartels.de Mon Aug 5 15:30:53 2002 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 05 Aug 2002 15:30:53 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <200208051252.OAA22851@mara.mops.net> Message-ID: <200208051328.g75DSwh30958@alpha.bartels.de> Hello, On Mon, 5 Aug 2002 14:52:13 +0200 (CEST), Sebastian Willing wrote: >ASs allocated to RIPE: 6016 >ASs unassigned: 616 >ASs singlehomed: 224 >ASs unused: 1526 Good peace of work, interesting ... This statistics shows that the typical problem case isn't a singlehomed ASn, it's just an *unused at all* ASn. Thus it seems it isn't necessary to establish a big buerocracy with forms to be signed etc. (like we German tend to do ;-|, its just sufficient to validate their use in the global table and/or view peer/upstream AS references (listing in as-set or aut-num object of partner) corresponding to the ASn in the RIPE database. IMHO this should give a large yield (1500+x) with little effort and covers most "I am $BIGCOMPANY and need a ASn because its rare and for free" cases. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From henk at ripe.net Mon Aug 5 16:20:52 2002 From: henk at ripe.net (Henk Uijterwaal (RIPE-NCC)) Date: Mon, 5 Aug 2002 16:20:52 +0200 (CEST) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <200208051335.PAA25976@mara.mops.net> Message-ID: Sebastian, > > wrote: > > > > > ASs allocated to RIPE: 6016 > > > ASs unassigned: 616 > > > ASs singlehomed: 224 > > > ASs unused: 1526 > If RIPE would run the tool regulary (each week or so) on their routers > and some route-servers of EP's (no need to make them public, just give > RIPE some kind of very limited access), we'ld have better results. We already have similar numbers online: http://www.ris.ripe.net/as-stat/ These show the number of AS's seen by sites peering with one of the RRC's of the RIS project, split out by month and by registry. The data doesn't change that much, so running this once a month is sufficient. What we want to do is to add a list showing the individual AS's, registries and number of peers for all AS's assigned to the RIPE NCC. If you look at over the last 7 months: the number of AS's increased by about 2000 (12000 in January, 14000 now), while at the same time the percentage of single-homed AS's dropped from 50% to 40%. I'll show plots of both at RIPE43. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal at ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk at ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. From ncc at ripe.net Mon Aug 5 16:47:05 2002 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Mon, 05 Aug 2002 16:47:05 +0200 Subject: [lir-wg] New Document available: RIPE-243 Message-ID: <200208051447.g75El57F001344@birch.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "New Values of the "status:" Attribute for inet6num Objects". Short content description ------------------------- This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "New Values of the "status:" Attribute for inet6num Objects" is available from the WWW at the following URL: http://www.ripe.net/docs/new-value-status.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-243.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-243.txt plain text version Kind Regards, Jeroen Bet Webmaster RIPE NCC From ncc at ripe.net Mon Aug 5 16:52:05 2002 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Mon, 05 Aug 2002 16:52:05 +0200 Subject: [lir-wg] New Document available: RIPE-256 Message-ID: <200208051452.g75Eq57F003576@birch.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "IPv6 Address Space Policy for Internet Exchange Points" Short content description ------------------------- Internet Exchange Points (IXPs) are used to exchange Internet traffic between different Internet Service Providers (ISPs). Many Exchange Point operators require address space for the peering mesh that is independent from any of the address space in use by member networks. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "IPv6 Address Space Policy for Internet Exchange Points" is available at the following URL: http://www.ripe.net/docs/ripe-256.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-256.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-256.txt plain text version Kind Reagrds, Jeroen Bet Webmaster RIPE NCC From PLu at cw.net Mon Aug 5 17:01:28 2002 From: PLu at cw.net (Lu, Ping) Date: Mon, 5 Aug 2002 11:01:28 -0400 Subject: [lir-wg] AS Number Policy - continued Message-ID: Look like those singlehomed ASs need to shutdown their primary link and activate their backup link so RIPE NCC could verify their LEGAL use of ASes :( For the unused ASs, I think an annual renewal fee is a whole lot easier to verify their intent to use then go thru INCOMPLETE global routing table and non-distribute whois db :) Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Oliver Bartels [mailto:oliver at bartels.de] > Sent: Monday, August 05, 2002 9:31 AM > To: lir-wg at ripe.net > Subject: Re: [lir-wg] AS Number Policy - continued > > > Hello, > On Mon, 5 Aug 2002 14:52:13 +0200 (CEST), Sebastian Willing wrote: > >ASs allocated to RIPE: 6016 > >ASs unassigned: 616 > >ASs singlehomed: 224 > >ASs unused: 1526 > Good peace of work, interesting ... > > This statistics shows that the typical problem case isn't a > singlehomed > ASn, it's just an *unused at all* ASn. > > Thus it seems it isn't necessary to establish a big buerocracy > with forms to be signed etc. (like we German tend to do ;-|, its > just sufficient to validate their use in the global table and/or view > peer/upstream AS references (listing in as-set or aut-num object > of partner) corresponding to the ASn in the RIPE database. > > IMHO this should give a large yield (1500+x) with little effort > and covers most "I am $BIGCOMPANY and need a ASn because > its rare and for free" cases. > > Best Regards > Oliver Bartels > > > > Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany > oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 > > From crain at icann.org Mon Aug 5 22:01:00 2002 From: crain at icann.org (John Crain) Date: Mon, 5 Aug 2002 13:01:00 -0700 Subject: [lir-wg] Webcasting Meetings In-Reply-To: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> Message-ID: <003401c23cba$d5381040$5d2300c0@VAIO> Hi Stephen, One way participation of a single meeting, i.e. a webcast, is "relatively" easy to do in this day and age. I'm presently building a kit for this under the guidance of the UofO folks who do the IETF's and NANOG. The equipment, though not cheap, is an investment that is IMHO well worth while if you intend To broadcast multiple meetings. The UofO folks also broadcast our last two meetings. They are extremely helpful folks and I'm sure would be willing to help with such a project if the NCC folks requested. Go to http://www.icann.org/bucharest for links to the stored archives if you want to see a sample. The difficulty for the RIPE meetings would be to have the the multiple meetings up at the same time, more gear and more staff. Two way participation is slightly more complicated. IRC, works but needs staffing to queue the questions. My experience from what I've seen is that 99% of the traffic is irrelevant to the topic. An Email addess is less interactive, still needs queueing but attracts less noise. There may be many other solutions. All of them will of course take resources to work during the meeting. It may be interesting to try broadcasting lir-wg and plenary as a test Case with a simple irc or mail interface for questions at the next Amsterdam meeting? Anyway I hereby offer my assistance along with those other offers. _________________________________________ John Crain Manager of Technical Operations ICANN crain at icann.org 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _________________________________________ > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net] On > Behalf Of Stephen Burley > Sent: Monday, August 05, 2002 4:19 AM > To: Lir-Wg at Ripe.Net > Subject: [lir-wg] Webcasting Meetings > > > Hi > I am formaly asking that if not RIPE 43 then all future > meetings will be webcast so that all memebers who want to > attend can attend the meeting. Otherwise this is by no means > an equal opportunity meeing to attend and is only open to > those who can get their expenses justified for holiday > destinations with the express intention of going to the > meeting, which lets face it in the current climate is nigh > impossible. Its not that i do not appreciate the venues or > that the meetings are not the place to go, its just getting > harder to get to them. > I wish to see a broader section of the community > contributing to the RIPE process which is unique and a fine > foundation for the RIPE community to come together, its just > that the coming together is much harder for most now. > Otherwise the only views expressed and heard are those of the > people who can attend physicaly which is not the majority so > limiting the scope and participation of the community at large. > > Regards, > > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > From gert at space.net Mon Aug 5 23:06:07 2002 From: gert at space.net (Gert Doering) Date: Mon, 5 Aug 2002 23:06:07 +0200 Subject: [lir-wg] Webcasting Meetings In-Reply-To: ; from mjrobinson@genuity.net on Mon, Aug 05, 2002 at 12:34:57PM +0100 References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> Message-ID: <20020805230607.C27015@Space.Net> Hi, I do also second Stephen's proposal, it's a good idea. On Mon, Aug 05, 2002 at 12:34:57PM +0100, Matthew J Robinson wrote: > I'd like to lend my support to this proposal. At it's simplest this is a few > people with a few web cams and a bit of multicast support from a couple of > networks. I'm fairly sure I can get some support from the multicast people on > our network. > > Any one definately going that has a webcam and would be prepared to run a > trial? I'll offer what help I can. I admit to knowing little about webcam > software but I can route packets ;-) ... on the other hand, I tried this last meeting in Amsterdam, and "just any Webcam" won't buy it. The video quality was very poor, and I did not have any audio. I have a new web cam now, which has better video at about 100 kbit, but for recognizable audio, one would need good microphone equipment, or maybe (much better) a way to tap into the conference room's audio system. Most likely we'll have to do the routing over a tunnel into someone's home network, and distribute the multicast from there, as the RIPE network didn't have multicast routing enabled on the last few meetings. (The interesting question is "how many listeners do have multicast?" - maybe we need to do RealAudio instead). Also, bandwidth might be a problem as the link is usually already saturated without video going on... I'd be willing to participate in the experiments, though. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pim at bit.nl Mon Aug 5 23:26:24 2002 From: pim at bit.nl (Pim van Pelt) Date: Mon, 5 Aug 2002 23:26:24 +0200 Subject: [lir-wg] Webcasting Meetings In-Reply-To: <20020805230607.C27015@Space.Net> References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> <20020805230607.C27015@Space.Net> Message-ID: <20020805212624.GA94670@hog.ipng.nl> Hi gents, I'm sure I could distribute the RIPE video from our AS. We are at AMS-IX and generally have fine connectivity to the RIPE-NCC networks. This is a good proposal/idea and I would like to support it from the IP point of view. I agree with Gert that a realvideo stream might be better. I myself would be interrested in the (foreign) meetings which I do not attend, but am quite clueless with the (multicast && unix) combo. In principal, the meetings should be able to be sent into the Internet if somebody takes some hardware along with them. groet, Pim On Mon, Aug 05, 2002 at 11:06:07PM +0200, Gert Doering wrote: | Hi, | | I do also second Stephen's proposal, it's a good idea. | | On Mon, Aug 05, 2002 at 12:34:57PM +0100, Matthew J Robinson wrote: | > I'd like to lend my support to this proposal. At it's simplest this is a few | > people with a few web cams and a bit of multicast support from a couple of | > networks. I'm fairly sure I can get some support from the multicast people on | > our network. | > | > Any one definately going that has a webcam and would be prepared to run a | > trial? I'll offer what help I can. I admit to knowing little about webcam | > software but I can route packets ;-) | | ... on the other hand, I tried this last meeting in Amsterdam, and "just | any Webcam" won't buy it. The video quality was very poor, and I did not | have any audio. | | I have a new web cam now, which has better video at about 100 kbit, but | for recognizable audio, one would need good microphone equipment, or | maybe (much better) a way to tap into the conference room's audio system. | | Most likely we'll have to do the routing over a tunnel into someone's | home network, and distribute the multicast from there, as the RIPE network | didn't have multicast routing enabled on the last few meetings. (The | interesting question is "how many listeners do have multicast?" - maybe | we need to do RealAudio instead). | | Also, bandwidth might be a problem as the link is usually already | saturated without video going on... | | I'd be willing to participate in the experiments, though. | | Gert Doering | -- NetMaster | -- | Total number of prefixes smaller than registry allocations: 46631 (46284) | | SpaceNet AG Mail: netmaster at Space.Net | Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 | 80807 Muenchen Fax : +49-89-32356-299 -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From woeber at cc.univie.ac.at Tue Aug 6 10:22:51 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 06 Aug 2002 10:22:51 +0200 Subject: [lir-wg] Webcasting Meetings Message-ID: <00A120BB.AEF7261A.4@cc.univie.ac.at> >Hi, > >I do also second Stephen's proposal, it's a good idea. Before I throw in my (historical :-) 2 Groschen, is this the right place to discuss remote participation? Looking at the goal (supporting the open policy process), it is - looking at technology and implementation issues, I'm not so sure? Wilfried. From joao at ripe.net Tue Aug 6 10:22:53 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 6 Aug 2002 10:22:53 +0200 Subject: [lir-wg] Webcasting Meetings In-Reply-To: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> Message-ID: Stephen, as you know a few years ago RIPE meetings were broadcast over the Mbone. Then it was decided to stop doing it because the observed attendency was really low. I am more than willing to restart broadcasting and add remote participation with what is available today. As a matter of fact there is a provision in the RIPE NCC's 2003 budget proposal to acquire this sort of equipment and we will be getting familiar with the hw and sw during the next couple of months. We already approached the people who do session broadcast for NANOG at the last NANOG. For a definitive response on whether we actually get to do this at the RIPE meetings however, the RIPE chair (Rob) has the last word. Cheers, Joao At 12:19 +0100 5/8/02, Stephen Burley wrote: >Hi > I am formaly asking that if not RIPE 43 then all future meetings will be >webcast so that all memebers who want to attend can attend the meeting. >Otherwise this is by no means an equal opportunity meeing to attend and is >only open to those who can get their expenses justified for holiday >destinations with the express intention of going to the meeting, which lets >face it in the current climate is nigh impossible. Its not that i do not >appreciate the venues or that the meetings are not the place to go, its just >getting harder to get to them. > I wish to see a broader section of the community contributing to the >RIPE process which is unique and a fine foundation for the RIPE community to >come together, its just that the coming together is much harder for most >now. Otherwise the only views expressed and heard are those of the people >who can attend physicaly which is not the majority so limiting the scope and >participation of the community at large. > >Regards, > > >Stephen Burley >WorldCom EMEA Hostmaster >SB855-RIPE From kurtis at kurtis.pp.se Tue Aug 6 10:43:27 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 06 Aug 2002 10:43:27 +0200 Subject: [lir-wg] Webcasting Meetings In-Reply-To: <20020805212624.GA94670@hog.ipng.nl> References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> <20020805230607.C27015@Space.Net> <20020805212624.GA94670@hog.ipng.nl> Message-ID: <235920000.1028623407@laptop.kurtis.pp.se> Although I generally think it's a good idea, I am also sharing Gerts concerns about the bandwidth...I am not completly convinced that I would like to sacrify meeting bandwidth for the streaming... - kurtis - --On Monday, August 05, 2002 23:26:24 +0200 Pim van Pelt wrote: > Hi gents, > > I'm sure I could distribute the RIPE video from our AS. We are at AMS-IX > and generally have fine connectivity to the RIPE-NCC networks. > > This is a good proposal/idea and I would like to support it from the IP > point of view. > > I agree with Gert that a realvideo stream might be better. I myself > would be interrested in the (foreign) meetings which I do not attend, > but am quite clueless with the (multicast && unix) combo. > > In principal, the meetings should be able to be sent into the Internet > if somebody takes some hardware along with them. > > groet, > Pim > > On Mon, Aug 05, 2002 at 11:06:07PM +0200, Gert Doering wrote: >| Hi, >| >| I do also second Stephen's proposal, it's a good idea. >| >| On Mon, Aug 05, 2002 at 12:34:57PM +0100, Matthew J Robinson wrote: >| > I'd like to lend my support to this proposal. At it's simplest this >| > is a few people with a few web cams and a bit of multicast support >| > from a couple of networks. I'm fairly sure I can get some support >| > from the multicast people on our network. >| > >| > Any one definately going that has a webcam and would be prepared to >| > run a trial? I'll offer what help I can. I admit to knowing little >| > about webcam software but I can route packets ;-) >| >| ... on the other hand, I tried this last meeting in Amsterdam, and "just >| any Webcam" won't buy it. The video quality was very poor, and I did not >| have any audio. >| >| I have a new web cam now, which has better video at about 100 kbit, but >| for recognizable audio, one would need good microphone equipment, or >| maybe (much better) a way to tap into the conference room's audio system. >| >| Most likely we'll have to do the routing over a tunnel into someone's >| home network, and distribute the multicast from there, as the RIPE >| network didn't have multicast routing enabled on the last few meetings. >| (The interesting question is "how many listeners do have multicast?" - >| maybe we need to do RealAudio instead). >| >| Also, bandwidth might be a problem as the link is usually already >| saturated without video going on... >| >| I'd be willing to participate in the experiments, though. >| >| Gert Doering >| -- NetMaster >| -- >| Total number of prefixes smaller than registry allocations: 46631 >| (46284) >| >| SpaceNet AG Mail: netmaster at Space.Net >| Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >| 80807 Muenchen Fax : +49-89-32356-299 > > -- > __________________ > Met vriendelijke groet, /\ ___/ > Pim van Pelt /- \ _/ Business Internet Trends BV > PBVP1-RIPE /--- \/ __________________ From leo at ripe.net Tue Aug 6 16:28:03 2002 From: leo at ripe.net (leo vegoda) Date: Tue, 6 Aug 2002 16:28:03 +0200 Subject: [lir-wg] Updating inet6num objects with a legacy status attribute Message-ID: <20020806142803.GC11181@ripe.net> Dear Colleagues, The RIPE Database server, whois.ripe.net, has been updated to allow the new status attributes specified in the document: "New Values of the 'status:' Attribute for inet6num Objects" The status values of all inet6num objects maintained by the RIPE NCC have been updated as appropriate. We would be grateful if everyone maintaining inet6num objects would update them to use the new status attribute values. The RIPE NCC will use the "ASSIGNED" status value to determine the HD ratio when it receives a request for an additional IPv6 allocation. A request form for additional IPv6 allocations will be published in the near future. Best regards, -- leo vegoda RIPE NCC Registration Services From stephenb at uk.uu.net Wed Aug 7 14:46:16 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Wed, 7 Aug 2002 13:46:16 +0100 Subject: [lir-wg] Webcasting Meetings References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> Message-ID: <025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> > > For a definitive response on whether we actually get to do this at > the RIPE meetings however, the RIPE chair (Rob) has the last word. Since it is our money and our community why does one person hold the keys on this desicion? > > >Stephen Burley > >WorldCom EMEA Hostmaster > >SB855-RIPE > From zsako at banknet.net Wed Aug 7 16:39:09 2002 From: zsako at banknet.net (Janos Zsako) Date: Wed, 7 Aug 2002 16:39:09 +0200 (MET DST) Subject: [lir-wg] Webcasting Meetings Message-ID: <200208071439.QAA07847@banknet.banknet.net> > From owner-lir-wg at ripe.net Wed Aug 7 14:48:37 2002 > From: "Stephen Burley" Dear Stephen, > > For a definitive response on whether we actually get to do this at > > the RIPE meetings however, the RIPE chair (Rob) has the last word. > > Since it is our money and our community why does one person hold the keys on > this desicion? I think this question could be appropriate if there was _consensus_ in the community that this is something we _must_ have, and Rob would oppose it. At present I think it is not the case. Janos From kurtis at kurtis.pp.se Wed Aug 7 16:54:43 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 07 Aug 2002 16:54:43 +0200 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <5.1.0.14.2.20020807150452.00ffeba0@max.att.net.il> References: <200208051252.OAA22851@mara.mops.net> <200208051252.OAA22851@mara.mops.net> <5.1.0.14.2.20020807150452.00ffeba0@max.att.net.il> Message-ID: <429430000.1028732083@laptop.kurtis.pp.se> > My experience is that returning things to RIPE is just as hard as trying > to get a /16 for a new ISP :-). So Kurt, you are absolutely right that > "we have a problem" with 25% unused RIPE assigned ASNs. Yes, I agree. Perhaps we could have a discussion around this added to the agenda of the next LIR-WG meeting? Hans-Petter? - kurtis - From hank at att.net.il Wed Aug 7 14:35:49 2002 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 07 Aug 2002 15:35:49 +0300 Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <2549650000.1028553451@laptop.kurtis.pp.se> References: <200208051252.OAA22851@mara.mops.net> <200208051252.OAA22851@mara.mops.net> Message-ID: <5.1.0.14.2.20020807150452.00ffeba0@max.att.net.il> At 03:17 PM 05-08-02 +0200, Kurt Erik Lindqvist wrote: >--On Monday, August 05, 2002 14:52:13 +0200 Sebastian Willing > wrote: > >>ASs allocated to RIPE: 6016 >>ASs unassigned: 616 >>ASs singlehomed: 224 >>ASs unused: 1526 > > >Sebastian, this is a good excersie! > >However, if we really have 25% of the AS:es assigned to RIPE not visible >in the Global routing table, I think we have a problem.... As someone who actively goes after unused ASNs as well as single-homed ASNs, I would say the toughest problem is RIPE itself. Here are some examples: --------------------------------------------------------- Example #1: ASN returned 2/2001 and not reused. It took a few emails on my part to "convince" RIPE to reuse it, as they did finally in 6/2002: >>Dear Hank >> >>We have taken AS8885 back, however we cannot re-assign it as it is >>referenced in another object in the RIPE Database. > >There is no reason that that entry be in the database since Doarnet has >not existed for the past 2 years and I doubt they have paid their RIPE >dues for the past 2 years. Proof: they no longer are listed as a member: >http://www.ripe.net/ripencc/mem-services/general/indices/IL.html > >What procedures does RIPE use to reclaim IP address space that has been >assigned and no longer is used? > >-Hank Incidentally, they reclaimed the ASN from this bankrupt ISP but have not yet reclaimed the IP address space from this defunct ISP: inetnum: 212.77.128.0 - 212.77.129.255 netname: DOARNET-IL descr: DoarNet Internal Net. country: IL admin-c: SP401 tech-c: SP401 rev-srv: dns.doar.net rev-srv: dns2.doar.net status: ASSIGNED PA notify: shai at consonet.com mnt-by: DRNT-SP changed: shai at consonet.com 19990201 source: RIPE ----------------------------------------------------- Example #2: ASN removed by one hostmaster and reassigned to a new organization and then along comes another hostmaster and does: >Thanks for your message about the deleted and unused AS number AS6875. > >Unfortunately, we cannot return it to the pool of unused AS numbers at >this time because it still has one peer. > >Here is the data from http://www.ris.ripe.net/cgi-bin/asinuse.cgi=20 > >full url below: > >(http://www.ris.ripe.net/cgi-bin/asinuse.cgi?as=3DAS6875&display=3Dpeer&int= >erval=3Done&outype=3Dhtml&.submit=3DSubmit) > > >"AS6875 was last announced on Thu Jul 18 16:37:57 2002 (UTC). 1 peer are fo= >und for AS6875. > >Neighbor of 6875 Last Seen AS Path >9004 Thu Jul 18 16:37:57 2002 13129 8220 12761 9004 6875" > >Do you know anything about this? I had to go explain that AS6875 was already returned, reassigned and has already established a new peer session with AS9004. ------------------------------------------------- Example #3: Company owning the ASN is bought out, no longer needs the ASN, but it is protected via "auth:" with one of email|crypt-pw|md5 which is no longer known. This then requires for written hardcopy, quoting from hostmaster: >Changing the authorisation of a maintainer object means changing >sensitive user data. In cases when our manual intervention is necessary >we require written hardcopy confirmation from the maintainer's admin-c >which serves as a form of authentication and authorisation for the >change. > >So before we can change your maintainer for you please send us a fax >stating the reason for the change and full text of the old and then new >object. The fax should be on the headed paper of your company, signed by >the admin-c of the object ... I was lucky to find someone in the new company who joined in the email ping-pong marathon with RIPE, typed up the letter on company letterhead, faxed it to RIPE (4x until RIPE accepted it), and then finally I was able to change the entry and then delete it. And I was lucky on that one. If the company had gone bankrupt or just shutdown, and the autnum entry were "auth" protected, and there would be no "admin-c" to speak to, I do not know what RIPE would end up doing. You really see LIRs investing a few hours of work every time they try to be "good to the Internet" to return a defunct ASN and battle with RIPE hostmasters every step of the way? My experience is that returning things to RIPE is just as hard as trying to get a /16 for a new ISP :-). So Kurt, you are absolutely right that "we have a problem" with 25% unused RIPE assigned ASNs. -Hank >- kurtis - From mjrobinson at genuity.net Wed Aug 7 15:40:22 2002 From: mjrobinson at genuity.net (Matthew J Robinson) Date: Wed, 07 Aug 2002 14:40:22 +0100 Subject: [lir-wg] Webcasting Meetings In-Reply-To: Your message of "Wed, 07 Aug 2002 13:46:16 BST." <025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> Message-ID: Hi all, Sounds like we need a 'trial run' this time round. Maybe just broadcast a single session to 'see if it works'. I'm quite keen to promote multicast for this - mainly due to fact we had a multicast working group and we should promote it's use! Maybe we can take the multicast stream and plumb it into a realmedia server? If someone goes and takes a webcam let's try it out. Maybe a BoF is called for to get some interest. If a few people watch this time, We can get a better solution in for next time round. I'm trying not to get too caught up in the money/technical side. Let's have some fun - like we used to in the 'good old days'! Kind regards Matthew > > For a definitive response on whether we actually get to do this at > > the RIPE meetings however, the RIPE chair (Rob) has the last word. > > Since it is our money and our community why does one person hold the keys on > this desicion? > > > > > > >Stephen Burley > > >WorldCom EMEA Hostmaster > > >SB855-RIPE > > > > From randy at psg.com Wed Aug 7 18:08:49 2002 From: randy at psg.com (Randy Bush) Date: Wed, 07 Aug 2002 09:08:49 -0700 Subject: [lir-wg] Webcasting Meetings References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> <025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> Message-ID: >> For a definitive response on whether we actually get to do this at >> the RIPE meetings however, the RIPE chair (Rob) has the last word. > Since it is our money and our community why does one person hold the keys > on this desicion? because we have strange things called "management structures." From gert at space.net Wed Aug 7 21:05:42 2002 From: gert at space.net (Gert Doering) Date: Wed, 7 Aug 2002 21:05:42 +0200 Subject: [lir-wg] Webcasting Meetings In-Reply-To: ; from mjrobinson@genuity.net on Wed, Aug 07, 2002 at 02:40:22PM +0100 References: <025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> Message-ID: <20020807210542.F27015@Space.Net> Hi, On Wed, Aug 07, 2002 at 02:40:22PM +0100, Matthew J Robinson wrote: > Sounds like we need a 'trial run' this time round. Maybe just broadcast a > single session to 'see if it works'. I'm quite keen to promote multicast for > this - mainly due to fact we had a multicast working group and we should > promote it's use! Maybe we can take the multicast stream and plumb it into a > realmedia server? It can work the other way round (you send an unicast stream to the RealServer, and it will optionally send it out as multicast). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46631 (46284) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From stephenb at uk.uu.net Thu Aug 8 15:47:46 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 8 Aug 2002 14:47:46 +0100 Subject: [lir-wg] Webcasting Meetings References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net><025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> Message-ID: <047101c23ee2$2d4da730$2e04bf3e@eu.frd.uu.net> > >> For a definitive response on whether we actually get to do this at > >> the RIPE meetings however, the RIPE chair (Rob) has the last word. > > Since it is our money and our community why does one person hold the keys > > on this desicion? > > because we have strange things called "management structures." > Not in the RIPE community, the managment run the NCC (within the RIPE communities guide lines) not the RIPE community, they do NOT control what happens within the community structure. From randy at psg.com Thu Aug 8 16:21:01 2002 From: randy at psg.com (Randy Bush) Date: Thu, 08 Aug 2002 07:21:01 -0700 Subject: [lir-wg] Webcasting Meetings References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> <025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> <047101c23ee2$2d4da730$2e04bf3e@eu.frd.uu.net> Message-ID: sadly, we funny monkeys have not figured out how to successfully run an organization the size of the ripe ncc as an anarchic commune. hence we have hiyou don'terarchic management structures. i don't think i would be very comfortable betting my network on having the ncc conducting "management research" on how to run. randy From fm at st-kilda.org Thu Aug 8 16:32:55 2002 From: fm at st-kilda.org (Fearghas McKay) Date: Thu, 8 Aug 2002 15:32:55 +0100 Subject: [lir-wg] Webcasting Meetings In-Reply-To: References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net> <025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> <047101c23ee2$2d4da730$2e04bf3e@eu.frd.uu.net> Message-ID: Randy RIPE NCC != the RIPE Community but you know that right - because you are a travelled civilised American. And one person making the decisions is not a management structure unless you can feed data into it and review its outcomes. The RIPE meetings are for the community to meet - they are organised by the NCC as part of its service remit but the community drives the process. Stephen's point is valid as a general point ie meeting venue and date choices as recent examples, there is no way that I am aware of to send formal feedback into the system for meeting management other than through WG chairs. f At 7:21 am -0700 8/8/02, Randy Bush wrote: >sadly, we funny monkeys have not figured out how to successfully >run an organization the size of the ripe ncc as an anarchic >commune. hence we have hiyou don'terarchic management structures. >i don't think i would be very comfortable betting my network on >having the ncc conducting "management research" on how to run. > >randy From leo at ripe.net Thu Aug 8 16:40:55 2002 From: leo at ripe.net (leo vegoda) Date: Thu, 8 Aug 2002 16:40:55 +0200 Subject: [lir-wg] Fwd: ARIN to allocate from 69.0.0.0/8 Message-ID: <20020808144055.GA11647@ripe.net> ----- Forwarded message ----- From: "Leslie Nobile" To: Subject: ARIN to allocate from 69.0.0.0/8 Date: 8 August 2002 14:23:58 GMT In the near future, ARIN will begin making allocations from 69.0.0.0/8. This will include allocations of /20 and shorter prefixes, according to ARIN's minimum allocation policy. For informational purposes, a list of ARIN's currently administered blocks can be found at http://www.arin.net/statistics/index.html Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) ----- End forwarded message ----- Regards, -- leo vegoda RIPE NCC Registration Services From support at form-net.com Thu Aug 8 17:51:01 2002 From: support at form-net.com (Wycliffe Bahati) Date: Thu, 08 Aug 2002 18:51:01 +0300 Subject: [lir-wg] Webcasting Meetings References: <011a01c23c71$ee519450$2e04bf3e@eu.frd.uu.net><025401c23e10$6bfee160$2e04bf3e@eu.frd.uu.net> <047101c23ee2$2d4da730$2e04bf3e@eu.frd.uu.net> Message-ID: <3D529365.CD9DC65D@form-net.com> Very interesting it depends on the interpretation. Someone got to provide a definition Stephen Burley wrote: > > >> For a definitive response on whether we actually get to do this at > > >> the RIPE meetings however, the RIPE chair (Rob) has the last word. > > > Since it is our money and our community why does one person hold the > keys > > > on this desicion? > > > > because we have strange things called "management structures." > > > Not in the RIPE community, the managment run the NCC (within the RIPE > communities guide lines) not the RIPE community, they do NOT control what > happens within the community structure. From stephenb at uk.uu.net Thu Aug 15 13:08:34 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 15 Aug 2002 12:08:34 +0100 Subject: [lir-wg] DNSSEC training WHY? Message-ID: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> Hi Could someone please tell me WHY we are running free training courses for DNS? Training how to interact with the NCC and DB i understand, but dns i do not. Who made the descision to implement this training and what grounds are there for doing this? Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE From pim at bit.nl Thu Aug 15 13:28:00 2002 From: pim at bit.nl (Pim van Pelt) Date: Thu, 15 Aug 2002 13:28:00 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> References: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> Message-ID: <20020815112800.GA50198@hog.ipng.nl> On Thu, Aug 15, 2002 at 12:08:34PM +0100, Stephen Burley wrote: | Hi | Could someone please tell me WHY we are running free training courses | for DNS? Training how to interact with the NCC and DB i understand, but dns | i do not. Who made the descision to implement this training and what grounds | are there for doing this? As a former student in one of the DNSSEC courses (actually, I have also given one with Olaf Kolkman) I very much welcome the active role of the RIPE folk educating the community with new technological features which might be otherwise implemented/deployed in a wrong way. I think it is a goal of RIPE to enhance the exchange of expertise and see them in an educating role for their service region. I must add though, that this course is not a DNS course. It aims specifically at deploying DNSSec, rolling over keys, signing zones and what you can expect with the (until so far) not so well documented software available on the marketplace today. May I ask what exactly is your problem with this type of education ? Perhaps it is tie that RIPE takes part in more training/education aspects such as IPv6 deployment. groet Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________ From Daniel.Karrenberg at ripe.net Thu Aug 15 13:44:33 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 15 Aug 2002 13:44:33 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> Message-ID: <4.3.2.7.2.20020815133350.067ac130@localhost.ripe.net> At 01:08 PM 8/15/2002, Stephen Burley wrote: >Hi > Could someone please tell me WHY we are running free training courses >for DNS? Training how to interact with the NCC and DB i understand, but dns >i do not. Who made the descision to implement this training and what grounds >are there for doing this? Stephen, this is part of the DISI activity as specified in the RIPE NCC Activity Plan 2002 which was discussed by RIPE and adopted by the RIPE NCC membership. I quote the most relevant parts below foir your convenience. The idea of DISI is to promote deployment of security relevant technology **that needs to be deployed in the Infrastructure**, as opposed to technology that is under individual organisation's responsibility. In particular the courses announced deal with DNSSEC technology and are targeted at people thoroughly familiar with DNS itself. They are not general purpose DNS courses. More info about DISI can be found at http://www.ripe.net/ripencc/pub-services/np/DISI/index.html Regards Daniel --------- Deployment of Internet Security Infrastructure (DISI) Security Deployment is a new activity started in late 2000. As the Internet is used for more and more critical applications, security becomes increasingly important. A lot of security technology has recently been developed and now needs to be deployed throughout the Internet Infrastructure [RFC 2828]. Prominent examples are DNSSec [RFC 2535] and IPSec [RFC 2401]. The DISI project will support the RIPE community in deploying these technologies, specifically those technologies that need to be deployed in the Internet Infrastructure itself, rather than at the end sites only. This project initially focuses on DNSsec and will later be expanded to other relevant technologies. As from the RIPE 40 Meeting, the RIPE NCC will start to offer courses on securing a zone using DNSsec. Information and experience will also be gathered by the deployment of the technologies within the RIPE NCC. The information will be shared with the RIPE community in additional workshops and white papers. During the start-up phase of this project, it has become clear that a lot of work still needs to be done on the technology and the implementations before DNSSEC can be deployed in a large scale production environment. The RIPE NCC has therefore set up collaborations with NLnet-labs, Nominum, and other parties interested in these technologies to help improve the deploy-ability of DNSSEC. This is also pursued by active involvement in the relevant IETF working groups. DISI will continue in 2002. From m.hallgren at free.fr Thu Aug 15 13:53:43 2002 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 15 Aug 2002 13:53:43 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> Message-ID: > >Hi Hi, > Could someone please tell me WHY we are running free training courses >for DNS? Training how to interact with the NCC and DB i understand, but dns >i do not. Who made the descision to implement this training and what grounds >are there for doing this? > I think (personally, and also hope that RIPE community think) that it's pretty much in line with the idea of a community organization to propose such training... for the benefit of future operation. Kind regards Michael -- Michael Hallgren, http://m.hallgren.free.fr/, MH2198-RIPE (ex-Teleglobe, BB Eng., peering, and such.) >Regards, > >Stephen Burley >WorldCom EMEA Hostmaster >SB855-RIPE From Daniel.Karrenberg at ripe.net Thu Aug 15 13:57:50 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 15 Aug 2002 13:57:50 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: References: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> Message-ID: <4.3.2.7.2.20020815135356.022b7ee8@localhost.ripe.net> At 01:53 PM 8/15/2002, Michael Hallgren wrote: >I think (personally, and also hope that RIPE community think) that it's >pretty >much in line with the idea of a community organization to propose such >training... for the benefit of future operation. Thank you for your support Michael. I have also had some private e-mail asking whether the RIPE NCC is 'joining the post September 11 2001 psychosis/bandwaggon'. Before I get any more of this I'd like to make clear that DISI pre-dates September 11 2001 by a fair margin. See: http://www.ripe.net/ripencc/pub-services/np/DISI/Talks/0101_DISI/sld001.html Daniel From john at chagres.net Thu Aug 15 14:25:21 2002 From: john at chagres.net (John M. Brown) Date: Thu, 15 Aug 2002 06:25:21 -0600 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <4.3.2.7.2.20020815135356.022b7ee8@localhost.ripe.net> Message-ID: <002801c24456$d9747740$f9ecdfd8@laptoy> I believe that all RIR's should have as one of its missions the providing of education to its members and to the community. By increasing the "CLUE" factor we only help improve the net in general. I'm glad to see RIPE continuing to take a leadership role in this. John Brown Speaking for himself > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net] On > Behalf Of Daniel Karrenberg > Sent: Thursday, August 15, 2002 5:58 AM > To: m.hallgren at free.fr > Cc: Stephen Burley; local-lir at ripe.net; Lir-Wg at Ripe.Net > Subject: RE: [lir-wg] DNSSEC training WHY? > > > At 01:53 PM 8/15/2002, Michael Hallgren wrote: > > > >I think (personally, and also hope that RIPE community > think) that it's > >pretty much in line with the idea of a community organization to > >propose such training... for the benefit of future operation. > > Thank you for your support Michael. > > I have also had some private e-mail asking whether the RIPE > NCC is 'joining the post September 11 2001 > psychosis/bandwaggon'. Before I get any more of this I'd like > to make clear that DISI pre-dates September 11 2001 by a fair margin. > See: > http://www.ripe.net/ripencc/pub-services/np/DISI/Talks/0101_DI SI/sld001.html Daniel From stephenb at uk.uu.net Thu Aug 15 14:53:35 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 15 Aug 2002 13:53:35 +0100 Subject: [lir-wg] DNSSEC training WHY? References: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> <5.1.0.14.2.20020815143318.00fbb7c0@max.att.net.il> Message-ID: <054401c2445a$c51fb490$2e04bf3e@eu.frd.uu.net> I agree with Hank, the NCC is not there to educate the community in protocols and applications that is the express responsibility of the companies involved. If you are going to start training this kind of thing is should be at the very least on a subscription basis. I for one do not want to fund the education of the entire ripe community. I feel this is wrong, it is not part of our service agreement which is what we pay for, much the same as the test traffic white elephant we funded for years. If the RIPE community feels it needs an internationally run training organisation then maybe the NCC can organise this. The community is not an educational charity, the NCC is not there to help those to learn what the rest already know through hard work and research. Please do not get me wrong I am not against the reason behind the education initiative I am against you using our money to do this, I would prefer to see the money better spent on things we need, like better applications, smaller wait queues, automation to name but a few. The NCC does do a good job of educating the community in NCC interaction which is right and proper use of funds, DNSSEC courses are not. Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE ----- Original Message ----- From: "Hank Nussbacher" To: "Pim van Pelt" ; "Stephen Burley" Cc: ; "Lir-Wg at Ripe.Net" Sent: Thursday, August 15, 2002 12:35 PM Subject: Re: [lir-wg] DNSSEC training WHY? > At 01:28 PM 15-08-02 +0200, Pim van Pelt wrote: > >On Thu, Aug 15, 2002 at 12:08:34PM +0100, Stephen Burley wrote: > >| Hi > >| Could someone please tell me WHY we are running free training courses > >| for DNS? Training how to interact with the NCC and DB i understand, but dns > >| i do not. Who made the descision to implement this training and what grounds > >| are there for doing this? > > > >As a former student in one of the DNSSEC courses (actually, I have also > >given one with Olaf Kolkman) I very much welcome the active role of the > >RIPE folk educating the community with new technological features which > >might be otherwise implemented/deployed in a wrong way. > > > >I think it is a goal of RIPE to enhance the exchange of expertise and > >see them in an educating role for their service region. > > Then why not give free courses on multicast, MPLS, or XML? > > > >I must add though, that this course is not a DNS course. It aims > >specifically at deploying DNSSec, rolling over keys, signing zones and > >what you can expect with the (until so far) not so well documented > >software available on the marketplace today. > > > >May I ask what exactly is your problem with this type of education ? > > By giving free courses, RIPE is using its member fees to subsidize > functions that are not in its main charter of business. > > -Hank > > > >Perhaps it is tie that RIPE takes part in more training/education > >aspects such as IPv6 deployment. > > > >groet > >Pim > > > > > >-- > > __________________ > >Met vriendelijke groet, /\ ___/ > >Pim van Pelt /- \ _/ Business Internet Trends BV > >PBVP1-RIPE /--- \/ __________________ > From m.hallgren at free.fr Thu Aug 15 15:40:40 2002 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 15 Aug 2002 15:40:40 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <054e01c2445c$3b5c2610$2e04bf3e@eu.frd.uu.net> Message-ID: > > >I agree but we do not foot the bill, because if thats the case where does it >stop as i feel i would like a free course in XML, bluetooth, c++, oracle, >sybase, apache, tomcatand the list goes on. One could argue that DNS(SEC|) could be considered of more immediate common operational importance. One could argue further, that a RIPE training course is of a more informational (BCP, consensus, etc) character.. Right? > If this is whats needed then >another organisation needs to be created to meet this need, the NCC is our >RIR not our free internet education tool. > I do of course share your opinion that RIPE {c,sh}ouldn't substitute more regular sources of education: academical, vendor's, pay-for or other. And, as you see above, not only because of the funding issue you mention. But, I believe that, well-tuned, training provided by RIPE (or similar organization) serve as a useful complement. mh > > >for the benefit of future operation. >> >> Kind regards >> >> Michael >> >> -- >> Michael Hallgren, http://m.hallgren.free.fr/, MH2198-RIPE >> (ex-Teleglobe, BB Eng., peering, and such.) >> >> >> >Regards, >> > >> >Stephen Burley >> >WorldCom EMEA Hostmaster >> >SB855-RIPE >> >> From john at chagres.net Thu Aug 15 15:09:56 2002 From: john at chagres.net (John M. Brown) Date: Thu, 15 Aug 2002 07:09:56 -0600 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <054401c2445a$c51fb490$2e04bf3e@eu.frd.uu.net> Message-ID: <003c01c2445d$13f5fa50$f9ecdfd8@laptoy> Community outreach and education is part of stewardship. Making sure members are knowledgeable about technical issues, allows them to help form better policies. In the ARIN region, the members recently agreed that training was useful, valuable and they supported it as a good use of time and money. I'm glad to see the RIR's providing this service. It fosters better involvement and, ummm, NET working, which is better than NOT working :) john brown speaking for himself > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net] On > Behalf Of Stephen Burley > Sent: Thursday, August 15, 2002 6:54 AM > To: Pim van Pelt; Hank Nussbacher > Cc: local-lir at ripe.net; Lir-Wg at Ripe.Net > Subject: Re: [lir-wg] DNSSEC training WHY? > > > I agree with Hank, the NCC is not there to educate the > community in protocols and applications that is the express > responsibility of the companies involved. If you are going to > start training this kind of thing is should be at the very > least on a subscription basis. I for one do not want to fund > the education of the entire ripe community. I feel this is > wrong, it is not part of our service agreement which is what > we pay for, much the same as the test traffic white elephant > we funded for years. If the RIPE community feels it needs an > internationally run training organisation then maybe the NCC > can organise this. The community is not an educational > charity, the NCC is not there to help those to learn what the > rest already know through hard work and research. > Please do not get me wrong I am not against the reason > behind the education initiative I am against you using our > money to do this, I would prefer to see the money better > spent on things we need, like better applications, smaller > wait queues, automation to name but a few. The NCC does do a > good job of educating the community in NCC interaction which > is right and proper use of funds, DNSSEC courses are not. > > Regards, > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > ----- Original Message ----- > From: "Hank Nussbacher" > To: "Pim van Pelt" ; "Stephen Burley" > Cc: ; "Lir-Wg at Ripe.Net" > Sent: Thursday, August 15, 2002 12:35 PM > Subject: Re: [lir-wg] DNSSEC training WHY? > > > > At 01:28 PM 15-08-02 +0200, Pim van Pelt wrote: > > >On Thu, Aug 15, 2002 at 12:08:34PM +0100, Stephen Burley wrote: > > >| Hi > > >| Could someone please tell me WHY we are running free training > courses > > >| for DNS? Training how to interact with the NCC and DB i > understand, > > >| but > dns > > >| i do not. Who made the descision to implement this training and > > >| what > grounds > > >| are there for doing this? > > > > > >As a former student in one of the DNSSEC courses (actually, I have > > >also given one with Olaf Kolkman) I very much welcome the > active role > > >of the RIPE folk educating the community with new technological > > >features which might be otherwise implemented/deployed in a wrong > > >way. > > > > > >I think it is a goal of RIPE to enhance the exchange of > expertise and > > >see them in an educating role for their service region. > > > > Then why not give free courses on multicast, MPLS, or XML? > > > > > > >I must add though, that this course is not a DNS course. It aims > > >specifically at deploying DNSSec, rolling over keys, signing zones > > >and what you can expect with the (until so far) not so well > > >documented software available on the marketplace today. > > > > > >May I ask what exactly is your problem with this type of > education ? > > > > By giving free courses, RIPE is using its member fees to subsidize > > functions that are not in its main charter of business. > > > > -Hank > > > > > > >Perhaps it is tie that RIPE takes part in more training/education > > >aspects such as IPv6 deployment. > > > > > >groet > > >Pim > > > > > > > > >-- > > > __________________ > > >Met vriendelijke groet, /\ ___/ > > >Pim van Pelt /- \ _/ Business Internet Trends BV > > >PBVP1-RIPE /--- \/ __________________ > > > From stephenb at uk.uu.net Thu Aug 15 15:04:03 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 15 Aug 2002 14:04:03 +0100 Subject: [lir-wg] DNSSEC training WHY? References: Message-ID: <054e01c2445c$3b5c2610$2e04bf3e@eu.frd.uu.net> > > I think (personally, and also hope that RIPE community think) that it's > pretty > much in line with the idea of a community organization to propose such > training... I agree but we do not foot the bill, because if thats the case where does it stop as i feel i would like a free course in XML, bluetooth, c++, oracle, sybase, apache, tomcatand the list goes on. If this is whats needed then another organisation needs to be created to meet this need, the NCC is our RIR not our free internet education tool. for the benefit of future operation. > > Kind regards > > Michael > > -- > Michael Hallgren, http://m.hallgren.free.fr/, MH2198-RIPE > (ex-Teleglobe, BB Eng., peering, and such.) > > > >Regards, > > > >Stephen Burley > >WorldCom EMEA Hostmaster > >SB855-RIPE > > From john at chagres.net Thu Aug 15 16:01:11 2002 From: john at chagres.net (John M. Brown) Date: Thu, 15 Aug 2002 08:01:11 -0600 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <054e01c2445c$3b5c2610$2e04bf3e@eu.frd.uu.net> Message-ID: <003e01c24464$3cc7ca60$f9ecdfd8@laptoy> Stephen, I think you are missing the point. I would not expect the RIR's to teach about C++, Apache, etc.. Bringing courses out on new, relevant topics, new adopted protocols or BCP's is well within the RIR charter, IMHO.. I'm exiting the conversation as it seems to now be thrashing.... john brown speaking for himself > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net] On > Behalf Of Stephen Burley > Sent: Thursday, August 15, 2002 7:04 AM > To: m.hallgren at free.fr; local-lir at ripe.net > Cc: Lir-Wg at Ripe.Net > Subject: Re: [lir-wg] DNSSEC training WHY? > > > > > > > I think (personally, and also hope that RIPE community think) that > > it's pretty much in line with the idea of a community > organization to > > propose such training... > > I agree but we do not foot the bill, because if thats the > case where does it stop as i feel i would like a free course > in XML, bluetooth, c++, oracle, sybase, apache, tomcatand the > list goes on. If this is whats needed then another > organisation needs to be created to meet this need, the NCC > is our RIR not our free internet education tool. > > > > for the benefit of future operation. > > > > Kind regards > > > > Michael > > > > -- > > Michael Hallgren, http://m.hallgren.free.fr/, MH2198-RIPE > > (ex-Teleglobe, BB Eng., peering, and such.) > > > > > > >Regards, > > > > > >Stephen Burley > > >WorldCom EMEA Hostmaster > > >SB855-RIPE > > > > > From stephenb at uk.uu.net Thu Aug 15 16:11:28 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 15 Aug 2002 15:11:28 +0100 Subject: [lir-wg] DNSSEC training WHY? References: Message-ID: <057a01c24465$a5c9b2c0$2e04bf3e@eu.frd.uu.net> > >Community outreach and education is part of stewardship. Making > >sure members are knowledgeable about technical issues, allows them > >to help form better policies. > > Fine at no cost to those who do not benefit. > >In the ARIN region, the members recently agreed that training > >was useful, valuable and they supported it as a good use > >of time and money. > > No such agreement was made in RIPE region if it was it was not voiced to the comunity at large. From henk at ripe.net Thu Aug 15 16:44:44 2002 From: henk at ripe.net (Henk Uijterwaal (RIPE-NCC)) Date: Thu, 15 Aug 2002 16:44:44 +0200 (CEST) Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <054e01c2445c$3b5c2610$2e04bf3e@eu.frd.uu.net> Message-ID: Stephen, > > I think (personally, and also hope that RIPE community think) that it's > > pretty > > much in line with the idea of a community organization to propose such > > training... > > I agree but we do not foot the bill, because if thats the case where does it > stop as i feel i would like a free course in XML, bluetooth, c++, oracle, > sybase, apache, tomcatand the list goes on. If this is whats needed then > another organisation needs to be created to meet this need, the NCC is our > RIR not our free internet education tool. XML, bluetooth and others can all be independently deployed by organizations. No coordination is needed and if one of them makes a mistake during deployment, all they do is to hurt themselves. This is NOT the case for security technology for the infrastructure structure. Here a certain amount of coordination is needed and one person mis-configuring his part can break the entire chain. The goal of the DISI project is to do this coordination as well as to make sure that the participating organizations have the technical knowledge in house. The DNSSEC courses are organized to accomplish the latter. > No such agreement was made in RIPE region if it was it was not voiced to > the comunity at large. I like to point out that the DISI project was first presented to the community at RIPE37 (Sept'2000) and has always been mentioned at the plenary since then. Courses were mentioned as part of the project from the beginning. I have attended all those meetings but, until today, only had positive feedback on this idea. The project is also mentioned in the activity plans for 2001 and 2002 and those have been explictly approved by the membership. So, while you are certainly entitled to your opinion that the RIPE NCC should not do this project, I don't think that it is fair to say that the RIPE NCC is using membership money to organize courses for its members without asking them first. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal at ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) NOTE: My email address (and a hole in our mailing list software) is being abused by a spammer. We are working on fixing this hole and tracking the spammer down. If you receive mail from "henk at ripe.net" that is obviously spam, please send me a copy of the mail including ALL headers. I'm sorry for any inconvenience caused by this. From hank at att.net.il Thu Aug 15 13:35:56 2002 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 15 Aug 2002 14:35:56 +0300 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <20020815112800.GA50198@hog.ipng.nl> References: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> Message-ID: <5.1.0.14.2.20020815143318.00fbb7c0@max.att.net.il> At 01:28 PM 15-08-02 +0200, Pim van Pelt wrote: >On Thu, Aug 15, 2002 at 12:08:34PM +0100, Stephen Burley wrote: >| Hi >| Could someone please tell me WHY we are running free training courses >| for DNS? Training how to interact with the NCC and DB i understand, but dns >| i do not. Who made the descision to implement this training and what grounds >| are there for doing this? > >As a former student in one of the DNSSEC courses (actually, I have also >given one with Olaf Kolkman) I very much welcome the active role of the >RIPE folk educating the community with new technological features which >might be otherwise implemented/deployed in a wrong way. > >I think it is a goal of RIPE to enhance the exchange of expertise and >see them in an educating role for their service region. Then why not give free courses on multicast, MPLS, or XML? >I must add though, that this course is not a DNS course. It aims >specifically at deploying DNSSec, rolling over keys, signing zones and >what you can expect with the (until so far) not so well documented >software available on the marketplace today. > >May I ask what exactly is your problem with this type of education ? By giving free courses, RIPE is using its member fees to subsidize functions that are not in its main charter of business. -Hank >Perhaps it is tie that RIPE takes part in more training/education >aspects such as IPv6 deployment. > >groet >Pim > > >-- > __________________ >Met vriendelijke groet, /\ ___/ >Pim van Pelt /- \ _/ Business Internet Trends BV >PBVP1-RIPE /--- \/ __________________ From peter.juul at uni-c.dk Thu Aug 15 13:39:48 2002 From: peter.juul at uni-c.dk (Peter B. Juul) Date: Thu, 15 Aug 2002 13:39:48 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <20020815112800.GA50198@hog.ipng.nl>; from pim@bit.nl on Thu, Aug 15, 2002 at 01:28:00PM +0200 References: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> <20020815112800.GA50198@hog.ipng.nl> Message-ID: <20020815133947.N22145@uni-c.dk> On Thu, Aug 15, 2002 at 01:28:00PM +0200, Pim van Pelt wrote: > May I ask what exactly is your problem with this type of education ? I guess it's the fact that all LIRs pay for what RIPE decides to do for "free". Personally, I think it's a good thing to have a free DNS course, as DNS servers are often horribly misconfigured and the way we use the net depend on them. The DNSSec et al however seems a tad exotic for a community funded course. > Perhaps it is tie that RIPE takes part in more training/education > aspects such as IPv6 deployment. Actually, a lot of RIPE meetings (every?) have a great IPv6 tutorial for just that purpose. I took part in the one in Prague at RIPE-40 and it gave me most of the background I needed to prepare for "my" networks participation in the 6net project. (It didn't prepare me for the anguish I would have to go through to actually _get_ IPv6 addresses, but that's another story.) Peter B. Juul, Uni?C (PBJ255-RIPE) From m.hallgren at free.fr Thu Aug 15 16:02:48 2002 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 15 Aug 2002 16:02:48 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <003c01c2445d$13f5fa50$f9ecdfd8@laptoy> Message-ID: > >Community outreach and education is part of stewardship. Making >sure members are knowledgeable about technical issues, allows them >to help form better policies. > >In the ARIN region, the members recently agreed that training >was useful, valuable and they supported it as a good use >of time and money. > >I'm glad to see the RIR's providing this service. It fosters >better involvement and, ummm, NET working, which is better >than NOT working :) > :) >john brown mh >speaking for himself idem From randy at psg.com Thu Aug 15 16:29:25 2002 From: randy at psg.com (Randy Bush) Date: Thu, 15 Aug 2002 07:29:25 -0700 Subject: [lir-wg] DNSSEC training WHY? References: <057a01c24465$a5c9b2c0$2e04bf3e@eu.frd.uu.net> Message-ID: >> In the ARIN region, the members recently agreed that training >> was useful, valuable and they supported it as a good use >> of time and money. > No such agreement was made in RIPE region if it was it was not voiced to > the comunity at large. did daniel's message specifically addressing this get caught in your mail filters? > this is part of the DISI activity as specified in the RIPE NCC Activity Plan > 2002 which was discussed by RIPE and adopted by the RIPE NCC membership. randy From randy at psg.com Thu Aug 15 16:21:33 2002 From: randy at psg.com (Randy Bush) Date: Thu, 15 Aug 2002 07:21:33 -0700 Subject: [lir-wg] DNSSEC training WHY? References: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> <4.3.2.7.2.20020815133350.067ac130@localhost.ripe.net> Message-ID: >> Could someone please tell me WHY we are running free training courses >> for DNS? i think you are not reading daniel's comment sufficiently > The idea of DISI is to promote deployment of security relevant technology > **that needs to be deployed in the Infrastructure**, as opposed to > technology that is under individual organisation's responsibility. > > In particular the courses announced deal with DNSSEC technology and are > targeted at people thoroughly familiar with DNS itself. They are not > general purpose DNS courses. dnssec will affect the GLOBAL AND RIPE/NCC infrastructure and the ripe members will have to interface with it and coordinate. i.e. ripe/ncc and we will have to change the way we do things. so if ripe/ncc were not to experiment with this stuff and get us ready for it would be irresponsible. randy From nigel at packetexchange.net Thu Aug 15 17:35:04 2002 From: nigel at packetexchange.net (Nigel Titley) Date: 15 Aug 2002 15:35:04 +0000 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <057a01c24465$a5c9b2c0$2e04bf3e@eu.frd.uu.net> References: <057a01c24465$a5c9b2c0$2e04bf3e@eu.frd.uu.net> Message-ID: <1029425704.1624.90.camel@magrat> On Thu, 2002-08-15 at 14:11, Stephen Burley wrote: > > > > >Community outreach and education is part of stewardship. Making > > >sure members are knowledgeable about technical issues, allows them > > >to help form better policies. > > > > > Fine at no cost to those who do not benefit. > > > > >In the ARIN region, the members recently agreed that training > > >was useful, valuable and they supported it as a good use > > >of time and money. > > > > > No such agreement was made in RIPE region if it was it was not voiced to the > comunity at large. Back to Daniel's comment about DISI, which was part of the activity plan 2002, which was accepted by the RIPE NCC membership at the AGM, last October. All RIPE NCC members are entitled to attend and vote. I don't recall UUNET making use of that vote. Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part URL: From mguz at Scotland.net Thu Aug 15 16:37:45 2002 From: mguz at Scotland.net (Mark S. Guz) Date: Thu, 15 Aug 2002 15:37:45 +0100 Subject: [lir-wg] DNSSEC training WHY? References: <050a01c2444c$194a05c0$2e04bf3e@eu.frd.uu.net> Message-ID: <3D5BBCB9.4090609@Scotland.net> Stephen Burley wrote: > Hi > Could someone please tell me WHY we are running free training courses > for DNS? Training how to interact with the NCC and DB i understand, but dns > i do not. Who made the descision to implement this training and what grounds > are there for doing this? > > Regards, > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE > Surely this is relevant to NCC operations though. Could DNSSEC not be used in the delegation of in-addr.arpa zone info? And at any rate, I'm all for this as any extra value I get for my LIR subscription fee is fine by me and if it raises the general clue rating of all concerned then I say go for it. Of course if no course materialises in the UK(Edinburgh would be nice) then I may not be so enthusiastic. Just my 2p's worth! Regards Mark Guz MG241-RIPE Senior System/Network Engineer Scotland On Line. > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs SkyScan > service. For more information on a proactive anti-virus service working > around the clock, around the globe, visit http://www.messagelabs.com > ________________________________________________________________________ > > . > From gert at space.net Thu Aug 15 22:57:28 2002 From: gert at space.net (Gert Doering) Date: Thu, 15 Aug 2002 22:57:28 +0200 Subject: [lir-wg] DNSSEC training WHY? In-Reply-To: <057a01c24465$a5c9b2c0$2e04bf3e@eu.frd.uu.net>; from stephenb@uk.uu.net on Thu, Aug 15, 2002 at 03:11:28PM +0100 References: <057a01c24465$a5c9b2c0$2e04bf3e@eu.frd.uu.net> Message-ID: <20020815225728.Q27015@Space.Net> Hi, On Thu, Aug 15, 2002 at 03:11:28PM +0100, Stephen Burley wrote: > > >Community outreach and education is part of stewardship. Making > > >sure members are knowledgeable about technical issues, allows them > > >to help form better policies. > > Fine at no cost to those who do not benefit. Stephen - everybody benefits if people increase their clue factor about how to run a global network service like DNSSEC. Besides, as Daniel and others pointed out: if you don't want money spent for that, go to the AGM and vote against the budget for DISI. That's what the AGM is for. I, for one, am in favour of things like this. Lack of clue is costing much more than this small fraction of our fees spent on courses. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 46871 (46631) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From hph at online.no Thu Aug 15 23:26:02 2002 From: hph at online.no (Hans Petter Holen) Date: Thu, 15 Aug 2002 23:26:02 +0200 Subject: [lir-wg] Draft agenda Message-ID: <00a601c244a2$5b6e4820$7f00a8c0@no.tiscali.com> Dear lir-wg, Thanks to help from Leo we now have the following draft agenda. Please send me suggestions and updaes as nedded to prepare a relevant agenda for our meeting: The LIR Working Group session will be held on Wednesday 11 September 2002 from 09.00 - 12.30. Draft Agenda for RIPE 43 (version 0.1) 09:00 - 12:30 Wednesday, 11 September 2002 Chair: Hans Petter Holen Co-chair: Denesh Bhabuta A. Admin: Scribe Participant List, Charter, Mailing lists B. Agenda bashing C. RIPE 42 minutes and actions D. Report from the RIPE NCC Registration Services - Presentation by leo vegoda E. Report from the Address Council - Presentation F. IPv4 Assignment and Allocation Policy F.1 "Official Sub-Allocations" Proposal by Gert Doering G. Presentation of AC candiates X. Any other business Y. Summary of actions arising from this meeting Z. Open microphone ---------------------------------------------------------------------------- ---- For current issues, please turn to the LIR Working Group mailing list archives at: http://www.ripe.net/ripe/mail-archives/lir-wg/index.html More information about this working group is located at: http://www.ripe.net/ripe/wg/lir/index.html Best regards, --- Hans Petter Holen, Technical Manager, Tiscali, Norway, phone: +47 24 11 26 44 mobile: +47 99 21 76 70 fax:+47 24 11 24 11 From dave.wilson at heanet.ie Thu Aug 15 18:28:01 2002 From: dave.wilson at heanet.ie (Dave Wilson) Date: Thu, 15 Aug 2002 17:28:01 +0100 Subject: [lir-wg] Webcasting Meetings References: Message-ID: <3D5BD691.7090006@heanet.ie> >> I am formaly asking that if not RIPE 43 then all future meetings will be >>webcast so that all memebers who want to attend can attend the meeting. FWIW, HEAnet organised video streaming of the TERENA Networking Conference held in Limerick last June, an event of perhaps roughly the same size and complexity as RIPE. We got a *lot* of positive feedback, and it was especially useful for those who were hit by the concurrent airline strike and sudden news of KPNQwest's demise. However, I can assert that it was quite a lot of work, between preparing the hardware and overseeing each session, to do it properly. I think it would be a very good thing to see RIPE meetings webcast in the same way, but do please be aware that it soaks up more FTEs than is at first apparent. (If anyone at the RIPE NCC would like to talk to our guys about it, please drop me a mail). Dave From webmaster at ripe.net Fri Aug 16 15:37:57 2002 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Fri, 16 Aug 2002 15:37:57 +0200 Subject: [lir-wg] E-mail address masquerading for archived mail messages Message-ID: <200208161337.g7GDbvSe012969@birch.ripe.net> Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ================== From joao at ripe.net Fri Aug 16 19:04:00 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 16 Aug 2002 19:04:00 +0200 Subject: [lir-wg] Re: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: <3D5287FB.7070109@garr.it> References: <3D5287FB.7070109@garr.it> Message-ID: Dear Gabriella, we have been working on this process, not as fast as we would have liked to, I must admit. We will start by transferring ASNs. There are fewer and simpler cases when compared with IP address blocks and it will allow everyone to get a better understanding of the real amount of work involved, rather than just having an estimate, as good as it may be. As a matter of fact, we were going to send an announcement earlier today explaining the process, which is meant to start next week, but some internal problems have prevented this from happening. A message will be posted on Monday. It would be good to have some time during the lir-wg session at RIPE 43 to present the results of the first, relatively easy, step and close any issues people may have with the more complex transfer of the IP addresses. We could then proceed with the rest of the resources soon after the discussions at the RIPE meeting and in these lists. Best regards, Joao Damas RIPE NCC At 17:02 +0200 8/8/02, Gabriella Paolini wrote: >"Transferring InterNIC space from ARIN Database to other RIR databases". > >Any news about that? > >Regards, > >Gabriella Paolini >------------------------------------------------- >GARR - The Italian Academic and Research Network >http://www.garr.it >m at il: gabriella.paolini at garr.it >------------------------------------------------- From beri at kpnqwest.net Fri Aug 16 21:29:39 2002 From: beri at kpnqwest.net (Berislav Todorovic) Date: Fri, 16 Aug 2002 21:29:39 +0200 (CEST) Subject: [lir-wg] Re: Transferring InterNIC space from ARIN Database to other RIR databases In-Reply-To: Message-ID: Today I've got the following message from ARIN: [ --- From noreply at arin.net Fri Aug 16 21:28:37 2002 --- ] When the American Registry for Internet Numbers (ARIN) was formed in December 1997, they inherited the InterNIC database of IP addresses and AS numbers, and the responsibility to maintain the records in it. These records became known as early registrations. Discussions regarding early registrations have taken place amongst the Regional Internet Registries (RIRs) and throughout their communities. These RIRs include Asia Pacific Network Information Centre (APNIC), ARIN and the RIPE Network Coordination Centre (RIPE NCC). Discussion has also taken place in the emerging Latin American and Caribbean IP address Regional Registry (LACNIC) region. The decision was made that the interests of the resource holders would best be served by managing the resources through the RIR of the region in which they reside. You are receiving this message because you are listed as a point of contact (POC) for a registration that will be transferred to RIPE NCC within 30 days. For a list of resources to be transferred, or for more information on this this project, visit: http://www.arin.net/registration/erx You may address general and specific questions to hostmaster at arin.net. Regards, Registration Services ARIN On Fri, 16 Aug 2002, Joao Luis Silva Damas wrote: >> Dear Gabriella, >> >> we have been working on this process, not as fast as we would have >> liked to, I must admit. >> >> We will start by transferring ASNs. There are fewer and simpler cases >> when compared with IP address blocks and it will allow everyone to >> get a better understanding of the real amount of work involved, >> rather than just having an estimate, as good as it may be. >> >> As a matter of fact, we were going to send an announcement earlier >> today explaining the process, which is meant to start next week, but >> some internal problems have prevented this from happening. >> >> A message will be posted on Monday. >> >> It would be good to have some time during the lir-wg session at RIPE >> 43 to present the results of the first, relatively easy, step and >> close any issues people may have with the more complex transfer of >> the IP addresses. >> >> We could then proceed with the rest of the resources soon after the >> discussions at the RIPE meeting and in these lists. >> >> Best regards, >> >> Joao Damas >> RIPE NCC >> >> >> At 17:02 +0200 8/8/02, Gabriella Paolini wrote: >> >"Transferring InterNIC space from ARIN Database to other RIR databases". >> > >> >Any news about that? >> > >> >Regards, >> > >> >Gabriella Paolini >> >------------------------------------------------- >> >GARR - The Italian Academic and Research Network >> >http://www.garr.it >> >m at il: gabriella.paolini at garr.it >> >------------------------------------------------- >> >> --------- Berislav Todorovic, Senior IP Specialist -------- ------- KPNQwest N.V. - IP Engineering / NOC Support ------ ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- -- Email: beri at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From woeber at cc.univie.ac.at Mon Aug 19 14:37:25 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 19 Aug 2002 14:37:25 +0200 Subject: [lir-wg] DNSSEC training WHY? Message-ID: <00A12B16.66845EBA.9@cc.univie.ac.at> Hi Stephen! > [ ... ] >If you are going to start training this kind of thing is should be at >the very least on a subscription basis. I for one do not want to fund >the education of the entire ripe community. I feel this is wrong, it is >not part of our service agreement which is what we pay for, much the same >as the test traffic white elephant we funded for years. I am fully aware that some organisations now and then go through phases where any and all expenses are more tightly checked than in the past ;-) While the Annual Activity Plan issue has already been taken care of, there is another aspect which cannot (for the benfit of those who joined the community at a later date or who didn't follow the project in detail) be left standing without a comment: your "white elefant" claim, implying that the community funds a pet project for a minority: I have just today approved payment for the TTM Service invoice for ACOnet's testbox, amounting to 6K+ EUR. We have actually _bought_ the hardware, and we pay an _annual service_ fee. So it definitely IS a self-sufficient, _subscription based_ service offered by the NCC! Best regards, _________________________________:_____________________________________ 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 joao at ripe.net Mon Aug 19 17:24:17 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 19 Aug 2002 17:24:17 +0200 Subject: [lir-wg] Early Registration Transfer Project Message-ID: Dear Colleagues, Prior to the formation of the RIPE NCC, all Internet resources were issued by the InterNIC and its predecessors, based in the USA. The RIPE community has decided to transfer registrations of resources used in the RIPE NCC Service Region to the RIPE Whois Database. Initially we will transfer Autonomous System Number registrations. The work will start on 21 August 2002, with the transfer of ASN records. Contacts for all registrations to be transferred will be notified by a separate e-mail detailing the process. A brief report on the results of the transfer process will be made at RIPE 43 in Rhodes. During and after the RIPE 43 meeting there will be the opportunity to discuss any issues that may arise from the transfer of IPv4 registrations. A complete list of ASN registrations being transferred and details of the transfer process are available from our web site at: In the meantime should you have any further questions please contact us at: Kind regards, Joao Damas RIPE NCC From leo at ripe.net Mon Aug 19 18:02:22 2002 From: leo at ripe.net (leo vegoda) Date: Mon, 19 Aug 2002 18:02:22 +0200 Subject: [lir-wg] AS policy discussion - summary Message-ID: <20020819160222.GA14713@ripe.net> Dear Colleagues, Please find below a brief summary of the discussion on AS Numbers. This summary should provide input for further discussions at RIPE 43: In order to conserve AS numbers and routing table space, current policy only allows the assignment of an AS Number if a network is multi-homed. It is difficult if not impossible to reliably verify if a network is multi-homed soley by looking at the routing tables. Nonetheless, it was proposed that where a reciprocal routing policy is published in the Routing Registry it is very likely that multi-homing is in place. While reclamation of unused AS numbers was not a point of contention, no definition of "usage" was achieved. No conclusion was reached although varying proposals were brought forward. Therefore we suggest that each month the RIPE NCC publish a list of assigned AS numbers and their status. The information will be drawn from the IRR and the RIS project. Best regards, -- leo vegoda RIPE NCC Registration Services From hank at att.net.il Mon Aug 19 21:24:53 2002 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 19 Aug 2002 22:24:53 +0300 (IDT) Subject: [lir-wg] Early Registration Transfer Project In-Reply-To: Message-ID: On Mon, 19 Aug 2002, Joao Luis Silva Damas wrote: The process is not working. Based on: http://www.arin.net/registration/erx/index.html I should have been notified Aug 15 about AS378. I wasn't. So I checked another Israeli "early" ASN. AS1680 also didn't get any notification email. ARIN can say they are notifying those listed in their whois, but I can only assume they have a bug in their software and proper email notifications are *not* going out to all early ASNs. -Hank > Dear Colleagues, > > Prior to the formation of the RIPE NCC, all Internet resources > were issued by the InterNIC and its predecessors, based in the > USA. The RIPE community has decided to transfer registrations > of resources used in the RIPE NCC Service Region to the RIPE > Whois Database. > > Initially we will transfer Autonomous System Number registrations. > The work will start on 21 August 2002, with the transfer of ASN > records. Contacts for all registrations to be transferred will > be notified by a separate e-mail detailing the process. > > A brief report on the results of the transfer process will be made > at RIPE 43 in Rhodes. During and after the RIPE 43 meeting there > will be the opportunity to discuss any issues that may arise > from the transfer ofIPv4 registrations. > > A complete list of ASN registrations being transferred and details > of the transfer process are available from our web site at: > > > > In the meantime should you have any further questions please > contact us at: > > Kind regards, > > Joao Damas > RIPE NCC > From JimFleming at ameritech.net Tue Aug 20 16:07:19 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Tue, 20 Aug 2002 09:07:19 -0500 Subject: [lir-wg] "The process is not working." ?? Message-ID: <01c701c24852$e747dd80$8c56fea9@repligate> From: "Hank Nussbacher" "The process is not working." ===== There are many things on the "toy" 32-bit Internet which do not work properly. It is a good place to sort things out before moving to the serious 128-bit DNS run by commercial companies that provide flawless service. Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.ican.org/what's_new!!!.htm http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt ----- Original Message ----- From: "Hank Nussbacher" To: "Joao Luis Silva Damas" Cc: ; Sent: Monday, August 19, 2002 2:24 PM Subject: Re: [lir-wg] Early Registration Transfer Project > On Mon, 19 Aug 2002, Joao Luis Silva Damas wrote: > > The process is not working. Based on: > http://www.arin.net/registration/erx/index.html > I should have been notified Aug 15 about AS378. I wasn't. So I checked > another Israeli "early" ASN. AS1680 also didn't get any notification > email. ARIN can say they are notifying those listed in their whois, but I > can only assume they have a bug in their software and proper email > notifications are *not* going out to all early ASNs. > > -Hank > > > Dear Colleagues, > > > > Prior to the formation of the RIPE NCC, all Internet resources > > were issued by the InterNIC and its predecessors, based in the > > USA. The RIPE community has decided to transfer registrations > > of resources used in the RIPE NCC Service Region to the RIPE > > Whois Database. > > > > Initially we will transfer Autonomous System Number registrations. > > The work will start on 21 August 2002, with the transfer of ASN > > records. Contacts for all registrations to be transferred will > > be notified by a separate e-mail detailing the process. > > > > A brief report on the results of the transfer process will be made > > at RIPE 43 in Rhodes. During and after the RIPE 43 meeting there > > will be the opportunity to discuss any issues that may arise > > from the transfer ofIPv4 registrations. > > > > A complete list of ASN registrations being transferred and details > > of the transfer process are available from our web site at: > > > > > > > > In the meantime should you have any further questions please > > contact us at: > > > > Kind regards, > > > > Joao Damas > > RIPE NCC > > > > From joao at ripe.net Wed Aug 21 18:17:27 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 21 Aug 2002 18:17:27 +0200 Subject: [lir-wg] Early Registration Transfer Project In-Reply-To: References: Message-ID: Update to the list: At 22:24 +0300 19/8/02, Hank Nussbacher wrote: >On Mon, 19 Aug 2002, Joao Luis Silva Damas wrote: > >The process is not working. Based on: >http://www.arin.net/registration/erx/index.html >I should have been notified Aug 15 about AS378. I wasn't. So I checked >another Israeli "early" ASN. AS1680 also didn't get any notification >email. ARIN can say they are notifying those listed in their whois, but I >can only assume they have a bug in their software and proper email >notifications are *not* going out to all early ASNs. > >-Hank We have been in touch with Hank. For reasons as yet unknown the mail is not in his mailbox, even though the automated acknowledgment was received by ARIN, so the mail reached that mail address and was accepted for local delivery. Also, for AS1680, the mail server exchanges indicate that the user's mail servers accepted mail for local delivery and there were no bounces. We take these matters seriously and are concerned with providing the best possible service. If you have any concerns about this process, please send email to er-transfer at ripe.net regards, Joao Damas RIPE NCC From krazavi at dpimail.net Thu Aug 22 20:50:48 2002 From: krazavi at dpimail.net (Cathy) Date: Thu, 22 Aug 2002 23:20:48 +0430 Subject: [lir-wg] Message-ID: <009401c24a0c$d509fde0$d83d1dd5@home> Hi all Who knows how can i Register the assigment in Database ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus at ri.st Thu Aug 22 21:24:18 2002 From: marcus at ri.st (Marcus Rist) Date: Thu, 22 Aug 2002 21:24:18 +0200 Subject: [lir-wg] In-Reply-To: <009401c24a0c$d509fde0$d83d1dd5@home>; from krazavi@dpimail.net on Thu, Aug 22, 2002 at 11:20:48PM +0430 References: <009401c24a0c$d509fde0$d83d1dd5@home> Message-ID: <20020822212418.D1098@c3po.netplace.de> Hi Cathy, Cathy wrote To lir-wg at ripe.net: > Who knows how can i Register the assigment in Database ? A good start would be to read http://www.ripe.net/ripe/docs/databaseref-manual.html and to visit a LIR training course. Cheers -Marcus -- Marcus Rist Don't hit a man when he's down -- kick him; it's easier. From leo at ripe.net Mon Aug 26 13:05:54 2002 From: leo at ripe.net (leo vegoda) Date: Mon, 26 Aug 2002 13:05:54 +0200 Subject: [lir-wg] FW: Proposal for Transfer of 6bone Address Management Responsibilities to RIRs Message-ID: <20020826110554.GC14417@ripe.net> Dear Colleagues, It has been proposed that the management of the 6bone 3FFE::/16 address space be transferred to the Regional Internet Registries (RIRs). More information about the 6bone can be obtained at: At a recent 6bone meeting, Bob Fink made a proposal for this management transfer. A copy of the presentation slides are available at: or at: These presentation slides were based on the text, "Policies for transfer of 6bone address management responsibilities to RIRs," provided below. Please send your comments about this proposal to the LIR WG mailing list . The 6bone and other RIRs will be conducting similar reviews within their communities and the RIPE NCC will summarise the collective responses, issues, and concerns, made in regard to this proposal. This review process will end on December 31, 2002. Regards, -- leo vegoda RIPE NCC Registration Services ----- Forwarded message ----- ******************* Policies for transfer of 6bone address management responsibilities to RIR Version: 20 August 2002 1. Introduction 6bone was established in 1996 as a continuing IPv6 test bed with the original purpose of testing of standards and implementations, and the more current focus on testing of transition and operational procedures, as well as application conversion. It provides an opportunity for those wanting early experience and/or needing to experiment with IPv6, with a minimum of startup complexity, particularly in terms of address management policies, and at minimal cost. It also provides an open peer process for information, hookup help, and support, with strong ties to the IETF process as well as to the operational community. To date, 6bone address space has been allocated and registered in an informal process quite separate from the existing Regional Internet Registry system. The purpose of this proposal is to establish a long term model that provides for a more "official" home for 6bone address space management within the established Internet administrative structures. At the same time, the proposal recognizes that 6bone's most important functions as an accessible and informal test bed network must be maintained. This document proposes the transfer of responsibility for administration of 6bone address space (3ffe::/16) to the Regional Internet Address Registries (RIRs). It describes a set of policies and procedures for this transfer, and for the ongoing administration of 6bone address space within the RIR framework. It should be noted that the ongoing operation of the 6bone, and policies related to it, are still the purview of the 6bone community itself. For example, 6bone network compliance with the 6bone routing guidelines is a matter for the community itself to resolve, typically by mail lists. It is also important to continue the strongly volunteer efforts of the 6bone, both to make it as easy and friendly as possible for individuals, sites and networks to experiment and learn about IPv6, but also to keep the process streamlined and cost-effective. 2. Definitions a) "6bone" and "6bone community", as it appears in section 3 below, means 6bone organizations and individuals including the RIRs, "6bone members" (see below), and those participating in the 6bone mail list. b) 6bone members are defined as entities which are approved for address space allocation by the 6bone community in accordance with 6bone policies, and who agree to be bound by those policies and the policies stated below. c) 6bone allocations are allocations of 6bone address space which are held by 6bone members, or made to 6bone members in accordance with these policies. d) 6bone address space is defined as IPv6 address space within the 3ffe::/16 address block. 3. Policies 3.1 General a) In consultation with 6bone, RIRs will implement a common set of policies applying specifically to 6bone allocations. This will follow the current RFC2772, "6Bone Backbone Routing Guidelines" and/or successor documents resulting as an evolution of conversations in the 6bone community and the RIRs.; b) 6bone members will be served by respective RIR in their region, for "6bone Address Services" including 6bone address allocation, database registration and maintenance, and ip6.arpa registration (as described below); c) In order to receive 6bone address services from an RIR as described here, each 6bone member must "join" that RIR, that is, enter into the appropriate membership or services agreement with the RIR. d) RIR fees will be waived for 6bone address services provided by RIRs to 6bone members (but not for other services 6bone members may require), until 1 year after this agreement starts. After this time each RIR may charge an administration fee to cover each allocation made. This fee simply covers registration and maintenance, rather than the full allocation process for standard RIR members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. e) Organizations may receive 6bone address services from the RIR only on approval by 6bone, and in accordance with these policies; f) 6bone members will have the option to receive other services from an RIR (including allocation of production IPv6 address space), by following the policy, process and procedures in place at the time of application for those services. g) Continuing compliance with 6bone policies, and with the policies defined here, will be verified by 6bone at least every 2 years; 3.2 6bone Address Services a) 6bone Address Services include allocation of 6bone address space, registration and maintenance of database records relating to that address space, and registration of ip6.arpa records; b) 6bone address space allocations will be made from 3ffe::/16 and only /32 prefixes will be allocated. There will be exceptions for unusual and new proposals per joint RIR and 6bone review and approval. A relevant example of this is one or more new strategies such as geographic or metro addressing; c) No additional 6-bone address space will be allocated to any 6bone member (therefore no provision will be made for aggregation of multiple allocations, reservations etc); d) 6bone address services will be provided strictly for experimental, non-commercial use; e) Allocations will be made on the clear and stated understanding that the prefix 3ffe::/16 has a limited lifetime. The dates for the termination of allocation from the prefix and the expiration of the prefix will be determined at a future date. The RIRs will not participate in these determinations. f) 6bone address space will be returned to the RIR when no longer in use, when reclaimed due to non-compliance with 6bone or RIR policies, or when 3ffe: space is finally withdrawn; g) Registration of 6bone address space within the ip6.int zone is not covered by this policy, and is at option of 6bone member; h) Registration of 6bone sites, maintainers, persons and address space within the existing consolidated 6bone registry is not covered by this policy, and is at option of 6bone and its current policies. 3.3 Transfer of existing 6bone members a) Responsibility for existing 6bone members in respect of services described here will be transferred from 6bone to the respective RIR, at the option of those members individually, on entering into the appropriate agreement with the RIR; b) On joining the RIR, 6bone address registration records for the member concerned will be transferred from 6bone registry to the respective RIR database; c) On joining the RIR, 6bone members may establish ip6.arpa delegation records in accordance with applicable RIR procedures; d) Legacy holders will use RIR administrative procedures for management of their records; e) There will be a sunset (2 years?) on existing 6bone members not transferring to RIR administrative procedures, after which their address allocation will be revoked. ----- End forwarded message ----- From gert at space.net Thu Aug 29 15:30:40 2002 From: gert at space.net (Gert Doering) Date: Thu, 29 Aug 2002 15:30:40 +0200 Subject: [lir-wg] Action from RIPE 42: Sub-Allocations revisited Message-ID: <20020829153040.M27015@Space.Net> Hi, and once again, the suballocation topic. On RIPE42 in Amsterdam, the feedback was pretty much non-existant, so nothing has been decided on this proposal. I still think it's useful. Not for all LIRs, but for the larger ones that have a multi-level reseller hierarchy, or maybe a multi-national internal hierarchy (Stephen and the MIR thing). In the last months, I've heard a few comments from different sides that "hmm, yes, this could be exactly what we need". Also, APNIC is working on a similar proposal for their community. Please read the following thoughts, and form an opinition. (It's a bit repetitive, as a couple of questions have come up again that are already answered in the draft). If you're in favour of it, please voice it. If you don't think it's useful, but don't see any harm coming from it, please voice that as well (please don't just write "this is crap!" unless you're convinced that nobody else can benefit from it either, and it will do more harm than good). If you *do* think it's complete crap and will destroy the whole RIPE structure, please by all means voice that as well :-) Gert Doering -- NetMaster ------------- snip ------------- Motivation: - Some LIRs have internal hierarchies, like "resellers that have their own end customers". - For aggregation reasons internal to the LIR network, LIRs "allocate" address space to their resellers ("hierarchical sub-LIRs"), who then "assign" addresse from that to their customers. Usually the LIR has to approve all end-user requests, but the sub-LIR is doing the actual assignment from the "allocated" space. - The current policy doesn't explicitely permit this, but acknowledges to some extent that it is done. - When the LIR goes to the RIR to get another allocation, the 80% rule does not take into account the fact that some of the "not assigned" space may be in fact "sub-allocated" to a "sub-LIR", thus it may be very hard to reach 80% (and will lead to internal fragmentation). (This is what Wilfried calls "reservation") - The sub-allocations are not documented, so an outsider cannot see who might be the best contact (the reseller!) if one of the end customers misbehaves (this part could be solved with "LIR-PARTITIONED"). Proposal: - permit LIRs to sub-allocate the address allocation they receive from a RIR to "downstream parties", from now on called sub-LIRs - the Sub-Allocations are documented as an inetnum: object with "status: SUB-ALLOCATED PA" in the RIPE database. I do not like "LIR-PARTITIONED", because it isn't partitioned ("equal parts"), and also because it doesn't go far enough. - All assignments from the Sub-Allocation are done by the Sub-LIR. The Sub-LIR is responsible to the LIR for following policies and procedures. The LIR is responsible to the RIR for making sure that the Sub-LIR follows the procedures. This is no big difference from what is being *done* now, it's just "officially documented". - When the LIR has to apply for an additional allocation, the Sub-Allocation are counted for the "80% utilization rule". So, to show an extreme example, a LIR that has sub-allocated 90% to its resellers, and they have only assigned a total of 30% of the total allocation yet, the LIR *would be* entitled to get a new allocation (under the current policy, it is not). In extreme cases, it might be necessary to show lots of good documentation to the RIR as for "why did you allocate so much". Points of Concern: - "They will just waste address space". Yes, it will waste some space, due to better aggregation. It is not expected that this will waste space due to "sloppyness" in following the policies and procedures - each hierarchy level will be fully responsible for making sure that the next-lower level will understand the rules and follow them. It is similar to what IANA and the RIRs do. The RIRs try to hand out address space in a responsible way (which does not always succeeed, which is why changes to the procedures are made, like /19 -> /20 for the initial allocation), and in this proposal, the LIRs have to hand out space to the sub-LIRs in a responsible way. If the RIRs mess up, they have a problem with IANA, if the LIRs mess up, they have a problem with their RIR. - "How big shall the sub-allocation be"? The exact numbers for the default case would have to be defined. Again, this is similar to the RIR->LIR case. A LIR by default gets a /20, but might get a bigger space in case it produces a good forecast that shows a reasonable need for a bigger space. I propose to give a Sub-LIR a /24 to start with, except in cases that they show evidence for needing more. Rationale: it's not too much, and you can delegate DNS on /24 boundaries without ugly tricks. When the Sub-Allocation is used up (= 80% of the space in there is ASSIGNED), the Sub-LIR can ask for more. If a customer asks for more space than the Sub-LIR has left, the Sub-Allocation can also be increased / a new Sub-Allocation be made. As a starting point for the discussion, I propose: - minimum size of a Sub-Allocation: /24 (because that's what's needed to be able to properly delegate the reverse DNS zone) - maximum size of a Sub-Allocation: 4x AW per year and sub-LIR (the number "4" here is of course open for discussion) - if a bigger size is required, go through NCC hostmasters alternatively one could introduce a new "Sub-Allocation-AW", but that's even more bureaucracy. - "What's the size of networks a Sub-LIR can assign to their customers"? It can not go over the AW of the LIR. This part is fixed due to the RIR/LIR relation. As for the rest, I propose that this should be a matter between the LIR and the Sub-LIR. They have a contract, and it's the LIRs job to make sure that the Sub-LIR follows the official policies and procedures, maybe introducing their own Sub-AW per Sub-LIR etc. Thoughts and Considerations from the RIPE NCC (Leo Vegoda): 1. How should the RIPE NCC act when a further allocation is requested if the existing allocation is not at "about 80%" usage (when used means valid assignments) - but "about 80%" is used in assignments and sub-allocations? Answer: see above in the "Motivation" block. The idea is that Sub-Allocations are considered "usage", so if (for example) 40% is ASSIGNED and another 40% is SUB-ALLOCATED, 80% usage is achieved. What percentage of the SUB-ALLOCATED space is actually ASSIGNED is not considered. So the answer is "if all other things are fine, a new allocation should be made". It is envisioned that the NCC hostmasters are going to ask nasty questions if the percentage of SUB-ALLOCATED is "overly" high and the percentage of end-user assignments overall is "overly" low (exact values to be defined). 2. If the RIPE NCC should count a "sub-allocation" as used then should it take account of the degree of assignment in the sub-allocations? If so, what degree should be assigned from them? Answer: I think that the number of end-user assignments made inside sub-allocations should not be a hard criterium (like the 80% rule). I do think that very low ratios should lead to nasty questions. I do also think that this should be compared to the IANA/RIR level - if a RIR comes back to IANA because all /8s have been "used up" (by allocating to LIRs), IANA doesn't consider the actual usage ratio *inside* the allocations, as long as the RIR has been following its rules for "under which circumstances is it permitted to make an allocation, and which size is OK". 3. Should there be a maximum size an LIR can sub-allocate? If so, what size? (I know you've previously proposed a /24 as a default or minimum size). Answer: see above (yes, but the exact number has to be decided upon). 4. Should holders of a sub-allocation be allowed to sub-allocate, too? This is allowed in IPv6. Should IPv4 be different? Answer: I can see arguments for both sides - sub-sub-allocations might not really make sense in IPv4 (not enough bits to do so much hierarchy), but then, it might make sense in some networks. I'd leave this one to the community for a decision. 5. LIRs are contractually obliged to follow the RIPE community's policies. Is it possible to enforce any requirement for a holder of a sub-allocation to follow those policies, too? Answer: The LIR has signed that it will obey all policies. So it would be part of those to enforce the RIPE rules onto the Sub-LIR as well (by an appropriate contract). This would have to be made very explicit in the "sub-allocation policy document". 6. If an LIR makes a sub-allocation this is presumably becasue it trusts the re-seller to administer the space responsibly and wants to delegate responsibility for the assignments. This implies that the LIR would place the re-seller's mnt-lower on the sub- allocation allowing the re-seller to assign without returning to the LIR. However, this would remove control over that portion of address space from the LIR. Would this policy require the reclaim attribute to be implemented in the Database? Answer: this is something to be worked out with the database WG, but to avoid trouble with the RIPE DB entries when a Sub-LIR "goes away" without cleaning up their entries, this is considered useful. 7. Database rules would have to be made as for what kind of "nesting" is permitted (SUB-ALLOCATED PA is only permitted inside another SUB-ALLOCATED or ALLOCATED PA, not inside "* PI", and so on). Answer: yes, of course. Other Comments (various sources) * this will generate a radical new structure (two-level RIR/LIR to multi-level) Answer: yes, this is the intention. * Considering the address wastage - it might not actually waste that much space, if it means some "Sub-LIRs" will not become full-sized LIRs (with a /20 each) but are happy with a /22 Sub-Allocation. So maybe it will even reduce the new-LIR rush in the progress. * Would this mean that the existing AWs would have to be reviewed (to make sure that these LIRs do not mis-use their AW to create lots of useless Sub-Allocations)? Answer: I don't think so. Maybe one need to do some kind of "small audit" on sub-allocated ranges after a few month, to get experience with this. -- Total number of prefixes smaller than registry allocations: 46611 (45583) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pieterjan at itn.skynet.be Thu Aug 29 16:39:44 2002 From: pieterjan at itn.skynet.be (D'HERTOG Pieterjan) Date: Thu, 29 Aug 2002 16:39:44 +0200 Subject: [lir-wg] AS1 in ripe db ? Message-ID: Look what I discovered in the RIPE DB... aut-num: AS1 as-name: NETS-AS descr: NetServices Autonomous System Number admin-c: TBNS1-RIPE tech-c: MK2488-RIPE notify: hostmaster at switchworld.nl mnt-lower: NETS-MNT mnt-routes: NETS-MNT mnt-by: NETS-MNT changed: hostmaster at switchworld.nl 20020814 source: RIPE Should be bbn planet no ? whois -h rr.arin.net AS1 % ARIN Internet Routing Registry Whois Interface aut-num: AS1 as-name: ASN-GTEI descr: GTE Internetworking import: from AS3847 action pref=50; accept ANY import: from AS5646 action pref=50; accept ANY export: to AS3847 announce ANY export: to AS5646 announce ANY admin-c: BBN Planet NOC tech-c: BBN Planet NOC remarks: For Spam complaints, send mail to "abuse at bbnplanet.com" For network related issues, send mail to "ops at bbnplanet.com" or call +1 781 262 6186 notify: corp-neteng at bbnplanet.com mnt-by: BBNPLANET changed: smeuse at bbnplanet.com 19990929 source: RADB --- Pieterjan d'Hertog, Senior Network Engineer Belgacom Skynet NV/SA, 2 Rue Carli, B-1140 Brussels Phone +3227061311 Fax +3227061150 http://www.skynet.be PGP fingerprint: D9AB CD6A 2A78 73CC 68BF 0AFA 8FB3 5821 E4BB 9D2E From andrei at ripe.net Thu Aug 29 18:21:08 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 29 Aug 2002 18:21:08 +0200 Subject: [lir-wg] AS1 in ripe db ? References: Message-ID: <3D6E49F4.7000406@ripe.net> Dear Pieterjan d'Hertog, D'HERTOG Pieterjan wrote: > Look what I discovered in the RIPE DB... > > aut-num: AS1 > as-name: NETS-AS > descr: NetServices Autonomous System Number > admin-c: TBNS1-RIPE > tech-c: MK2488-RIPE > notify: hostmaster at switchworld.nl > mnt-lower: NETS-MNT > mnt-routes: NETS-MNT > mnt-by: NETS-MNT > changed: hostmaster at switchworld.nl 20020814 > source: RIPE > > Should be bbn planet no ? This ASN space is allocated to ARIN as indicated by the as-block AS1 - AS6. Data in the RIPE Database registered within this block is not authoritative. Unfortunately at the moment we cannot protect ASN space allocated to ARIN and APNIC as this will make impossible creation of route objects with originating AS from this space. We are working on implementation of cross-registry authorisation in the RIPE Database, which will allow us to lock this space. This aut-num, AS1, should not be in the RIPE Database. We will contact the owners of this object and ask them to delete it. > > whois -h rr.arin.net AS1 > > % ARIN Internet Routing Registry Whois Interface > > aut-num: AS1 > as-name: ASN-GTEI > descr: GTE Internetworking > import: from AS3847 > action pref=50; > accept ANY > import: from AS5646 > action pref=50; > accept ANY > export: to AS3847 > announce ANY > export: to AS5646 > announce ANY > admin-c: BBN Planet NOC > tech-c: BBN Planet NOC > remarks: For Spam complaints, send mail to "abuse at bbnplanet.com" > For network related issues, send mail to "ops at bbnplanet.com" > or call +1 781 262 6186 > notify: corp-neteng at bbnplanet.com > mnt-by: BBNPLANET > changed: smeuse at bbnplanet.com 19990929 > source: RADB > > --- > Pieterjan d'Hertog, Senior Network Engineer > Belgacom Skynet NV/SA, 2 Rue Carli, B-1140 Brussels > Phone +3227061311 Fax +3227061150 http://www.skynet.be > PGP fingerprint: D9AB CD6A 2A78 73CC 68BF 0AFA 8FB3 5821 E4BB 9D2E Regards, Andrei Robachevsky DB Group RIPE NCC From chr at jay.net Thu Aug 29 20:11:06 2002 From: chr at jay.net (Christian Rasmussen) Date: Thu, 29 Aug 2002 20:11:06 +0200 Subject: [lir-wg] Action from RIPE 42: Sub-Allocations revisited In-Reply-To: <20020829153040.M27015@Space.Net> Message-ID: Hi, I think this is a very useful proposal. Several of our customers are ISPs themselves and intends to become LIR when they have utilization of a /22. Until then the procedure for registering their assignments is a bit complicated, the main problems are that we cannot let our customer take care of the administrative part - we have to be in contact with their customer and when allocating/reserving an IP net for the customer, we get a problem when requesting a new allocation from Ripe (80% rule). > Proposal: > > - permit LIRs to sub-allocate the address allocation they receive from > a RIR to "downstream parties", from now on called sub-LIRs > > - the Sub-Allocations are documented as an inetnum: object with > "status: SUB-ALLOCATED PA" in the RIPE database. I do not like > "LIR-PARTITIONED", because it isn't partitioned ("equal parts"), and > also because it doesn't go far enough. > I also believe "SUB-ALLOCATED PA" is more appropriate. > Points of Concern: > > - "How big shall the sub-allocation be"? > > The exact numbers for the default case would have to be defined. > > Again, this is similar to the RIR->LIR case. A LIR by default gets > a /20, but might get a bigger space in case it produces a good > forecast that shows a reasonable need for a bigger space. > > I propose to give a Sub-LIR a /24 to start with, except in cases that > they show evidence for needing more. Rationale: it's not too much, > and you can delegate DNS on /24 boundaries without ugly tricks. > > When the Sub-Allocation is used up (= 80% of the space in there is > ASSIGNED), the Sub-LIR can ask for more. If a customer asks for more > space than the Sub-LIR has left, the Sub-Allocation can also be > increased / a new Sub-Allocation be made. > > As a starting point for the discussion, I propose: > > - minimum size of a Sub-Allocation: /24 > (because that's what's needed to be able to properly delegate > the reverse DNS zone) > - maximum size of a Sub-Allocation: 4x AW per year and sub-LIR > (the number "4" here is of course open for discussion) > - if a bigger size is required, go through NCC hostmasters > > alternatively one could introduce a new "Sub-Allocation-AW", but > that's even more bureaucracy. In my oppinion it should be closer to a /22. If its only a /24 it has to be split into quite many subnets before its worth the effort of "setting up" a sub-LIR.. But I don't see much point in allocating a larger net than /22, if larger is needed and growth expected then it would be better to set up a normal LIR. Yes, a "Sub-Allocation-AW" might be an idea, but I think it should be a matter between the LIR and the sub-LIR, no reason to bother Ripe with this. > > > - "What's the size of networks a Sub-LIR can assign to their customers"? > > It can not go over the AW of the LIR. This part is fixed due to the > RIR/LIR relation. > > As for the rest, I propose that this should be a matter between the > LIR and the Sub-LIR. They have a contract, and it's the LIRs job to > make sure that the Sub-LIR follows the official policies and > procedures, maybe introducing their own Sub-AW per Sub-LIR etc. > The LIR acts as a RIR, so the sub-LIR sends ripe-219 applications to the LIR and the LIR approves according to AW, if the request is larger than AW it is forwarded to Ripe NCC hostmasters (just as normal IP requests). > > Thoughts and Considerations from the RIPE NCC (Leo Vegoda): > > 1. How should the RIPE NCC act when a further allocation is > requested if the existing allocation is not at "about 80%" usage > (when used means valid assignments) - but "about 80%" is used in > assignments and sub-allocations? > > Answer: see above in the "Motivation" block. The idea is that > Sub-Allocations are considered "usage", so if (for example) > 40% is ASSIGNED and another 40% is SUB-ALLOCATED, 80% usage > is achieved. What percentage of the SUB-ALLOCATED space is > actually ASSIGNED is not considered. > > So the answer is "if all other things are fine, a new > allocation > should be made". > > It is envisioned that the NCC hostmasters are going to ask > nasty questions if the percentage of SUB-ALLOCATED is > "overly" high and the percentage of end-user > assignments overall > is "overly" low (exact values to be defined). > It would be a problem if specific percentages dictates if another allocation is possible or not, since their could be valid reasons for even extreme situations. But in general it might be prudent to go through the documented need for the sub-allocations when requesting a new allocation. > > 2. If the RIPE NCC should count a "sub-allocation" as used then > should it take account of the degree of assignment in the > sub-allocations? If so, what degree should be assigned from them? > > Answer: I think that the number of end-user assignments made inside > sub-allocations should not be a hard criterium (like the > 80% rule). I do think that very low ratios should lead to > nasty questions. > > I do also think that this should be compared to the IANA/RIR > level - if a RIR comes back to IANA because all /8s have been > "used up" (by allocating to LIRs), IANA doesn't consider the > actual usage ratio *inside* the allocations, as long as the RIR > has been following its rules for "under which circumstances is > it permitted to make an allocation, and which size is OK". > No, I don't think it would make sense if Ripe NCC had to go into the degree of assignments of a LIRs sub-LIRs when deciding to do another allocation. But again, its important that the sub-allocations are properly documented (and valid), that should instead be the criterium. > > 3. Should there be a maximum size an LIR can sub-allocate? If so, > what size? (I know you've previously proposed a /24 as a default > or minimum size). > > Answer: see above (yes, but the exact number has to be decided upon). > I would think it would be better if the sub-LIR instead setup a normal LIR in case the need was larger than a /22, or would people prefer sub-LIRs with /20 allocations or larger? In my oppinion the sub-LIR status should only be temporary until the customers address utilization had passed /22. > > 4. Should holders of a sub-allocation be allowed to sub-allocate, > too? This is allowed in IPv6. Should IPv4 be different? > > Answer: I can see arguments for both sides - sub-sub-allocations might > not really make sense in IPv4 (not enough bits to do so much > hierarchy), but then, it might make sense in some networks. > > I'd leave this one to the community for a decision. No, in that case the sub-LIR would probably have a need of quite many addresses, and therefore it would be better to set up a LIR. > > > 5. LIRs are contractually obliged to follow the RIPE community's > policies. Is it possible to enforce any requirement for a holder > of a sub-allocation to follow those policies, too? > > Answer: The LIR has signed that it will obey all policies. So it would > be part of those to enforce the RIPE rules onto the Sub-LIR > as well (by an appropriate contract). This would have to be > made very explicit in the "sub-allocation policy document". > It is the responsibility of the LIR that ALL assignments (also those from sub-allocations) are valid according to policies. A contract like the one between LIRs and RIRs might be a good idea between the LIR and the sub-LIR too. > > 6. If an LIR makes a sub-allocation this is presumably becasue it > trusts the re-seller to administer the space responsibly and > wants to delegate responsibility for the assignments. This implies > that the LIR would place the re-seller's mnt-lower on the sub- > allocation allowing the re-seller to assign without returning to > the LIR. However, this would remove control over that portion of > address space from the LIR. Would this policy require the reclaim > attribute to be implemented in the Database? > > Answer: this is something to be worked out with the database WG, > but to avoid trouble with the RIPE DB entries when a Sub-LIR > "goes away" without cleaning up their entries, this is > considered useful. > Yes, I believe its necessary that the LIR can somehow overrule everything done in the Ripe DB by the sub-LIR. A few things I would like to add to this proposal: It might also be a good idea if the Ripe NCC keeps a record of all the sub-LIRs, especially if/when the sub-LIR decides to become a LIR. The sub-LIR should also be allowed to assign its own infrastructure within the sub-allocation. The Ripe-219 should as default describe whether its a LIR or a sub-LIR assignment. Some sort of fee for registering as a sub-LIR might be appropriated, at least to make sure not everybody suddenly wants to be sub-LIR! But maybe the decision should be made by the individual LIRs. I would assume that the LIR have to take care of all questions the sub-LIR might have regarding policies, RIPE DB entries and so on. If all future LIRs have first been sub-LIRs it should make it easier for the Ripe NCC hostmasters when setting up the LIRs and doing the first assignments. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager jay.net a/s From stephenb at uk.uu.net Fri Aug 30 12:33:50 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Fri, 30 Aug 2002 11:33:50 +0100 Subject: [lir-wg] Action from RIPE 42: Sub-Allocations revisited Message-ID: <015601c25010$bab7ed30$2e04bf3e@eu.frd.uu.net> My first comment - BTW this is a well outlined. - All assignments from the Sub-Allocation are done by the Sub-LIR. The Sub-LIR is responsible to the LIR for following policies and procedures. The LIR is responsible to the RIR for making sure that the Sub-LIR follows the procedures. This is no big difference from what is being *done* now, it's just "officially documented". I feel the Sub-LIR should still be responsible to RIPE for approvals etc. Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE From mjrobinson at genuity.net Fri Aug 30 10:15:36 2002 From: mjrobinson at genuity.net (Matthew Robinson) Date: Fri, 30 Aug 2002 09:15:36 +0100 Subject: [lir-wg] AS1 in ripe db ? In-Reply-To: Message from Andrei Robachevsky of "Thu, 29 Aug 2002 18:21:08 +0200." <3D6E49F4.7000406@ripe.net> Message-ID: <200208300815.g7U8Fa5j028155@asparagus.localnet> > Dear Pieterjan d'Hertog, > > D'HERTOG Pieterjan wrote: > > Look what I discovered in the RIPE DB... > > > > aut-num: AS1 > > as-name: NETS-AS > > descr: NetServices Autonomous System Number > > admin-c: TBNS1-RIPE > > tech-c: MK2488-RIPE > > notify: hostmaster at switchworld.nl > > mnt-lower: NETS-MNT > > mnt-routes: NETS-MNT > > mnt-by: NETS-MNT > > changed: hostmaster at switchworld.nl 20020814 > > source: RIPE > > > > Should be bbn planet no ? Well, we're called Genuity now but yes it's our North American ASN. Around Europe we're better known as AS7176. > This ASN space is allocated to ARIN as indicated by the as-block AS1 - > AS6. Data in the RIPE Database registered within this block is not > authoritative. > > Unfortunately at the moment we cannot protect ASN space allocated to > ARIN and APNIC as this will make impossible creation of route objects > with originating AS from this space. We are working on implementation of > cross-registry authorisation in the RIPE Database, which will allow us > to lock this space. Would it be worth registering AS1 correctly in the RIPE db as well as ARIN (and RADB) or will this simply cause confusion? > This aut-num, AS1, should not be in the RIPE Database. We will contact > the owners of this object and ask them to delete it. Many thanks for this, I'll pop the lawyers back in their cage for the moment ;-) Kind regards Matthew