El Tao de IETF: Una guía sobre la IETF para principiantes

Paul Hoffman, Editor


About This Document

Copyright © 2013 IETF Trust. All rights reserved.

The current version of this web page can always be found at http://www.ietf.org/tao.html; that page can also be retrieved protected by TLS. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2013-07-22.

Este sitio Web está en Español. Existe una lista de las traducciones del Tao de la IETF.


1. Introducción

Desde sus inicios, la participación en las reuniones presenciales del Internet Engineering Task Force (IETF) ha crecido sobremanera. Entre quienes participan por primera vez, muchos se convierten en asistentes habituales. Cuando las reuniones eran más pequeñas, resultaba relativamente fácil para un recién llegado saber lo que estaba pasando. Sin embargo, hoy en día los recién llegados se encuentran con mucha más gente nueva, entre ellos personas a quienes previamente solo conocían por ser los autores de documentos o por sus incisivos correos electrónicos.

Este documento detalla muchos aspectos del IETF, con el objetivo de explicar a los recién llegados cómo funciona. Leerlo les dará tranquilidad y les permitirá sacar el máximo partido de la reunión y de las discusiones de los Grupos de Trabajo para que sean más productivas para todos. Este documento empezó siendo bastante breve, pero luego fue ampliándose en respuesta a las sugerencias de los recién llegados sobre lo que hubieran querido saber antes de asistir a su primera reunión presencial o antes de participar activamente en su primer Grupo de Trabajo.

Muchos participantes del IETF no asisten a las reuniones presenciales, sino que participan activamente en las listas de correo de varios Grupos de Trabajo. Entender el funcionamiento interno de los Grupos de Trabajo puede resultar complejo y es por ello que este documento ofrece información útil que los recién llegados necesitarán para convertirse en participantes activos.

El IETF se encuentra en un estado de permanente cambio. Aunque las bases de este documento seguirán siendo las mismas, con el tiempo los detalles prácticos pueden cambiar. Por ejemplo, una herramienta web podría haber reemplazado a una dirección de correo electrónico para pedir algún tipo de acción.

En el Tao se mencionan muchos tipos de documentos, desde BCP a RFC y STD. BCP (Best Current Practices) se refiere a mejores prácticas recomendadas en Internet; las RFC (Requests for Comments o Peticiones de Comentarios) son la principal documentación técnica del IETF; y las STD son las RFC identificadas como “estándares”. En estos momentos, los tres tipos de documentos se consideran RFC; consulteSection 6 para obtener más información.

Esta página web es una continuación de la serie de RFC titulada “Tao del IETF”. Consulte[RFC6722] para obtener una explicación sobre cómo la última RFC de la serie se convirtió en esta página web. Esta versión web del Tao se basa en[RFC4677], Susan Harris fue su coautora. La versión original de este documento se publicó en 1994 y fue escrita por Gary Malkin.

¿Pero por qué “Tao”? La palabrra Tao se pronuncia “dao” y se refiere al principio básico subyacente en las enseñanzas de Lao-tse, un maestro chino. Su símbolo familiar es el círculo ying-yang de color blanco y negro. El taoísmo concibe el mundo como un solo organismo y al ser humano como una parte interdependiente de un todo cósmico. Algunas veces Tao se traduce como “el camino”, pero según la filosofía taoísta su verdadero significado no se puede expresar en palabras.

1.1 Abreviaturas y acrónimos utilizados en el Tao

Algunos acrónimos y abreviaturas de este documento se incluyen en la lista siguiente.

Término Significado
AD Area Director – Director de Área
BCP Best Current Practices – Mejores Prácticas Actuales
BOF Birds Of a Feather – Grupo de debate informal
FAQ Frequently Asked Questions – Preguntas frecuentes
FYI For Your Information – Para su información
IAB Internet Architecture Board – Consejo de Arquitectura de Internet
IAD IETF Administrative Director – Director Administrativo del IETF
IANA Internet Assigned Numbers Authority – Autoridad para la Asignación de Números de Internet
IAOC IETF Administrative Oversight Committee – Comité de Supervisión Administrativa del IETF
IASA IETF Administrative Support Activity – Actividad de Apoyo Administrativo del IETF
ICANN Internet Corporation for Assigned Names and Numbers – Corporación de Internet para la Asignación de Nombres y Números
I-D Internet-Draft – Borrador de Internet
IESG Internet Engineering Steering Group – Grupo Directivo de Ingeniería de Internet
IETF Internet Engineering Task Force – Grupo de Trabajo de Ingeniería de Internet
IPR Intellectual property rights – Derechos de propiedad intelectual
IRTF Internet Research Task Force – Grupo de Trabajo de Investigación de Internet
ISOC Internet Society
RFC Request for Comments – Petición de comentarios
STD Standard – Estándar (RFC)
WG Working Group – Grupo de Trabajo

2. ¿Qué es el IETF?

El IETF es un grupo de personas con una organización informal que contribuye a la ingeniería y evolución de las tecnologías de Internet. Es el principal organismo comprometido con el desarrollo de nuevas especificaciones sobre estándares de Internet. El IETF es una organización atípica, ya que existe como una recopilación de sucesos pero no es una corporación, no tiene consejo directivo, ni miembros, ni tasas; consulte [BCP95], "Declaración de intenciones del IETF”, para obtener más información.

Su misión incluye lo siguiente:

Una reunión del IETF no es una conferencia, aunque hay presentaciones técnicas. El IETF no es una organización de normalización tradicional, aunque muchas de las especificaciones que se producen se convierten en estándares. El IETF está formado por voluntarios, muchos de los cuales se reúnen tres veces al año para cumplir la misión del IETF.

No hay membresía en el IETF. Cualquier persona puede registrarse para una reunión y asistir. Lo más cercano que existe a ser un miembro del IETF es pertenecer a las listas de correo de los Grupos de Trabajo (consulte Section 2.3). Aquí es donde encontrará la mejor información acerca de las actividades actuales y el enfoque del IETF.

Está claro que ninguna organización puede tener tanto éxito como el IETF sin tener algún tipo de estructura. En el caso del IETF, la estructura la proporcionan otras organizaciones, como se describe en [BCP11], "Las organizaciones que participan en el proceso de creación de estándares del IETF". Si participa en el IETF y solo tiene tiempo para leer una BCP, éste es el que debería leer.

El sitio web del IETF http://www.ietf.org, es la mejor fuente de información sobre reuniones, Grupos de Trabajo, Internet Drafts, RFC, direcciones de correo del IETF y mucho más.

De hecho, el IETF funciona sobre la base de las creencias de sus participantes. Una de las "creencias fundacionales” se ve reflejada en esta cita sobre el IETF de David Clark: "Rechazamos reyes, presidentes y votaciones. Creemos en el consenso general y en el código que funciona". Otra cita, sobre el IETF que también se ha convertido en una creencia común fue pronunciada por Jon Postel: “Sé conservador en lo que envías y liberal en lo que aceptas".

Para el IETF lo importante son los participantes. Como las puertas del IETF están abiertas a todas las personas interesadas, los participantes del IETF provienen de todo el mundo y de diferentes sectores de la industria de Internet. El IETF realiza su trabajo exclusivamente en inglés. Consulte Section 3.12 para obtener más información sobre cómo encaja tanta gente en el IETF.

Hay una cosa más que resulta importante para quienes recién comienzan a participar: a pesar de lo que algunos comentan erróneamente, el IETF no “dirige Internet” de manera alguna. El IETF crea estándares voluntarios que a menudo adoptan los usuarios de Internet, pero no controla Internet y ni siquiera la patrulla. Si su interés en el IETF es motivado por su deseo de formar parte de un grupo de supervisores, se verá profundamente decepcionado.

2.1 Comienzos Humildes

La primera reunión del IETF se celebró en enero de 1986 en Linkabit (San Diego) con 21 asistentes. La 4ª reunión del IETF, que se celebró en SRI (Menlo Park) en octubre de 1986, fue la primera reunión a la que asistieron vendedores. El concepto de Grupos de Trabajo se introdujo en la 5ª reunión del IETF, realizada en el Centro de investigación Ames de la NASA (California) en febrero de 1987. La 7ª IETF, que tuvo lugar en MITRE, McLean (Virginia), en julio de 1987 fue la primera reunión con más de 100 asistentes.

La 14ª reunión deL IETF se celebró en la universidad de Stanford en julio de 1989. Esta reunión marcó un gran cambio en la estructura del universo del IETF. Se modificó la estructura del IAB (Internet Activities Board, ahora conocido como Internet Architecture Board), que hasta ese momento supervisaba muchos “grupos de trabajo”, dejándole solo dos: el IETF y el IRTF. El IRTF tiene como objetivo considerar los problemas de investigación a largo plazo relacionados con Internet. El IETF también cambió en esa reunión.

Después de la creación de Internet Society (ISOC) en 1992, el IAB propuso a ISOC que las actividades del IAB se llevaran a cabo bajo los auspicios de Internet Society. Durante el INET 92 de Kobe (Japón), los directores de ISOC aprobaron un nuevo estatuto para el IAB que reflejaba la relación propuesta.

En julio de 1993 el IETF se reunió en Ámsterdam (Países Bajos). Esta fue la primera reunión que se celebró en Europa, y la proporción entre asistentes estadounidenses y no estadounidense fue de casi 50/50. El IETF se reunió por primera vez en Asia (en Adelaida, Australia) en 2000.

Actualmente, el IETF se reúne en Norteamérica, Europa y Asia. Su intención es reunirse una vez al año en cada región, aunque debido a problemas de programación, suele haber más reuniones en Norteamérica y menos en Asia y Europa. El número de asistentes no estadounidenses sigue siendo elevado — cerca del 50%, incluso en las reuniones que se celebran en Estados Unidos.

2.2 La Jerarquía

2.2.1 ISOC (Internet Society)

Internet Society es una organización internacional sin ánimo de lucro basada en membresía que fomenta la expansión de Internet. Una de las formas con las que cuenta ISOC para conseguirlo es ofreciendo apoyo financiero y legal a otros grupos “I” descritos aquí, en particular el IETF. ISOC ofrece cobertura para muchas personas que ostentan puestos de liderazgo en el IETF y actúa como canal de relaciones públicas cuando uno de los grupos “I” desea comunicar algo a la prensa. ISOC es uno de los principales héroes desconocidos de Internet.

A partir de la primavera de 2005, ISOC se convirtió en la sede del personal administrativo contratado directamente por el IETF. Esto se describe con más detalle en [BCP101], "Estructura de la Actividad de Apoyo Administrativo del IETF (IASA)". Los empleados, en principio, incluyen solo un Director Administrativo (IAD) que trabaja a tiempo completo supervisando la planificación de las reuniones del IETF, aspectos operativos de los servicios de apoyo (la secretaría, IANA (Autoridad para la Asignación de Números de Internet) y el Editor de RFC , puestos que se describen más adelante en esta misma Sección), y el presupuesto. La persona (en estos momentos un hombre) que lidera la Actividad de Apoyo Administrativo del IETF (IASA) se encarga de tareas tales como cobrar las tasas de inscripción a las reuniones y pagar facturas, también se encarga de las herramientas para el trabajo que desarrollan los grupos de trabajo del IETF, el IESG, el IAB y el IRTF (más información sobre ello más adelante en esta misma sección).

El Comité de Supervisión Administrativa (IAOC) del IETF está formado por voluntarios, todos ellos elegidos directa o indirectamente por la comunidad del IETF, además de miembros ex oficio de ISOC y el IETF. La IASA y el IAD son dirigidos por el IAOC.

Ni el IAD ni el IAOC influyen en el desarrollo de los estándares del IETF, tema que ahora veremos.

2.2.2 IESG (Internet Engineering Steering Group – Grupo de Dirección de Ingeniería de Internet)

El IESG es responsable de la gestión técnica de las actividades del IETF y los procesos de elaboración de estándares de Internet. Administra el proceso según las normas y procedimientos que ha ratificado la Junta Directiva de ISOC. Sin embargo, el IESG no ejerce un liderazgo directo, del tipo que encontrará en otros organismos de estandarización. Como su nombre sugiere, su función es marcar direcciones más que dar órdenes. El IESG ratifica o guía el resultado de los Grupos de Trabajo (WG) del IETF, inicia o da por finalizados a los WG, y se asegura de que los borradores que no provienen de un WG y que se han de convertir en RFC sean correctos.

Consulte las páginas web del IESG, http://www.ietf.org/iesg.html, donde encontrará información actualizada sobre los borradores procesados, las RFC publicadas y los documentos en Última Llamada, además de los informes de estado mensuales del IETF.

El IESG está formado por Directores de Zona (llamados a menudo AD, siglas de Area Director) seleccionados por el Comité de Nominaciones (habitualmente denominado “el NomCom”) por un período de dos años. El proceso para designar a los miembros del IESG se detalla en [BCP10], "Proceso de selección, confirmación y destitución del IAB y el IESG: Funcionamiento de los Comités de Nominación y Destitución”.

A continuación se muestran las Áreas actuales y sus abreviaturas.

Área Descripción
Aplicaciones (APP) Protocolos que ven los programas de los usuarios, tales como el correo electrónico y la web
General (GEN) Proceso del IETF y área para los WG que no encajan en otras áreas (muy pocos)
Internet (INT) Diferentes formas de mover paquetes IP e información de DNS
Operaciones y Gestión – Operations and Management (OPS) Aspectos operativos, supervisión de redes y configuración
Aplicaciones en Tiempo Real e Infraestructura – Real-time Applications and Infrastructure (RAI) (RAI) Comunicaciones interpersonales sensibles al retardo
Enrutamiento (RTG) Cómo llevar los paquetes a su destino
Seguridad (SEC) Autenticación y privacidad
Transporte (TSV) Servicios especiales para paquetes especiales

Como el IESG ejerce mucha influencia a la hora de determinar si un Internet Draft se convertirá o no en RFC, muchos consideran que los Directores de Área (AD) son una especie de “seres superiores”. Los participantes del IETF a veces piden con reverencia a los Directores de Área su opinión sobre un tema determinado. Sin embargo, la mayoría de los AD son prácticamente indistinguibles de los simples mortales y casi nunca hablan como si lo hicieran desde un pedestal. De hecho, cuando se les solicita algún comentario sobre un tema técnico específico, los AD a menudo se someten a la opinión de otros participantes del IETF que en su opinión tienen más conocimientos que ellos sobre el tema.

El Director de un Área en particular conoce la labor de los WG de su área mejor que cualquier otra persona. Por otra parte, el IESG revisa todos los borradores de Internet que se propone transformar en RFC. Cualquier Director de Área puede, con su voto, fijar una posición de “DISCUTIR” contra un borrador si tiene dudas serias. Si estas dudas no se pueden resolver mediante una discusión, se define un proceso de anulación, de forma que al menos dos miembros del IESG deben expresar sus dudas antes de poder bloquear un borrador y que éste no siga adelante. Estos procedimientos ayudan a asegurar que el “proyecto preferido” de un AD no ingrese al proceso de estandarización aunque vaya a tener un efecto negativo sobre los demás protocolos del IEFT y que un “capricho” no pueda bloquear una iniciativa de manera indefinida.

Esto no significa que el IESG no tenga ningún poder. El IESG actúa cuando ve que un Grupo de Trabajo se desvía de sus estatutos, o cuando un WG pide al IESG que convierta un protocolo mal diseñado en un estándar. De hecho, debido a su alta carga de trabajo, el IESG normalmente trabaja de forma reactiva. Finalmente aprueba la mayoría de las solicitudes de los WG para que los borradores de Internet se conviertan en RFC y en general solo interviene cuando algo ha salido muy mal. Dicho de otra manera, se podría decir que el trabajo de los Directores de Área consiste en pensar todo el proceso, no solo en dirigirlo. La calidad de los estándares del IETF se debe tanto a las revisiones en los Grupos de Trabajo como al escrutinio que la revisión del WG obtiene de los Directores de Área.

El IETF funciona por consenso y es el IESG quien juzga si un WG ha conseguido un resultado que cuenta con el consenso de la comunidad del IETF. (Consulte Section 4.2 para obtener más información sobre el consenso en un WG.) Debido a esto, una de las principales razones por las que el IESG podría bloquear algo producido en un WG es porque el resultado no consiguió consenso en el IETF, es decir, entre todos los Grupos de Trabajo y en todas las Áreas. Por ejemplo, el resultado de un WG podría chocar con una tecnología desarrollada en un Grupo de Trabajo diferente, quizá perteneciente a otra Área. Una labor importante del IESG es supervisar los resultados producidos por todos los WG para intentar evitar que existan protocolos del IETF que choquen unos contra otros. Es por ello que los Directores de Área deben revisar los borradores que provienen de Áreas que no son las suyas propias.

2.2.3 IAB (Internet Architecture Board – Consejo de Arquitectura de Internet)

El IAB es responsable de estar pendiente de Internet en su conjunto y su trabajo se centra en la planificación a largo plazo y la coordinación entre las diferentes áreas de actividad del IETF. El IAB se mantiene al tanto de los grandes problemas de Internet a largo plazo y los pone en conocimiento de quienes cree conveniente.

Los miembros del IAB prestan especial atención a las actividades emergentes del IETF. Cuando en el IETF se propone un nuevo Grupo de Trabajo, el IAB revisa la coherencia y la integridad de sus estatutos. Incluso antes de la creación del grupo, los miembros del IAB están más que dispuestos a discutir nuevas ideas con las personas que las proponen.

El IAB también patrocina y organiza el IRTF (Internet Research Task Force – Grupo de Trabajo de Investigación de Internet) y convoca a talleres para realizar revisiones profundas de temas específicos relacionados con la arquitectura de Internet. Típicamente, los informes de los talleres contienen recomendaciones dirigidas a la comunidad del IETF y al IESG.

El IAB también:

Al igual que los miembros del IESG, los miembros del IAB son seleccionados por el NomCom y aprobados por la Junta Directiva de ISOC. También permanecen en sus cargos por un período de dos años.

2.2.4 IANA (Internet Assigned Numbers Authority – Autoridad para la Asignación de Números de Internet)

El principal registro de las actividades del IETF es la IANA (consulte http://www.iana.org). Muchos protocolos de Internet necesitan que alguien realice un seguimiento de determinadas partes del protocolo que se añadieron después de la publicación del mismo. Son ejemplos típicos de los tipos de registros necesarios los números de puerto TCP y los tipos MIME. El IAB ha designado a la IANA para que ejecute esas tareas y las actividades de la IANA reciben el apoyo financiero de ICANN, la Corporación de Internet para la Asignación de Nombres y Números. El IAB seleccionó a ICANN y la IANA realiza sus actividades de forma gratuita, como se especifica en [RFC2860].

Hace diez años nadie se hubiera imaginado que la IANA iba a aparecer en la portada de un periódico. El papel desempeñado por la IANA siempre ha sido moderado. El hecho de que la IANA también fuera el guardián de la raíz del sistema de nombres de dominio le obligó a convertirse en una entidad más pública, una que mucha gente criticó sin mirar cuál era su verdadera función. Hoy en día, el IETF generalmente ya no se involucra en las funciones de asignación de nombres de dominio y direcciones IP que realiza la IANA, las cuales son supervisadas por ICANN.

Aunque puede que ser un registro no suene interesante, muchos participantes del IETF darán testimonio de la importancia que ha tenido la IANA para Internet. Contar con un repositorio estable a largo plazo dirigido por operadores cuidadosos y conservadores hace que resulte más fácil experimentar sin preocuparse de estropear las cosas. Todos confiaban en que Jon Poste, fundador de la IANA, mantendría el orden mientras Internet crecía a pasos de gigante y Jon no defraudó sino que realizó una labor estupenda hasta su fallecimiento en 1998.

2.2.5 Editor de RFC

En colaboración con el IESG, el Editor de RFC edita, maqueta y publica los borradores de Internet como RFC. Una importante función secundaria es ofrecer un repositorio definitivo para todas las RFC (consulte http://www.rfc-editor.org). Una vez publicada, una RFC no puede modificarse. Si la especificación descrita en la RFC cambia, se publicará otra RFC que convertirá en “obsoleta” a la primera.

Uno de los principales malentendidos dentro de la comunidad del IETF es que la función de Editor de RFC la desempeña la IANA. Aunque durante muchos años tanto el Editor de RFC como la IANA involucraban a las mismas personas, el trabajo del Editor de RFC es una tarea independiente. Hoy en día, estas tareas son desempeñadas por organizaciones diferentes. El IAB aprueba la organización que actuará como Editor de RFC y su política general. El Editor de RFC es financiado por la IASA.

Hasta finales de 2009, el Editor de RFC era una única entidad. En coordinación con la comunidad del IETF, el IAB dividió esta función en varias subfunciones que pueden desempeñar personas u organizaciones diferentes, lideradas por el Editor de las Series de RFC designado por el IAB. El modelo del Editor de RFC se describe en[RFC6635].

2.2.6 Secretaría del IETF

Algunas personas reciben una remuneración por mantener el IETF. La Secretaría del IETF ofrece apoyo logístico diario, lo que en principio significa coordinar las reuniones presenciales y dirigir las listas de correo específicas del IETF. La Secretaría es también responsable de mantener el directorio oficial de Internet Drafts actualizado y ordenado, mantener el sitio web del IETF y ayudar al IESG a hacer su trabajo. Ofrece diferentes herramientas para que uso de la comunidad y el IESG. La Secretaría del IETF tiene un contrato con la IASA, que a su vez recibe apoyo financiero de las tarifas que se cobran a quienes asisten a las reuniones presenciales.

2.2.7 Fundación IETF (IETF Trust)

La Fundación IETF se creó a finales de 2005 para ser titular y otorgar licencias de los derechos de propiedad intelectual del IETF. La Fundación IETF se creó porque alguien tenía que ser el titular de la propiedad intelectual y este alguien debía ser una entidad estable y legalmente identificable. Los directores son las mismas personas que se desempeñan como miembros del IAOC. Pocos participantes del IETF tienen contacto con la Fundación, lo que significa que sus miembros están haciendo bien su trabajo y en forma discreta. Puede obtener más información sobre la Fundación IETF en su sitio web, http://trustee.ietf.org.

2.3 Listas de Correo del IETF

Cualquier persona que esté pensando asistir a una reunión del IETF debería unirse a la lista de correos de anuncios del IETF (consulte https://www.ietf. org/mailman/listinfo/IETF-Announce). Ahí encontrará toda la información sobre las reuniones, anuncios sobre las RFC y las Últimas Llamadas y Acciones de Protocolo del IESG. Quienes disfrutan de las discusiones sobre temas técnicos también pueden unirse a la lista de discusión general del IETF (consulte https://www.ietf.org/ mailman/listinfo/ietf). En esta lista se llevan a cabo discusiones de importancia global (los Grupos de Trabajo tienen sus propias listas de correo para discusiones relacionadas con su trabajo). Otra lista de correo anuncia cada versión nueva de los Borradores de Internet conforme se publican (consultehttps://www.ietf. org/mailman/listinfo/I-D-Announce).

Las suscripciones a estas y otras listas del IETF son gestionadas por un programa llamado "mailman". Mailman puede ser un poco quisquilloso con el formato de los mensajes de suscripción y a veces no interactúa bien con los programas de correo electrónico que convierten todos los mensajes en archivos HTML. Sin embargo, si formatea sus mensajes correctamente, Mailman le tratará bien.

La lista de discusión del IETF no está sujeta a moderación, lo que significa que todo el mundo puede expresar su opinión sobre los problemas que afectan a Internet. Sin embargo, no es lugar para que las empresas o individuos realicen pedidos o hagan publicidad, tal como se especifica en [BCP45], "Estatutos de las listas de discusión del IETF". Antes de publicar en la lista de discusión del IETF es una buena idea leer toda la RFC (¡es breve!). Actualmente, la lista cuenta con dos “alguaciles” que vigilan que no haya publicaciones inapropiadas y además existe un proceso para excluir de la lista a los ofensores persistentes. Afortunadamente, este proceso se utiliza muy rara vez.

Solo la Secretaría y un pequeño grupo de líderes del IETF pueden aprobar los mensajes que se envían a la lista de anuncios, aunque estos mensajes pueden ser enviados por diferentes personas.

Aunque las listas de correo del IETF “representan” a los participantes del IETF en general, es importante tener en cuenta que asistir a una reunión del IETF no significa que le vayan a añadir automáticamente a ninguna de las listas de correo.


3. Reuniones del IETF

En la industria de la IT hay incontables conferencias, seminarios, exposiciones y todo tipo de reuniones. Las reuniones presenciales del IETF no se parecen en nada a ninguno de estos eventos. Estas reuniones tienen lugar tres veces al año y son verdaderas “reuniones de tribus” de una semana de duración cuyo principal objetivo es que los WG hagan su trabajo y su objetivo secundario es promover un equilibrio justo entre los WG y las diferentes Áreas. El costo de las reuniones lo cubren las personas que asisten y las empresas que patrocinan cada reunión (si es que las hay), aunque la IASA envía fondos adicionales para cosas como la retransmisión del audio de algunas de las sesiones de los Grupos de Trabajo.

Para muchos, las reuniones del IETF son una bocanada de aire fresco en comparación con las conferencias habituales de la industria de la IT. No hay una sala de exposiciones, hay pocos tutoriales y no hay expertos supuestamente de renombre en la industria. En cambio lo que hay es una gran cantidad de trabajo y tiempo suficiente para socializar entre tantos participantes. Las del reuniones IETF resultan poco interesantes para la gente de ventas y marketing, pero son de gran interés para ingenieros y desarrolladores.

El flujo general de una reunión del IETF es el siguiente: empieza con tutoriales y una reunión informal el día domingo y luego hay reuniones de los WG y BoF de lunes a viernes. Las reuniones de los WG duran entre 1 y 2,5 horas cada una y algunos WG se reúnen varias veces durante la semana según la cantidad de trabajo que hayan planificado.

Hay dos sesiones plenarias, una técnica y otra administrativa, al final de la tarde. El plenario técnico es organizado por el IAB y habitualmente incluye uno o dos paneles de expertos en temas de interés para muchos WG y Áreas. El plenario administrativo es organizado por el Chair del IETF e incluye cosas como informes de progreso del Editor de RFC y el anuncio de reuniones futuras. Los plenarios son un buen momento para compartir con el IESG y el IAOC. Los elogios son bienvenidos, pero con más frecuencia se presentan problemas y preocupaciones.

En estos momentos, el IETF se reúne en Norteamérica, Europa y Asia, aproximadamente una vez al año en cada región. Las últimas reuniones han tenido cerca de 1200 participantes. Hasta el momento se han celebrado más de 80 reuniones del IETF. Además, en la página web del IETF incluimos una lista de futuras reuniones http://www.ietf.org/meeting/upcoming.html.

Quienes asisten por primera vez a una reunión presencial del IETF a menudo se sorprenden, ya que piensan que será similar a las reuniones de otros organismos de normalización o a una conferencia de IT. Afortunadamente, la sorpresa desaparece después de un día o dos y muchos nuevos asistentes se animan a participar apenas se dan cuenta de lo mucho que se divierten. Por otro lado, en ocasiones las reuniones del IETF pueden ser sorprendentemente maleducadas, con personas que hablan en voz alta mientras alguien está hablando por el micrófono o empujándose unos a otros para conseguir comida y bebida. Este tipo de comportamiento antisocial parece ser más común en las reuniones del IETF que en las conferencias de IT.

3.1 Inscripción

Para asistir a una reunión del IETF es necesario registrarse y pagar la tasa de inscripción. La lugar donde se realizará la reunión y los detalles de la inscripción se anuncian con dos meses de antelación — o antes si es posible. Se envía un anuncio a través del correo electrónico a lista de anuncios del IETF y la información se publica en el sitio web del IETF,http://www.ietf.orgese mismo día.

Puede registrarse y pagar la inscripción en el sitio web antes de la reunión, o bien puede pagar la inscripción personalmente en la propia reunión. Si desea pagar una tasa de inscripción reducida, debe hacerlo antes de la fecha límite especificada (más o menos una semana antes de la reunión). La tasa de inscripción cubre todas las reuniones de la semana, la recepción de bienvenida que se realiza el domingo (bar), el desayuno continental diario y las bebidas y tentempiés de la tarde.

La inscripción está abierta durante toda la semana de la reunión. Sin embargo, la Secretaría recomienda que los asistentes lleguen a tiempo para el primer período de inscripción que normalmente empieza el domingo a mediodía y continúa todo el domingo, incluso durante la recepción de la tarde. La recepción es un evento popular donde puede comer algún bocadillos y socializar.

Vale la pena destacar que los nombres de los participantes, sus direcciones y las listas de correo del IETF nunca están a la venta.

Antes de registrarse, verá una página “Note Well” (Prestar especial atención). Lea esta página cuidadosamente ya que en ella se describen las normas sobre derechos de propiedad intelectual del IETF.

Si necesita dejar un mensaje para otros asistentes, puede hacerlo en las carteleras de corcho que por lo general se encuentran cerca del mostrador de registro. En estas carteleras también se anuncia información sobre cambios de último momento en las reuniones y salas.

Los objetos perdidos se deben llevar al mostrador de registro. Al finalizar la reunión, los objetos que no hayan sido reclamados por sus dueños quedarán en el hotel o se llevarán a la oficina de la Secretaría.

A propósito del mostrador de registro del IETF, este es un buen lugar de encuentro. Si alguien dice “nos vemos en el mostrador”, debería aclarar si se refiere al mostrador de registro del IETF o al mostrador de check-in del hotel. No hacerlo ha causado unos cuantos desencuentros.

3.2 ¡Arriésguese y quédese toda la semana!

Las reuniones de los WG del IETF se programan entre el lunes por la mañana y el viernes por la tarde. Por lo general, las reuniones que no son de los WG se llevan a cabo el fin de semana anterior o el siguiente. Lo más recomendable es estar presente toda la semana para aprovechar al máximo las discusiones entre los diferentes Grupos de Trabajo y los debates informales que se dan en los corredores. Como se comenta a continuación, la agenda es muy flexible y muchas veces los participantes se han perdido sesiones importantes debido a cambios de última hora cuando ya habían ultimado los detalles de su viaje. Estar presente toda la semana es la única manera de evitar este problema.

Si no encuentra reuniones que sean de su interés para cada momento de la semana, puede aprovechar las reuniones del IEFT y trabajar entre sesiones. La mayoría de quienes asisten a estas reuniones traen sus propias computadoras y es común verles en la sala de terminales o en los pasillos trabajando mientras se llevan a cabo las sesiones. A menudo existe buena cobertura de Internet en muchos lugares de la reunión (restaurantes, cafeterías, etc.), de modo que ponerse al día con el correo electrónico mientras no se está reunido es algo común entre los participantes.

3.3 Capacitación para principiantes

Se recomienda que los principiantes asistan a la orientación para nuevos participantes (Newcomer’s Orientation) que tiene lugar el domingo por la tarde y está diseñada para quienes asisten por primera vez a una reunión del IETF. Esta orientación es organizada y dirigida por el equipo EDU del IETF y tiene como objetivo ofrecer información introductoria útil. La sesión explica lo que significan todos los puntos que aparecen en las credenciales con los nombres de los participantes, la estructura del IETF y muchos otros temas esenciales y muy informativos para los nuevos participantes.

Al final de la tarde hay una reunión de bienvenida para principiantes (Newcomer’s Meet and Greet), un evento exclusivo para quienes se incorporan al IETF por primera vez y los presidentes de los WG. Es un buen lugar para conocer otros asistentes que tengan conocimientos en las áreas de su interés. Aproveche para acercarse a cualquier presidente de un WG –no solo a aquellos de su Área– ya sea para aprender sobre su WG en particular o bien para que le ayude a encontrar personas del suyo.

3.4 Código de vestimenta

Los asistentes deben llevar una credencial con su nombre y por lo general su vestimenta es informal – camisas o camisetas, pantalones o faldas. Muchos principiantes sienten vergüenza cuando al llegar el lunes por la mañana vistiendo un traje descubren que el resto de los participantes lleva camiseta, vaqueros (o pantalones cortos si el tiempo lo permite) y sandalias. De todos modos, hay gente en el IETF que se niega a llevar otra cosa que no sea un traje. Afortunadamente, estas personas son bien conocidas (por otras razones) y normalmente se les disculpa esta particular idiosincrasia. La norma general es usar ropa cómoda y adecuada para el clima del lugar.

3.5 Reuniones de los Grupos de Trabajo

Las reuniones de los WG son el elemento principal de las reuniones del IETF. Diferentes presidentes de diferentes WG tienen estilos diferentes, de modo que es imposible generalizar sobre los WG. Casi todos los WG tienen una agenda para la reunión, aunque algunas reuniones siguen la agenda al pie de la letra mientras que otras son más flexibles.

Todas las reuniones de los WG de una reunión del IETF tienen varias cosas importantes en común. Al empezar la reunión, el presidente entregará un bloc de hojas azules – formularios de papel en los que todos escriben su nombre y dirección de correo electrónico. Estas hojas se archivan para saber cuánta gente asistió a una reunión determinada y, en algunos pocos casos, para saber quiénes asistieron. El procedimiento normal es ver de dónde vienen las hojas azules y pasarlas en la misma dirección.

Siempre que hable en una reunión debe dirigirse a los micrófonos. Si el tema en discusión genera controversia seguramente habrá cola en el micrófono, pero no dude en ser el primero en hablar si tiene alguna pregunta o algo que contribuir a la discusión. El presidente o presentador del WG le indicará cuándo puede hablar. Aunque le parezca más fácil levantar la mano desde su asiento, los micrófonos desempeñan una labor muy útil: permiten que quienes están en la parte de atrás de la sala oigan su pregunta o comentario. Al llegar al micrófono se espera que diga su nombre, así la persona que redacta las actas sabrá quién está hablando.

3.6 Puntos de colores

Verá que algunas personas del IETF tienen un punto de color en la credencial con su nombre. Unos pocos tendrán más de un punto. Estos puntos permiten identificar a quienes, sin saber en qué se metían, se han ofrecido voluntariamente para trabajar muy duro. Los colores tienen los significados que se indican en la tabla siguiente.

Color Significado
Azul Presidente de un Grupo de Trabajo/BOF
Verde Grupo Anfitrión
Rojo Miembro del IAB
Amarillo Miembro del IESG
Naranja Miembro del Comité de Nominaciones
Violeta IAOC
Rosado IRSG
Verde azulado RSE

(Los miembros de la prensa llevan etiquetas color naranja).

Los anfitriones pueden responder preguntas acerca de la sala de terminales, los restaurantes y otros puntos de interés en la zona.

Es importante que quienes llegan al IETF por primera vez no tengan miedo de iniciar conversaciones con la gente que lleva estos puntos en sus credenciales. Si los miembros del IAB o el IESG, los presidentes de los Grupos de Trabajo y de los BOF no quisieran hablar con nadie, no andarían por la conferencia mostrando sus credenciales. Sin embargo, tenga en cuenta que habitualmente las reuniones del IETF son días muy intensos para los Directores de Área. Si durante la reunión habla con un Director de Área, es probable que esta persona le pida que le envíe un correo electrónico más o menos en dos semanas. Además, cuando empiece una conversación de pasillo con un Director de Área (o incluso con el presidente de un WG), muchas veces es una buena idea darles 30 segundos de contexto.

3.7 Sala de terminales

Una de las cosas más importantes que hace el anfitrión es ofrecer acceso a Internet a los asistentes de la reunión. En general, la conexión inalámbrica es excelente en todas las salas de reunión y en la mayoría de zonas comunes. Además, la sala de terminales tiene conexiones cableadas. Las personas y empresas que donan sus equipos, servicios y tiempo se merecen nuestro más profundo agradecimiento.

Aunque se recomienda preparar su participación con bastante anticipación, es posible que deba hacer ciertas cosas de último momento en la sala de terminales. Esta sala también puede ser útil si necesita preparar algún informe mientras aun tiene todo fresco en la memoria.

Para ingresar a la sala de terminales debe llevar su credencial de identificación. En la sala de terminales encontrará múltiples enchufes, puertos Ethernet para computadoras portátiles, conexión inalámbrica (para quienes no necesitan Ethernet pero sí energía eléctrica), generalmente una impresora para uso del público en general y a veces estaciones de trabajo. Lo que no se ofrece son terminales – el nombre de la sala es apenas histórico. El servicio de ayuda técnica de la sala de terminales es un buen lugar para hacer preguntas acerca de posibles fallos en la red, aunque puede que de allí lo deriven al personal encargado.

3.8 Almuerzos, cenas y otras delicias

Marshall Rose una vez dijo que el IETF era un excelente lugar donde ir en busca de “muchos buenos almuerzos y cenas". Aunque es cierto que hay gente que come muy bien durante las reuniones del IETF, cada participante suele buscar sus propias opciones ya que el almuerzo y la cena no están incluidos en la tasa de inscripción. La Secretaría se encarga de los aperitivos que se sirven en la recepción de bienvenida del domingo por la tarde (que no sustituyen la cena), del desayuno continental de lunes a viernes (según donde se lleve a cabo la reunión) y de las galletas, brownies, frutas y otras delicias que se sirven durante algunos de los descansos de la tarde. Muchas veces estos refrigerios son ofrecidos por el anfitrión de la reunión o por uno de sus patrocinadores.

Si a la hora de comer prefiere salir del hotel, generalmente el anfitrión tiene una lista de lugares próximos a la reunión.

3.9 Evento social

Otra cosa importante que organiza y dirige el anfitrión de la reunión es el evento social, que puede ser un evento relacionado con la tecnología o bien puede ser un evento en un museo o salón de fiestas. Sin embargo, tenga en cuenta que no todas las reuniones del IETF incluyen eventos sociales.

Se anima a quienes recién llegan al IETF a que asistan a los eventos sociales. Se recomienda que todos lleven la credencial con su nombre y dejen sus computadoras portátiles en casa. Los eventos sociales están pensados como una oportunidad para que los participantes se conozcan a nivel social, más que a nivel técnico.

3.10 Agenda

La agenda de las reuniones del IETF es muy flexible. Está disponible en la web unas semanas antes del comienzo de la reunión, aunque también hay pequeñas agendas disponibles en el mostrador de registro (estas últimas son ideales para aquellos con buena vista que deseen guardar una copia en su bolsillo o junto con su credencial). Claro que en el IETF la palabra “final” no significa lo mismo que en el resto del mundo. La agenda final es simplemente la versión que llegó a la imprenta. La Secretaría publicará los cambios en la cartelera de anuncios que está cerca del mostrador de registro del IETF (no del mostrador de check-in del hotel). Estos cambios de último momento no son antojadizos sino que se introducen “justo a tiempo” cuando el moderador de una sesión o conferencista detecta algún conflicto de horarios que no se había anticipado. El IETF es demasiado dinámica como para cerrar definitivamente una agenda con semanas de antelación.

En la agenda también encontrará un mapa que muestra la ubicación de las salas. Si la agenda cambia, es posible que también cambien las salas asignadas. Algunos Grupos de Trabajo se reúnen varias veces, por lo que se hace lo posible para que cada Grupo se reúna siempre en la misma sala.

3.11 Equipo EDU al rescate

Si ciertos aspectos del IETF aún le resultan desconcertantes (incluso después de leer el Tao), tal vez quiera asistir al curso presencial que ofrece el equipo de Educación (EDU). Estas clases informativas se han diseñado tanto para quienes recién se integran al IETF como para los veteranos. Además de la formación para nuevos participantes, el equipo EDU ofrece talleres para editores de documentos y presidentes de Grupos de Trabajo, más un extenso tutorial sobre seguridad indispensable para todos quienes participan en el IETF. Las sesiones de EDU suelen programarse para los domingos por la tarde. Puede encontrar más información sobre el equipo EDU en http://www.ietf.org/edu/.

3.12 Y yo dónde encajo?

El IETF significa cosas distintas para cada persona. muchas personas han sido muy activas en el IETF sin haber asistido a ninguna de sus reuniones. No se sienta obligado a asistir a una reunión del IETF solo para saber de qué se trata. Las siguientes directrices le ayudarán a decidir si desea venir y, de ser así, cómo aprovechar mejor el tiempo en su primera reunión.

3.12.1 Gerentes de Sistemas

Como ya dijimos, las reuniones del IETF no se parecen en nada a las ferias a las que puede haber asistido anteriormente. Las reuniones del IETF son particularmente inadecuadas si su intención es saber cuáles serán el año que viene las tendencias en la industria de Internet. Puede estar bastante seguro de que las reuniones de los Grupos de Trabajo le confundirán más de lo que le ayudarán a comprender qué es lo que está pasando, o qué pasará, en la industria.

Eso no significa que la industria no deba asistir a las reuniones del IETF. Como Gerente de Sistemas, quizás debería considerar enviar al personal específico responsable de las tecnologías que se están desarrollando en el IETF. Dado que estas personas leen los Borradores de Internet y siguen las discusiones en las listas de los Grupos de Trabajo correspondientes, ellos sabrán si su presencia valdrá la pena para su empresa o para los Grupos de Trabajo.

3.12.2 Operadores de redes e ISP

Administrar una red ya es bastante difícil sin tener que lidiar con nuevos protocolos o nuevas versiones de los protocolos con los que ya está trabajando. Si trabaja con el tipo de redes que siempre utilizan lo último en hardware y software y en su tiempo libre sigue a los Grupos de Trabajo relevantes, participar en el IETF resultará valioso para usted. Parte de la labor del IETF también abarca muchos otros aspectos de las operaciones de los ISP y las grandes empresas, por lo que los comentarios de los operadores son un gran aporte para que esta labor siga siendo dinámica y relevante. Muchos de los mejores documentos del IETF sobre operaciones provienen de operadores reales, no de proveedores ni del sector académico.

3.12.3 Proveedores de software y hardware para redes

Puede que la imagen del IETF como una torre de marfil y punto de encuentro los académicos fuera cierta en el pasado, pero ahora los típicos participantes trabajan en la industria. En la mayoría de las áreas del IETF son los empleados de los proveedores quienes escriben los protocolos y lideran los Grupos de Trabajo, de modo que es totalmente apropiado que los proveedores asistan a las reuniones. Si usted desarrolla hardware o software para Internet y todavía nadie de su empresa ha asistido a una reunión del IETF, debería asistir a una reunión aunque más no sea para contarle al resto si la reunión fue relevante para su negocio o no.

Esto no significa que las empresas tengan que cerrar sus oficinas durante las reuniones del IETF para que todos puedan asistir. Está bien que la gente de marketing –incluso el personal de marketing técnico– no asista a las reuniones del IETF, siempre y cuando algunos técnicos de la empresa sí lo hagan. Del mismo modo, no es necesario –ni útil– que todo el departamento técnico se haga presente, en particular si no todos leen los Borradores de Internet y siguen las listas de correo de los Grupos de Trabajo. Muchas empresas envían unos pocos participantes, escogidos por su habilidad para elaborar informes muy completos y útiles. Además, muchas empresas implementan esfuerzos de coordinación internos y una estrategia para sus estándares. Si una compañía depende de Internet para parte o para la totalidad de su negocio, esta estrategia debería incluir al IETF.

3.12.4 Mundo académico

Las reuniones del IETF son un excelente lugar para que los informáticos se enteren de qué está pasando con los protocolos que pronto se desplegarán. Los profesores y estudiantes de posgrado (y a veces también los estudiantes de grado más ambiciosos) que investigan en el área de las redes o las comunicaciones pueden obtener mucha información siguiendo a los Grupos de Trabajo de sus áreas de interés específicas. Ingresar a las reuniones de diferentes Grupos Trabajo puede tener el mismo efecto que asistir a simposios y seminarios. Obviamente, las actividades del IRTF también podrían interesar a los investigadores.

3.12.5 Prensa especializada en informática

Si es miembro de la prensa y desea asistir a una reunión del IETF, hemos preparado una sección especial del Tao solo para usted — Consulte Section 8.2.

3.13 Actas

Las actas de las reuniones del IETF se compilan durante los dos meses siguientes a cada reunión y están disponibles en línea. Asegúrese de leerlas — las actas contienen una gran cantidad de información acerca del IETF que no encontrará en ningún otro sitio. Por ejemplo, en ellas encontrará instantáneas de la mayoría de los estatutos de los Grupos de Trabajo al momento de la reunión, lo que le permitirá entender mejor la evolución de una actividad determinada.

A veces las actas comienzan con un mensaje informativo (y muy divertido). Cada volumen contiene la agenda final, un resumen de la reunión, informes de cada Área y Grupo de Trabajo y diapositivas de las presentaciones técnicas y sobre protocolos. Si los materiales no fueron enviados a la Secretaría a tiempo para su publicación, puede que los informes y presentaciones de los Grupos de Trabajo estén incompletos.

También incluyen la lista de asistentes con los nombres y afiliaciones proporcionados en el formulario de registro. Para más información sobre cómo obtener una copia de las actas, diríjase a http://www.ietf.org/meeting/proceedings.html.

3.14 Otros temas generales

En general, quienes participan en las reuniones del IETF son personas muy accesibles. No tenga miedo de acercarse a alguien y presentarse. Tampoco tenga miedo a la hora de hacer preguntas, en especial si se trata de la jerga o los acrónimos.

Las conversaciones de pasillo son también muy importantes. Mucho y muy buen trabajo es realizado por gente que conversa entre reuniones, a la hora del almuerzo y durante la cena. Cada instante de la reunión del IETF se puede considerar como tiempo de trabajo.

Las reuniones paralela (histórica pero poco adecuadamente llamadas “BOF de bar”) son reuniones no oficiales que se llevan a cabo entre las reuniones de los WG o por la tarde y durante las cuales se trabaja mucho. Estas reuniones alternativas surgen en muchos lugares diferentes próximos a la reunión del IETF, como por ejemplo en restaurantes, cafeterías, salas sin ocupar y (si tiene suerte) piscinas.

No es muy inteligente interponerse entre un participante hambriento (y no los hay de otro tipo) y las galletas del coffee break, sin importar lo interesante que sea la conversación. Steve Coya, el primer director ejecutivo del IETF, solía decir “Toma tu galleta y aléjate de la mesa".

Los asistentes al IETF son extremadamente independientes. Puede cuestionar sus opiniones y ofrecer alternativas, pero no espere que sigan órdenes.

Las reuniones del IETF, en particular las sesiones plenarias, no son lugar para que los proveedores intenten vender sus productos. Los participantes pueden responder preguntas acerca de su empresa y sus productos, pero tenga en cuenta que el IETF no es una feria de muestras. Esto no significa que no podrá recuperar lo que invierta en camisetas, prendedores y protectores de bolsillo relacionados con el IETF.

Siempre hay una “mesa de distribución de materiales” cerca del mostrador de inscripción. Esta mesa se usa para distribuir información a los asistentes (por ejemplo, copias de algo que se ha discutido en una sesión de un Grupo de Trabajo, la descripción de información relacionada con el IETF disponible en Internet). Antes de colocar su material en el mostrador consulte a la Secretaría, ya que éste podría ser retirado si la Secretaría lo considera inapropiado.

Si necesita su computadora portátil durante la reunión, es buena idea traer una batería extra. En algunas salas no siempre es fácil encontrar un enchufe libre y usar el acceso inalámbrico puede consumir más batería de la que esperaba. Si se sienta cerca de un enchufe múltiple, tenga en cuenta que otros le pedirán que enchufe y desenchufe sus equipos. Muchos traen su propio cable con un múltiple, lo cual, además de muy útil, resulta una buena manera de entablar amistad con su vecino. Si necesita un adaptador, intente comprar uno por adelantado ya que normalmente son más fáciles de encontrar en su propio país.


4. Grupos de Trabajo

La mayor parte del trabajo que se realiza en el IETF se hace en los Grupos de Trabajo. En el momento de escribir este documento existían 115 WG diferentes. [BCP25], "Directrices y procedimientos de los Grupos de Trabajo del IETF", es un excelente recurso para cualquiera que participe en discusiones de los WG.

En realidad un Grupo de Trabajo es una lista de correo con un poco de supervisión. Puede "unirse” a un WG suscribiéndose a la lista de correo correspondiente – todas las listas de correo son abiertas. Cualquiera puede publicar en la lista de correo de un WG, aunque la mayoría de las listas exigen que las contribuciones enviadas por una persona no suscrita sea moderada antes de su publicación. Cada Grupo de Trabajo tiene uno o dos (o incluso algunas veces tres) presidentes.

Aún más importante, cada WG tiene un estatuto que debe respetar. Este estatuto define el alcance de las discusiones del Grupo y sus objetivos. En teoría, la lista de correo y las reuniones presenciales de cada WG se deberían limitar a lo que se ha descrito en los estatutos y no desviarse hacia otros temas de interés. Está claro que a veces mirar más allá del alcance del WG resulta útil, pero el grueso de las discusiones debe centrarse en los temas listados en el estatuto. De hecho, los estatutos de algunos WG especifican qué no debe hacer el Grupo, especialmente si cuando en el momento de su creación original surgieron temas atractivos pero no que no pudieron ser bien definidos. Los estatutos de los distintos Grupos de Trabajo son una lectura interesante para quienes deseen a qué se dedica cada uno de ellos.

4.1 Presidentes de los Grupos de Trabajo

La función de los presidentes de los WG se describe en [BCP11] y [BCP25].

La primera tarea del presidente consiste en determinar los objetivos e hitos de consenso del Grupo, manteniendo actualizado el estatuto. Luego, a menudo con la ayuda de los secretarios de los WG o los editores de documentos, el presidente debe gestionar los debates del Grupo, tanto en la lista de correo como programando reuniones presenciales cuando corresponda. A veces ocurre que las discusiones se estancan en algún punto controvertido y el presidente debe dirigir a los participantes hacia una interacción productiva para luego poder declarar que existe consenso general y que la discusión ha terminado. En ocasiones los presidentes también gestionan la interacción con participantes que no pertenecen al WG o con el IESG, en especial cuando se va a publicar un documento del Grupo. Los presidentes son responsables de la calidad técnica y no técnica del trabajo producido por el WG. Como podrá imaginar, teniendo en cuenta la mezcla de trabajo de secretaría, interpersonal y técnico que deben abarcar, los presidentes de algunos Grupos de Trabajo le parecerán mejores que otros.

Se recomienda encarecidamente a los presidentes de los Grupos de Trabajo que asistan a la capacitación en liderazgo que tiene lugar el sábado anterior a la reunión del IETF. Habitualmente también se organiza un almuerzo para presidentes a mediados de semana durante el cual se presentan y discuten temas específicamente de interés para los presidentes. Si desea más información sobre este tema, eche un vistazo a las diapositivas que se encuentran en http://edu.ietf.org.

4.2 Cómo funciona un Grupo de Trabajo

Un hecho que confunde a muchos principiantes es que las reuniones presenciales de los WG son menos importantes en los encuentros del IETF que en las reuniones de muchas otras organizaciones. Cualquier decisión que se toma en la reunión presencial debe obtener consenso en la lista de correo. Hay muchos ejemplos de decisiones importantes que se han tomado en reuniones de un WG y que luego fueron anuladas en la lista de correos, muchas veces porque alguien que no pudo asistir a la reunión señala un error grave en la lógica empleada para llegar a esa decisión. Por último, las reuniones de los WG no son “sesiones de redacción” como lo son en muchas otras organizaciones de normalización – en el IETF, las tareas de redacción se llevan a cabo en otras instancias.

Otro aspecto de los Grupos de Trabajo que suele confundir es el hecho de que no exista un voto formal. La regla general sobre los temas discutidos es que el Grupo de Trabajo debe llegar a un “consenso general”, es decir que una gran mayoría debe ponerse de acuerdo. El método exacto para determinar si existe consenso general varía según el grupo del que se trate. A veces el consenso se determina por “tarareo" — si está conforme con una propuesta, tararee cuando se lo pregunte el presidente. La mayoría de las preguntas tipo “tarareo” tienen dos partes: tararee la primera parte si está de acuerdo con la propuesta o tararee la segunda si no lo está. Quienes observan esto por primera vez lo encuentran muy peculiar, pero funciona. El presidente decide cuándo el Grupo de Trabajo ha alcanzado un consenso general.

La falta de votaciones formales ha provocado importantes demoras en algunas propuestas, pero la mayoría de los participantes del IETF que han sido testigos de un consenso general logrado después de ásperos y difíciles debates sienten que gracias a estas demoras se han logrado mejores protocolos. (Pensándolo bien, cómo se podría “votar” en un grupo abierto a todas las personas interesadas en participar, sobre todo cuando es imposible contar a los participantes.) El consenso general tiene muchas definiciones, pero una versión simplificada dice que se deben debatir las objeciones más controvertidas hasta que la mayoría considere que esas objeciones son incorrectas.

Un problema relacionado con lo anterior es que hay quienes creen que su propuesta se debería debatir en el WG, aún cuando el presidente del WG crea lo contrario. Por ejemplo, si el trabajo propuesto no forma parte del estatuto, el presidente del WG podría limitar la discusión para que el Grupo siga trabajando sobre los temas indicados en su estatuto. Si alguien piensa que el WG debería tratar un tema que el presidente considera no cubierto por el estatuto, lo que puede hacer es comunicar su inquietud al AD responsable. El AD podrá estar de acuerdo con incorporar el tema al estatuto o decidir que ya está cubierto en el mismo, o bien podrá determinar que los presidentes del WG tienen razón y el participante deberá trabajar en la propuesta al margen del WG.

Una vez que un documento del WG se ha discutido en profundidad, normalmente pasa por la última llamada del WG (a menudo abreviada “WGLC”, siglas de Working Group Last Call). Esta es la última oportunidad que tiene el grupo para eliminar cualquier problema. Algunas veces la WGLC sacará a relucir tantos problemas que tras incorporar las revisiones será necesario realizar una nueva WGLC. No existen normas formales sobre cómo implementar una WGLC, ni tampoco nada que diga cuándo se necesita una WGLC: el presidente del WG es quien lo decide.

Otro práctica común en los Grupos de Trabajo es tener un “secretario” que administre los diferentes documentos y cambios. El secretario puede realizar un seguimiento de cualquier problema que surja o puede estar simplemente a cargo de vigilar que todas las decisiones que se toman en la lista de correo se reflejen en las nuevas versiones de los documentos.

El funcionamiento de un WG cesa cuando ha cumplido con su estatuto. (La mayoría de las listas de correo de los WG permanecen activas y continúan discutiendo incluso después del cierre del WG.) En el IETF, se considera una señal de éxito que un WG cierre porque ha cumplido con su objetivo. Este es uno de los aspectos del IETF que quienes recién llegan y tienen experiencia con otras organizaciones de normalización no entienden con facilidad. Sin embargo, algunos presidentes nunca logran que su WG cese, o siguen añadiendo nuevas tareas a los estatutos, de modo que el Grupo de Trabajo existe por muchos años (o incluso, en algunos pocos casos, durante décadas). Muchas veces los resultados que producen por estos WG de mayor edad no resultan tan útiles como sus primeros productos.

4.3 Documentos de los Grupos de Trabajo

Existe una distinción oficial entre los borradores de los WG y los borradores independientes, aunque en la práctica no hay gran diferencia de procedimientos. Por ejemplo, muchas listas de correo también discuten borradores independientes (según lo crea conveniente el presidente del WG). Los presidentes de los WG deciden cuáles borradores se convertirán en borradores del WG y quiénes serán los autores o editores de dichos borradores, para lo cual normalmente se basan en una consulta con el WG y, en ocasiones, en una consulta con su Director de Área. Este proceso puede ser complejo cuando hay muchos interesados en escribir un borrador, aunque es igualmente complejo cuando nadie quiere hacerlo, incluso cuando el WG tiene como objetivo realizar un trabajo específico. Los procedimientos de los borradores de Internet se describirán con mayor detalle más adelante en este documento.

Algunos Grupos de Trabajo cuentan con documentos o grupos de documentos complejos (o ambas cosas). Eliminar todos los errores de uno o más documentos complejos es un tarea abrumadora. Para ayudar a resolver este problema, algunos Grupos de Trabajo utilizan “sistemas de seguimiento de incidentes”, es decir, listas en línea de los problemas aún no resueltos, el estado del problema, las soluciones propuestas, etc. Un sistema de seguimiento de incidentes ayuda a los WG a no olvidar las cosas importantes y resulta de gran ayuda cuando alguien luego pregunta por qué algo se hizo de una forma en particular.

En el caso de los documentos de los Grupos de Trabajo, el editor del documento trabaja bajo las órdenes del presidente del WG. A menudo hay más de un editor para cada documento del Grupo de Trabajo, especialmente cuando se trata de documentos complejos. El editor del documento es responsable de asegurar que su contenido refleje exactamente las decisiones del Grupo de Trabajo, en particular cuando se crea un nuevo protocolo o extensión. Si el editor del documento no sigue el consenso del WG, el presidente del WG deberá ejercer más presión para que los cambios estén acordes con el consenso o sustituirá al editor del documento por alguien más dispuesto a escuchar al Grupo. Conforme un documento del Grupo de Trabajo progresa, los participantes sugieren cambios en la lista de correo del Grupo correspondiente. Se espera que los editores del documento sigan la discusión y realicen cambios una vez que se llegue a un acuerdo.

Si un participante contribuye de manera significativa, el editor del documento o el presidente puede invitar a dicho participante a convertirse en coautor o coeditor del mismo, aunque esta adición deber ser aprobada por los presidentes del WG. Algunas veces los Grupos de Trabajo consideran varias alternativas antes de seleccionar un borrador de Internet en particular como documento del Grupo de Trabajo. A menudo los Grupos de Trabajo toman ideas de numerosas alternativas para crear un solo documento. En este caso el presidente determinará quién será reconocido como autor en la portada y quién será reconocido como en el cuerpo del documento.

Cuando un documento de un WG está listo para salir del Grupo, el presidente del WG designa un “guía” (“shepherd”) para que se haga cargo del proceso final. La función del guía de un documento se describe en [RFC4858].

4.4 Cómo prepararse para la reunión de un Grupo de Trabajo

Lo más importante que todos (principiantes y expertos) deberían hacer antes de asistir a una reunión del IETF es leer los borradores de Internet y las RFC con antelación. Las reuniones de los WG no tienen explícitamente una finalidad formadora sino que son instancias donde se desarrollan los documentos del grupo. Incluso si no tiene pensado decir aleonada en la reunión, debería leer o al menos echar un vistazo a los documentos del grupo para entender de qué se está hablando.

El presidente del WG es el responsable de la agenda de la reunión, que normalmente prepara con semanas de antelación. Si hay algo que quiere que se discuta en una reunión, asegúrese de decírselo a su presidente. Las agendas de todas las reuniones de los WG están disponibles en el sitio web del IETF, aunque algunos presidentes son algo laxos (e incluso negligentes) a la hora de enviarlas.

La Secretaría programa las reuniones de los WG con apenas unas semanas de antelación y muchas veces la programación sufre cambios de último momento. Si piensa a asistir a la reunión de un solo WG puede llegar a tener problemas con sus planes de viaje si el horario de la reunión cambia. Asegúrese de mantenerse al tanto de los últimos cambios en la agenda a la hora de reservar sus vuelos y alojamiento. Aunque, si lo piensa bien, quizá no debería viajar por la reunión de un solo WG. Lo más probable es que su conocimiento sea valioso para varios WG, asumiendo que haya leído sus borradores y RFC.

Si su nombre aparece en la agenda de alguna reunión presencial debería preparar algunas diapositivas. Pero no prepare un tutorial: se supone que los asistentes han leído los borradores con antelación. En todas las salas de reuniones hay proyectores que podrá usar para presentar desde su computadora portátil.

Un consejo sobre su presentación para una reunión de un WG o para su presentación en el plenario: aunque se trata de una práctica común fuera del IETF, no incluya el logotipo de su compañía en cada diapositiva. Al IETF no le gusta este tipo de publicidad corporativa (excepto cuando lo hace el patrocinador en la sesión plenaria). La mayoría de los presentadores ni siquiera coloca el logotipo de su empresa en la primera diapositiva. El IETF trabaja con contenido técnico, no con publicidad encubierta. Muchas veces las diapositivas son en blanco y negro para que sean más legibles y solo se usa color cuando añade claridad. Recuerde que el contenido es la parte más importante de las diapositivas, no cómo se presentan.

Algo quizás le resulte útil e incluso puede ser divertido durante las sesiones de los Grupos de Trabajo es seguir los comentarios en directo en la sala Jabber asociada con ese Grupo de Trabajo en particular. Los comentarios en vivo muchas veces se utilizan como base de las actas de la reunión, pero también pueden incluir chistes y otros aportes externos. Jabber es una tecnología gratuita de streaming basada en XML que se suele usar para mensajería instantánea. Puede encontrar sugerencias sobre clientes Jabber para diferentes plataformas en http://xmpp.org/xmpp-software/ Clientes. Las salas de chat de Jabber llevan el nombre del Grupo de Trabajo seguido de "@jabber.ietf.org". De hecho, estas salas están disponibles todo el año (no solo durante las reuniones del IETF) y algunas se utilizan durante todo el desarrollo de un protocolo.

4.5 Listas de correo de los Grupos de Trabajo

Como ya se ha mencionado anteriormente, las listas de anuncios y discusión del IETF son las principales listas de correo para las actividades del IETF. Sin embargo, existen muchas otras listas relacionadas con la labor del IETF. Por ejemplo, los Grupos de Trabajo tienen sus propias listas de discusión. Además, algunos debates técnicos a largo plazo se han trasladado de las listas del IETF a listas creadas especialmente para esos temas. Recomendamos seguir las discusiones de las listas de correo de los Grupos de Trabajo a cuya reunión desea asistir. Cuanto más trabajo se haga en las listas de correo electrónico, menos trabajo habrá que hacer en la reunión, lo que le permitirá tener más tiempo para otros intercambios profesionales (por ejemplo, asistir a Grupos de Trabajo fuera de su principal área de interés con el objetivo de ampliar su perspectiva).

Las listas de correo también ofrecen un foro para aquellos que desean seguir o contribuir a la labor del Grupo de Trabajo pero que no pueden asistir a las reuniones del IETF. Es por ello que los procedimientos del IETF exigen que todas las decisiones sean confirmadas por “la lista” y muchas veces, para cerrar una discusión, oirá a los presidentes de los WG decir “Preguntemos a la lista”.

Muchas listas de discusión del IETF usan mailman u otro gestor de listas de correo electrónico, Majordomo. Generalmente tienen una dirección “-request” que se ocupa de los detalles administrativos de unirse y abandonar la lista. (Consulte Section 2.3 para obtener más información acerca de mailman). Por lo general no se permite que estos temas administrativos aparezcan en las discusiones de las listas.

Las listas de discusión del IETF se archivan, es decir que todos los mensajes que se envían a las listas se almacenan automáticamente en un host que permite acceso anónimo vía HTTP o FTP. Muchos de estos archivos se encuentran en un listado disponible enftp://ftp.ietf.org/ietf-mail-archive o bien en un archivo web. Si no encuentra la lista que está buscando, envíe un mensaje a la dirección 0“-request” de la lista (no a la lista en sí). Los listados de los estatutos de los Grupo de Trabajo en http://datatracker.ietf.org/wg son también un recurso muy útil. En http://www.ietf.org/wg/concluded encontrará una lista de WG antiguos que ya han concluido.

Las listas de algunos WG limitan el tamaño de los mensajes, en particular para evitar que grandes documentos o presentaciones lleguen a las bandejas de entrada de todo el mundo. Vale la pena recordar que no todos los participantes tienen acceso a conexiones de banda ancha (e incluso aquellos que habitualmente tienen acceso a banda ancha leen su correo electrónico usando conexiones más lentas cuando viajan), de modo que se aprecian más los mensajes cortos. Se pueden publicar documentos como borradores de Internet; las presentaciones se pueden publicar en un sitio web controlado por el remitente o pueden enviarse individualmente a quienes que las soliciten. Algunos WG configuran sitios especiales donde guardar estos documentos, de modo que los remitentes puedan publicarlos primero allí y luego enviar la URL del documento a la lista.

4.6 Reuniones interinas de los Grupos de Trabajo

Los Grupos de Trabajo suelen tener reuniones interinas entre las reuniones del IETF. Las reuniones interinas no sustituyen a las reuniones del IETF — un grupo no puede decidir saltarse una reunión en un lugar a donde no desea ir y en vez de ello reunirse en Cancún (o algún otro sitio que le agrade) tres semanas después. Las reuniones interinas deben ser aprobadas por el AD y se deben anunciar al menos con un mes de antelación. El lugar y la fecha escogidos deben permitir que todo los participantes puedan acceder en pie de igualdad. Al igual que en las reuniones del IETF, alguien debe tomar notas y se debe registrar la asistencia. Las decisiones que se tomen, de forma tentativa, durante una reunión interina deben ser ratificadas en la lista de correo del Grupo de Trabajo.

En los últimos años, algunos Grupos de Trabajo han empezado a organizar “reuniones interinas virtuales” que se llevan a cabo de forma telefónica o en línea, no de forma presencial. Las reuniones interinas virtuales son ideales para que los Grupos de Trabajo se mantengan atentos entre las reuniones presenciales regulares del IETF. Además, el costo de asistir a estas reuniones es menor que el de asistir a una reunión presencial. Las reuniones interinas virtuales tienen los mismos requisitos de informes que las reuniones cara a cara.

EL IESG tiene normas sobre la notificación por adelantado del lugar y la fecha donde se realizarán las reuniones interinas de los Grupos de Trabajo, además de tener normas sobre cómo informar los resultados de las mismas. El objetivo de esas normas es que las reuniones interinas sean accesibles para el mayor número posible de miembros del Grupos de Trabajo y mantener la transparencia del proceso del Grupo de Trabajo.


5. BOF

Para formar un Grupo de Trabajo se necesita un estatuto y alguien capaz de presidirlo. Para ello se necesita gente interesada que pueda enfocar el estatuto y convencer al Director de Área de que el proyecto vale la pena. Las reuniones presenciales son útiles para esto. De hecho, pocos WG son iniciados por un Director de Área: la mayoría comienza luego de un BOF informal donde los asistentes han expresado interés en el tema.

Una reunión informal (BOF) debe ser aprobada por el Director de Área correspondiente antes de programarla. Si cree que necesita un nuevo WG, acérquese a un AD de manera informal con su propuesta y pídale su opinión. El siguiente paso consiste en solicitar un una sala en la siguiente reunión presencial del IETF. Obviamente, no es necesario esperar a esa reunión para ir adelantando trabajo, como por ejemplo configurar una lista de correo y empezar a discutir el estatuto.

Las reuniones de los BOF tienen un tono diferente a las reuniones de los WG. El objetivo de un BOF es asegurar la creación de un buen estatuto con buenos hitos y que haya bastante gente que quiera trabajar para crear estándares. Algunos BOF ya tienen con borradores de Internet en proceso, mientras que otros empiezan de cero.

La ventaja de tener un borrador antes del BOF es que ayuda a enfocar la discusión. Por otra parte, tener un borrador podría limitar lo que otros miembros del BOF desean hacer en el estatuto. Es importante recordar que la mayoría de los BOF se reúnen para obtener el apoyo necesario para crear un Grupo de Trabajo, no para obtener apoyo o ayuda para un documento en particular.

Muchos BOF no se convierten en WG por diferentes razones. Un problema común es que no hay suficientes personas dispuestas a ponerse de acuerdo sobre el enfoque a darle al trabajo. Otro motivo típico es que el trabajo no terminará convirtiéndose en un estándar — si, por ejemplo, los autores del documento no desean ceder el control de los cambios a un WG. (Discutiremos el control de cambios más adelante en este mismo documento). Solo se pueden programar dos reuniones BOF sobre un tema en particular, luego se debe formar un Grupo de Trabajo o el tema se debe abandonar.


6. Los Borradores de Internet y las RFC

Si participa por primera vez en una reunión del IETF y busca una RFC o un borrador de Internet en particular, diríjase a las páginas del Editor de RFC, http://www.rfc-editor.org/rfc.html. Ese sitio también incluye enlaces para solicitar recopilaciones de RFC, muchos de ellos con funciones de búsqueda. Si conoce el número de la RFC que está buscando, diríjase a las páginas del Editor de RFC, http://www.rfc-editor.org/rfc.html. Una buena fuente para los borradores de Internet es el sitio del IETF https://datatracker.ietf.org/doc, donde puede buscar por título o por palabras claves.

6.1 Cómo conseguir que se publique una RFC

Una de las preguntas más comunes que los veteranos oyen de los principiantes es “¿Cómo publico un estándar del IETF?” Una pregunta aún mejor sería “¿Debo escribir un estándar para el IETF?”, ya que la respuesta no siempre es afirmativa. Si decide intentar escribir un documento que se convierta en estándar del IETF, tenga en cuenta que el proceso general puede ser arduo, incluso cuando cada paso individual es relativamente sencillo. De todos modos mucha gente logra salir del proceso ilesa. Además, se han escrito muchas directrices que ayudan a los autores a salir con su ego más o menos intacto.

Una de las primeras cosas que debe decidir es si quiere que su documento se considere en un Grupo de Trabajo o si prefiere que se considere como una propuesta individual (es decir, no de un WG). A pesar de que la mayoría de los estándares provienen de los Grupos de Trabajo, algunos son el resultado de un esfuerzo personal: puede que no haya un Grupo de Trabajo apropiado o que el Grupo de Trabajo apropiado esté ocupado en otras cosas.

Cada estándar del IETF se publica como una RFC (Request for Comments) y cada RFC comienza como un Borrador de Internet (muchas veces llamados Internet Drafts, I-D o solo Drafts). Los pasos básicos para lograr que algo se publique como estándar del IETF son los siguientes:

  1. Publique el documento como borrador de Internet.
  2. Reciba los comentarios sobre el borrador.
  3. Edite el borrador sobre la base de los comentarios recibidos.
  4. Repita los pasos 1 al 3 varias veces.
  5. Pregunte a un Director de Área si debería presentar el borrador al IESG (si se trata de una presentación Individual). Si el borrador es un producto oficial del Grupo de Trabajo, el presidente del WG le pide a su AD que lo lleve al IESG.
  6. Si el Director de Área acepta la propuesta, se hace una revisión inicial y se pueden pedir actualizaciones antes de seguir adelante.
  7. Solicite revisiones de parte de los miembros del IETF en general. En particular, en algunas Áreas del IETF se han formado equipos de revisión para analizar los borradores que ya están listos para pasar al IESG. Dos de los equipos de revisión más activos son el de la Dirección de Seguridad (“SecDir”) y el Equipo de Revisión del Área General (Gen-Art). Recuerde que estas revisiones le ayudarán a mejorar la calidad de una eventual RFC.
  8. Hable de sus preocupaciones con los miembros de IESG. Sus preocupaciones se podrían resolver con una simple respuesta o quizá el documento necesite nuevas modificaciones.
  9. Espere a que el Editor de RFC publique el documento.

Puede encontrar una explicación más detallada de estos pasos en [BCP9], "El Proceso de los Estándares de Internet”. Quienes escriben un borrador y desean que se convierta en un estándar del IETF deben leer la BCP 9 para conocer el proceso que debe seguir el documento. Para seguir el progreso puede utilizar el IETF Datatracker http://datatracker.ietf.org. La BCP 9 (y otros documentos que la actualizan) describe detalladamente un tema que a menudo da lugar a malentendidos, incluso por parte de participantes del IETF muy experimentados: diferentes tipos de RFC tienen procesos y clasificaciones diferentes. Existen seis tipos de RFC:

Solo los dos primeros, es decir los propuestos y completos, se consideran estándares en el IETF. Puede leer un buen resumen de ello en el documento acertadamente titulado [RFC1796], "No todas las RFC son estándares".

También existen dos subseries de RFC, conocidas como BCP y STD. Las BCP (Best Current Practices o Mejores Prácticas Actuales) describen la aplicación de diferentes tecnologías en Internet y por lo general se utilizan para documentar las numerosas partes del proceso del IETF. La subserie de documentos llamados FYI (For Your Information o Para su información) consiste en “documentos informativos”, en el sentido de la enumeración anterior a los cuales se les han aplicado unas etiquetas especiales. (También existía una subserie de RFC “Para su información” creada para documentar los resúmenes y temas introductorios o que convocaban a un público amplio, pero esta serie está oficialmente cerrada).

La subserie STD RFC se creó para identificar a las RFC que sí especifican estándares de Internet. Algunos STD están formados por más de una RFC, por lo que designación “estándar” se aplica al conjunto de documentos.

6.2 Ceder el control con elegancia

La principal razón por la cual la gente no quiere que sus documentos pasen por el proceso de estandarización del IETF es que deben renunciar al control sobre los cambios en el protocolo. Es decir, apenas alguien propone que su protocolo se convierta en un estándar del IETF debe ceder completamente el control. Si hay acuerdo general, algunas partes del protocolo pueden cambiar por completo, se pueden eliminar secciones enteras, se pueden añadir cosas nuevas y hasta se puede cambiar el nombre.

A algunos autores les resulta difícil ceder el control sobre los cambios en su protocolo. Si usted se identifica con este tipo de autores, ni siquiera considere la idea de proponer que su protocolo se convierta en un estándar del IETF. Por el contrario, si su objetivo es crear el mejor estándar posible con la implementación más amplia posible, entonces el proceso del IETF es para usted.

Y por cierto, el control de cambios no termina cuando el protocolo ingresa al proceso de estandarización. El protocolo se puede modificar más adelante por diferentes motivos, siendo el más común que se descubra un problema al implementar el estándar. Estos cambios de último momento están bajo el control del IETF, no de los editores del documento.

El objetivo de los estándares del IETF es que se utilicen para escribir programas que sean interoperables. Estos estándares no existen para documentar las ideas de los autores ni para que una empresa pueda decir, “Tenemos un estándar del IETF”. Si una RFC tiene apenas una implementación en el proceso (cuando para que avance se necesitan dos), seguramente proponerla fue un error.

Tenga en cuenta que un autor no puede tomar el documento de otra persona y hacerlo pasar como suyo propio; consulte [BCP78], sección 5.6, punto (a).

6.3 Borradores de Internet

Empecemos por el principio. Todos los documentos que acaban en el repositorio de RFC comienzan siendo borradores de Internet. Estos documentos son muy preliminares — su objetivo es que los lectores hagan comentarios sobre los mismos de modo que los autores puedan pensar en los comentarios y decidir cuáles incorporar. Para que nadie se olvide de su naturaleza provisoria, después de seis meses los borradores de Internet se eliminan de manera automática de los directorios activos en línea. En realidad no son estándares. Como dice la [BCP9]:

"Un borrador NO es un medio para “publicar” una especificación; las especificaciones se publican a través del mecanismo del RFC… Los borradores de Internet no tienen ningún estado formal y están sujetos a cambios o eliminación en cualquier momento. Ningún artículo, informe o llamado a licitación debería hacer referencia a un borrador de Internet. Además, ningún proveedor debería reclamar que se cumpla con un borrador de Internet”.

Siempre se puede identificar a las personas que no entienden el IETF (o que intentan engañar a la gente) cuando presumen de haber publicado un borrador de Internet. Esto no requiere de un gran esfuerzo.

Al enviar un borrador de Internet usted cede ciertos derechos de publicación al IETF. Esto se hace para que su borrador esté disponible de forma gratuita para cualquier persona que desee leerlo o comentar sobre el mismo. Los derechos que cede o no cede a el IETF se describen en la [BCP78], "Derechos sobre las contribuciones al IETF".

Hay una herramienta muy útil en http://tools.ietf.org/tools/idnits. Si utiliza esta herramienta antes de enviar su borrador, evitará que éste sea rechazado debido a errores de forma y formato.

Un borrador de Internet (I-D) debería tener el mismo formato, aproximadamente, que una RFC. Al contrario de lo que mucha gente cree, no es necesario que un I-D sea igual a una RFC, no obstante lo cual podemos usar los mismos procedimientos de formato que usa el Editor de RFC para crear nuestros propios I-D. De esta forma se facilita la labor del Editor de RFC a la hora de publicar su borrador como RFC. La [RFC2223], "Instrucciones para autores de RFC” describe el formato de presentación. También existe una herramienta llamada "xml2rfc", disponible en http://xml.resource.org, que toma el texto en formato XML y lo convierte en un borrador de Internet válido.

El borrador de Internet puede ser un borrador de un Grupo de Trabajo o una propuesta individual. Los borradores de los Grupos de Trabajo suelen ser revisados por el propio WG antes de ser aceptados como documento del grupo, pero son los presidentes quienes tienen la última palabra.

Si le interesa conocer el estado de un borrador en particular, si no recuerda su nombre exacto o si desea saber en qué borrador está trabajando un Grupo de Trabajo dado, hay dos herramientas muy útiles que puede utilizar. La “Interfaz de la base de datos de borradores de Internet”, a la que puede acceder en https://datatracker.ietf.org/doc, permite buscar un borrador por su autor, Grupo de Trabajo, fecha o nombre de archivo. Resulta especialmente útil para los autores que quieren seguir el progreso de su borrador mientras avanza en el proceso de publicación.

Hay algunas reglas informales acerca de cómo dar nombre a los borradores de Internet que han evolucionado con el tiempo. Los nombres de los borradores de Internet que revisan una o más RFC existentes suelen incluir la partícula ”bis”, que significa “otra vez” o “dos veces". Por ejemplo, un borrador podría llevar el siguiente nombre: "draft-alguien-rfc2345bis-00.txt".

6.3.1 Lecturas recomendadas para los escritores

Antes de crear la primera versión de su borrador de Internet debería leer cuatro documentos:

También debería visitar la página de herramientas del IETF, http://tools.ietf.org, donde encontrará información acerca de otras herramientas que automatizarán parte de su trabajo para el IETF.

6.3.2 Nombres de archivos y otras cuestiones

Cuando esté listo para presentar su borrador de Internet, envíelo a ahttp://datatracker.ietf.org/submit. Las instrucciones que figuran en esa página web le guiarán paso a paso; además, hay una dirección de correo en caso que necesite ayuda personalizada.

Cuando envíe la primera versión del borrador debe indicarle al administrador del borrador el nombre que propone para el mismo. Si el borrador es un producto oficial de un Grupo de Trabajo, el nombre comenzará con "draft-ietf-" seguido por la designación del WG y una o dos palabras descriptivas seguidas de "00.txt".

Por ejemplo, un borrador del Grupo de Trabajo S/MIME acerca de la creación de claves se llamaría "draft-ietf-smime-keying-00.txt". Si no es el producto de un grupo de trabajo, el nombre empezará con "draft-" y el apellido de uno de los autores, seguido de una o dos palabras descriptivas y "00.txt". Por ejemplo, un borrador que escribió una persona llamada Smith, se titularía "draft-smith-keying-00.txt". Si el borrador se envía de forma individual pero está relacionado con un Grupo de Trabajo en particular, a veces los autores colocan su nombre junto al nombre del Grupo de Trabajo, como por ejemplo "draft-smith-smime-keying-00.txt". Si sigue las directrices sobre nomenclatura disponibles en http://www.ietf.org/ietf/1id-guidelines.txt, es muy probable que el nombre de archivo que sugiera sea aceptado.

Después de la primera edición del borrador, el número del nombre del archivo se incrementa. Por ejemplo, la segunda edición del borrador del S/MIME que mencionamos anteriormente pasaría a ser "draft-ietf-smime-keying-01.txt". Tenga en cuenta que hay casos en los que el nombre del archivo cambia después de una o dos versiones, como por ejemplo cuando un esfuerzo inicialmente individual es retomado por un Grupo de Trabajo. Cuando el nombre de un borrador cambia, el número vuelve a -00. Los presidentes del Grupo de Trabajo informarán al administrador de borradores de Internet el nombre que tenía el borrador antes del cambio para poder así mantener las bases de datos actualizadas y exactas.

6.4 Procedimiento para que una RFC se convierta en estándar

El procedimiento para crear y avanzar un estándar se describe en [BCP9]. Cuando un borrador de Internet se ha discutido en profundidad y existe consenso general de que su contenido sería un estándar útil, el borrador se presenta ante el IESG para su consideración. Si se trata de un borrador oficial de un Grupo de Trabao, el presidente del WG lo envía al Director de Área apropiado. Si se trata de una propuesta individual, el autor o editor del borrador lo envía al Director de Área apropiado. La BCP 9 también describe el proceso de apelación que deben seguir aquellas personas que piensan que un presidente de un Grupo de Trabajo, un AD o el IESG no ha tomado la decisión adecuada en relación con la creación o avance de un estándar.

Cuando el I-D se envía al IESG, el IESG anuncia una última llamada (muchas veces abreviada como “LC”, siglas de Last Call). Con ello buscan llamar la atención de quienes no estaban siguiendo el progreso del borrado y que podrían introducir más cambios al mismo. También es el momento para que aquellos que sienten que no se les ha escuchado debidamente presenten sus comentarios delante de todo el mundo. Un período de última llamada del IETF dura al menos dos semanas en el caso de los borradores de los WG y cuatro semanas en el caso de las propuestas individuales.

El objetivo de una última llamada del IETF es discutir estos documentos con toda la comunidad antes de que el IESG los considere. Pero cuidado con la palabra “discutir” usada en este contexto. En general se considera de mala educación enviar comentarios durante el período de última llamadas sobre documentos que no ha leído o enviar comentarios pero no estar dispuesto a debatir su punto de vista. La última llamada del IETF no es una votación, por lo que las campañas creadas para que la gente apoye o se oponga a un documento habitualmente fracasan. Dicho esto, los comentarios que se reciben en la última llamada provenientes de personas que han leído el documento por primera vez pueden llegar a poner en evidencia problemas que el IETF o los colaboradores del Grupo de Trabajo no habían visto hasta el momento, razón por la cual la discusión está abierta a todos quienes deseen participar.

Si el IESG aprueba un borrador para que se convierta en una RFC estándar, se le solicita al Editor de RFC que lo publique como estándar propuesto. En este momento pueden pasar suceder diferentes cosas. Primero, es común darse cuenta de que hay que reescribir algunas de las especificaciones del estándar porque un programador interpretó una cosa mientras que otro programador interpretó algo completamente distinto. Otra ocurrencia habitual es que ninguna de las implementaciones realmente intentó implementar algunas de las funciones del estándar, por lo que dichas funciones se eliminan – no solo porque nadie las ha probado, sino porque son innecesarias.

No se sorprenda si un estándar en particular no pasa de ser un estándar propuesto a ser un estándar de Internet. Para convertirse en un estándar de Internet una RFC debe tener múltiples implementaciones interoperables y se deben eliminar las funciones del estándar propuesto que no se utilizan. También existen requisitos adicionales que se listan en [BCP9]. La mayoría de los estándares de uso generalizado son estándares propuestos que nunca avanzan más allá. Esto se puede deber a que nadie dedica el tiempo suficiente para que se conviertan en estándares de Internet, a que otros estándares a los cuales hacen referencia todavía son estándares propuestos, o a que la gente tiene otras cosas más importantes que hacer.

6.4.1 Usar la terminología apropiada — Uso de MUST, SHOULD y MAY

Escribir especificaciones de manera que se implementen como el autor lo desea es un verdadero arte. Puede escribir una especificación muy breve, apenas una lista de requisitos, pero esto suele tener como consecuencia que los programadores la implementan demasiado libremente. Por el contrario, si crea especificaciones con demasiado texto, sugerencias, etc., los programadores suelen no tomar en cuenta todos los requisitos (y a menudo no están de acuerdo con las sugerencias). Las especificaciones óptimas se encuentran a mitad de camino entre estos dos tipos.

Una manera de aumentar las probabilidades de que los operadores creen implementaciones interoperables de los estándares es ser claro respecto de lo que ordena la especificación. Las primeras RFC usaban todo tipo de expresiones para explicar qué había que hacer, de modo que los programadores no siempre sabían qué partes eran sugerencias y qué partes eran requisitos. Como resultado, en términos generales, los escritores de estándares del IETF acordaron limitar sus escritos a unas pocas palabras específicas y con un significado específico.

Escrita en 1989, [STD3], "Requisitos para hosts de Internet: solicitud y soporte” incluía una breve lista de términos que parecían ser muy útiles: "must", "should" y "may" (“debe”, “debería” y "puede"). Estas definiciones se actualizaron y se concretaron aún más en [BCP14], "Palabras clave para su uso en RFC con el objeto de indicar niveles de requisitos", documento al que se hace referencia a menudo en los estándares de Internet actuales. La BCP 14 también define específicamente los términos “must not” y “should not” (“no debe” y “no debería”) y ofrece una lista de algunos sinónimos de las palabras definidas.

Cuando redacte un estándar, para estar seguro de que está usando las definiciones de la BCP 14, hay dos cosas que debe hacer. Primero, haga referencia a la BCP 14 (aunque la mayoría hace referencia a la RFC 2119, porque es lo que dice la BCP 14), de modo que el lector sepa cómo está definiendo los términos que utiliza. Segundo, señale qué instancias de las palabras que utiliza se toman de la BCP 14. La práctica aceptada consiste en escribir estas palabras en mayúsculas. Es por ello que en los estándares de la IETF se suelen ver las palabras “MUST” y “SHOULD” en mayúsculas.

La BCP 14 es un documento breve que debería tener en cuenta cualquier persona que lea o escriba estándares para el IETF. Aunque la definición de los términos “must” y “must not” es bastante clara, la definición de “should” y “should not” suele causar grandes confusiones en muchos Grupos de Trabajo. Al revisar un borrador de Internet suele surgir la siguiente pregunta: “¿Esa frase debería ser MUST o SHOULD?" De hecho, esta es una muy buena pregunta, ya que las especificaciones no deberían abusar del MUST, pero tampoco deben usar SHOULD en lugar de MUST cuando la interoperabilidad así lo requiera. Esto hace al meollo de la cuestión – especificar mucho o especificar poco los requisitos de un estándar.

6.4.2 Referencias normativas en los estándares

Un aspecto de la redacción de los estándares del IETF que confunde a muchos principiantes (y también a algunos participantes experimentados) es la regla que especifica cómo hacer “referencias normativas” a documentos que no son del IETF o a otras RFC en un estándar. Una referencia normativa es una referencia a un documento que se debe seguir para implementar un estándar. Una referencia no normativa (a veces llamada “referencia informativa”) es una referencia que es útil para el programador pero que no es imprescindible.

Un estándar del IETF puede hacer referencia normativa a cualquier otra RFC estándar que tenga el mismo nivel o un nivel superior al del estándar en cuestión, o a cualquier “estándar abierto” que se haya desarrollado fuera del IETF. La regla del “mismo nivel o un nivel superior” significa que antes de que un estándar pueda pasar de propuesto a borrador, todas las RFC para las cuales existe una referencia normativa también deben ser borradores o estándares de Internet. Esta regla, la cual se describe en la [BCP97], asegura a los programadores que lo que se describe en un estándar de Internet sea bastante estable, incluso las cosas referenciadas fuera del estándar. Sin embargo, esto también puede retrasar la publicación del borrador o estándar de Internet varios meses (a veces incluso años) mientras los documentos se actualizan.

No hay una manera rápida y sencilla de determinar qué se considera un “estándar abierto”, pero en general se refiere a un estándar estable que todo el mundo puede copiar (aunque tengan que pagar por ello) y que fue creado por una organización de estandarización reconocida. Si el estándar externo cambia, su especificación debe hacer referencia a la versión particular de ese estándar, por ejemplo, designando la fecha del estándar. Algunos organismos de estandarización externos sacan de circulación los estándares antiguos, lo que supone un problema para los estándares del IETF que deban utilizarse en el futuro. En caso de duda, el autor del borrador debería preguntar al presidente del WG o al Director de Área apropiado si un estándar externo determinado se puede usar en un estándar del IETF.

6.4.3 Consideraciones para la IANA

Cada vez más estándares del IETF requieren registrar diferentes parámetros de los protocolos, también llamados opciones de protocolo. Como mencionamos en Section 2.2.4, el principal registro de todos los estándares del IETF ha sido la IANA. Debido a la gran cantidad y variedad de registros necesarios para los estándares, la IANA debe tener información específica sobre cómo registrar los parámetros, qué no registrar, quién decide qué se registrará (si alguien lo hace), etc.

Cualquier persona que escriba un estándar de Internet y que necesite un registro nuevo de la IANA o nuevos valores de un registro actual de IANA debe leer la [BCP26], "Directrices para escribir una sección de consideraciones para la IANA en una RFC”, que describe cómo los autores de una RFC deberían solicitar a la IANA que inicie o que se haga cargo de un registro. La IANA también mantiene registros que se iniciaron mucho antes de la existencia de la BCP 26.

6.4.4 Consideraciones sobre seguridad

Un requisito obligatorio para cualquier RFC y borrador de Internet es incluir una sección de “Consideraciones sobre seguridad”. Esta sección debería describir cualquier vulnerabilidad conocida del protocolo, posibles amenazas y mecanismos o estrategias para tratarlos. No minimice la importancia de esta sección — en particular, no diga “Aquí está nuestro protocolo, si quiere seguridad utilice IPsec”. Esto no funciona porque no responde a la pregunta de cómo interactúa IPsec con su protocolo y viceversa. Consulte la [BCP72], "Directrices para escribir el texto de una RFC sobre las consideraciones de seguridad” para obtener más información sobre cómo escribir esta sección.

6.4.5 Patentes en los estándares del IETF

En los últimos años los problemas relacionados con la propiedad intelectual han surgido cada vez con mayor frecuencia, en particular con respecto a las patentes. El objetivo del IETF es contar con estándares que se utilicen ampliamente y que sean validados en el mercado. Si para crear un producto que usa un estándar es necesario obtener una licencia de una patente, es poco probable que alguien implemente este estándar. Por lo tanto, no debe sorprender a nadie que la regla general haya sido siempre “usar buena tecnología no patentada siempre que sea posible".

Obviamente, esto no siempre es posible. Algunas veces las patentes aparecen después de haber establecido un estándar. A veces lo que está patentado es tan valioso que no existe un equivalente no patentado. A veces el titular de la patente es generoso y promete ofrecer una licencia gratuita de la patente a los programadores, con lo cual la implementación es tan fácil como si no hubiese existido la patente.

Los métodos del IETF para tratar con las patentes en los estándares se han debatido exhaustivamente. Las reglas oficiales sobre los derechos de propiedad intelectual (IPR) en los documentos del IETF (no solo patentes) se tratan en la [BCP78] y [BCP79], "Derechos de propiedad intelectual en la tecnología del IETF". Es probable que estos documentos sean de interés para todos aquellos que participan en los Grupos de Trabajo del IETF, ya que describen las normas que todo el mundo acepta seguir.

Los titulares de patentes que permiten que quienes implementan los estándares del IETF utilicen libremente sus patentes suelen ganarse la buena voluntad de los miembros del IETF. Y esta generosidad es más común de lo que podría pensarse. Por ejemplo, la RFC 1822 es una licencia de IBM para una de sus patentes de seguridad en el contexto de un protocolo en particular y por ello la comunidad de seguridad ha respondido muy favorablemente a IBM (mientras que a varias empresas se les ha dado la espalda por su inflexibilidad con respecto a sus patentes de seguridad).

Si está escribiendo un borrador de Internet y conoce una patente que se aplica a la tecnología sobre la que está escribiendo, no mencione la patente en el documento. Consulte la página sobre propiedad intelectual del IETF en http://www.ietf.org/ipr para determinar cómo proceder. Los derechos de propiedad intelectual no se mencionan en las RFC porque, una vez publicadas, las RFC no se modifican, pero el conocimiento de los derechos de propiedad intelectual puede variar en cualquier momento. Por consiguiente, cualquier lista de derechos de propiedad intelectual en una RFC sería incompleta y engañaría al lector. La [BCP79] provee un texto específico que se debería añadir en las RFC cuando el autor es conciente de que existen problemas relacionados con los derechos de propiedad intelectual.

6.5 RFC informativas y experimentales

Como ya hemos comentado anteriormente, no todas las RFC son estándares. De hecho, muchas RFC de gran importancia no están siquiera en proceso de convertirse en estándares. Actualmente existen dos designaciones para las RFC que no son estándares: informativas (como el Tao) y experimentales. (En realidad existe una tercera designación (históricas) que se utiliza para documentos que estaban en la lista de estándares y que se han eliminado debido a su falta de uso o debido a que investigaciones recientes indican que se trata de una tecnología dañina para Internet).

La función de las RFC informativas se debate a menudo en el IETF. Muchos desean tenerlas, en particular para especificaciones que fueron creadas fuera del IETF pero a las que se hace referencia en los documentos del IETF. También son útiles para especificaciones que fueron precursoras de la labor que hacen los Grupos de Trabajo del IETF. Por otra parte, hay quienes llaman a las RFC informativas “estándares” aunque no lo sean, habitualmente para engañar al público con respecto a algo que intentan vender o apoyar. Cada vez que esto sucede, el debate sobre las RFC informativas se renueva.

Las RFC experimentales son para especificaciones que pueden ser interesantes pero que no está claro si existe mucho interés en implementarlas o si funcionarán una vez desplegadas. Es decir, si es posible que una especificación pueda resolver un problema, aunque no quede claro si muchos consideran ese problema como algo importante o que vale la pena molestarse en resolver con la especificación, esta especificación será una RFC experimental. Si más adelante la especificación se vuelve popular (o demuestra que funciona bien), se puede volver a publicar como RFC estándar. Las RFC experimentales también se usan para que la gente experimente con una tecnología que podría convertirse en estándar, pero para la cual aún quedan preguntas por responder.

El IESG ha creado directrices sobre cómo elegir entre el estado informativo o experimental: http://www.ietf.org/iesg/informational-vs-experimental.html. Si está creando un documento que piensa que podría convertirse en una RFC experimental, conocer la forma de pensar actual podría ayudarle a justificar la elección que haya tomado.


7. Cómo contribuir al IETF

7.1 Qué puede hacer usted

Leer — Revise los borradores de Internet que están dentro de su área de conocimiento y comente sobre ellos en los Grupos de Trabajo. Participe en las discusiones de manera amable y atenta con el objetivo de obtener el mejor estándar de Internet posible. Escuche más de lo que hable. Si no está de acuerdo, debata los problemas técnicos pero no ataque a las personas.

Implementar — Escriba programas que utilicen estándares de Internet actuales. Los estándares no valen nada si no están disponibles para los usuarios de Internet. Implemente incluso los estándares “menores”, ya que si aparecen en más programas se volverán importantes. Informe los problemas que encuentre al Grupo de Trabajo apropiado para que el estándar se aclare en versiones posteriores. Uno de los principios más citados del IETF es “el código que se ejecuta es el ganador”, de modo que puede apoyar los estándares que quiere que se popularicen creando más código que se ejecute. Puede contribuir al desarrollo de protocolos antes de que se conviertan en estándares mediante la implementación (pero no el despliegue) de I-D para asegurar que los autores hayan hecho un buen trabajo. Si no encuentra errores u omisiones, proponga mejoras basadas en su experiencia de implementación.

Escribir — Edite o participe como coautor de borradores de Internet en su área de especialización. Hágalo para beneficiar a la comunidad de Internet, no para que su nombre aparezca en un documento (o incluso peor, el de su compañía). Los autores de los borradores se exponen a todo tipo críticas técnicas (y a veces también personales); recíbalas con ecuanimidad y úselas para mejorar su borrador de manera de producir el mejor estándar posible y el más interoperable.

7.2 Qué puede hacer su empresa

Compartir — Evite los estándares propietarios. Si es programador, muestre una marcada preferencia por los estándares del IETF. Si los estándares del IETF no son tan buenos como los propietarios, trabaje para mejorar los estándares del IETF. Si es comprador, evite los productos que utilicen estándares propietarios que compitan con los estándares abiertos del IETF y comente a las empresas a quienes les compra por qué lo está haciendo.

Abrirse — Si su empresa controla una patente que se utiliza en un estándar del IETF, convenza a su empresa para que la patente esté disponible sin costo para todos aquellos que implementen el estándar. En los últimos años, las patentes han causado muchos problemas a los estándares de Internet porque evitan que algunas empresas puedan implementar los estándares libremente. Por suerte, muchas empresas han ofrecido generosamente licencias ilimitadas para ciertas patentes en particular a fin de ayudar a que los estándares del IETF florezcan. Para estas empresas la recompensa suele ser publicidad positiva por el hecho de no ser tan codiciosas ni tener tan poca visión de futuro como otros titulares de patentes.

Asociarse — Hágase miembro de ISOC. Más importante aún, aliente a las empresas que se han beneficiado de Internet a convertirse en miembros corporativos de ISOC, ya que esto supone el mayor beneficio financiero para el grupo y, por supuesto, también beneficiará a la Internet en general.


8. El IETF y el mundo exterior

8.1 El IETF y otros grupos de estándares

A pesar de que a muchos participantes del IETF les gustaría pensar lo contrario, el IETF no existe en el vacío. Hay muchas otras (quizá demasiadas) organizaciones de estandarización cuyas decisiones afectan a Internet. También hay algunos organismos de normalización que ignoraron Internet durante un tiempo y que ahora quieren tener participación en el tema.

En general, el IETF intenta mantener relaciones cordiales con otras organizaciones de normalización. Eso no siempre es fácil, ya que muchas otras organizaciones tienen una estructura diferente al IETF y el IETF está principalmente dirigido por voluntarios que probablemente prefieren escribir estándares a reunirse con representantes de otras organizaciones. Aún así, hay otras organizaciones de normalización que se esfuerzan para interactuar bien con el IETF a pesar de sus obvias diferencias culturales.

En el momento de escribir este documento, el IETF colaboraba con grandes organizaciones de normalización, entre ellas la UIT-T (la sección de normalización sobre telecomunicaciones de la Unión Internacional de Telecomunicaciones), el W3C (World Wide Web Consortium), el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) y el consorcio Unicode. Tal como se especifica en el estatuto del IAB [BCP39], "Las colaboraciones son lo más informales posibles y deben tener un valor demostrado a la hora de mejorar la calidad de las especificaciones del IETF". En la práctica, el IETF prefiere las colaboraciones directamente a nivel de Grupos de Trabajo, dejando en segundo plano las relaciones formales y los documentos de colaboración.

Algunas de esas tareas de colaboración competen al IESG mientras que otras competen al IAB. Un lector detallista aprenderá mucho acerca de los métodos formales para tratar con otras organizaciones de normalización en la [BCP102], "Procesos de IAB para la gestión de las relaciones de colaboración del IETF” y la [BCP103], "Procedimientos para manejar las declaraciones de colaboración desde y hacia el IETF". El mejor lugar para comprobar si el IETF tiene alguna colaboración formal es la lista de colaboraciones del IETF, http://www.ietf.org/liaison. Esta lista muestra que existen muchas colaboraciones diferentes con los subcomités ISO/IEC JTC1.

8.2 Cobertura periodística del IETF

El IETF es una de las organizaciones más conocidas que contribuyen al progreso de Internet, por lo que es natural que la prensa especializada en informática (e incluso la prensa comercial) quiera cubrir sus movimientos. En los últimos años, algunas revistas han asignado periodistas y editores para cubrir el IETF en profundidad durante un largo periodo de tiempo. Estos periodistas ya pasaron por la experiencia de escribir artículos incorrectos, hacer declaraciones equivocadas sobre el estado de los borradores de Internet, citar a personas no relacionadas con la labor del IETF, Etty muchas otras.

Los principales errores que comete la prensa se pueden agrupar en dos categorías: decir que el IETF está considerando algo cuando de hecho se trata de un borrador de Internet preparado por un Grupo de Trabajo y decir que el IETF ha aprobado algo cuando solo se ha publicado una RFC informativa. En ninguno de los dos casos la culpa es exclusivamente de la prensa, puesto que por lo general una empresa les avisa de la historia de un protocolo que quiere publicitar y que la empresa ha desarrollado o apoya. Está claro que los periodistas podrían investigar un poco y ponerse en contacto con alguien que les pudiera ofrecer información fidedigna, como por ejemplo el presidente de un Grupo de Trabajo o un Director de Área. El primer lugar que la prensa debería consultar para obtener contactos de prensa del IETF es <http://www.ietf.org/media.html>.

El hecho de que estos periodistas que se han equivocado regresen a las reuniones del IETF demuestra que es posible hacer las cosas bien. No obstante, las reuniones del IETF no son para periodistas que no conocen el proceso del IETF (aunque si es usted un periodista, el hecho de que esté leyendo este documento es una buena señal). Además, si piensa que obtendrá un titular asistiendo a una reunión del IETF, lo más seguro es que se sienta decepcionado.

Teniendo en cuenta lo anterior, no es sorprendente que algunos miembros del IETF prefieran que la prensa se mantenga lo más posible de las reuniones. Obtener un poco de publicidad en la prensa para los protocolos que se están por completar y que en los próximos años serán significativos para la industria puede ser una buena cosa. Sin embargo, pocos periodistas pueden resistir la tentación de escribir un artículo elogiando un protocolo en ciernes como si se tratara del próximo salvador de Internet. Este tipo de historias son más dañinas que otra cosa, tanto para los lectores del artículo como para el IETF.

La principal razón por la que un periodista querría asistir a una reunión del IETF no es para cubrir las tecnologías candentes (eso puede hacerlo desde la comodidad de su oficina simplemente leyendo las listas de correo) sino para conocer personalmente a los participantes. Desafortunadamente, los participantes más interesantes son también los más ocupados durante las reuniones del IETF. Además, algunas personas tienden a salir corriendo en dirección contraria cuando ven una credencial de prensa. Sin embargo, las reuniones del IETF son una excelente oportunidad para conocer y hablar con los autores de los documentos y los presidentes de los Grupos de Trabajo, algo que resulta valioso para los periodistas que cubren el progreso de los protocolos.

Se aconseja a los periodistas que quieran saber “qué está haciendo el IETF” sobre un tema en particular que hablen con más de una persona que esté participando activamente en el tema. También deberían hablar con el presidente del Grupo de Trabajo. Es imposible determinar qué pasará con un borrador simplemente mirándolo o hablando con el autor. Afortunadamente, todos los WG tienen archivos que un periodista puede revisar con indicaciones recientes sobre el progreso de los borradores; desafortunadamente, pocos periodistas tienen el tiempo o las ganas de hacer este tipo de investigación. Puesto que el IETF no colabora con la prensa, las revistas o periódicos que publican una historia con errores no tendrán noticias directas del IETF y, por consiguiente, no sabrán qué han hecho mal, con lo que podrían repetir el mismo error.


9. Consideraciones sobre seguridad

Section 6.4.4 explica por qué es necesario que todas las RFC tengan una sección de consideraciones de seguridad y da ideas sobre lo que debería y no debería contener esta sección. Aparte de esa información, este documento no aborda la seguridad en Internet.

10. Informative References

[BCP9] Bradner, S., “The Internet Standards Process -- Revision 3”, BCP 9, RFC 2026, RFC 6410, October 1996.
[BCP10] Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees”, BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, “The Organizations Involved in the IETF Standards Process”, BCP 11, RFC 2028, October 1996.
[BCP14] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[BCP22] Scott, G., “Guide for Internet Standards Writers”, BCP 22, RFC 2360, June 1998.
[BCP25] Bradner, S., “IETF Working Group Guidelines and Procedures”, BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
[BCP39] Internet Architecture Board and B. Carpenter, “Charter of the Internet Architecture Board (IAB)”, BCP 39, RFC 2850, May 2000.
[BCP45] Harris, S., “IETF Discussion List Charter”, BCP 45, RFC 3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, July 2003.
[BCP78] Bradner, S., “IETF Rights in Contributions”, BCP 78, RFC 5378, November 2008.
[BCP79] Bradner, S., “Intellectual Property Rights in IETF Technology”, BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., “A Mission Statement for the IETF”, BCP 95, RFC 3935, October 2004.
[BCP97] Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level”, BCP 97, RFC 3967, December 2004.
[BCP101] Austein, R. and B. Wijnen, “Structure of the IETF Administrative Support Activity (IASA)”, BCP 101, RFC 4071, April 2005.
[BCP102] Daigle, L. and Internet Architecture Board, “IAB Processes for Management of IETF Liaison Relationships”, BCP 102, RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, “Procedures for Handling Liaison Statements to and from the IETF”, BCP 103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, “Not All RFCs are Standards”, RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, “Instructions to RFC Authors”, RFC 2223, October 1997.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority”, RFC 2860, June 2000.
[RFC6635] Kolkman, O. and J. Halpern, “RFC Editor Model (Version 2)”, RFC 6635, March 2012.
[RFC4677] Hoffman, P. and S. Harris, “The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force”, RFC 4677, September 2006.
[RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, “Document Shepherding from Working Group Last Call to Publication”, RFC 4858, May 2007.
[RFC6722] Hoffman, P., “Publishing the "Tao of the IETF" as a Web Page”, RFC 6722, August 2012.
[STD3] Braden, R., “Requirements for Internet Hosts - Application and Support”, STD 3, RFC 1123, October 1989.

A. Principios rectores del IETF

Si ha llegado hasta este punto del Tao, ya ha aprendido muchas cosas sobre el funcionamiento del IETF. Lo que encontrará en este apéndice resume gran parte de lo que ha leído y añade un par de puntos que debería considerar. Asegúrese de leer todos los principios; si los toma como un todo, le darán una nueva perspectiva sobre qué es lo que hace que el IETF funcione.

A.1 Generales

El IETF funciona con un proceso abierto y sobre la base del consenso general. Esto se aplica a todos los aspectos del funcionamiento del IETF, incluso a la creación de documentos y a las decisiones sobre los procesos que se utilizan. Pero el IETF también observa con gran interés los experimentos y el código en ejecución. Esto también se debería aplicar a los procesos operativos de la organización.

El IETF trabaja en áreas en las que tiene, o puede encontrar, competencia.

El IETF depende de un núcleo voluntario de participantes activos.

Para participar en el IETF o en sus Grupos de Trabajo no es necesario pagar ninguna tasa. No se trata de un proceso definido desde el punto de vista organizativo, sino que se basa en la autoidentificación y participación activa de los individuos.

A.2 Gestión y liderazgo

El IETF reconoce posiciones de liderazgo y concede el poder de decisión a los líderes. No obstante, las decisiones están sujetas a apelación.

La delegación de autoridad y responsabilidad es esencial para que el IETF sea efectivo. Se alentará a tantas personas como sea posible para que asuman el liderazgo de las tareas del IETF.

Las discrepancias, quejas y apelaciones son consecuencia de la naturaleza del IETF y deberían considerarse eventos normales. Por último, hay que aceptar que ciertas decisiones no se pueden apelar de manera efectiva.

Las posiciones de liderazgo tienen una duración fija (aunque no hay ninguna limitación formal del números de veces que puede ocuparse un cargo).

Es importante desarrollar a los líderes futuros dentro de la comunidad activa.

Para seleccionar el liderazgo se utiliza un proceso comunitario.

Los líderes están capacitados para decidir si se ha llegado a un consenso general. Sin una membresía formal, no existen normas formales de consenso.

A.3 Proceso

Aunque el IETF necesita un proceso claro y públicamente documentado para los casos normales, también debería existir flexibilidad suficiente para que los casos inusuales se manejen con sentido común. Aplicamos nuestro criterio personal y solo escribimos código cuando estamos seguros. (Pero sí codificamos quiénes pueden tomar decisiones personales).

El trabajo de desarrollo técnico debería ser llevado a cabo en Grupos de Trabajo específicos con estatutos definidos.

Las partes del proceso que han demostrado ser poco prácticas se deberían eliminar o convertir en opcionales.

A.4 Grupos de Trabajo

Los Grupos de Trabajo deberían tener como principal responsabilidad la calidad de sus resultados; apoyados por el liderazgo del IETF, los presidentes de los Grupos de Trabajo deberían actuar como respaldo de la calidad.

Los Grupos de Trabajo deberían ser responsables de evaluar el impacto negativo de su labor en Internet y, por consiguiente, de obtener revisiones de otras áreas. El liderazgo del IETF debería actuar como respaldo de múltiples áreas.

Una pronta revisión de los documentos, en particular por parte de los Grupos de Trabajo, es más efectiva a la hora de tratar grandes problemas que una revisión tardía.

Los Directores de Área (AD) son responsables de guiar la formación y la creación de Grupos de Trabajo, de darles instrucciones siempre que sea necesario y de finalizarlos. Los presidentes de los Grupos de Trabajo responden al AD responsable.

Los presidentes de los Grupos de Trabajo son responsables de asegurar que los Grupos de Trabajo cumplan con lo dispuesto en sus estatutos, alcancen sus objetivos y creen productos listos para su publicación. Los editores de documentos responden a los presidentes de los Grupos de Trabajo.

Los Directores de Área son responsables de organizar las revisiones de respaldo y la aprobación final del documento.

A.5 Documentos

Con frecuencia los estándares del IETF comienzan como borradores personales, pueden convertirse en borradores de un WG y son aprobados para su publicación permanente por un cuerpo de liderazgo independiente del WG o de las personas que produjeron el documento.

Los estándares del IETF pertenecen a la comunidad, no a sus autores. De todos modos, la autoría se reconoce y se valora, al igual que se valoran las contribuciones menores que no llegan a ser de autoría.

La calidad y la corrección técnica son los principales criterios para alcanzar un consenso sobre los documentos.

Las especificaciones del IETF se pueden publicar como Informativas, Experimentales, Estándares, Históricas o Mejores Prácticas Actuales.

Las especificaciones estándares del IETF no se consideran estándares satisfactorios hasta que se haya demostrado que son implementaciones interoperables e independientes. (Esta es la materialización del slogan del “código en ejecución”.) Sin embargo, el IETF no se hace responsable de las pruebas de interoperabilidad ni certifica la interoperabilidad.

Los procesos del IETF se publican como Mejores Prácticas Actuales.

La información útil que no es una especificación ni un proceso se puede publicar como Informativa.

Las especificaciones y procesos obsoletos o que han caído en desuso pueden pasar a ser Históricos.

El proceso de estandarización debería distinguir las especificaciones que demuestran su interoperabilidad.

Los documentos de estándares y mejores prácticas deben someterse al consenso general del IETF (proceso de última llamada). Normalmente, para los demás documentos el consenso general del Grupo de Trabajo es suficiente.

Los cambios sustanciales introducidos durante la última llamada o evaluación del IESG deben ser llevados nuevamente con el Grupo de Trabajo.

El IETF determina los requisitos para la publicación y archivo de sus documentos.