De Wikipedia, la enciclopedia libre
Ir a navegaciónSaltar a buscar

Una Solicitud de Comentarios ( RFC ) es una publicación de Internet Society (ISOC) y sus organismos asociados, principalmente el Grupo de Trabajo de Ingeniería de Internet (IETF), los principales organismos de desarrollo técnico y establecimiento de estándares para Internet .

Un RFC es escrito por individuos o grupos de ingenieros e informáticos en forma de un 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 u ocasionalmente humor de ingeniería. [1] 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. [2] El sistema RFC fue inventado por Steve Crocker en 1969 para ayudar a registrar notas no oficiales sobre el desarrollo de ARPANET.. Desde entonces, los RFC se han convertido en documentos oficiales de especificaciones , protocolos de comunicación , procedimientos y eventos de Internet . [3] Según Crocker, los documentos "dan forma al funcionamiento interno de Internet y han jugado un papel importante en su éxito", pero no son muy conocidos fuera de la comunidad. [4]

Fuera de la comunidad de Internet , se han publicado otros documentos también llamados solicitudes de comentarios en el trabajo del gobierno federal de los EE. UU. , Como la Administración Nacional de Seguridad del Tráfico en las Carreteras . [5]

Historia

El inicio del formato RFC se produjo en 1969 como parte del proyecto fundamental ARPANET . [4] En la actualidad, es el canal de publicación oficial del Grupo de trabajo de ingeniería de Internet (IETF), el Consejo de arquitectura de Internet (IAB) y, hasta cierto punto, la comunidad global de investigadores de redes informáticas en general.

Los autores de las primeras RFC escribieron a máquina su trabajo y distribuyeron copias impresas entre los investigadores de ARPA . A diferencia de las RFC modernas, muchas de las RFC tempranas eran Solicitudes de comentarios reales y se titulaban como tales para evitar sonar demasiado declarativas y fomentar la discusión. [6] [7] El RFC deja preguntas abiertas y está escrito en un estilo menos formal. Este estilo menos formal es ahora típico de los borradores de documentos de Internet , el paso previo antes de ser aprobado como RFC.

En diciembre de 1969, los investigadores comenzaron a distribuir nuevos RFC a través de ARPANET, que estaba en funcionamiento. RFC  1, titulado "Host Software", fue escrito por Steve Crocker de la Universidad de California, Los Ángeles (UCLA), y publicado el 7 de abril de 1969. [8] Aunque escrito por Steve Crocker, el RFC había surgido desde un principio discusión en grupo de trabajo entre Steve Crocker, Steve Carr y Jeff Rulifson .

En 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 flexible de investigadores interesados ​​en el proyecto ARPANET. De hecho, incluyó a cualquiera que quisiera unirse a las reuniones y discusiones sobre el proyecto.

Muchos de los RFC posteriores de la década de 1970 también vinieron de UCLA, porque UCLA es uno de los primeros procesadores de mensajes de interfaz (IMP) en ARPANET. El Centro de Investigación de Aumento (ARC) del Instituto de Investigación de Stanford , dirigido por Douglas Engelbart , es otro de los cuatro primeros 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. [9] Desde 1969 hasta 1998, Jon Postel se desempeñó como editor de RFC.. A su muerte en 1998, su obituario se publicó como RFC 2468.

Tras la expiración del contrato original de ARPANET con el gobierno federal de los EE. UU., Internet Society, actuando en nombre del 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 asumir la dirección y Publicar responsabilidades bajo la dirección de la IAB. Sandy Ginoza se unió a USC / ISI en 1999 para trabajar en la edición de RFC, y Alice Hagens en 2005. [10] 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. 2006.

En julio de 2007, se definieron los flujos de RFC, de modo que las tareas de edición pudieran dividirse. Los documentos de IETF provienen de grupos de trabajo de IETF o presentaciones patrocinadas por un director de área de 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. [11] Se propuso un nuevo modelo en 2008, perfeccionado y publicado en agosto de 2009, dividiendo la tarea en varias funciones, [12] incluido el Grupo Asesor de la Serie RFC (RSAG). El modelo se actualizó en 2012. [13]Las corrientes también se refinaron en diciembre de 2009, con estándares definidos para su estilo. [14] En enero de 2010, la función de editor de RFC se trasladó a un contratista, Association Management Solutions, con Glenn Kowack como editor interino de la serie. [15] A finales de 2011, Heather Flanagan fue contratada como editora permanente de la serie RFC. También en ese momento, se creó un Comité de Supervisión de la Serie RFC (RSOC). [dieciséis]

Las solicitudes de comentarios se produjeron originalmente en formato de texto no ajustable . En agosto de 2019, se cambió el formato para que los nuevos documentos se puedan ver de manera óptima en dispositivos con diferentes tamaños de pantalla. [17]

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, algunos RFC reemplazan a otros; Se dice que las RFC reemplazadas están en desuso , obsoletas u obsoletas por la RFC que las reemplaza. Juntos, los RFC serializados 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 ( El proceso de estándares de Internet, revisión 3 ). [18]

El proceso de producción RFC difiere de la estandarización de procesos de las organizaciones formales de normas tales 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 del IETF y generalmente son producidos por expertos que participan en los Grupos de Trabajo del IETF , que primero publican un Borrador de Internet. Este enfoque facilita las rondas iniciales de revisión por pares antes de que los documentos se conviertan en RFC. [ cita requerida ]

La tradición RFC de autoría de estándares pragmática, impulsada por la experiencia y posterior a los hechos lograda por individuos o pequeños grupos de trabajo puede tener importantes ventajas [ aclaración necesaria ] sobre el proceso más formal, impulsado por comités, típico de ISO y organismos nacionales de estándares. [ cita requerida ]

La mayoría de las RFC utilizan un conjunto común de términos como "DEBE" y "NO RECOMENDADO" (como se define en RFC 2119 y RFC 8174), formulario Backus-Naur aumentado (ABNF) (RFC 5234) como metalenguaje y texto simple -basado en formato, con el fin de mantener las RFC coherentes y fáciles de entender. [18]

Subserie

La serie RFC contiene tres subseries para RFC IETF : BCP, FYI y STD. Best Current Practice (BCP) es una subserie de RFC IETF obligatorias que no están en el camino de los estándares. Para su información (FYI) es una subserie de RFC informativas promovidas por el IETF como se especifica en RFC 1150 (FYI 1). En 2011, RFC 6360 dejó obsoleto el FYI 1 y concluyó esta subserie. Estándar (STD) solía ser el tercer y más alto nivel de madurez de la pista de estándares IETF especificada en RFC 2026 (BCP 9). En 2011, RFC 6410 (una nueva parte de BCP 9) redujo el seguimiento de estándares a dos niveles de madurez. [ cita requerida ]

Streams

Hay cuatro flujos de RFC: IETF , IRTF , IAB y envío independiente . [19] Solo el IETF crea BCP y RFC en la pista de estándares. El IESG verifica una presentación independiente en busca de conflictos con el trabajo del IETF; la calidad es evaluada por un comité editorial de envío independiente . En otras palabras, se supone que el IRTF y los RFC independientes  contienen información o experimentos relevantes para Internet en general que no entran en conflicto con el trabajo del IETF; compare RFC 4846, RFC 5742 y RFC 5744. [ cita requerida ]

Obtención de RFC 

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

La fuente oficial de RFC en la World Wide Web es RFC Editor . Casi cualquier RFC publicado se puede recuperar a través de una URL con el formato http://www.rfc-editor.org/rfc/rfc5000.txt, que se muestra para RFC 5000.

Cada RFC se envía como texto ASCII sin formato 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, incluido el resumen, las palabras clave, el autor (es), la fecha de publicación, la errata, el estado y, en especial, las actualizaciones posteriores, el sitio del RFC Editor ofrece un formulario de búsqueda con muchas características. Una redirección establece algunos parámetros eficientes, por ejemplo: rfc: 5000 . [ cita requerida ]

El número de serie estándar internacional (ISSN) oficial de la serie RFC es 2070–1721. [14]

Estado

No todos los RFC son estándares. [20] [21] 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 .

Cada RFC es estático; si se cambia el documento, se vuelve a enviar y se le asigna un nuevo número RFC. [ cita requerida ]

Pista de estándares

Los documentos de seguimiento de estándares se dividen a su vez en documentos de estándar propuesto y estándar de Internet . [22]

Solo el IETF, representado por el Grupo Directivo de Ingeniería de Internet (IESG), puede aprobar RFC de seguimiento de estándares .

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 son los Estándares Oficiales de Protocolo de Internet. Anteriormente, STD 1 solía mantener una instantánea de la lista. [23]

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

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

Informativo

Un RFC informativo puede ser casi cualquier cosa, desde bromas 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

Un RFC experimental puede ser un documento IETF o un envío individual al 'Editor de RFC'. Un borrador se considera experimental si no está claro que la propuesta funcionará según lo previsto o si no está claro si la propuesta será ampliamente adoptada. Un RFC experimental puede promoverse a seguimiento de estándares si se vuelve popular y funciona bien. [24]

Mejores prácticas actuales

La subserie Best Current Practice recopila documentos administrativos y otros textos que se consideran normas oficiales y no solo informativas , pero que no afectan a los datos por cable . El límite entre la vía de estándares y el BCP a menudo no está claro. Si un documento solo afecta el proceso de estándares de Internet, como el BCP 9, [25] o la administración del 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 el camino de los 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 utilizar el filtrado de origen para dificultar los ataques DoS (RFC 2827: " Filtrado de entrada de 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, que difiere del encabezado "Obsoletes" en un RFC de reemplazo. Por ejemplo, RFC 821 ( SMTP ) en sí está obsoleto por varios RFC más nuevos, pero SMTP en sí sigue siendo "tecnología actual", por lo que no está en estado "Histórico". [26] Sin embargo, dado que la versión 4 de BGP ha reemplazado por completo las versiones anteriores de BGP, las RFC que describen esas versiones anteriores, como RFC 1267, se han designado históricas.

Desconocido

El estado desconocido se usa para algunas RFC muy antiguas, donde no está claro qué estado obtendría el documento si se publicara hoy. Algunas de estas RFC no se publicarán en absoluto hoy; Una RFC temprana solía ser solo eso: una simple Solicitud de comentarios, sin la intención de especificar un protocolo, procedimiento administrativo o cualquier otra cosa para la que se usa la serie RFC en la actualidad. [ cita requerida ]

Ver también

  • RFC del Día de los Inocentes
  • Mejores prácticas actuales
  • Nota de experimento de Internet
  • Lista de RFC

Referencias

  1. ^ Waitzman, David (1 de abril de 1990). Un estándar para la transmisión de datagramas IP en aves portadoras . IETF . doi : 10.17487 / RFC1149 . RFC 1149 . Consultado el 29 de marzo de 2017 .
  2. ^ Huitema, cristiano ; Postel, Jon ; Crocker, Steve (abril de 1995). No todos los RFC son estándares . IETF . doi : 10.17487 / RFC1796 . RFC 1796 . Consultado el 15 de mayo de 2018 .
  3. ^ "RFC, solicitud de comentarios de Internet" . Livinginternet.com . Consultado el 3 de abril de 2012 .
  4. ^ a b "Stephen D. Crocker, cómo Internet obtuvo sus reglas , The New York Times, 6 de abril de 2009" . Nytimes.com. 7 de abril de 2009 . Consultado el 3 de abril de 2012 .
  5. ^ Aviso y solicitud de comentarios , en el Registro Federal (16 de enero de 2018).
  6. ^ Hafner, Katie; Lyon, Matthew (1996). Donde los magos se quedan despiertos hasta tarde: los orígenes de Internet.
  7. ^ "Conoce al hombre que inventó las instrucciones para Internet" . Cableado . 18 de mayo de 2012 . Consultado el 18 de diciembre de 2018 .
  8. ^ Crocker, Steve (7 de abril de 1969). "RFC 1" . 
  9. ^ Elizabeth J. Feinler (julio-septiembre de 2010). "El Centro de Información de la Red y sus Archivos". Anales de la historia de la informática . 32 (3): 83–89. doi : 10.1109 / MAHC.2010.54 .
  10. ^ Leslie Daigle (marzo de 2010). "Editor de RFC en transición: pasado, presente y futuro" . El diario de protocolo de Internet . 13 (1). Cisco Systems . Consultado el 17 de agosto de 2011 .
  11. ^ Daigle, Leslie (julio de 2007). La serie RFC y el editor RFC . IETF . doi : 10.17487 / RFC4844 . RFC 4844 .
  12. ^ Kolkman, Olaf (agosto de 2009). Modelo de editor de RFC (versión 1) . IETF . doi : 10.17487 / RFC5620 . RFC 5620 .
  13. ^ Kolkman, Olaf; Halpern, Joel (junio de 2012). Modelo de editor de RFC (versión 2) . IETF . doi : 10.17487 / RFC6635 . RFC 6635 .
  14. ^ a b Daigle, Leslie; Kolkman, Olaf (diciembre de 2009). Secuencias de RFC, encabezados y plantillas . IETF . doi : 10.17487 / RFC5741 . RFC 5741 .
  15. ^ Glenn Kowack (7 de enero de 2010). "Anuncio de transición del editor RFC" . Archivado desde el original el 29 de junio de 2011.
  16. ^ Editor de RFC. "El editor de la serie RFC y la reorganización de la serie" . Consultado el 5 de abril de 2013 .
  17. ^ Preguntas frecuentes sobre el cambio de formato RFC
  18. ^ a b " Índice RFC " . Editor de RFC. 25 de mayo de 2008 . Consultado el 26 de mayo de 2008 .
  19. ^ "Envíos independientes" . Editor de RFC . Consultado el 5 de enero de 2018 .
  20. ^ "¿Todos los RFC son documentos de estándares de Internet?" . Editor de RFC . Consultado el 16 de marzo de 2018 .
  21. ^ Huitema, cristiano ; Postel, Jon ; Crocker, Steve (abril de 1995). No todos los RFC son estándares . IETF . doi : 10.17487 / RFC1796 . RFC 1796 . ... cada RFC tiene un estado ...: Informativo, Experimental o Estándar (Estándar propuesto, Borrador de estándar, Estándar de Internet) o Histórico.
  22. ^ Housley, Russell; Crocker, Dave; Burger, Eric (octubre de 2011). Reducir el seguimiento de estándares a dos niveles de madurez . IETF . doi : 10.17487 / RFC6410 . RFC 6410 .
  23. ^ RFC 7100 Retiro del documento de resumen "Estándares de protocolo oficial de Internet"
  24. ^ "7.5. RFC informativas y experimentales" , The Tao of IETF , consultado el 26 de noviembre de 2017
  25. ^ Bradner, Scott O. (octubre de 1996). El proceso de estándares de Internet - Revisión 3 . IETF . BCP 9 . Consultado el 25 de octubre de 2017 .
  26. ^ "Declaración de IESG sobre la designación de RFC como históricos" . IETF. 20 de julio de 2014 . Consultado el 14 de abril de 2016 .

Enlaces externos

  • Editor de RFC
  • Base de datos RFC
  • Fe de erratas de RFC
  • Preguntas frecuentes sobre RFC
  • Índice RFC (texto)
  • Estándares oficiales de protocolo de Internet
  • Página de RFC de IETF
  • Índice RFC (HTML) Con el texto de cada RFC, también menciona qué otros RFC "actualiza" o "actualiza" este.