Resumen

  • El 3 de septiembre de 2026, la IESG determinó que la revisión 12 de Safe-IOC no entraba en conflicto con trabajo de la IETF. Esa decisión no es una aprobación técnica, consenso de la IETF ni avance al Standards Track.
  • Después aparecieron las revisiones 13 y 14. Los diffs públicos reflejan varias sugerencias del ballot y el historial muestra actividad de ISE, IANA y producción RFC, pero no existe un registro público completo que atribuya la resolución de cada comentario.
  • Un recibo de versión y disposición debería unir el hash revisado, la respuesta RFC 5742, los identificadores de comentarios, las razones de ISE, los cambios exactos, los estados IANA/RPC y el futuro número y boilerplate del RFC.

La decisión pertenece a la revisión 12

El anuncio de la IESG identifica draft-grimminck-safe-ioc-sharing-12. La IESG dijo no tener problema con su publicación como RFC Informational y no encontrar conflicto con trabajo de la IETF. En un mandato separado pidió al Independent Submissions Editor revisar los comentarios del ballot y del historial de Datatracker y decidir si merecían incorporación.

Son estados distintos. La revisión de conflicto terminó para la versión 12. Las observaciones técnicas quedaron bajo el juicio de ISE. El Independent stream podía seguir. El RFC aún no existía.

La ficha vigente de Datatracker muestra ahora la revisión 14, todavía como active individual Internet-Draft del Independent Submission stream con estado previsto Informational. La identidad continúa; los bytes y la etapa cambiaron.

RFC 5742 limita deliberadamente la autoridad

El RFC 5742 define cinco posibles respuestas de conflicto. Aquí se aplicó la primera y más estrecha: no hay conflicto con trabajo de la IETF. También explica que los documentos de streams no IETF normalmente no reciben consenso IETF ni aprobación de la IESG. Tras la ausencia de conflicto, el RFC Editor sigue evaluando mérito técnico y posible daño a Internet.

Así se evita que la IESG convierta una verificación de perímetro en revisión técnica total y que ISE use la ausencia de conflicto para eludir su propio juicio. “No problem with publication” solo elimina ese motivo de bloqueo; no recomienda la especificación en nombre de la IETF.

La pregunta del ballot era si la respuesta de conflict review propuesta era correcta. Al cierre observado constaban dos Yes y ocho No Objection. No eran diez votos técnicos sobre cada regla, vector o afirmación de seguridad.

Del comentario al cambio, sin recibo formal

Mohamed Boucadair apoyó la respuesta de conflicto y añadió cuatro sugerencias: citar RFC 9424 como contexto de los IoC; no usar “safe” de forma que parezca eliminar el riesgo; distinguir prefijos de direcciones; e incluir formas IPv4 embebidas en IPv6 de RFC 6052. Éric Vyncke hizo un comentario breve sobre la abundancia de contenido IPv6.

La revisión 13 apareció después del anuncio. El historial y el diff 12–14 revelan correspondencias fuertes: “a safe obfuscation format” pasa a “an obfuscation format”; se añade RFC 9424; el lenguaje CIDR habla de prefijos; aparecen RFC 6052 y dos casos de prueba; Boucadair figura en agradecimientos.

Es correcto decir que el texto posterior refleja las sugerencias. No es correcto declarar probada una disposición formal. El diff no explica si ISE aceptó cada punto literalmente, lo combinó con otra revisión o hizo el mismo cambio por una razón diferente.

La revisión 14 incorpora además “defanging”, ajusta la gramática de hosts y referencias a RFC 1035, convierte dos SHOULD normativos en recomendaciones ordinarias e introduce el riesgo de ambigüedad cuando Path, Query o Fragment ya contiene tokens entre corchetes. Ninguna tabla pública enlaza todos esos cambios con un ID estable y una decisión de aceptar, rechazar o aceptar parcialmente.

Producción no equivale a publicación

El 9 de septiembre se cargó la revisión 14 y ISE la remitió al RFC Editor. IANA pasó a In Progress y luego a No IANA Actions el 16 de septiembre. Producción quedó brevemente blocked por Author Input Required y volvió a In Progress. El historial RPC pasó después de esperar reference checking y formatting a esperar asignación de editor.

El XML oficial de la cola todavía enumera la revisión 14 en el stream ISE, recibida el 9 de septiembre, con asignación ref_checker. Datatracker y la cola proyectan tareas diferentes; ninguno autoriza resumir todo como “aprobado”. No había número RFC final al corte.

El proceso de Independent Submissions distingue revisiones iterativas, decisión inicial de publicación, entrega al RPC, AUTH48 y publicación. ISE puede decidir no publicar hasta que el RFC sea liberado. Estar en cola prueba custodia y trabajo, no un texto final público.

Qué debe contener el recibo

La primera fila uniría el hash exacto y la fecha de revisión 12 con la respuesta RFC 5742. Cada comentario llevaría ID estable, autor, hash del texto y superficie de origen. ISE declararía accepted, rejected o partially accepted con razón. Un punto aceptado apuntaría a la primera versión que lo implementa y al hunk exacto.

La misma cadena registraría el resultado IANA, causas y condiciones de salida de bloqueos RPC, responsable, número RFC final, boilerplate de stream y futuros errata o reemplazos. Un comentario consultivo seguiría siendo consultivo; un cambio surgido en otra revisión no se atribuiría retroactivamente al ballot.

La separación también contiene las promesas de seguridad. Una convención textual reversible puede reducir activación accidental, pero no valida si un indicador es malicioso, vigente o correctamente atribuido. La procedencia del documento y la del indicador son registros distintos.

Fuentes