Registration and validation of abuse contact

Rationale—scope of mandatory abuse-c registration · The new rationale adds an explicit statement that the abuse-c attribute, previously referenced only for aut-num objects, is intended to become mandatory for inetnum, inetnum6, and any analogous future objects, and that it must contain at least an abuse-mailbox attribute; the old rationale proceeds directly to the proposed text without this statement.

Operational management of abuse-mailbox · The required mailbox changes from being valid and monitored to being valid, monitored, and actively managed, adding an express operational-management requirement.

Section 12.3—status and design of the validation procedure · The old text prescribes a ten-step validation workflow, including two consecutive plain-text emails, a specified validation URL, a separate code, anti-automation controls, temporary and permanent invalid status, and automatic repetition. The new text instead requires LACNIC to develop a procedure meeting five stated objectives; the detailed workflow is retained only as an example under Additional Information. This changes the detailed workflow from prescribed policy text to an illustrative implementation example.

Section 12.5—escalation mailbox address · The old text specifies [email protected] as the escalation mailbox. The new text makes that address illustrative by introducing it with “for example,” allowing a different mailbox to be used.

Scope of affected resource recipients · The supplied old text frames missing or ineffective abuse contacts primarily in terms of LIRs. The supplied new text broadens this framing to organizations that received LACNIC resources and expressly mentions LIRs/ISPs, end users, and other recipients.

Resource-object terminology for mandatory abuse contacts · The supplied old text identifies the relevant address objects as “inetnum” and “inetnum6.” The supplied new text instead refers to “inetnum” objects for both IPv4 and IPv6.

Policy Manual section and appendix numbering · The supplied new text adds a note specifying that the existing Section 12 appendixes would become Section A at the end of the Manual, with corresponding numbering updates, so the proposal text can become Section 12. The supplied old text proceeds directly to proposed Section 12 without this renumbering note.

Validation and escalation deadlines · The supplied old text sets a validation period of no more than two business days and, after failure, a three-business-day escalation period directed to the LIR. The supplied new text sets separate initial and escalated periods of up to fifteen days each, directs escalation to the resource recipient—including an LIR or end user—and authorizes LACNIC to modify both periods while informing the community of its reasons.

Periodic validation frequency · The supplied old text requires periodic validation at least once every three months. The supplied new text changes the minimum to twice per year and expressly allows LACNIC to modify the frequency while informing the community of its reasons.

Consequences of noncompliance · The supplied old text states generally that noncompliance will result in more exhaustive follow-up under relevant policies and procedures. The supplied new text adds an initial block on “milacnic” for all resources associated with the organization, except access needed to update and revalidate abuse contacts, followed by more exhaustive follow-up and action under applicable policies if the next automatic validation confirms continued noncompliance.

Placement and numbering of the proposed policy section · The old version placed the appendix-renumbering note before Section 12 as part of the proposed new-text presentation and stated that the proposal would become Section 12. The new version moves this note to Additional Information, expressly excludes it from the Policy Manual, and allows the policy section to use Section 12 or another number selected by staff at implementation.

Resources required to have an abuse-c contact · The requirement changes from all resources allocated by LACNIC to all resources that use LACNIC's registration systems.

Treatment of child objects · The old text said child IP-address objects may be covered by parent objects or may have their own abuse-c attribute. The new text says child objects, including sub-assignments, are covered by parent objects and that a child object's own abuse-c attribute is optional.

Submission and handling of abuse reports · The new text generalizes the reporting party from a company developing an interface for each case to any entity developing an interface for each resource recipient, broadens the acceptable initial information to information applicable to each type of abuse, and adds an expectation that an assigned ticket number be maintained throughout communications.

Automation of validation · The old validation objectives directed LACNIC to avoid automated processing. The new version states that a fully automated process should be avoided, while retaining a requirement for the validating person to understand the procedure, monitor the mailbox, take measures, and respond to reports.

Validation and escalation periods · The old policy set initial and escalated validation periods that must not exceed fifteen days. The new policy specifies an initial period of fifteen days and an additional period of fifteen days, with escalation expressly directed to the original recipient of the resources. Both versions permit LACNIC to modify the periods after informing the community, but the new text removes the example concerning future shortening of the periods.

Events and frequency triggering validation · The old text required validation when either abuse-c or abuse-mailbox was created or updated, periodically at least twice yearly, and whenever LACNIC saw fit. The new text requires periodic validation at least twice yearly and whenever abuse-c attributes are created or modified; it no longer expressly identifies abuse-mailbox-only changes or an unrestricted additional 'whenever LACNIC sees fit' trigger.

Validation-message domains and content · The old policy text authorized LACNIC to use domains other than lacnic.* and modify validation-message subjects and bodies. The new policy text removes that authorization from Section 12.4 and places comparable language in the non-policy example validation procedure under Additional Information.

Definition of noncompliance · The new version creates a separate Failure to comply section and expressly defines noncompliance as failure to validate during both the initial and additional validation periods. The old version did not provide this separate definition.

Consequences and scope of system blocking · The old text specified blocking milacnic for all resources associated with the organization, except access needed to update and revalidate abuse contacts. The new text applies blocking to MiLACNIC and equivalent NIR-system measures, adds exceptions for strictly contractual and payment matters, retains contact-update access, and requires blocked access attempts to display the policy warning for full reading and affirmative confirmation before proceeding.

Continued noncompliance and resource-recovery reference · The old version required more exhaustive follow-up and a subsequent automatic validation, then expressly referenced Policy 7.1, Resource recovery, if noncompliance continued. The new version instead states generally that LACNIC will act under its relevant policies and procedures and does not expressly require the follow-up automatic validation or name Policy 7.1.

Escalation of fraudulent or mishandled abuse contacts · The old version prescribed an escalation mailbox and contemplated LACNIC revalidation, intermediation, and application of relevant policies and procedures, expressly including Resource recovery. The new version states that fraudulent behavior or failure to manage abuse cases may be reported to LACNIC for revalidation under Section 12.4, without prescribing a mailbox or expressly providing for intermediation or Resource recovery in this section.

Non-policy example validation deadlines · In the Additional Information example, the validation-code validity changes from a maximum of two working days to a maximum of fifteen days, and the follow-up period before permanent invalidation changes from three working days to an additional fifteen days.

Non-policy escalation mechanisms · The new Additional Information example adds a requirement for LACNIC mechanisms such as a form or email address to facilitate reports of policy breaches, revalidation, and intervention under applicable policies, procedures, and contracts. The old example contained no corresponding numbered mechanism provision.

Implementation timetable · The old timetable described ninety days, subject to LACNIC confirmation, for tool development and LIR contact updates. The new timetable describes a reasonable time of ninety days, also subject to confirmation, extends the update language to recipients of LACNIC resources, and adds that LACNIC may send a reminder with notice of Board ratification.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.