Una solicitud de comentarios ( RFC ) es una publicación de una serie de los principales organismos de desarrollo técnico y establecimiento de estándares para Internet , más prominentemente el Grupo de trabajo de ingeniería de Internet (IETF). [1] [2] Una RFC es escrita por individuos o grupos de ingenieros y científicos informáticos en forma de memorando que describe métodos, comportamientos, investigaciones o innovaciones aplicables al funcionamiento de Internet y los sistemas conectados a Internet. Se envía para revisión por pares o para transmitir nuevos conceptos, información o, ocasionalmente, humor de ingeniería. [3]
El IETF adopta algunas de las propuestas publicadas como RFC como estándares de Internet . Sin embargo, muchas RFC son de naturaleza informativa o experimental y no son estándares. [4] El sistema RFC fue inventado por Steve Crocker en 1969 para ayudar a registrar notas no oficiales sobre el desarrollo de ARPANET . Desde entonces, las RFC se han convertido en documentos oficiales de especificaciones de Internet , protocolos de comunicación , procedimientos y eventos. [5] Según Crocker, los documentos "dan forma al funcionamiento interno de Internet y han desempeñado un papel importante en su éxito", pero no son ampliamente conocidos fuera de la comunidad. [6]
Fuera de la comunidad de Internet, se han publicado otros documentos también llamados solicitudes de comentarios , como en trabajos del gobierno federal de Estados Unidos , como la Administración Nacional de Seguridad del Tráfico en las Carreteras . [7]
El formato RFC se creó en 1969 como parte del proyecto ARPANET . [6] Hoy en día, es el canal de publicación oficial del Internet Engineering Task Force (IETF), el Internet Architecture Board (IAB) y, en cierta medida, la comunidad global de investigadores de redes informáticas en general.
Los autores de las primeras RFC escribieron a máquina su trabajo y lo distribuyeron en papel entre los investigadores de ARPA . A diferencia de las RFC modernas, muchas de las primeras RFC eran en realidad solicitudes de comentarios y se titulaban como tales para evitar sonar demasiado declarativas y fomentar el debate. [8] [9] La RFC deja las preguntas abiertas y está escrita en un estilo menos formal. Este estilo menos formal es ahora típico de los documentos de borrador de Internet , el paso previo a su aprobación como RFC.
En diciembre de 1969, los investigadores comenzaron a distribuir nuevos RFC a través de la recién puesta en funcionamiento ARPANET. El RFC 1, titulado "Host Software", fue escrito por Steve Crocker de la Universidad de California en Los Ángeles (UCLA) y publicado el 7 de abril de 1969. [10] Aunque fue escrito por Steve Crocker, el RFC había surgido de una discusión inicial en un grupo de trabajo entre Steve Crocker, Steve Carr y Jeff Rulifson .
EnEn el RFC 3, que definió por primera vez la serie RFC, Crocker comenzó a atribuir la serie RFC al Network Working Group. En lugar de ser un comité formal, era una asociación informal de investigadores interesados en el proyecto ARPANET. De hecho, incluía a cualquiera que quisiera participar en las reuniones y discusiones sobre el proyecto.
Muchos de los RFC posteriores de la década de 1970 también vinieron de la UCLA, porque la UCLA es uno de los primeros de lo que fueron procesadores de mensajes de interfaz (IMP) en ARPANET. El Augmentation Research Center (ARC) en el Stanford Research Institute , dirigido por Douglas Engelbart , es otro de los cuatro primeros de lo que fueron nodos de ARPANET y la fuente de los primeros RFC. El ARC se convirtió en el primer centro de información de red ( InterNIC ), que fue administrado por Elizabeth J. Feinler para distribuir los RFC junto con otra información de red. [11]
Desde 1969 hasta 1998, Jon Postel fue editor de RFC . Cuando falleció en 1998, su obituario se publicó como RFC 2468.
Tras la expiración del contrato original de ARPANET con el gobierno federal de los Estados Unidos, la Internet Society, actuando en nombre 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. [12] Bob Braden asumió el papel de líder del proyecto RFC, mientras que Joyce K. Reynolds continuó siendo parte del equipo hasta el 13 de octubre de 2006.
En julio de 2007, se definieron los 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 de presentaciones patrocinadas por un director de área del IETF del Internet Engineering Steering Group . El IAB puede publicar sus propios documentos. Un flujo de investigación de documentos proviene del Internet Research Task Force (IRTF), y un flujo independiente de otras fuentes externas. [13] Se propuso un nuevo modelo en 2008, que se perfeccionó y se publicó en agosto de 2009, dividiendo la tarea en varias funciones, [14] incluido el RFC Series Advisory Group (RSAG). El modelo se actualizó en 2012. [15] Los flujos también se perfeccionaron en diciembre de 2009, con estándares definidos para su estilo. [16]
En enero de 2010, la función de editor de RFC se trasladó a un contratista, Association Management Solutions, y Glenn Kowack se desempeñó como editor interino de la serie. [17] A fines 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). [18]
En 2020, el IAB convocó el programa de Desarrollo Futuro del Editor de RFC para discutir posibles cambios en el modelo del Editor de RFC. Los resultados del programa incluyeron el Modelo del Editor de RFC (Versión 3) según 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 de RFC y la función del Editor de RFC. Los cambios en el nuevo modelo incluyeron el establecimiento del puesto del Editor Consultor de RFC, el Grupo de Trabajo de la Serie de RFC (RSWG) y la Junta de Aprobación de la Serie de RFC (RSAB). También estableció una nueva Línea Editorial para la Serie de RFC y concluyó el RSOC. El rol del RSE se cambió al de Editor Consultor de la Serie de RFC (RSCE). En septiembre de 2022, Alexis Rossi fue designado para ese puesto. [19]
Las solicitudes de comentarios se redactaban originalmente en formato de texto no ajustable . En agosto de 2019, se modificó el formato para que los nuevos documentos se puedan visualizar de forma óptima en dispositivos con distintos tamaños de pantalla. [20]
El editor de RFC asigna a cada RFC un número de serie . Una vez que se le asigna un número y se publica, una RFC nunca se rescinde ni se modifica; si el documento requiere modificaciones, los autores publican un documento revisado. Por lo tanto, algunas RFC reemplazan a otras; se dice que las RFC reemplazadas están en desuso , obsoletas u obsoletas por la RFC que las reemplaza. En conjunto, las RFC serializadas componen un registro histórico continuo de la evolución de los estándares y prácticas de Internet. El proceso de RFC está documentado en RFC 2026 ( The Internet Standards Process, Revision 3 ). [21]
El proceso de producción de RFC difiere del proceso de estandarización de las organizaciones de estándares formales como la Organización Internacional de Normalización (ISO). Los expertos en tecnología de Internet pueden enviar un borrador de Internet sin el apoyo de una institución externa. Los RFC de seguimiento de estándares se publican con la aprobación de la IETF y generalmente son producidos por expertos que participan en los Grupos de Trabajo de la IETF , que primero publican un Borrador de Internet. Este enfoque facilita las rondas iniciales de revisión por pares antes de que los documentos maduren y se conviertan en RFC. [22]
La tradición de RFC de autoría de normas pragmática, basada en la experiencia y posterior a los hechos, realizada por individuos o pequeños grupos de trabajo, puede tener ventajas importantes [ aclaración necesaria ] sobre el proceso más formal, impulsado por comités, típico de la ISO y los organismos de normalización nacionales. [23]
La mayoría de los RFC utilizan un conjunto común de términos como "DEBE" y "NO RECOMENDADO" (como se define en RFC 2119 y 8174), la forma Backus-Naur aumentada (ABNF) ( RFC 5234) como metalenguaje y un formato simple basado en texto, para mantener los RFC consistentes y fáciles de entender. [21]
La serie RFC contiene tres subseries de RFC del IETF : BCP, FYI y STD. Best Current Practice (BCP) es una subserie de RFC obligatorias del IETF que no se encuentran en la vía de estándares. For Your Information (FYI) es una subserie de RFC informativas promovidas por el IETF, tal como se especifica en la RFC 1150 (FYI 1). En 2011, la RFC 6360 dejó obsoleta la 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 la RFC 2026 (BCP 9). En 2011 , la RFC 6410 (una nueva parte de BCP 9) redujo la vía de estándares a dos niveles de madurez. [ cita requerida ]
Existen cinco corrientes de RFC: IETF , IRTF , IAB , presentación independiente , [24] y Editorial . [1] Solo el IETF crea BCP y RFC en la vía de estándares. El IAB publica documentos informativos relacionados con políticas o arquitecturas. El IRTF publica los resultados de la investigación, ya sea como documentos informativos o como experimentos. Las presentaciones independientes se publican a discreción del Editor de presentaciones independientes. El IESG revisa los documentos que no son del IETF para detectar conflictos con el trabajo del IETF. El IRTF y las RFC independientes generalmente contienen información relevante o experimentos para Internet en general que no entran en conflicto con el trabajo del IETF. Compárese con RFC 4846, 5742 y 5744. [25] [26] La corriente Editorial se utiliza para efectuar cambios en la política editorial en toda la serie de RFC (consulte RFC 9280). [1]
La fuente oficial de RFC en la World Wide Web es RFC Datatracker. Casi cualquier RFC publicada se puede recuperar a través de una URL con el formato https://datatracker.ietf.org/doc/html/rfc5000, que se muestra para RFC 5000.
Cada RFC se envía como texto ASCII simple y se publica en ese formato, pero también puede estar disponible en otros formatos .
Para acceder fácilmente a los metadatos de un RFC, incluidos el resumen, las palabras clave, el autor(es), la fecha de publicación, las erratas, el estado y, especialmente, las actualizaciones posteriores, el sitio RFC Editor ofrece un formulario de búsqueda con muchas funciones. Una redirección establece algunos parámetros eficientes, por ejemplo: rfc:5000. [4]
El número oficial de serie internacional estándar (ISSN) de la serie RFC es 2070-1721. [16]
No todas las RFC son estándares. [27] [28] A cada RFC se le asigna una designación con respecto al estado dentro del proceso de estandarización de Internet. Este estado es uno de los siguientes: Informativo , Experimental , Mejor práctica actual , Seguimiento de estándares o Histórico .
Una vez presentada, aceptada y publicada, una RFC no puede modificarse. Se pueden presentar erratas, que se publican por separado. Los cambios más significativos requieren una nueva presentación, que recibirá un nuevo número de serie. [29]
Los documentos de la vía de estándares se dividen además en documentos de Estándares propuestos y Estándares de Internet . [30]
Sólo el IETF, representado por el Internet Engineering Steering Group (IESG), puede aprobar RFC de carácter normativo .
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 los estándares oficiales de protocolo de Internet. Anteriormente, STD 1 solía mantener una instantánea de la lista. [31]
Cuando se actualiza un estándar de Internet, su número STD permanece igual, y ahora hace referencia a un nuevo RFC o conjunto de RFC. Un estándar de Internet determinado, STD n , puede ser los RFC x e y en un momento dado, pero más tarde el mismo estándar puede actualizarse para convertirse en RFC z . 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, [actualizar]el STD 1 es el RFC 5000. A partir de diciembre de 2013, el RFC 5000 se reemplaza por el RFC 7100, lo que actualiza el RFC 2026 para que ya no utilice el STD 1.[actualizar]
(Las mejores prácticas actuales funcionan de manera similar; BCP n se refiere a una determinada RFC o conjunto de RFC, pero dicha RFC o RFC pueden cambiar con el tiempo).
Una RFC informativa puede ser prácticamente cualquier cosa, desde chistes del 1 de abril hasta RFC esenciales ampliamente reconocidos, como la Estructura y delegación del sistema de nombres de dominio ( RFC 1591). Algunas RFC informativas formaron la subserie FYI .
Una RFC experimental puede ser un documento de la IETF o una presentación individual al editor de RFC. Un borrador se designa como experimental si no está claro si la propuesta funcionará como se pretende o si será ampliamente adoptada. Una RFC experimental puede ser promovida a la vía de estándares si se vuelve popular y funciona bien. [32]
La subserie Best Current Practice recopila documentos administrativos y otros textos que se consideran reglas oficiales y no solo informativos , pero que no afectan a los datos por cable . La frontera entre la vía de estándares y el BCP a menudo no está clara. Si un documento solo afecta al Proceso de estándares de Internet, como BCP 9, [33] o la administración de IETF, es claramente un BCP. Si solo define reglas y regulaciones para los registros de la Autoridad de números asignados de Internet (IANA), es menos claro; la mayoría de estos documentos son BCP, pero algunos están en la vía de estándares.
La serie BCP también cubre recomendaciones técnicas sobre cómo practicar los estándares de Internet; por ejemplo, la recomendación de usar filtrado de origen para dificultar los ataques DoS ( RFC 2827: " Filtrado de ingreso a la red: Derrotar ataques de denegación de servicio que emplean suplantación de direcciones de origen IP ") es BCP 38.
Un RFC histórico es aquel en el que la tecnología definida por el RFC ya no se recomienda para su uso, lo que difiere del encabezado "Obsoletos" en un RFC de reemplazo. Por ejemplo, el RFC 821 ( SMTP ) en sí mismo está obsoleto por varios RFC más nuevos, pero SMTP en sí mismo sigue siendo una "tecnología actual", por lo que no está en estado "Histórico". [34] Sin embargo, dado que la versión 4 de BGP ha reemplazado por completo 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 algunas RFC muy antiguas, en las que no está claro qué estado obtendría el documento si se publicara hoy. Algunas de estas RFC ni siquiera se publicarían hoy en día; una RFC temprana a menudo era solo eso: una simple solicitud de comentarios, no destinada a especificar un protocolo, un procedimiento administrativo ni nada para lo que se utiliza la serie de RFC en la actualidad. [35]
La regla general es que los autores originales (o sus empleadores, si sus condiciones de empleo así lo estipulan) conservan los derechos de autor a menos que hagan una transferencia explícita de sus derechos. [36]
Un organismo independiente, el IETF Trust, posee los derechos de autor de algunas RFC y, para todas las demás, los autores le otorgan una licencia que le permite reproducirlas. [37] En muchas RFC anteriores a la RFC 4714 se hace referencia a la Internet Society como propietaria de los derechos de autor, pero transfirió sus derechos al IETF Trust. [38]
La serie de solicitudes de comentarios (RFC) es la serie de archivo dedicada a documentar las especificaciones técnicas de Internet, ...
... cada RFC tiene un estado…: informativo, experimental o de vías de estándares (estándar propuesto, borrador de estándar, estándar de Internet) o histórico.
Las RFC son una serie de documentos archivados; no pueden cambiar[.]
Muchos de los primeros documentos RFC tienen el estado "desconocido" porque provienen de una época ya lejana en la que un RFC en realidad era solo una solicitud de comentarios.
Identificación de RfC (P892) (ver usos )