[rpd] IPv4 Soft Landing BIS

Sun Apr 29 15:54:07 UTC 2018

As the process stands that require another meeting - but I’m ok with the
idea.

The biggest issue that I see is that the biggest point of contention is
around the premise of the policy itself.

There is fundamental disagreement between those that oppose and those that
support about if address space should be rationed at all - hence the
alternative proposal that was withdrawn at community request that wanted to
revoke even the current soft landing.

Hence - i am far from convinced that resolution can be found here - and am
still of the opinion that the compromise position is the current policy -
and that’s ok - I just see a total lack of willingness to compromise on the
part of the proposers.

Andrew

On Sun, Apr 29, 2018 at 6:48 PM, Lee Howard <lee.howard at retevia.net> wrote:

> Maybe the co-chairs could use the discussion at the meeting to list the
> issues that need to be addressed. Then each of those issues could be
> addressed independently, either on the list or with changes to the proposed
> policy. After all of them have been addressed, there can be another call
> for consensus. I don't know whether that call would require another
> meeting, or be another Last Call.
>
> Lee
> On 04/29/2018 06:37 AM, Komi Elitcha wrote:
>
> Daniel,
> Please, find few comments below.
>
> 2018-04-28 21:27 GMT+00:00 Daniel Yakmut <yakmutd at googlemail.com>:
>
>>
>> The argument and discussion on this policy will continue to go back and
>> forth,
>
>
> Intentionally? The question is worth asking?
> 
>
>> 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,
>
> 
> We've gone a long way through this policy[1].
> 
>
>> in this regard can we answer the following:
>>
>> 1. Is there in any form, an agreement that the community needs a policy
>> of this nature?
>>
>
> Considering that the said policy has reached "Last call". I'd answer yes.
> 
>
>> 2. If we agree that the policy is required, then what are the issues?
>>
>
> I find a clue for this here[2]
> 
>
>> 3. If the policy is not required, then it should just be buried  and we
>> make progress on more productive issues.
>>
>
> Archives should tell about the interest or lack of interest the community
> on the SL-BIS
>
>>
>> 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,
>
>
> Co-chairs have already declared "consensus". Does it make your suggestion
> obsolete?
> 
>
>> 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.
>>
>> But if we think the policy is not required, just bury it and move on.
>>
>> 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.
>>
>
> Assuming the problem statement, here is what 2.0 says.
> {
> This policy proposal solves the problem described above by:
>
> Changing the value of the maximum allocations/assignment sizes during
> exhaustion phases 1 and 2.
> Reserving a dedicated block to facilitate IPv6 deployment.
> }
> So IPv6 deployment is covered.
> Hoping this helps.
> Thanks.
> 
>
> [1] https://lists.afrinic.net/pipermail/rpd/2017/007909.html
> [2] https://lists.afrinic.net/pipermail/rpd/2018/008217.html
>
>
>> Regards,
>> Daniel
>>
>>
>> ----- Original Message -----
>> From: "ALAIN AINA" <aalain at trstech.net>
>> To: rpd at afrinic.net
>> Sent: Saturday, April 28, 2018 12:55:36 PM
>> Subject: Re: [rpd] IPv4 Soft Landing BIS
>>
>> hello,
>>
>>
>> > On 28 Apr 2018, at 01:48, Owen DeLong <owen at delong.com> wrote:
>> >
>> > There are a number of problems with this:
>> >
>> > 1.    History shows that forcing people to accept IPv6 addresses in
>> order to obtain
>> >       more IPv4 addresses doesn’t actually help deploy IPv6, it just
>> makes a mess of
>> >       the registry and registry related statistics.
>> >
>>
>> > 2.    Please explain how one goes about determining equivalence between
>> an IPv4 allocation/assignment
>> >       and an IPv6 allocation or assignment. Is a v6 /64 more like a v4
>> /32 or a v4 /24? Answer: it depends.
>> >       Is a /48 more like a /24 or something larger? Answer: it depends.
>> >
>> >       IPv4 and IPv6 are so very different in terms of address size and
>> allocation boundaries that there
>> >       simply isn’t a good way to define equivalence. That’s a good
>> thing, but it means that what you are
>> >       proposing simply doesn’t work very well (if at all).
>> >
>> > 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?
>>
>> Oy yes “community”
>>
>> 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.
>>
>> lets discuss this in Dakar.
>>
>> —Alain
>> >
>> > Owen
>> >
>> >
>> >> On Apr 27, 2018, at 16:10 , Paschal Ochang <pascosoft at gmail.com>
>> wrote:
>> >>
>> >> 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.
>> _______________________________________________
>> >> RPD mailing list
>> >> RPD at afrinic.net
>> >> https://lists.afrinic.net/mailman/listinfo/rpd
>> >
>> >
>> > _______________________________________________
>> > RPD mailing list
>> > RPD at afrinic.net
>> > https://lists.afrinic.net/mailman/listinfo/rpd
>>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>>
>
>
>
> --
> --KE
>
>
>
>
> _______________________________________________
> RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20180429/9a93ce0f/attachment-0001.html>