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 , entre los que destaca el Grupo de Trabajo de Ingeniería de Internet (IETF). [1] [2] Un RFC está escrito por individuos o grupos de ingenieros e 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, muchos 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, los RFC se han convertido en documentos oficiales de especificaciones , protocolos de comunicaciones , procedimientos y eventos de Internet . [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 EE. UU ., como la Administración Nacional de Seguridad del Tráfico en las Carreteras . [7]
El inicio del formato RFC se produjo en 1969 como parte del proyecto fundamental 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, hasta cierto punto, la comunidad global de investigadores de redes informáticas en general.
Los autores de los primeros RFC escribieron a máquina su trabajo y distribuyeron copias impresas entre los investigadores de ARPA . A diferencia de los RFC modernos, muchos de los primeros RFC eran solicitudes de comentarios reales y se titulaban como tales para evitar sonar demasiado declarativos y fomentar el debate. [8] [9] El RFC deja preguntas abiertas y está escrito en un estilo menos formal. Este estilo menos formal es ahora típico de los documentos Draft de Internet , el paso precursor antes de ser aprobado como RFC.
En diciembre de 1969, los investigadores comenzaron a distribuir nuevos RFC a través de ARPANET, recientemente operativo. 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. [10] Aunque escrito por Steve Crocker, el RFC surgió de una temprana Discusión del grupo de trabajo entre Steve Crocker, Steve Carr y Jeff Rulifson .
EnRFC 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 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 Augmentation Research Center (ARC) del Stanford Research Institute , 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 ), administrado por Elizabeth J. Feinler para distribuir los RFC junto con otra información de la red. [11] 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 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 editorial y responsabilidades de publicación 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 a Alice Hagens en 2005. [12] Bob Braden asumió el rol de líder del proyecto RFC, mientras que Joyce K. Reynolds continuó siendo parte del equipo hasta el 13 de octubre. 2006.
En julio de 2007, se definieron flujos de RFC para poder dividir las tareas de edición. Los documentos del IETF provienen de grupos de trabajo del IETF o presentaciones patrocinadas por un director de área del IETF del Grupo Directivo de Ingeniería de Internet . La IAB puede publicar sus propios documentos. Un flujo de documentos de investigación proviene del Internet Research Task Force (IRTF) y un flujo independiente de otras fuentes externas. [13] En 2008 se propuso un nuevo modelo, se perfeccionó y se publicó en agosto de 2009, dividiendo la tarea en varias funciones, [14] incluido el Grupo Asesor de la Serie RFC (RSAG). El modelo se actualizó en 2012. [15] Las corrientes también se refinaron en diciembre de 2009, con estándares definidos para su estilo. [16] En enero de 2010, la función del editor RFC se trasladó a un contratista, Association Management Solutions, con Glenn Kowack como editor interino de la serie. [17] 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). [18]
En 2020, la IAB convocó el programa de desarrollo futuro del editor RFC para discutir posibles cambios en el modelo del editor RFC. Los resultados del programa se incluyeron en el Modelo de Editor RFC (Versión 3) tal como se define en RFC 9280, publicado en junio de 2022. [1] Generalmente, el nuevo modelo tiene como objetivo aclarar responsabilidades y procesos para definir e implementar políticas relacionadas con el RFC. series y la función Editor RFC. Los cambios en el nuevo modelo incluyeron el establecimiento de la posición del Editor Consultor RFC, el Grupo de Trabajo de la Serie RFC (RSWG) y la Junta de Aprobación de la Serie RFC (RSAB). También estableció una nueva corriente editorial para la Serie RFC y concluyó el RSOC. La función del RSE se cambió a la de Editor consultor de la serie RFC (RSCE). En septiembre de 2022, Alexis Rossi fue designado para ese cargo. [19]
Las solicitudes de comentarios se produjeron originalmente en formato de texto no ajustable . En agosto de 2019, se cambió el formato para que los documentos nuevos se puedan ver de manera óptima en dispositivos con diferentes tamaños de pantalla. [20]
El Editor RFC asigna a cada RFC un número de serie . Una vez asignado un número y publicado, un 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 los RFC reemplazados están en desuso , obsoletos u obsoletos por el RFC reemplazante. 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 RFC está documentado en RFC 2026 ( El proceso de estándares de Internet, Revisión 3 ). [21]
El proceso de producción de RFC difiere del proceso de estandarización de organizaciones de estándares formales como la Organización Internacional de Normalización (ISO). Los expertos en tecnología de Internet pueden presentar 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, por lo general, los producen 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 maduren y se conviertan en RFC. [22]
La tradición RFC de autoría de estándares pragmática, basada en la experiencia y a posteriori, realizada por individuos o pequeños grupos de trabajo, puede tener ventajas importantes [ se necesita aclaración ] sobre el proceso más formal, impulsado por comités, típico de ISO y de los organismos nacionales de normalización. [ cita necesaria ]
La mayoría de los RFC utilizan un conjunto común de términos como "DEBE" y "NO RECOMENDADO" (según lo definido por RFC 2119 y RFC 8174), forma Backus-Naur aumentada (ABNF) (RFC 5234) como metalenguaje y texto simple. -formato basado en, para mantener los RFC consistentes y fáciles de entender. [21]
La serie RFC contiene tres subseries para RFC del IETF : BCP, FYI y STD. Best Current Practice (BCP) es una subserie de RFC obligatorias del IETF que no siguen el seguimiento de 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 a FYI 1 y concluyó esta subserie. El estándar (STD) solía ser el tercer y más alto nivel de madurez del seguimiento de estándares del IETF especificado en RFC 2026 (BCP 9). En 2011, RFC 6410 (una nueva parte de BCP 9) redujo el seguimiento de los estándares a dos niveles de madurez. [ cita necesaria ]
Hay cinco corrientes de RFC: IETF , IRTF , IAB , presentación independiente , [23] y editorial . [1] Sólo el IETF crea BCP y RFC en el ámbito de los estándares. La 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. El IESG revisa los documentos que no pertenecen al IETF para detectar conflictos con el trabajo del IETF. El IRTF y los RFC independientes generalmente contienen información o experimentos relevantes para Internet en general que no entran en conflicto con el trabajo del IETF. compárese RFC 4846, RFC 5742 y RFC 5744. [24] [25] Editorial Stream se utiliza para efectuar cambios en la política editorial en toda la serie RFC (consulte RFC 9280). [1]
La fuente oficial de RFC en la World Wide Web es el Editor RFC. Casi cualquier RFC publicado se puede recuperar a través de una URL del formato http://www.rfc-editor.org/rfc/rfc5000.txt, 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 resúmenes, palabras clave, autor(es), fecha de publicación, erratas, estado y, especialmente, actualizaciones posteriores, el sitio del Editor RFC 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 de serie estándar internacional (ISSN) oficial de la serie RFC es 2070-1721. [dieciséis]
No todos los RFC son estándares. [26] [27] 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 , Mejores prácticas actuales , Seguimiento de estándares o Histórico .
Una vez enviado, aceptado y publicado, un RFC no se puede modificar. Se podrán presentar erratas, que se publican por separado. Los cambios más significativos requieren un nuevo envío que recibirá un nuevo número de serie. [28]
Los documentos de seguimiento de estándares se dividen a su vez en documentos de estándar propuesto y estándar de Internet . [29]
Sólo 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 se utilizaba para mantener una instantánea de la lista. [30]
Cuando se actualiza un estándar de Internet, su número STD permanece igual y ahora se refiere a un nuevo RFC o conjunto de RFC. Un estándar de Internet determinado, STD n , puede ser RFC xey en un momento dado, pero más tarde el mismo estándar puede actualizarse para ser RFC z . 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 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 reemplazada por RFC 7100, actualizándose RFC 2026 para que ya no use STD 1.[actualizar][actualizar]
(Las mejores prácticas actuales funcionan de manera similar; BCP n se refiere a un determinado RFC o conjunto de RFC, pero dicho RFC o RFC pueden cambiar con el tiempo).
Un RFC informativo puede ser casi 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 formaron la subserie FYI .
Un RFC experimental puede ser un documento del IETF o un envío individual al Editor 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 promocionarse a la categoría de estándares si se vuelve popular y funciona bien. [31]
La subserie Mejores Prácticas Actuales recopila documentos administrativos y otros textos que se consideran normas oficiales y no sólo informativas , sino que no afectan a los datos transmitidos por cable . La frontera entre el seguimiento de estándares y el BCP a menudo no está clara. Si un documento sólo afecta al Proceso de Estándares de Internet, como BCP 9, [32] 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 en 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 ingreso a la red: derrotar los ataques de denegación de servicio que emplean suplantación de dirección de origen IP ") es BCP 38.
Un RFC histórico es aquel en el que ya no se recomienda el uso de la tecnología definida por el RFC, lo que difiere del encabezado "Obsoletos" en un RFC de reemplazo. Por ejemplo, el RFC 821 ( SMTP ) en sí está obsoleto debido a varios RFC más nuevos, pero el SMTP en sí sigue siendo "tecnología actual", por lo que no está en estado "Histórico". [33] 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, han sido designados históricos.
El estado desconocido se utiliza para algunos RFC muy antiguos, donde no está claro qué estado obtendría el documento si se publicara hoy. Algunos de estos RFC no se publicarían en absoluto hoy; Una de las primeras RFC era a menudo solo eso: una simple solicitud de comentarios, que no pretendía especificar un protocolo, procedimiento administrativo o cualquier otra cosa para la que se utiliza la serie RFC en la actualidad. [34]
La regla general es que los autores originales (o sus empleadores, si así lo estipulan sus condiciones laborales) conservan los derechos de autor a menos que realicen una transferencia explícita de sus derechos. [35]
Un organismo independiente, el IETF Trust, posee los derechos de autor de algunos RFC y, para todos los demás, los autores le otorgan una licencia que le permite reproducir los RFC. [36] En muchos RFC anteriores al RFC4714 se hace referencia a Internet Society como propietario de los derechos de autor, pero transfirió sus derechos al IETF Trust. [37]
La serie Solicitud de comentarios (RFC) es la serie de archivos dedicada a documentar las especificaciones técnicas de Internet,...
... cada RFC tiene un estado...: Informativo, Experimental o de Seguimiento de Estándares (Estándar Propuesto, Borrador de Estándar, Estándar de Internet) o Histórico.
Los RFC son una serie de documentos de archivo;
no pueden cambiar[.]
Muchos de los primeros documentos RFC tienen el estado "desconocido" porque provienen de la versión larga -Se acabó la época en la que un RFC en realidad era solo una solicitud de comentarios.