Tipo de contenido
Research
Dentro de la faceta Tipo de contenido, la inteligencia de Research reúne artículos de BTW.MEDIA que comparten el mismo formato editorial, lo que ayuda a los lectores a comparar informes, perfiles, notas de riesgo, análisis de mercado y cobertura de eventos sin mezclar distintos tipos de evidencia. La página explica cómo este tipo de contenido enmarca los eventos de infraestructura de Internet, los movimientos empresariales, las decisiones de gobernanza, las señales operativas y la evidencia pública en todo el sitio. Los lectores pueden comparar qué actores o sistemas de infraestructura aparecen con más frecuencia, cómo la calidad de las fuentes cambia la interpretación y si el material es un perfil duradero, un evento sensible al tiempo, una señal estratégica de mercado o un desarrollo de gobernanza. El resultado es una página de búsqueda útil para operadores, inversores, clientes, analistas y partes interesadas en políticas públicas que necesitan comprender la consecuencia, el momento y la evidencia detrás de formatos de artículo similares.

Historia de Internet
La búsqueda de Archie no podía estar más al día que su último listado FTP
Archie permitió buscar en archivos FTP anónimos repartidos por la red al recopilar sus listados de directorios. Ese detalle delimitaba lo que podía prometer: encontraba un nombre y una ubicación, pero el archivo seguía alojado en otro ordenador, y el índice solo describía lo que…

Historia de Internet
La licencia cubría el software, no el protocolo: el límite de Gopher en 1993
El 11 de marzo de 1993, el equipo de Gopher de Minnesota publicó en Usenet una nota que empezaba por responder a los rumores. La frase que sobrevivió fue fácil de repetir: los usos comerciales tendrían que pagar. El texto era más preciso. Separaba a los usuarios según el…

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.

Líderes
Alan Greenberg y la solicitud que abrió un expediente en el GNSO
En mayo de 2007, Alan Greenberg llevó al GNSO una decisión del ALAC: pedir al personal de ICANN que estudiara el domain tasting. La solicitud abrió una vía formal de análisis. No fijó la política ni convirtió a sus participantes en representantes electorales de todos los usuarios…

Historia de Internet
El enchufe tenía cuatro clavijas: NORDUnet ante la elección europea de protocolos
En mayo de 1988, una red nórdica de investigación pidió a Estados Unidos una conexión con NSFNET mientras planeaba transportar varios servicios que ya usaban las universidades de la región. Su enchufe de cuatro clavijas convirtió una pregunta difícil en una imagen concreta…

Líderes
Tina Dam y la prueba de la raíz que no podía aprobar un nombre
Antes de añadir un dominio internacionalizado de nivel superior a la raíz, ICANN planteó una pregunta deliberadamente acotada: ¿alterarían las etiquetas codificadas el funcionamiento de los servidores y resolutores DNS? La prueba de laboratorio respondió dentro de su montaje. No…

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ó…

Académicos
Lorrie Cranor quiere que la privacidad siga el rastro del código
El trabajo sobre la sección Data safety de Google Play plantea una pregunta práctica: ¿puede un desarrollador vincular cada declaración de la tienda con el código y el comportamiento de los SDK? La investigación de Lorrie Cranor sobre privacidad usable sitúa ese problema de…

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.

Historia de Internet
Publicar la falla no era publicar el gusano: el debate de divulgación de RFC 1135
Después del gusano de Internet de 1988, “divulgar” no significaba una sola cosa. Los registros distinguen entre describir las fallas, explicar los métodos, distribuir correcciones y publicar el código descompilado. RFC 1135 conservó respuestas enfrentadas sin convertirlas en una…

Líderes
El regreso de Rebecca MacKinnon pone en perspectiva dos métodos de rendición de cuentas
¿Qué demuestra que una empresa pertenezca a una iniciativa de derechos digitales? En el Índice de Ranking Digital Rights (RDR) de 2020, la respuesta fue deliberadamente limitada para un indicador concreto: la membresía en Global Network Initiative (GNI), por sí sola, solo merecía…

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…

Historia de Internet
« De rutina » no significaba « sin revisión »: el criterio de RFC 6709
Una extensión puede añadir muy poca sintaxis y exigir mucho trabajo a los sistemas que ya están en servicio. Por eso RFC 6709 no medía lo «rutinario» contando líneas de código. Lo vinculaba a una condición más estricta: ¿podían el protocolo base y las implementaciones desplegadas…

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.

Historia de Internet
Una Internet, muchos operadores: la analogía telefónica de RFC 1462
El FYI de 1993 recurrió a una llamada telefónica para explicar una topología nueva: el usuario veía un servicio de Internet, aunque distintas redes operaban y reparaban sus propios tramos.

Historia de Internet
NAT era una función, no una interfaz: por qué tuvo que cambiar la MIB de la RFC 4008
En el ejemplo de configuración de la RFC 4008, el gestor SNMP crea primero una fila ligada a un índice de interfaz y luego añade los mapas de direcciones. Diez años después, NATV2-MIB describía la traducción como una función lógica que puede abarcar varias interfaces. La propia…

Líderes
El marco de Anriette Esterhuysen preguntó qué capacidad perdura después del IGF
El informe de 2021 del Foro para la Gobernanza de Internet cuenta subvenciones, participantes con apoyo y talleres. El marco que Anriette Esterhuysen preparó antes planteaba una pregunta de más largo plazo: ¿podían las personas y sus instituciones seguir definiendo y alcanzando…

Historia de Internet
La trama cruzaba el pseudowire, pero no su rol de servicio: RFC 7152
En 2014, un memorando de requisitos del IETF señaló una brecha discreta en las VPN de capa 2: un equipo de borde podía recibir una trama Ethernet por un pseudowire sin saber si procedía de un acceso raíz o de hoja. La RFC 7152 convirtió esa falta de contexto en requisitos para…

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.
