AFRINIC · Monitoramento de RIR
AFPUB-2018-GEN-001-DRAFT07
Comece aqui pelo registro de cada proposta: o que mudou, por que isso foi relevante, quem defendeu cada posição, como as posições evoluíram, o que foi decidido e onde ainda há lacunas nas evidências.
Fatos com fonte
- ID da política
- AFPUB-2018-GEN-001-DRAFT07
- RIR
- AFRINIC
- Status oficial
- Ratified
- Status normalizado
- Aceita
- Apresentada
- 17 de mai. de 2021
- Última atualização das fontes
- 10 de out. de 2026
- Cobertura
- Parcial
Quem realmente moldou o debate?
Evolução da política
source representation · The retained source changes from a title-only Draft 1 capture to the full Draft 1 proposal and staff assessment. The comparison establishes added source detail, not a policy amendment between two policy texts.
Fatos com fonte −
AFPUB-2018-GEN-001-DRAFT01: Abuse Contact Policy Update (Draft 1) ArchivedFatos com fonte ↗
source representation · The retained source changes from a title-only Draft 2 capture to a full proposal page containing the draft text, revision history and staff assessment. The newly available detail should be treated as source enrichment rather than an inferred policy change.
Fatos com fonte −
AFPUB-2018-GEN-001-DRAFT02: Abuse Contact Policy Update (Draft 2) ArchivedFatos com fonte ↗
Coverage of directly assigned resources · Draft 3 explicitly applies the mandatory abuse-c contact to resources allocated or assigned by AFRINIC; Draft 2's operative wording referred to allocated resources. This clarifies the text's coverage of direct assignments rather than establishing that the proposal had already been implemented.
Fatos com fonte −
All resources allocated by AFRINIC must include a mandatory "abuse-c" contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving manual or automatic reports regarding abusive behavior, security issues, and the like.Fatos com fonte ↗
Fatos com fonte +
Resources allocated/assigned by AfriNIC must include a mandatory "abuse-c" contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving manual or automatic reports regarding abusive behavior, security issues, and the like.Fatos com fonte ↗
Response to failed abuse-contact validation · Draft 2 prescribed initial account blocking, except for contact updates, and release of the block after revalidation. Draft 3 replaces that fixed sequence with further follow-up, warnings and blocking of certain services at AFRINIC's discretion under the relevant policies and procedures. The new wording does not identify which services must be blocked.
Fatos com fonte −
Lack of compliance will initially lead to the blocking of that account’s access to its resources, except for updating the abuse-c/abuse-mailbox. The account blocking will be released upon re-validation of the abuse-c/abuse-mailbox. AFRINIC will do a more exhaustive follow-up, in accordance with the relevant AFRINIC policies/procedures, especially those related to revocation of resources.Fatos com fonte ↗
Fatos com fonte +
Lack of compliance will lead to a more exhaustive follow-up, warnings and blocking of certain services, at AFRINIC discretion, in accordance with the relevant policies/procedures.Fatos com fonte ↗
Escalation mechanism in section 8.6 · Draft 3 retains escalation for fraudulent validation or inadequate abuse responses, but states the operative requirement as a method enabling revalidation. Draft 2 placed an example mailbox and possible AFRINIC intermediation or resource-revocation procedures in section 8.6 itself; Draft 3 moves implementation examples and those further actions to the additional-information procedure. This is a change in how the requirement is specified, not evidence that escalation ceased to exist.
Fatos com fonte −
an escalation method should be provided (for example, a mailbox such as " This email address is being protected from spambots. You need JavaScript enabled to view it. "), thus allowing for a re-validation (according to section 8.5 above) and even the intermediation by AFRINIC and, where appropriate, the application of the relevant policies/procedures, especially those related to revocation of resources. 3.2 Additional InformationFatos com fonte ↗
Fatos com fonte +
8.6 Escalation to AFRINIC In order to allow escalation of fraudulent behavior (for example, an "abuse-mailbox" that only replies to AFRINIC's emails, or to messages with a specific subject or content), or failure to comply with the remaining aspects of this policy (incorrect or lack of response to cases of abuse), an escalation method should be provided, thus allowing for a re-validation (according to section 8.5 above). 3.2 Additional information:Fatos com fonte ↗
Time limits in the illustrative validation procedure · The worked example in Draft 3 extends validation-code validity from two working days to 15 working days and the subsequent correction period from three business days to 15 business days. These changes belong to the example procedure; the section 8.4 objectives already specified initial and escalation periods of no more than 15 days in both drafts.
Fatos com fonte −
The alphanumeric code will only be valid for a maximum of two working days. If the code is not entered within that time, the system will mark the "abuse-c" as "temporarily invalid” and will alert AFRINIC staff so that they can initiate a personalized follow-up with the LIR. If no reply is received confirming that the situation has been corrected, after an additional period of three business days, the "abuse-c" will be permanently marked as "invalid". The validation processFatos com fonte ↗
Fatos com fonte +
The alphanumeric code will only be valid for a maximum of 15 working days. If the code is not entered within that time, the system will mark the "abuse-c" as "temporarily invalid” and will alert AFRINIC staff so that they can initiate a personalized follow-up with the resource-holder. If no reply is received confirming that the situation has been corrected, after an additional period of 15 business days, the "abuse-c" will be permanently marked as "invalid". AFRINIC must ensureFatos com fonte ↗
Automation and human validation · Draft 3 changes the validation objective from avoiding automated processing to avoiding exclusively automated processing. The distinction allows automation alongside the retained requirement for a person to understand the procedure and monitor the abuse mailbox.
Fatos com fonte −
2) Avoid automated processing. 3) Confirm that the person performing the validation understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", that measures are taken, and that the abuse report receives a response. 4) Validation periodFatos com fonte ↗
Fatos com fonte +
1. Avoid exclusively automated processing. 1. Confirm that the person performing the validation understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", that measures are taken, and that the abuse report receives a response. 1. Validation periodFatos com fonte ↗
IRT and abuse-c publication wording · Draft 3 describes the IRT publication relationship explicitly as an alias to abuse-c, where Draft 2 said the IRT would also be published as abuse-c. Both retain the aim of finding the same contact information through either name and preserving the remaining IRT information; neither passage demonstrates that the migration had occurred.
Fatos com fonte −
3.2 Additional Information After this proposal is implemented, AFRINIC will publish the IRT also as abuse-c, in order to facilitate the search in whois for the same information, regardless if looking for abuse-c or IRT. The rest of the actual information in the IRT, can be kept as per the actual guidelines (which will need to be updated by AFRINIC). This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c. Example of the validation procedure.Fatos com fonte ↗
Fatos com fonte +
3.2 Additional information: Since this proposal is implemented, AFRINIC will publish the IRT as an alias to the abuse-c, in order to facilitate the search in whois for the same information, regardless if looking for abuse-c or IRT. The rest of the actual information in the IRT, can be kept as per the actual guidelines (which will need to be updated AFRINIC). This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c. Example of the validation procedure.Fatos com fonte ↗
Ticket continuity in abuse correspondence · Draft 3 adds that a generated ticket number should be retained, typically in the subject, through successive communications. Draft 2 already described automatic reporting and optional initial ticket assignment but did not include this explicit continuity instruction in the corresponding passage.
Fatos com fonte −
This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved. 8.4 ObjectivesFatos com fonte ↗
Fatos com fonte +
This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved. Commonly, if a ticket number has been generated, it should be kept (typically as part of the subject) through successive communications. 8.4 ObjectivesFatos com fonte ↗
Warnings in the illustrative follow-up procedure · Draft 3 adds explicit multi-channel warnings to the resource holder, including other mailboxes and alert pop-ups, with the policy text and consequences of continued non-compliance. It also says that blocking access to certain services should be considered in the example procedure. Draft 2 proceeded from its short correction window to repeated validation without this warning paragraph.
Fatos com fonte −
If no reply is received confirming that the situation has been corrected, after an additional period of three business days, the "abuse-c" will be permanently marked as "invalid". The validation process will be repeated automaticallyFatos com fonte ↗
Fatos com fonte +
AFRINIC must ensure that all possible means of “warning” the resource-holder are put in place, such as periodic emails to other email boxes, alert pop-ups, etc. All those must contain the policy text and reminders about consequences in case of continued policy violation. Means of blocking access to certain services should be also considered. The validation process will be repeated automaticallyFatos com fonte ↗
Contact data model · Draft 5 clarifies that abuse-c is a mandatory attribute pointing to a person or role, with at least one monitored abuse mailbox. Draft 4 described a mandatory object and a contact in the corresponding WHOIS entry. This makes the reference structure more explicit; it does not create evidence of a completed WHOIS migration.
Fatos com fonte −
Resources allocated/assigned by AfriNIC must include a mandatory "abuse-c" contact attribute (abuse contact) in their corresponding WHOIS entry, with at least one valid, monitored and actively managed email inbox (abuse-mailbox)Fatos com fonte ↗
Fatos com fonte +
Resources allocated/assigned by AFRINIC must include a mandatory "abuse-c" contact attribute (abuse contact), pointing to a person or role, with at least one valid, monitored and actively managed email inbox (abuse-mailbox)Fatos com fonte ↗
Contacts used when validation fails · The escalation recipient changes from other LIR contacts to other member contacts, and the surrounding implementation discussion similarly refers to members. The new wording is less tied to the LIR class. Both versions keep the second validation period at no more than 15 days; the text does not establish how many members were affected in practice.
Fatos com fonte −
If validation fails, escalate to other LIR contacts and set a new validation period not to exceed 15 days.Fatos com fonte ↗
Fatos com fonte +
If validation fails, escalate to other member contacts and set a new validation period not to exceed 15 days.Fatos com fonte ↗
Express enforcement sentence · The draft-4 sentence prescribing follow-up, warnings and discretionary service blocking after non-compliance is absent from draft 5's proposed section 8.5. The validation frequency and escalation-to-AFRINIC mechanism remain. The newer rationale expressly invokes database-accuracy obligations under the RSA, so this omission must not be treated as a waiver of separate RSA enforcement or proof that sanctions were abolished.
Fatos com fonte −
Lack of compliance will lead to a more exhaustive follow-up, warnings and blocking of certain services, at AFRINIC discretion, in accordance with the relevant policies/procedures.Fatos com fonte ↗
Fatos com fonte +
This is also contradictory with RSA, that states that information in databases must be accurate. This policy ensures that this can be automatically and periodically verified by AFRINIC, without entering in the operational details of how to do it.Fatos com fonte ↗
IRT transition and operational discretion · The earlier additional information promised an IRT alias or pointer to abuse-c. The newer draft says that, if consensus is reached, mnt-IRT must be renamed to abuse-c; AFRINIC chooses whether and how long to retain an alias and the IRT data, and how to update the guidelines. This replaces a specific transitional arrangement with more operational discretion, conditional on the proposal's approval.
Fatos com fonte −
Since this proposal is implemented, AFRINIC will publish the IRT as an alias (or pointer) to the abuse-c, in order to facilitate the search in whois for the same information, regardless if looking for abuse-c or IRT.Fatos com fonte ↗
Fatos com fonte +
If this proposal reaches consensus, to comply with it, AFRINIC must rename mnt-IRT to abuse-c. It is an operational AFRINIC decision if an alias (pointer, duplicated attibute, or any other alternative) to mnt-IRT is kept and for how much time (transition period)Fatos com fonte ↗
Validation wording and escalation contacts · Draft 6 changes confirmation that the resource holder understands the policy into confirmation that the holder has read it, with separate monitoring, action and response bullets. It also changes other member contacts back to other LIR contacts. Although its history calls the revision editorial improvements, those are observable wording differences; the latter should not be silently treated as identical coverage of all member categories.
Fatos com fonte −
Confirm that the resource holder understands the procedure and the policy, that they regularly monitor the abuse-mailbox, that measures are taken, and that abuse reports receive a response.Fatos com fonte ↗
Fatos com fonte +
Confirms that the resource holder: * has read the procedure and the policy * regularly monitor the abuse-mailbox * measures are taken * abuse reports receive a response.Fatos com fonte ↗
New staff assessment and implementation constraints · The new page adds a dated staff assessment describing WHOIS, MyAFRINIC and registration-process changes, the initial compliance workload and potential staffing needs. It says the proposal's 90-day expectation cannot be met, estimates six months for systems work and twelve months for member compliance, and requests clarification about legacy resources. These are staff estimates and unresolved scope questions, not evidence of implementation or an amendment that automatically imposes those timelines.
Fatos com fonte −
The proposal is expected to be implemented in 90 days, to be confirmed by AfriNIC, a reasonable time frame to allow both the staff to develop the tool and the members to update their abuse-c contacts.Fatos com fonte ↗
Fatos com fonte +
Due to the significant amount of systems impacted and coding required to onboard the AFRINIC members into adopting the abuse-c contact, 90 days for implementation cannot be met. The AFRINIC team can implement the policy within the 6 months from the Last Call as mandated by the CPM on its systems and 12 months to get the members to comply with the policy.Fatos com fonte ↗
Historical references and date uncertainty · The references now describe LACNIC as having accepted an equivalent proposal that was under implementation, and describe discussion in RIPE. These are the source's historical comparisons, not verified present-day implementation status. Draft 5's own history dates it to 22 November 2019, while draft 6's retrospective history says 21 November; that disagreement remains visible. Draft 6's dated assessment and later typo correction are separate from its 5 August 2020 draft date.
Fatos com fonte −
An equivalent proposal has been accepted in APNIC (already implemented) and is under discussion in the ARIN, LACNIC and RIPE regions.Fatos com fonte ↗
Fatos com fonte +
An equivalent proposal has been accepted in APNIC (already implemented) and LACNIC (under implementation) and is under discussion in the RIPE.Fatos com fonte ↗
New operative slow-start provision · Draft 7 adds proposed section 8.7, expressly allowing yearly adjustment of initial and escalation periods and validation frequency in light of staffing, procedures and actual data, with reasons communicated to the community. Draft 6 discussed adjustable periods in Additional information but lacked this separate operative section. The change gives the gradual rollout an explicit policy basis; it is not proof that any particular extension was exercised.
Fatos com fonte −
As a matter of clarification, the “initial” and “escalation” validation periods may be modified by AFRINIC, if deemed appropriate, provided it informs the community of its motivation for doing so.Fatos com fonte ↗
Fatos com fonte +
8.7 Slow-start and progress follow-up The initial/escalation periods and the validation periodicity set by this policy can be amended yearly by AFRINIC, considering internal procedures, staffing needs and actual data, considering both, a slow-start and follow-up of the accuracy of the data. The reasons for the amendments shall be properly communicated to the community.Fatos com fonte ↗
Legacy resources, abuse definitions and enforcement boundaries · The new explanatory text says the proposal sets no different conditions for legacy holders, leaves non-compliance consequences to the RSA and leaves the definition of abuse and escalation beyond contact validation to participants and their local rules. It also asserts no additional GDPR impact. The earlier staff assessment expressly requested guidance on legacy applicability; the newer assessment lists no clarification requests. These statements clarify the author's intended scope and the assessment's position, but are not an independent legal determination or proof that every legacy resource was brought into compliance.
Fatos com fonte −
AFRINIC is assuming that the abuse-c will not be mandatory for inetnum and aut-num that hold legacy status. Clear guidance from the author is required on this matter.Fatos com fonte ↗
Fatos com fonte +
As in all the other policies, this one doesn’t set specific different conditions for legacy holders. This is a generic AFRINIC issue that should be tackled in a uniform way for all the policy manual. Similarly, the policy doesn’t state the consequences of lack of compliance, as this is generically stated in the RSA.Fatos com fonte ↗
Rollout timing and financial assessment · The newer additional information illustrates an initial pass lasting 12–24 months and explicitly leaves implementation timing to AFRINIC's operations, priorities and staffing. Its revised staff assessment records no financial impact and a phased rollout, replacing the earlier assessment's extra-staff requirement and six-month systems/twelve-month compliance estimates. These remain proposal explanations and staff planning statements; they do not establish actual completion dates or a measured absence of cost.
Fatos com fonte −
6.0 Finance Recruitment of additional support staff to cater for the increase in tickets that the implementation of the policy will generate.Fatos com fonte ↗
Publication and adoption context · The newer retained page identifies DRAFT07, gives 17 May 2021 and labels the proposal Ratified, whereas the earlier retained page is an archived draft-6 page with a conflicting DRAFT01 header. The comparison follows the source-specific draft sequence. The Ratified label is evidence of the later page's stated status; it does not itself date a Board decision to the submission date or prove technical implementation.
Fatos com fonte −
AFPUB-2018-GEN-001-DRAFT01: Abuse Contact Policy Update (Draft 6) ArchivedFatos com fonte ↗
Fatos com fonte +
ID AFPUB-2018-GEN-001-DRAFT07 Date Submitted 17 May 2021 Author(s) Jordi Palet Martínez Version 7 Obsoletes Abuse Contact Policy (Section 8.0 of the CPM) Status RatifiedFatos com fonte ↗
Renewal of proposal validity · Draft 8's revision history explicitly describes a version update without policy changes to extend validity for Board ratification, with reference information updated. The retained operative provisions, including the yearly-adjustable slow-start rule, remain substantively the same as draft 7; punctuation and explanatory wording differ. This is evidence of the stated purpose of the renewal, not proof that the Board ratified the proposal or that deployment occurred on 15 May 2022.
Fatos com fonte −
8.7 Slow-start and progress follow-up The initial/escalation periods and the validation periodicity set by this policy can be amended yearly by AFRINIC, considering internal procedures, staffing needs and actual data, considering both, a slow-start and follow-up of the accuracy of the data. The reasons for the amendments shall be properly communicated to the community.Fatos com fonte ↗
Fatos com fonte +
15 May 2022 Version 8: AFPUB-2018-GEN-001-DRAFT08 * Version update without changes to extend the policy proposal validity to allow the Board ratification. However, the info in the references section has been updated so as to be consistent with the actual status in other RIRs.Fatos com fonte ↗
Availability of the staff assessment · The draft-7 page carries a full staff assessment, including operational effects and phased implementation. The retained draft-8 page ends with Staff Assessment (In Progress). That changes the evidence available on this page; it does not prove that the prior assessment was repudiated or that previously described systems obligations were removed. The earlier assessment remains retained separately.
Fatos com fonte −
In this regard, should this policy gain consensus, AFRINIC will adopt a phased implementation while keeping the community informed.Fatos com fonte ↗
Conflicting migrated metadata and status labels · The newer page title says Draft 8 and its history dates that version to 15 May 2022, yet its header reuses DRAFT01 and a 5 August 2020 submission date and labels the page Archived. The older draft-7 page says Ratified. These are conflicting retained page metadata and capture contexts, not evidence that ratification was reversed. The derived sequence uses the explicit draft-8 title and history while preserving both source snapshots and their status differences.
Fatos com fonte −
ID AFPUB-2018-GEN-001-DRAFT07 Date Submitted 17 May 2021 Author(s) Jordi Palet Martínez Version 7 Obsoletes Abuse Contact Policy (Section 8.0 of the CPM) Status RatifiedFatos com fonte ↗
Fatos com fonte +
Proposal Name Abuse Contact Policy Update (Draft 8) Archived ID AFPUB-2018-GEN-001-DRAFT01 Date Submitted 2020-08-05 Author(s) Refer to Proposal Tab Status ArchivedFatos com fonte ↗
Linha do tempo do debate
Entidades
- Mensagens de discussão0Primeira atividadeDesconhecidaÚltima atividadeDesconhecidaPrimeira posição explícitaDesconhecidaÚltima posição explícitaDesconhecidaMudanças de posição0Coerência do ponto de vistaNenhuma posição explícita declaradaOutras políticas7
Fontes e cobertura
Fontes oficiais
Arquivos de discussões públicas
- afrinic-rpd
- Primeiro registro
- 4 de ago. de 2004
- Último registro
- 25 de ago. de 2026
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 13.116
- Lacunas conhecidas
- 0
- www.afrinic.net
- afrinic-africann
- Primeiro registro
- 3 de ago. de 2026
- Último registro
- 2 de out. de 2026
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 2.532
- Lacunas conhecidas
- 0
- afrinic-afripv6-discuss
- Primeiro registro
- 17 de ago. de 2015
- Último registro
- 18 de set. de 2026
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 2.538
- Lacunas conhecidas
- 0
- afrinic-announce
- Primeiro registro
- 18 de ago. de 2015
- Último registro
- 18 de set. de 2026
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 2.497
- Lacunas conhecidas
- 0
- afrinic-community-discuss
- Primeiro registro
- 11 de set. de 2015
- Último registro
- 29 de dez. de 2019
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 3.127
- Lacunas conhecidas
- 0
- afrinic-dbwg
- Primeiro registro
- 4 de ago. de 2026
- Último registro
- 6 de out. de 2026
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 883
- Lacunas conhecidas
- 0
- afrinic-dnssec-ops
- Primeiro registro
- 18 de ago. de 2015
- Último registro
- 1 de dez. de 2016
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 307
- Lacunas conhecidas
- 0
- afrinic-icp2-review
- Primeiro registro
- 10 de abr. de 2025
- Último registro
- 10 de nov. de 2025
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 0
- Lacunas conhecidas
- 0
- afrinic-measurement-wg
- Primeiro registro
- 1 de fev. de 2018
- Último registro
- 22 de nov. de 2024
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 138
- Lacunas conhecidas
- 0
- afrinic-mira
- Primeiro registro
- 17 de nov. de 2020
- Último registro
- 22 de nov. de 2024
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 0
- Lacunas conhecidas
- 0
- afrinic-ois-wg
- Primeiro registro
- 9 de set. de 2021
- Último registro
- 22 de nov. de 2024
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 0
- Lacunas conhecidas
- 0
- afrinic-rpki-discuss
- Primeiro registro
- 15 de jan. de 2016
- Último registro
- 23 de abr. de 2026
- Última atualização
- 10 de out. de 2026
- Cobertura
- A cobertura da fonte está incompleta.
- Carregando
- 154
- Lacunas conhecidas
- 0
Cobertura
Parcial
Primeiro registro: 4 de ago. de 2004
Último registro: 10 de out. de 2026
Atualização
Lacunas conhecidas
- www.afrinic.net: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- www.afrinic.net: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-rpd: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- www.afrinic.net: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-africann: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-afripv6-discuss: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-announce: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-community-discuss: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-dbwg: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-dnssec-ops: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-measurement-wg: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.
- afrinic-rpki-discuss: A cobertura da fonte está incompleta. · O limite da fonte ainda não foi alcançado.