Solicitud de comentarios
Publicación del desarrollo y estándares para Internet

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]

Historia

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]

Función del editor de RFC

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]

Nuevo formato de publicación

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]

Producción y control de versiones

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]

Subserie

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 ]

Arroyos

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]

Obtención de RFC

RFC 2046 Tipos de medios Noviembre de 1996 A. Gramática recopilada .................................... 431. Introducción El primer documento de este conjunto, RFC 2045, define una serie de encabezados campos, incluido Content-Type. El campo Content-Type se utiliza para especificar la naturaleza de los datos en el cuerpo de una entidad MIME, por proporcionando identificadores de tipo y subtipo de medio y proporcionando datos auxiliares información que puede ser necesaria para ciertos tipos de medios. Después de la
RFC  2046, que define el tipo MIME text/plain , es en sí mismo un texto simple.

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]

Estado

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]

Ruta de estándares

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).

Informativo

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 .

Experimental

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]

Mejores prácticas actuales

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.

Histórico

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.

Desconocido

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]

Véase también

Referencias

  1. ^ abcd St Andre, Peter (junio de 2022). RFC Editor Model (versión 3). IETF . doi : 10.17487/RFC9280 . RFC 9280. La serie de solicitudes de comentarios (RFC) es la serie de archivo dedicada a documentar las especificaciones técnicas de Internet, ...
  2. ^ "RFC". IETF . Consultado el 5 de noviembre de 2023 .
  3. ^ Waitzman, David (1 de abril de 1990). Un estándar para la transmisión de datagramas IP en portadoras aviares. IETF . doi : 10.17487/RFC1149 . RFC 1149 . Consultado el 29 de marzo de 2017 .
  4. ^ ab Huitema, Christian ; Postel, Jon ; Crocker, Steve (abril de 1995). No todas las RFC son estándares. IETF . doi : 10.17487/RFC1796 . RFC 1796 . Consultado el 15 de mayo de 2018 .
  5. ^ "RFC's, Internet Request For Comments" (RFC, solicitud de comentarios en Internet). Livinginternet.com . Consultado el 3 de abril de 2012 .
  6. ^ ab "Stephen D. Crocker, How the Internet Got Its Rules, The New York Times, 6 de abril de 2009". The New York Times . 7 de abril de 2009 . Consultado el 3 de abril de 2012 .
  7. ^ "Aviso y solicitud de comentarios". Registro Federal . 16 de enero de 2018.
  8. ^ Hafner, Katie; Lyon, Matthew (1996). Donde los magos se quedan despiertos hasta tarde: los orígenes de Internet . Un libro de Touchstone. Simon & Schuster. ISBN 978-0-684-81201-4.
  9. ^ Metz, Cade (18 de mayo de 2012). «Conozca al hombre que inventó las instrucciones para Internet». Wired . Consultado el 18 de diciembre de 2018 .
  10. ^ Crocker, Steve (7 de abril de 1969). RFC 1. doi : 10.17487/RFC0001 . RFC 1.
  11. ^ Elizabeth J. Feinler (julio-septiembre de 2010). "El Centro de Información de Redes y sus Archivos". Anales de la Historia de la Computación . 32 (3): 83–89. doi : 10.1109/MAHC.2010.54 . S2CID 206443021 . 
  12. ^ Leslie Daigle (marzo de 2010). "Editor de RFC en transición: pasado, presente y futuro". The Internet Protocol Journal . Vol. 13, núm. 1. Cisco Systems. Archivado desde el original el 20 de septiembre de 2010. Consultado el 17 de agosto de 2011 .
  13. ^ Daigle, Leslie (julio de 2007). La serie RFC y el editor de RFC. IETF . doi : 10.17487/RFC4844 . RFC 4844.
  14. ^ Kolkman, Olaf (agosto de 2009). Modelo del editor RFC (Versión 1). IETF . doi : 10.17487/RFC5620 . RFC 5620.
  15. ^ Kolkman, Olaf; Halpern, Joel (junio de 2012). Modelo del editor RFC (Versión 2). IETF . doi : 10.17487/RFC6635 . RFC 6635.
  16. ^ ab Daigle, Leslie; Kolkman, Olaf (diciembre de 2009). RFC Streams, Headers, and Boilerplates. IETF . doi : 10.17487/RFC5741 . RFC 5741.
  17. ^ Glenn Kowack (7 de enero de 2010). "Anuncio de transición del editor de RFC". Archivado desde el original el 29 de junio de 2011.
  18. ^ "El editor de la serie RFC y la reorganización de la serie" . Consultado el 5 de abril de 2013 .
  19. ^ "Alexis Rossi fue nombrado editor consultor de la serie RFC" . Consultado el 19 de agosto de 2023 .
  20. ^ "Preguntas frecuentes sobre cambios de formato RFC".
  21. ^ ab "Índice RFC". RFC Editor. 25 de mayo de 2008. Consultado el 26 de mayo de 2008 .
  22. ^ Directrices y procedimientos del grupo de trabajo de la IETF. doi : 10.17487/RFC2418 . RFC 2418.
  23. ^ Este artículo se basa en material tomado de Request+for+Comments en el Diccionario gratuito en línea de informática antes del 1 de noviembre de 2008 e incorporado bajo los términos de "renovación de la licencia" del GFDL , versión 1.3 o posterior.
  24. ^ "Presentaciones independientes". Editor de RFC . Consultado el 5 de enero de 2018 .
  25. ^ Klensin, John; Thaler, David (julio de 2007). Envíos independientes al editor de RFC. IAB . doi : 10.17487/RFC4846 . RFC 4846.>
  26. ^ Alvestrand, Harald; Housley, Russ (diciembre de 2009). Procedimientos del IESG para el manejo de presentaciones de flujos independientes y de IRTF. IETF . doi : 10.17487/RFC5742 . RFC 5742.
  27. ^ "¿Son todos los RFC documentos de estándares de Internet?". Editor de RFC . Consultado el 16 de marzo de 2018 .
  28. ^ Huitema, Christian ; Postel, Jon ; Crocker, Steve (abril de 1995). No todas las RFC son estándares. IETF . doi : 10.17487/RFC1796 . RFC 1796. ... 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.
  29. ^ Nottingham, Mark (31 de julio de 2018). "Cómo leer una RFC" . Consultado el 18 de septiembre de 2023 . Las RFC son una serie de documentos archivados; no pueden cambiar[.]
  30. ^ Housley, Russell; Crocker, Dave; Burger, Eric (octubre de 2011). Reducción de la trayectoria de los estándares a dos niveles de madurez. IETF . doi : 10.17487/RFC6410 . RFC 6410.
  31. ^ Retiro del documento resumen "Estándares de protocolo oficial de Internet". doi : 10.17487/RFC7100 . RFC 7100.
  32. ^ "7.5. RFC informativos y experimentales". El Tao del IETF . Consultado el 26 de noviembre de 2017 .
  33. ^ Bradner, Scott O. (octubre de 1996). The Internet Standards Process – Revision 3 [El proceso de normalización de Internet: revisión 3]. IETF . BCP 9. Consultado el 25 de octubre de 2017 .
  34. ^ "Declaración del IESG sobre la designación de RFC como históricas". IETF. 20 de julio de 2014. Consultado el 14 de abril de 2016 .
  35. ^ "Estándares IETF escritos por colaboradores de ISC". Consorcio de sistemas de Internet . 10 de septiembre de 2021. Archivado desde el original el 5 de abril de 2022. Consultado el 11 de abril de 2022. 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.
  36. ^ "Reproducción de RFC". IETF Trust . Consultado el 12 de agosto de 2021 .
  37. ^ Bradner, Scott; Contreras, Jorge (noviembre de 2008). Derechos que los colaboradores proporcionan al fideicomiso IETF. IETF . doi : 10.17487/RFC5378 . RFC 5378.
  38. ^ "Reproducción de RFC". IETF Trust . Consultado el 13 de agosto de 2021 .
Wikidata tiene la propiedad:
  • Identificación de RfC (P892) (ver usos )
  • Editor de RFC
  • Base de datos RFC
  • Erratas del RFC
  • Preguntas frecuentes sobre RFC
  • Índice RFC (texto)
  • Estándares oficiales del protocolo de Internet
  • Página de RFC de la IETF
  • Índice RFC (HTML) Junto con el texto de cada RFC, también se menciona qué otros RFC "actualiza" éste o es "actualizado por".
Obtenido de "https://es.wikipedia.org/w/index.php?title=Solicitud_de_comentarios&oldid=1258190501"