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
781 artículos
IETF
BBF espera el modelo BGP. La WGLC de IDR no es una fecha de publicación
El Broadband Forum necesita saber qué ocurre con una especificación de la que depende WT-477i2. Esa necesidad puede ser legítima y visible sin convertirse en poder para terminar el proceso de otra institución. La secuencia pública contiene tres objetos distintos: la petición de…
IETF
Joseph Touch y las opciones UDP que dejan decidir a la aplicación
Un campo añadido al final de un paquete UDP puede ampliar un protocolo sin convertirse en un permiso. La RFC 9868, coescrita por Joseph D. Touch, conserva esa frontera: las opciones de transporte van después de los datos declarados por el usuario y la aplicación decide qué…
IETF
Loa Andersson y la decisión MPLS que se detenía en la carta
Una decisión de grupo de trabajo puede ordenar su trabajo futuro sin elegir el protocolo de una red operativa. RFC 3468 registra que el grupo MPLS concentró el trabajo de ingeniería de tráfico en RSVP-TE y no emprendería nuevos trabajos sobre CR-LDP. Loa Andersson y George…
IETF
Deborah Brungard y el perfil de transporte que no elegía una red
Una exigencia técnica puede poner una capacidad a disposición sin decidir qué red la usará. RFC 5654, editado entre otros por Deborah Brungard, fija requisitos para un perfil de transporte MPLS. Su límite más importante es explícito: trata del comportamiento de mecanismos y…
IETF
Alia Atlas y la métrica TE que no prometía una ruta
Una cifra de rendimiento puede ser útil sin constituir una promesa. RFC 7471, coautorada por Alia Atlas, permite que OSPF distribuya información de rendimiento de enlaces para ingeniería de tráfico. No prescribe cómo medirla ni qué debe hacer quien la recibe. Por eso una métrica…
IETF
Jari Arkko y el campo de registro que el protocolo no necesitaba
Que una columna figure en un registro desde hace años no demuestra que siga cumpliendo una función. La RFC 8602 hace una corrección pequeña y verificable: IANA deja de pedir direcciones postales en dos trámites de registro de TRIP y elimina las que ya había recogido. Conserva el…
IETF
Lars Eggert y el datagrama UDP que no escapaba de los costes compartidos
UDP da a una aplicación un contrato de transporte pequeño, no una red privada. La RFC 8085, en la que Lars Eggert figura como coautor, traza esa frontera: el diseño puede ser local, pero el coste de congestionar una ruta compartida no se traslada a terceros.
IETF
La reunión de VELOCE eligió un puntero de IANA. El borrador del grupo aún no pide acciones a IANA
El 25 de agosto, un resumen atribuido de una reunión de VELOCE afirmó que se había confirmado un modelo de indirección mediante IANA: un registro apuntaría al repositorio, en vez de incorporar el módulo al RFC. La revisión 00 del grupo de trabajo, publicada ese mismo día…
IETF
Heather Flanagan y el archivo RFC que no puede quedarse inmóvil
Un estándar publicado necesita una memoria firme, pero su infraestructura editorial no puede quedar atrapada para siempre en un error de XML o en una herramienta de generación caduca. El problema empieza cuando se confunde la reparación del soporte con el derecho a cambiar el…
IETF
Nandita Dukkipati y la recuperación TCP que dejó de avanzar a tirones
Dos emisores pueden terminar una recuperación con la misma ventana y haber tratado a la red de maneras opuestas. Uno guarda silencio durante parte de un viaje de ida y vuelta y después compensa con una ráfaga. El otro dosifica cada envío al ritmo de los ACK que regresan. El…
IETF
PROCON acordó reflejar la política vigente, pero sus borradores también la cambian
«Los documentos resultantes deberán reflejar con precisión la política vigente». Esa fue la frase que PROCON decidió proponer en IETF 126 para estabilizar el alcance de su trabajo. Sin embargo, los borradores no realizan una sola clase de mantenimiento: eliminan el conocido…
IETF
Ashesh Mishra y la comprobación BFD que tenía que poder deshacerse
El receptor todavía no confiaba en el paquete. Sin embargo, para comprobarlo debía ejecutar un cálculo capaz de borrar el estado desde el que podría rechazarlo.
IETF
El espacio reservado para IETF 131 se adjudicó a otro. La sede pública seguía por definir.
IETF 131 conserva fecha y región, pero perdió algo que nunca había llegado a la página pública: un espacio reservado. El informe de la IETF Administration LLC del 1 de septiembre dice que ese espacio se entregó a otro y que el equipo vuelve a sedes asiáticas ya conocidas. También…
IETF
Wes Hardaker y el servidor DNS que tuvo que sobrevivir a dos TTL
El error no estaba en la nueva configuración. Estaba en declarar muerto al servidor anterior mientras una parte de Internet todavía conservaba una indicación válida para encontrarlo.
IETF
El BoF de Agentproto respaldó un grupo de trabajo, pero rechazó su alcance inicial
Un acta puede reproducir cada cifra y aun así permitir dos relatos incompatibles. En Agentproto, 154 respuestas favorables parecen apoyar una Working Group; 124 respuestas negativas parecen tumbar el alcance con el que esa misma Working Group fue presentada. La salida no está en…
IETF
Mirja Kühlewind y el spin bit de QUIC que midió el período de la aplicación, no el RTT de red
La traza mostraba un cambio cada 200 milisegundos. Llamarlo «RTT de 200 ms» parecía natural, pero una aplicación que envía a ese ritmo produce el mismo pulso sobre una ruta mucho más rápida.
IETF
Murray Kucherawy y la firma DKIM que dejó la cola sin firmar
El correo llegó con una marca de autenticación positiva. Debajo de esa marca, sin embargo, podía existir una cola que nunca pasó por el hash. DKIM no se contradice: la etiqueta `l=` permite que la firma termine antes que el cuerpo que recibe y muestra el cliente.
IETF
John Klensin y la respuesta SMTP que aceptó la responsabilidad, no la entrega
Un transportista firma que recibió el paquete; nadie confundiría esa firma con la del destinatario. En SMTP ocurre algo parecido: el `250` posterior a DATA permite al remitente soltar su copia, pero solo porque otro sistema asumió la obligación de seguir adelante.
IETF
RATS ya incorporó una corrección de dos relojes en el código fuente. La versión 09 sigue en última llamada
La historia no termina cuando un autor responde «de acuerdo» en una lista. Termina, al menos provisionalmente, cuando puede seguirse la observación hasta el texto que cambió y distinguir ese cambio de la decisión que todavía falta. Eso ocurrió con RATS Endorsements: una…
IETF
Tomek Mrugalski y el éxito DHCPv6 que no renovó la concesión
Un equipo cambia de planta, vuelve a conectarse y conserva su dirección IPv6. El servidor responde `Success`, pero el reloj de la concesión no vuelve al inicio. RFC 9915 separa dos libros que suelen mezclarse: dónde encaja la dirección y hasta cuándo está autorizado su uso.
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