AFRINIC · Vigilancia de RIR
AFPUB-2018-GEN-001-DRAFT07
Consulta aquí el historial de cada propuesta: qué cambió, por qué fue relevante, quién defendió cada postura, cómo evolucionaron las posiciones, qué se decidió y dónde persisten las lagunas en la evidencia.
Hechos con fuentes
- ID de política
- AFPUB-2018-GEN-001-DRAFT07
- RIR
- AFRINIC
- Estado oficial
- Ratified
- Estado normalizado
- Aceptada
- Presentada
- 17 may 2021
- Última actualización de fuentes
- 9 oct 2026
- Cobertura
- Parcial
¿Quiénes marcaron realmente el debate?
Evolución de la 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.
Hechos con fuentes −
AFPUB-2018-GEN-001-DRAFT01: Abuse Contact Policy Update (Draft 1) ArchivedHechos con fuentes ↗
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.
Hechos con fuentes −
AFPUB-2018-GEN-001-DRAFT02: Abuse Contact Policy Update (Draft 2) ArchivedHechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
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 InformationHechos con fuentes ↗
Hechos con fuentes +
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:Hechos con fuentes ↗
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.
Hechos con fuentes −
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 processHechos con fuentes ↗
Hechos con fuentes +
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 ensureHechos con fuentes ↗
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.
Hechos con fuentes −
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 periodHechos con fuentes ↗
Hechos con fuentes +
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 periodHechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved. 8.4 ObjectivesHechos con fuentes ↗
Hechos con fuentes +
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 ObjectivesHechos con fuentes ↗
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.
Hechos con fuentes −
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 automaticallyHechos con fuentes ↗
Hechos con fuentes +
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 automaticallyHechos con fuentes ↗
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.
Hechos con fuentes −
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)Hechos con fuentes ↗
Hechos con fuentes +
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)Hechos con fuentes ↗
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.
Hechos con fuentes −
If validation fails, escalate to other LIR contacts and set a new validation period not to exceed 15 days.Hechos con fuentes ↗
Hechos con fuentes +
If validation fails, escalate to other member contacts and set a new validation period not to exceed 15 days.Hechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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)Hechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
An equivalent proposal has been accepted in APNIC (already implemented) and is under discussion in the ARIN, LACNIC and RIPE regions.Hechos con fuentes ↗
Hechos con fuentes +
An equivalent proposal has been accepted in APNIC (already implemented) and LACNIC (under implementation) and is under discussion in the RIPE.Hechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
6.0 Finance Recruitment of additional support staff to cater for the increase in tickets that the implementation of the policy will generate.Hechos con fuentes ↗
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.
Hechos con fuentes −
AFPUB-2018-GEN-001-DRAFT01: Abuse Contact Policy Update (Draft 6) ArchivedHechos con fuentes ↗
Hechos con fuentes +
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 RatifiedHechos con fuentes ↗
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.
Hechos con fuentes −
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.Hechos con fuentes ↗
Hechos con fuentes +
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.Hechos con fuentes ↗
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.
Hechos con fuentes −
In this regard, should this policy gain consensus, AFRINIC will adopt a phased implementation while keeping the community informed.Hechos con fuentes ↗
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.
Hechos con fuentes −
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 RatifiedHechos con fuentes ↗
Hechos con fuentes +
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 ArchivedHechos con fuentes ↗
Cronología del debate
Entidades
- Mensajes de discusión0Primera actividadDesconocidaÚltima actividadDesconocidaPrimera postura explícitaDesconocidaÚltima postura explícitaDesconocidaCambios de postura0Coherencia del punto de vistaNo se expresa una postura explícitaOtras políticas7
Fuentes y cobertura
Fuentes oficiales
Archivos de debates públicos
- afrinic-rpd
- Primera captura
- 4 ago 2004
- Última captura
- 25 ago 2026
- Última actualización
- 10 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 13.116
- Vacíos conocidos
- 0
- www.afrinic.net
- afrinic-africann
- Primera captura
- 3 ago 2026
- Última captura
- 2 oct 2026
- Última actualización
- 10 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 2520
- Vacíos conocidos
- 0
- afrinic-afripv6-discuss
- Primera captura
- 17 ago 2015
- Última captura
- 18 sept 2026
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 2538
- Vacíos conocidos
- 0
- afrinic-announce
- Primera captura
- 18 ago 2015
- Última captura
- 18 sept 2026
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 2497
- Vacíos conocidos
- 0
- afrinic-community-discuss
- Primera captura
- 11 sept 2015
- Última captura
- 29 dic 2019
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 3127
- Vacíos conocidos
- 0
- afrinic-dbwg
- Primera captura
- 4 ago 2026
- Última captura
- 6 oct 2026
- Última actualización
- 10 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 871
- Vacíos conocidos
- 0
- afrinic-dnssec-ops
- Primera captura
- 18 ago 2015
- Última captura
- 1 dic 2016
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 307
- Vacíos conocidos
- 0
- afrinic-icp2-review
- Primera captura
- 10 abr 2025
- Última captura
- 10 nov 2025
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 0
- Vacíos conocidos
- 0
- afrinic-measurement-wg
- Primera captura
- 1 feb 2018
- Última captura
- 22 nov 2024
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 138
- Vacíos conocidos
- 0
- afrinic-mira
- Primera captura
- 17 nov 2020
- Última captura
- 22 nov 2024
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 0
- Vacíos conocidos
- 0
- afrinic-ois-wg
- Primera captura
- 9 sept 2021
- Última captura
- 22 nov 2024
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 0
- Vacíos conocidos
- 0
- afrinic-rpki-discuss
- Primera captura
- 15 ene 2016
- Última captura
- 23 abr 2026
- Última actualización
- 9 oct 2026
- Cobertura
- La cobertura de la fuente está incompleta.
- Cargando
- 154
- Vacíos conocidos
- 0
Cobertura
Parcial
Primera captura: 4 ago 2004
Última captura: 10 oct 2026
Actualización
Vacíos conocidos
- www.afrinic.net: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- www.afrinic.net: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-rpd: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- www.afrinic.net: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-africann: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-afripv6-discuss: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-announce: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-community-discuss: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-dbwg: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-dnssec-ops: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-measurement-wg: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
- afrinic-rpki-discuss: La cobertura de la fuente está incompleta. · Aún no se ha alcanzado el límite de la fuente.
