Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] End of Last call

Jaco Kroon jaco at uls.co.za
Thu Oct 8 20:02:19 UTC 2020


Ok, I believe I was looking at the wrong thing here, this thread is
about a completely different policy it would seem.  My bad.  My apologies.

Regarding the issue w.r.t. Board Prerogatives, what prevents abuse
here?  As I see it directly after a PPM the board could decide to vary
some process for whatever justification is seemingly fit, and this would
stand until the next PPM.  They could for example take the policy that
(currently) states that post transfer the source may only obtain
resources again from afrinic within 12 months, and motivate that this
must be changed because it prevents xyz from obtaining resources.


Kind Regards,
Jaco

On 2020/10/08 21:07, Jaco Kroon wrote:


> 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

>

> _______________________________________________

> 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/e6a9cd78/attachment-0001.html>


More information about the RPD mailing list