La Gaceta de Linux ...¡ haciendo a Linux un poco más divertido !

Sobre los RFC

Por Amber Pawar

Traducción al español por Jorge Paredes
el día 8 de Octubre de 2005, para La Gaceta de Linux

Introducción

Cualquiera que estudie a la Internet o a las "Redes de Computadoras" en general se topará con algunos de los RFCs, los cuales describen los protocolos y estándares de las redes. Muchos piensan que los RFC's estan entre los documentos más aburridos que se pueda leer. Conozco incluso una persona que usa los RFC's como un sustituto de las pastillas para dormir.

Este artículo es un intento por cambiar esa imagen de aburrimiento mortal asociada a los RFC's. En este artículo doy una breve definición de lo que es un RFC, a la cual sigue una clasificación informal. En la sección siguiente, la principal, vierto mis comentarios sobre algunos de los más interesantes RFCs que he encontrado. En ese punto notarán, amigos lectores, que este artículo trata sobre el lado más ligero de los RFCs.

Qué es un RFC?

Los RFCs (un acrónimo de "Request For Comments", petición de comentarios) son las notas de trabajo de la comunidad científica y de desarrollo de la Internet. Contienen descripciones de protocolos, sistemas y procedimientos para la Internet, o simplemente revisiones, experimentos o información sobre algún tópico. Todos los estándares de la Internet están descritos en detalle en RFCs.

Los RFC son una serie de documentos, cada uno identificado con un número único. El primer RFC fue escrito en 1969. En la actualidad sobrepasan los 3800, y este número sigue creciendo. Un RFC es para siempre. Una vez publicado, un RFC no puede ser cambiado o modificado en forma alguna. Si hay algún error en el RFC, entonces se publica una revisión del RFC que anula al primero

Un RFC puede ser enviado por cualquiera. Eventualmente, si concita el interés suficiente, podría llegar a convertirse en un estándar.

El sitio donde se pueden leer todos los RFCs es: http://www.ietf.org/rfc.html

Categorías

Basándose en su contenido, los RFCs pueden ser clasificados en las siguientes categorías:

1. Estándares, estándares preliminares, estándares propuestos (conocidos en conjunto como STD)

Estos documentos detallan un estándar de Internet o una especificación preliminar de éste. Aquí están incluidos los estándares oficiales de los protocolos de Internet definidos por la IETF (Internet Engineering Task Force, organización encargada del desarrollo y promoción de los estándares de Internet)

2. Mejores prácticas actuales (BCP, Best Current Practices)

Estos documentos describen las mejores prácticas actuales a seguir por la comunidad de la internet. Se trata de lineamientos y recomendaciones, mas no estándares, propuestos por la IETF.

3. Informativos (FYI, For your information, "para su información")

Los RFCs informativos o documentos FYUs son RFCs de interés particularmente para los usuarios de Internet.

4. Históricos

Fueron alguna vez considerados estándares, lo que propusieron actualmente se considera no recomendado u obsoleto.

5. RFCs de 1ero. de Abril

Desde 1978,cada 1ero de Abril ("Día de los tontos", el equivalente a nuestro Día de los Santos inocentes), se publican RFCs muy poco usuales. Estos documentos están entre los más interesantes. Se trata de documentos muy jocosos, algunas veces escritos en un estilo formal que hace difícil diferenciarlos de los RFC "serios". En la siguiente sección describiré brevemente algunos de estos RFC.

Algunos de los más interesantes RFCs

Aquí describo brevemente algunos de los RFCs más interesantes que he podido descubrir. Incluyo poesías, hechos, recomendaciones, y RFCs típicos de 1ro de Abril.

RFC 3092 - Etimología de la palabra "Foo"

Muchos de nosotros hemos usado "foo", "bar", y "foobar" para designar cualquier cosa (o más bien nada) sin ponernos a pensar de donde vienen estos términos. Mucho de los trozos de código que vemos tienen nombres de archivo o funciones llamadas foo, bar o foobar. Más de 200 RFCs han usado estos términos sin definirlas de forma alguna.

Una mirada al RFC 3092 nos revela la etimología de "foo". Este RFC da media docena de definiciones de "foo". También da varias pistas sobre el origen de la palabra "foobar", incluyendo algunas tiras cómicas además. Revela que los orígenes de "foobar" posiblemente se remontan a la jerga castrense en la época de la 2da Guerra Mundial, "FUBAR", que según parece se deriva de la palabra alemana furchtbar ("terrible").

RFC 1178 – Eligiendo un nombre para su ordenador

Así como lo lee, este RFC da algunos consejos sobre el mejor nombre para su ordenador, aunque no es exactamente como aquellos libros que tratan sobre elegir los mejores nombres para nuestros niños. Este RFC describe en detalle qué es lo que hace a un nombre bueno o malo, y qué se debe tomar en cuenta antes de ponerle un nombre a su ordenador. Se incluyen consejos sobre la apropiada longitud y el mejor deletreo para el nombre. Este RFC es relamente divertido. La línea que se me ha quedado grabada es la que está precisamente antes de la conclusión: "Podría seguir con esto pero sería más fácil olvidar que existe esta recomendación" (se refiere a una en particular, no a todo el artículo)

RFC 1149 - Standard para la transmision de datagramas IP a través de canales "alados"

Este RFC describe el estándar para la transmisión de datos a través de canales alados, también conocidos como pájaros (palomas para ser más específicos), aunque el documento en ningún momento usa las palabras "pájaro" o "paloma". Este RFC describe muy formalmente todo el proceso, desde imprimir los datos a papel, pasando por fijar el papel a la pata del pájaro con cinta adhesiva, hasta despegar el papel en el extremo receptor. Se menciona también que este canal tiene incorporado un sistema anti-colisiones. Leer este RFC es aconsejable si se quiere saber hasta qué límites puede llegar el pensamiento de la gente.

RFC 2549 - Transmisión de datagramas IP a través de canales alados con "Quality of Service"

Este RFC refina el anterior. Es mucho más técnico también. Va un paso más allá y explica cómo la calidad de la transmisión depende del canal usado. Se sugiere el uso de avestruces para grandes transmisiones de datos, que sin embargo tienen la limitación de que necesitan un puente (NT: juego de palabras relacionado con puente de red, "network bridge") real entre los dominios. Valiéndose sólo de caracteres ASCII, sugiere con un gráfico que incluso se podría implementar encolamiento ponderado de canales. Este RFC incluso llega a definir su propio MIB (NT: "management information base", un tipo de base de datos usada para administrar los dispositivos en una red de comunicaciones).

RFC 3514 - El flag de seguridad en las cabeceras IPv4

Este es otro RFC de 1ero de Abril. Aquí se define un flag de seguridad, comocido como bit "maligno" en las cabeceras IPv4. Este bit se debería usar para distinguir los paquetes "buenos" de aquellos "mal intencionados". Este RFC estipula que los programas deberían poner este bit a 1 cuando el paquete tiene un fin "malévolo", y en cualquier otro caso lo deberían poner a 0.

RFC 1605 - Traducción de SONET a SONNET

Este RFC revela algunos aspectos literarios de la tecnología de transmisión de datos. Habla sobre la traducción de paquetes SONET (Synchronous Optical NETwork, red óptica síncrona) a paquetes SONNET (SONET Over Novel English Translation, SONET traducido a inglés nuevo). Este RFC explica como se puede traducir frames SONET OC1 de 9x90 bytes a sonetos ingleses de catorce versos decasílabos. Coincidentemente, el nombre del autor coincide con el de uno de los literatos más leídos de la historia, William Shakespeare.

RFC 2550 - Y10K y más allá

Todos sabemos del problema del Y2K, que mantuvo ocupados a los programadores en COBOL por mucho tiempo. El problema del año 2000 fue causado por la poca visión de futuro de los programadores, que escribieron programas que fallarían en el año 2000. Los arreglos que se hicieron en los programas para solucionar el problema tienen el mismo defecto intrínseco: Fallarán esta vez en el año 10 000. Este RFC propone una solución al problema del Y10K. Y10K es conocido también como problema del "YAK", ya que el equivalente en hexadecimal para 10 es A, o del "YXK", de acuerdo a la notación romana para 10 (X).

RFC 1925 - Las 12 verdades de las redes

Si Ud. cree que sabe mucho (o tal vez todo) sobre redes, entonces tal vez le gustaría verificarlo con estas 12 verdades, las cuales me parecen muy esclarecedoras, muy en especial la que habla sobre los cerdos voladores.

A algunos les parecerá que el corolario de la verdad número 2 y la verdad número 3 son un tanto contradictorias. Pero, si se lee con cuidado, se notará que la verdad 2 tiene que ver con tiempo y velocidad, mientras que la verdad número 3 no tiene nada que ver. Si no entiende de lo que estoy hablando, pues lea el RFC 1925.

POEMAS

Hay varios RFC que revelan el lado literario de la computación. Los siguientes cuatro son un ejemplo.

RFC 1121 - Acto uno - los poemas

Ésta es una colección de poemas que fueron presentados en el "Acto uno", un simposio organizado en parte para celebrar el aniversario 20 de ARPANET. Mi favorito es el titulado "EL BIG BANG (o el nacimiento de ARPANET)", por Leonard Kleinrock.

RFC 968 - Fue la noche antes del arranque

Este bello poema de Vint Cerf, publicado en 1985, expone los peligros que representa el error de indexación en programación (referenciar un índice no válido por márgen de uno). Discute los problemas que podrían surgir y la técnica de depuración usada para que la red vuelva a estar operativa.

RFC 1882 - Los 12 días de tecnología antes de navidad

Ud. debe recordar la canción navideña "Los 12 días de la navidad". Nuestros tecnófilos amigos han lanzado una versión nueva y mejorada. La llaman "Los 12 Días de Tecnología Antes de Navidad", así que no se quede atrás y actualícese con esta nueva versión leyendo este RFC.

RFC 1300 - Remembranzas del pasado

Un trabajo brillante de Stanley R. Greenfield. Hay muchas palabras que solemos usar en el mundo de la computación, sin ponernos a pensar en su origen. Este RFC trata precisamente sobre este aspecto. Palabras como bus, red, puerto, puente y menú, las cuales se han asociado a la computación, pero que para la gente fuera de ese mundo evocan cosas muy distintas.

¿Y cómo puedo publicar un RFC?

Cualquiera puede enviar un RFC, pero antes de ser publicado como RFC en sí, Ud. debe publicarlo como un I-D (Internet Draft,borrador de internet). El I-D luego estará disponible para revision y comentarios en el directorio de I-Ds de la IETF, el cual es accesible también a través de otros hosts. Tal vez quiera consultar el RFC 2223, "Instrucciones para los autores de RFCs"

¿Cómo puedo publicar un RFC de 1ero de Abril?

Los RFCs de primero de Abril son los únicos que no requieren ser publicados antes como I-D. Se debe enviar el RFC directamente en la página de edición de RFCs http://www.rfc-editor.org. Si los encargados lo encuentran interesante, lo publicarán como un RFC en 1ero de Abril.

Otros RFCs interesantes

En este artículo he descrito brevemente algunos de los RFC interesantes que he encontrado. Hay muchos más, por supuesto. Cuando de verdad esté dispuesto a leerlos, encontrará que la mayoría son muy vivaces e interesantes. Adelante, léalos y aprenda algo sobre los protocolos, mejores prácticas, revisiones, experimentos e información sobre algún tema ¿No se supone que para eso son los RFCs?

Finalmente, les dejo una lista de algunos otros RFCs que encontré interesantes.

RFC 602 - Los calcetines fueron colgados con cuidado sobre la chimenea
RFC 1217 - Memorándum del consorcio para la investigación de la lenta conmoción
RFC 1313 - La programación de hoy en KRFC 1313 AM, "Internet Talk Radio"
RFC 1402 - ¡Hay oro allá en las redes! o buscando tesoros en lugares equivocados
RFC 1438 - Soporíferos documentos de la IETF
RFC 1606 - Una perspectiva histórica del uso de IP version 9
RFC 1607 - UNA MIRADA DESDE EL SIGLO XXI
RFC 1776 - La dirección es el mensaje.
RFC 1924 - Una representación compacta de las direcciones IPv6
RFC 2322 - Administración de las direcciones IP vía ganchos para ropa + DHCP
RFC 2324 - Protocolo de hipertexto para el control de cafeteras (HTCPCP/1.0)
RFC 2325 - Definiciones de objetos administrados para dispositivos hardware para goteo de líquidos calientes (NT: Léase, Cafeteras) usando SMIv2
RFC 2795 - La suite de protocolos "mono infinito"
RFC 3251 - Electricidad vía IP

 


"[BIO]" Amber Pawar es un ingeniero de software trabajando en una trasnacional. Es un ex- alumno del 'Centro Nacional para Tecnología de Software' (National Center for Software Technology, NCST). Le gusta leer y escuchar todo tipo de música, excepto el que él denomina "ruido". Algo que extraña es la comida hecha en casa. Sus intereses incluyen Linux, L10N y estructuras de datos.


Copyright © 2004, Amber Pawar. Publicado bajo los términos de la Open Publication license

Publicado en el número 106 de Linux Gazette, Septiembre del 2004