Summary

  • A 17 September contributor article on the LACNIC Blog says XARF v4 requires a minimum of seven fields. The current XARF specification lists eight mandatory top-level fields.
  • The missing item in the short enumeration is sender. XARF keeps it separate from reporter so a CERT, service provider or other intermediary can transmit a complaint without becoming the complainant.
  • The discrepancy does not show that any report was lost or that LACNIC mandates XARF. It shows why an intake receipt should bind “valid” to an exact schema version, required-field inventory, role map, transport result and triage state.

The eighth field carries a different authority

Imagine a validator built with seven slots. It accepts a schema version, report ID, incident time, reporter, source, category and type. The JSON parses. Every slot is filled. Yet the message arrived through a national CERT acting for a member, and the validator has nowhere to record the organization that actually sent it.

Nothing in that example proves an abuse allegation. It does expose a smaller and more tractable problem: a report can look structurally complete while one operational role has disappeared.

That boundary appears in “How to Keep an Abuse Report from Getting Lost in Your Mailbox,” published on the LACNIC Blog on 17 September. The contributor article describes XARF v4 as a community-maintained JSON format covering 32 incident types in seven categories. It then says version 4 requires a minimum of seven fields: schema version, unique identifier, incident timestamp, reporter, abuse source, category and type.

The current XARF v4 technical specification lists eight mandatory top-level fields: xarf_version, report_id, timestamp, reporter, sender, the source identifier field, category and type. Its common-fields reference repeats the eight and specifies required attributes inside the two organization objects.

The count difference is visible rather than inferred. It is also bounded. The blog's next paragraph correctly distinguishes reporter from sender, and its example includes both objects. The page carries the usual contributor disclaimer: the author's views do not necessarily reflect LACNIC's. There is no evidence here that LACNIC deployed a seven-field validator, that XARF rejected a particular message, or that a real complaint went unread because of this sentence.

What matters is the role omitted from the count. reporter is the organization that identified or complained about the abuse. sender is the organization transmitting the report. They may be identical. They need not be. XARF gives the examples of a reporting-infrastructure provider, a brand-protection service, an anti-abuse intermediary and a national CERT reporting for members.

Collapsing the two roles changes the questions an operator can answer. Who made the allegation? Which system authenticated and transmitted it? Which contact can correct a malformed payload? Is a duplicate the same complaint sent twice, or the same incident reported by two parties? A single generic origin field cannot preserve every answer.

The distinction is especially important because schema validity is only the first state in a longer chain. The XARF specification marks source_port, evidence, evidence_source and confidence as recommended common fields. Category-specific schemas can impose additional mandatory fields. Standard validation requires the universal and category-specific mandatory fields; strict validation also requires recommended ones.

So a permissively valid report may contain no evidence array. A report with evidence may still contain irrelevant or misleading material. A perfect payload can fail SMTP delivery, land in the wrong queue, wait without human review, or describe conduct the resource holder disputes. Syntax, delivery, routing, triage, adjudication and remediation are separate facts.

The blog itself recognizes this boundary. It says evidence is recommended in the schema but often makes a report actionable in practice. It also says plain text remains valid when it carries the affected resource, UTC time, abuse type, evidence and a responsive contact. A well-written message can therefore outperform badly structured JSON. XARF is a possible common language, not a license to ignore other reports.

LACNIC's Policy Manual section 12 provides the regional context. It requires an actively managed abuse contact, permits manual or automatic reports and does not require a reporting form. The policy concerns a reachable mailbox and operational handling. It does not mandate XARF, certify the truth of a report, or transfer case-level judgment to a schema maintainer.

Transport adds another boundary. The contributor article explains email carriage through ARF and names RFC 5965. That RFC defines the extensible feedback-report format, but explicitly leaves report destination, validation of content and trust between generators and recipients outside its scope. RFC 6650 is the later applicability statement. An envelope can carry structured content without deciding whether the content deserves action.

The practical answer is not another claim that automation will solve abuse. It is a small intake receipt. For each report, record the schema name and semantic version, the schema or documentation digest used by the validator, and the exact universal and category-specific field inventory it enforced. Preserve reporter and sender as separate roles even when their values match.

Then record validation mode, outcome and warnings; evidence count and bundle digest when evidence exists; transport message ID, receiving endpoint and receipt time; assigned queue and current triage state; and a correction path. A digest proves that two systems examined the same bytes. It does not prove those bytes are true.

Such a receipt makes the seven/eight difference repairable. If documentation is corrected or the schema changes, an operator can identify which reports were checked under which rule and revalidate only the affected set. Without it, “valid XARF” becomes a floating label whose meaning depends on whatever code or guide happened to be in front of the operator.

Sources