<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [address-policy-wg] The final /8 policy proposals, part 2</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Am quite up for capping the request size, if a newcomer comes along and wants<BR>
a big bunch of v4 addresses then they are obviously not transitioning and not the sort<BR>
of people that we want to be wasting the remaining v4 address space on.<BR>
<BR>
The only edge case I can think of here is when $company has address space from $provider<BR>
and $provider tells them to get lost and they find they have to fend for themselves.<BR>
<BR>
Do people think that this will become a problem? people ditching v4 only customers<BR>
in order to get address space back (i.e making them IPv4 homeless?)?<BR>
<BR>
Dave.<BR>
<BR>
<BR>
------------------------------------------------<BR>
David Freedman<BR>
Group Network Engineering<BR>
Claranet Limited<BR>
<A HREF="http://www.clara.net">http://www.clara.net</A><BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: address-policy-wg-admin@ripe.net on behalf of Stream Service<BR>
Sent: Sun 7/5/2009 11:52<BR>
To: 'Address Policy Working Group'<BR>
Subject: RE: [address-policy-wg] The final /8 policy proposals, part 2<BR>
<BR>
Hello,<BR>
<BR>
If you ask me; the requests should be processed like now, with 3<BR>
differences:<BR>
- IF someone/a company has IPv4 address space already they need to prove<BR>
that they use it in the right way (1 IP/VPS or 2 IP/server or 1 IP/NIC or 1<BR>
IP/SSL certificate for example sounds reasonable for me). If this is not the<BR>
case (they use more IPv4 addresses for this) the new allocation will be<BR>
refused.<BR>
- Someone/a company without IPv4 address space already should get only a /24<BR>
or a /23, after they have proven to use this correctly (see above) they<BR>
could request another range.<BR>
- The biggest range someone can get with any new request should be limited<BR>
to a /22.<BR>
<BR>
Requests should be processed at a first-come-first-serve base (where<BR>
possible) if you ask me.<BR>
<BR>
With kind regards,<BR>
<BR>
Mark Scholten<BR>
<BR>
-----Original Message-----<BR>
From: address-policy-wg-admin@ripe.net<BR>
[<A HREF="mailto:address-policy-wg-admin@ripe.net">mailto:address-policy-wg-admin@ripe.net</A>] On Behalf Of Sander Steffann<BR>
Sent: zondag 5 juli 2009 11:13<BR>
To: Address Policy Working Group<BR>
Subject: [address-policy-wg] The final /8 policy proposals, part 2<BR>
<BR>
Hello WG,<BR>
<BR>
I want to continue the discussion about the Final /8 proposals <BR>
(2008-06 and 2009-04). The responses to my last question ("Do we (this <BR>
working group) want to put IPv6 related requirements in the policy?") <BR>
were 100% negative: We don't want IPv6 related requirements in the <BR>
Final /8 policy.<BR>
<BR>
The next question is about the amount of addresses someone can get <BR>
from the Final /8. I think we have a number of options here:<BR>
a) Everyone gets one (and only one) fixed size block, as described in <BR>
2008-06<BR>
b) All requests are downscaled by a certain factor, as described in <BR>
2009-04<BR>
c) We place a limit on the amount of addresses that can be requested <BR>
per time slot (year?)<BR>
<BR>
I think it is important to think about new companies. They will very <BR>
probably require some IPv4 address space during the transition from <BR>
IPv4 to IPv6. I think the whole community will be in a lot of trouble <BR>
if we make a policy that makes it impossible for new entrants to <BR>
participate in a dual-stack world.<BR>
<BR>
Once we have discussed this basic issue I'll steer the discussion back <BR>
to the other differences between the proposals. Please keep the <BR>
discussion on this topic for now.<BR>
<BR>
Thank you,<BR>
Sander Steffann<BR>
APWG co-chair<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>