AFRINIC has implemented the Lame Delegation policy proposal in its entirety; specifically fulfilling the requirements of Section 10.7 of the CPM

The planned go-live date is 29th April 2021.

Definition of 'LAME'

An authoritative DNS name server is considered lame when it does not adequately respond to queries for a domain, for which it is the designated Start of Authority (SOA).

For the purpose of this policy implementation, a DNS nameserver that, if queried using a standard DNS client or library, the server does not respond with an authoritative answer for the specific domain is considered lame.

No differentiation is made here between the following behaviours of a DNS server:

• Not responding at all.
• Responding in some way, but not for the specific domain queried.
• Responding for the correct domain, but without the authority bit set.

All the above variations result in a 'lame' delegation.

What does this implementation entail?

DNS lameness tests will be run on a monthly basis on all nameservers registered as "nserver" records within "domain" objects in the AFRINIC WHOIS database.

These checks will be running from at least three different geographical locations and a single successful recorded authoritative answer from a single test location is sufficient to NOT consider a nameserver as “lame”.

Once a given ‘nserver’ record has been determined to be lame for a given domain, and reasonable attempts have been made to contact the responsible person(s), the nserver attribute must then be removed from the given domain object. A ‘remarks’ line will be added to the domain object in the database recording this.

In the event that all nameserver records are lame for a given domain, the domain object will be removed in its entirety.

The complete "lameness" checking approach is as follows:

The lameness checks will continue to run on a daily basis and where a nameserver is no longer detected as lame, the corresponding remark will be removed.

What is the impact on members whose domains have lame delegations?

The negative impact of reverse DNS Lame delegations will affect the users of the network in question as well as any third parties relying on DNS records from the affected domain.

DNS lookup for deleted domains will be answered by an NXDOMAIN response, meaning this domain is not listed in any AFRINIC DNS zone.

What can a member do to resolve Lame Delegation?

AFRINIC highly recommends that the necessary steps must be taken to correct the DNS lameness issue before deletion takes place; this could either be, by making the nameservers authoritative for the relevant zones, or by editing the list of nameservers in the "nserver" attributes of the relevant "domain" objects.

Objects with lame delegations can be updated by logging in to https://my.afrinic.net

• Go to the "Resources" tab
• Select "Reverse Delegation" in the drop-down list
• Click the expand icon adjacent to the IP prefix
• Select the edit icon

You may also do it through the WHOIS web interface on the AFRINIC website https://www.afrinic.net/whois or through e-mail, where the domain objects can be submitted to This email address is being protected from spambots. You need JavaScript enabled to view it..

The implementation is designed to minimize the possibility of false positives and we recommend to members to make use of the lameness checker https://afrinic.net/whois/lame to verify against false positives as well validating any updates made or any new reverse domain delegation registered.

Statistics regarding Lame DNS delegation statistics are available here: https://stats.afrinic.net/lamerdns/

For any inquiries, you can contact This email address is being protected from spambots. You need JavaScript enabled to view it..

Further reference:

Consolidated Policy Manual section 10.7 at https://afrinic.net/policy/manual#lame

How to resolve Lame Delegation? https://afrinic.net/support/whois/resolve-lame-delegation

DNS troubleshooting best practices are recommended in RFC 1912 at https://www.ietf.org/rfc/rfc1912.txt

AFRINIC will be participating in the virtual event OSIANE 2021 organised by the nongovernmental organisation PRATIC (Promotion, Reflection and Analysis on Information and Communication Technologies).

AFRINIC CEO Eddy Kayihura will be part of a panel in the session entitled "Towards a High-Quality Internet in Central Africa"

• More information about this event is available at https://www.internetsociety.org/events/central-africa-peering-forum/capf-2021/
• Registration for this event is open at https://isoc.zoom.us/webinar/register/WN_fVU-aGAaRx-mAfjvRMgE8g (Apr 29, 2021, 01:00 PM UTC)

AFRINIC is a proud sponsor of OSIANE 2021 which is being held alongside the Central Africa Peering Forum (CAPF).

Resource Public Key Infrastructure (RPKI) is the way to cryptographically sign records that associate a Border Gateway Protocol (BGP) route announcement with the correct originating Autonomous System Number (ASN).

But if you are just getting started learning about RPKI or simply wish to read up on it, you will soon realize there is no one single authoritative Request for Comment (RFC) on the topic. In fact, there are more than 40 RFCs about RPKI found in different categories.

Someone: Read the RFC
Me: Sure 🤷🏽‍♂️#RPKI pic.twitter.com/KoKjnAZKoY

— Aftab Siddiqui (@aftabsiddiqui) August 19, 2020

Figure 1 — There are more than 40 RFCs about RPKI.

The fact that it is not possible to find all the information about RPKI in one place makes it difficult to understand RPKI from scratch.

To give a bit more context, the Internet Engineering Task Force (IETF) is the premier Internet standards body, developing open standards through open processes. The IETF works on a broad range of networking technologies organized into IETF Areas. The IETF Security Area, with more than 20 active Working Groups, provides a focal point for security-related technical work.

RPKI is a framework that was first defined in RFC 6480 (An Infrastructure to Support Secure Internet Routing) in 2012. Different working groups under the IETF Security Area have contributed to the topic, and there are now more than 40 RPKI-related RFCs.

So, if you want to read about RPKI, the questions are many: where should you start? What RFC should you read first? What can you learn from the various RFCs? Should you read all of them?

To help you find useful information efficiently, we try to answer all these questions with a new tool: The RPKI RFCs Graph (source available in Github).

This graph shows the dynamics of all the RPKI-related RFCs and gives you a brief of each. The RFCs are represented in an interactive graph where you can see their relations to each other.

Figure 2 — The RPKI RFCs Graph

Figure 2 shows:

Three categories of RFCs: PROPOSED STANDARD (STANDARD), BEST CURRENT PRACTICE (BCP) and INFORMATIONAL.

RPKI-related RFCs are in blue, RPKI-related RFCs with briefs are in yellow, and other RFCs are in grey.

• Links follows UPDATE (green) or OBSOLETE (red) relationships between RFCs.
• 4 BCPs, 7 INFORMATIONAL, and 52 STANDARD.
• In addition to the list of RFCs in the screenshot above, we have added some RFCs following UPDATE or OBSOLETE relationships where available. For instance, RFC 8212 (not RPKI-related) updated RFC 4271. Reading RFC 4271 alone is a good start, but will only give partial information about BGP-4.
• Filtering options.

In Figure 2, we can also see that non-RPKI RFCs (RFC 8654, RFC 8212, RFC 7705, RFC 7607, RFC 7606, RFC 6793, RFC 6608, RFC 6286) updates RPKI RFC 4271. This shows that reading RFC 4271 will not be sufficient; updates are available on non-RPKI RFCs. From the same Figure, it is clear that reading RFC 1771 is of little value since it has been obsoleted by RFC 4271.

The interactive graph allows these filters:

• Tooltip: Enable/disable RFC metadata information.
• MUST read: According to our classification, there are six RPKI RFCs that MUST be read.
• SHOULD read: These RFCs are useful, but you can read them after reading those in the MUST group.
• MAY read: These are the less important ones.

Figure 3 shows RFC 6484 metadata with the ‘tooltip filtering option’ activated:

Figure 3 — RFCs Graph showing RFC 6484 metadata

The graph shows isolated RFCs (RFCs without relation to any other RFC). It is well understood that BCP and INFORMATIONAL comprise isolated RFCs. Only STANDARD RFCs presents relationships. On this version of the graph, RFCs with summaries are marked in yellow. For instance, a click on RFC 6811 will show the brief as pictured below (Figure 4).

The brief is structured with the following components:

• Title: RFC title.
• Targets: Can be relaying parties, vendor, RIR, and more.
• Terminology: New concepts and acronyms used in the RFC.
• Text of the brief.

An RFC targeting a vendor will be less important to a Regional Internet Registry, for instance. This work focuses on relaying parties, thus our classification was made from the point of view of a relaying party.

We hope you find this tool useful when navigating the many RPKI-related RFCs. If you have any comments or suggestions, please leave us a comment below.

This blog post has been republished from https://blog.apnic.net/2021/03/15/which-rpki-related-rfcs-should-you-read/ published on March 15, 2021. 

About the author

Alfred Arouna is a research engineer for Simula and MANRS’ 2020 Fellow.

Co-authored by CAIDA’s Roderick Fanou, Postdoctoral Scholar; Ricky Mok, Assistant Research Scientist; Bradley Huffaker, Technical Manager; and Kc Claffy, Founder and Director.

The underlying physical infrastructure of the Internet includes a mesh of submarine cables, generally shared by network operators who purchase capacity from the cable owners.

As of late 2020, over 400 submarine cables interconnected continents worldwide and constituted the oceanic backbone of the Internet. Although they carry more than 99% of international traffic, little academic research has occurred to isolate end-to-end performance changes induced by their launch.

It is generally assumed that the deployment of undersea cables improves performance, at least for economies around the cable. But by how much, and what happens to traffic from and towards neighbouring economies?

To study this, we looked at the South Atlantic Cable System (SACS), which was launched in mid-September, 2018. It was the first transatlantic cable traversing the southern hemisphere and provided an ideal opportunity to examine what happened to traffic between different Internet regions pre and post-launch.

Figure 1 – This image shows the Angola Cables Network, which includes the SACS cable. The cable stretches for 6,165km and has a capacity of 40Tbps and 4 fibre pairs (Source: Angola Cables)SACS connects Angola in Africa to Brazil in South America. In our paper, ‘Unintended consequences: Effects of submarine cable deployment on Internet routing‘, we shed empirical light on how it affected traffic patterns, by investigating the operational impact of SACS on Internet routing. Last year, we presented our results at the Passive and Active Measurement Conference (PAM) 2020, where it was awarded ‘best paper’.

Here, we summarize the contributions of our study, including our methodology, and some findings.

How did we measure the change in performance?

Our methodology quantifies the end-to-end communication performance changes from a new submarine cable deployment on Internet paths.

Our approach relies on existing subsea maps/databases and public measurement infrastructures.

Our method has four steps:

1. Collect candidate IP paths that could have crossed the cable
2. Identify router IP interfaces on both sides of the cable based on those candidate IP paths
3. Search for corresponding paths (between same endpoint pairs) in historical traceroute datasets
4. Annotate collected paths with the necessary information for analysis such as hostnames, ASes, IP geolocations, and round-trip time (RTTs) differences between consecutive hops

Collecting candidate IP paths

Identifying which Internet paths are passing through a newly deployed cable is quite challenging. To accurately identify IPs on both sides of the cable, we need samples of IP paths crossing it in both directions, which we can obtain by running measurements after the cable launch.

Our first step involves executing, in both directions, traceroutes between vantage points (VPs) located within two networks, denoted AS1 and AS2, that are topologically close to the respective ends of the cable.

From this, we get candidate IP paths containing IP addresses of routers traversed by packets from AS1 to AS2 or vice-versa via the cable as well as the round-trip times (RTTs) from the respective source IP addresses to each of them. We selected the networks hosting vantage points (VPs) as well as the active VPs within those networks, using existing measurement platforms (CAIDA Ark and RIPE Atlas) and publicly available sea cable databases/maps.

Identifying router interfaces at both ends of the cable

Using the speed of light constraint and the known length of the cable, we were able to deduce the minimum RTT to cross the cable. This gave us a threshold that we could use to narrow down the candidate IP paths, finding matching traceroutes containing RTT bumps greater or equal to the inferred minimum threshold.

We looked for cases where the locations of those IP interfaces, according to geolocation databases Netacuity and Maxmind, match the countries linked by the new subsea cable. Then, we inferred matching pairs of potential IPs on each side of the cable and looked for router aliases of those IPs.

Searching for corresponding paths in historical traceroute datasets

Using existing measurement platforms RIPE Atlas and CAIDA Ark, we looked for historical traceroutes containing any of the identified pairs separated by an RTT bump, greater or equal to the minimum threshold needed to cross the studied cable. We then grouped them into two sets, depending on whether they were run pre or post-cable launch.

Annotating collected paths with the necessary information for analysis

We annotated these IP paths with hostnames, ASes, locations, and RTT differences between consecutive hops.

Finally, we used three metrics to evaluate end-to-end performance and AS paths, before and after the cable launch:

• The RTTs to the common IP hops closest to the traceroute destinations determines the time that packets took to travel from a source interface to a common IP close to a given destination network, measured before and after the cable launch
• The AS-centrality of transit ASes represents the percentage of paths for which an AS played a role in transit
• The length of AS paths crossing the studied cable operator’s network post-event, which we compared to the length of the AS paths serving the corresponding source IP destination prefixes, pre-event

So what did we discover?

Comparing RTTs before and after SACS

We started our analysis by comparing RTTs before and after SACS deployment. For the same source VP and destination prefix, we built a set of common IP hops in the traces before and after SACS, and selected the IP closest to the destination as a point of comparison.

Using the RTTs from VPs toward IP hops from the traces pre and post-SACS, we plotted the box plots of Figure 2, clustering RTTs by continent and measurement platform.

Figure 2 – Box plots of minimum RTTs from Ark and Atlas VPs to the common IP hops closest to the destination IPs. The red line of every box plot represents the median of these minimum RTTs; we marked the 75th and 25th percentile as well as the interquartile range (IQR).

What was the impact of SACS on latency?

Although the median latency across the whole dataset for paths crossing SACS post-launch did not change much (median RTT drops of 2-3ms); this hides significant decreases and increases in latency across paths from/to specific regions.

Interestingly, paths from South America experienced a median latency decrease of 38%, which was quite significant compared to paths from Oceania-Australia (8% decrease), and those from Africa (3%).

At the economic level, we found predictable performance improvements (RTT decrease) for paths going from Africa to Brazil, or from South America to Angola. However, we found an asymmetrical RTT reduction; the decrease of the median RTT from Africa to Brazil (73ms) was a third of that from South America to Angola (226ms). We also noted some unpredicted and unreported performance degradations. For example, we saw packets sub-optimally routed through SACS for paths going from North America to Brazil or Africa/Europe to Angola, leading to latency increases.

Comparing Transit Structure

We provide an in-depth inspection of the transit structure pre and post-SACS, an analysis of the impact on AS path lengths, and a validation of our results in the paper.

What are the contributions and key findings of this study?

In summary, the key contributions of this study can be listed as follows:

• We introduced a reproducible method to investigate the impact of a cable deployment on macroscopic Internet topology and performance
• We applied our methodology to the case of SACS, the first trans-Atlantic cable from South America to Africa
• We discovered that the RTT decrease for IP paths going from Africa to Brazil was roughly a third of that noticed on paths from South America to Angola
• Further, we discovered surprising performance degradations to/from some regions and analyzed the root-causes of these unintended consequences

From the findings of this paper, we suggest that to avoid suboptimal routing post-activation of cables in the future, ASes could inform BGP neighbours to allow time for changes, ensure optimal iBGP configurations post-activation, and use measurement platforms to verify path optimality.

Our code and data are published to facilitate reproducibility. This codebase can be extended to other cable use-cases.

This blog post has been republished from https://blog.apnic.net/2021/02/22/unintended-consequences-of-submarine-cable-deployment-on-internet-routing published in February 22, 2021. 

About the author

Roderick Fanou 

After obtaining his PhD in Telematics Engineering from IMDEA Networks Institute and Universidad Carlos III de Madrid, Spain in 2017, Roderick Fanou, joined CAIDA (University of California, San Diego), US in March 2018, where he worked as a Postdoctoral Scholar till March 2021. During his stay, he contributed to the MANIC and PANDA projects alongside Amogh Dhamdhere (in 2018) and Kc Claffy. His research activities involved assisting with the design and development of new applications as well as the integration of existing codebases that measure interdomain congestion, topology, and performance, for enabling large-scale scientific projects.

The study presented by this post is one of the outcomes of his collaboration with the CAIDA team.  

Last November we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2021. Today, we are sharing what you told us through the survey and how we’ll be improving PeeringDB and your experience of it in 2021.

We had over 200 responses to the survey. Respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. 99% of respondents described themselves as very or somewhat satisfied with PeeringDB overall.

When we asked about specific service categories, we were told that Network Configuration Data and Search and Discovery capabilities were the most important. These service categories had lower, though still high, levels of satisfaction, with 95% and 96% of respondents describing themselves as very or somewhat satisfied with these aspects of PeeringDB.

Although we saw higher satisfaction with the User Experience and Web Interface, at 97%, this service category both had the most responses and the most divided feedback. One user described the current web interface as “clean and simple” while others said it was “showing its age.”

Documentation quality was also an area with lower specific satisfaction, at 93%. One comment homed in on a key problem, noting: "Needs a top-level overview document/intro. Or if it exists, I need to find it."

We have used your feedback to guide our product roadmap for 2021. The four key focus areas will be:

• Improving geographic search
• Developing a structured framework for user documentation
• Improving the web site’s responsiveness
• Introducing a communications framework to alert users to developments and support future tooling

Our first steps to accomplish this have been to add database support for coordinates of facilities. All new facilities will be located by their latitude and longitude, with street addresses as human-friendly search terms instead of authoritative data. This is a major project and we will share more on this work in a future blog post.

Another key change is the publication of our first HOWTO document. This document is designed to help new networks register with PeeringDB using our website. We will be publishing more documents in this series and developing a broader documentation framework to support API and web users equally.

If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub. If you find a data quality issue, please let us know at This email address is being protected from spambots. You need JavaScript enabled to view it.

About Peering DB

PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centres, and other interconnection facilities, and is the first step in making interconnection decisions.

About the Author

Leo Vegoda is developing PeeringDB’s product roadmap. He was previously responsible for organizational planning and improvement in ICANN’s Office of the COO, and Internet Number Resources in the IANA department, as well as running Registration Services at the RIPE NCC.

Summary of the AFRINIC Community Consultative webinar on the topic “Public persecution and Constructive criticism on AFRINIC mailing lists’’ that took place on Thursday 4 March 2021.

AFRINIC organised a consultative webinar on Thursday 4 March 2021 on the topic "Public persecution and Constructive criticism on AFRINIC mailing lists".

The main objectives of the webinar were to:

• Listen to concerns on the AFRINIC mailing lists
• Share some of our concerns on the virulence of exchanges on AFRINIC Mailing lists
• Discuss ways to adopt good practices on the AFRINIC mailing lists

 Arthur Cardinal, Head of Stakeholder Engagement at AFRINIC introduced the session by providing the “house rules” of the session. Mr Eddy Kayihura, the Chief Executive Officer of AFRINIC followed with a speech drawing the lines between the two concepts in the title of the session ‘’Public persecution and Constructive criticism’ highlighting that the AFRINICmailing list sometimes contains language that amounts to persecution.

Mr Kayihura traced the growth of AFRINIC since 2003 amidst the expansion of the digital space in Africa highlighting his personal experience when he first joined the AFRINIC Mailing lists explaining that the diversity of the African membership and community is our wealth and we should all strive to keep it alive and healthy.

“The AFRINIC mailing lists are an important avenue for policy building and continuous dialogue. Through our mailing list, we can engage in open, respectful discussion, on matters of importance to the African Internet community and people” said Mr Kayihura. In conclusion, he recalled to his audience that collectively it is our duty to create a conducive space for the newcomers who are joining our platform and that there is a lot to achieve with our community in our region and for our continent.

Next on the agenda was Mr Ashil Oogarah, the AFRINIC Communications Team Lead who spoke on the concern of AFRINIC on the virulence of some exchanges on the mailing list. Mr Oogarah explained the potential consequences of such actions and the need for the AFRINIC community to balance their freedom of expression with the rights of others. As a corporate citizen, and responsible RIR, AFRINIC has an obligation to ensure that content appearing on its platform is not unlawful.

Mr Kayihura then invited the community for the Questions and Answers session which was quite interactive on the following questions.

What do you think AFRINIC should or should not do that would help maintain constructive discussions on our mailing lists?

The following points were highlighted during the discussions:

• AFRINIC needs to train the community or do more in terms of outreach, publishing of documents to enforce the code of conduct.
• It is fine to comment on people's ideas respectfully without attacking the person. We need to find a way to foster an environment where ‘’the ideas get attacked and not the people’’.
• Community member verification on the mailing lists not rigorous enough.
• It is difficult to establish a set of criteria for an open community that cannot be an exclusive community.
• It was highlighted that AFRINIC encourages an open environment.
• The community was invited to comment on the new Terms of Use for mailing lists.

How should AFRINIC deal with archives posts that potentially represent a legal risk for the organisation?

The following points were highlighted during the discussions.

• An archive should be an immutable record of the mailing list. There is a legal risk when "it comes not from the archive content, but from the original post".
• Posts that were marked as unacceptable or against the code of conduct, removing the original content of the post or altering it is an attempt to revise history.
• Even though we have an aspect of record keeping and history there is an aspect of risk even though there is a section that states that each person is going to take responsibility for their comment or post on a mailing list in the new Terms of Use.
• There is some global consensus across the Internet that deleting archives is a very serious thing.
• If there is an archive or certain content on a website that is published, it could potentially have a legal risk to the organisation which publishes it.
• A question was posed on whether there was a way to put archives somewhere else and contents that contain child pornographic or terrorist information must be deleted in any consequences.
• Archives should be preserved except for certain content that can’t be preserved for legal reasons.
• Deleting archives is similar to censorship. Even in extreme cases such as terrorism or child pornography, there needs to be a court order. If AFRINIC notices that contents may be illegal it should ask the authorities to confirm if archives should be removed. There must be a way that AFRINIC can protect itself such that it is just seen as not being responsible for the posting and acting as a record keeper. The jurisdiction where the postings have been made can also be an issue.
• A proposal for putting the archive on a different domain was highlighted in addition to the importance to bring sanity to our mailing list.
• AFRINIC should go back and review its code of conduct and platform.
• The issue of civil responsibility versus criminal offence was addressed. The importance and role of free speech and civil responsibility versus the lack of action from the authorities for a criminal offence were also highlighted.
• We don't have the right to attack anyone, naming them, but the right to privacy applies to everyone, hence the need to comment responsibly was highlighted.
• There was another support for not deleting archives. However, based on points he has listened to about child porn and terrorism, his views shifted a little. If we are going to agree to delete archives, ‘’are we going to set strict rules that will be followed on what can be deleted and how it should be deleted?’’
• A personal story of an interaction with the AFRINIC mailing list was shared when someone joined the AFRINIC community years ago, it really helped him to fit in because there was nothing about deleting archives, but when these archives are edited and they are no longer the original content, a new user coming in will not have the actual representation of what is happening in AFRINIC and that affects the person standing.
• Encourage anonymous participation because it covers the legitimate rights of individual participants. Still, anonymous participation *must* not be an acceptable mean to bypass the CoC or any well defined AUP.
•  Anonymous participation rights *must* not include the right to participate in any selection process to vote in any election.  Because any rightful voter must be identified to be able to vote; so that the 'one man; one vote' principle could be applicable. 
• A mailing list archive is a special tool which *should* be preserved first hand. Therefore there are very few things/use cases for which it *should* be envisaged to *redact* part of the clearly identified *offending* content (such as a URL locating a dangerous attached file unexpectedly passed on the list; text or link to porn materials or any URL assessed as dangerous inside a spammy email, or materials unexpectedly shared on the list.
• No reference to any email should be removed to a mailing list archive, but exceptionally, if there is a really dangerous email that has unexpectedly found its way to appear on a mailing list archive; some direct appropriate actions should be taken as early as possible. Such actions could include a partial modification of the proven *offending* URL or attached file.
• We should engage in other actions to foster community participation: about ensuring a minimum of coherence between all the ToRs or Guidelines of the different committees, not including the PDWG's ones. 
• A comment about the situation where various AFRINIC staff names were mentioned on the mailing list and nothing has been done so far with respect to this. AFRINIC is not there to remove historical information, but there is a need to review the process for mailing lists.
• People are using anonymity in the wrong way on our mailing lists and AFRINIC has had anonymous postings. "If these get deleted, another one comes, then we have a deeper problem." Our system is based on argument and consensus. "Arguments need to be read in a way people agree with you. One argument may be better than 1000 sock puppets arguments In discussing policies, anonymously is not a problem. We can allow people to post anonymously but their ID should be verified by staff at AFRINIC."
• There was a proposal to moderate anonymous posters.
• There was a suggestion to improve the Code of conduct with respect to anonymous posting.
• People or organisations have been attacked on the mailing list. This is not an adequate situation with regard to the reputation of such organisations.

Closing remarks

In his closing remarks, Mr Kayihura thanked all the participants and highlighted that AFRINIC is working towards getting to a point where it is safe to communicate and welcome more people to our mailing lists. He also added that during the AFRINIC strategic meeting last year, it was assessed that the engagement level with AFRINIC members and community was one of the pillars where AFRINIC needs to improve. AFRINIC intends to have an environment that is conducive enough and helpful for everyone to freely participate and where people are safe to contribute.