Solicitud de comentarios
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, principalmente Internet Engineering Task. Fuerza (IETF). Un RFC está 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 o, en ocasiones, humor de ingeniería.
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. 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 de Internet, protocolos de comunicación, procedimientos y eventos. 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.
Fuera de la comunidad de Internet, se han publicado otros documentos también llamados solicitudes de comentarios en el trabajo del gobierno federal de EE. UU., como la Administración Nacional de Seguridad del Tráfico en las Carreteras.
Historia
El inicio del formato RFC se produjo en 1969 como parte del proyecto seminal ARPANET. Hoy en día, es el canal de publicación oficial del Grupo de Trabajo de Ingeniería de Internet (IETF), la Junta de Arquitectura de Internet (IAB) y, hasta cierto punto, la comunidad global de investigadores de redes informáticas en general.
Los autores de los primeros RFC mecanografiaron 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 que suenen demasiado declarativos y para fomentar el debate. El RFC deja preguntas abiertas y está escrito en un estilo menos formal. Este estilo menos formal ahora es típico de los documentos borrador 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 operativa. 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 Aunque escrito por Steve Crocker, el RFC surgió de una discusión inicial en un 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 Grupo de trabajo de red. En lugar de ser un comité formal, era una asociación informal de investigadores interesados en el proyecto ARPANET. En efecto, 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 provinieron 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) en el Instituto de Investigación de Stanford, dirigido por Douglas Engelbart, es otro de los cuatro primeros de lo que fueron nodos 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. 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 de 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 las responsabilidades editoriales y de 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. Bob Braden asumió el papel de líder del proyecto RFC, mientras que Joyce K. Reynolds siguió formando parte del equipo hasta el 13 de octubre de 2006.
En julio de 2007, se definieron flujos de RFC, de modo que se pudieran 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. 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. En 2008 se propuso un nuevo modelo, se perfeccionó y se publicó en agosto de 2009, dividiendo la tarea en varios roles, incluido el Grupo asesor de la serie RFC (RSAG). El modelo se actualizó en 2012. Las secuencias también se refinaron en diciembre de 2009, con estándares definidos para su estilo. En enero de 2010, la función Editor de RFC se transfirió a un contratista, Association Management Solutions, con Glenn Kowack como editor interino de la serie. A fines 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).
En 2020, el IAB convocó el programa de desarrollo futuro del editor de RFC para analizar posibles cambios en el modelo del editor de RFC. Los resultados del programa incluyeron el Modelo del Editor de RFC (Versión 3) como se define en el RFC 9280 publicado en junio de 2022. 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 el Editor de RFC. función. Los cambios en el nuevo modelo incluyeron el establecimiento de la posición del 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 estableció una nueva Corriente Editorial para la Serie RFC y concluyó el RSOC.
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.
Producción y versiones
El editor de RFC asigna a cada RFC un número de serie. Una vez asignado un número y publicado, un RFC nunca se rescinde ni modifica; si el documento requiere enmiendas, 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 o 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 de RFC está documentado en RFC 2026 (El proceso de estándares de Internet, revisión 3).
El proceso de producción de RFC difiere del proceso de estandarización de las organizaciones formales de estándares, como la Organización Internacional de Estandarizació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 se conviertan en RFC.
La tradición RFC de autoría de estándares pragmática, impulsada por la experiencia y posterior a los hechos realizada por individuos o pequeños grupos de trabajo puede tener ventajas importantes sobre el proceso más formal, impulsado por comités, típico de ISO y los organismos nacionales de normalización.
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 de Backus-Naur aumentada (ABNF) (RFC 5234) como un metalenguaje y formato simple basado en texto, para mantener los RFC consistentes y fáciles de entender.
Subserie
La serie RFC contiene tres subseries para RFC de IETF: BCP, FYI y STD. Best Current Practice (BCP) es una subserie de RFC de IETF obligatorios que no están en el camino de los estándares. Para su información (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 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 parte nueva de BCP 9) redujo el seguimiento de estándares a dos niveles de madurez.
Transmisiones
Hay cuatro flujos de RFC: IETF, IRTF, IAB y presentación independiente. Solo el IETF crea BCP y RFC en la vía de los estándares. El IESG verifica una presentación independiente en busca de conflictos con el trabajo del IETF; la calidad es evaluada por un consejo editorial independiente. En otras palabras, se supone que la IRTF y los RFC independientes contienen información o experimentos relevantes para Internet en general que no entren en conflicto con el trabajo de la IETF; compare RFC 4846, RFC 5742 y RFC 5744.
Obtención de RFC
RFC 2046 Tipos de medios noviembre 1996 A. Coleccionado Grammar........................... 43 1. Introducción El primer documento en este conjunto, RFC 2045, define un número de encabezado campos, incluyendo 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 tipos de medios y identificadores de subtipo, y proporcionando auxiliar información que puede ser necesaria para ciertos tipos de medios. Después de la |
La fuente oficial de RFC en la World Wide Web es el Editor de RFC. Casi cualquier RFC publicado se puede recuperar a través de una URL del formulario 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, los autores, la fecha de publicación, la fe de erratas, el estado y, en especial, las actualizaciones posteriores, el sitio del editor de RFC ofrece un formulario de búsqueda con muchas funciones. Una redirección establece algunos parámetros eficientes, ejemplo: rfc:5000.
El número de serie estándar internacional (ISSN) oficial de la serie RFC es 2070-1721.
Estado
No todos los RFC son estándares. 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ática; si se modifica el documento, se vuelve a enviar y se le asigna un nuevo número de RFC.
Pista de estándares
Los documentos de seguimiento de estándares se dividen a su vez en documentos Estándar propuesto y Estándar de Internet.
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 de STD pero conserva su número de RFC. La lista definitiva de Estándares de Internet son los Estándares Oficiales de Protocolo de Internet. Anteriormente, STD 1 se usaba para mantener una instantánea de la lista.
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 dado, STD n, puede ser RFC x e y en un momento dado, pero más tarde el mismo estándar puede actualizarse para ser RFC z en su lugar. Por ejemplo, en 2007, RFC 3700 era un estándar de Internet (STD 1) y en mayo de 2008 se reemplazó con 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 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 chistes del 1 de abril hasta RFC esenciales ampliamente reconocidos, como Delegación y estructura 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 una presentación individual al Editor de RFC. Un borrador se designa como 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 seguimiento de estándares si se vuelve popular y funciona bien.
Mejor práctica actual
La subserie Best Current Practice recopila documentos administrativos y otros textos que se consideran normas oficiales y no solo informativos, sino que no afectan a los datos por cable. El límite entre la pista de estándares y BCP a menudo no está claro. Si un documento solo afecta el proceso de estándares de Internet, como BCP 9 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 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 fuentes para dificultar los ataques DoS (RFC 2827: "Filtrado de entrada de red: Derrotar los ataques de denegación de servicio que emplean la suplantación de direcciones IP de origen") es BCP 38.
Histórica
(feminine)Un RFC histórico es aquel en el que ya no se recomienda el uso de la tecnología definida por el RFC, que difiere de "Obsoletos" encabezado 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 "Histórico" estado. 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 RFC 1267, se han designado como históricos.
Desconocido
Estado desconocido se utiliza para algunos RFC muy antiguos, en los que no está claro qué estado tendría el documento si se publicara hoy. Algunas de estas RFC no se publicarían hoy; un RFC temprano a menudo era 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.
Derechos de autor
La regla general es que los autores originales (o sus empleadores, si sus condiciones laborales así lo estipulan) conservan los derechos de autor a menos que hagan una transferencia explícita de sus derechos.
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. Se hace referencia a Internet Society en muchos RFC anteriores al RFC4714 como el propietario de los derechos de autor, pero transfirió sus derechos al IETF Trust.