Hello, If you ask me; the requests should be processed like now, with 3 differences: - IF someone/a company has IPv4 address space already they need to prove that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1 IP/SSL certificate for example sounds reasonable for me). If this is not the case (they use more IPv4 addresses for this) the new allocation will be refused. - Someone/a company without IPv4 address space already should get only a /24 or a /23, after they have proven to use this correctly (see above) they could request another range. - The biggest range someone can get with any new request should be limited to a /22. Requests should be processed at a first-come-first-serve base (where possible) if you ask me. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Sander Steffann Sent: zondag 5 juli 2009 11:13 To: Address Policy Working Group Subject: [address-policy-wg] The final /8 policy proposals, part 2 Hello WG, I want to continue the discussion about the Final /8 proposals (2008-06 and 2009-04). The responses to my last question ("Do we (this working group) want to put IPv6 related requirements in the policy?") were 100% negative: We don't want IPv6 related requirements in the Final /8 policy. The next question is about the amount of addresses someone can get from the Final /8. I think we have a number of options here: a) Everyone gets one (and only one) fixed size block, as described in 2008-06 b) All requests are downscaled by a certain factor, as described in 2009-04 c) We place a limit on the amount of addresses that can be requested per time slot (year?) I think it is important to think about new companies. They will very probably require some IPv4 address space during the transition from IPv4 to IPv6. I think the whole community will be in a lot of trouble if we make a policy that makes it impossible for new entrants to participate in a dual-stack world. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair