Resumen

  • Un artículo de colaborador publicado el 17 de septiembre en el blog de LACNIC dice que XARF v4 requiere un mínimo de siete campos. La especificación vigente de XARF enumera ocho campos superiores obligatorios.
  • El elemento ausente del recuento breve es sender. No equivale siempre a reporter: puede ser un CERT nacional, un proveedor de infraestructura u otro intermediario que transmite la denuncia por cuenta de quien la originó.
  • La diferencia no demuestra que se haya perdido un reporte ni que LACNIC exija XARF. Sí justifica un recibo que vincule cada validación con la versión exacta del esquema, el inventario de campos, los roles, el transporte y el estado de triaje.

Una cifra pequeña puede borrar a un actor entero

Siete parece un detalle editorial. Para una persona que lee el texto completo, quizá lo sea: dos párrafos después aparece la distinción correcta y el ejemplo contiene ambos objetos. Para un equipo que convierte una lista corta en requisitos de un validador, el número puede convertirse en arquitectura.

El 17 de septiembre, el blog de LACNIC publicó “Cómo evitar que un reporte de abuso se pierda en el buzón”, firmado por Guillermo Pereyra. El texto presenta XARF v4 como un formato JSON mantenido por la comunidad, con 32 tipos de incidentes distribuidos en siete categorías. Al resumir la estructura común afirma que la versión 4 requiere un mínimo de siete campos.

La enumeración incluye versión del esquema, identificador único, fecha y hora del incidente, reportante, fuente del abuso, categoría y tipo. Sin embargo, la especificación técnica vigente de XARF v4 muestra ocho campos obligatorios de nivel superior: xarf_version, report_id, timestamp, reporter, sender, el campo identificador de la fuente, category y type.

La referencia de campos comunes confirma la misma estructura. Además, exige atributos internos para los objetos reporter y sender. Las reglas por categoría pueden añadir más campos obligatorios. Por eso “ocho campos superiores comunes” no significa que todo reporte válido contenga únicamente ocho valores.

La pieza que falta en la frase es sender. El propio artículo la explica correctamente: reporter es la organización que identificó el abuso o presentó la queja; sender es quien transmite el reporte. En muchos casos serán la misma entidad. En otros, una plataforma técnica, un servicio de protección de marca o un CERT nacional enviará el mensaje en nombre de un cliente o miembro.

La página también publica un ejemplo con los dos objetos. Y aclara que las opiniones corresponden al autor y no necesariamente a LACNIC. Estos límites importan: no hay base para afirmar que LACNIC implantó un analizador de siete campos, que una implementación de XARF falló o que un caso real quedó sin atender por este texto.

La discrepancia sí permite observar qué se pierde cuando se fusionan los roles. El receptor necesita saber quién acusa, quién operó el canal de envío, a quién pedir una corrección técnica y qué identidad debe recibir el acuse de entrega. También necesita distinguir una retransmisión del mismo reporte de dos reportantes independientes sobre un mismo incidente.

Un esquema común puede reducir el trabajo de interpretar formatos, pero no suprime las etapas posteriores. XARF clasifica source_port, evidence, evidence_source y confidence como campos comunes recomendados. Algunas categorías imponen requisitos propios. El modo estándar exige los campos obligatorios comunes y los de la categoría; el modo estricto añade los recomendados.

De ahí se siguen varias negativas útiles. Un JSON válido no prueba que la evidencia sea suficiente. Un paquete con evidencia no garantiza que sea pertinente. El envío puede rebotar, llegar al buzón equivocado, esperar sin revisión o describir hechos controvertidos. Validación sintáctica, entrega, enrutamiento interno, análisis, decisión y remedio son estados distintos.

El artículo del blog reconoce buena parte de esa separación. Señala que la evidencia es recomendada en el esquema, aunque en la práctica vuelve accionable el reporte. También conserva el texto libre como opción válida si contiene recurso afectado, marca temporal UTC, tipo de abuso, evidencia y un contacto capaz de responder. Un correo claro puede ser mejor que un JSON impecable en apariencia y pobre en sustancia.

La sección 12 del Manual de Políticas de LACNIC establece el contexto regional: debe existir un contacto de abuso administrado activamente, se admiten reportes manuales y automáticos y no puede imponerse un formulario. Esa política busca un canal alcanzable y gestionado. No obliga a usar XARF ni convierte la conformidad con un esquema en prueba del abuso.

El transporte tampoco resuelve el fondo. La nota remite a ARF y cita RFC 5965, que define un formato extensible de reportes de retroalimentación. El propio RFC deja fuera de alcance el destino, la validación del contenido y la confianza entre generador y receptor. RFC 6650 desarrolla su aplicabilidad. La envoltura organiza el intercambio; no adjudica el caso.

Una recepción auditable puede ser compacta. El recibo debería guardar nombre y versión semántica del esquema, huella del documento o archivo usado por el validador e inventario exacto de requisitos comunes y específicos de categoría. reporter y sender deben seguir siendo roles separados incluso cuando sus datos coincidan.

Después se añaden modo y resultado de validación, advertencias, cantidad y huella del conjunto de evidencias cuando exista, identificador del mensaje, punto receptor, hora de ingreso, cola asignada, estado de triaje y mecanismo de corrección. Una huella demuestra identidad de bytes; no demuestra veracidad.

Así, una corrección futura no obliga a adivinar. El operador puede encontrar qué reportes fueron validados con una regla antigua y volver a examinarlos. Sin ese vínculo, “XARF válido” es una etiqueta móvil: parece precisa, pero nadie sabe qué séptimo u octavo requisito contenía cuando produjo una decisión.

Fuentes