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.
Institucionales globales
ISC-AGP1: qué autoridad puede demostrar Internet Systems Consortium y quién puede corregirla
La presencia pública de Internet Systems Consortium, Inc. atraviesa software DNS y DHCP, la participación en F-root, registros de recursos numéricos, observaciones de enrutamiento y autorizaciones RPKI. El problema institucional es que esas huellas no constituyen por sí solas una…
ICANN
La autoridad de ICANN no vive en un solo documento
La autoridad operativa de ICANN se construye por capas: propósito corporativo, estatutos, contratos con registros y registradores, y mecanismos de cumplimiento que convierten compromisos institucionales en consecuencias operativas. La pregunta decisiva no es solo qué puede hacer…
Institucionales globales
INFINITYWIFI y AS210057: quién puede corregir, autorizar o revertir una acción de red
El resumen de inteligencia de INFINITYWIFI y AS210057: quién puede corregir, autorizar o revertir una acción de red explica el desarrollo, la evidencia pública disponible para los lectores, las organizaciones implicadas, el contexto regional, la exposición de mercado y las…
ICANN
La autoridad de ICANN no es general: se vuelve ejecutable a través de contratos y procedimientos
ICANN coordina identificadores únicos de Internet, pero sus decisiones no tienen todas el mismo origen ni ofrecen las mismas vías de impugnación. La cadena decisiva va de una misión limitada y políticas comunitarias a obligaciones contractuales, ejecución por registries y…
ICANN
La autoridad de ICANN no está en una sola puerta: del mandato a los recursos
ICANN coordina identificadores esenciales de Internet, pero sus documentos no describen una autoridad gubernamental general. Describen una combinación más precisa: un mandato institucional, obligaciones contractuales, funciones delegadas y procedimientos de rendición de cuentas.…
ICANN
La autoridad de ICANN no nace de una sola fuente: cómo una coordinación técnica se convierte en control operativo
ICANN coordina identificadores únicos de Internet, pero esa función no equivale por sí sola a soberanía sobre la red. Su capacidad efectiva aparece cuando varias capas se conectan: una corporación californiana con fines públicos, unos estatutos que delimitan su misión y sus…
IETF
IETF y W3C: dos sistemas de autoridad ocultos tras una misma etiqueta
La etiqueta IETF-W3C sugiere una sola institución técnica. El registro público muestra otra cosa: son sistemas distintos, con instrumentos diferentes para conceder autoridad, decidir, objetar y recurrir.
ICANN
ICANN no tiene un recurso universal: cada impugnación activa una cadena distinta
Las reglas de ICANN ofrecen varias vías para cuestionar decisiones de la Junta o del personal, pero no todas pueden hacer lo mismo. La diferencia decisiva está en quién inicia el procedimiento, qué órgano decide y si el resultado puede rechazar una acción, recomendar una…
Historias
DATAMATIX y AS210973: qué puede demostrar la evidencia pública sobre control y continuidad
El resumen de inteligencia de DATAMATIX y AS210973: qué puede demostrar la evidencia pública sobre control y continuidad explica el desarrollo, la evidencia pública disponible para los lectores, las organizaciones implicadas, el contexto regional, la exposición de mercado y las…
ICANN
La quinta cadena variante asignable activa otra tasa de evaluación completa
Para un nuevo solicitante, las primeras cuatro cadenas variantes pueden estar incluidas, pero cada variante asignable adicional genera otra tasa completa.
ICANN
Una solicitud gTLD presentada conserva un plazo de pago de siete días
Presentar un gTLD a tiempo no basta: ICANN debe recibir la tasa de evaluación dentro de una ventana de pago separada.
ICANN
El control administrativo es un filtro de presentación, no una decisión de fondo
El control administrativo de ICANN verifica datos de presentación y prepara conjuntos de cadenas idénticas; no aprueba la solicitud en cuanto al fondo.
ICANN
Una evaluación RSP puede cubrir muchos gTLD, solo para servicios cualificados
Una evaluación puede reutilizarse entre gTLD, pero la cualificación de ICANN sigue ligada a servicios concretos.
ICANN
La cobertura de RSP es un mapa de funciones, no un recuento de proveedores
Un solicitante puede nombrar varios Proveedores de Servicios de Registro y aun así dejar una función crítica sin cubrir. El marco de la ronda de 2026 de ICANN distingue los roles Main, DNS, DNSSEC y Proxy opcional, cada uno con funciones y límites propios.
ICANN
Nombrar un RSP no equivale a confirmarlo durante la contratación
Un solicitante puede identificar a un Proveedor de Servicios de Registro en su solicitud, mientras ICANN solicita por separado una confirmación al proveedor durante la contratación. La selección, la solicitud de ICANN y cualquier respuesta efectiva del RSP son elementos de prueba…
ICANN
La selección de RSP puede esperar hasta la evaluación, no indefinidamente
Las reglas de ICANN de 2026 permiten presentar una solicitud sin nombrar proveedores de servicios de registro, pero antes de la Evaluación del Solicitante y de la Solicitud deben estar cubiertas las funciones críticas mínimas.
ICANN
Los conjuntos de variantes compiten juntos, no cadena por cadena
Las reglas de ICANN de 2026 tratan la cadena primaria y sus variantes asignables solicitadas como una unidad de contención cuando distintos solicitantes buscan cadenas del mismo conjunto.
ICANN
Las solicitudes de variantes de gTLD existentes reciben prioridad, no aprobación
ICANN adelanta una categoría de solicitudes en el orden de tramitación: las variantes asignables de gTLD existentes de la ronda de 2012. Esa prioridad modifica la secuencia, no el resultado sustantivo.
ICANN
Las variantes de un gTLD existente llevan el registro a un solo acuerdo de 2026
Un operador que solicita variantes asignables de un gTLD existente no añade etiquetas aisladas a un contrato intacto. Las reglas de ICANN para 2026 exigen la transición al nuevo Acuerdo Base de Registro y sitúan el gTLD existente y sus variantes bajo un único acuerdo.
ICANN
Solo el operador del gTLD existente puede solicitar sus variantes IDN
En la ronda de ICANN de 2026, quien solicite variantes IDN de un gTLD existente debe ser la misma entidad jurídica que su operador de registro.