Registration and validation of abuse contact

Original Language Español Date Published 05/03/2018 Last Modified 26/09/2019
Last Call for Comments Period Does not apply Date Ratified Does not apply Implementation Date Does not apply
Status Under discussion Download TXT PDF XML DOCX
See other versions 1.0 2.0 3.0 4.0 5.0 6.0 (compare)

Authors

Name: Jordi Palet Martinez
Email: jordi.palet@theipv6company.com
Organization: The IPv6 Company

Proposal Data

Policy Type: LACNIC
Id: LAC-2018-5
Last version: 6
Presented at: LACNIC 32 Presentations:

Summary

This proposal allows ensuring and validating an organization's WHOIS abuse contacts (abuse-c and abuse-mailbox) and thus reporting and solving cases of abuse.

It seeks to solve the problem by ensuring the existence of a proper abuse-c contact and a process for its utilization.

Rationale

The current (ASN) policy is not clear regarding the obligation to register an abuse contact (abuse-c) or its specific format, nor as to whether this applies to other WHOIS records.

As a result, some organizations that have received resources from LACNIC may not have this contact information on record for their resources, and there are even cases of LIRs/ISPs, end users or others that use a non-existent email address or one that is not actively monitored.

Because these contacts are not validated, cases of abuse cannot be effectively reported. This creates security issues and costs for the victims.

To solve this problem, a simple, periodic verification of abuse contacts is proposed that will avoid unnecessary costs to third parties.

The proposal guarantees that the cost of processing an abuse falls on the recipient of the resource who is responsible for the abuse, either directly or indirectly (through a customer, from whom they are possibly receiving financial compensation for the service), instead of falling on the victim. Bear in mind that this will keep the problem from escalating and will save time and legal costs for both parties involved if the matter is taken to court.

In this case, the abuse-c attribute —which has so far only been referenced for the “aut-num” object— becomes mandatory in the “inetnum” objects (for both IPv4 and IPv6), as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the “abuse-mailbox” attribute.

Text

Current text:

N/A

New text:

12. Registration and validation of “abuse-c” and “abuse-mailbox”

12.1. Description of “abuse-c” and “abuse-mailbox”
All resources that use LACNIC's registration systems must include a mandatory abuse-c contact attribute (abuse contact) in their corresponding WHOIS entries, with at least one valid, monitored, and actively managed abuse-mailbox that allows sending manual or automatic reports regarding abusive behavior, security issues, and the like.

Unrestricted access to the “abuse-mailbox” attribute must be available via whois, APIs and future technologies.

Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional.

Following usual practices, other “e-mail” attributes may be included for other purposes.

12.2. About the “abuse-mailbox”

The “abuse-mailbox”:
• Must require intervention by the recipient.
• Must not require the use of a form to report abuse.
• Must guarantee that abuse reports, logs, headers, examples, etc. relating to the case of abuse are received.

12.3. Purpose of “abuse-c”/ “abuse-mailbox” validation

The procedure, to be developed by LACNIC, must meet the following objectives:

1) A simple process that guarantees its functionality and the fulfillment of its purpose.
2) It should confirm that the person performing the validation:
• understands the procedure and the LACNIC policies in force;
• regularly monitors the “abuse-mailbox”;
• takes measures in connection thereto;
• responds to the abuse report.
3) Include an “Initial” validation period of fifteen (15) days.
4) If this validation fails, “escalate”, by any possible means, to the rest of the available contacts within an additional period of fifteen (15) days.

12.4. Validation of “abuse-c”/“abuse-mailbox”
LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified.

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods.

12.5. Escalation to LACNIC

Fraudulent behavior (for example, an “abuse-mailbox” that only replies to emails from LACNIC or to emails having a specific subject or body) or failure to comply with the remaining aspects of this policy (ignoring or improper attention to cases of abuse) may be reported to LACNIC for re-validation according to 12.4.

Additional Information

Note (not to be included in the Policy Manual): Current Section “12. Appendixes” would become Section “A. Appendixes” and be located at the end of the Policy Manual. In addition, the entire Manual would be updated to reflect this change of numbering. Then, as the Manual continues to grow, renumbering would not be necessary when a new section is added. The text of this proposal would therefore be included in the Policy Manual as Section 12 or any other number deemed appropriate by the staff at the time of its implementation , once consensus has been reached.

LACNIC may modify the “initial” and “escalated” validation periods if it sees fit, provided that the community is informed of the reasons for such changes. For example, these periods might be extended during the initial implementation phase and then progressively adjusted as a higher portion of contacts is verified.

Similarly, the frequency of the periodic verification may be modified by LACNIC if it sees fit, also informing the community of the reasons for doing so. For example, the first year a single validation might be carried out to facilitate compliance with the policy, and then number of validations might be progressively increased, perhaps conducting them quarterly, to improve the quality of the contacts.

The following text is an example of a validation procedure based on typical helpdesk practices which, for example, does not require clicking on an html link sent via email to prevent phishing or other malicious actions. While this text is not part of the policy, we recommend its consideration, as it is the result of the discussions on abuse-c policies that have taken place among the global community.
(See previous version of the proposal, the form only allows a limited number of characters)

Timetable

-

References

-

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - versión 6

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------

Applicability
------------
This proposal applies to organizations receiving resources from LACNIC, who would need to register a valid abuse contact for ASNs, IPv4 and IPv6 addresses.

Modifications to the current text
--------------------------------
Current Section “12. Appendixes” becomes section “A. Appendixes,” located at the end of the Policy Manual. All references are updated as applicable.

The following sections are added:
- 12. Registration and validation of “abuse-c” and “abuse-mailbox”
- 12.1 Description of “abuse-c” and “abuse-mailbox”
- 12.2. About the “abuse-mailbox”
- 12.3. Purpose of “abuse-c”/ “abuse-mailbox” validation
- 12.4. Validation of “abuse-c”/“abuse-mailbox”
- 12.5. Escalation to LACNIC

This new version of the policy proposal:

- Summarizes and reduces the length of Section “12.2. About the “abuse-mailbox” where it describes the characteristics required for an abuse-mailbox.
- Eliminates the section titled “Failure to comply” and adds Subsection 12.4. Validation of “abuse-mailbox”, ‘Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods.’

LACNIC Staff Comments
-------------------------
(Comments are observations to help differentiate the changes presented by the proposal with respect to the current text of the Policy Manual)

1. LACNIC interprets that the proposed periods might be modified as LACNIC sees fit for their better implementation, both the initial validation and the escalation periods as well as the frequency of the periodic validations.

2. LACNIC understands that the purpose of the proposal is not to revoke resources when any type of evidence is discovered, but only in case of repeated and significant breaches of the policies. LACNIC will proceed to revoke resources only as a last resort.

It is important to keep in mind that resource revocation is a complex and permanent process that has a significant impact on the operation of an organization. Therefore, we recommend that resources be revoked only once all other measures have been exhausted and a significant period of time after detecting the failure to comply.

3. It should be noted that in order to implement this proposal LACNIC would need to invest new resources to handle those cases requiring follow-up in case of failure to comply.

4. While the Policy Manual does not specify that each IPv4 block must include an abuse contact, LACNIC's system already supports this format and IPv4 and IPv6 blocks as well as ASNs already include this attribute. The same is true in the case of sub-assignments: abuse-c is the administrative contact of the organization that receives the assignment or sub-assignment.
A LACNIC database was queried for the abuse contacts registered for each type of resource. The following results were obtained:
- Number of IPv4, IPv6, and ASN resources with null or blank abuse contacts: 0
- Number of legacy IPv4 resources with null or blank abuse contacts: 241
- Number of legacy IPv6 resources with null or blank abuse contacts: 0
- Number of legacy ASN resources with null or blank abuse contacts: 146

This means that currently, only legacy resources have a blank/null abuse contact in the database. Any resources that appear in the database with a null or blank abuse contact are legacy resources. LACNIC does not validate such contacts.

5. LACNIC understands that this does not apply to organizations holding legacy resources. While these organizations are also included in the LACNIC database, many do not have any valid contact information (e-mail address, telephone number) nor a contractual obligation to update such information given the date on which they were assigned (prior to 1997). Likewise, organizations holding legacy resources are not required to abide by LACNIC policies, which means that this policy would not apply to such organizations.

6. As for the following text: “Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional,”
LACNIC understands this to mean that, in the case of address sub-assignments, the “abuse-c” contact may be covered either by that of the parent organization or by that of its own organization. Therefore, LACNIC interprets that sub-assignments would not be verified.

7. As for item 5) of Section 12.3, LACNIC understands that the validation error would be escalated to the other contacts of the organization.

Recommendations
-------------------
8. We recommend not specifying a specific timeline, but instead defining the necessary actions and allowing the corresponding timeline to be defined based on operational considerations.

Impact of the policy on the registration system
-----------------------------------------------
This proposal would involve developing a procedure to automatically monitor abuse-c and abuse-mailbox.
It would also involve developing a system for the portals of the NIRs and LACNIC.

Official Sources
----------------

Policies in force in the other RIRs
----------------------------------
- RIPE
A policy titled Abuse Contact Management in the RIPE Database is currently in its implementation stage: https://www.ripe.net/publications/docs/ripe-705
However, this policy is more flexible: validation is performed on an annual basis and the validation procedure is simpler, as RIPE only checks that a domain exists and that an email server has been configured.

- APNIC
A policy similar to the one under discussion in the LACNIC region achieved consensus during the past APNIC event and is already in its implementation stage.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

- ARIN: According to Section 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data
ARIN currently uses the following validation procedure: an email notification is sent to each of the points of contact on an annual basis. Each point of contact has up to 60 days in which to respond with an affirmative that their contact information is correct and up to date. If the point of contact does not reply within 60 days, it is marked as invalid in the database. Until the point of contact is updated, these users have limited access to the functionality within ARIN Online.
In addition, a proposal similar to the one under discussion in the LACNIC region has been submitted and will be presented at the ARIN event to be held in April: https://www.arin.net/participate/policy/drafts/2019_5/

- AFRINIC
A proposal similar to the one submitted in the LACNIC region has been under discussion since November 2018. This proposal was presented at the latest AFRINIC event and was sent back for further discussion.
https://afrinic.net/policy/2018-gen-001-d2#proposal

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - versión 5

Interpretación de la propuesta por el staff de LACNIC
-----------------------------------------------------

Aplicación de la propuesta
--------------------------
Esta propuesta se aplicaría a los receptores de recursos de LACNIC para que registren un contacto de abuso válido para ASNs, IPv4 e IPv6.

Modificación del texto actual
-----------------------------
La sección actual “12. Apéndices” pasa ser “A. Apéndices”, al final del Manual de Políticas, y se actualizan todas sus referencias.

Se agregan las secciones:
o 12. “Registro y Validación de "abuse-c" y "abuse-mailbox”
o 12.1 “Descripción del "abuse-c" y "abuse-mailbox”
o 12.2. “Características del "abuse-mailbox"
o 12.3. Objetivos de la validación del "abuse-c"/"abuse-mailbox
o 12.4. Validación del "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado a LACNIC

La nueva versión incorpora
---------------------------
1. La sugerencia del staff para incluir todo tipo de recursos que utilicen los sistemas de LACNIC.
2. En la sub sección 12.5 Incumplimientos, que el bloqueo de MiLACNIC se realizará si no se han validado los contactos en el plazo inicial ni adicional.
3. Agrega las correspondencias con los sistemas de los otros NIRs.
4. Modifica la sub sección 12.4 de incumplimentos

Comentarios del staff
---------------------
1. Si bien el Manual de Políticas no indica que el bloque IPv4 debe contener un contacto de abuso, el sistema de LACNIC ya soporta esta modalidad y los bloques IPv4, IPv6 y ASN ya poseen este atributo. Lo mismo sucede en el caso de las sub asignaciones, el abuse-c utilizado es el punto de contacto administrativo de la organización que recibe la asignación o la sub asignación.
Se realizó una consulta a la Base de Datos de LACNIC sobre el registro de los contactos de abuso de cada tipo de recursos y se obtuvieron los siguientes resultados:
- Cantidad de recursos IPv4, IPv6, ASN con contacto de abuso null o vacío: 0
- Cantidad de recursos legados IPv4 con contactos de abuso null o vacío: 241
- Cantidad de recursos legados IPv6 con contactos de abuso null o vacío: 0
- Cantidad de recursos legados ASN con contactos de abuso null o vacío: 146

Por lo tanto, actualmente no existe ningún recurso que no sea legado con el contacto de abuso vacío/null. Todos los que aparecen el la BD con null/vacío son legados. Sin embargo, LACNIC no hace ningún tipo de validación sobre los contactos.

2. LACNIC entiende que esto no aplica para las organizaciones con recursos legados. Si bien estas organizaciones están en la misma base de datos de LACNIC, muchos no tienen un contacto válido (e-mail, teléfono) ni obligación contractual de actualizarlo debido a la antigüedad de la asignación (antes de 1997). Las organizaciones con recursos legados tampoco están obligadas a regirse por las políticas de LACNIC por lo que esta política tampoco sería aplicable a ellos.

3. Con relación al siguiente texto: “ Teniendo en cuenta la naturaleza jerárquica de los objetos, los heredados de aquellos distribuidos directamente por LACNIC (por ejemplo, sub-asignaciones), están cubiertos por los objetos de nivel superior y su propio atributo “abuse-c” es opcional.”
LACNIC entiende que esto significa que en caso de sub asignaciones de direcciones, el contacto de “abuse-c” puede estar cubierto por el de la organización de nivel superior o por el de su propia organización.

4. Se observa que para la implementación de esta propuesta LACNIC necesitará invertir nuevos recursos para atender el seguimiento de todos los casos que lo necesiten.

5. Tal como está redactada la propuesta, el bloqueo de Mi LACNIC permitiría acceso acceso a las cuestiones exclusivamente contractuales y relacionadas con pagos, así como la actualización de los contactos abuse-c/abuse-mailbox Por lo cual, inhabilitaría a nuevos servicios que surjan podría ofrecer Mi LACNIC.

Recomendaciones
-------------------
1. En la sección 12.5, cuando se indica “De mantenerse el incumplimiento, LACNIC actuará de conformidad con sus políticas y procedimientos pertinentes”:
a. no se especifica cómo deberá proceder LACNIC. LACNIC interpreta que el incumplimiento de esta política no determina la revocación de los recursos dado que se eliminó en la versión anterior. Si se pretende que el incumplimiento de esta política sea causal de revocación el autor deberá dejarlo explícito en el texto propuesto.
b. se recomienda aclarar al indicar “de mantenerse el incumplimiento (...) LACNIC entiende que se refiere a mantenerse el incumpliemiento durante el período de verificación inicial y adicional.

2. Es importante recordar que la revocación de recursos es de carácter permanente, tiene alto impacto sobre la operativa de las organizaciones y es un proceso complejo. Por este motivo recomendamos que esta instancia únicamente se aplique agotados todos los recursos y pasado un plazo significativo luego de que la irregularidad es detectada.

3. En el punto 5) de la sección 12.3, LACNIC asume que el “escalado” sería con el contacto administrativo de la organización. Se recomienda aclarar la redacción.

4. Se recomienda que la propuesta no defina plazos, sino que determine acciones y que los plazos necesarios se definan en base a razones operativas.

Impacto en el sistema de registro
---------------------------------
Esta propuesta implicará la creación de un proceso para el control automático del abuse-c y abuse-mailbox.
Además implicará un desarrollo para el sistema el portal de los NIRs y de LACNIC para el bloqueo inicial.
Fuentes oficiales de referencias

Políticas sobre el contacto de abuso en otros RIRs
.-------------------------------------------------
RIPE
Hay una propuesta en fase de implementación: https://www.ripe.net/publications/docs/ripe-705
Sin embargo, es más flexible: la frecuencia es cada un año y es más simple, RIPE revisará que exista un dominio y que haya un servidor de correo configurado únicamente.

APNIC
Una política similar a la de LACNIC llegó a consenso en el último evento de APNIC y está en fase de implementación.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

ARIN: De acuerdo a la sección 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data
Actualmente ARIN utiliza el siguiente procedimiento de validación: envía un correo una vez al año a cada contacto registrado. Cada contacto tiene un máximo de 60 días para responder que el contacto es correcto y está actualizado. De no responder luego de los 60 días, el contacto será marcado como inválido en la base de datos. Estos usuarios tendrán acceso limitado a las funcionalidades de ARIN online hasta que actualicen el contacto.
Además, hay una propuesta similar a la de LACNIC que se presentará en el evento de abril de ARIN: https://www.arin.net/participate/policy/drafts/2019_5/

AFRINIC
Hay una propuesta similar a la de LACNIC que está en discusión desde noviembre del 2018. Se presentó en el último evento y volvió a discusión.
https://afrinic.net/policy/2018-gen-001-d2#proposal

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - versión 4

LACNIC Staff's Interpretation of the Proposal
----------------------------------------------------

Applicability:
---------------------------
This proposal would apply to those receiving resources from LACNIC,
who would need to register a valid abuse contact for ASNs, IPv4 and IPv6 addresses.

Modifications to the current text:
----------------------------
Current section “12. Appendixes” would become section “A. Appendixes,” located at the end of the Policy Manual. All references would be updated as applicable.

The following sections would be added:
o 12. Registration and validation of “abuse-c” and “abuse-mailbox”
o 12.1 Description of “abuse-c” and “abuse-mailbox”
o 12.2. About the “abuse-mailbox”
o 12.3. Purpose of “abuse-c”/”abuse-mailbox” validation
o 12.4. Validation of “abuse-c” / “abuse-mailbox”
o 12.5. Escalation to LACNIC

The new version of the policy proposal incorporates the following:
---------------------------
1. The suggestion by LACNIC staff that it should still be possible to access the contract and the payment section of Mi LACNIC while Mi LACNIC is blocked, despite being in breach of the policy.

2. Several editorial improvements.

LACNIC staff comments:
----------------------
1. Although the Policy Manual does not specify that an IPv4 block must include an abuse contact, LACNIC’s system already supports this format and the IPv4, IPv6 blocks and ASNs already have this attribute. The same is true in the case of sub-assignments: the abuse-c contact currently in use is the administrative contact of the organization that received the assignment or sub-assignment.

The LACNIC database was queried for the abuse contacts registered for each type of resource. The following results were obtained:
- Number of IPv4, IPv6, ASN resources with null or blank abuse contacts: 0
- Number of legacy IPv4 resources with null or blank abuse contacts: 241
- Number of legacy IPv6 resources with null or blank abuse contacts: 0
- Number of legacy ASN resources with null or blank abuse contacts: 146

This means that currently only legacy resources have a blank/null abuse contact in the database.
2. LACNIC understands that this does not apply to organizations holding legacy resources, as there is no mention of this type of organizations.

3. As for the following text: “Considering the hierarchical nature of the objects, child objects of those directly distributed by LACNIC (for example, sub-assignments) are covered by the parent objects and their own “abuse-c” attribute is optional”
LACNIC understands this to mean that, in the case of address sub-assignments, the “abuse-c” contact may be covered either by that of the parent organization or by that of its own organization.

4. It should be noted that, in order to implement this proposal, LACNIC would need to invest new resources to handle the cases requiring follow-up.

Recommendations:
-------------------
5. Section 12.5 specifies that “If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.”

5.1 does not specify how LACNIC should proceed. LACNIC interprets that failure to comply with this policy will not cause the revocation of resources, as this was included in the prior version and has now been eliminated. If the intention of the authors is that breach of this policy be considered grounds for revocation, they should include text to this effect in the proposal.

Where section 5.2. specifies that “If the failure to comply continues (...),” LACNIC understands that this failure to comply would next be verified during the second annual validation.

6. It is important to keep in mind that resource revocation is a complex and permanent process that has a significant impact on the operation of an organization. Therefore, we recommend that resources be revoked only once all other measures have been exhausted and a significant period of time after detecting the failure to comply.

7. Section 12.1 specifies that “All resources allocated (…)”. We recommend replacing that with “All resources allocated and assigned (…)”. This will help maintain the consistency of the language used in the Policy Manual to specify that “allocated” refers to ISPs and “assigned” refers to End Users.

8. As for item 5) of Section 12.3, LACNIC understands that the validation error would be escalated to the administrative contact of the organization. We recommend clarifying the text of this item.

9. We recommend that the proposal not specify a specific timeline, but that instead it defines the necessary actions and that the corresponding timeline be defined based on operational considerations.
Impact of the policy on the registry system:
---------------------------------

This proposal would involve developing a procedure to automatically monitor abuse-c and abuse-mailbox.
It would also involve developing a system to implement initial blocking for the NIR portals and Mi LACNIC.

Official sources:
-------------------------------
Policies on abuse contacts in the other RIRs:
--------------------------------------------------
- RIPE
A policy known as “Abuse Contact Management in the RIPE Database” is currently in its implementation stage: https://www.ripe.net/publications/docs/ripe-705
However, this policy is more flexible: the validation frequency is once a year and the validation procedure is simpler, as RIPE will check that a domain exists and that an email server has been configured.

- APNIC
A policy similar to the one under discussion in the LACNIC region achieved consensus during the past APNIC event and is already in the implementation stage.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

- ARIN
According to Section 3.6 https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data:

ARIN currently uses the following validation procedure: an email notification is sent to each of the points of contact on an annual basis. Each point of contact has up to 60 days in which to respond with an affirmative that their contact information is correct and up to date. If the point of contact does not reply within 60 days, it is marked as invalid in the database. Until the point of contact is updated, these users have limited access to the functionality within ARIN Online.

In addition, a proposal like the one under discussion in the LACNIC region has been submitted and will be presented at the ARIN event to be held in April:
https://www.arin.net/participate/policy/drafts/2019_5/

- AFRINIC
A proposal similar to the one submitted in the LACNIC region has been under discussion since November 2018. This proposal was presented at the latest AFRINIC event and was sent back for further discussion.
https://afrinic.net/policy/2018-gen-001-d2#proposal

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - version 3

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------

Applicability of Section 12. Registration and validation of “abuse-c” and “abuse-mailbox”
----------------------------------------------------------------------------------------
This proposal would apply to organizations receiving resources from LACNIC, which would be required to register a valid abuse contact for ASNs as well as for IPv4 and IPv6 addresses.

Modifications to the current text
--------------------------------
According to the modifications included in policy proposal 2018-5, the Policy Manual would be modified as follows:

• Addition of the following sections:
o 12. Registration and validation of "abuse-c" and "abuse-mailbox"
o 12.1. Description of "abuse-c" and "abuse-mailbox"
o 12.2. "abuse-mailbox” characteristics
o 12.3. Purpose of validating "abuse-c"/"abuse-mailbox"
o 12.4. Validation of "abuse-c"/"abuse-mailbox"
o 12.5. Escalation to LACNIC

• Numbering would be removed from Section 12. Appendixes so that renumbering would not be required whenever a new addition is included.

LACNIC Staff Comments
------------------------

• Changes compared to the previous version of the proposal:
o The new version incorporates LACNIC staff recommendations on:
- The use of the inetnum object for both IPv4 and IPv6
- Removing appendix numbers
o It adds that the procedure to be established by LACNIC must avoid a completely automated validation process.
o It specifies that, if the abuse contact is not properly validated during the initial stage, the issue will be escalated with the recipient of the resources within a period not to exceed 15 instead of 3 days.
o It adds that LACNIC may modify the period for “initial” and “escalated” validation.
o It modifies periodic validations by LACNIC, reducing their frequency from once every three months to twice a year. It also allows LACNIC to modify the validation frequency if it sees fit.
o An alternative is proposed for the case of non-compliance:
- Initial blocking of milacnic for all the organization's resources, except to update the abuse-c/abuse-mailbox contacts.
- If the abuse contacts are duly updated, they will be re-validated to allow milacnic to be unblocked.
- If non-compliance continues, Section 7.1 Resource Recovery will be applied.

Recommendations
• Sections 12.4 and 12.4 specify that “Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant LACNIC policies/procedures, especially 7.1. Resource Recovery, yet they do not specify how LACNIC should proceed, whether policy 7.1 should be applied in all cases or not.

• It should be noted that, in order to implement this proposal, LACNIC would need to invest new resources for handling the cases requiring follow-up.

• We recommend not specifying any deadlines for this, but instead stating that the necessary actions and their corresponding terms will be defined based on operational reasons.

• We suggest that while milacnic is blocked the contract and the payment section should also be allowed.

• As for the additional information mentioned in the proposal, it specifies that a similar proposal relating to abuse contact validation reached consensus in RIPE NCC in June 2018. (https://www.ripe.net/participate/policies/proposals/2017-02).
RIPE NCC proposal 2017-2 is more flexible, as it does not specify any deadlines and the validation to be implemented by RIPE NCC is not as complex, as they will only verify that a domain exists and that an email server has been configured.

Impact of the policy on the registration system and address management
--------------------------------------------------------------------------
This proposal would involve the development of a process for automatically monitoring abuse-c and abuse-mailbox.

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2018-5 - version 2

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------
Applicability
-----------
This proposal would apply to RIRs, requiring that they provide a valid abuse contact.

Modifications to the current text
---------------------------------
According to the modifications presented in policy proposal 2018-4, the Policy Manual would be modified as specified below.

• Addition of the following sections:
o 12. Registration and validation of "abuse-c" and "abuse-mailbox"
o 12.1. Description of "abuse-c" and "abuse-mailbox"
o 12.2. "abuse-mailbox” characteristics
o 12.3. Purpose of validating "abuse-c"/"abuse-mailbox"
o 12.4. Validation of "abuse-c"/"abuse-mailbox"
o 12.5. Escalation to LACNIC

• Section 12. Appendixes would be renumbered as section 13. Appendixes.


LACNIC Staff Comments

------------------------
• Sections 12.4 and 12.5 specify that “Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant LACNIC policies/procedures, especially 7.1. Resource recovery. However, it is not clear how LACNIC should proceed – whether policy 7.1 should be applied in every case.


• It should be noted that in order to implement this proposal LACNIC would need to invest new resources to handle those cases requiring follow-up. 


• This proposal makes reference to inetnum6 objects. LACNIC's whois only references inetnum objects, both for IPv4 and IPv6.


• LACNIC recommends not numbering the Appendix, but instead including it as A. (appendix). The purpose of this recommendation is to avoid having to update appendix numbers each time a section is added to the manual, as this could potentially result in errors due to the large number of references to the appendix (section 12) that appear throughout the text of the Policy Manual.

Impact of the policy on the registration system and address management
-------------------------------------------------------------------------
This proposal would involve developing a process to automatically monitor abuse-c and abuse-mailbox.

Privacy Policy