Informe de Strategic Circle
Únete para desbloquear informes estratégicos después de iniciar sesión.
Únete al Círculo EstratégicoGobernanza / IETF
IETF
El IETF escribe los protocolos con los que funciona cada red. Seguimos los borradores, los debates de los grupos de trabajo y los estándares publicados, y explicamos qué cambia cada uno para los operadores antes de que llegue a producción.
GlobalGobernanza de protocolosRiesgo de interoperabilidad
Cobertura reciente
Titulares de IETF
1656 artículos
IETF
La IETF necesita algo más que nombres para cubrir sus puestos
La ampliación del NomCom hasta el 23 de octubre buscaba más personas dispuestas a aceptar una candidatura. Ese sí implica comprometer recursos, no solo dejarse proponer.
IETF
El modelo superó la validación; RFC 10057 aún esperaba aprobaciones.
El Datatracker mostró cero errores y cero advertencias de validación YANG para la revisión 44. Aun así, RFC-to-be 10057 seguía en revisión final, con dos aprobaciones de autores sin registrar y un posible bloqueo del clúster.
IETF
La RFC 10065 estandariza el identificador de grupo, no su significado
Un atributo de RADIUS puede llevar una etiqueta de grupo hasta una política de acceso. La RFC 10065 no fija quién define el grupo ni cómo se traduce la etiqueta en tráfico.
IETF
La IESG aprueba la nueva carta de PROCON y fija nuevos hitos
La IESG aprobó la carta que PROCON sometió a revisión en septiembre. El nuevo calendario apunta a noviembre para dos documentos de proceso y a diciembre para uno sobre las facultades de la presidencia; es un mandato de trabajo, no un cambio normativo inmediato.
IETF
Mark Townsley y el alcance de su reconocimiento en la RFC 6333
Un agradecimiento breve en la RFC 6333 atribuye a Mark Townsley una aportación concreta: sus comentarios sobre la arquitectura orientaron el trabajo hacia SNAT. La portada nombra a otras cuatro personas como autores. Al leer juntos ese reconocimiento, los borradores previos y las…
IETF
Tomek Mrugalski y el nombre DHCPv6 que dirige el túnel IPv4 hacia el operador
Una respuesta DHCPv6 puede llevar el nombre de un extremo Dual-Stack Lite. El equipo del cliente puede resolverlo e intentar abrir un túnel IPv4 dentro de IPv6. Ese nombre no demuestra que DNS haya respondido, que exista el túnel, que el AFTR haya creado una traducción ni que el…
IETF
La ECN sobre UDP depende de la API de sockets
Cuando desaparece el contador ECN de un transporte, la explicación más cómoda es que la ruta no marcó paquetes. El RFC 10055 obliga a considerar otra posibilidad antes de cerrar el diagnóstico: la API del socket puede no haber entregado la señal a la aplicación.
IETF
Una conexión necesita memoria: Marcelo Bagnulo y tres puntos de control
Los equipos suelen dibujar una red como una ruta entre dos extremos. Las decisiones que mantienen útil esa ruta, sin embargo, pueden vivir en sitios distintos: en el anfitrión que conserva una relación entre direcciones, en un traductor que une IPv6 con IPv4 o en el receptor que…
IETF
La propuesta de carta de MASQUE reduce la lista de cierre; el borrador Ethernet sigue en el IESG
El grupo de trabajo de MASQUE tiene ahora una lista más corta de tareas antes de su cierre propuesto. El borrador Ethernet que ya no aparece en ella continúa, por separado, en la revisión de publicación del IESG.
IETF
El curso de iniciación de IETF no seguirá a sus alumnos. Su impacto aún necesita un registro
IETF está encargando un curso a ritmo propio para ayudar a quienes empiezan a participar en un proceso técnico que puede tardar años en aprenderse. La decisión de no evaluar ni seguir a cada alumno establece un límite valioso para la privacidad. También plantea una pregunta de…
IETF
El IETF tramita dos selecciones para el área Internet con plazos distintos
El IETF lleva a la vez dos procesos para la dirección del área Internet (INT). Uno cubrirá la salida de Tommy Jensen a mitad de mandato; el otro corresponde al puesto ordinario de dos años que Éric Vyncke no busca continuar. Los calendarios y los periodos de servicio son…
IETF
NomCom: más acceso al comité, una huella pública más larga
La nueva revisión de una propuesta individual eleva a cinco el máximo de puestos garantizados para un grupo de adhesión voluntaria. Su diseño vincula la selección con una información pública que podría conservarse y recopilarse durante años.
IETF
RFC 10065 lleva el grupo al ACL, pero no acredita quién aplicó la regla
La auditoría de acceso suele atascarse en una pregunta concreta: ¿en qué punto dejó de coincidir la decisión de identidad con la regla que vio el paquete? RFC 10065 hace más explícita la relación entre grupo y ACL, pero no registra por sí solo todo ese recorrido.
IETF
Syslog podía informar sobre la calidad del reloj. El operador aún debía fijar sus límites: RFC 5424
Un sello horario expresado en UTC puede parecer inequívoco y, aun así, dejar sin respuesta una pregunta básica: ¿quién sabía qué reloj y qué zona horaria estaba usando el sistema que originó el mensaje? RFC 5424 permite adjuntar parte de esa respuesta al propio registro.
IETF
Dentro de EAP-FAST, el tipo 6 significaba otra cosa: RFC 5421
RFC 5421 llevó un código EAP conocido a un marco distinto: el tipo 6 seguía figurando como Generic Token Card, pero dentro del túnel EAP-FAST seleccionaba un intercambio interno con otro formato. La norma fijó una separación estricta entre ambos usos y la nota del IESG advirtió…
IETF
El éxito del aprovisionamiento no decidía el acceso a la red: RFC 5422
RFC 5422 separa la preparación de credenciales de la autorización de red; su modo sin autenticación del servidor se reserva para aprovisionar.
IETF
AAA reconocía al abonado. El Home Agent aún necesitaba su propia clave: RFC 5419
RFC 5419 explica por qué algunos operadores de Mobile IPv6 querían aprovechar la relación AAA existente para autenticar a sus abonados. La pregunta decisiva aparece después: el servidor AAA del hogar puede reconocer al usuario, pero el Home Agent elegido todavía necesita una…
IETF
Autenticar CAPWAP no daba de alta el equipo en la red: RFC 5418
El análisis de RFC 5418 separa la autenticación WTP–AC del alta en un despliegue, la función autorizada y la ruta de los datos. Una sesión válida solo resuelve una parte de la decisión operativa.
IETF
Antes del descubrimiento CAPWAP, DHCP ordenaba los controladores que podía probar el punto de acceso: RFC 5417
Una opción DHCPv4 o DHCPv6 puede anteponer un controlador a otro en la búsqueda inicial de un punto de acceso. RFC 5417 define esa secuencia como una preferencia configurada; la fase de descubrimiento y DTLS determinan después qué par puede convertirse en el extremo de control.
IETF
RFC 5416: el vínculo 802.11 tiene un límite de época
RFC 5416 no es una promesa de compatibilidad con todo el Wi-Fi actual. Es la definición de un vínculo CAPWAP para la base IEEE 802.11-2007: estaciones, radios, QoS, BSSID y WLAN se describen dentro de ese contrato. La pregunta de gobierno es qué puede demostrar un mensaje de ese…
Desbloqueo para miembros
Análisis de perfil reservado
Inicia sesión para desbloquear los informes completos de perfil y las secciones de análisis en profundidad.
Informe de Leadership Alliance
Para propietarios de activos IP y equipos directivos: informes de la alianza, reportes privados y apoyo directo de analistas.
Unirse a Leadership Alliance