August 2013 - address-policy-wg

enforcing abuse requests for counterfeit goods, child pornography, etc…
by Yoann Bohbot 29 Aug '13

29 Aug '13

Hi everyone, I have come across over a dozen "hosting" providers that host a slew of sites that are clearly selling illegal items. These "hosting" providers provide a contact address that is not checked, or at least not acted upon. I believe there should be policy enforcing your clients to respond to requests or they can have their ip addresses suspended. Using regular methods of law enforcement is almost useless, and they are not equipped with knowledge or equipment to handle these type of problems (counterfeit goods.) Domain resolutions take months and cost thousands. The only other option is you. Please consider.

3 3

2013-05 New Policy Proposal (No Restrictions on End User Assignments in Intra-RIR Transfers)
by Emilio Madaio 22 Aug '13

22 Aug '13

Dear Colleagues, A proposed change to RIPE Policy Document ripe-592, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-05/ We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 19 August 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC

13 19

regarding housecleaning efforts in absurdum
by Mikael Abrahamsson 19 Aug '13

19 Aug '13

First and foremost, I must say I am all for keeping the database up to date and making sure all resources are documented correctly. However, I know of at least one specific case where a PI network that was operationally handed over around the year 2000 (MNT object etc), is currently properly documented and the operational holder is willing to do everything needed to become the properly documented holder, but can't, because he can't produce transfer documents by the company initially holding it, because that company doesn't have any operational staff anymore. The staff at the time the PI network was operationally transfered is available, but isn't currently employed by the original company so they can't sign the required paperwork on the original company letterhead. RIPE NCC is now saying they're going to de-register the PI network and reclaim it because transfer documents for the handover done 13 years ago can't be produced. I think this is wrong. There should be some kind of statue of limitation on time for producing documents. The dispute isn't between the original company and the current operational holder, the dispute is solely between RIPE NCC and the current operational holder. What policy documents need to change for this to happen? -- Mikael Abrahamsson email: swmike(a)swm.pp.se

5 10

2013-03 Review Period extended until 14 August (No Need - Post-Depletion Reality Adjustment and Cleanup)
by Emilio Madaio 15 Aug '13

15 Aug '13

Dear Colleagues, The Review Period for the proposal 2013-03, "No Need - Post-Depletion Reality Adjustment and Cleanup", has been extended until 14 August. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-03 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Emilio Madaio Policy Development Officer RIPE NCC

2 1

Draft proposal: Guidance Requested: Reassigning Referenced ASNs
by Ingrid Wijte 14 Aug '13

14 Aug '13

Dear colleagues, Thank you for your feedback on this issue. Based on the input we have received we propose taking the following action: - The RIPE NCC will send an email to the maintainer and contacts of the RIPE Database objects in which the returned AS numbers are referenced, asking for the reference to be removed. - The RIPE NCC will send three additional reminders, at intervals of three weeks from each other, for a total of four emails. - If after four emails the reference is still in place, the RIPE NCC will update the RIPE Database object itself, removing the reference. - If the reference is being recreated within one month from deletion (possibly due to automatic updates), the RIPE NCC will contact the organisation through means of communication other than email. The total number of RIPE Database objects that reference returned AS numbers is currently about 2000. All references are in the policy attributes of aut-num objects. No route(6) objects are involved. Thank you again and best regards, Ingrid Wijte RIPE NCC

2 1

2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up)
by Emilio Madaio 12 Aug '13

12 Aug '13

Dear colleagues, The second version of the draft document for the policy proposal 2013-03 has been published, along with an impact analysis carried out by the RIPE NCC. Noteworthy changes in this version include: - Text that suggested contractual requirements are only "recommended" for PI space (section 7.0) has been removed. This text was dependent on previously established context discussing PI vs PA space. As version 1.0 of the proposal removed the PI discussion in the preceding paragraphs, the resulting lack of context made the sentence confusing. The statement was also incorrect, as contractual requirements have been mandatory for PI space since 2007-01 was accepted. - Additional wording has been added to explicitly state that PI space cannot be reassigned or further assigned to other parties (see section 7.0 for ASSIGNED PI). - The third point from the last /8 policy (section 5.1) has been removed, as this is considered a meaningless circular reference by the author. - General re-wording in some sections for improved readability. - The policy proposal 2012-03 has been withdrawn, so the related argument against the proposal has been removed from the rationale. You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2013-03 The draft document can be found at: https://www.ripe.net/ripe/policies/proposals/2013-03/draft We encourage you to read the draft document text and send any comments to <address-policy-wg(a)ripe.net> before 30 July 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC

36 138

Re: [address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up)
by Milton Mueller 12 Aug '13

12 Aug '13

I see now why people are confused about the conservation issue. Sylvain, the price in a market is not known in advance. I will be set by competitive bidding and reflect supply and demand. I don't know where you got this 1,75 Euro number or what on earth gives you the idea that the price will remain fixed. As supply diminishes, the price goes up. That creates powerful and effective conservation incentives. On Sun, Aug 11, 2013 at 2:29 PM, Sylvain Vallerot < sylvain.vallerot(a)opdop.net> wrote: > On Sun, Aug 11, 2013 at 03:45:22PM +0000, Milton L Mueller wrote: > > But if they have to pay a price that reflects the relative scarcity of > the > > resource they have a much stronger incentive to conserve that the > alternative > > situation you describe. "Commercials" cannot simply provide all the > addresses > > their customers want when they cannot replenish their stock without > paying a > > rising price. > > We are talking about 1,75 € per address and per year. > > I guess this wouldn't stop any commercial from reselling to a client who > asks for it, and certainly can pay for it, if conservation is abandonned. > > Best regards, > Sylvain > >

3 2

Guidance Requested: Changing the Status of PI Address Space
by andrea 11 Aug '13

11 Aug '13

Dear colleagues, The RIPE NCC has seen an increase in the number of organisations requesting to change the status of IP addresses from "assigned PI" to "allocated PA". At the Address Policy WG session during RIPE 66, we requested guidance from the RIPE community on what we should do with these requests. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the requests to turn PI assignments into PA allocations are coming from organisations that received a PI assignment in the past and have since become LIRs. These requests may also come from LIRs that have taken over End User organisations with PI addresses. PA allocations have more flexibility than PI assignments. With the scarcity of IPv4 addresses, organisations are looking to use this space for customer assignments or to transfer it, but are prevented from doing so by the policy for PI addresses. Problem: current RIPE Policy does not address the change in status from assigned PI to allocated PA. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Allow LIRs to change the status of their PI assignments to PA allocations (if equal or larger than the minimum allocation size) B. Do not allow LIRs to change the status of their PI assignments to PA allocations Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf Thank you in advance for your feedback Andrea Cima RIPE NCC

28 38

2013-03: Summary of amendments for version 3.0
by Tore Anderson 07 Aug '13

07 Aug '13

Hi APWG, As you all know, during the Review phase a couple of potentially problematic issues in the proposal was brought up, which I've offered to improve on by amending the proposal. I want to detail the individual amendments and how they impact the proposal, so that you can all review them before we send the new version of the proposal back to the NCC. I welcome your opinions on the amendments, but please also realise it is not an invitation to bikeshedding - I'm trying to find a middle ground the WG will find acceptable, not necessarily perfect. In doing so I hope that we can ensure that we won't be sending Emilio off on a wild goose chase when we ask him to create a new Impact Analysis - so if you are completely unable to live with any of this, then do speak now or forever hold your peace. I'd like to especially thank Filiz Yilmaz and Malcom Hutty for highlighting and elaborating on the issues that resulted in the first two amendments, and to Andrea, Emilio, and Marco from the NCC for collaborating with me on writing the texts of the last two amendments and confirming that there will be no misunderstandings as to their intent and interpretation. Amendment 1: Retain "Fairness" goal =================================== This amendment retains our community's overall philosophical and moral goal of fair distribution of IPv4 address space to end users operating networks. Our current IPv4 policy lumps together a "Fairness" and a "Conservation" goal (unlike our IPv6 policy, which separates the two). Seeking only to remove the latter, the current version of 2013-03 accidentally removed the former as well. The amendment makes no attempt to define what constitutes "fair distribution" in our current environment of scarcity - this will remain a value judgement each LIR has to make for themselves, just like it is today. The benefits of this amendment include: * Avoids throwing the baby out with the bathwater. * Guides LIRs to assign address space to end users who are operating networks, as well as to base any value judgement they would need to make related to this on their own notion of fairness. * Ensures that we keep the door open for a potential future discussion on how to define and possibly enforce fair distribution in an environment of scarcity. * Provides "ammunition" for the NCC in their talks and interactions with critical governments, regulators, or similar entities. The exact amendment, which is to be inserted into section 3.0 of the proposed policy, reads: «Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.» Note that except for the title, this is the exact same phrase as is found in our current policy. This is fully intentional, as 2013-03 has no ambition to alter previously agreed upon consensus in this regard. I chose the title "Fairness" to match the one used in the IPv6 policy document (ripe-589). Amendment 2: Retain "Need" for final /22 allocations ==================================================== This amendment retains the current practice of requiring the LIRs that seek to obtain their final /22 from the austerity ("last /8") allocation pool to use it for making assignments to their end users or their own infrastructure. This is not in conflict with 2013-03's "No Need" moniker, as changing the "last /8 policy" is not its ambition. That the current version of the proposal does so was only due to a layer of indirection, in which the "last /8" policy made a reference to the "old policy" which 2013-03 did remove as part of its overall clean-up efforts. In practical terms, the amendment will result in a "check box" or a "yes/no" question in the allocation request form, where LIRs would be required to declare this to be their intent in order to receive the allocation. This interpretation has been confirmed by the NCC. The benefits of this amendment include: * Ensures our RIR-to-LIR allocation policy remains pursuant to the "Fairness" goal described in amendment 1. * Avoids any confusion leading to an impression that 2013-03 would make the RIPE NCC start to "sell IPv4 addresses". This in turn leads to the following benefits: -- Alleviates concerns that the RIPE NCC may lose its status as a non-profit membership association with the Dutch tax authorities, -- Shields the NCC from some of the legal concerns and impacts noted in the current Impact Analysis' EU Competition Law report, -- Provides "ammunition for the NCC in their talks and interactions with critical governments, regulators, or similar entities. * Ensures the proposed policy remains as much in line with RFC 2050bis' Allocation Pool Management goal as our current policy is. * Prevents LIRs from obtaining their last /22 for other purposes than "networking"; in particular re-sale, stockpiling, or hoarding. This amendment reads as follows, and is to be inserted as a new bullet point in the proposed policy's section 5.1: «The LIR must confirm it will make assignment(s) from the allocation» Amendment 3: Clarify criteria for IXP assignment expansions =========================================================== The NCC noted in its Impact Analysis for the current version of the proposal that the precise criteria for when an IXP may request an expansion of its peering LAN assignment from "last /8 IXP assignments" was lost and thus left undefined. This was unintentional and happened due to the exact same "layer of indirection" problem described above. As 2013-03 has no ambition to change the "last /8 policy", including the parts specific to IXPs, and the proposed amendment seeks only to document and uphold the status quo. The argument in favour of this amendment is of course to ensure we continue to provide the NCC and its hostmasters with clear guidance on how our policies should be implemented. The amendment will be inserted into section 6.1, replacing the fourth bullet point, and reads as follows: «New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined» The RIPE NCC has confirmed that this text accurately describes today's practice, and that it will merely uphold the current status quo. The amendments are also attached in unified diff format. Best regards, Tore Anderson

1 0

Re: [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up)
by David Farmer 05 Aug '13

05 Aug '13

On 8/4/13 09:59 , bmanning(a)vacation.karoshi.com wrote: > Pragmatically, there is zero chance of verification of operational need > for anything larger than a /96 in IPv6 space.... So the rules for v6 > allocation actually are fairly close to the original v4 allocation policies. I disagree, /64 is easily justified by how the protocols are defined, so is a /56 and probably a /48 for a business customer. You may want to argue if the protocols should have been defined to use a whole /64 for a single Ethernet. But that is not an RIR policy question, that is an IETF protocol question. The RIR's have to work with the protocols as the IETF defines them. I'm not saying you are necessary wrong, just that this isn't the forum. > The concept of verified operational need arose in times of scarcity, when > there was -no- other option. Again I disagree, if you wanted a Class A or B you needed to justify the request, it was relatively easy by comparison for sure. And if you wanted more you had to explain what you did with the ones you had. But justification didn't just come in with conservation or scarcity, it always been there, what has changed is the standards for the justification. I'm not stuck on the current standards for justification, but eliminating both "operational need" and any concept of "fairness" to replace it is an issue for me. -- ================================================ David Farmer Email: farmer(a)umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================

2 1