Estructura del IETF y procesos
de estandarización en Internet
Transparencias originales de:
Scott Bradner
(traducción de Marcelo Bagnulo)
LACNIC 18
Montevideo, URUGUAY
Agenda
Panorámica e historia del IETF
Rol y alcance del IETF
Estructura del IETF y de los grupos asociados
Gestión y selección del IETF
Procesos y procedimientos del IETF
Una sesión de un grupo de trabajo
Derechos de propiedad intelectual (IPR)
El IETF
Internet Engineering Task Force
Formado en 1986
Evoluciona a partir de las actividades del gobierno de los
USA relacionadas con ARPANET
Internet Configuration Control Board (ICCB) (1979) and Internet
Activities Board (1983)
No fue considerado como algo importante durante
mucho tiempo – bien!!
No fue “aprobado” por ningún gobierno – Muy bien!!
Pero, tuvo apoyo económico del gobierno de los USA hasta 1997
Personas y no compañías
“We reject kings, presidents and voting. We believe in
rough consensus and running code”
Dave Clark (1992)
Panorámica del IETF
Somos los estándares de Internet
la mayoría de los estándares relacionados con
Internet han sido desarrollados o son mantenidos por
el IETF
No se incluyen los estándares relacionados con la capa física
No existe (en el sentido legal), sin miembros, ni votos
El IETF es “una actividad organizada de la Internet
Society”
1K a 1.5K personas en 3 reuniones por año
Muchos muchos más en las listas de correo
Participación en el IETF
Equipo de trabajo del IETF
Alrededor de 134 grupos de trabajos (WGs) (donde se
realiza el trabajo)
Cualquiera puede participar en los grupos de trabajo
8 áreas (por comodidad organizativa) con Directores
de Area (ADs)
APS, GEN, INT, O&M, RAI, RTG, SEC, TSV
Internet Engineering Steering Group (IESG): dirección
(ADs + IETF Chair)
Internet Architecture Board (IAB): supervisión
arquitectónica y enlaces
El IETF produce estándares y otros documentos
“Estándares” del IETF
Estándares del IETF: no son estándares “porque nosotros
lo decimos”
Son estándares sólo si la gente los usa
Las organizaciones de estandarización formales pueden
crear estándares que deben usarse por ley
Los estándares del IETF no son reconocidos formalmente
Por gobiernos o por organizaciones de estandarización
aprobadas
pero algunos estándares de los gobiernos los refieren
La falta de participación formal de los gobiernos es un
“problema”
al menos para algunos gobiernos
El rol y el alcance del IETF
‘por encima de los cables y por debajo de la
aplicación’
IP, TCP, email, routing, IPsec, HTTP, FTP, ssh, LDAP,
SIP, mobile IP, ppp, RADIUS, Kerberos, streaming
video & audio, ...
pero los cables se están volviendo más difusos
MPLS, GMPLS, pwe3, VPN, ...
en general es difícil el alcance del IETF
El IETF está constantemente explorando los límites
e.g. Telefonía (IP)
Alcance de otras SDOs
Internet (y sus protocolos) son muy atractivos para otras
organizaciones de estandarización (SDOs)
Internet se ha convertido en la base del negocio de las
telecomunicaciones
otras SDOs intentan “arreglar” o “extender” los protocolos
del IETF
Pueden intentar solucionar un problema diferente
o hacen distintos supuestos
problema:¿qué ocurre cuando esas extensiones rompen los
supuestos originales y hay problemas para interoperar?
SDO (incluyendo IETF) asumen: cada SDO modifica sus
propios protocolos
ver los problemas pasados con la ITU-T sobre MPLS
Organización del IETF
Internet
Society
IAD
IESG
IASA
IAB
IRTF
RFC
IANA
IANA
“el IETF”
area
area
area
La Internet Society (ISOC)
Organización sin fines de lucro, no gubernamental,
independiente e internacional
más de 130 organizaciones miembros & más de 55,000
miembros individuales & unos 90 capítulos en 72 países
formada en 1992 con el objetivo de:
proveer marco legal para el IETF
Continuar los workshops Landwebber para los países en
vías de desarrollo
En la actualidad:
“dedicada a asegurar el desarrollo abierto, la evolución y
el uso de Internet para el beneficio de la gente en todo el
mundo”
únete en ww.isoc.org
ISOC, cont.
IETF acepta el marco legal del ISOC en 1996
después de una (larga) discusión en un grupo de trabajo
ISOC es ahora el marco administrativo y organizativo
del IETF
marco legal, seguro, IASA, empleador del IAD, etc.
ISOC Board of Trustees es parte de la cadena de
apelaciones
El presidente del ISOC nombra al chair del NOMCOM
El presidente del ISOC está en la lista y las audios del IAB
El IETF (a través del IAB) nombra 3 miembros del BoT
del ISOC
Internet Research Task Force (IRTF)
Con foco en problemas de largo plazo
Anti-Spam Research Group (ASRG)
Crypto Forum Research Group (CFRG)
Delay-Tolerant Networking Research Group (DTNRG)
Host Identity Protocol (HIP) Research Group (HIPRG)
Internet Congestion Control Research Group (ICCRG)
Information Centric Networking Research Group (ICNRG)
Network Complexity Research Group (NCRG)
Network Management Research Group (NMRG)
IRTF, cont.
Peer-to-Peer Research Group (P2PRG)
Routing Research Group (RRG)
Scalable Adaptive Multicast Research Group (SAMRG)
El chair del IRTF es nombrado por el IAB
más información en http://www.irtf.org
Chair del IRTF: Lars Eggert
Internet Architecture Board (IAB)
brinda supervisión arquitectónica
Al IESG, IETF & ISOC
aprueba la propuesta de IESG del nomcom
es un eslabón en la cadena de apelación
Brinda “supervisión” del proceso de estandarización
del IETF
se encarga de las liaisons externas del IETF
Nombra el chair del IRTF
selecciona IETF-IANA
nombra y supervisa el RFC Editor
Mecanismos de supervisión del
IAB
Revisa los BOFs
Provee comentarios al IESG sobre la formación de WG y
sus charters
Esponsoriza y organiza al IRTF
Organiza workshops en temas específicos
La mayoría de ellos por invitación
Organiza grupos ad-hoc de expertos para zanjar
discusiones técnicas
Escribe IDs/RFCs describiendo la posición del IAB
Revisados por el IESG y la comunidad
Participa en discusiones de los WG
Internet Assigned Number
Authority (IANA)
asigna números y evita colisiones
Asigna números de protocolo (puertos, MIME types, etc)
Direcciones IP
asigna bloques de direcciones a los 5 RIRs
los cuales las asignan a ISPs y usuarios finales
Nombres de dominio
define top level domains (TLDs) - e.g., .com, .ca, .us, ...
mantiene la base de datos de servidores raíz con las
direcciones de los servidores TLD
IANA es anterior al IETF
IANA Cont.
Funciones formaron parte del IETF cuando este fue
creado
financiado por el gobierno de los USA hasta 1998
Las funciones se separaron del IETF con la creación
del Internet Corporation for Assigned Names and
Numbers (ICANN) en 1998
Corporación independiente que se hizo cargos de las
funciones de IANA
Ahora hay una IETF-IANA y una non-IETF-IANA
Hay un contrato del gobierno de los USA con ICANN
específico para las funciones de IANA
se renovó en julio del 2012 por 3 años
IETF-IANA
opera bajo el MoU entre el ICANN y el IETF
RFC 2860
asigna parámetros de protocolos para protocolos del
IETF
No está financiado por el IETF
Números de protocolos
puertos TCP/UDP
PPP protocol ids
MIME types
Direcciones IP de uso especial
etc.
Dirección del IETF
IETF Chair
AD para el General Area, portavoz
Area Directors (ADs)
Gestionan áreas (dos por área)
Internet Engineering Steering Group (IESG)
ADs + IETF Chair
Internet Architecture Board
El chair del IETF es parte del IAB
Todos son elegidos por el nomcom
Por dos años
Dirección del IETF, cont.
Todos los puestos son voluntarios
Dedicación de un AD : medio tiempo a 3/4
Dedicación del IAB: 1/3
Dedicación del IETF Chair job: full time
El IETF paga a los ADs, ni a los miembros del IAB,
IAOC, WG chairs or IETF Chair (ni salario ni gastos)
Están financiados por sus compañía o por ellos
mismos
El secretariado, el soporte a la publicación de las RFC
& IAD son pagos
IETF Chair
Russ Housley [email protected]
chair del IESG
AD del General Area
miembro ex officio del IAB
Nominado por la comunidad del IETF
Seleccionado por el nomcom
IETF’s “CTO” - “Chief Talking (& Traveling) Officer”
Area Directors (ADs)
Areas tienen 2 ADs
Excepto la General Area
responsable de definir la dirección del Area
responsable de gestionar los procesos del Area
aprueba BOFs & propone working groups
Revisa los documentos de los working group
Antes de ser revisados por el IESG
IESG
Internet Engineering Steering Group
ADs + IETF Chair
Gestiona los procesos y aprueba las RFCs
Aprueba la creación de WG (aconsejado por el IAB)
Brinda revisión técnica & aprueba la publicación de
los documentos del IETF
Revisa y comenta propuestas de RFCs que no viene
del IETF
Grupo multi-disciplinario
Selección de la dirección del IETF
Seleccionados por un comité de nominaciones (nomcom)
Chair del nomcom es nombrado por el presidente de ISOC
Proceso descrito en RFC 3777
Los miembros son seleccionados al azar de una lista de
voluntarios
requisito: haber ido a 3 de las últimas 5 reuniones del IETF
proceso aleatorio para seleccionar voluntarios: RFC 3797
Se publica la lista de puestos a ocupar
Puede incluir IETF Chair, IESG, IAB & IAOC
Se nominan personas para los distintos puestos
selección del IAOC la aprueba el IESG, las del IESG y IETF chair, por
el IAB y los del IAB por el ISOC BoT
Areas del IETF
General Area (gen) - 0 WGs (as of 2/13/2012)
Applications (app) - 17 WGs
Internet (int) - 25 WGs
Operations & Management (ops) - 16 WGs
Real-time Applications and Infrastructure (rai) - 29 WGs
Routing (rtg) - 18 WGs
Security (sec) – 12 WGs
Transport Services (tsv) - 16 WGs
Secretariado del IETF
Association Management Solutions, LLC - Fremont, CA,
USA
gestionado por el IETF Administrative Support Activity
(IASA)
Se encarga de gestionar
Reuniones, listas de correo,
Directorio de Internet-Drafts, teleconferencias del IESG
coordina
El trabajo diario del IESG
IETF Administrative Support
Activity (IASA)
Brinda la estructura administrativa para el proceso de
estandarización del IETF: RFCs 4071 & 4371
No tiene autoridad sobre el proceso
Es parte de la Internet Society
crea el presupuesto para el IETF
dinero viene de las reuniones y de ISOC
responsable de las finanzas del IETF
contrata las funciones de soporte del IETF
Secretariado, revisión y publicación de RFCs, IETF-IANA
lidia con temas de IPR del IETF
IASA, cont.
incluye
IETF Administrative Director (IAD) - Ray Pelletier
empleado de ISOC
supervisa las operaciones
IETF Administrative Oversight Committee (IAOC)
8 miembros
IAB & IETF chairs & presidente del ISOC
más
miembros elegidos por el nomcom (2), IAB, IESG &
ISOC
IETF Trust
Creado en Dic 2005 para tener el IPR del IETF
copyrights (en RFCs etc)
nombres de dominio (e.g., ietf.org)
marcas
software pago por el IETF
bases de datos
etc
Puntos
Miembro del IAB (rojo)
Miembro del IESG (amarillo)
Working Group chair (azul)
nomcom (naranja)
Local host (verde)
Miembro del IAOC (purpura)
Working Groups
Es donde se realiza el trabajo del IETF
Mayoría de las discusiones en listas de correo
Las reuniones se centran en temas críticos
(idealmente)
nota: las reuniones son en general cortas
“proceso de abajo hacia arriba”
i.e., en general propuesto por participantes del IETF,
no los ADs
A veces son precedidos por un BOF
Birds of a Feather Sessions (BOF)
A veces preceden a la creación de un Working Group
Gente interesada en un tema
convence a un AD que la idea es buena – vale la
pena explorar y hay gente interesada en hacer el
trabajo
Es necesaria una descripción y una agenda antes de
ser agendado
Y a veces una propuesta de charter para el WG
BOFs en general se reúnen una sola vez
Pueden resultar en un WG o no
Working Groups
El trabajo de los Working Groups está definido en el
“charter” que es acordado entre lo WG chairs y los
Area directors.
Los charters son limitados y tienen resultados
específicos
Los charter son aprobados por el IESG con
comentarios del IAB
Después de una solicitud pública de comentarios
Se anuncia a otras SDOs para verificar duplicidades
La última palabra la tiene el IESG
Los WGs se cierran cuando terminan su trabajo
Creación de un Working Group
Chair, descripción,
objetivos
comunidad
BOF (opcional)
new-work &
IETF Announce
Area Director
IESG
Working group creado
IAB
Working Groups cont.
No hay membresía formal
Sólo participantes
“Rough consensus and running code...”
No hay voto formal (no está definido quien puede votar)
es habitual pedir que la gente presente que está de acuerdo
con algo levante la mano
No se requiere la unanimidad
El chair determina si hay consenso
Los desacuerdos se resuelven mediante discusiones
Lista de correo y reuniones presenciales
Las decisiones deben ser verificadas en la lista de correo
Para asegurar que todos lo que no están en la reunión
puedan opinar
Formato de los documentos del
IETF
El idioma oficial del IETF es el inglés
Pero está permitido hacer traducciones de cualquier documento
del IETF a cualquier lenguaje, e.g. www.rfc-es.org
ASCII es el formato de los documentos y las listas de
correo
Discusiones constantes sobre formatos alternativos
EL IETF parece haberse quedado atrás, pero no hay
consenso en formatos alternativos
El formato es válido después de 40 años! (ver la RFC20)
Cuantas otras SDOs pueden decir lo mismo?
Proceso de estandarización
Propuestas técnicas son publicadas como Internet Drafts
(ID)
Se trabaja en ellas en un WG
El WG pide la publicación del ID cuando cree que está listo
La propuesta es revisada por el AD responsable del WG
puede ser devuelto al WG para trabajar más en
2 semanas de IETF Last-Call
4 semanas para individual standards track
Revisión del IESG
Comentarios recibidos en el last call más del IESG
puede ser devuelto al WG para más trabajo
Publicación como RFC
Domentos del IETF
Todos los documentos del IETF abiertos
i.e., cualquiera puede bajarlos y hacer copias
(completas)
Internet Draft
Documentos de trabajo del IETF
algunos I-Ds son documentos del WG
RFC
Publicaciones archivadas (nunca más son cambiadas
una vez publicadas)
los cambios o correcciones son nuevas RFCs
Muchos tipos de RFCs
Documentos de trabajo del IETF
Internet-Draft
Ideas estructuradas o al azar
Entrada al proceso
no hay control de admisión más allá del formato
(boilerplate, ver la parte de IPR)
en teoría, se eliminan del repositorio del IETF después
de 6 meses
a no ser que se envíe una nueva versión o esté en
consideración del IESG
pero existen muchos mirrors, incluído el del IETF tools
Todas las RFCs debe existir anteriormente como IDs
(excepto algunas del IANA o del RFC editor)
¿Qué es una RFC?
RFC es la sigla de “Request for Comments”
actualmente es un nombre/marca
tendencia a ser documentos más formales que antaño
Es la serie de documentos publicados por el IETF
RFC 1 Host Software – 7 Abril 1969
Actualmente hay más de 6000 RFCs
¡No todas las RFCs son estándares!
ver 1796
A pesar que algunos vendedores implican lo contrario
Muchos tipos de RFCs
EL repositorio de RFC contiene
estándares
poesía
‘Twas the night before startup
OSPF, IPv6, IPsec ...
Estándares obsoletos
white papers
RIPv1
On packet switches with
infinite storage
requerimientos
Host Requirements
Documentación corporativa
Ascend multilink protocol
políticas
Classless InterDomain Historia técnica
Netblt
Routing
Bromas del Día de los
inocentes
Documentación de procesos
IP en palomas
mensajeras...
... actualizada para QoS
Proceso de estandarización
del IETF
RFC Editor
Encargado de las publicaciones del IETF
Originalmente un persona, ahora una función
Tiene múltiples partes
Supervisión (RFC Series Editor - RSE)
edición (RFC Production) - AMS
publicación (RFC Publisher) - AMS
independent submissions ( Independent Submissions
Editor - ISE)
RSE & ISE nombrados por el IAB
RFC Producción & Publicación
recibe solicitudes de publicación de IDs de múltiples
partes
IETF (via IESG)
IRTF (via IRSG)
IAB
Independent Submissions (via ISE)
edita los IDs para su publicación
verifica la edición con los autores
Publica las RFCs
Independent Submissions Editor
ISE publica RFCs
sólo puede publicar informational or
experimental RFCs
Solicita comentarios al IESG
pero tiene discrecionalidad de publicar o no
Se espera que publique RFCs útiles y
correctas técnicamente
Documentos del IETF
Doc del grupo de trabajo, or
Doc individual
enviar
comentarios
IESG
Tal vez
RFC Production
RFC Publisher
“Last Call”
Comentarios,
sugerencias
Revisión por la comunidad
del IETF
RFC publicada
Documentos de fuera del IETF
individuo
El IAB y el IRTF tiene sus
propios procedimientos
Comentarios de contenido
y editoriales
enviar
Commentarios
IESG
Independent Submissions Editor
Tal vez
RFC
Production
RFC Publisher
RFC publicada
Standards Track RFCs:
Best Current Practices (BCP)
Políticas o procedimientos (la mejor manera que
conocemos)
Standards track (cambiado en Oct 2011 - RFC 6410)
Proposed Standard (PS)
buena idea, no tiene problemas conocidos
Internet Standard (STD)
PS + estable + “bueno para la comunidad de Internet”
múltiples implementaciones interoperables que demuestran la
claridad de los documentos
Otros tipos de RFCs
Informational
Experimental
Historical
Siempre verifica el estatus de una RFC antes de
usarla. Una nueva RFC puede haber vuelto
obsoleta la RFC que estás usando
esto se puede verificar mirando el índice de RFCs
Proceso de apelaciones
Las decisiones del IETF pueden ser apeladas
se empieza en el nivel superior al apelado
1º al WG chair(s)
Después al Area Director
Después al IESG
Después al IAB
Si el reclamo es sobre que el proceso es incorrecto,
(no que el proceso no se ha seguido correctamente)
Entonces se puede apelar al ISOC Board (después de
haber completado los pasos anteriores)
No hay problema con apelar – esto ocurre (& aceptado)
pero las apelaciones no son rápidas
empezar de abajo es lo correcto
Una sesión de un Working Group
Los WG se reúnen durante una horas en las reuniones
Mayor parte del trabajo se realiza en la lista de correo
Sólo temas específicos sin resolver se discuten en las reuniones
Hay que leer los IDs y la lista antes de una sesión
Consejo: escuchar y leer antes de hablar
Las sesiones se transmiten en directo y se graban
Hay que hablar con el micrófono
Hay que decir el nombre cada vez que se habla en el micrófono
para la gente escuchando el audio y los que hacen las minutas
Firmar las hojas azules
Registra quienes están en la reunión – necesario para
transparencia
Derechos de propiedad intelectual
(IPR)
Los IPR son un tema muy importante en las SDOs
¿Qué hacer si hay una patente en la tecnología?
¿Qué hacer si una solicitud de una patente?
¿Qué hacer si no sabemos que hay una patente hasta
después que el estándar es creado?
Preguntas sobre patentes:
¿deberíamos pedir derechos gratuitos de
implementación?
¿Deberíamos requerir licencias justas y no
discriminatorias?
¿Qué pasa si la patente en realidad no existe?
e.g., un intento de bloquear el estándar
¿debería el SDO evaluar la validez de las patentes?
Patentes
Muchas patentes en el mundo
Algunas son muy buenas, otras, no tanto
Presión de la comunidad de código abierto por
estándares sin IPR (conocidos)
Tal vez en algún universo paralelo
ver AU “Innovation Patent” AU 2001100012 A4 (8/01)
también U.S. Patent 5,443,036 (8/95)
Método para
ejercitar un
gato
Dispositvo circular
facilitador de
transporte
IPR (Patentes)
RFC 2026 revisa las reglas de IPR para el IETF
Antes se requería licencias “justas y no discriminatorias”
Estándares se podían bloquear en el proceso anterior
Ahora usamos los niveles de estándares para verificar
temas de IPR
Requiriendo múltiples implementaciones basadas en
múltiples licencias para avanzar en el nivel se
estandarización
Las reglas de patentes de RFC 2026 han sido
remplazadas por RFC 3979 & RFC 4879
mayormente clarificaciones
IPR, cont.
Reglas para IPR del IETF (RFC 3979)
requieren revelar en tiempo y forma los IPR propios que
afectan las contribuciones propias y las de los demás
Estos anuncios son publicados en el web del IETF
Si estos IPR son conocidos de forma personal por el
participante
i.e., no se requiere un búsqueda de patentes
El WG puede tomar los IPRs en consideración cuando
elige una solución
RFC 3669 brinda antecedentes y guía
Presión de la gente de código abierto por un proceso sin
IPRs
Hay consenso de no cambiar a un proceso sin IPRs
Pero muchos WG prefieren soluciones sin IPRs (conocidos)
IPR (Copyright)
Los autor(es) deben dar derechos de publicación no
exclusivos al IETF trust para poder ser publicado
También (normalmente) dan derechos para realizar
trabajos derivados
esto es obligatorio para RFC estándares
autor(es) retienen todos los demás derechos
Actualizado en la RFC 5378
Expande los derechos cedidos al IETF Trust
FAQ sobre el copyright en el IETF
http://trustee.ietf.org/faqs.html
¿Siguientes pasos?
Suscribirse a las listas de correo
es donde se realiza el trabajo
Lee (y entiende) antes de escribir
Lee los drafts y contribuye
No seas tímido (pero tampoco te pases)
Habla con la gente
Busca posiciones comunes
¿Preguntas?
Descargar

IETF Structure and Internet Standards Process