Dominio principal
Gobernanza de Internet y enrutamiento
En la faceta Dominio principal, los análisis de Gobernanza de Internet y enrutamiento se agrupan por dominio principal para que los lectores puedan seguir un área concreta de la infraestructura de Internet, la gobernanza, los mercados de conectividad o el capital digital. La página reúne artículos relacionados, evidencia pública, instituciones, empresas, personas, exposición regional, dependencias operativas y contexto de mercado que de otro modo aparecerían en páginas de categoría separadas. Explica el dominio, la clase probable de actor, el contexto de mercado o de gobernanza y el material de origen que los lectores deben usar al comparar señales. Operadores, analistas y lectores de gobernanza pueden ver cómo el mismo dominio aparece en eventos, perfiles, cambios de mercado, evidencia de fuentes públicas, dependencias regionales y decisiones de infraestructura de ciclos más largos a lo largo del tiempo.

ICANN
Un cambio de cadena .Brand puede añadir palabras, pero no crear ni ampliar la contención
La Ronda 2026 de ICANN ofrece a un solicitante .Brand elegible una vía limitada para cambiar su cadena cuando existe contención. No es un derecho general a renombrar una solicitud.

ICANN
Un cambio sustancial en las partes públicas abre 30 días de comentarios, no una aprobación automática
Cuando ICANN considera que un cambio afecta sustancialmente a las partes públicas de una solicitud, se abre una consulta de 30 días sin que el cambio quede aprobado.

Sociedad de recursos numéricos
El número de serie de una caché RPKI no es una marca temporal de frescura
Dos cachés RPKI pueden mostrar números de serie correctos sin revelar cuál contiene la vista global más reciente. RFC 8210 limita cada serie a una sesión de caché y una versión del protocolo. Ordenar los valores como si fueran tiempo crea una cronología inexistente.

ICANN
El asesoramiento consensuado del GAC abre un registro de respuesta de 21 días, no un resultado automático
El asesoramiento formal del GAC cambia la posición procesal del solicitante, pero no constituye por sí mismo la decisión de la Junta Directiva de ICANN.

ICANN
Una alerta temprana del GAC es una señal, no un veto: el registro de respuesta del solicitante
La Ronda de 2026 permite que un representante gubernamental señale formalmente una preocupación sin convertir ese aviso en una decisión automática sobre la solicitud.

ICANN
Un riesgo de singular/plural no se ejecuta solo: el expediente ICANN de 30 días
En la Ronda de 2026, una pareja gramatical solo se convierte en una decisión del programa mediante una notificación oportuna respaldada por pruebas lexicográficas verificables.

ICANN
Una apelación de objeción ante ICANN no es un nuevo juicio: qué puede cambiar el criterio de error manifiesto
En la Ronda 2026, la apelación revisa un error identificado en la objeción; no vuelve a abrir toda la controversia.

ICANN
Una objeción comunitaria no es la CPE: dos procedimientos de ICANN para preguntas distintas
La palabra «comunidad» aparece en ambos nombres, pero cambian las partes, las pruebas y la decisión que se solicita.

ICANN
¿Qué expediente probatorio debe preparar un solicitante para la Evaluación de Prioridad Comunitaria?
Un expediente vinculado a criterios vale más que una acumulación de apoyos.

Expediente
Sesenta nombres eran demandados; el estatuto seguía definiendo la acción: Harrods v Sixty Internet Domain Names
El encabezado del pleito parecía invertir la relación habitual: no figuraba una persona como demandada, sino sesenta nombres de dominio. Esa forma in rem permitió llevar los nombres ante un tribunal cuando la jurisdicción personal sobre el titular no estaba disponible. No…

ICANN
ICANN examina el significado geográfico de cada cadena solicitada. ¿Qué debe demostrar una carta de apoyo?
En la ronda de 2026, ICANN revisa todas las cadenas por su posible carácter geográfico. El expediente debe probar autoridad, autenticidad y alcance.

IETF
Corey Bonnell y la firma de CRL hecha con una clave sin autorización
Una cadena de confianza puede llegar al ancla correcta y, aun así, conducir a la clave equivocada para el acto que se intenta validar. RFC 10007 convierte esa diferencia en una comprobación obligatoria: en un certificado v3 del emisor de una CRL, la finalidad no se presume; debe…

IETF
Kireeti Kompella y la respuesta Echo que no demostró el servicio
Una respuesta MPLS Echo puede demostrar que una sonda definida llegó a un router capaz de explicar un FEC concreto. No demuestra que funcionen todas las rutas ECMP, que el respaldo dormido esté listo, que la vuelta repita la ida ni que la aplicación del cliente termine. El valor…

IETF
Eliot Lear y la política de dispositivo que nunca fue una atestación
Una descripción de tráfico puede reducir el espacio de ataque de un sensor sin certificar el sensor. Esa separación sostiene Manufacturer Usage Description en RFC 8520: el fabricante propone un patrón de comunicación y la red que asumirá el riesgo decide si lo acepta, lo estrecha…

IETF
Tero Kivinen y la nueva IKE SA que recibió Child SA aún activas
La operación dice que la clave se renovó; los SPI de tráfico dicen que no. Ambas afirmaciones pueden ser ciertas si la primera describe la IKE SA de control y la segunda las Child SA que protegen los paquetes. En RFC 7296, la sucesora IKE recibe la custodia de asociaciones ya…

IETF
Roy Fielding y el método que nombraba una intención, no un permiso
Un intermediario puede leer el primer token de una solicitud HTTP antes de saber casi nada de la aplicación. Esa visibilidad permite coordinar clientes, cachés y servidores. También invita a una conclusión falsa: creer que el nombre de la acción autoriza a quien la pide. La…

IETF
Mark Nottingham y el agente de usuario que no podía hablar por todos
Un navegador puede interponerse entre una persona y un servicio, limitar lo que el sitio ve, llevar una preferencia concreta y dejar abierta una alternativa. Esa capacidad protege intereses humanos sin convertir al programa, a su fabricante ni a quien redacta un estándar en…
