From gert at space.net Thu Oct 1 16:34:12 2009 From: gert at space.net (Gert Doering) Date: Thu, 1 Oct 2009 16:34:12 +0200 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> Message-ID: <20091001143412.GR628@Space.Net> Hi, Filiz, thanks for pointing this out so clearly. On Mon, Sep 14, 2009 at 05:57:46PM +0200, Filiz Yilmaz wrote: > New ARIN "A. Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated address space to the > IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool. > > RIPE "3.1 Phase I" > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. Each > RIR shall at quarterly intervals return any such recovered address > space to the IANA in aggregated blocks of /24 or larger, for inclusion > in the recovered IPv4 pool. As per the discussion between Wilfried and Scott, this is a significantly different proposal than the one that we have achieved consensus on. ARIN has a MAY here, both for recovery and return-to-IANA. RIPE has a MUST here (it's still a "may" regarding recovery, but as soon as it is recovered, it MUST be returned to IANA). We'll definitely have to discuss this at the WG meeting next week, and I'm afraid that this proposal will have to do another round through the policy processes to achieve identical wording - otherwise it can't be a global policy. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From nigel at titley.com Thu Oct 1 17:12:31 2009 From: nigel at titley.com (Nigel Titley) Date: Thu, 01 Oct 2009 16:12:31 +0100 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <20091001143412.GR628@Space.Net> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <20091001143412.GR628@Space.Net> Message-ID: <4AC4C6DF.6000508@titley.com> > As per the discussion between Wilfried and Scott, this is a significantly > different proposal than the one that we have achieved consensus on. > > ARIN has a MAY here, both for recovery and return-to-IANA. > > RIPE has a MUST here (it's still a "may" regarding recovery, but as soon > as it is recovered, it MUST be returned to IANA). > > We'll definitely have to discuss this at the WG meeting next week, and > I'm afraid that this proposal will have to do another round through the > policy processes to achieve identical wording - otherwise it can't be > a global policy. > There appears to be a certain amount of doubt as to whether the wording has to be identical or merely substantially the same (but I agree with Gert that this, on the face of it, is a substantially different policy). Note however that ARIN is the odd man out here. All the other RIRs have agreed on the original wording, so it may not be up to *us* to do anything. Nigel From gert at space.net Thu Oct 1 17:45:23 2009 From: gert at space.net (Gert Doering) Date: Thu, 1 Oct 2009 17:45:23 +0200 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <20091001143412.GR628@Space.Net> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <20091001143412.GR628@Space.Net> Message-ID: <20091001154523.GU628@Space.Net> Hi, one important correction - sorry, I was not fully paying attention: On Thu, Oct 01, 2009 at 04:34:12PM +0200, Gert Doering wrote: > As per the discussion between Wilfried and Scott, this is a significantly > different proposal than the one that we have achieved consensus on. I must point out that the RIPE region had NOT achieved formal consensus on this proposal (2009-01) yet. Since we have been aware that the ARIN AC was working on the wording, we deliberately stalled moving the proposal ahead in our policy process - and can now easily do another round of discussion/review phase, with the changed wording (if we agree that this is the way forward). Now, for the other regions, I can't say what the state of affairs is over there. Sorry again for the confusion. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From michael.dillon at bt.com Thu Oct 1 18:22:34 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 1 Oct 2009 17:22:34 +0100 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4AC4C6DF.6000508@titley.com> Message-ID: <28E139F46D45AF49A31950F88C4974580362ADB7@E03MVZ2-UKDY.domain1.systemhost.net> > Note however that ARIN is the odd man out here. All the > other RIRs have agreed on the original wording, so it may not > be up to *us* to do anything. Actually it is up to us to do something. Now that ARIN has approved a policy with substantially different wording, there is not going to be a global policy covering this. RIPE needs to decide if we are happy with separate regional policies, or if we are willing to adopt ARIN's wording in an attempt to reach a global policy. Of course, if there is not much desire to change anything, then de facto, ARIN's policy is regional and there will be no globally consistent policy. That is roughly how the NRO process works. --Michael Dillon From filiz at ripe.net Thu Oct 1 18:37:25 2009 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 1 Oct 2009 18:37:25 +0200 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <20091001154523.GU628@Space.Net> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <20091001143412.GR628@Space.Net> <20091001154523.GU628@Space.Net> Message-ID: Hello, On Oct 1, 2009, at 5:45 PM, Gert Doering wrote: > > Now, for the other regions, I can't say what the state of affairs is > over there. > AfriNIC, APNIC and LACNIC have reached consensus on the proposal (where the wording matches with the one we have in RIPE). ARIN has not yet reached consensus on its version - they are still discussing it. It is also scheduled to be discussed in their next Public Policy Meeting, which will take place from 21 - 23 October 2009. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC > Sorry again for the confusion. > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 141055 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From scottleibrand at gmail.com Thu Oct 1 18:41:13 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 01 Oct 2009 09:41:13 -0700 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <28E139F46D45AF49A31950F88C4974580362ADB7@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C4974580362ADB7@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4AC4DBA9.4080908@gmail.com> michael.dillon at bt.com wrote: >> Note however that ARIN is the odd man out here. All the >> other RIRs have agreed on the original wording, so it may not >> be up to *us* to do anything. >> > > Actually it is up to us to do something. > > Now that ARIN has approved a policy with substantially different > wording, there is not going to be a global policy covering this. > > RIPE needs to decide if we are happy with separate regional policies, or > if we are willing to adopt ARIN's wording in an attempt to reach a > global policy. > > Of course, if there is not much desire to change anything, then de > facto, ARIN's policy is regional and there will be no globally > consistent policy. That is roughly how the NRO process works. For clarity, ARIN has not yet approved 2009-3. The ARIN AC has revised it, and the revised version is going to be up for adoption discussion at the Dearborn meeting. If the community supports the revised version, and the ARIN AC votes to adopt it, then the other RIRs can decide whether they want to adopt that text as well. Without global consensus, this policy doesn't really do much for us. It is written as a Global Policy because it directs IANA how to redistribute returned address space. That portion of the policy has to go through as a Global Policy, or not at all. -Scott From plzakr at gmail.com Thu Oct 1 18:38:03 2009 From: plzakr at gmail.com (Ray Plzak) Date: Thu, 1 Oct 2009 12:38:03 -0400 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <28E139F46D45AF49A31950F88C4974580362ADB7@E03MVZ2-UKDY.domain1.systemhost.net> References: <4AC4C6DF.6000508@titley.com> <28E139F46D45AF49A31950F88C4974580362ADB7@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <004101ca42b5$8eca0b00$ac5e2100$@com> If in fact there are irreconcilable differences regarding what space is to be recovered and/or returned, then the global policy should be abandoned and a new one proposed which tells IANA what to do when it receives returned address space from an RIR. Ray -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of michael.dillon at bt.com Sent: Thursday, October 01, 2009 12:23 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries > Note however that ARIN is the odd man out here. All the > other RIRs have agreed on the original wording, so it may not > be up to *us* to do anything. Actually it is up to us to do something. Now that ARIN has approved a policy with substantially different wording, there is not going to be a global policy covering this. RIPE needs to decide if we are happy with separate regional policies, or if we are willing to adopt ARIN's wording in an attempt to reach a global policy. Of course, if there is not much desire to change anything, then de facto, ARIN's policy is regional and there will be no globally consistent policy. That is roughly how the NRO process works. --Michael Dillon From nigel at titley.com Thu Oct 1 19:31:09 2009 From: nigel at titley.com (Nigel Titley) Date: Thu, 01 Oct 2009 18:31:09 +0100 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4AC4DBA9.4080908@gmail.com> References: <28E139F46D45AF49A31950F88C4974580362ADB7@E03MVZ2-UKDY.domain1.systemhost.net> <4AC4DBA9.4080908@gmail.com> Message-ID: <4AC4E75D.1020609@titley.com> Scott Leibrand wrote: > For clarity, ARIN has not yet approved 2009-3. The ARIN AC has > revised it, and the revised version is going to be up for adoption > discussion at the Dearborn meeting. If the community supports the > revised version, and the ARIN AC votes to adopt it, then the other > RIRs can decide whether they want to adopt that text as well. > > Without global consensus, this policy doesn't really do much for us. > It is written as a Global Policy because it directs IANA how to > redistribute returned address space. That portion of the policy has > to go through as a Global Policy, or not at all. Exactly. And that part of the policy is still common. So even if ARIN changes the conditions under which they decide to return addresses to the pool for the common good, the policy can still go forward for adoption as a global policy. Of course the other RIRs might decide that ARIN's stance changes their minds on whether to adopt this policy, but that is a different situation. Nigel From randy at psg.com Fri Oct 2 00:31:34 2009 From: randy at psg.com (Randy Bush) Date: Fri, 02 Oct 2009 07:31:34 +0900 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4AC4C6DF.6000508@titley.com> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <20091001143412.GR628@Space.Net> <4AC4C6DF.6000508@titley.com> Message-ID: >> ARIN has a MAY here, both for recovery and return-to-IANA. >> RIPE has a MUST here (it's still a "may" regarding recovery, but as >> soon as it is recovered, it MUST be returned to IANA). > There appears to be a certain amount of doubt as to whether the > wording has to be identical or merely substantially the same < tact=off > < reality=on > underlying the words is substantial disagreement. arin policy wonks have zero intent to return any /8s recovered from the us military to the iana. and those /8s are specifically the subject of this lacnic proposal. randy From nick at inex.ie Fri Oct 2 00:48:09 2009 From: nick at inex.ie (Nick Hilliard) Date: Thu, 01 Oct 2009 23:48:09 +0100 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <20091001143412.GR628@Space.Net> <4AC4C6DF.6000508@titley.com> Message-ID: <4AC531A9.2010904@inex.ie> On 01/10/2009 23:31, Randy Bush wrote: > underlying the words is substantial disagreement. arin policy wonks > have zero intent to return any /8s recovered from the us military to the > iana. and those /8s are specifically the subject of this lacnic > proposal. It is sad to see this policy deteriorating into the tragedy of the commons. The original wording had merit. Nick From randy at psg.com Fri Oct 2 03:04:53 2009 From: randy at psg.com (Randy Bush) Date: Fri, 02 Oct 2009 10:04:53 +0900 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4AC531A9.2010904@inex.ie> References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <20091001143412.GR628@Space.Net> <4AC4C6DF.6000508@titley.com> <4AC531A9.2010904@inex.ie> Message-ID: >> underlying the words is substantial disagreement. arin policy wonks >> have zero intent to return any /8s recovered from the us military to >> the iana. and those /8s are specifically the subject of this lacnic >> proposal. > It is sad to see this policy deteriorating into the tragedy of the > commons. it's the tragedy of the americas, a few hudred years of colonialism, and it goes on. randy From Marcus.Gerdon at versatel.de Mon Oct 5 11:04:24 2009 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Mon, 5 Oct 2009 11:04:24 +0200 Subject: AW: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries Message-ID: <227142482560EF458FF1F7E784E26AB801371983@FLBVEXCH01.versatel.local> I don't think the situation's that different. I case ARIN's going to adopt the '*may* return to IANA' version I definitely see no sense in any other RIR implementing a *must*. Quite to the contrary. In this part I've to somewhat agree with Randy and unfortunately have to raise the question why we should return any addresses to IANA if ARIN decides to keep everything for themselves (with quite a bunch of legacy /8's being handled there). Marcus > Exactly. And that part of the policy is still common. So even if ARIN > changes the conditions under which they decide to return addresses to > the pool for the common good, the policy can still go forward for > adoption as a global policy. Of course the other RIRs might > decide that > ARIN's stance changes their minds on whether to adopt this > policy, but > that is a different situation. > > Nigel > > ---------------------------------------------------------------------------------------- Engineering IP Services Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon at versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Gesch?ftsf?hrer: Marc L?tzenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ---------------------------------------------------------------------------------------- From plzakr at gmail.com Mon Oct 5 16:12:34 2009 From: plzakr at gmail.com (Ray Plzak) Date: Mon, 5 Oct 2009 10:12:34 -0400 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: References: <1505D7FE-EE07-45FE-A80C-98493CBC9DBF@ripe.net> <20091001143412.GR628@Space.Net> <4AC4C6DF.6000508@titley.com> Message-ID: <004e01ca45c5$e45e9c80$ad1bd580$@com> Randy, Can you give this list the source for your statement "arin policy wonks have zero intent to return any /8s recovered from the us military to the iana. and those /8s are specifically the subject of this lacnic proposal." As one of the original authors of this proposal which was drafted by persons from all regions, I really have trouble understanding that this is a LACNIC proposal. Ray -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Randy Bush Sent: Thursday, October 01, 2009 18:32 To: Nigel Titley Cc: Gert Doering; Filiz Yilmaz; RIPE Address Policy Working Group Subject: Re: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries >> ARIN has a MAY here, both for recovery and return-to-IANA. >> RIPE has a MUST here (it's still a "may" regarding recovery, but as >> soon as it is recovered, it MUST be returned to IANA). > There appears to be a certain amount of doubt as to whether the > wording has to be identical or merely substantially the same < tact=off > < reality=on > underlying the words is substantial disagreement. arin policy wonks have zero intent to return any /8s recovered from the us military to the iana. and those /8s are specifically the subject of this lacnic proposal. randy From kamil at extendbroadband.com Tue Oct 6 07:08:52 2009 From: kamil at extendbroadband.com (Kamil Semavi) Date: Tue, 6 Oct 2009 08:08:52 +0300 Subject: [address-policy-wg] how to change ASN Message-ID: <000001ca4643$189e9680$49dbc380$@com> Hello guys, I want to change ASN of my whole subnet. How can I do it ? Thanks K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Tue Oct 6 13:50:03 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 06 Oct 2009 13:50:03 +0200 Subject: [address-policy-wg] RIPE-471 and suballocations In-Reply-To: <4A1EB96F.2050204@ripe.net> References: <4A1E8377.8030405@ripe.net> Message-ID: <5.1.0.14.2.20091006134253.00c5f0a8@efes.iucc.ac.il> I have been looking over RIPE-471 section 9: http://www.ripe.net/docs/ipv4-policies.html#9 and noticed that only some "status" categories are listed as "Sub-allocations cannot be made from this type of address space". Therefore I would have assumed that any status not listed as "Sub-allocations cannot be made from this type of address space" would allow sub-allocations. That is incorrect - for example - ASSIGNED PI does not allow sub-allocations. Can the doc please updated so it reflects correctly the s/w? Thanks, Hank From sander at steffann.nl Tue Oct 6 15:25:10 2009 From: sander at steffann.nl (Sander Steffann) Date: Tue, 6 Oct 2009 14:25:10 +0100 Subject: [address-policy-wg] RIPE-471 and suballocations In-Reply-To: <5.1.0.14.2.20091006134253.00c5f0a8@efes.iucc.ac.il> References: <4A1E8377.8030405@ripe.net> <5.1.0.14.2.20091006134253.00c5f0a8@efes.iucc.ac.il> Message-ID: <2EF4E2B5-3D9C-4143-B70C-533DEB781A72@steffann.nl> Hello Hank, > I have been looking over RIPE-471 section 9: > http://www.ripe.net/docs/ipv4-policies.html#9 > and noticed that only some "status" categories are listed as "Sub- > allocations cannot be made from this type of address space". > Therefore I would have assumed that any status not listed as "Sub- > allocations cannot be made from this type of address space" would > allow sub-allocations. That is incorrect - for example - ASSIGNED > PI does not allow sub-allocations. Parts of any anything that has been assigned can not be allocated/sub- allocated/assigned. Only parts of allocations can be sub-allocated or assigned. The "Sub-allocations cannot be made from this type of address space." is only meant to mark allocation types that can not contain sub-allocations. I understand your confusion though. > Can the doc please updated so it reflects correctly the s/w? There is work being done to clear up the RIPE documents without changing the meaning. I think this fits nicely into that effort. Once this document gets cleaned up the new proposed version will be posted to this mailing list for review. Thank you, Sander Steffann APWG co-chair From nigel at titley.com Tue Oct 6 17:51:56 2009 From: nigel at titley.com (Nigel Titley) Date: Tue, 06 Oct 2009 16:51:56 +0100 Subject: [address-policy-wg] Legal advice on final /8 policies Message-ID: <4ACB679C.4000400@titley.com> Folks, The RIPE NCC has taken legal advice on the various final /8 policies viz-a-viz EU competition policy. I attach a copy of the advice for your delight and edification. Executive summary: don't panic! Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: Final :8 policies advice.pdf Type: application/pdf Size: 241525 bytes Desc: not available URL: From ncc at ripe.net Thu Oct 8 09:42:59 2009 From: ncc at ripe.net (Nathalie Trenaman) Date: Thu, 08 Oct 2009 09:42:59 +0200 Subject: [address-policy-wg] Proposal to Remove Routing Requirements from the IPv6 Address Allocation Policy Implemented Message-ID: <4ACD9803.9030301@ripe.net> Dear Colleagues, We are pleased to announce that policy proposal 2000-06,"Removing Routing Requirements from the IPv6 Address Allocation Policy", has been implemented. The RIPE NCC is now ready to accept requests for IPv6 address space under the new policy. This proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2009-06.html The updated "IPv6 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-481.html The following FAQ has also been updated to reflect this policy implementation: http://www.ripe.net/info/faq/rs/ipv6.html Regards, Nathalie Trenaman Registration Services RIPE NCC From jcurran at arin.net Thu Oct 8 17:32:10 2009 From: jcurran at arin.net (John Curran) Date: Thu, 8 Oct 2009 11:32:10 -0400 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries Message-ID: <0FE430CD-E919-448C-8DDC-3E98AD4C7587@arin.net> > it's the tragedy of the americas, a few hudred years of colonialism, > and it goes on. To understand concerns in the ARIN region, I'd recommend that folks read the actual policy text and staff assessment at . Because this global policy results in significant departure from RFC2050 need-based allocation (with one equal allocation unit per RIR each 6 month period even if less than regional demand), there are challenges of equity that result from mandating the return to the IANA. The reality is that returned address space has been going back to IANA and will continue to do under current practices; see for more information. Thanks! /John John Curran President and CEO ARIN From gert at space.net Thu Oct 8 18:18:02 2009 From: gert at space.net (Gert Doering) Date: Thu, 8 Oct 2009 18:18:02 +0200 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <0FE430CD-E919-448C-8DDC-3E98AD4C7587@arin.net> References: <0FE430CD-E919-448C-8DDC-3E98AD4C7587@arin.net> Message-ID: <20091008161802.GX86885@Space.Net> Hi, On Thu, Oct 08, 2009 at 11:32:10AM -0400, John Curran wrote: > The reality is that returned address space has been going back to IANA > and will continue to do under current practices; see > for more information. I think that this is a fairly important bit to comprehend the full picture. Nevertheless, we'll need to see what your membership will decide before we can decide whether there is usefulness in proceeding with our proposal... regards, Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From randy at psg.com Thu Oct 8 19:32:21 2009 From: randy at psg.com (Randy Bush) Date: Thu, 08 Oct 2009 10:32:21 -0700 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <0FE430CD-E919-448C-8DDC-3E98AD4C7587@arin.net> References: <0FE430CD-E919-448C-8DDC-3E98AD4C7587@arin.net> Message-ID: > To understand concerns in the ARIN region, I'd recommend that folks > read the actual policy text and staff assessment at > > Because this global policy results in significant departure from > RFC2050 need-based allocation (with one equal allocation unit per RIR > each 6 month period even if less than regional demand), there are > challenges of equity that result from mandating the return to the > IANA. return is input to the pool which is quite different from [need based] allocation, which is output from the pool > The reality is that returned address space has been going back to IANA > and will continue to do under current practices problem is that arin's unique rewording rather blatantly hedges that for the future. randy From nigel at titley.com Thu Oct 8 19:31:38 2009 From: nigel at titley.com (Nigel Titley) Date: Thu, 08 Oct 2009 18:31:38 +0100 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <20091008161802.GX86885@Space.Net> References: <0FE430CD-E919-448C-8DDC-3E98AD4C7587@arin.net> <20091008161802.GX86885@Space.Net> Message-ID: <4ACE21FA.2000905@titley.com> Gert Doering wrote: > Hi, > > On Thu, Oct 08, 2009 at 11:32:10AM -0400, John Curran wrote: > >> The reality is that returned address space has been going back to IANA >> and will continue to do under current practices; see > > for more information. >> > > I think that this is a fairly important bit to comprehend the full > picture. > Well, this is slightly disingenuous, as IANA currently only accepts returned /8s. Part of the global policy proposal was to encourage IANA to accept smaller blocks for distribution that would otherwise be stuck with the RIR in which they were returned. Also of course, the argument that this policy does not comply with the "at need" practice currently followed by RIRs is a little shaky too. This policy only kicks in once the IANA pool is completely exhausted. All RIRs will be able to make justification for the tiny remaining dribbles of IPv4 space that this policy will generate. As noted several times today, this policy is not about usefully extending the life of IPv4. It is about showing that RIRs are able to act in a magnanimous and equitable fashion with the last remaining dregs of an irreplaceable resource. Nigel From leo.vegoda at icann.org Thu Oct 8 21:27:29 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 8 Oct 2009 12:27:29 -0700 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4ACE21FA.2000905@titley.com> Message-ID: On 08/10/2009 10:31, "Nigel Titley" wrote: [...] > Well, this is slightly disingenuous, as IANA currently only accepts > returned /8s. I would re-phrase that as "current policy only allows IANA to allocate to RIRs in multiples of /8". I think it's worth distinguishing between a lack of willingness and pointlessness. Until there is a policy allowing smaller allocations to RIRs there's no point in returning anything less than a /8 to the IANA free pool. Regards, Leo Vegoda Number Resources Manager, IANA From nigel at titley.com Fri Oct 9 08:35:57 2009 From: nigel at titley.com (Nigel Titley) Date: Fri, 09 Oct 2009 07:35:57 +0100 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: References: Message-ID: <4ACED9CD.3080602@titley.com> Leo Vegoda wrote: > I would re-phrase that as "current policy only allows IANA to allocate to > RIRs in multiples of /8". I think it's worth distinguishing between a lack > of willingness and pointlessness. Until there is a policy allowing smaller > allocations to RIRs there's no point in returning anything less than a /8 to > the IANA free pool. > I never meant to imply a lack of willingness on the part of IANA and am happy to accept your correction. This of course is why this policy proposal specifically addresses both return and distribution. Nigel From jcurran at arin.net Fri Oct 9 11:42:51 2009 From: jcurran at arin.net (John Curran) Date: Fri, 9 Oct 2009 05:42:51 -0400 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4ACE21FA.2000905@titley.com> References: <0FE430CD-E919-448C-8DDC-3E98AD4C7587@arin.net> <20091008161802.GX86885@Space.Net> <4ACE21FA.2000905@titley.com> Message-ID: On Oct 8, 2009, at 6:31 PM, Nigel Titley wrote: > > > Also of course, the argument that this policy does not comply with the > "at need" practice currently followed by RIRs is a little shaky too. > This policy only kicks in once the IANA pool is completely exhausted. > All RIRs will be able to make justification for the tiny remaining > dribbles of IPv4 space that this policy will generate. As noted > several > times today, this policy is not about usefully extending the life of > IPv4. It is about showing that RIRs are able to act in a magnanimous > and > equitable fashion with the last remaining dregs of an irreplaceable > resource. If the RIR's are drawing from the IANA pool in relatively small amounts on intervals based on their actual documented need, the runout of the IANA free pool is quickly followed by runout of available space for new ISP/NIR/LIR allocations in all regions at roughly the same time globally (this excludes consideration of the "final /8's", which may or may not be available for such allocations depending on regional policy). All RIR's running out together at the about same time is certainly "equitable". Globally, we're presently going through 10 to 12 /8's each year. Under today's policies, if one assumes that a handful of /8's were to be reclaimed through focused efforts and returned to the IANA, we'd continue allocations for few months. Post-IANA runout, this global policy sets fixed allocation sizes which will likely be less than some regions need yet larger other regions needs for years to come. This effectively insures that a subset of economies need to deal with IPv4 address depletion first. "Magnanimous" applies to such a situation, but "equitable" is a matter of perspective. The altering of IPv4 depletion impact among economies is not necessarily a bad thing, and in fact, may indeed be the right choice for the best chances of global IPv6 deployment. While the discussion of this policy has recently focused on the mandatory/optional IANA return issue that ARIN introduced, the larger implications of departing from strictly need-based policy is likely the redirection of the IPv4 depletion impact to a subset of RIRs. /John From Woeber at CC.UniVie.ac.at Fri Oct 9 12:56:48 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 09 Oct 2009 10:56:48 +0000 Subject: [address-policy-wg] 2009-01, Global Policy for the allocation of IPv4 blocks to Regional Internet Registries In-Reply-To: <4AC4E75D.1020609@titley.com> References: <28E139F46D45AF49A31950F88C4974580362ADB7@E03MVZ2-UKDY.domain1.systemhost.net> <4AC4DBA9.4080908@gmail.com> <4AC4E75D.1020609@titley.com> Message-ID: <4ACF16F0.30601@CC.UniVie.ac.at> Nigel Titley wrote: > Scott Leibrand wrote: > >> For clarity, ARIN has not yet approved 2009-3. The ARIN AC has >> revised it, and the revised version is going to be up for adoption >> discussion at the Dearborn meeting. If the community supports the >> revised version, and the ARIN AC votes to adopt it, then the other >> RIRs can decide whether they want to adopt that text as well. >> >> Without global consensus, this policy doesn't really do much for us. >> It is written as a Global Policy because it directs IANA how to >> redistribute returned address space. That portion of the policy has >> to go through as a Global Policy, or not at all. > > Exactly. And that part of the policy is still common. So even if ARIN > changes the conditions under which they decide to return addresses to > the pool for the common good, the policy can still go forward for > adoption as a global policy. Wearing my AC-hat for a moment, and while I may not be supposed to have a formal point of view here, I would be *very* uncomfortable to see a policy text being forwarded to the Address Council's table for processing according to our rules, which consists of some stuff which IS NOT to be considered part of a global policy, and another section which IS to be regarded as a global policy. OTOH, the NRO may be in a position to separate the parts and only forward those that are common across all regions? > Of course the other RIRs might decide that > ARIN's stance changes their minds on whether to adopt this policy, but > that is a different situation. > > Nigel Wilfried From patrick.arkley at se.verizonbusiness.com Fri Oct 9 13:52:07 2009 From: patrick.arkley at se.verizonbusiness.com (Arkley, Patrick) Date: Fri, 9 Oct 2009 13:52:07 +0200 Subject: [address-policy-wg] Inet6num requirements in the db Message-ID: Hi. I seem to recall from the RIPE meeting that Axel talked about the RIPE database as a valuable source of information. Also other organisations thinks it is a valuable and trustworthy source. It is also a very easy way of finding out the most likely users (at least one step down stream from the LIR) of a specific IP-range. But how come there is no requirement to add end-user objects for IPv6? Only the LIR's allocations are required. If we want to continue the work that has been done for IPv4 I think we need end-user objects for IPv6 as well. Maybe there is good reasoning behind this but the explanation I got from the RIPE NCC crew was not satisfactory. Best regards Patrick Arkley Verizon Europe Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009- huvudkontorets adress: Armegatan 38, Box 4127, 171 04 Solna, Sverige -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr at cluenet.de Fri Oct 9 20:30:32 2009 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 9 Oct 2009 20:30:32 +0200 Subject: [address-policy-wg] Registration of IPv6 DHCPv6-PD pools Message-ID: <20091009183032.GA23976@srv03.cluenet.de> Hi, the current IPv6 Address Allocation and Assignment Policy (RIPE-481) states: http://www.ripe.net/ripe/docs/ripe-481.html#registration_assignment ======================================================================= 5.5. Registration When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate. (Information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered at the granularity of End Site assignments. [...] ======================================================================= Let's assume a residential eyeball network with $BIGNUM customers provides a dynamic /56 via DHCPv6-PD to each customer by default, from a large pool of /56s. I'm not sure what the implications of above policy is, especially in regards to the last sentence, "Information is registered at the granularity of End Site assignments.". Given that the End Site identity changes dynamically in a relatively high frequency, and considering $BIGNUM in the 6 to 7 figure range, it certainly won't be sensible pumping a $BIGNUM count of /56 inet6nums into the RIPE DB, all with "descr: dynamic end site network". Unfortunately it seems that this is actually required ny the policy though, wether in the RIPE DB or a DB operated by the LIR in question, accessible to the NCC. Providing dynamic networks to end sites instead of only single addresses is something new to the community. I'm looking for clarification on how we're going to handle those kind of deployments in regard of assignment registration. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From leo.vegoda at icann.org Fri Oct 9 21:00:52 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 9 Oct 2009 12:00:52 -0700 Subject: [address-policy-wg] Registration of IPv6 DHCPv6-PD pools In-Reply-To: <20091009183032.GA23976@srv03.cluenet.de> Message-ID: Hi Daniel, On 09/10/2009 11:30, "Daniel Roesen" wrote: > it must register assignment information in a > database, accessible by RIRs as appropriate. [...] > I'm not sure what the implications of above policy is, especially in > regards to the last sentence, "Information is registered at > the granularity of End Site assignments.". Given that the End Site > identity changes dynamically in a relatively high frequency, and > considering $BIGNUM in the 6 to 7 figure range, it certainly won't be > sensible pumping a $BIGNUM count of /56 inet6nums into the RIPE DB, all > with "descr: dynamic end site network". Unfortunately it seems that this > is actually required ny the policy though, wether in the RIPE DB or a DB > operated by the LIR in question, accessible to the NCC. My interpretation the text of the policy different from yours. It does not say that assignments must be registered in the RIPE database, just that the database has to be accessible by RIRs. This is presumably to allow the RIPE NCC to assess you for your next allocation when your allocation is 'full'. I also think that if there is a highly dynamic movement of prefixes between subscribers in the pool then it would make most sense to register the pool rather than the end user, just like you do for IPv4. I suspect that most ISPs treat pool of dynamic IPv4 addresses as the site and the subscribers as users connected to that site. Does this need to change for IPv6? This is just my interpretation, though. Regards, Leo Vegoda From dr at cluenet.de Sat Oct 10 00:40:15 2009 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 10 Oct 2009 00:40:15 +0200 Subject: [address-policy-wg] Re: Registration of IPv6 DHCPv6-PD pools In-Reply-To: References: <20091009183032.GA23976@srv03.cluenet.de> Message-ID: <20091009224015.GA7214@srv03.cluenet.de> On Fri, Oct 09, 2009 at 12:00:52PM -0700, Leo Vegoda wrote: > My interpretation the text of the policy different from yours. It does not > say that assignments must be registered in the RIPE database, just that the > database has to be accessible by RIRs. That's my interpretation as well, see "the "or a DB operated by the LIR": > > Unfortunately it seems that this is actually required ny the policy though, > > wether in the RIPE DB or a DB operated by the LIR in question, accessible > > to the NCC. I guess this is a reference to a local RIPE-like DB as employed by several LIRs. No matter in which database, it makes (in my view) absolutely no sense to have each /56 in there as individual entries. > I also think that if there is a highly dynamic movement of prefixes between > subscribers in the pool then it would make most sense to register the pool > rather than the end user, just like you do for IPv4. Agreed, but the policy doesn't really (in my interpretation, I'm seeking for clarification on that) allow this option as it clearly says that the granularity of registration is supposed to be at End Site level - that's quite normative. > I suspect that most ISPs treat pool of dynamic IPv4 addresses as the site > and the subscribers as users connected to that site. Does this need to > change for IPv6? Using this analogy ("pool of /56s" = "end site") would mean that the pool can be only 256 /56s big (=/48) without approval by NCC, see policy "5.4.2. Assignment of multiple /48s to a single End Site". In fact, this would mean we would need to get approval for all our end user IP pools. On the other side, a business ISP wouldn't ever need to approach NCC for assigning their allocation full of /48s for end users, as long as any single site does not exceed /48. This makes no sense to me. Even simple IPv4 DHCP pools for single WAN IPs aren't clearly regulated by policy. Ask hostmaster A and he/she will say "that's your infrastructure, as you need those IPs to connect your customer to you, just use INFRA-AW, no approvals required". Ask the next hostmaster and he/she will tell you differently, that this is abuse of INFRA-AW and needs approval. Ideally we're going to find a consensus interpretation on how to deal with dynamic pools (of any size), be it for single IPs or prefix delegations via DHCP-PD. I would see some merit in codifying this in the addressing policy so it becomes much less ambiguous. For IPv4 this is probably not really necessary anymore, we won't have to deal with this ambiguities and indifferent interpretations by NCC for much longer. But "prefix pools" is something we as a community have no experience how to deal with regarding policy and policy application. It's something "new" we will see with IPv6 deployment. I see value in giving NCC guidance on how to deal with that. Looking forward to further input. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From bernard.dugas.2009 at is-production.com Sat Oct 10 10:18:25 2009 From: bernard.dugas.2009 at is-production.com (Bernard Dugas) Date: Sat, 10 Oct 2009 10:18:25 +0200 Subject: [address-policy-wg] Allocations/assignements statistics ? Message-ID: <4AD04351.5020504@is-production.com> Dear Colleagues, To analyse the use of IPV4 currently, i need to have the number and size of IPV4 prefixes, PA allocated and PI assigned, and ASN, linked to the 5 membership categories. It should be consistent with other data avalaible, meaning that snapshot of 20090930 would be optimal. Thanks a lot, Best regards, -- __Bernard DUGAS ______________________________________________________ From david.freedman at uk.clara.net Sat Oct 10 13:54:52 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Sat, 10 Oct 2009 12:54:52 +0100 Subject: [address-policy-wg] Re: Registration of IPv6 DHCPv6-PD pools References: <20091009183032.GA23976@srv03.cluenet.de> <20091009224015.GA7214@srv03.cluenet.de> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B2C2FA1@EXVS01.claranet.local> >Ideally we're going to find a consensus interpretation on how to deal with >dynamic pools (of any size), be it for single IPs or prefix delegations >via DHCP-PD. I think it depends very much on how big an assignment you would want to make out of these, in my personal opinion, I think that anything larger than /64 (which is the minimum you need to get anything done) should be documented. Why do I think this? In the IPv4 world, we take a /24 pool and divide it up into /32s which we need to connect the customer to us ("infrastructure") and no per-customer documentation is needed. The minute an IPv4 customer asks for some addresses to be routed to them, enough to create another "network", we give them at minimum a /29 and document this. In the IPv6 world, I think I would be following the same approach, only on a bigger scale. The minute a customer wants more than just to have their home IPv6 devices work in a basic fashion (i.e they want another /64 or a /56) then I would expect there to be some documentation for it, I'm not trying to be restrictive about what they do with their home networks, just trying to draw a line in the sand somewhere, below which I don't care about usage and above which I do. Now, as for the question of what this documentation should be or where it lives, I can't see much use in populating the RIR DB with all of this small assignment stuff, perhaps best draw another line and make this the RIR reporting threshold. Dave. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Oct 13 09:29:31 2009 From: gert at space.net (Gert Doering) Date: Tue, 13 Oct 2009 09:29:31 +0200 Subject: [address-policy-wg] Inet6num requirements in the db In-Reply-To: References: Message-ID: <20091013072931.GJ86885@Space.Net> Hi, there's two parallel "inet6num registration" discussions going on at the same time - let me respond to this one first, because it's a bit easier. On Fri, Oct 09, 2009 at 01:52:07PM +0200, Arkley, Patrick wrote: > I seem to recall from the RIPE meeting that Axel talked about the RIPE > database as a valuable source of information. Also other organisations > thinks it is a valuable and trustworthy source. It is also a very easy > way of finding out the most likely users (at least one step down stream > from the LIR) of a specific IP-range. > > But how come there is no requirement to add end-user objects for IPv6? > Only the LIR's allocations are required. If we want to continue the work > that has been done for IPv4 I think we need end-user objects for IPv6 as > well. Regarding end-user registrations in the RIPE DB, there are a few conflicting interests to balance: - finding someone "who can make it stop" in case of net-abuse - knowing the end user - protection of personal data for private users - documenting that the network resources are properly used The crucial one is balancing the first one vs. the third one. For private users, there really is no point in having the contact data of the end customer in the database - because if they get some angry e-mails or phone calls from someone who is just now being attacked from their PC, the chance is very high that this end user has no idea whatsoever to do about it. So the best point of contact in that case might be the ISP, who knows the customer, knows whom to call, and how to bring the message "your 0wn3d" across. Now, if there is not much sense in having that data around (because it won't help), EU data protection requires that we don't store it in the first place... Now, for enterprise customers, or multi-level ISP re-seller structures, the question of "whom to contact" and responsibility for abuse handling is different again - so for these, registering the inet6num: objects makes very much sense, and is perfectly fine according to data protection laws (because there is an operational purpose of storing the data). There has been long discussions about this whole topic, mostly taking place in the database working group, and this is the resulting compromise: - you *can* store the end user objects in the RIPE DB, if it makes sense - you don't *have* to store them (in a publically visible database), if it does not make sense - the data needs to be made available to the RIPE NCC, so that for additional allocations, the usage ratio of your allocation can be verified - but that can be in a private DB only accessible to the NCC. So - basically this means "the contact of last resort is the LIR, and if they are not publishing end-user contact data, they (need to!) take responsibility for handling all issues relating to that network block". I assume that this answer is not exactly what you have hoped for, but I think that this should at least clarify the reasoning a bit. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From patrick.arkley at se.verizonbusiness.com Tue Oct 13 09:33:44 2009 From: patrick.arkley at se.verizonbusiness.com (Arkley, Patrick) Date: Tue, 13 Oct 2009 09:33:44 +0200 Subject: [address-policy-wg] Inet6num requirements in the db Message-ID: I'm fine with that. Thanks. / Patrick Arkley ** sent from mobile device ** ----- Original Message ----- From: Gert Doering To: Arkley, Patrick Cc: address-policy-wg at ripe.net Sent: Tue Oct 13 09:29:31 2009 Subject: Re: [address-policy-wg] Inet6num requirements in the db Hi, there's two parallel "inet6num registration" discussions going on at the same time - let me respond to this one first, because it's a bit easier. On Fri, Oct 09, 2009 at 01:52:07PM +0200, Arkley, Patrick wrote: > I seem to recall from the RIPE meeting that Axel talked about the RIPE > database as a valuable source of information. Also other organisations > thinks it is a valuable and trustworthy source. It is also a very easy > way of finding out the most likely users (at least one step down stream > from the LIR) of a specific IP-range. > > But how come there is no requirement to add end-user objects for IPv6? > Only the LIR's allocations are required. If we want to continue the work > that has been done for IPv4 I think we need end-user objects for IPv6 as > well. Regarding end-user registrations in the RIPE DB, there are a few conflicting interests to balance: - finding someone "who can make it stop" in case of net-abuse - knowing the end user - protection of personal data for private users - documenting that the network resources are properly used The crucial one is balancing the first one vs. the third one. For private users, there really is no point in having the contact data of the end customer in the database - because if they get some angry e-mails or phone calls from someone who is just now being attacked from their PC, the chance is very high that this end user has no idea whatsoever to do about it. So the best point of contact in that case might be the ISP, who knows the customer, knows whom to call, and how to bring the message "your 0wn3d" across. Now, if there is not much sense in having that data around (because it won't help), EU data protection requires that we don't store it in the first place... Now, for enterprise customers, or multi-level ISP re-seller structures, the question of "whom to contact" and responsibility for abuse handling is different again - so for these, registering the inet6num: objects makes very much sense, and is perfectly fine according to data protection laws (because there is an operational purpose of storing the data). There has been long discussions about this whole topic, mostly taking place in the database working group, and this is the resulting compromise: - you *can* store the end user objects in the RIPE DB, if it makes sense - you don't *have* to store them (in a publically visible database), if it does not make sense - the data needs to be made available to the RIPE NCC, so that for additional allocations, the usage ratio of your allocation can be verified - but that can be in a private DB only accessible to the NCC. So - basically this means "the contact of last resort is the LIR, and if they are not publishing end-user contact data, they (need to!) take responsibility for handling all issues relating to that network block". I assume that this answer is not exactly what you have hoped for, but I think that this should at least clarify the reasoning a bit. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 141055 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009? huvudkontorets adress: Arm?gatan 38, Box 4127, 171 04 Solna, Sverige -------------- next part -------------- An HTML attachment was scrubbed... URL: From president at ukraine.su Wed Oct 21 18:42:28 2009 From: president at ukraine.su (Max Tulyev) Date: Wed, 21 Oct 2009 19:42:28 +0300 Subject: [address-policy-wg] RIPE staff vs Court Message-ID: <4ADF39F4.5010705@ukraine.su> Hello! Today I just got a strange letter from RIPE staff. I didn't saw anything like that before. They told me about a ten of networks registered through our LIR. All these networks have changed admin-c and tech-c to other country, and routed through one server on that country. Based on this, RIPE man sent the notification about reclamation of that networks, as "that seems to don't be valid anymore." Of course, I immediately contacted my client and asked what's happened. He said they work as usual, but one certain offshore IT company is used to manage their networks. So they changed contact details to that company, as that company is correct contact point in any network questions. And traffic flows through the offshore company site as they manage and control it, hosts data, etc. >From one point of view, situation seems very strange. From second - nothing to be not real in practice. So we (first time?) faced with IP reclamation dispute. I don't really know did our clients something bad - perhaps no, as none from these nets listed at Spamhouse ;). I think it is 50/50. May be they told me (and RIPE) truth, may be lied. I can't 100% check it by tools/rights/possibilities I have. But about ten of businesses are on decision of one person that "seems to ...". My strong position is THERE SHOULD BE A COURT DECISION OR OUR COMMUNITY COURT-LIKE STRUCTURE, and only that structure based on court-like controversy process (if not a real court) can make a decision about reclaim any address space. NO WAYS LIKE "IT SEEMS TO...". So now we have: http://www.ripe.net/ripe/docs/ripe-475.html#42 My proposal is to change: "Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User" to "Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User, SUPPORTED BY..." By what? By Dutch Court? By some independent court-like staff? Any ideas? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From mark at streamservice.nl Wed Oct 21 20:01:37 2009 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 21 Oct 2009 20:01:37 +0200 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <4ADF39F4.5010705@ukraine.su> References: <4ADF39F4.5010705@ukraine.su> Message-ID: <01da01ca5278$892d4900$9b87db00$@nl> Hello Max, As long as it is Dutch Court I don't see a problem. If you are against a decision RIPE did make you can go to Dutch Court and ask if they decide to change it. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Max Tulyev Sent: woensdag 21 oktober 2009 18:42 To: address-policy-wg at ripe.net Subject: [address-policy-wg] RIPE staff vs Court Hello! Today I just got a strange letter from RIPE staff. I didn't saw anything like that before. They told me about a ten of networks registered through our LIR. All these networks have changed admin-c and tech-c to other country, and routed through one server on that country. Based on this, RIPE man sent the notification about reclamation of that networks, as "that seems to don't be valid anymore." Of course, I immediately contacted my client and asked what's happened. He said they work as usual, but one certain offshore IT company is used to manage their networks. So they changed contact details to that company, as that company is correct contact point in any network questions. And traffic flows through the offshore company site as they manage and control it, hosts data, etc. >From one point of view, situation seems very strange. From second - nothing to be not real in practice. So we (first time?) faced with IP reclamation dispute. I don't really know did our clients something bad - perhaps no, as none from these nets listed at Spamhouse ;). I think it is 50/50. May be they told me (and RIPE) truth, may be lied. I can't 100% check it by tools/rights/possibilities I have. But about ten of businesses are on decision of one person that "seems to ...". My strong position is THERE SHOULD BE A COURT DECISION OR OUR COMMUNITY COURT-LIKE STRUCTURE, and only that structure based on court-like controversy process (if not a real court) can make a decision about reclaim any address space. NO WAYS LIKE "IT SEEMS TO...". So now we have: http://www.ripe.net/ripe/docs/ripe-475.html#42 My proposal is to change: "Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User" to "Violation of Law by the End User, supported by a Dutch court order; or violation of RIPE Policy by the End User, SUPPORTED BY..." By what? By Dutch Court? By some independent court-like staff? Any ideas? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Wed Oct 21 20:21:19 2009 From: president at ukraine.su (Max Tulyev) Date: Wed, 21 Oct 2009 21:21:19 +0300 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <01da01ca5278$892d4900$9b87db00$@nl> References: <4ADF39F4.5010705@ukraine.su> <01da01ca5278$892d4900$9b87db00$@nl> Message-ID: <4ADF511F.7050805@ukraine.su> Hello Mark, I'm not against RIPE decision now, I'm against drop down ten businesses down just because one man thought that "it seems" something for him. Each such business-critical case should be pedantic investigated by a group of authoritative people, if not a court. No way any "it seems..."! While Dutch Court process a case (it is not a hours or days, much more I think) clients will went away, isn't it? Mark Scholten wrote: > Hello Max, > > As long as it is Dutch Court I don't see a problem. > > If you are against a decision RIPE did make you can go to Dutch Court and > ask if they decide to change it. > > With kind regards, > > Mark Scholten > > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Max Tulyev > Sent: woensdag 21 oktober 2009 18:42 > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] RIPE staff vs Court > > Hello! > > Today I just got a strange letter from RIPE staff. I didn't saw anything > like that before. They told me about a ten of networks registered > through our LIR. All these networks have changed admin-c and tech-c to > other country, and routed through one server on that country. > > Based on this, RIPE man sent the notification about reclamation of that > networks, as "that seems to don't be valid anymore." > > Of course, I immediately contacted my client and asked what's happened. > He said they work as usual, but one certain offshore IT company is used > to manage their networks. So they changed contact details to that > company, as that company is correct contact point in any network > questions. And traffic flows through the offshore company site as they > manage and control it, hosts data, etc. > >>From one point of view, situation seems very strange. From second - > nothing to be not real in practice. So we (first time?) faced with IP > reclamation dispute. I don't really know did our clients something bad - > perhaps no, as none from these nets listed at Spamhouse ;). I think it > is 50/50. May be they told me (and RIPE) truth, may be lied. I can't > 100% check it by tools/rights/possibilities I have. > > But about ten of businesses are on decision of one person that "seems to > ...". > > My strong position is THERE SHOULD BE A COURT DECISION OR OUR COMMUNITY > COURT-LIKE STRUCTURE, and only that structure based on court-like > controversy process (if not a real court) can make a decision about > reclaim any address space. NO WAYS LIKE "IT SEEMS TO...". > > So now we have: http://www.ripe.net/ripe/docs/ripe-475.html#42 > My proposal is to change: > "Violation of Law by the End User, supported by a Dutch court order; or > violation of RIPE Policy by the End User" > to > "Violation of Law by the End User, supported by a Dutch court order; or > violation of RIPE Policy by the End User, SUPPORTED BY..." > > By what? By Dutch Court? By some independent court-like staff? Any ideas? > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From marcoh at marcoh.net Wed Oct 21 20:14:54 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 21 Oct 2009 20:14:54 +0200 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <01da01ca5278$892d4900$9b87db00$@nl> References: <4ADF39F4.5010705@ukraine.su> <01da01ca5278$892d4900$9b87db00$@nl> Message-ID: On Oct 21, 2009, at 8:01 PM, Mark Scholten wrote: > Hello Max, > > As long as it is Dutch Court I don't see a problem. > > If you are against a decision RIPE did make you can go to Dutch > Court and > ask if they decide to change it. No you can't...under the standard service agreement which you signed when you became a LIR you signed for the conflict arbitration procedure which is described in RIPE-174. To comment on the orginal complaint, seems to me you got bitten by RIPE-471, section 6.6: ==== 6.6 Validity of an Assignment All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid. For these reasons it is important that LIRs make sure that assignments approved by the RIPE NCC are properly registered in the database. The inetnum object or objects for approved assignments must use the netname(s) approved by the RIPE NCC and not be larger than the approved size. Additionally, the date in the first ?changed:? attribute must not be earlier than the date of the approval message from the RIPE NCC. The RIPE NCC reviews assignments made by LIRs when evaluating requests for additional allocations (see 5.3). It also runs consistency checks as part of the auditing activity requested by the community as described in the RIPE document ?RIPE NCC Audit Activity? found at: http://www.ripe.net/ripe/docs/audit.html ==== So as I understand the big question here is if the original criteria on which those assignments are made still are valid by changing registration data and administratively move them to another entity or country. I guess the only people who can answer that question are the NCC hostmasters, please keep in mind this is a RIPE community mailinglist and not the NCC who you are complaining to. Nobody on this mailinglist has access to supporting documents or when they do are bound by NDA so nobody on this list is capable of making sany sane judgement wether this complaint is justified or what the background is for sending the letter about reclaiming space in the first place. So please as a simple request, please take this to where it belongs and contact hostmaster at ripe about this or start a arbitration as described in 174: "Initiation of the Procedure In case of conflicts both parties should document their grievances and communicate them to the other party. They should then try to resolve the conflict between themselves. Only if such resolution has been tried and documented by at least one of the parties can the formal procedure start. The party initiating the procedure will select an arbiter from the pool and provide the arbiter with a written summary of their position in the conflict as well as documentation of their efforts to resolve it. The arbiter shall verify that sufficient attempts at direct resolution have been made. He shall then notify the other party that the resolution procedure has been initiated. The other party will then have two calendar weeks to either accept arbitration by this arbiter or to select one of their own from the pool. If they do not react within this time, the first arbiter can decide to proceed with the single arbiter procedure or to select another arbiter from the pool for the other party and proceed with the three arbiter procedure." Thank you MarcoH From president at ukraine.su Wed Oct 21 20:36:57 2009 From: president at ukraine.su (Max Tulyev) Date: Wed, 21 Oct 2009 21:36:57 +0300 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: References: <4ADF39F4.5010705@ukraine.su> <01da01ca5278$892d4900$9b87db00$@nl> Message-ID: <4ADF54C9.5040400@ukraine.su> Marco, I'm not comlaining for a certain hostmaster. I'm trying to adjust a policy when one man with their feeling or opinion can't drop down somebody's business. The difference is very big: will you go through arbitration BEFORE or AFTER the blackdown of your network. Marco Hogewoning wrote: > > On Oct 21, 2009, at 8:01 PM, Mark Scholten wrote: > >> Hello Max, >> >> As long as it is Dutch Court I don't see a problem. >> >> If you are against a decision RIPE did make you can go to Dutch Court and >> ask if they decide to change it. > > > No you can't...under the standard service agreement which you signed > when you became a LIR you signed for the conflict arbitration procedure > which is described in RIPE-174. > > To comment on the orginal complaint, seems to me you got bitten by > RIPE-471, section 6.6: > > ==== > 6.6 Validity of an Assignment > All assignments are valid as long as the original criteria on which the > assignment was based are still valid and the assignment is properly > registered in the RIPE Database. If an assignment is made for a specific > purpose and that purpose no longer exists, the assignment is no longer > valid. If an assignment is based on information that turns out to be > invalid, the assignment is no longer valid. > > For these reasons it is important that LIRs make sure that assignments > approved by the RIPE NCC are properly registered in the database. The > inetnum object or objects for approved assignments must use the > netname(s) approved by the RIPE NCC and not be larger than the approved > size. Additionally, the date in the first ?changed:? attribute must not > be earlier than the date of the approval message from the RIPE NCC. > > The RIPE NCC reviews assignments made by LIRs when evaluating requests > for additional allocations (see 5.3). It also runs consistency checks as > part of the auditing activity requested by the community as described in > the RIPE document ?RIPE NCC Audit Activity? found at: > http://www.ripe.net/ripe/docs/audit.html > > ==== > > So as I understand the big question here is if the original criteria on > which those assignments are made still are valid by changing > registration data and administratively move them to another entity or > country. > > I guess the only people who can answer that question are the NCC > hostmasters, please keep in mind this is a RIPE community mailinglist > and not the NCC who you are complaining to. Nobody on this mailinglist > has access to supporting documents or when they do are bound by NDA so > nobody on this list is capable of making sany sane judgement wether this > complaint is justified or what the background is for sending the letter > about reclaiming space in the first place. > > So please as a simple request, please take this to where it belongs and > contact hostmaster at ripe about this or start a arbitration as described > in 174: > > "Initiation of the Procedure > > In case of conflicts both parties should document their grievances and > communicate them to the other party. They should then try to resolve the > conflict between themselves. Only if such resolution has been tried and > documented by at least one of the parties can the formal procedure > start. The party initiating the procedure will select an arbiter from > the pool and provide the arbiter with a written summary of their > position in the conflict as well as documentation of their efforts to > resolve it. The arbiter shall verify that sufficient attempts at direct > resolution have been made. He shall then notify the other party that the > resolution procedure has been initiated. The other party will then have > two calendar weeks to either accept arbitration by this arbiter or to > select one of their own from the pool. If they do not react within this > time, the first arbiter can decide to proceed with the single arbiter > procedure or to select another arbiter from the pool for the other party > and proceed with the three arbiter procedure." > > Thank you > > MarcoH > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From marcoh at marcoh.net Wed Oct 21 20:47:47 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 21 Oct 2009 20:47:47 +0200 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <4ADF511F.7050805@ukraine.su> References: <4ADF39F4.5010705@ukraine.su> <01da01ca5278$892d4900$9b87db00$@nl> <4ADF511F.7050805@ukraine.su> Message-ID: On Oct 21, 2009, at 8:21 PM, Max Tulyev wrote: > Hello Mark, > > I'm not against RIPE decision now, I'm against drop down ten > businesses > down just because one man thought that "it seems" something for him. > > Each such business-critical case should be pedantic investigated by a > group of authoritative people, if not a court. No way any "it > seems..."! > > While Dutch Court process a case (it is not a hours or days, much > more I > think) clients will went away, isn't it? Well depends, let's assume you find yourself a lawyer and go to court: - judge points you back to arbitration in 5 minutes - judge decides other wise: - reclaims the addresses This simply creates the big and feared red button all those film and record companies are hoping for, any case of copyright infringment within the RIPE region has a real good chance of ending up in Dutch court to reclaim the IPs. Wether this actually will stop routing is not important, it's because they can. - he dedcides you can keep the addresses. Oh great, if a request is turned down by a hostmaster I can now go to court and fight over that last /8. Now there is a fair chance that both decissions are appealed for and then again and again, which will take years and years and wil bring significant cost to the NCC, which in the end has to be paid by the members, that's you, me and approx 6000 others. It will be a strange situation that while you fight them, technically you pay the lawyers on both sides :) In the meantime what that judge in his internal wisdom has done, is proclaim himself to boss of the internet, IANA can go and further assigments are done by the joined Dutch judges in which case I think the Dutch government has someting to explain to the rest of the world. And yes I have been in court cases about IP addresses and yes you can forget about a judge actually understanding the mechanisms at work and make a sensible judgement inline with what was internationally agreed on. Taking this to court will make everybody cry, one way or another there is a fair chance we will end with nothing but loosers and a huge bill to pay. I can understand you are pissed off, I would be too if I recieved such a letter. Let it cool down for a bit, count to ten and tomorrow try and contact a hostmaster or IPRA as they are called these days to explain what happened here and see if you can work out how to correct this following the regular processes. If this fails please try arbitration first before going to court, the procedure is there and is very clear and you save the community from a hell of a headache and the membership from a huge bill. MarcoH From marcoh at marcoh.net Wed Oct 21 21:07:15 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 21 Oct 2009 21:07:15 +0200 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <4ADF54C9.5040400@ukraine.su> References: <4ADF39F4.5010705@ukraine.su> <01da01ca5278$892d4900$9b87db00$@nl> <4ADF54C9.5040400@ukraine.su> Message-ID: <970ACE99-2FB1-4521-BAD6-90B4EFA0C9D8@marcoh.net> On Oct 21, 2009, at 8:36 PM, Max Tulyev wrote: > Marco, > > I'm not comlaining for a certain hostmaster. I'm trying to adjust a > policy when one man with their feeling or opinion can't drop down > somebody's business. > > The difference is very big: will you go through arbitration BEFORE or > AFTER the blackdown of your network. Well technically there are no ways for the NCC to stop you from using the IP addresses although they will be flagged as bogon in a lot of systems. Secondly, the document you point to (RIPE-475) has some clear guidelines in 4.2.1, which gives you 30 days to respond and resolve any issues. Now either your contact details are out of date and you missed an email, but you should still have a couple of weeks at least. In respect to your orginal comments, the full article here states: > "The RIPE NCC will de-register the independent Internet number > resources in case of a fundamental breach of contract by the End > User, supported by a Dutch court order; or > Violation of Law by the End User, supported by a Dutch court order; > or violation of RIPE Policy by the End User." > No where there is any mention it is a one man job to decide wether there is a violation, it says 'RIPE NCC' which is a legal entity, who in it's turn has a bunch of people on the payroll to check wether allocation and assignment policies are followed. Now obviously it can be the case that one IPRA on it's own decides the assignment is no longer valid accoording to RIPE-471 but my guess is that in case of any doubt things are double checked before the axe is raised and if they do so, you should have some time to respond, ask them to explain what happened and possibly talk to another hostmaster. If this all fails you have the arbitration procedure. As far as AP is concerned I don't see how we can help, you have a conflict with the NCC not with the community. This has no relation with assignment and allocation guidelines, they are all there and pretty clear. They are also very clear what happens if you don't confirm to the policy and which enitity makes that decission, it's the RIPE NCC a group of people who are in a seperate legal enitity and who are controlled by and finally paid for by the members. Your position to ask for and I quote "...OUR COMMUNITY COURT-LIKE STRUCTURE" is there, it's called RIPE-174. MarcoH From davidm at futureinquestion.net Thu Oct 22 20:56:24 2009 From: davidm at futureinquestion.net (David Monosov) Date: Thu, 22 Oct 2009 20:56:24 +0200 Subject: [address-policy-wg] Details regarding the progress of 2007-01 Phase 2 implementation? Message-ID: <4AE0AAD8.4080209@futureinquestion.net> Dear address-policy-wg, As phase 2 of the implementation of 2007-01 is well underway and gradually approaching its conclusion, it might be both interesting and beneficial to see some details about the success of this effort so far. Could RIPE NCC furnish the following data at their earliest convenience for the benefit of this work group, and if workload permits, provide monthly updates until phase 2 is complete? - Number and % of direct assignments marked by LIRs as "My End User". - Number and % of direct assignments marked by LIRs as "Not My End User". - Number and % of direct assignments marked by LIRs as "My Infrastructure". - Number and % of direct assignments marked by LIRs as "My End User" for which contracts and registration information were provided but are not yet processed. - Number and % of direct assignments marked by LIRs as "My End User" for which contracts and registration information were provided and subsequently approved by RIPE NCC. - Number and % of direct assignments marked by LIRs as "My End User" for which contracts and registration information were provided and subsequently rejected by RIPE NCC. - Number and % of direct assignments which fall under the scope of 2007-01 phase 2 which remain completely untreated. This data should provide some insight about the challenges that further implementation phases will entail, and create an opportunity for the community to address such challenges on the policy level in a timely manner if required. -- Respectfully yours, David Monosov From michael.dillon at bt.com Thu Oct 22 23:05:30 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 22 Oct 2009 22:05:30 +0100 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <01da01ca5278$892d4900$9b87db00$@nl> Message-ID: <28E139F46D45AF49A31950F88C49745803AF8169@E03MVZ2-UKDY.domain1.systemhost.net> > If you are against a decision RIPE did make you can go to > Dutch Court and ask if they decide to change it. It's better for RIPE to not make dumb decisions so that nobody has to go to court. If reclamation is going to happen, it has to follow some kind of notification process with an appeal period. --Michael Dillon From michael.dillon at bt.com Thu Oct 22 23:23:53 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 22 Oct 2009 22:23:53 +0100 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745803AF816E@E03MVZ2-UKDY.domain1.systemhost.net> > Nobody on this mailinglist has access to supporting documents > or when they do are bound by NDA so nobody on this list is > capable of making sany sane judgement It would be interesting to see a copy of the letter that was sent to Max. > So please as a simple request, please take this to where it > belongs and contact hostmaster at ripe about this or start a > arbitration as described in 174: Was that mentioned in the letter? If not, it should be. Lots of companies offshore work including us. However, even if the work is being done in India by people with email addresses from an Indian company, all of our networks are still owned and operated by BT. We don't outsource core assets, and I doubt that anyone else does. Hostmasters who see something that looks like a transfer of number resources should assume that it is really just outsourcing of work, and make inquiries to confirm the status of the number resources. In fact, its about time we get rid of that horrid name. The people are not masters of anything or anyone, and the work that they do has nothing to do with hosts. They handle member relations and we should have a name for them that reflects that. --Michael Dillon From marcoh at marcoh.net Thu Oct 22 23:29:46 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 22 Oct 2009 23:29:46 +0200 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <28E139F46D45AF49A31950F88C49745803AF816E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803AF816E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <5FC154A9-272D-44A3-8FDE-71C172B21C0F@marcoh.net> > In fact, its about time we get rid of that horrid name. > The people are not masters of anything or anyone, and the work > that they do has nothing to do with hosts. They handle member > relations and we should have a name for them that reflects that. The official name has been IP resource analyst or IPRA in short for ages now. Marco From jim at rfc1035.com Fri Oct 23 10:32:34 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 23 Oct 2009 09:32:34 +0100 Subject: [address-policy-wg] transfers of number resources within an LIR In-Reply-To: <28E139F46D45AF49A31950F88C49745803AF816E@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803AF816E@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On 22 Oct 2009, at 22:23, wrote: > Hostmasters who see something that looks like a transfer of number > resources should assume that it is really just outsourcing of work Er, no. They should not do that. Or make any sorts of assumptions about an LIR's business. It may well be that inside BT transfers of number resources tend to be accompanied by some sort of outsourcing arrangement. I doubt that will always be the case. Even if this was always true for every BT transfer, that doesn't mean it'll be true for any other LIR. And it would not be wise for RIPE to have LIR-specific policies or actions whenever an LIR is shuffling number resources around its organisation. > and make inquiries to confirm the status of the number resources. Yes. Which is what they should be doing anyway whenever an LIR's number resources are moved around. From michael.dillon at bt.com Fri Oct 23 11:13:55 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 23 Oct 2009 10:13:55 +0100 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <5FC154A9-272D-44A3-8FDE-71C172B21C0F@marcoh.net> Message-ID: <28E139F46D45AF49A31950F88C49745803AF844F@E03MVZ2-UKDY.domain1.systemhost.net> > The official name has been IP resource analyst or IPRA in > short for ages now. Then why do they still use hostmaster at ripe.net ? Why don't documents say: Send an email to the IP Resource Analysts at enquiries at ripe.net and: Send the template to the automated request system at requests at ripe.net Let's just stamp out this antiquated meaningless word from all RIPE documents. --Michael Dillon From andrea at ripe.net Fri Oct 23 16:44:00 2009 From: andrea at ripe.net (Andrea Cima) Date: Fri, 23 Oct 2009 16:44:00 +0200 Subject: [address-policy-wg] Allocations/assignements statistics ? In-Reply-To: <4AD04351.5020504@is-production.com> References: <4AD04351.5020504@is-production.com> Message-ID: <4AE1C130.3040701@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Bernard, The numbers below are based on the data used for the Charging Scheme. All independent Internet number resources listed by LIRs as "Not My End-User", through the 2007-01 interface, have been excluded. IPv4 PA; # of LIRs; # of Allocations; # of IPs Extra Small; 1,282; 1,005; 2.4 million Small; 3,540; 4,438; 25.2 million Medium; 1,288; 3,982; 65.1 million Large; 258; 2,126; 224.5 million Extra Large; 64; 915; 421.3 million IPv6 PA, # of Allocations Extra Small; 28 Small; 822 Medium; 581 Large; 192 Extra Large; 65 Independent Resources, # of Assignments Extra Small; 2,115 Small; 6,202 Medium; 7,421 Large; 4,726 Extra Large; 2,190 I hope this helps. If you have any questions please don't hesitate to contact me. Best regards, Andrea Cima RIPE NCC Bernard Dugas wrote: > Dear Colleagues, > > To analyse the use of IPV4 currently, i need to have the number and size > of IPV4 prefixes, PA allocated and PI assigned, and ASN, linked to the 5 > membership categories. > > It should be consistent with other data avalaible, meaning that snapshot > of 20090930 would be optimal. > > Thanks a lot, > Best regards, -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrhwTAACgkQXOgsmPkFrjNaRwCdHRsl6ivu2IyVhAtyJe/jThGu lsAAni1oXZDV+MOlVd7PnUafN4bCzpPY =GkIn -----END PGP SIGNATURE----- From dr at cluenet.de Sat Oct 24 02:04:27 2009 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 24 Oct 2009 02:04:27 +0200 Subject: [address-policy-wg] Re: Details regarding the progress of 2007-01 Phase 2 implementation? In-Reply-To: <4AE0AAD8.4080209@futureinquestion.net> References: <4AE0AAD8.4080209@futureinquestion.net> Message-ID: <20091024000427.GA9536@srv03.cluenet.de> Hi, On Thu, Oct 22, 2009 at 08:56:24PM +0200, David Monosov wrote: > As phase 2 of the implementation of 2007-01 is well underway and gradually > approaching its conclusion, it might be both interesting and beneficial to see > some details about the success of this effort so far. Indeed, this data would be interesting. Thanks for the suggestion. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From richard.cox at btuser.net Sat Oct 24 03:05:49 2009 From: richard.cox at btuser.net (Richard Cox) Date: Sat, 24 Oct 2009 01:05:49 +0000 Subject: [address-policy-wg] RIPE staff vs Court In-Reply-To: <4ADF39F4.5010705@ukraine.su> Message-ID: On Wed, 21 Oct 2009 16:42 UTC Max Tulyev wrote: > I don't really know did our clients something bad - perhaps > no, as none from these nets listed at Spamhouse ;). Whether the clients did "something bad" isn't really relevant here. What is relevant is whether the clients you say you now have, really are the same people to whom the original IP/ASN allocations were made. What can you tell us about these clients? > Of course, I immediately contacted my client Ah, now it's just ONE client? But these ten networks were all (originally) registered to ten different organisations, yes? From: "6.6 Validity of an Assignment" "If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid." > and asked what's happened. He said they work as usual, but one > certain offshore IT company is used to manage their networks. I'm sure people here would rapidly understand the real situation if you were to explain which (and where) that "offshore IT company" was, and who is actually running it. -- Richard Cox Co-Chair, Anti-Abuse Working Group but writing in a personal capacity ... From bernard.dugas.2009 at is-production.com Sat Oct 24 17:13:01 2009 From: bernard.dugas.2009 at is-production.com (Bernard Dugas) Date: Sat, 24 Oct 2009 17:13:01 +0200 Subject: [address-policy-wg] Allocations/assignements statistics ? In-Reply-To: <4AE1C130.3040701@ripe.net> References: <4AD04351.5020504@is-production.com> <4AE1C130.3040701@ripe.net> Message-ID: <4AE3197D.2070808@is-production.com> Bonjour Andrea, Thank you for these very informational data. As you invite me, i have some questions to understand precisely some details : Andrea Cima wrote: > The numbers below are based on the data used for the Charging Scheme. Dated 2009-09-30 ? > All independent Internet number resources listed by LIRs as "Not My > End-User", through the 2007-01 interface, have been excluded. Please can you also give the global numbers of allocations and size, to have the relative idea ? This is like it was another category TBD :-) If you don't have precise number, no problem, i just need to know if this is 1% or 30% ! > IPv4 PA; # of LIRs; # of Allocations; # of IPs clear for me. > IPv6 PA, # of Allocations Would you please have size, even if we know it is still small ? > Independent Resources, # of Assignments I imagine from your fisrt statement that these are all PI except "Not my end user" ? > Extra Small; 2,115 > Small; 6,202 > Medium; 7,421 > Large; 4,726 > Extra Large; 2,190 To have a complete view, do you have also numbers of AS ? > I hope this helps. If you have any questions please don't hesitate to > contact me. Yes, it helps a lot, thank you very much ! Best regards, -- __Bernard DUGAS ______________________________________________________ | IS Production s.a. Innovative Solutions | From hank at efes.iucc.ac.il Sun Oct 25 07:36:27 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 25 Oct 2009 08:36:27 +0200 Subject: [address-policy-wg] Details regarding the progress of 2007-01 Phase 2 implementation? In-Reply-To: <4AE0AAD8.4080209@futureinquestion.net> Message-ID: <5.1.0.14.2.20091025083610.00bc3c20@efes.iucc.ac.il> At 20:56 22/10/2009 +0200, David Monosov wrote: Excellent questions and I hope RIPE responds. -Hank >Dear address-policy-wg, > >As phase 2 of the implementation of 2007-01 is well underway and gradually >approaching its conclusion, it might be both interesting and beneficial to see >some details about the success of this effort so far. > >Could RIPE NCC furnish the following data at their earliest convenience >for the >benefit of this work group, and if workload permits, provide monthly updates >until phase 2 is complete? > >- Number and % of direct assignments marked by LIRs as "My End User". >- Number and % of direct assignments marked by LIRs as "Not My End User". >- Number and % of direct assignments marked by LIRs as "My Infrastructure". >- Number and % of direct assignments marked by LIRs as "My End User" for which >contracts and registration information were provided but are not yet >processed. >- Number and % of direct assignments marked by LIRs as "My End User" for which >contracts and registration information were provided and subsequently approved >by RIPE NCC. >- Number and % of direct assignments marked by LIRs as "My End User" for which >contracts and registration information were provided and subsequently rejected >by RIPE NCC. >- Number and % of direct assignments which fall under the scope of 2007-01 >phase >2 which remain completely untreated. > >This data should provide some insight about the challenges that further >implementation phases will entail, and create an opportunity for the community >to address such challenges on the policy level in a timely manner if required. > >-- >Respectfully yours, > >David Monosov From andrea at ripe.net Mon Oct 26 12:47:47 2009 From: andrea at ripe.net (Andrea Cima) Date: Mon, 26 Oct 2009 12:47:47 +0100 Subject: [address-policy-wg] Details regarding the progress of 2007-01 Phase 2 implementation? In-Reply-To: <4AE0AAD8.4080209@futureinquestion.net> References: <4AE0AAD8.4080209@futureinquestion.net> Message-ID: <4AE58C63.5080502@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear David, David Monosov wrote: > Dear address-policy-wg, > > As phase 2 of the implementation of 2007-01 is well underway and gradually > approaching its conclusion, it might be both interesting and beneficial to see > some details about the success of this effort so far. > > Could RIPE NCC furnish the following data at their earliest convenience for the > benefit of this work group, and if workload permits, provide monthly updates > until phase 2 is complete? The numbers below are from 2009-10-26. The total number of independent Internet number resources included in phase 2 are 26940 and the number of LIRs involved is 4903. Currently about 88% of independent resources involved in phase 2 have their status set (23790 out of 26940); Currently about 73% (3617 out of 4903) of LIRs have participated. > - Number and % of direct assignments marked by LIRs as "My End User". 12187 independent resources have been marked as "My End User". > - Number and % of direct assignments marked by LIRs as "Not My End User". 6705 independent resources have been marked as "Not My End User". > - Number and % of direct assignments marked by LIRs as "My Infrastructure". 4652 independent resources have been marked as "My Infrastructure". > - Number and % of direct assignments marked by LIRs as "My End User" for which > contracts and registration information were provided but are not yet processed. About 750. > - Number and % of direct assignments marked by LIRs as "My End User" for which > contracts and registration information were provided and subsequently approved > by RIPE NCC. About 760 (this number and the one above also include about 200 contracts received for independent resource transfers between LIRs). LIRs will soon be reminded about the timelines. > - Number and % of direct assignments marked by LIRs as "My End User" for which > contracts and registration information were provided and subsequently rejected > by RIPE NCC. We do not reject the contract. if the contract does not fulfill the requirements we will work together with the LIR to fix the inconsistency. > - Number and % of direct assignments which fall under the scope of 2007-01 phase > 2 which remain completely untreated. About 12% (3150 independent resources). I hope this helps. If you have any questions please don't hesitate to contact me. Best regards, Andrea Cima RIPE NCC > This data should provide some insight about the challenges that further > implementation phases will entail, and create an opportunity for the community > to address such challenges on the policy level in a timely manner if required. > > -- > Respectfully yours, > > David Monosov > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrljGMACgkQXOgsmPkFrjPK9ACdFEkobOyFz0rRKdqX9JGQQwVK /XgAnA+T1KAUuOKXSz8X+BR9Cpkvo6FI =mpvE -----END PGP SIGNATURE----- From hank at efes.iucc.ac.il Mon Oct 26 13:42:42 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 26 Oct 2009 14:42:42 +0200 Subject: [address-policy-wg] Details regarding the progress of 2007-01 Phase 2 implementation? In-Reply-To: <4AE58C63.5080502@ripe.net> References: <4AE0AAD8.4080209@futureinquestion.net> <4AE0AAD8.4080209@futureinquestion.net> Message-ID: <5.1.0.14.2.20091026144131.056104c0@efes.iucc.ac.il> At 12:47 26/10/2009 +0100, Andrea Cima wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >Dear David, > >David Monosov wrote: > > Dear address-policy-wg, > > > > As phase 2 of the implementation of 2007-01 is well underway and gradually > > approaching its conclusion, it might be both interesting and beneficial > to see > > some details about the success of this effort so far. > > > > Could RIPE NCC furnish the following data at their earliest convenience > for the > > benefit of this work group, and if workload permits, provide monthly > updates > > until phase 2 is complete? > >The numbers below are from 2009-10-26. >The total number of independent Internet number resources included in >phase 2 are 26940 and the number of LIRs involved is 4903. > >Currently about 88% of independent resources involved in phase 2 have >their status set (23790 out of 26940); > >Currently about 73% (3617 out of 4903) of LIRs have participated. > > > - Number and % of direct assignments marked by LIRs as "My End User". > >12187 independent resources have been marked as "My End User". > > > - Number and % of direct assignments marked by LIRs as "Not My End User". > >6705 independent resources have been marked as "Not My End User". > > > - Number and % of direct assignments marked by LIRs as "My Infrastructure". > >4652 independent resources have been marked as "My Infrastructure". > > > - Number and % of direct assignments marked by LIRs as "My End User" > for which > > contracts and registration information were provided but are not yet > processed. > >About 750. > > > - Number and % of direct assignments marked by LIRs as "My End User" > for which > > contracts and registration information were provided and subsequently > approved > > by RIPE NCC. > >About 760 (this number and the one above also include about 200 >contracts received for independent resource transfers between LIRs). > >LIRs will soon be reminded about the timelines. > > > - Number and % of direct assignments marked by LIRs as "My End User" > for which > > contracts and registration information were provided and subsequently > rejected > > by RIPE NCC. > >We do not reject the contract. if the contract does not fulfill the >requirements we will work together with the LIR to fix the inconsistency. > > > - Number and % of direct assignments which fall under the scope of > 2007-01 phase > > 2 which remain completely untreated. > >About 12% (3150 independent resources). What does RIPE NCC plan on doing with these? Timeline? Treatment? Perhaps a special RIPE doc for this? >I hope this helps. Excellently! -Hank >If you have any questions please don't hesitate to contact me. > >Best regards, > >Andrea Cima >RIPE NCC > > > > This data should provide some insight about the challenges that further > > implementation phases will entail, and create an opportunity for the > community > > to address such challenges on the policy level in a timely manner if > required. > > > > -- > > Respectfully yours, > > > > David Monosov > > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.11 (Darwin) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iEYEARECAAYFAkrljGMACgkQXOgsmPkFrjPK9ACdFEkobOyFz0rRKdqX9JGQQwVK >/XgAnA+T1KAUuOKXSz8X+BR9Cpkvo6FI >=mpvE >-----END PGP SIGNATURE----- From andrea at ripe.net Tue Oct 27 17:52:24 2009 From: andrea at ripe.net (Andrea Cima) Date: Tue, 27 Oct 2009 17:52:24 +0100 Subject: [address-policy-wg] Details regarding the progress of 2007-01 Phase 2 implementation? In-Reply-To: <5.1.0.14.2.20091026144131.056104c0@efes.iucc.ac.il> References: <4AE0AAD8.4080209@futureinquestion.net> <4AE0AAD8.4080209@futureinquestion.net> <5.1.0.14.2.20091026144131.056104c0@efes.iucc.ac.il> Message-ID: <4AE72548.70001@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Hank, Hank Nussbacher wrote: [...] >> - Number and % of direct assignments which fall under the scope of > 2007-01 phase >> 2 which remain completely untreated. > > About 12% (3150 independent resources). > >> What does RIPE NCC plan on doing with these? Timeline? Treatment? >> Perhaps a special RIPE doc for this? The resources that do not have a contract in place by the end of Phase 2 will be considered 'orphaned' and will be made part of Phase 3 (contact the End Users of those resources directly). As we now have a better insight into the number of resources we will be dealing with, we are working on the Phase 3 process. As you suggest, before starting Phase 3, we will publish a procedural document detailing the process. With regards to the timeline, we are currently assessing the implications of contacting End Users who have been assigned resources in the past. Best regards, Andrea Cima RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrnJUgACgkQXOgsmPkFrjOG4wCgj8DAAIxxcSwv1z2ZM6wzZQHu t2oAoJHgKd4pEU94iMA8Fq07wvmf7R86 =tiGC -----END PGP SIGNATURE----- From hank at efes.iucc.ac.il Tue Oct 27 19:41:56 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 27 Oct 2009 20:41:56 +0200 (IST) Subject: [address-policy-wg] Details regarding the progress of 2007-01 Phase 2 implementation? In-Reply-To: <4AE72548.70001@ripe.net> References: <4AE0AAD8.4080209@futureinquestion.net> <4AE0AAD8.4080209@futureinquestion.net> <5.1.0.14.2.20091026144131.056104c0@efes.iucc.ac.il> <4AE72548.70001@ripe.net> Message-ID: On Tue, 27 Oct 2009, Andrea Cima wrote: > The resources that do not have a contract in place by the end of Phase 2 > will be considered 'orphaned' and will be made part of Phase 3 (contact > the End Users of those resources directly). May I suggest that as stage 1, postal mail be sent as well as email not only to the tech-c, admin-c etc but also to the email address as listed here: http://puck.nether.net/netops/nocs.cgi This way you have a better chance of actually getting someone. If no contact after 3 weeks, at stage 2, check the RIB and look for the upstream peers of the ASN announcing the resource (ASN or IP space). Send email to those tech-c and admin-c and NOCs as well as postal mail informing them that a downstream customer of theirs has gone AWOL. If the resource is not being announced then needless to say, you can skip this stage. Regards, Hank > > As we now have a better insight into the number of resources we will be > dealing with, we are working on the Phase 3 process. > > As you suggest, before starting Phase 3, we will publish a procedural > document detailing the process. With regards to the timeline, we are > currently assessing the implications of contacting End Users who have > been assigned resources in the past. > > Best regards, > > Andrea Cima > RIPE NCC > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.11 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrnJUgACgkQXOgsmPkFrjOG4wCgj8DAAIxxcSwv1z2ZM6wzZQHu > t2oAoJHgKd4pEU94iMA8Fq07wvmf7R86 > =tiGC > -----END PGP SIGNATURE----- > From ingrid at ripe.net Thu Oct 29 11:20:25 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 29 Oct 2009 11:20:25 +0100 Subject: [address-policy-wg] 2009-03 Last Call for Comments (Run Out Fairly) Message-ID: <20091029102025.EE7852F599@herring.ripe.net> PDP Number: 2009-03 Run Out Fairly Dear Colleagues, The proposal described in 2009-03 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html Please note that we have also updated the proposal to version two. This new version has some minor textual changes, clarifying the intent of paragraph 6.3. Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 26 November 2009. Regards Ingrid Wijte Policy Development Officer RIPE NCC