Vous êtes sur la page 1sur 3

03/09/13

¿RFC?, sí, claro, las "Request For Comments" | manuel.cillero.es

las "Request For Comments" | manuel.cillero.es ¿RFC?, sí, claro, las "Request For Comments"

¿RFC?, sí, claro, las "Request For Comments"

Manuel Cillero

Si no te dedicas a esto de las tecnologías de la información y la comunicación o te trae al pairo el funcionamiento y de la internet ya puedes salir pitando de aquí porque no voy a escatimar en referencias para describir y contextualizar las llamadas Request For Comments, más conocidas por sus iniciales, RFC; que puede decirse que son la biblia de internet y de las que debo confesar que nunca he sabido muy bien cómo se guisan y en qué cocina se preparan.

Una definición inicial, ¿qué son las RFC?

Básicamente las RFC son documentos de especificación muy detallada y sin ambigüedades de protocolos, procedimientos y/o eventos definidos para la internet. Cada RFC tiene un número asignado, que no puede repetirse ni eliminarse aunque el documento quede obsoleto; cuanto mayor sea este número, más actualizada será la versión.

Pero empecemos por el principio

Resulta que la primera RFC tiene fecha del 7 de abril de 1969 y fue creada por Steve Crocker (foto a la derecha), por aquel

entonces estudiante de postgrado en UCLA y líder de un grupo de investigación 1 que quería intercomunicar los cuatro primeros nodos de una red de ordenadores entre UCLA (Universidad de California, Los Ángeles), UCSB (Universidad de California, Santa Bárbara), SRI (Stanford Research Institute) y la Universidad de Utah. Estamos hablando de la primigenia ARPANET. Crocker tomó la iniciativa de organizar las notas que el grupo fue generando desde sus inicios para documentar

el trabajo realizado. Según explicaba el propio Steve:

el trabajo realizado. Según explicaba el propio Steve: La mayoría de nosotros éramos estudiantes de postgrado
el trabajo realizado. Según explicaba el propio Steve: La mayoría de nosotros éramos estudiantes de postgrado
el trabajo realizado. Según explicaba el propio Steve: La mayoría de nosotros éramos estudiantes de postgrado
el trabajo realizado. Según explicaba el propio Steve: La mayoría de nosotros éramos estudiantes de postgrado

La mayoría de nosotros éramos estudiantes de postgrado y esperábamos que en cualquier momento vendría un grupo

de profesionales para hacerse cargo y resolver los problemas que estábamos tratando. 2

Más o menos creían que aquellos trabajos algún día pasarían a ser liderados por otras personas, pero no fue así y al final Crocker se admiraba de que:

cualquiera podía decir lo que quisiera y que nada sería oficial. Para dejar esto muy claro denominé las notas como 'Solicitud de Comentarios' (Request for Comments, RFC). Jamás soñé que esas notas serían distribuidas a través del mismo medio del que hablábamos en

ellas. 2

a través del mismo medio del que hablábamos en ellas. 2 A comienzos de 1970 sería

A comienzos de 1970 sería un alumno amigo de Crocker llamado Jon Postel (foto a la izquierda), y a la postre otro de los

padres de internet 3 , quien se encargaría de recopilar, copiar, distribuir y archivar todas las RFC desde el que llamarían

Centro de Información de la Red, Network Information Center ó NIC 4 , en el SRI, convirtiéndose en el editor oficial de RFC's durante veinticinco años y el autor más prolífico ya que escribió o participó en más de 200 RFC's, algunas de ellas claves para la actual internet como los protocolos IP (RFC 791), ICMP (RFC 792) y TCP (RFC 793); o definiendo las instrucciones para otros autores de RFC's (RFC 2223).

para otros autores de RFC 's ( RFC 2223 ). El caso es que estos documentos

El caso es que estos documentos empezaron como un mecanismo informal para compartir ideas con otros investigadores

de tal manera que las propuestas presentadas en una RFC impulsaran otra RFC con nuevas ideas y así sucesivamente hasta llegar por consenso a una especificación definitiva para su implementación. Ahora nos sorprende, pero resulta evidente que al principio las RFC, redactadas en texto plano ASCII, tenían que imprimirse y distribuirse por correo ordinario. En el momento que empezó a usarse el protocolo FTP para la transferencia de ficheros fue cuando las RFC comenzaron a difundirse a través de la red.

las RFC comenzaron a difundirse a través de la red. Y así han llegado a convertirse

Y así han llegado a convertirse en los únicos documentos oficiales dentro de la comunidad de estándares en Internet,

aunque ningún funcionario ni organismo les ha dado jamás el visto bueno para ser tal cosa.

¿Y en la actualidad qué pasa con las RFC?

Pues ahora las RFC son publicadas, adoptadas y reguladas como estándares de internet por IETF (Internet Engineering Task Force 5 , algo así

como Grupo Especial sobre Ingeniería de Internet), organización internacional sin ánimo de lucro creada en 1986 -celebró su 25 aniversarion en enero-

y conocida por su carácter abierto ya que cualquier persona puede ser miembro a título personal. Se estructura en grupos de trabajo con técnicos en

redes, investigadores, diseñadores de red, administradores, vendedores y profesionales que velan por el buen funcionamiento de la arquitectura de

Internet y los protocolos que la conforman.

03/09/13

¿RFC?, sí, claro, las "Request For Comments" | manuel.cillero.es

Por tanto, cualquiera puede contribuir con nuevas RFC a la IETF siempre que se cumplan las reglas expuestas en RFC 5378 y RFC 3979 (actualizada

por RFC 4879). Todas las RFC, incluyendo las que describen estándares de internet, son propiedad de ISOC 6 , acrónimo de Internet Society, aunque están disponibles libremente y sin coste para todo el mundo.

Actualmente el sitio oficial para buscar cualquier RFC es http://www.rfc-editor.org 7 , cuyo diseño parece no haber cambiado desde su versión para Mosaic.

Buenas prácticas y otros tipos de RFC's

Las RFC de buenas prácticas, o Best Current Practices, son un subconjunto importante entre todas las RFC, hasta el punto de que tienen su propia numeración interna, BCPXXXdonde XXXes un número secuencial que no se repite.

Por ejemplo, en la RFC 2026, de octubre de 1996, actualizada por la relativamente reciente RFC 5657, de septiembre de 2009, y agrupadas ambas por el identificador BCP9, se detallan un conjunto de buenas prácticas para la estandarización de protocolos y procedimientos, incluyendo una serie de estados para indicar el grado de madurez de una RFC, que para las que serán estándares de internet son:

"PROPOSED STANDARD", ó "PROPUESTA"; estado de las RFC que están siendo consideradas para ser un futuro estandar.

"DRAFT STANDARD", ó "BORRADOR"; en este estado se está considerando seriamente adoptar el estándar y sólo se modificarán aspectos que solucionen defectos del estándar propuesto.

"INTERNET STANDARD", ó "ESTÁNDAR"; aquellas RFC que oficialmente se convierten en estándar de internet. Se podría hablar de dos categorías, aquellas que se aplicarán a toda la internet y las que sólo afectan a ciertas redes.

Las RFC de estándares tienen también su propia numeración interna, STDXXXdonde XXXes el correspondiente secuencial que no se repite. El STD1contiene la lista actual completa de los protocolos oficiales de internet, que ahora se corresponde con la RFC 5000, de mayo de 2008, que dejó obsoleta la 3700, que a su vez dejó obsoleta la 3600 hasta la 1083 que incluyó el primer listado oficial de protocolos.

Las categorías para las RFC que no definen estándares de la internet son:

"EXPERIMENTAL"; aquellas usadas para pruebas de investigación.

"INFORMATIONAL", ó "INFORMATIVA"; con información general para la comunidad. Algunas incluso se han preparado fuera de la comunidad y no se incorporan al proceso de normalización. Algunas RFC en esta categoría son simplemente bromas (ver más abajo).

"HISTORIC", ó "HISTÓRICA"; son las que han sido reemplazadas por versiones más nuevas y han quedado obsoletas. También pueden ser aquellas que no han recibido suficiente apoyo o han tenido poco interés.

Hay un tercer subconjunto entre las RFC que se nombran como FYIXXX, ya sabes, XXXes un secuencial; que son documentos creados For Your Information, más exactamente vienen a ser RFC's que destacan por su especial interés para los usuarios de internet. Estas RFC deben tener el estado "INFORMATIONAL". Por ejemplo, FYI20es la RFC 1462 donde se explica nada menos qué es internet.

¿Algún detalle más de las RFC?

Pues en la RFC 2119, de marzo del 97, se describen una serie de palabras clave que suelen aparecer en mayúsculas al principio de muchas RFC para indicar ciertos niveles en la aplicación de los requerimientos del documento:

"MUST" ("DEBE"), esta palabra, o los términos "REQUIRED" ("OBLIGATORIO") o "SHALL" ("DEBERÁ") indicarán que un requerimiento de la especificación es absolutamente imprescindible.

"MUST NOT" ("NO DEBE"), o la frase "SHALL NOT" ("NO DEBERÁ") indicarán una prohibición absoluta en la especificación.

"SHOULD" ("DEBERÍA"), o "RECOMMENDED" ("RECOMENDADO") significan que en determinadas circunstancias y conociendo las implicaciones, se pueden ignorar parte de las especificaciones.

"SHOULD NOT" ("NO DEBERÍA"), o la frase "NOT RECOMMENDED" ("NO RECOMENDADO") indicarán que en determinadas circunstancias y conociendo las implicaciones, puede ser útil aplicar ciertas especificaciones aunque no deba hacerse.

"MAY" ("PUEDE"), o la palabra "OPTIONAL" ("OPCIONAL") indicará un elemento que podrá aplicarse opcionalmente a elección del proveedor, por ejemplo porque sienta que un mercado en particular lo necesite o porque crea que mejora el producto.

Estos términos se usan normalmente en especificaciones con implicaciones de seguridad, y recomiendan ser usados con cuidado y mesura; por ejemplo no deberían utilizarse para intentar imponer un método concreto a los implementadores a no ser que la interoperabilidad (palabra que comercialmente está ahora muy de moda) lo requiera.

Sentido del humor de los científicos de la red

Algunas RFC son simple y llanamente bromas, inocentadas o memorándums jocosos que se añaden a la biblioteca de RFC's por puro entretenimiento. A mí me ha hecho especial gracia la RFC 3751, de abril de 2004, editada por Scott Bradner de la Universidad de Harvard, que analiza los requerimientos para un ¡¿protocolo omnisciente?! capaz de resolver las carencias que actualmente tiene la red para interferir activamente en las actividades que puedan catalogarse como ilegales de los usuarios de la red.

Fuentes y referencias

Bueno, pues ahora ya sé kung fu, perdón, ya sé bastante sobre RFC's como para darme por satisfecho. Pero si tú quieres profundizar más puedes empezar por donde yo:

03/09/13

¿RFC?, sí, claro, las "Request For Comments" | manuel.cillero.es

Sobre mí

Hola, mi nombre es Manuel Cillero y trabajo en esto que ahora llaman tecnologías de la información y la comunicación. Actualmente soy el responsable del servicio de informática del Centro Regional de Transfusión Sanguínea de Granada y Almería.

Este sitio es un espacio abierto para todos los que compartan mis inquietudes y aficiones; es mi circunstancia digital y si no la salvo a ella no me salvo yo—.

Suscríbete

Uso

Cuando no se indique una licencia de uso específica, los contenidos creados por Manuel Cillero en manuel.cillero.es estarán bajo Licencia Creative Commons.

estarán bajo Licencia Creative Commons .