Resumen

  • Verified significa que la corrección fue revisada y considerada exacta. Aun así, el RFC Editor no incorpora el cambio a las ediciones TXT, PDF o XML ordinarias.
  • El proceso sirve para errores presentes al publicarse el RFC. Una idea nueva, un cambio de intención o una alteración importante necesita volver al proceso técnico y, normalmente, producir otro RFC.

La corrección vive junto al archivo

Un equipo encuentra una contradicción en un RFC y consulta su página de errata. Allí aparecen el pasaje original, una redacción corregida, una fecha y el estado Verified. Seguir la corrección puede ser la decisión de ingeniería adecuada. Presentarla como si siempre hubiera formado parte del documento es una afirmación histórica falsa.

El RFC registra una aprobación colectiva en un momento concreto. El erratum registra un juicio posterior y acotado sobre un error. El primero explica de dónde nació la norma; el segundo advierte que su lectura literal puede causar una implementación equivocada. La trazabilidad depende de conservar ambos.

El sitio del RFC Editor enlaza las dos capas. La corrección no desaparece en una nota privada, pero tampoco se introduce sin marca en las publicaciones habituales. Este diseño obliga al lector a ver la unión entre decisión y reparación.

La fricción tiene valor institucional. Impide que la custodia editorial se transforme, por comodidad, en autoridad para cambiar el contenido consensuado.

Reported, Verified, Rejected y Held no dicen lo mismo

Reported solo confirma que alguien presentó una afirmación. Todavía puede ser correcta, errónea, ambigua o demasiado amplia. Automatizarla como regla operativa convierte una petición sin resolver en una obligación.

Verified confirma que el informe es válido según los criterios y debe estar disponible para quienes implementan o despliegan el RFC. Es la clasificación más fuerte, aunque sigue limitada a corregir el error conforme a la intención original.

Rejected indica que la petición no vale en ese canal. Puede ser falsa o intentar un cambio que debe discutirse y aprobarse mediante un RFC que actualice o sustituya al anterior.

Held for Document Update conserva un asunto que no exige corregir el documento vigente. Una revisión futura puede considerarlo. No es una aprobación aplazada con efectos inmediatos ni una autorización para modificar pruebas de conformidad.

Las cuatro categorías forman un registro de decisiones. Reducirlas a una casilla “última corrección” elimina la diferencia entre alegación, validación, rechazo y memoria para una futura revisión.

La competencia depende del flujo de publicación

La serie RFC contiene varios flujos: IETF, IAB, IRTF, Independent Submission y Editorial. Cada uno dispone de su propia autoridad sobre el contenido. Por eso la persona u órgano que verifica un erratum depende de dónde se originó el RFC.

En los errata técnicos del flujo IETF, el aviso llega a autores, presidencias del grupo de trabajo y Area Directors. Estos últimos responden del tratamiento, aunque pueden delegar el análisis. Los problemas editoriales pasan primero por el RFC Editor y escalan si esconden una cuestión técnica.

La separación protege dos límites. Quien administra la publicación no recibe automáticamente potestad sobre el protocolo. Quien domina el protocolo tampoco puede modificar el archivo sin dejar la decisión y el fundamento en el canal correspondiente.

Para una auditoría, Verified debe leerse con su sujeto: quién verificó, bajo qué flujo, cuándo y con qué razonamiento. La etiqueta aislada no prueba la autoridad que la produjo.

El consenso original limita la corrección

La declaración activa de la IESG de 2021 define el umbral. El erratum se refiere a algo que ya era erróneo cuando el RFC fue aprobado. Conocimientos posteriores, capacidades nuevas o preferencias diferentes deben ir a un grupo de trabajo, a una discusión de área o a la IESG.

Una solución técnica clara y alineada con la intención original puede ser Verified. Si exige deliberación, queda Held. Si cambia el funcionamiento del protocolo frente al consenso aprobado, debe rechazarse en general. La IESG también rechaza usar este mecanismo para alterar procesos como una política de registro IANA cuando ello cambiaría la decisión comunitaria.

Un cambio pequeño en caracteres puede tener un efecto enorme. Un MUST convertido en SHOULD, una condición invertida o una asignación ampliada redistribuye riesgos y poder. Por eso el revisor necesita el contexto de Last Call, las discusiones del grupo, las evaluaciones de interoperabilidad y el algoritmo completo.

Cuando ese expediente no demuestra una única corrección, mantener la duda es un resultado legítimo. El sistema no debe inventar certeza para limpiar la página.

Reemitir un RFC preserva el significado

RFC 9720 permite reemitir la versión definitiva RFCXML y sus rendiciones por razones controladas, entre ellas cambios del esquema, errores XML y evolución de las herramientas. Las versiones antiguas deben quedar archivadas y cada reemisión necesita una fecha y una explicación públicas.

RFC 9920, publicado en febrero de 2026 y sustituto de RFC 9280, conserva la estabilidad entre las propiedades históricas de la serie. También reconoce que una presentación puede regenerarse. El requisito central consiste en preservar la semántica original.

Corregir un dibujo truncado o una codificación defectuosa no equivale a adoptar una conducta protocolaria distinta. Tampoco la posibilidad de reemisión autoriza a absorber en bloque los errata Verified. El mantenimiento de la publicación, la corrección enlazada y el cambio normativo son tres actos con mandatos diferentes.

Gracias a esa frontera, una investigación puede distinguir si dos sistemas siguieron significados distintos o simplemente consultaron formatos distintos del mismo contenido.

La referencia de ingeniería debe ser compuesta y fechada

“Cumple RFC 1234” no basta. Un expediente reproducible identifica la versión consultada, los RFC posteriores que la actualizan u obsoletan, la fecha de consulta de los errata y las correcciones Verified incorporadas al producto.

Las pruebas deben enlazar cada corrección con comportamiento observable. Si otros equipos aún aplican el pasaje original, las notas de versión necesitan explicar la compatibilidad. Un defecto de seguridad puede requerir mitigación inmediata, aunque la publicación archivada permanezca intacta.

Los elementos Held pueden orientar una revisión futura sin convertirse en fallos automáticos. Los Rejected ayudan a saber qué interpretación fue examinada y descartada. Incluso el rechazo produce información útil cuando conserva sus razones.

La disciplina evita dos extremos: considerar infalible al archivo o considerar legislador al administrador de errata. El corpus operativo puede evolucionar sin borrar las capas que justifican su evolución.

Un registro común deliberadamente delgado

La visión de Heng Lu reserva al registro común las afirmaciones que necesitan coordinación global y deja la evolución a decisiones competentes y adopción voluntaria. El sistema de errata funciona bien bajo esa restricción.

Puede afirmar el RFC, la sección, el pasaje, la propuesta, el estado, el revisor, la fecha y la razón. No puede demostrar que todos los proveedores desplegaron la corrección, que un Held obliga o que la ausencia de objeciones en un grupo inactivo significa consenso.

Mantener separadas esas proposiciones refuerza la legitimidad. La corrección vale porque describe con precisión un defecto revisado y el alcance del juicio, no porque finja haber borrado el proceso que publicó el texto.

Fuentes