Registration and validation of abuse contact

Original Language Español Date Published 05/03/2018 Last Modified 25/04/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 (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: 5
Presented at: LACNIC 31 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”

Email messages sent to the “abuse-mailbox” must require manual intervention by the recipient at some time and may not be filtered, as in certain cases this might prevent the reception of abuse reports. For example, a spam report that includes the spam message itself or URLs or content typically classified as spam.

The “abuse-mailbox” may initially return an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports. This would not be viable, as it would place the cost of processing the abuses on those who submit the claims and are therefore the victims of the abuse, not on those who (directly or indirectly) cause the abuse.

It is reasonable for the person reporting the abuse to submit sufficient information in the first report (logs, a copy of the spam message or its full headers, or equivalent information as applicable for each type of abuse). Likewise, it is reasonable for the initial auto-reply email to specify that the claim will not be processed unless such information has been submitted, thus offering the sender the opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved. Usually, once a ticket number has been assigned, it is to be expected that the same number will be maintained in all communications (typically as part of the subject).

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

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

1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).
2) A fully automated process should be avoided.
3) 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.
4) An “Initial” validation period of fifteen (15) days.
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.

The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

(By way of recommendation, a detailed procedure is included in this policy proposal under “Additional Information”)

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.

The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.

12.5. Failure to comply

Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization. Strictly contractual and payment-related matters will be excepted, as will the possibility of updating the abuse-c/abuse-mailbox contacts so that they may be automatically re-validated to allow MiLACNIC to be unblocked.

Any attempt to access MiLACNIC (or the equivalent systems of the NIRs) while the system remains blocked will display a warning message including the text of this policy. Before the system allows the person to continue, this message must be “read” in full and confirmed by selecting a checkbox or other similar mechanism. As technology evolves, other equivalent mechanisms may be adopted.

If the failure to comply continues, LACNIC will act in accordance with its relevant policies and procedures.

12.6. 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 incorrectly managing 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.

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.

1) LACNIC automatically initiates the validation by sending TWO consecutive emails to the “abuse-mailbox”.
2) These emails will contain plain text only (thus hiding any URLs intended as phishing or other types of attacks).
3) At the discretion of LACNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 12.6), LACNIC may use domains other than lacnic.* and even modify the subject and body of the message in order to increase the efficiency of said validations.
4) The first email will contain the URL where the validation is to be performed (“validacion.lacnic.net”) and may contain information about the procedure, a brief summary of this policy, etc.
5) The second email will contain a unique alphanumeric validation code.
6) The recipient responsible for the “abuse-mailbox” must go to the URL and paste the code they received in the second email in the form.
7) This URL must be designed in such a way that it prevents the use of an automated process (for example, “captcha”). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that appropriate measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a checkbox that must be accepted in order to proceed.
8) The alphanumeric code will be valid for a maximum of 15 days.
9) If the code is not entered within this period, the system will mark the “abuse-c” as “temporarily invalid” and will alert LACNIC staff so that they can initiate a personalized follow-up with the resource's recipient.
10) If no reply is received confirming that the situation has been corrected, after an additional period of 15 days, the “abuse-c” will be marked as permanently “invalid”.
11) The validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the “abuse-c” will be marked as “valid”; otherwise, it will be considered in breach of the policy.
12) LACNIC will have mechanisms in place (a form, an email address and possibly others in the future) to facilitate the escalation in cases where reporting a breach of this policy is desired. This will allow re-validation (12.4) and LACNIC's intervention in applying the policies, procedures and contractual requirements in force.

Timetable

-

References

-

Public Comments by LACNIC Staff

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