Search RPD Archives
[rpd] End of Last call
Jaco Kroon
jaco at uls.co.za
Thu Oct 8 19:07:22 UTC 2020
Hi Ekaterina,
I believe we all agree that we want to get a transfer policy passed as
soon as reasonably possible. I don't think anyone is disputing the urgency.
We are disputing the process taken, as well as the content of the
specific policy (and I sincerely hope I'm looking at the right one since
there are three possible ones on the site) being ratified now.
Nothing that affects me or my employer directly, so frankly - for me
this is one of those "for the greater good" issues.
As Jordi, amongst others, has pointed out, a CHANGE to the policy in
order to try and make it reciprocal has been introduced at the very last
minute, specifically relating to legacy resources. Specifically around
5.7.4.3,
Currently worded as:
Transferred IPv4 legacy resources will no longer be regarded as legacy
resources.
Proposed wording:
Transferred legacy resources will still be regarded as legacy resources.
Ref: https://afrinic.net/policy/proposals/2019-v4-003-d3#proposal
Further more, as per https://afrinic.net/policy/proposals this policy is
still "Under Discussion".
The above means:
1. Previously, when transfer of legacy resources happened, inside of
AfriNIC, they lost legacy status, and the holders of those resources
would then be bound by the policy manual.
2. Updated wording means that this is no longer the case, and legacy
status is retained.
This is a complete inversion.
Others have stated the issues with these legacy resources and why we
should aim to reduce them, and not keep them around longer than required.
We can't prescribe to other RIRs. As such, the historic 5.7.4.3 would
not be reciprocal with the inter-RIR transfer policies of other RIRs.
We don't want to compound the problem.
As such, this only sensible solution is to allow legacy resources to
retain legacy status as per policy of recipient RIR, which if AFRINIC is
the recipient, or this is an intra-AFRINIC transfer (to which the policy
previously applied) is that it loses status. As such, 5.7.4.3 could be
better worded as "Transferred IPv4 legacy resources will no longer be
regarded as legacy resources if the recipient is an AFRINIC member" or
"... if the recipient RIR is AFRINIC". This maintains the status quo
for intra-RIR transfers, and enforces it for inbound transfers, but says
nothing for outbound.
Now we can go on to 5.7.3.1 as well, and indicate that this means that
the *source* of the resources must comply with the policies of the
recipient RIR ... which cannot possibly be the case if the source is not
AFRINIC. The source must comply with the policies of the source RIR,
and the recipient with those of the recipient RIR ... but that is NOT
what the proposed clause states.
The proposal mucks up the grammar for 5.7.3.2 without changing the
meaning in any meaningful way in the attempt to change tenses. Two
fixes, leave as per the old wording or fix the grammar. Both carries
the same intent and meaning so this could be left as current, or "for*a*
12 month period after" (this really is a nitpick and grammatical fix).
Not that my grammar is as good as it should be.
In 5.7.4.1 the need for an intra-RIR (AFRNIC to AFRINIC) to show need
for resources is dropped. This is a MAJOR policy change. Again, the
intent is clear, but it's not what's stated. As far as I can see the
extra sentence "*A transfer from another RIR to AFRINIC requires a
need-based evaluation.*" was simply added in front of the policy.
Perhaps the first sentence of the original clause just needs to be
updated, "AFRINIC must, in the case where the recipient is an AFRINIC
member, approve the recipient's need for the IPv4 number resources." As
I understand this was the intention of the change, this says nothing of
recipients in other RIRs, as the former wording did, but also doesn't
negate this for intra-AFRINIC transfers.
Most of the above really are major objections in my view and
understanding, it actually stops the policy from working, or reverses
completely what's currently in the CPM. In my opinion these are easily
fixed, so why not fix it? Or has this been done already and we simply
just don't have visibility onto that which has been passed into last
call and now ratified? As far as I'm concerned, the state on this
policy is still "Under Discussion" as that's what is stated on
https://afrinic.net/policy/proposals
I further make note that draft 2 isn't available in any form. And there
is a HUGE variance between draft 1 and draft 3 (which has been released
21 Sept 2020). And there is a discrepancy between this date on the main
proposal listing (proposals) and the one on
https://afrinic.net/policy/proposals/2019-v4-003-d3
So let's take a step back here, some are saying any objections after 2nd
of October should be ignored. So let's step two weeks back, that takes
us to 18 September. So you're telling me a policy was sent to last call
before it was even released?
This does not and cannot possibly be right.
There is no staff impact assessment available either.
I do not see how this could have gone to last call, never mind ratification.
Kind Regards,
Jaco
On 2020/10/08 19:52, Ekaterina Kalugina wrote:
> Dear all,
>
> The objections to this policy were not major objections. Therefore,
> the chairs performed the administrative function within the scope of
> the CPM.
>
> In addition, none of us are 'fans' of the proposed policy. It's just
> some of our colleges including myself see a great value and need in
> passing this policy as soon as possible.
>
> Let us not try to downplay the danger of the situation. Stability of
> the region must be preserved. Not having an inter RIR policy on time
> could be detrimental. Especially in these unprecedented times we must
> take every step.
>
> The CPM is there to ensure the best future for the region. This should
> be our main focus. And it seems to me that between all these squabbles
> and passive aggressive statements many of you lost sight of what is
> actually important here.
>
> In my view, it's important to create a safe net instead of raging over
> minor technicalities of the PDP.
>
> I think it makes more sense to advocate for preventative care rather
> than suffer the consequences of the terribly uncertain future.
> Wouldn't you agree?
>
> Best,
>
> Ekaterina
>
> On Thu, 8 Oct 2020, 19:11 Gregoire EHOUMI via RPD <rpd at afrinic.net
> <mailto:rpd at afrinic.net>> wrote:
>
> I agree with Jordi on this.
>
> This is a total mess between the policy proposal versions and the
> discussions.
>
> I can see that the co-chairs did not take into account outstanding
> objections.
>
> Therefore, I urge co-chairs to reconsider this decision.
>
> --
> Gregoire
>
> On Oct. 8, 2020 3:42 a.m., JORDI PALET MARTINEZ via RPD
> <rpd at afrinic.net <mailto:rpd at afrinic.net>> wrote:
>
> Hi Moses, all,
>
>
>
> I feel that there is a fundamental mistake here and I beg you
> to reconsider it.
>
>
>
> You've not waited for the staff confirmation about the
> reciprocity of the Inter-RIR transfers. What happens if now
> the staff comes back and confirms that we can’t decide in our
> policy what do to in other regions, so there is no reciprocity
> and so, we can’t implement this policy?
>
>
>
> Accordingly, I strongly suggest that you change your mind,
> following section 3.5 of the PDP: “A person who disagrees with
> the actions taken by the Chair(s) shall discuss the matter
> with the PDWG Chair(s) or with the PDWG”.
>
>
>
> The reasons for this are:
>
> 1. The only valid proposal version is the one that is
> published at the web site and then announced to the list.
> The authors did changes several times, that aren’t there.
> As we are discussing version 2, we should have a version
> 2.x to show those.
> 2. The staff must confirm the reciprocity of the last 2.x
> version in the list. As indicated in 3.4.3, you can extend
> the last-call to ensure that this is matched.
> 3. This and other aspects, have been indicated several times
> by myself and others during the last-call. Those are
> valid-objections that remain unresolved and if you extend
> the last-call and agree with the latest changes from the
> authors, then could make sense, otherwise, it is
> impossible that you can declare the last-call and still
> “consensus”.
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 8/10/20 1:37, "Moses Serugo" <moses.serugo at gmail.com
> <mailto:moses.serugo at gmail.com>> escribió:
>
>
>
> Hello PDWG members,
>
>
>
> Following the last online PPM held on 16^th -17^th September
> 2020. Last call was announced on 21^st September 2020 for the
> following policy proposals.
>
> · Board Prerogatives on the PDP
>
> · Resource Transfer Policy
>
> This is to further announce that the last call period for the
> above proposals has ended, based on feedback received from the
> community and the editorial changes made by authors to address
> community concerns, the consensus decision from AFRINIC32 is
> still maintained.
>
> Co-Chairs will now send a report to the Board recommending
> ratification of the two above proposals in line with CPM 3.0.
>
> Regards,
>
> Co-Chairs
>
> _______________________________________________ RPD mailing
> list RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be
> privileged or confidential. The information is intended to be
> for the exclusive use of the individual(s) named above and
> further non-explicilty authorized disclosure, copying,
> distribution or use of the contents of this information, even
> if partially, including attached files, is strictly prohibited
> and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying,
> distribution or use of the contents of this information, even
> if partially, including attached files, is strictly
> prohibited, will be considered a criminal offense, so you must
> reply to the original sender to inform about this
> communication and delete it.
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20201008/4efd76ef/attachment-0001.html>
More information about the RPD
mailing list