<div dir="ltr">Hi Daniel,<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 28, 2018 at 5:27 PM, Daniel Yakmut <span dir="ltr"><<a href="mailto:yakmutd@googlemail.com" target="_blank">yakmutd@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The argument and discussion on this policy will continue to go back and forth, as i see a dangerous trend of members standing at very sharp and deep divides. The proponents and those opposed to the policy are not ready to shift grounds, in this regard can we answer the following:<br></blockquote><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I agree with your assessment.</span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1. Is there in any form, an agreement that the community needs a policy of this nature?<br></blockquote><div><br></div><div><br></div><div>No.  This is the crux of the issue.   Once we define/agree on the problem statement, we can move forward.</div><div><br></div><div>Regards,</div><div><br></div><div>McTim</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. If we agree that the policy is required, then what are the issues?<br>
3. If the policy is not required, then it should just be buried  and we make progress on more productive issues.<br>
<br>
However if we answer is Yes to No. 1. Then i will suggest that we do a clause by clause discussion and come to some consensus, any clause agreed upon will form part of the policy. Though tedious but that way, we can identify the "offensive" clause(s) and agree or discard it.<br>
<br>
But if we think the policy is not required, just bury it and move on.<br>
<br>
It is important we quickly turn our attention to policies that will fast track the deployment of IPV6, as we are overstretching the discussion on IPV4.<br>
<br>
Regards,<br>
Daniel <br>
<div class="HOEnZb"><div class="h5"><br>
<br>
----- Original Message -----<br>
From: "ALAIN AINA" <<a href="mailto:aalain@trstech.net">aalain@trstech.net</a>><br>
To: <a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a><br>
Sent: Saturday, April 28, 2018 12:55:36 PM<br>
Subject: Re: [rpd] IPv4 Soft Landing BIS<br>
<br>
hello,<br>
<br>
<br>
> On 28 Apr 2018, at 01:48, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br>
> <br>
> There are a number of problems with this:<br>
> <br>
> 1.    History shows that forcing people to accept IPv6 addresses in order to obtain<br>
>       more IPv4 addresses doesn’t actually help deploy IPv6, it just makes a mess of<br>
>       the registry and registry related statistics.<br>
> <br>
<br>
> 2.    Please explain how one goes about determining equivalence between an IPv4 allocation/assignment<br>
>       and an IPv6 allocation or assignment. Is a v6 /64 more like a v4 /32 or a v4 /24? Answer: it depends.<br>
>       Is a /48 more like a /24 or something larger? Answer: it depends.<br>
> <br>
>       IPv4 and IPv6 are so very different in terms of address size and allocation boundaries that there<br>
>       simply isn’t a good way to define equivalence. That’s a good thing, but it means that what you are<br>
>       proposing simply doesn’t work very well (if at all).<br>
> <br>
> Besides, can’t we just kill this proposal? How many times does the community need to reject it before the authors will recognize that it is not wanted?<br>
<br>
Oy yes “community”<br>
<br>
The proposal  got  consensus and was  recommended for ratification by BoD. There has been an appeal against co-chair decision. The Appeal committee decision to nullify the cochairs decision was baseless and has been challenged.<br>
<br>
lets discuss this in Dakar.<br>
<br>
—Alain<br>
> <br>
> Owen<br>
> <br>
> <br>
>> On Apr 27, 2018, at 16:10 , Paschal Ochang <<a href="mailto:pascosoft@gmail.com">pascosoft@gmail.com</a>> wrote:<br>
>> <br>
>> Is it possible to add a clause under 5.4.5 allocation criteria whereby any member requesting for ipv4 addresses must also request for a quota of ipv6 as well. Therefore ipv4 addresses cannot be requested without requesting for an equivalent quota of ipv6 and further request can be made when deployment of the allocated ipv6 block has been ascertained. ______________________________<wbr>_________________<br>
>> RPD mailing list<br>
>> <a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/<wbr>mailman/listinfo/rpd</a><br>
> <br>
> <br>
> ______________________________<wbr>_________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/<wbr>mailman/listinfo/rpd</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/<wbr>mailman/listinfo/rpd</a><br>
<br>
______________________________<wbr>_________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/<wbr>mailman/listinfo/rpd</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Cheers,<br><br>McTim<br>The 'name' of a resource indicates *what* we seek, an 'address' indicates *where* it is, and a 'route' tells us *how to get there*.</div>
</div></div>