<div dir="auto">If I recall well we provided you Review Proposal which you fight energetically.<div dir="auto"><br></div><div dir="auto">But it contains all these provisions. But history give us reason. </div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto"><br></div><div dir="auto">--</div><div dir="auto">Arnaud </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 25 juil. 2021 à 12:38, JORDI PALET MARTINEZ via RPD <<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Exactly.<br>
<br>
There is today an internal procedure for resource reclamation.<br>
<br>
The community can either, work with the staff (may be via an specific WG) in improving that procedure or even better, make it via a policy proposal.<br>
<br>
This way, we can be sure that the de-registration process and all the associated "issues" (whois, IRR, ROAs, AS0 ROAs, etc.) follow the patch as decided by the community, instead of leaving that in the complete decision of AFRINIC.<br>
<br>
If we believe that instead of 3 months before cleaning up in case of reclamation, should be, for example:<br>
- 3 months of warning to resolve any issues<br>
- 3 months, if no resolution, of publication of what resources will be recalled<br>
- 1 month after, removal of reverse DNS<br>
- 1 month after, removal of whois, etc.<br>
- 1 months after, publication of those resources in the AS0 ROA.<br>
<br>
But all that need to be independent of this proposal, because is affecting many other aspects of a reclamation process, it will be making no-sense to duplicate it in several places of the CPM.<br>
<br>
And there is already some work on that direction:<br>
<br>
<a href="https://www.afrinic.net/policy/proposals/2020-gen-001-d1?lang=en-GB#proposal" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/policy/proposals/2020-gen-001-d1?lang=en-GB#proposal</a><br>
<br>
We plan, actually, to send a new version *soon*, so inputs on that are welcome! Change the subject please!<br>
<br>
Regards,<br>
Jordi<br>
@jordipalet<br>
<br>
<br>
<br>
El 24/7/21 18:04, "Nishal Goburdhan" <<a href="mailto:nishal@controlfreak.co.za" target="_blank" rel="noreferrer">nishal@controlfreak.co.za</a>> escribió:<br>
<br>
On 24 Jul 2021, at 14:48, Ben Maddison via RPD wrote:<br>
<br>
> If you are asking about the process for issuing AS0 ROAs for reclaimed<br>
> resources (or previously allocated resources in general), I believe <br>
> the<br>
> only safe answer is "once consent has been given by the previous <br>
> holder".<br>
<br>
that’s *a* safe answer, but certainly not the *only* answer. and <br>
rather than point to many cases where this is not the the only safe <br>
answer, i’ll point instead to a suggestion that was made earlier : <br>
draw up a solid operating practice for when/how this can/should be <br>
applied. part of that operating policy would likely include something <br>
like: “if the claim to the address space is being contested in a <br>
court of law, then no changes should be made to IRR/ROAs..” (that of <br>
course, needs to be cleaned up, to be made mode appropriate!)<br>
<br>
and so, in a case like we are seeing unfold, a “no change” to the <br>
state of CI’s ROAs / IRR objects should be the process that’s <br>
followed, until there’s an answer from the court. frankly, i’m <br>
unsure why anyone would think different about this? if the court’s <br>
eventual ruling is in favour of afrinic, then, regardless of whether, or <br>
not CI gives their “consent”, afrinic can act to reclaim the space <br>
(and follow the relevant associated behaviour). if the court rules in <br>
favour of CI, well,..this discussion is moot ..<br>
<br>
there’s precedent for this; when we authored the lame delegation <br>
policy we wrote an operating guide for what we thought would amount to a <br>
safe implementation for afrinic to follow. ben/owen/noah, you’re <br>
savvy enough to see the value of AS0 ROAs, and to suggest text for edge <br>
cases (like this). why not offer to help afrinic author that part of <br>
the operating manual, so that we end up with the best of both worlds? <br>
(frankly, i’d see that as a good opportunity to review and comment on <br>
their regular reclamation process too, but .. i can’t speak for what <br>
afrinic might be willing to entertain)<br>
<br>
-n.<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com" rel="noreferrer noreferrer" target="_blank">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</blockquote></div>