From gert at space.net Wed Oct 4 10:09:22 2006 From: gert at space.net (Gert Doering) Date: Wed, 4 Oct 2006 10:09:22 +0200 Subject: [address-policy-wg] 2006-06 New Policy Proposal (IPv4 Maximum Allocation Period) In-Reply-To: <20060912081514.C11822F5A0@herring.ripe.net> References: <20060912081514.C11822F5A0@herring.ripe.net> Message-ID: <20061004080922.GA20002@Space.Net> HI, On Tue, Sep 12, 2006 at 10:15:14AM +0200, Filiz Yilmaz wrote: > This proposal is to have the RIPE NCC allocate address space to > Local Internet Registries (LIRs) based on their one-year needs. In > other words, it suggests setting a maximum allocation period of 12 > months. I agree with Jeroen - the subject is a bit misleading, and the wording of the summary could also be a bit more clearer. Regarding the proposal itself, playing the devil's advocate, I'm not sure why we want that - "the other registries are changing their policies so their members have a disadvantage now -- let's make life more difficult for our members as well?". Global harmonization is nice, but as the *main* argument for a change that's reducing people's freedom in planning, I'm always a bit sceptical... To better judge the impact on address fragmentation (and speaking from a LIR's perspective, having too many different allocations *is* a nuisance - think "reverse DNS", "routing announcements", etc), I'd like to see some numbers what impact in terms of "how many LIRs would have received multiple blocks instead of a single contiguous block?" if the allocation time frame would have changed to "1 year" something like 5 years ago... Gert Doering -- speaking as LIR, not as APWG co-chair -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Wed Oct 4 10:19:11 2006 From: gert at space.net (Gert Doering) Date: Wed, 4 Oct 2006 10:19:11 +0200 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) In-Reply-To: <20060912081804.19FAF2F592@herring.ripe.net> References: <20060912081804.19FAF2F592@herring.ripe.net> Message-ID: <20061004081911.GB20002@Space.Net> Hi, On Tue, Sep 12, 2006 at 10:18:04AM +0200, Filiz Yilmaz wrote: > This proposal suggests the minimum Assignment Window (AW) available > to LIRs should be raised from zero (0) to /21 (2048 IPv4 addresses). I'm not fully happy with this proposal, because I think a /21 is too big - that's half the amount of addresses a new LIR receives, and the general assumption "a new LIR doesn't yet know how the game goes" still holds. Argueing "if people don't know what they are doing, they will be in for a hard time when they come for a new allocations" is true, but will hit the wrong people - it means the LIR will have done assignments to end users that will be very difficult to revoke (if done inappropriately), and *new* customers of that LIR might have to wait for a long time for new addresses (because the new allocation is delayed). So the customers get hurt because of sloppiness elsewhere in the process. I'd propose a minimum AW of /24, to be raised to a /22 if the LIR has sent one? two? person(s) to a LIR training course (and the trainer is convinced that these people have listened and understood the rules). (Because having good training doesn't help if people don't use it) So... let's have some discussion. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From fgarcia at eurocomercial.es Wed Oct 4 10:25:50 2006 From: fgarcia at eurocomercial.es (=?ISO-8859-1?Q?Fernando_Garc=EDa?=) Date: Wed, 4 Oct 2006 10:25:50 +0200 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) In-Reply-To: <20061004081911.GB20002@Space.Net> References: <20060912081804.19FAF2F592@herring.ripe.net> <20061004081911.GB20002@Space.Net> Message-ID: <75C81307-3FBC-41D2-936A-B24DB4AF33D0@eurocomercial.es> hello El 04/10/2006, a las 10:19, Gert Doering escribi?: > I'd propose a minimum AW of /24, to be raised to a /22 if the LIR has > sent one? two? person(s) to a LIR training course (and the trainer is > convinced that these people have listened and understood the rules). Considering that the training course doesn't have an examn, it's dificult for the trainer to know how much people has understood. I would modify your propossal to: 1st AW or /24 Raised AW to /22 after the first or second allocation is made if there are no errors in those. Regards, Fernando ------------------------------------------------ Fernando Garcia |Tel: +34 91 4359687 EUROCOMERCIAL I&C SA |Fax: +34 91 4313240 Valent?n Beato, 5 |e-mail: fgarcia at eurocomercial.es E-28037 Madrid | Spain |http://www.eurocomercial.es From gert at space.net Wed Oct 4 10:29:40 2006 From: gert at space.net (Gert Doering) Date: Wed, 4 Oct 2006 10:29:40 +0200 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) In-Reply-To: <75C81307-3FBC-41D2-936A-B24DB4AF33D0@eurocomercial.es> References: <20060912081804.19FAF2F592@herring.ripe.net> <20061004081911.GB20002@Space.Net> <75C81307-3FBC-41D2-936A-B24DB4AF33D0@eurocomercial.es> Message-ID: <20061004082939.GD20002@Space.Net> Hi, On Wed, Oct 04, 2006 at 10:25:50AM +0200, Fernando Garc?a wrote: > I would modify your propossal to: > 1st AW or /24 > Raised AW to /22 after the first or second allocation is made if > there are no errors in those. Well, that's the way it is now - if you send a few requests to the NCC hostmasters, and they are approved, you're granted an AW of the size of these requests (roughly so). So we wouldn't actually need the second sentence, it would account to "minimum AW of a /24"... - which I could live with, but Leo is clearly aiming for "more". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Woeber at CC.UniVie.ac.at Wed Oct 4 10:34:57 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 04 Oct 2006 08:34:57 +0000 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) In-Reply-To: <75C81307-3FBC-41D2-936A-B24DB4AF33D0@eurocomercial.es> References: <20060912081804.19FAF2F592@herring.ripe.net> <20061004081911.GB20002@Space.Net> <75C81307-3FBC-41D2-936A-B24DB4AF33D0@eurocomercial.es> Message-ID: <45237231.4080309@CC.UniVie.ac.at> Fernando Garc?a wrote: [...] > Considering that the training course doesn't have an examn, it's > dificult for the trainer to know how much people has understood. ...and there's https://e-learning.ripe.net/ :-) Wilfried. From Woeber at CC.UniVie.ac.at Wed Oct 4 12:23:38 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 04 Oct 2006 10:23:38 +0000 Subject: [address-policy-wg] Data Protection Task Force - Ref: RIPE53 DB-WG Draft Agenda V3. item C Message-ID: <45238BAA.6060105@CC.UniVie.ac.at> Dear Community, the logistical infrastructure for the Data Protection Task Force has been set up by the NCC. It is available at http://www.ripe.net/ripe/tf/index.html We are trying to get together a reasonably diverse mix of people for this task force, representing the various roles, activities and types of interest. The TF will be presented and discussed on Fr. morning in the DB-WG session where we will try to collect the initial population. If you can't make it to the DB-WG meeting, please indicate your interest by personal mail to Jochem de Ruig and myself. Please read up on the TF's mandate, the goals and logistics, and consider stepping forward to *actively* contribute! Thank you. See you Friday morning, Wilfried. From Michael.Dillon at btradianz.com Wed Oct 4 15:53:24 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 4 Oct 2006 14:53:24 +0100 Subject: [address-policy-wg] Data Protection Task Force - Ref: RIPE53 DB-WG Draft Agenda V3. item C In-Reply-To: <45238BAA.6060105@CC.UniVie.ac.at> Message-ID: > Please read up on the TF's mandate, the goals and logistics, and consider > stepping forward to *actively* contribute! Thank you. Has RIPE published a clear statement of purpose for the database? If not, then when will RIPE comply with Article 7 of the Personal Data Registration Act 2000? Artikel 7 Persoonsgegevens worden voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden verzameld In English: Personal data shall be collected for specific/particular, explicitly defined and justified/legitimate purposes. Do we have an explicitly defined purpose? Is it a legitimate and justified purpose? Personally, I don't believe that there is an explicitly defined purpose and I do believe that some of the purposes for which the database are not legitimate or justified. --Michael Dillon From slz at baycix.de Wed Oct 4 16:52:51 2006 From: slz at baycix.de (Sascha Lenz) Date: Wed, 04 Oct 2006 16:52:51 +0200 Subject: [address-policy-wg] 2006-06 New Policy Proposal (IPv4 Maximum Allocation Period) In-Reply-To: <20061004080922.GA20002@Space.Net> References: <20060912081514.C11822F5A0@herring.ripe.net> <20061004080922.GA20002@Space.Net> Message-ID: <4523CAC3.6000600@baycix.de> Hi, Gert Doering wrote: > HI, > > On Tue, Sep 12, 2006 at 10:15:14AM +0200, Filiz Yilmaz wrote: >> This proposal is to have the RIPE NCC allocate address space to >> Local Internet Registries (LIRs) based on their one-year needs. In >> other words, it suggests setting a maximum allocation period of 12 >> months. > > I agree with Jeroen - the subject is a bit misleading, and the wording > of the summary could also be a bit more clearer. > > Regarding the proposal itself, playing the devil's advocate, I'm not > sure why we want that - "the other registries are changing their > policies so their members have a disadvantage now -- let's make life > more difficult for our members as well?". Global harmonization is > nice, but as the *main* argument for a change that's reducing people's > freedom in planning, I'm always a bit sceptical... i'm with you and your arguments here. Especially since the policies of the other RIRs are all different from each other, and there's only a similiar proposal to harmonise it in one of them. > To better judge the impact on address fragmentation (and speaking > from a LIR's perspective, having too many different allocations *is* > a nuisance - think "reverse DNS", "routing announcements", etc), I'd > like to see some numbers what impact in terms of "how many LIRs would > have received multiple blocks instead of a single contiguous block?" > if the allocation time frame would have changed to "1 year" something > like 5 years ago... According to "b. Arguments Opposing the Proposal", the impact is minimal compared to other DFZ-bloating issues, but i don't have any numbers on it myself. Additionally, i still see no real reason to conserve IPv4 address space, my inofficial point of view is: waste IPv4 addresses so we can go with IPv6 :) All in all, i don't support this proposal at the moment. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From slz at baycix.de Wed Oct 4 17:20:37 2006 From: slz at baycix.de (Sascha Lenz) Date: Wed, 04 Oct 2006 17:20:37 +0200 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) In-Reply-To: <20061004082939.GD20002@Space.Net> References: <20060912081804.19FAF2F592@herring.ripe.net> <20061004081911.GB20002@Space.Net> <75C81307-3FBC-41D2-936A-B24DB4AF33D0@eurocomercial.es> <20061004082939.GD20002@Space.Net> Message-ID: <4523D145.6050506@baycix.de> Hi, Gert Doering wrote: > Hi, > > On Wed, Oct 04, 2006 at 10:25:50AM +0200, Fernando Garc?a wrote: >> I would modify your propossal to: >> 1st AW or /24 >> Raised AW to /22 after the first or second allocation is made if >> there are no errors in those. > > Well, that's the way it is now - if you send a few requests to the > NCC hostmasters, and they are approved, you're granted an AW of the > size of these requests (roughly so). > > So we wouldn't actually need the second sentence, it would account > to "minimum AW of a /24"... - which I could live with, but Leo is > clearly aiming for "more". For (standard) IPv6 assignments, you don't even have to ask RIPE in most cases by default. So, raising the IPv4 AW and thus (supposingly) reducing the workload on RIPE Hostmasters could probably leave to less cost and lower RIPE Membership fees - and/or better services as pointed out in the proposal. Although i'm a bit puzzled about this proposal (never thought about changing the AW handling lately), i'm supporting the proposal in general (larger AWs). I don't think there will be much negative impact. One might discuss the details though. I wouldn't object keeping a slow-start mechanism (to proof some kind of clue). Probably starting with - whatever - /24? and doubling the AW every two or three (RIPE approved) requests, regardless of their size. But this probably doesn't make that much sense either. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From Woeber at CC.UniVie.ac.at Wed Oct 4 17:35:09 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 04 Oct 2006 15:35:09 +0000 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) In-Reply-To: <4523D145.6050506@baycix.de> References: <20060912081804.19FAF2F592@herring.ripe.net> <20061004081911.GB20002@Space.Net> <75C81307-3FBC-41D2-936A-B24DB4AF33D0@eurocomercial.es> <20061004082939.GD20002@Space.Net> <4523D145.6050506@baycix.de> Message-ID: <4523D4AD.8020800@CC.UniVie.ac.at> Sascha Lenz wrote: [...] > For (standard) IPv6 assignments, you don't even have to ask RIPE in most > cases by default. [...] Which makes me remember again that I added the following comment to similar discussions in the past: "I don't believe that the /`whatever` is a useful yardstick to reasonably measure the complexity, difficulty or quality of request assessment for an assignment." My only problem is that I don't know which conclusion to draw from this, regarding the AW... Wilfried. From ncc at ripe.net Thu Oct 5 15:06:13 2006 From: ncc at ripe.net (Paul Rendek) Date: Thu, 05 Oct 2006 15:06:13 +0200 Subject: [address-policy-wg] NRO Number Counci Elections: Successful Candidate Announced Message-ID: <45250345.9060608@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, Dave Wilson, HEAnet, has been nominated from the RIPE NCC service region to take the vacant seat on the Number Resource Organization (NRO) Number Council (NC). Voting took place during the Plenary session of the RIPE 53 Meeting in Amsterdam at 09:00 - 10:30, Thursday 5 October, 2006. As the representative appointed by the Internet community for the NRO NC seat, Dave Wilson will serve a three-year term beginning on 1 January 2007. The term of Sabine Jaume, who was elected in January 2004, expires in December 2006. For more information about the NRO NC, nominations and the election process, see: http://www.ripe.net/info/resource-admin/nro2006/ Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From iljitsch at muada.com Thu Oct 5 20:36:48 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 5 Oct 2006 20:36:48 +0200 Subject: [address-policy-wg] Re: [ppml] Fwd: Keeping in reserve In-Reply-To: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> References: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> Message-ID: [Originally to ppml, CC to address-policy at ripe, prune as necessary] On 5-okt-2006, at 18:17, David Conrad wrote: > Is there any reason PI /48s shouldn't be allocated with the > bisection method, thus removing the need to reserve space? The goal of filtering in BGP is either to keep out accidentally injected prefixes, or keep out both accidentially and maliciously injected prefixes. This means that a reasonable filter, i.e., one that can be configured on a router with a relatively limited number of filter rules, must allow through all prefixes that match legitimate allocations, and reject as much of everything else as possible. This means that ideally, from a certain block of address space, prefixes of one size are allocated sequentially with no unused space between them. For instance: 192.0.0.0/24 -> /28s: 192.0.0.0/28 192.0.0.16/28 ... 192.0.0.192/28 192.0.0.208/28 In this example, only blocks above 192.0.0.208/28 can be successfully used to get around the filter, either for the purpose of hijacking unused address space for purposes like spamming, or to overload routers by injecting large numbers of bogus prefixes. If we now reserve a /26 for every user of a /28, we'd have: 192.0.0.0/28 192.0.0.64/28 ... 192.0.2.0/28 192.0.2.64/28 So a filter would have to allow 192.0.0.0/22 -> /26 - /28. This gives an attacker the opportunity to inject three malicious /28 prefixes between any two legitimate /28s. Worse, when someone grows out of a / 28 and gets a /27, such as 192.0.0.64/27, an attacker can inject 192.0.0.64/28 + 192.0.0.80/28, which cover the same address space but the longest match first rule makes packets flow toward the attacker rather than the real holder of the addresses. For this reason and because of temporary instability when moving from a smaller to a larger prefix, or maybe because of simple laziness or cluelessness, the real holder of the address space may choose to inject both 192.0.0.64/28 and 192.0.0.80/28 and maybe also 192.0.0.64/27. This negates the purpose of keeping some extra space in reserve between allocations. In IPv4 we have to be careful not to give too much space away, but in IPv6 there is absolutely no reason to skimp when people come back for seconds. So if a /48 isn't enough, don't grow to a /47 or even a /44, just give a /40 and then a /32. The number of extra prefixes in the routing table that this results in is minimal because even a /48 is more than enough for the majority of organizations, and it allows for much stricter filters. And it avoids fragmenting the address space. With the bisection method, you'd have to use even more liberal filters and allow between /25 and /28 in this example. All in all, it would be best if for every block of address space, only a fixed size allocations are given out. From kloch at kl.net Thu Oct 5 22:41:12 2006 From: kloch at kl.net (Kevin Loch) Date: Thu, 05 Oct 2006 16:41:12 -0400 Subject: [address-policy-wg] Re: [ppml] Fwd: Keeping in reserve In-Reply-To: References: <9991A4A8-7922-4338-8AEC-DBF635DAD7AB@virtualized.org> Message-ID: <45256DE8.1030409@kl.net> Iljitsch van Beijnum wrote: > [Originally to ppml, CC to address-policy at ripe, prune as necessary] > > On 5-okt-2006, at 18:17, David Conrad wrote: > >> Is there any reason PI /48s shouldn't be allocated with the >> bisection method, thus removing the need to reserve space? > > The goal of filtering in BGP is either to keep out accidentally > injected prefixes, or keep out both accidentially and maliciously > injected prefixes. > > This means that a reasonable filter, i.e., one that can be configured > on a router with a relatively limited number of filter rules, must > allow through all prefixes that match legitimate allocations, and > reject as much of everything else as possible. I don't see how fixed sizes and contiguous assignments will prevent people from announcing space not delegated to them. Right now the best way to manage this is by filtering your own customers with an explicit list (manually or RR generated) and applying peer pressure to peers who don't. Hopefully in the near future we will have crypto-signed announcements to solve this problem for real. - Kevin From leo at ripe.net Wed Oct 18 11:21:36 2006 From: leo at ripe.net (leo vegoda) Date: Wed, 18 Oct 2006 11:21:36 +0200 Subject: [address-policy-wg] New IPv6 block allocated to RIPE NCC Message-ID: <1803697A-F814-4A0F-A3A9-8642A83F0B95@ripe.net> [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv6 address range 2a00::/12 from the IANA in October 2006. This allocation expands two previous allocations. We will begin allocating from this new space in the near future. The minimum allocation size for this /12 has been set at /32. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Regards, -- leo vegoda Registration Services Manager RIPE NCC From filiz at ripe.net Wed Oct 18 17:18:42 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 18 Oct 2006 17:18:42 +0200 Subject: [address-policy-wg] 2006-06 Discussion Period extended until 29 November 2006 (IPv4 Maximum Allocation Period) Message-ID: <20061018151842.385A72F583@herring.ripe.net> PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues The Discussion Period for the proposal 2006-06 has been extended until 29 November 2006. This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-06.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Wed Oct 18 17:21:29 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 18 Oct 2006 17:21:29 +0200 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 29 November 2006 (Minimum IPv4 Assignment Window) Message-ID: <20061018152129.C54622F583@herring.ripe.net> PDP Number: 2006-07 Minimum IPv4 Assignment Window Dear Colleagues The Discussion Period for the the proposal 2006-07 has been extended until 29 November 2006. This proposal suggests the minimum Assignment Window (AW) available to LIRs should be raised from zero (0) to /21 (2048 IPv4 addresses). Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4096 IPv4 addresses). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-07.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From packetgrrl at gmail.com Thu Oct 19 13:26:57 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 19 Oct 2006 05:26:57 -0600 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 29 November 2006 (Minimum IPv4 Assignment Window) In-Reply-To: References: <20061018152129.C54622F583@herring.ripe.net> Message-ID: I support changing the assignment window to a /21 or even something larger. When I worked for a company that was a RIPE LIR I found that the small AW made it very difficult to do my job. I feel it's more appropriate to give LIRs information about how to make wise and documented assignments to customers and then assume they're adults and that they will do the right thing. If they fail in this then make it harder for them to get a subsequent allocation. Making them ask permission for every customer assignment is just a pain. Thanks! ---Cathy On 10/18/06, Filiz Yilmaz wrote: > > PDP Number: 2006-07 > Minimum IPv4 Assignment Window > > Dear Colleagues > > The Discussion Period for the the proposal 2006-07 has been extended > until 29 November 2006. > > > This proposal suggests the minimum Assignment Window (AW) available > to LIRs should be raised from zero (0) to /21 (2048 IPv4 addresses). > Because the sub-allocation policy references the AW policy, the > sub-allocation policy also needs to be updated. This proposal > suggests that the maximum sub-allocation should be kept at /20 (4096 > IPv4 addresses). > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2006-07.html > > > We encourage you to review this policy proposal and send your comments > to . > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DMenzulskiy at beeline.ru Thu Oct 19 16:35:01 2006 From: DMenzulskiy at beeline.ru (Dmitriy V Menzulskiy) Date: Thu, 19 Oct 2006 18:35:01 +0400 Subject: >>: Re: [address-policy-wg] 2006-07 Discussion Period extended until 29 November 2006 (Minimum IPv4 Assignment Window) Message-ID: I support those changes. Arguments are the same as Cathy gives. WBR, Dmitry Menzulskiy DM3740-RIPE ----- ?????????: Dmitriy V Menzulskiy/BeeLine ????: 19.10.2006 18:30 ----- address-policy-wg-admin at ripe.net ???????? 19.10.2006 15:26:57: > > I support changing the assignment window to a /21 or even something > larger. When I worked for a company that was a RIPE LIR I found > that the small AW made it very difficult to do my job. I feel it's > more appropriate to give LIRs information about how to make wise and > documented assignments to customers and then assume they're adults > and that they will do the right thing. If they fail in this then > make it harder for them to get a subsequent allocation. Making them > ask permission for every customer assignment is just a pain. > > Thanks! > ---Cathy > > On 10/18/06, Filiz Yilmaz < filiz at ripe.net> wrote: > PDP Number: 2006-07 > Minimum IPv4 Assignment Window > > Dear Colleagues > > The Discussion Period for the the proposal 2006-07 has been extended > until 29 November 2006. > > > This proposal suggests the minimum Assignment Window (AW) available > to LIRs should be raised from zero (0) to /21 (2048 IPv4 addresses). > Because the sub-allocation policy references the AW policy, the > sub-allocation policy also needs to be updated. This proposal > suggests that the maximum sub-allocation should be kept at /20 (4096 > IPv4 addresses). > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2006-07.html > > > We encourage you to review this policy proposal and send your comments > to . > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at ripe.net Mon Oct 23 17:00:11 2006 From: leo at ripe.net (leo vegoda) Date: Mon, 23 Oct 2006 17:00:11 +0200 Subject: [address-policy-wg] =?WINDOWS-1252?Q?2006-07_=96_Minimum_IPv4_Assignment_Window?= Message-ID: Dear Colleagues, During the Address Policy WG session at RIPE 53, we were asked to provide statistics showing - how many of the requests to make a PA assignment involve discussion with the requester; and - how much discussion takes place in those requests. We have prepared a set of statistics showing the number of rounds of messages in a ticket. Please note that tickets often include messages that are not directly related to the specific request. For instance, when an LIR is eligible for an additional allocation discussion can also occur on how to register something in the database, or we may remind them about an unpaid invoice. We looked at all the tickets where we approved PA assignments of prefixes up to and including /21 during the last three complete months of July, August and September in 2006. This was a set of 1100 tickets. The attached graph illustrates: - 80% of requests are approved immediately, or following just one exchange - 15% are approved with just two or three messages being exchanged - 4% of tickets involve a significant amount of discussion These figures show that only a small fraction of LIRs need significant assistance with their decision making. We will be able to dedicate significantly more time to this small group of LIRs if the minimum Assignment Window is raised. I hope you find these data useful when considering my proposal. The full table of results: Exchanges Tickets 0 673 1 214 2 118 3 48 4 11 5 20 7 6 8 4 11 4 12 2 An archive (available as a stream) of the RIPE 53 Address Policy WG webcast is available from our web site at: mms://webcast.ripe.net/ripe-53/ap.wmv and my presentation can be found at: http://www.ripe.net/ripe/meetings/ripe-53/presentations/ ipv4_min_aw_size.pdf Regards, -- leo vegoda Registration Services Manager RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: Discussion in PA Request Tickets.png Type: image/png Size: 31462 bytes Desc: not available URL: -------------- next part -------------- From stefan.camilleri at maltanet.net Tue Oct 24 12:14:18 2006 From: stefan.camilleri at maltanet.net (Stefan Camilleri) Date: Tue, 24 Oct 2006 12:14:18 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: Message-ID: <00d101c6f755$2b334920$2200a8c0@streamoffice.datastream.com.mt> Hi, I think that the modifications as proposed, though still not *there* are a big improvement on existing text particularly with the dropping of the requirement for 200 /48 assignments. I fully support the new Proposal Regards. Stephen SC4079-RIPE > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of JORDI > PALET MARTINEZ > Sent: L-Erbg?a, 27 ta' Settembru 2006 12:02 > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] IPv6 Address Allocation and > Assignment Policy (2006-02) > > Hi all, > > Same for this one ... Looking for further inputs to this > policy proposal. > > As the discussion period for this proposal > (http://www.ripe.net/ripe/policies/proposals/2006-02.html) is > almost over, I will like to ask for the latest inputs in > order to further decide how to proceed. > > Filiz arranged some stats about the discussion (thanks a lot > for that !) last July, and afterwards, even if the discussion > period has been extended, I don't recall having seen new comments. > > The stats don't include my own postings: > > >>> - there were 39 posts from 14 different individuals about it. > >>> > >>> - 8 people supported it. > >>> > >>> - 1 person *seemed* to be in favour of keeping the current policy. > >>> > >>> - 5 people made comments which I could not identify a > clear support > >>> or objection. > > So someone else will like to say anything new or clarify > their view in favor or opposition to the proposal ? > > Regards, > Jordi > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not > the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > > > From Michal.Miroslaw at nask.pl Tue Oct 24 13:02:29 2006 From: Michal.Miroslaw at nask.pl (=?iso-8859-2?Q?Micha=B3_Miros=B3aw?=) Date: Tue, 24 Oct 2006 13:02:29 +0200 Subject: [address-policy-wg] Comment on 2006-05 (PI Assignment Size) Message-ID: <20061024110229.GB25687@nask.pl> Hello, I support the 2006-05 proposal. We have one client who insisted on getting PI space, but they qualified for at most /27. Then we had to actually request that /27 and have them expierience what prefix filtering does to small PI networks. Alternative way to solve this would be to designate one /8 (or longer; divided among regional registries) that contained only prefixes longer than /24. It would allow for small PI's, be easy to configure filters for, and have a limited influence on global routing table size. But it would need agreement all over the internet. Best Regards, Michal Miroslaw NASK -- Michal Miroslaw PL > NASK > Network Administration Division > IP Team From president at ukraine.su Wed Oct 25 13:39:26 2006 From: president at ukraine.su (Max Tulyev) Date: Wed, 25 Oct 2006 11:39:26 +0000 Subject: [address-policy-wg] Comment on 2006-05 (PI Assignment Size) In-Reply-To: <20061024110229.GB25687@nask.pl> References: <20061024110229.GB25687@nask.pl> Message-ID: <453F4CEE.2080009@ukraine.su> Hello, I support this proposal too. And I think LIRs should be more face to client and a bit educate them about real situation before evaluating requests ;) Micha? Miros?aw wrote: > Hello, > > I support the 2006-05 proposal. We have one client who insisted > on getting PI space, but they qualified for at most /27. Then we > had to actually request that /27 and have them expierience what > prefix filtering does to small PI networks. > > Alternative way to solve this would be to designate one /8 (or longer; > divided among regional registries) that contained only prefixes > longer than /24. It would allow for small PI's, be easy to configure > filters for, and have a limited influence on global routing table size. > But it would need agreement all over the internet. > > Best Regards, > Michal Miroslaw > NASK > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From llc at dansketelecom.com Wed Oct 25 09:53:35 2006 From: llc at dansketelecom.com (Lars Lystrup Christensen) Date: Wed, 25 Oct 2006 09:53:35 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: <00d101c6f755$2b334920$2200a8c0@streamoffice.datastream.com.mt> Message-ID: <5DCC4AA34F470741B0CAE586CC8C8BB30109874A@exchange.office.dansketelecom.com> I believe the new proposal is much fairer to smaller ISPs, who currently are unable to justify assignments for IPv6. Currently we would not be able to assign 200 /48 in two years and therefore unable to receive IPv6 address space. However, until we are able to provide IPv6 connectivity, our customers won't request such IP addresses from us. And since our customers won't request them, we can't justify requesting from RIPE, who won't assign since we can't assign at lease 200 /48 in two years.... As shown this ends up in a deadlock situation and therefore IPv6 will only be available to larger ISPs. I know IPv6 is still quite a new "feature" and therefore still not widely used, but unless ISPs get access to IPv6 address space, it won't be more widely used. I'm definitely in favour of the new proposal. ______________________________________ Med venlig hilsen / Kind regards Lars Lystrup Christensen Network Engineer LLC11-RIPE > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Stefan Camilleri > Sent: 24. oktober 2006 12:14 > To: jordi.palet at consulintel.es; address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] IPv6 Address Allocation and Assignment > Policy (2006-02) > > Hi, > > I think that the modifications as proposed, though still not *there* are a > big > improvement on existing text particularly with the dropping of the > requirement > for 200 /48 assignments. > > I fully support the new Proposal > > Regards. > > Stephen > SC4079-RIPE > > > -----Original Message----- > > From: address-policy-wg-admin at ripe.net > > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of JORDI > > PALET MARTINEZ > > Sent: L-Erbg?a, 27 ta' Settembru 2006 12:02 > > To: address-policy-wg at ripe.net > > Subject: [address-policy-wg] IPv6 Address Allocation and > > Assignment Policy (2006-02) > > > > Hi all, > > > > Same for this one ... Looking for further inputs to this > > policy proposal. > > > > As the discussion period for this proposal > > (http://www.ripe.net/ripe/policies/proposals/2006-02.html) is > > almost over, I will like to ask for the latest inputs in > > order to further decide how to proceed. > > > > Filiz arranged some stats about the discussion (thanks a lot > > for that !) last July, and afterwards, even if the discussion > > period has been extended, I don't recall having seen new comments. > > > > The stats don't include my own postings: > > > > >>> - there were 39 posts from 14 different individuals about it. > > >>> > > >>> - 8 people supported it. > > >>> > > >>> - 1 person *seemed* to be in favour of keeping the current policy. > > >>> > > >>> - 5 people made comments which I could not identify a > > clear support > > >>> or objection. > > > > So someone else will like to say anything new or clarify > > their view in favor or opposition to the proposal ? > > > > Regards, > > Jordi > > > > > > > > > > > > > > ********************************************** > > The IPv6 Portal: http://www.ipv6tf.org > > > > Bye 6Bone. Hi, IPv6 ! > > http://www.ipv6day.org > > > > This electronic message contains information which may be > > privileged or confidential. The information is intended to be > > for the use of the individual(s) named above. If you are not > > the intended recipient be aware that any disclosure, copying, > > distribution or use of the contents of this information, > > including attached files, is prohibited. > > > > > > > > From dennis at gippnet.com Wed Oct 25 11:15:19 2006 From: dennis at gippnet.com (=?UTF-8?B?RGVubmlzIEx1bmRzdHLDtm0=?=) Date: Wed, 25 Oct 2006 11:15:19 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: <5DCC4AA34F470741B0CAE586CC8C8BB30109874A@exchange.office.dansketelecom.com> References: <5DCC4AA34F470741B0CAE586CC8C8BB30109874A@exchange.office.dansketelecom.com> Message-ID: <453F2B27.6060303@gippnet.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Lars. I guess It depends on the definition of an "end-site" The whole idea with IPv6 is to push the addresses to the end users. We would without a doubt see more "connected" household appliances in the future. And for our part. 200 /48 is not totally unrealistic. I would say It's way to early to say. It depends very much on how fast the market will adapt IPv6, and how fast new appliances are available. Personally I would say that even a qualified guess on an estimate is really, really hard here, and we don't want to lie to our friends at RIPE-NCC, don't we :-) Cheers! - --Dennis Lundstr?m GippNET AB (AS34537) Lars Lystrup Christensen wrote: > I believe the new proposal is much fairer to smaller ISPs, who > currently are unable to justify assignments for IPv6. Currently we > would not be able to assign 200 /48 in two years and therefore > unable to receive IPv6 address space. However, until we are able to > provide IPv6 connectivity, our customers won't request such IP > addresses from us. And since our customers won't request them, we > can't justify requesting from RIPE, who won't assign since we can't > assign at lease 200 /48 in two years.... > > As shown this ends up in a deadlock situation and therefore IPv6 > will only be available to larger ISPs. > > I know IPv6 is still quite a new "feature" and therefore still not > widely used, but unless ISPs get access to IPv6 address space, it > won't be more widely used. > > I'm definitely in favour of the new proposal. > > ______________________________________ > > Med venlig hilsen / Kind regards > > Lars Lystrup Christensen Network Engineer LLC11-RIPE > > >> -----Original Message----- From: address-policy-wg-admin at ripe.net >> [mailto:address-policy-wg- admin at ripe.net] On Behalf Of Stefan >> Camilleri Sent: 24. oktober 2006 12:14 To: >> jordi.palet at consulintel.es; address-policy-wg at ripe.net Subject: >> RE: [address-policy-wg] IPv6 Address Allocation and Assignment >> Policy (2006-02) >> >> Hi, >> >> I think that the modifications as proposed, though still not >> *there* are a big improvement on existing text particularly with >> the dropping of the requirement for 200 /48 assignments. >> >> I fully support the new Proposal >> >> Regards. >> >> Stephen SC4079-RIPE >> >>> -----Original Message----- From: >>> address-policy-wg-admin at ripe.net >>> [mailto:address-policy-wg-admin at ripe.net] On Behalf Of JORDI >>> PALET MARTINEZ Sent: L-Erbg?a, 27 ta' Settembru 2006 12:02 To: >>> address-policy-wg at ripe.net Subject: [address-policy-wg] IPv6 >>> Address Allocation and Assignment Policy (2006-02) >>> >>> Hi all, >>> >>> Same for this one ... Looking for further inputs to this policy >>> proposal. >>> >>> As the discussion period for this proposal >>> (http://www.ripe.net/ripe/policies/proposals/2006-02.html) is >>> almost over, I will like to ask for the latest inputs in order >>> to further decide how to proceed. >>> >>> Filiz arranged some stats about the discussion (thanks a lot >>> for that !) last July, and afterwards, even if the discussion >>> period has been extended, I don't recall having seen new >>> comments. >>> >>> The stats don't include my own postings: >>> >>>>>> - there were 39 posts from 14 different individuals about >>>>>> it. >>>>>> >>>>>> - 8 people supported it. >>>>>> >>>>>> - 1 person *seemed* to be in favour of keeping the >>>>>> current policy. >>>>>> >>>>>> - 5 people made comments which I could not identify a >>> clear support >>>>>> or objection. >>> So someone else will like to say anything new or clarify their >>> view in favor or opposition to the proposal ? >>> >>> Regards, Jordi >>> >>> >>> >>> >>> >>> >>> ********************************************** The IPv6 Portal: >>> http://www.ipv6tf.org >>> >>> Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org >>> >>> This electronic message contains information which may be >>> privileged or confidential. The information is intended to be >>> for the use of the individual(s) named above. If you are not >>> the intended recipient be aware that any disclosure, copying, >>> distribution or use of the contents of this information, >>> including attached files, is prohibited. >>> >>> >>> >>> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPysnsqJZaeZjsn8RAljpAKC8mRyq+x+piuXli7BNzF40uYCrVwCfT4LI uFK7kA3CozqLjc3nBmypEoE= =gmlg -----END PGP SIGNATURE----- From matthew.ford at bt.com Wed Oct 25 11:44:07 2006 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Wed, 25 Oct 2006 10:44:07 +0100 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) Message-ID: <70B775CD6175D84B978C843BDDF683970CC07AE4@i2km96-ukbr.domain1.systemhost.net> People sending comments to this list with the clear intention of supporting the adoption of new policy should take their responsibilities as stewards of the Internet's resources a little more seriously in my opinion. The proposed policy includes the following wording: "To qualify for an initial allocation of IPv6 address space, an organisation must: ... c) have a plan for making a reasonable number of /48 assignments within two years" Define 'reasonable'. Folks need to stop focussing on getting rid of the 200 /48 assignments rule and start focussing on developing good, useful policy for the region. In the absence of a better alternative (which 2006-02 is emphatically not), then the current policy must suffice. Regards, Mat > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Lars Lystrup Christensen > Sent: 25 October 2006 08:54 > To: address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] IPv6 Address Allocation and Assignment > Policy (2006-02) > > I believe the new proposal is much fairer to smaller ISPs, who currently > are unable to justify assignments for IPv6. Currently we would not be able > to assign 200 /48 in two years and therefore unable to receive IPv6 > address space. However, until we are able to provide IPv6 connectivity, > our customers won't request such IP addresses from us. And since our > customers won't request them, we can't justify requesting from RIPE, who > won't assign since we can't assign at lease 200 /48 in two years.... > > As shown this ends up in a deadlock situation and therefore IPv6 will only > be available to larger ISPs. > > I know IPv6 is still quite a new "feature" and therefore still not widely > used, but unless ISPs get access to IPv6 address space, it won't be more > widely used. > > I'm definitely in favour of the new proposal. > > ______________________________________ > > Med venlig hilsen / Kind regards > > Lars Lystrup Christensen > Network Engineer > LLC11-RIPE > > > > -----Original Message----- > > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > > admin at ripe.net] On Behalf Of Stefan Camilleri > > Sent: 24. oktober 2006 12:14 > > To: jordi.palet at consulintel.es; address-policy-wg at ripe.net > > Subject: RE: [address-policy-wg] IPv6 Address Allocation and Assignment > > Policy (2006-02) > > > > Hi, > > > > I think that the modifications as proposed, though still not *there* are > a > > big > > improvement on existing text particularly with the dropping of the > > requirement > > for 200 /48 assignments. > > > > I fully support the new Proposal > > > > Regards. > > > > Stephen > > SC4079-RIPE > > > > > -----Original Message----- > > > From: address-policy-wg-admin at ripe.net > > > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of JORDI > > > PALET MARTINEZ > > > Sent: L-Erbg?a, 27 ta' Settembru 2006 12:02 > > > To: address-policy-wg at ripe.net > > > Subject: [address-policy-wg] IPv6 Address Allocation and > > > Assignment Policy (2006-02) > > > > > > Hi all, > > > > > > Same for this one ... Looking for further inputs to this > > > policy proposal. > > > > > > As the discussion period for this proposal > > > (http://www.ripe.net/ripe/policies/proposals/2006-02.html) is > > > almost over, I will like to ask for the latest inputs in > > > order to further decide how to proceed. > > > > > > Filiz arranged some stats about the discussion (thanks a lot > > > for that !) last July, and afterwards, even if the discussion > > > period has been extended, I don't recall having seen new comments. > > > > > > The stats don't include my own postings: > > > > > > >>> - there were 39 posts from 14 different individuals about it. > > > >>> > > > >>> - 8 people supported it. > > > >>> > > > >>> - 1 person *seemed* to be in favour of keeping the current policy. > > > >>> > > > >>> - 5 people made comments which I could not identify a > > > clear support > > > >>> or objection. > > > > > > So someone else will like to say anything new or clarify > > > their view in favor or opposition to the proposal ? > > > > > > Regards, > > > Jordi > > > > > > > > > > > > > > > > > > > > > ********************************************** > > > The IPv6 Portal: http://www.ipv6tf.org > > > > > > Bye 6Bone. Hi, IPv6 ! > > > http://www.ipv6day.org > > > > > > This electronic message contains information which may be > > > privileged or confidential. The information is intended to be > > > for the use of the individual(s) named above. If you are not > > > the intended recipient be aware that any disclosure, copying, > > > distribution or use of the contents of this information, > > > including attached files, is prohibited. > > > > > > > > > > > > From gert at space.net Wed Oct 25 12:01:26 2006 From: gert at space.net (Gert Doering) Date: Wed, 25 Oct 2006 12:01:26 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: <70B775CD6175D84B978C843BDDF683970CC07AE4@i2km96-ukbr.domain1.systemhost.net> References: <70B775CD6175D84B978C843BDDF683970CC07AE4@i2km96-ukbr.domain1.systemhost.net> Message-ID: <20061025100126.GG20002@Space.Net> Hi, On Wed, Oct 25, 2006 at 10:44:07AM +0100, matthew.ford at bt.com wrote: > In the absence of a better alternative (which 2006-02 is emphatically > not), then the current policy must suffice. >From the "policy development process" view, this proposal is currently at the end of the "discussion phase". No consensus was reached, so it can not go ahead. As it was pretty clear that there is a desire to get rid of the 200-customer rule, but that this specific wording isn't going to be *the* answer, Jordi Palet is now working on an updated proposal, which should bring us further forward. The new proposal (actually, two new proposals, one for 2006-01 and one for 2006-02) will be circulated "in a few days". Gert Doering -- RIPE AP WG Chair -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From matthew.ford at bt.com Wed Oct 25 12:08:23 2006 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Wed, 25 Oct 2006 11:08:23 +0100 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) Message-ID: <70B775CD6175D84B978C843BDDF683970CC07BBE@i2km96-ukbr.domain1.systemhost.net> That's good news, and saves me typing up my unhappiness with the 2006-01 text as well :) Mat > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering > Sent: 25 October 2006 11:01 > To: Ford,M,Mat,CXR9 R > Cc: llc at dansketelecom.com; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 Address Allocation and > Assignment Policy (2006-02) > > Hi, > > On Wed, Oct 25, 2006 at 10:44:07AM +0100, matthew.ford at bt.com wrote: > > In the absence of a better alternative (which 2006-02 is > emphatically > > not), then the current policy must suffice. > > From the "policy development process" view, this proposal is currently > at the end of the "discussion phase". No consensus was reached, so it > can not go ahead. > > As it was pretty clear that there is a desire to get rid of > the 200-customer > rule, but that this specific wording isn't going to be *the* answer, > Jordi Palet is now working on an updated proposal, which should bring > us further forward. > > The new proposal (actually, two new proposals, one for > 2006-01 and one for > 2006-02) will be circulated "in a few days". > > Gert Doering > -- RIPE AP WG Chair > -- > Total number of prefixes smaller than registry allocations: 98999 > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 > > From Michael.Dillon at btradianz.com Wed Oct 25 13:07:21 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 25 Oct 2006 12:07:21 +0100 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: <70B775CD6175D84B978C843BDDF683970CC07AE4@i2km96-ukbr.domain1.systemhost.net> Message-ID: > People sending comments to this list with the clear intention of > supporting the adoption of new policy should take their > responsibilities as stewards of the Internet's resources a little > more seriously in my opinion. I think that we all take these responsibilities seriously, however we do not all have such narrow interpretations of "resource stewardship" as you seem to have. > Folks need to stop focussing on getting rid of the 200 /48 > assignments rule and start focussing on developing good, useful > policy for the region. The fact is that having the number 200 in the existing policy prevents that policy from being either good or useful. The proposed change puts the policy on the path towards being better and more useful. This is sufficient reason to support the policy. Not all ISPs have the same business model. But if an ISP has an IPv4 network and has received an allocation from RIPE, it is highly likely that their plans for IPv6 deployment will also be reasonable within RIPE's understanding of the term. After all, the organization is already a RIPE LIR. I fully support proposal 2006-2 --Michael Dillon From filiz at ripe.net Wed Oct 25 16:13:07 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 25 Oct 2006 16:13:07 +0200 Subject: [address-policy-wg] 2005-08 Draft Documents will be edited (Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy) Message-ID: <20061025141307.76C502F583@herring.ripe.net> PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues, The review period for the proposal 2005-08 is over. Following the feedback received, the draft documents will be edited. We will publish the updated text soon and we will tell you when it is available. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html Regards Filiz Yilmaz RIPE NCC Policy Development Officer From s.steffann at computel.nl Thu Oct 26 20:16:04 2006 From: s.steffann at computel.nl (Sander Steffann) Date: Thu, 26 Oct 2006 20:16:04 +0200 Subject: [address-policy-wg] Comment on 2006-05 (PI Assignment Size) References: <20061024110229.GB25687@nask.pl> Message-ID: <002201c6f92a$ce6954f0$64c8a8c0@balefirehome> Hi, > I support the 2006-05 proposal. We have one client who insisted > on getting PI space, but they qualified for at most /27. Then we > had to actually request that /27 and have them expierience what > prefix filtering does to small PI networks. I'm a bit afraid of mixing RIPE address policy interests/requirements and routing policy interests/requirements. Ofcourse a lot of address space is requested to be routed, so there is a connection between the two. I'm just afraid that common routing policies will change if we change the address policy, so then we'll have to change the address policy again, which will lead to changes in common routing policy, etc.. We have to be careful here. Sander From s.steffann at computel.nl Thu Oct 26 20:21:40 2006 From: s.steffann at computel.nl (Sander Steffann) Date: Thu, 26 Oct 2006 20:21:40 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) References: <70B775CD6175D84B978C843BDDF683970CC07AE4@i2km96-ukbr.domain1.systemhost.net> <20061025100126.GG20002@Space.Net> Message-ID: <003a01c6f92b$94e05e80$64c8a8c0@balefirehome> Hi, > As it was pretty clear that there is a desire to get rid of the > 200-customer > rule, but that this specific wording isn't going to be *the* answer, > Jordi Palet is now working on an updated proposal, which should bring > us further forward. > > The new proposal (actually, two new proposals, one for 2006-01 and one for > 2006-02) will be circulated "in a few days". Good to hear. I'm looking forward to the new text. Thanks, Sander From filiz at ripe.net Mon Oct 30 12:06:10 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 30 Oct 2006 12:06:10 +0100 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) Message-ID: <20061030110610.1716A2F593@herring.ripe.net> PDP Number: 2006-04 Contact e-mail Address Requirements Dear Colleagues We have published a draft document for the proposal described in 2006-04. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-04.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2006-04-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 27 November 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From Michael.Dillon at btradianz.com Mon Oct 30 16:19:26 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 30 Oct 2006 15:19:26 +0000 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) In-Reply-To: <20061030110610.1716A2F593@herring.ripe.net> Message-ID: > We have published a draft document for the proposal described in > 2006-04. >From the draft document: By making the wording of the existing policy about contact information in the RIPE Database more explicit, we should see less spam and abuse and more rapid correction in network operations. I question the logic of this proposal. While I also would like to see less spam and more rapid correction of network operational issues, I do not believe that this policy addresses these problems at all. A spammer that wants to comply with this policy change merely needs to maintain an abuse contact that delivers all complaints to an email robot which discards them in the same way that the RIPE hostmaster robot discards queries from unknown email addresses. But the policy has a larger problem. It attempts to place a stricter requirement on every organization which has received an assignment from a RIPE member. In this way it places a requirement on virtually every organization, commercial and non-commercial, which exists within our society. I do not believe that this is justified and I do not believe that most organizations have any real role to play in preventing spam or correcting network operational issues. The real issue here is that current RIPE policies allow RIPE members to wash their hands of all network operational issues associated with the addresses which they have assigned to other organizations. It would be far better to fix this policy by making it clear that there is one and only one organization responsible for network operational issues related to an allocated block and that is the RIPE member who received the allocation. If they want to have internal processes and contractual agreements that delegate some of that responsibility, that is OK, but they must nevertheless remain the primary point of contact. RIPE can impose an obligation on organizations who have received an allocation directly from RIPE and it can easily police such an obligation. But once 3rd parties enter the situation, RIPE can only make a lot of noise and create policies that have no teeth which no one really has to follow. The rules and policies surrounding the RIPE database are part of the tradition that we have been blindly following since the days of the ARPAnet when it was neccessary to record all users of the network in order to justify budget allocations. The network climate has change around us but the policies have not sufficiently evolved to meet the new environment. --Michael Dillon From hank at efes.iucc.ac.il Tue Oct 31 06:29:10 2006 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 31 Oct 2006 07:29:10 +0200 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) In-Reply-To: References: <20061030110610.1716A2F593@herring.ripe.net> Message-ID: <5.1.0.14.2.20061031072243.00b0f598@efes.iucc.ac.il> At 03:19 PM 30-10-06 +0000, Michael.Dillon at btradianz.com wrote: >But the policy has a larger problem. It attempts to >place a stricter requirement on every organization >which has received an assignment from a RIPE member. >In this way it places a requirement on virtually >every organization, commercial and non-commercial, >which exists within our society. I do not believe >that this is justified and I do not believe that >most organizations have any real role to play in >preventing spam or correcting network operational >issues. > >The real issue here is that current RIPE policies >allow RIPE members to wash their hands of all >network operational issues associated with the >addresses which they have assigned to other >organizations. Allow me to disagree. As someone who regularly sends out emails to contact info as located in the various whois databases, I would rate the RIPE info at #1, followed by RADB, APNIC, ARIN and last being LACNIC (no feedback yet from AFRNIC). Some of you may have received these emails over the past 5 years about leaking private ASNs which is sent to all emails I find in whois. I find the RIPE data to be accurate and comprehensive and light years ahead of the data inside LACNIC. I also find the people contacted inside RIPE respond far quicker than those in ARIN (APNIC is even better than ARIN in that respect). So before complaining about RIPE data, best to bring the rest of the world up to the level that RIPE maintains. Regards, Hank Nussbacher http://www.interall.co.il From dogwallah at gmail.com Tue Oct 31 06:40:36 2006 From: dogwallah at gmail.com (McTim) Date: Tue, 31 Oct 2006 08:40:36 +0300 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) In-Reply-To: <5.1.0.14.2.20061031072243.00b0f598@efes.iucc.ac.il> References: <20061030110610.1716A2F593@herring.ripe.net> <5.1.0.14.2.20061031072243.00b0f598@efes.iucc.ac.il> Message-ID: Hank, On 10/31/06, Hank Nussbacher wrote: > >The real issue here is that current RIPE policies > >allow RIPE members to wash their hands of all > >network operational issues associated with the > >addresses which they have assigned to other > >organizations. > > Allow me to disagree. Allow me to agree with you ;-), and support the policy as written. -- Cheers, McTim $ whois -h whois.afrinic.net mctim From Woeber at CC.UniVie.ac.at Tue Oct 31 11:01:27 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 31 Oct 2006 10:01:27 +0000 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) In-Reply-To: References: <20061030110610.1716A2F593@herring.ripe.net> <5.1.0.14.2.20061031072243.00b0f598@efes.iucc.ac.il> Message-ID: <45471EF7.9030400@CC.UniVie.ac.at> McTim wrote: > Hank, > > On 10/31/06, Hank Nussbacher wrote: > >> >The real issue here is that current RIPE policies >> >allow RIPE members to wash their hands of all >> >network operational issues associated with the >> >addresses which they have assigned to other >> >organizations. >> >> Allow me to disagree. > > > Allow me to agree with you ;-), and support the policy as written. IMHO it is easy to support the proposal (or not) as it is not going to change anything in real life ;-) Wilfried. From Woeber at CC.UniVie.ac.at Tue Oct 31 11:20:45 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 31 Oct 2006 10:20:45 +0000 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) In-Reply-To: References: Message-ID: <4547237D.30503@CC.UniVie.ac.at> Michael.Dillon at btradianz.com wrote: [...] > The real issue here is that current RIPE policies > allow RIPE members to wash their hands of all > network operational issues associated with the > addresses which they have assigned to other > organizations. To some degree, I think, this is a left-over from the previous millennium when we had (mostly) PI and Last-Resort-Registries per country. In general there was no relationship between the distribution path of addresses and the connectivity, the path for the packets... > It would be far better to fix this > policy by making it clear that there is one and > only one organization responsible for network > operational issues related to an allocated block > and that is the RIPE member who received the > allocation. If they want to have internal processes > and contractual agreements that delegate some of > that responsibility, that is OK, but they must > nevertheless remain the primary point of contact. Incidentally, the irt stuff was consciously engineered to support such a view, and to allow the proper registration of such responsibilities, plus the delegation to down-stream entities for PA-Blocks :-) The little disagreement here is that in my opinion the primary point of contact should by the "most down-strem" entity, with the NCC's Member contact to be used as an escalation path, if needed. The rational for this model is: the entity/role/group that is the NCC's member and is managing addres space may not be in aposition to get involved in operational or security aspects. This responsibility may rest with a third party, either within the same corporation or even somewhere else. > RIPE can impose an obligation on organizations > who have received an allocation directly from > RIPE and it can easily police such an obligation. > But once 3rd parties enter the situation, RIPE can > only make a lot of noise and create policies that > have no teeth which no one really has to follow. > > The rules and policies surrounding the RIPE database > are part of the tradition that we have been blindly > following since the days of the ARPAnet when it was > neccessary to record all users of the network in > order to justify budget allocations. The network > climate has change around us but the policies have > not sufficiently evolved to meet the new environment. Eventually, the results from the Data Protection Task Force may easily require us to do "a bit" of re-modeling... > --Michael Dillon Wilfried. From Michael.Dillon at btradianz.com Tue Oct 31 11:25:04 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 31 Oct 2006 10:25:04 +0000 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) In-Reply-To: <5.1.0.14.2.20061031072243.00b0f598@efes.iucc.ac.il> Message-ID: > >The real issue here is that current RIPE policies > >allow RIPE members to wash their hands of all > >network operational issues associated with the > >addresses which they have assigned to other > >organizations. > > Allow me to disagree. As someone who regularly sends out emails to contact > info as located in the various whois databases, I would rate the RIPE info > at #1, followed by RADB, APNIC, ARIN and last being LACNIC You have misinterpreted what I wrote. Perhaps you didn't notice that the proposal is about an email address where notifications of abuse can be sent. The current policy means that LIRs have no obligation to maintain active operational contact with the organizations to which they assign addresses. They merely need to record an email contact in the RIPE database and their job is done. That contact info may be incorrect or it may become stale over time. In order to deal efficiently with network operational issues including SPAM and DoS, we need to have contact points who are ready, willing and able to act upon problem reports. RIPE could impose this requirement on its LIRs with which it has a binding contractual relationship but RIPE cannot impose any obligation on 3rd parties who receive assignments from an LIR. If an LIR is made responsible for the totality of its allocation and is required, as part of the RIPE agreement, to maintain a contact point which is ready, willing and able to act upon problem reports, then we have covered 100% of the RIPE region address space. Of course, in many case, the LIR will need to contact a 3rd party in order to resolve the issue, but it is highly likely that the LIR has a binding contractual relationship with that 3rd party so that they know who to contact. In fact, some 3rd parties are not ABLE to deal with problem reports because there is noone on staff who is competent to deal with such issues. Other 3rd parties are not WILLING to deal with such problem reports because they think that they are buying a network service from the LIR and therefore the LIR should deal with such network issues. And yet other 3rd parties are not READY to deal with such problems because of extenuating issues. For instance the one capable staff member is sick or on holiday or has left and not yet been replaced. Or they are in the midst of a merger, or... The key thing here is that a workable response system requires that ALL contact points are READY, WILLING and ABLE to act upon problem reports. If RIPE policy required this then it would improve the process of dealing with network abuse. The policy as proposed does nothing whatsoever to deal with network abuse. Most 3rd parties do not follow RIPE activities so they are unlikely to comply with the change. There is no mechanism to police compliance and the policy proposed is so weak that a spammer can simply install a copy of the RIPE hostmaster auto-responder and leave the list of acceptable senders blank. --Michael Dillon From Michael.Dillon at btradianz.com Tue Oct 31 11:32:04 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 31 Oct 2006 10:32:04 +0000 Subject: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements) In-Reply-To: <4547237D.30503@CC.UniVie.ac.at> Message-ID: > The little disagreement here is that in my opinion the primary > point of contact should by the "most down-strem" entity, with the > NCC's Member contact to be used as an escalation path, if needed. I agree that this is superior in practice but only if that "most down-stream" contact is READY, WILLING and ABLE to act upon problem reports. It would be wise for a registration policy to allow and encourage the assignees to register such a contact, but the policy can only make it mandatory for LIRs to register such a contact. I think that if RIPE ever did make a sensible and workable policy like this, then the LIRs would put some effort into making sure that their customers have contacts who are READY, WILLING and ABLE to act upon problem reports. But they are closer to those customers and will know where it makes sense to do this and where it does not. > The rational for this model is: the entity/role/group that is the > NCC's member and is managing addres space may not be in aposition > to get involved in operational or security aspects. This responsibility > may rest with a third party, either within the same corporation or even > somewhere else. If RIPE is going to require a working abuse contact then it should point to the group that has this responsibility, not to the group that deals with address management. That is why I stress that the abuse contact must be READY, WILLING and ABLE to act upon problem reports. --Michael Dillon