Para saber más acerca de una parte fundamental de Internet como lo es la familia de protocolos TCP/IP existen documentos que explican a detalle las funcionalidades de cada uno de ellos. Estos documentos se conocen como RFCs (Requests For Comments).
Los RFCs son una colección de borradores y textos que abarcan desde documentos de interés general hasta detalladas especificaciones de los protocolos estándares como HTTP, FTP o NNTP, etc.
Para que un documento propuesto sea publicado como una especificación estándar necesita ser aprobado por e
l IESG (Internet Engineering Steering Group https://www.ietf.org/iesg/) del IETF (Internet Engineering Task Force https://www.ietf.org/).
Una cosa importante: todos los estándares de Internet son RFCs pero no todos los RFCs son estándares.
¿Cómo se desarrolla un estándar RFC?
Todos los estándares RFCs propuestos comienzan cuando una persona o un grupo tiene una propuesta y construye un prototipo. Si este prototipo funciona y se vuele popular más allá del grupo que lo desarrolló. La IETF forma un grupo de evaluación de la propuesta para documentar el protocolo en un borrador de Internet (Internet Draft) este borrador es modificado frecuentemente hasta que la propuesta llegue a una madurez técnica aceptable.
El proceso de creación de un RFC no es rápido, ya que el proceso es rígido y normalizado por lo que se tienen demoras considerables. Este proceso es delicado, ya que la IETF debe moldear la especificación para que funcione en Internet sin tener conflicto con los protocolos que ya están funcionando.
Claro que en este proceso hay excepciones, como por ejemplo: el protocolo HTTP que en 1996 no había alcanzado el status experimental pero como al IESG le gusto tanto que le asignó de inmediato un número RFC y lo publicó como un RFC experimental después de algunos cambios.
Existen también aspectos jurídicos que es necesario considerar. Muchos borradores contienen algoritmos y tecnologías que podrían tener una patente o una protección de copyright.
El proceso para convertir un borrador en un RFC consta de los siguientes pasos:
1-. Diseñar y organizar el borrador.
Cualquiera puede redactar una propuesta y enviarla para un análisis. En ocasiones puede ser una empresa que envía un documento que se convierte en borrador para volverse un RFC, pero son los grupos de trabajo de la IETF los que inician la mayoría de borradores.
2-. Analizar el borrador.
El IESG analiza el borrador presentado para decidir si merece un análisis técnico. En algunos casos, el EISG crea un grupo técnico para analizar el documento por si el estándar propuesto pudiera afectar el funcionamiento de Internet. Este grupo analiza técnicamente el borrador y evaluá sus efectos sobre la configuración de Internet ya establecida.
3-. Publicar el borrador.
Una vez concedida la aprobación inicial, el IESG autoriza la publicación del documento como estándar propuesto para toda la comunidad. Los borradores tienen una validez de seis meses. Durante este periodo el grupo puede modificar, reemplazar o incluso eliminar el borrador ya que los borradores carecen de status oficial.
4-. Revisar el borrador.
A medida que la gente estudia y comenta el borrador su contenido se modifica. En este periodo, el IESG y la comunidad de Internet evaluá los cambios y el impacto de la propuesta. Si los efectos son muy drásticos entonces el IESG podría ampliar el periodo de evaluación o bien devolverlo al principio del proceso de evaluación de estándares. Estas idas y vueltas provocan que algunos documentos tarden años o meses de retraso para recorren el proceso RFC.
5-. Conseguir la aceptación del borrador
Una vez que el borrador paso el periodo de análisis y si la IETF decide aprobar el borrador entonces este se convierte en un RFC. La RFC se dirige al editor del RFC y con autorización de la ISOC (Internet Society http://www.internetsociety.org/) para que el editor del RFC publique las RFC y es el responsable del último análisis de los documentos. Una vez aceptado se le asigna un número de STD y se convierte en un RFC STD. Cuando se publica una nueva versión de un RFC, la anterior recibe la categoría de Obsolete.
El éxito de un RFC dependerá que tan bien ese estándar funcione en la presencia de vendedores, inversores capitalistas y entusiastas que buscan tecnologías particulares para sus proyectos.
Además del proceso de desarrollo, un RFC tiene un requerimiento de nivel. Los posibles requerimientos de nivel son:
Required: los RFCs de esta categoría deben estar en todas las máquinas de Internet. Hay muy pocos protocolos en esta categoría. IP (RFC 791) por ejemplo es uno, incluso protocolos importantes como TCP o UDP están en la categoría recommend. Los protocolos que están en categoría son axiales para el funcionamiento de las máquinas en Internet.
Recommended: estos RFCs deben ser implementados por todos los los hosts de Internet que no tengan una razón para no implementarlo. RFCs por ejemplo: como TCP,UDP ,SMTP, Telnet, etc. Están en esta categoría.
Elective: estos RFCs pueden estar implementados por decisión propia para quien desee usar el protocolo. Por ejemplo: el del protocolo MIME ( RFC 1521) tiene este estatus.
Limited Use: estos RFCs deberían ser implementados en ciertas situaciones especiales, que no es indispensable para la mayoría de hosts.
Not recommended: los RFCs de esta categoría no deben ser utilizados por nadie.
Historic: un status para identificar RFCs que están clasificados como obsoletos.
Informational: en esta categoría hay dos grupos de RFC: El primer grupo define protocolos que están ampliamente utilizados pero no fueron desarrollados dentro del conjunto normal de pasos de un estándar de Internet y no han estado dentro del proceso formal de estandarización. Un buen ejemplo de esto es el Network File System (NFS) de Sun que está descrito en el RFC 1813. El segundo grupo de RFCs proporciona información como manuales de usuario pero no documenta un protocolo.
Enlaces:
