<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p data-local-id="7597c7b8a273" data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true" data-pm-slice="1 3 []"></p>
<p data-local-id="bc6736061d0a" data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">Dear Jordi/PDWG</p>
<p data-local-id="bc6736061d0a" data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">We appreciate the inquiry
regarding post-delegation follow-up and the subsequent comments
shared by the working group members. Please find AFRINIC’s
response below.</p>
<p data-local-id="60f1178b1ab2" data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">The Registration Service
Agreement (RSA) and Bylaws serve as the primary legal instruments
governing the relationship between AFRINIC and its Resource
Members. For this matter in particular, Clauses 4 and 6 of the RSA
and 8.2 of the Bylaws outline the expected behaviours of members,
including the mandatory requirement to comply with established
policies. These clauses also provide the necessary legal basis for
AFRINIC to take action when a member’s conduct or resource
utilisation deviates from the policies.</p>
<p data-local-id="5cb4208be883" data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">While it is important to ensure
compliance, embedding specific post-delegation follow-up actions
within applicable individual policies may present significant
scalability and agility constraints as below:</p>
<ul class="ak-ul"
data-local-id="58c5f83b-d68b-47c0-a0de-90146e2b792b"
data-prosemirror-content-type="node"
data-prosemirror-node-name="bulletList"
data-prosemirror-node-block="true">
<li data-local-id="abebd7e1-4379-4f60-ab02-2c9bf4211f66"
data-prosemirror-content-type="node"
data-prosemirror-node-name="listItem"
data-prosemirror-node-block="true">
<p data-local-id="ef9569a7abc6"
data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">Managing unique per-policy
mechanisms for every individual policy could lead to a complex
administrative burden.</p>
</li>
<li data-local-id="56df757d-6694-4316-9066-3c6e8ab71f9e"
data-prosemirror-content-type="node"
data-prosemirror-node-name="listItem"
data-prosemirror-node-block="true">
<p data-local-id="eb980932df05"
data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">Detailed operational steps
within the Consolidated Policy Manual (CPM) can make it rigid
to meet evolving administrative or technical needs without
undergoing the full Policy Development Process (PDP).</p>
</li>
</ul>
<p data-local-id="96a7e93767cd" data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">However, if the Working Group
deems it necessary, then a recommendation would be that:</p>
<ul class="ak-ul"
data-local-id="c7d0f51d-c0d0-4e2a-885d-af46c26dde26"
data-prosemirror-content-type="node"
data-prosemirror-node-name="bulletList"
data-prosemirror-node-block="true">
<li data-local-id="7cbe8e53-9142-4b47-aaff-9e29e38a081e"
data-prosemirror-content-type="node"
data-prosemirror-node-name="listItem"
data-prosemirror-node-block="true">
<p data-local-id="03a8eb344910"
data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">A consolidated guide or
framework could be introduced to the Policy Manual with
general reference to the RSA and Bylaws. Setting the
high-level mandate for compliance reviews without prescribing
specific, operational steps is beneficial.</p>
</li>
<li data-local-id="eae15a4f-ff6a-4756-bb13-43b212a5c9fd"
data-prosemirror-content-type="node"
data-prosemirror-node-name="listItem"
data-prosemirror-node-block="true">
<p data-local-id="9235fada032d"
data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">Specific details, such as
timelines, notification stages, and reclamation steps, can be
published by AFRINIC in separate publicly accessible
operational document(s) and implementation notes for specific
policies. This ensures that the community understands the
"how" while allowing the staff the flexibility to manage the
process effectively and inline with any prevailing operational
constraints. As reference , please see Section 5 of <span
class="inlineCardView-content-wrap inlineNodeView"
data-prosemirror-content-type="node"
data-prosemirror-node-name="inlineCard"
data-prosemirror-node-inline="true"><span aria-busy="true"
class="card"><a data-inline-card=""
href="https://afrinic.net/reverse-dns" data-card-data=""
style="border-radius: var(--ds-radius-small, 4px); box-decoration-break: clone; color: var(--ds-link, #1868DB); display: inline; line-height: 22px; margin-left: var(--ds-space-negative-025, -2px); -moz-user-select: none; -ms-user-select: text; padding: var(--ds-space-025, 2px) 0px; transition: 0.1s all ease-in-out; user-select: text; -webkit-box-decoration-break: clone; -webkit-transition: 0.1s all ease-in-out; -webkit-user-select: text;"
data-local-id="c14e537645f5"
class="moz-txt-link-freetext">https://afrinic.net/reverse-dns</a></span></span>
and <span class="inlineCardView-content-wrap inlineNodeView"
data-prosemirror-content-type="node"
data-prosemirror-node-name="inlineCard"
data-prosemirror-node-inline="true"><span aria-busy="true"
class="card"><a data-inline-card=""
href="https://afrinic.net/20210428-lame-dns-delegation-policy"
data-card-data=""
style="border-radius: var(--ds-radius-small, 4px); box-decoration-break: clone; color: var(--ds-link, #1868DB); display: inline; line-height: 22px; margin-left: var(--ds-space-negative-025, -2px); -moz-user-select: none; -ms-user-select: text; padding: var(--ds-space-025, 2px) 0px; transition: 0.1s all ease-in-out; user-select: text; -webkit-box-decoration-break: clone; -webkit-transition: 0.1s all ease-in-out; -webkit-user-select: text;"
data-local-id="7adb99ca4f1c"
class="moz-txt-link-freetext">https://afrinic.net/20210428-lame-dns-delegation-policy</a></span></span>
</p>
</li>
<li data-local-id="cbf6e9b69660"
data-prosemirror-content-type="node"
data-prosemirror-node-name="listItem"
data-prosemirror-node-block="true">
<p data-local-id="47af02e85ef7"
data-prosemirror-content-type="node"
data-prosemirror-node-name="paragraph"
data-prosemirror-node-block="true">The resource policies be
drafted in clear and unambiguous text so that compliance or
lack of compliance requires no additional interpretation</p>
</li>
</ul>
<p>Kind Regards</p>
<p>Madhvi</p>
<div class="moz-cite-prefix">On 22/05/2026 14:01, jordi.palet--- via
RPD wrote:<br>
</div>
<blockquote type="cite"
cite="mid:494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es">
<pre wrap="" class="moz-quote-pre">Hi all,
This point comes back frequently in discussions in different policy proposals, and I think we need to make it clear for once.
For example, yesterday Sami requested to add some kind of text for post-allocation follow-up.
I don’t think we have specific policy (other RIRs have it) for reclaim and recover, however, my understanding is that the existing RSA already enforces the policy compliance and AFRINIC may reclaim resources to any member that, for example, requested IPv4 or IPv6 addressing space with some specific plans, and after 1 or 2 years, the plans have been sensibly altered or even not complied at all, showing bad-faith on the original request.
Is my interpretation correct and coincident with AFRINIC or we should add very specific text for any policy proposal (or a generic proposal for lack of compliance like in some other RIRs), for AFRINIC to “verify” after a given period the compliance?
I will understand that plans for an organization may change, but I think in those cases, the organization must for its own interest, have an alternative plan for the business continuity/business strategy changes and that should be re-addressed with AFRINIC, in case the allocation of resources need to be modified.
I think a very clear (and urgent) response is needed in case we need to add some text into a new version of the current proposals under discussion before the dead line for a possible v2.
Tks!
Regards,
Jordi
@jordipalet
**********************************************
IPv4 is over
Are you ready for the new Internet ?
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
AFRINIC Policy Liaison.
t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net
facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia</pre>
</body>
</html>