Solicitud de comentarios

Desde 1969 hasta 1998, Jon Postel fue editor de RFC . Tras su fallecimiento en 1998, su obituario se publicó como RFC 2468. ^{[ 12 ]} 

Tras la expiración del contrato original de ARPANET con el gobierno federal de EE. UU., la Internet Society, en representación de la IETF, contrató a la División de Redes del Instituto de Ciencias de la Información (ISI) de la Universidad del Sur de California (USC ) para que asumiera las responsabilidades de edición y publicación bajo la dirección del IAB. Sandy Ginoza se unió a USC/ISI en 1999 para trabajar en la edición de RFC, y Alice Hagens en 2005. ^{[ 13 ]} Bob Braden asumió el rol de líder del proyecto RFC, mientras que Joyce K. Reynolds continuó formando parte del equipo hasta el 13 de octubre de 2006.

En julio de 2007, se definieron flujos de RFC, de modo que las tareas de edición pudieran dividirse. Los documentos del IETF provenían de grupos de trabajo del IETF o presentaciones patrocinadas por un director de área del IETF del Grupo Directivo de Ingeniería de Internet . El IAB puede publicar sus propios documentos. Un flujo de investigación de documentos proviene del Grupo de Trabajo de Investigación de Internet (IRTF), y un flujo independiente de otras fuentes externas. ^{[ 14 ]} Se propuso un nuevo modelo en 2008, se refinó y se publicó en agosto de 2009, dividiendo la tarea en varios roles, ^{[ 15 ]} incluido el Grupo Asesor de la Serie RFC (RSAG). El modelo se actualizó en 2012, ^{[ 16 ]} y 2020. ^{[ 17 ]} Los flujos también se refinaron en diciembre de 2009, con estándares definidos para su estilo. ^{[ 18 ]} En enero de 2010, la función de Editor de RFC se transfirió a un contratista, Association Management Solutions, con Glenn Kowack como editor de la serie interino. ^{[ 19 ]} A finales de 2011, Heather Flanagan fue contratada como editora permanente de la serie RFC (RSE). También en ese momento, se creó un Comité de Supervisión de la Serie RFC (RSOC). ^{[ 20 ]}

En 2020, el IAB convocó el programa de Desarrollo Futuro del Editor de RFC para debatir posibles cambios en el modelo del Editor de RFC. Los resultados del programa incluyeron el Modelo del Editor de RFC (Versión 3), tal como se define en el RFC 9280 , publicado en junio de 2022. ^{[ 1 ]} En general, el nuevo modelo tiene como objetivo aclarar las responsabilidades y los procesos para definir e implementar políticas relacionadas con la serie RFC y la función del Editor de RFC. Los cambios en el nuevo modelo incluyeron el establecimiento del puesto de Editor Consultor de RFC, el Grupo de Trabajo de la Serie RFC (RSWG) y la Junta de Aprobación de la Serie RFC (RSAB). También se estableció una nueva Línea Editorial para la Serie RFC y se concluyó el RSOC. El rol del RSE se cambió a Editor Consultor de la Serie RFC (RSCE). En septiembre de 2022, Alexis Rossi fue nombrado para ese puesto. ^{[ 21 ]} 

Las solicitudes de comentarios se generaron originalmente en formato de texto no adaptable . En agosto de 2019, se cambió el formato para que los nuevos documentos se puedan visualizar de forma óptima en dispositivos con diferentes tamaños de pantalla. ^{[ 22 ]}

La serie RFC contiene tres subseries para los RFC del IETF : BCP, FYI y STD. Best Current Practice (BCP) es una subserie de RFC obligatorios del IETF que no están en la vía de estándares. For Your Information (FYI) es una subserie de RFC informativos promovidos por el IETF como se especifica en RFC 1150 (FYI 1). En 2011, RFC 6360 dejó obsoleto FYI 1 y concluyó esta subserie. Standard (STD) solía ser el tercer y más alto nivel de madurez de la vía de estándares del IETF especificado en RFC 2026 (BCP 9). En 2011 , RFC 6410 (una nueva parte de BCP 9) redujo la vía de estándares a dos niveles de madurez.        

Hay cinco flujos de RFC: IETF , IRTF , IAB , envío independiente , ^{[ 26 ]} y Editorial . Solo el IETF crea BCP y RFC en la vía de estándares. El IAB publica documentos informativos relacionados con políticas o arquitectura. El IRTF publica los resultados de la investigación, ya sea como documentos informativos o como experimentos. Los envíos independientes se publican a discreción del Editor de Envíos Independientes. Los documentos que no son del IETF son revisados ​​por el IESG para detectar conflictos con el trabajo del IETF. Los RFC del IRTF y los independientes  generalmente contienen información o experimentos relevantes para Internet en general que no entran en conflicto con el trabajo del IETF. Comparar RFC 4846 , 5742 y 5744. ^{[ 27 ] [ 28 ]} El Flujo Editorial se utiliza para efectuar cambios en la política editorial en toda la serie de RFC (véase RFC 9280 ). ^{[ 1 ]}  

Los documentos de la vía de estándares se dividen además en documentos de Estándar Propuesto y Documentos de Estándar de Internet . ^{[ 31 ]}

Solo el IETF, representado por el Grupo Directivo de Ingeniería de Internet (IESG), puede aprobar los RFC que se incorporan a la vía de estandarización .

Si un RFC se convierte en un estándar de Internet (STD), se le asigna un número STD pero conserva su número RFC. La lista definitiva de estándares de Internet es la de Estándares Oficiales de Protocolo de Internet. Anteriormente, se utilizaba STD 1 para mantener una instantánea de la lista. ^{[ 32 ]}

Cuando se actualiza un estándar de Internet, su número STD permanece igual, refiriéndose ahora a un nuevo RFC o conjunto de RFC. Un estándar de Internet dado, STD n , puede ser los RFC x e y en un momento dado, pero más tarde el mismo estándar puede actualizarse para ser el RFC z en su lugar. Por ejemplo, en 2007 el RFC 3700 era un estándar de Internet (STD 1) y en mayo de 2008 fue reemplazado por el RFC 5000 , por lo que el RFC 3700 cambió a histórico , el RFC 5000 se convirtió en un estándar de Internet y a partir de mayo de 2008     STD 1 es RFC 5000. A partir de diciembre de 2013 .  RFC 5000 es reemplazado por RFC 7100 , actualizando RFC 2026 para que ya no utilice STD 1.   

(Las Mejores Prácticas Actuales funcionan de manera similar; BCP n se refiere a un RFC determinado o a un conjunto de RFC, pero qué RFC o RFC pueden cambiar con el tiempo).

Un RFC informativo puede ser prácticamente cualquier cosa, desde chistes del 1 de abril hasta RFC esenciales ampliamente reconocidos como Estructura y delegación del sistema de nombres de dominio ( RFC 1591 ). Algunos RFC informativos conformaron la subserie FYI . 

Un RFC experimental puede ser un documento del IETF o una propuesta individual enviada al editor de RFC. Un borrador se designa como experimental si no está claro si la propuesta funcionará según lo previsto o si será ampliamente adoptada. Un RFC experimental puede ser promovido a la vía de los estándares si se populariza y funciona correctamente. ^{[ 33 ]}

La subserie de Mejores Prácticas Actuales recopila documentos administrativos y otros textos considerados como normas oficiales, no solo informativas , pero que no afectan a los datos transmitidos por la red . La frontera entre la vía de los estándares y las BCP suele ser difusa. Si un documento solo afecta al Proceso de Estándares de Internet, como BCP 9, ^{[ 34 ]} o a la administración del IETF, es claramente una BCP. Si solo define normas y reglamentos para los registros de la Autoridad de Números Asignados de Internet (IANA), la situación es menos clara; la mayoría de estos documentos son BCP, pero algunos se encuentran en la vía de los estándares.

La serie BCP también abarca recomendaciones técnicas sobre cómo aplicar los estándares de Internet; por ejemplo, la recomendación de utilizar el filtrado de origen para dificultar los ataques DoS ( RFC 2827 : " Filtrado de entrada de red: cómo contrarrestar los ataques de denegación de servicio que emplean la suplantación de direcciones IP de origen ") es BCP 38 . 

Un RFC histórico es aquel cuya tecnología definida ya no se recomienda para su uso, lo que difiere del encabezado "Obsoletos" en un RFC de reemplazo. Por ejemplo, el RFC 821 ( SMTP ) está obsoleto debido a varios RFC más recientes, pero SMTP sigue siendo una "tecnología actual", por lo que no tiene el estado de "Histórico". ^{[ 35 ]} Sin embargo, dado que la versión 4 de BGP ha reemplazado por completo a las versiones anteriores de BGP, los RFC que describen esas versiones anteriores, como el RFC 1267 , se han designado como históricos.  

El estado desconocido se utiliza para algunos RFC muy antiguos, donde no está claro qué estado tendría el documento si se publicara hoy. Algunos de estos RFC no se publicarían en absoluto hoy; un RFC antiguo a menudo era simplemente eso: una simple Solicitud de Comentarios, sin la intención de especificar un protocolo, un procedimiento administrativo ni ninguna otra cosa para la que se utiliza la serie de RFC en la actualidad. ^{[ 36 ]}