<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear All,</p>
As indicated in the previous communication, an action plan has been
established to address and eliminate the identified non-conformant
certificates.<br>
<br>
<p>The plan is designed to ensure that no unnecessary alarms are
raised and that potential conflicts are avoided. It will be
implemented in phases, with clearly defined activities and
timelines, as outlined below.</p>
<p><b>Phase 1: Awareness & Self-Remediation (DIY) (2 months)</b></p>
<ul>
<li>Activity: Direct communication to affected members, including
a clear problem statement and a step-by-step “How-To” guide.</li>
</ul>
<ul>
<li>Support: Weekly helpdesk calls will be available to assist
members.</li>
</ul>
<ul>
<li>Goal: Enable the majority of active members to independently
correct their own ROAs</li>
</ul>
<p><b>Phase 2: Assisted Correction (2 Months)</b></p>
<ul>
<li>Activity: Targeted follow-ups with members who have not
responded or taken action.</li>
</ul>
<ul>
<li>Mechanism: i. Members can authorise AFRINIC to perform the
"Create New / Revoke Old" action for them. </li>
</ul>
<p> ii. Revoke non-conformant ROAs that
do not have matching routes in the Default Free Zone<br>
</p>
<ul>
<li>Support: Continued helpdesk availability.</li>
</ul>
<p><b>Phase 3: Final Deadline & Clean-up (2 Months )</b></p>
<ul>
<li>Activity: Issuance of final notices to members who have not
taken any corrective action.</li>
</ul>
<ul>
<li>Action: Revocation of all remaining non-conformant ROAs,
followed by the creation of new, compliant ROAs where
applicable.</li>
</ul>
<p data-start="1664" data-end="1854"><br>
</p>
<p data-start="1664" data-end="1854">The overall activity is planned
for a maximum duration of <span data-start="1722" data-end="1740">six
(6) months</span>. However, we anticipate that execution may be
completed sooner, as phases may be fast-tracked wherever possible.</p>
<p data-start="1856" data-end="1963">We plan to commence this
activity shortly, with final completion no later than 31 July.</p>
<p data-start="1965" data-end="1973">Regards,</p>
<p>James</p>
<p>We will be kickstart this activity shortly will a closing date of
31st July, latest.</p>
<p>Regards, </p>
<div class="moz-cite-prefix">On 16/12/2025 20:52, Frank Habicht
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:23bab62d-1296-4577-a654-68093d036fec@geier.ne.tz">Thank
you James.
<br>
Frank
<br>
<br>
On 12/16/2025 5:04 PM, James Chirwa wrote:
<br>
<blockquote type="cite">Dear Frank,
<br>
<br>
We take note of the points you have raised and consider them to
be valid.
<br>
<br>
A summary of the feedback is provided below:
<br>
<br>
The action plan will include communication to the affected
members, primarily to avoid causing force alarms, while also
allowing those who wish to undertake the required steps
independently to do so. This will, however, be timebound.
<br>
<br>
To achieve the objective of revoking all non-comforming
certificates, the majority of the revocation and re-keying will
eventually be carried out by staff.
<br>
<br>
We are currently working on the action plan and defining
appropriate timelines for execution, which we expect to share in
January.
<br>
<br>
Regards,
<br>
<br>
James
<br>
<br>
On 16/12/2025 09:59, Frank Habicht wrote:
<br>
<blockquote type="cite">Dear Yogesh, whole WG,
<br>
<br>
<nohat>
<br>
<br>
please see inline...
<br>
<br>
On 12/15/2025 5:45 AM, Yogesh Chadee via DBWG wrote:
<br>
<blockquote type="cite">Dear Mr Snijders,
<br>
<br>
I hope this email finds you well.
<br>
<br>
While we understand that a quick resolution is favourable
for everyone, we believe it would be wise to ensure
Certificate holders are aware of the issue first.
<br>
</blockquote>
<br>
agreed.
<br>
<br>
<blockquote type="cite">Re-issuing a Certificate of a person
who is unaware of the situation, without prior consent,
could have undesired consequences.
<br>
</blockquote>
<br>
At this place I would like to ask to be more specific. What
consequences?
<br>
<br>
I believe resource holders can end up with a certificate that
they didn't have before. that they didn't create *themselves*.
but it should reflect the intention of the resource holder
when they created the initial certificate. And it should have
the same properties.
<br>
<br>
<br>
<blockquote type="cite">If this method does not yield the
desired results, </blockquote>
<br>
Here I would like to get clarification about what time-line we
look at for finding out whether the desired results
materialised.
<br>
I believe when we rely on resource holder action, we have to
expect a "long tail" and a small percentage of ROAs will not
be deleted and re- issued, because of various reasons.
<br>
How long should software developers keep work-arounds?
<br>
Why should they keep them even now?
<br>
Exposing the incorrect data might give much more incentive for
resource holders to take action...
<br>
<br>
<blockquote type="cite">AFRINIC will then consider a quicker
resolution, having completed the necessary information
campaign.
<br>
</blockquote>
<br>
If AfriNIC relies on an information campaign....
<br>
... has it started or when will it start?
<br>
<br>
I personally still think that there is less risk, faster
resolution, more certainty if AfriNIC could re-issue the
certificates in question.
<br>
<br>
If useful, AfriNIC could probably get (informal) support from
external sources when considering the best methodology.
<br>
<br>
It will be good to inform resource holders as objects are
changed.
<br>
But this will be (i believe) much less effort than the above
mentioned "information campaign". Which will not be needed if
AfriNIC decides to *correct* the RPKI data on its own
initiative.
<br>
<br>
I understand that we got to this situation *not* because of
any fault of AfriNIC part, nor on resource holders. But
AfriNIC has the opportunity to "go the extra mile" and support
resource holders more than absolutely necessary.
<br>
<br>
Others are doing unilateral changes to improve database
consistency as well - e.g. "RIPE-NONAUTH" cleanup.
<br>
<br>
It's a way of proactively doing something "for the good of the
internet".
<br>
And to be honest, in my personal opinion, if this is not done,
it will be harder for AfriNIC to credibly claim to do all
that's needed to support RPKI adoption.
<br>
<br>
All of this just my personal opinion without any hat.
<br>
<br>
Regards,
<br>
Frank Habicht
<br>
<br>
<br>
_______________________________________________
<br>
DBWG mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:DBWG@afrinic.net">DBWG@afrinic.net</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/dbwg">https://lists.afrinic.net/mailman/listinfo/dbwg</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
James Chirwa
Head of Member Services
African Network Information Centre (AFRINIC) Limited
t: +230 403 51 00 | dir: +230 403 51 42
f: +230 466 6758
w: <a class="moz-txt-link-abbreviated" href="http://www.afrinic.net">www.afrinic.net</a> | tt: @afrinic
SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia</pre>
</body>
</html>