Organismo de estándares abiertos con impacto en la implementación a nivel mundial.
Gobernanza / IETF
IETF
El análisis de IETF abarca los desarrollos públicos que afectan a la infraestructura de Internet, a las decisiones de gobernanza, a los mercados de conectividad, a los flujos de capital digital y al riesgo operativo.
GlobalGobernanza de protocolosRiesgo de interoperabilidad
Proceso de protocolo y legitimidad de estándares.
Brecha entre especificación e implementación en proveedores y operadores.
Los cambios importantes en los estándares suelen afectar a los sistemas durante ciclos de 120 días o más.
Cobertura reciente
Titulares de IETF
783 artículos
IETF
La banda ancha busca quién revise sus propuestas en el IETF
La nueva lista sobre redes de acceso pretende facilitar el encuentro entre contribuyentes. El trabajo decisivo será reunir conocimientos y tiempo para evaluar las propuestas más allá de su presentación.
IETF
Mukul Srivastava y el Gauge BMP que contó una RIB sin ver una ruta
Una cifra puede estar bien tomada y aun así no describir el trayecto que interesa al operador. RFC 9972 amplía BMP con Gauges que cuentan rutas presentes en una vista RIB delimitada. Esa precisión no convierte el contador en el historial de un prefijo, ni en la explicación de una…
IETF
Los roles BGP convierten una relación de peering en una frontera contra fugas de rutas
Antes de intercambiar una sola ruta, dos redes pueden declarar qué tipo de vecino creen tener. RFC 9234 convierte esa afirmación bilateral en un control: los roles incompatibles pueden impedir la sesión y el atributo Only to Customer puede detener después una ruta marcada que…
IETF
Rich Salz y el requisito de TLS 1.3 que no era un comprobante de despliegue
Una norma puede fijar una regla exigente sin fabricar la prueba de que esa regla ya se cumple en cada sistema que está funcionando. La distinción no debilita la norma: evita que una decisión de protocolo se convierta en una afirmación de despliegue sin observación. El RFC 9852…
IETF
Una cookie DNS aporta evidencia de retorno, no identidad del cliente
Cuando un servidor valida una DNS Server Cookie obtiene una señal útil: alguien que usaba esa dirección de origen y esa Client Cookie recibió antes una respuesta con el valor esperado. La señal dificulta la falsificación fuera de ruta. No convierte una dirección compartida ni un…
IETF
Nancy Cam-Winget y el evento SCIM que no era un recibo de conciliación
Que un dominio de identidad comunique un cambio no demuestra que el dominio receptor ya lo haya incorporado. Aún debe identificar el recurso, conciliar esquemas, decidir si necesita una consulta de vuelta, aplicar su regla local y observar su propio estado. El RFC 9967, coescrito…
IETF
Chris Wendt y la respuesta firmada que no autenticaba el audio
El hecho de que una llamada llegue a una respuesta no resuelve por sí mismo una cuestión de identidad. Aún quedan por determinar el destino real, la autoridad de quien lo afirma, el nivel de riesgo que el llamante aceptó y el origen del medio que sigue a la señalización. RFC…
IETF
La falta de espacio en Viena pone a prueba las previsiones de la IETF
La IETF salió de Viena con un balance de satisfacción alto y una limitación reconocida: no hubo espacio para añadir los asientos habituales en los pasillos. El caso permite examinar cuánto dura una previsión de asistencia cuando la sede ya está elegida.
IETF
Michael Prorock y el identificador de algoritmo que no escogía una política de confianza
Una etiqueta criptográfica puede ordenar una verificación entre sistemas distintos. No puede explicar de dónde procede una clave, por qué merece confianza, qué afirmaciones son pertinentes ni qué medida debe tomar quien verifica. RFC 9964, firmado por Michael Prorock y Orie…
IETF
El IETF Trust tiene una presidencia final. Su salida aún necesita un registro de estado final.
Una transición puede estar descrita correctamente y, aun así, no ser un expediente público completo. Nombrar una presidencia final identifica a quien lleva una función residual. Comunicar un traspaso de activos prueba una etapa importante. Ninguna de ambas cosas dice por sí sola…
IETF
Dan Harkins y la clave de arranque que no podía acreditar su propia custodia
Que un dispositivo demuestre controlar una clave privada no explica quién entregó su clave pública al servidor, si esa entrega fue íntegra ni quién autorizó el acceso posterior. RFC 9966 deja esa frontera a la vista: convierte una clave de arranque en una prueba TLS acotada, no…
IETF
David Benjamin y el código de compatibilidad que no se convirtió en permiso general
Un dispositivo criptográfico antiguo puede frustrar una migración moderna en un punto muy concreto del intercambio. La solución solo conserva valor si mantiene ese límite. RFC 9963 abre una ruta estrecha para una firma de cliente heredada; no devuelve una autorización general al…
IETF
Al Morton y la prueba de capacidad que no se convirtió en una promesa de servicio
Una medición de velocidad puede aportar evidencia sobre un método, una ruta y un momento concretos. Se vuelve engañosa cuando se eleva a promesa sobre toda sesión futura, un plan de acceso, una aplicación o una red completa.
IETF
Muhammad Shahzad y el registro de dispositivo que no revocaba el acceso
Borrar un registro de dispositivo puede ser una señal operativa relevante. No demuestra por sí mismo que un punto de control retiró el acceso, que el dispositivo se desconectó ni que una conexión posterior fue denegada.
IETF
Cédric Fournet y el recibo que no completaba un registro
Que una prueba tenga firma y raíz criptográfica no significa que responda por toda la historia que un equipo necesita. Puede demostrar una propiedad puntual y seguir dejando abierto si el registro está completo, vigente o es apto para una decisión.
IETF
Christian Amsüss y el contexto de seguridad DoC que no protegía el DNS aguas arriba
Un intercambio DNS sobre CoAP puede ir protegido sin que todo el camino de resolución lo esté. RFC 9953, escrita colectivamente con Christian Amsüss, atribuye confidencialidad e integridad a las partes que comparten un contexto DTLS, TLS u OSCORE. También admite que el servidor…
IETF
La IETF puede acotar el pie de correo. Aún necesita un recibo de estado de la contribución.
Una nota de “sin obras derivadas” en un mensaje de la IETF parece capaz de decidirlo todo. La versión más reciente del borrador sobre esta materia propone algo bastante más limitado: reservar ese mecanismo para los Internet-Drafts y RFC que se usen en el proceso de estándares de…
IETF
Paul Wouters y el requisito IKEv2 que no era un recibo de negociación
Que una norma diga «MUST implement» no revela qué ocurrió en una conexión. RFC 8247, escrita entre otros por Paul Wouters, fija un mínimo de algoritmos para que implementaciones IKEv2 tengan una oportunidad de interoperar. No documenta una oferta, una selección, una SA creada ni…
IETF
Bernie Volz y el disparador DHCPv6 que aún no configuraba al cliente
Un servidor puede haber enviado Reconfigure y, sin embargo, no saber todavía que el cliente recibió el mensaje, inició el intercambio pedido, obtuvo un Reply o aplicó una configuración. La RFC 9915, escrita colectivamente con Bernie Volz, conserva esas diferencias. Reconfigure…
IETF
El OAM de CATS puede verificar una política de encaminamiento. No puede elegir el remedio.
El borrador OAM de CATS aborda una diferencia importante: que una dirección responda no demuestra que el servicio detrás de ella funcione. Una instancia puede seguir siendo alcanzable mientras la aplicación está bloqueada, agotada o degradada. Por eso el texto propone observar…
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 Strategic Circle
Únete para desbloquear informes estratégicos después de iniciar sesión.
Únete a Strategic CircleInforme de Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance