El contrato InterNIC y el precio de un único punto de estrangulamiento administrativo

Resumen

• En abril de 1993, la NSF lanzó InterNIC con Network Solutions encargándose del registro, recepción, procesamiento y actualizaciones de dominios no DDN, números de red y ASN; AT&T de la gestión del acceso al directorio y la base de datos; y General Atomics/CERFnet de la información y referencia. Las reproducciones del acuerdo provisional también establecieron requisitos de 3, 5 y 22 días laborables para las asignaciones de Clase C, B y A después de completar una solicitud, pero la evidencia conservada no mide su cumplimiento.
• El proceso de solicitud documentado de Network Solutions utilizó plantillas estándar, análisis automatizado, mensajes de error, verificación del solicitante, una ventana de confirmación de siete días, procesamiento final humano y estado de ticket visible, ofreciendo ganancias creíbles en escala, consistencia y visibilidad de la corrección.
• Las copias sobrevivientes del acuerdo son reproducciones no autenticadas; los informes de rendimiento carecen de denominadores decisivos de solicitudes de números; y las rutas documentadas de corrección, entre gestores, de partes contratantes y de apelación al registro no proporcionan series recuperadas de uso, duración, revocación o resultado.
• El registro establece una dependencia concentrada de recepción y procesamiento central para el trabajo definido de registro no DDN, pero no una inevitabilidad universal, exclusión sistemática, daño cuantificado al solicitante o prueba de que las rutas regionales, militares, de registros locales y de proveedores no estuvieran disponibles para una población afectada específica.

1 de abril de 1993: una solicitud entra por el nuevo canal

Una solicitud de registro no militar que se aproximaba al servicio central de Internet el 1 de abril de 1993 se encontró con un camino deliberadamente estructurado. El cambio era visible primero en instrucciones mundanas: qué buzón utilizar, qué formulario completar, a dónde llamar, y qué sucedería cuando el formulario no pasara una comprobación de máquina.

La descripción contemporánea más detallada es elRFC 1400, publicado en marzo de 1993. Su autor, Scott Williamson, trabajaba para Network Solutions, el contratista entrante del registro. El documento es, por lo tanto, un relato de primera mano de la transición prevista y del proceso de solicitud, no un examen independiente del rendimiento. Aun así, es inusualmente preciso acerca de la secuencia administrativa.

Durante la transición hasta el 31 de marzo, los usuarios no DDN podían enviar las plantillas existentes del Centro de Información de Red DDN (DDN NIC) a la antigua dirección del DDN NIC o a la nueva dirección del hostmaster de InterNIC. Los envíos por correo electrónico, fax y correo postal recibidos en cualquiera de los dos sitios serían procesados. Los usuarios DDN permanecían en una ruta militar separada y se les indicó que continuaran enviando sus solicitudes de registro al DDN NIC. La transición dividió las poblaciones de servicio; no cerró la institución anterior de un plumazo.

A partir del 1 de abril, una nueva solicitud de registro no DDN debía enviarse al buzón de registro automatizado de Network Solutions utilizando la nueva plantilla. Una plantilla obsoleta que llegara allí sería devuelta con errores de análisis y el formulario de reemplazo adjunto. El buzón del hostmaster continuaría aceptando el formato antiguo hasta el 30 de junio. Después de esa fecha, el formato antiguo sería devuelto en lugar de procesado.

El nuevo formulario fue diseñado para manejo automatizado y despojado de referencias específicas de DDN. Una vez enviado, un servidor de correo analizaba la plantilla y realizaba una comprobación rápida de la información que podía verificarse. El RFC 1400 utilizó un conflicto de nombre de dominio como ejemplo. A continuación, el sistema devolvía un formulario de verificación o un rechazo con mensajes de error.

Una verificación no era en sí el resultado final. El solicitante debía inspeccionar la interpretación de la máquina. Si la información analizada era correcta, devolvía el formulario a un buzón de verificación separado. Si era incorrecta, lo corregía antes de responder. Una solicitud rechazada debía ajustarse y reenviarse a través de la recepción automatizada. Los datos de verificación corregidos se comprobaban de nuevo y se emitía otro formulario de verificación. Solo después de que los Servicios de Registro recibieran una verificación aceptable, la solicitud pasaba al procesamiento final por parte del personal de InterNIC.

Esa secuencia combinaba trabajo de máquina y humano. El analizador gestionaba la recepción, las comprobaciones de formato, la verificación seleccionada y un ciclo de confirmación. El personal de registro retenía la etapa de procesamiento final. El RFC 1400 no revela la trayectoria completa de decisión interna para una solicitud de número de red. No muestra cómo el personal evaluaba un plan de topología particular, cómo se resolvían las consideraciones técnicas contrapuestas, ni qué explicación acompañaba una reducción sustancial o un rechazo. Tampoco su ejemplo de ticket de dominio establece el tratamiento del trabajo de números IP o ASN.

El solicitante disponía de siete días para devolver el formulario de verificación. Si no llegaba ninguna verificación dentro de ese plazo, la solicitud original caducaba y debía presentarse de nuevo. La regla de caducidad identifica una consecuencia procesal, pero el documento no proporciona una tasa de incidencia. No muestra con qué frecuencia caducaban las solicitudes, si se perdían mensajes, con qué frecuencia un error del analizador requería otro ciclo, o si la repetición producía un retraso material. La conformidad del formulario era una condición para el progreso; la evidencia disponible no convierte esa condición en un coste medible para los solicitantes.

La secuencia también ofrecía beneficios notables. Un mensaje de confirmación incluía un número de ticket de incidencia. Un usuario podía consultar el estado de la solicitud con la utilidadfingero conectándose interactivamente al host de registro. El ejemplo mostraba si un ticket estaba pendiente, cómo había llegado, cuándo se abrió y qué cuenta interna lo poseía. Para un servicio en expansión, esto sustituía parte de la incertidumbre de un buzón no rastreado por un estado administrativo visible.

El soporte manual seguía disponible por teléfono, correo electrónico, fax y correo postal. El servicio WHOIS operaba tanto en el sitio del DDN NIC como en el de InterNIC durante la transición. A partir del 1 de abril, el servidor DDN debía contener información DDN, mientras que el servidor InterNIC contenía registros sobre direcciones IP, dominios, ASN y puntos de contacto asociados. La distribución de la zona raíz, el registro de dominios, la asignación de números, los registros de contacto y el acceso WHOIS compartían partes del mismo entorno operativo, pero no eran la misma función.

El recorrido revela la concentración exacta que importa. En el servicio central no DDN, Network Solutions operaba la entrada electrónica aceptada, las plantillas, el analizador, el bucle de rechazo y corrección, la etapa de procesamiento por personal, el sistema de estado de tickets y el sistema de registros de registro. Esto es evidencia de una dependencia administrativa consecutiva. No es aún evidencia de que cada solicitante en el mundo tuviera que usar esta ruta, de que una clase particular careciera de alternativas, o de que el contratista ejerciera su posición para causar daño.

El mapa de lanzamiento—y la fecha en que dejó de estar completo

InterNIC se presentó a los usuarios como un servicio coordinado, pero la NSF lo obtuvo a través de organizaciones separadas. Elanuncio del 1 de abril de 1993 de los servicios operativos de InterNICdescribía un diseño de lanzamiento dividido entre servicios de registro, servicios de directorio y base de datos, y servicios de información. Una identidad pública unificada pretendía ocultar costuras innecesarias sin borrar la asignación subyacente de responsabilidad.

Network Solutions recibió el componente de registro. Su trabajo central no DDN incluía el registro de nombres de dominio, el registro de servidores de nombres de dominio, la asignación de números de red y la asignación de ASN. Aceptaba solicitudes, operaba los sistemas de procesamiento, mantenía los datos de registro y transfería los datos para su publicación y acceso.

AT&T recibió los servicios de directorio y base de datos. Esa función abarcaba el almacenamiento, recuperación y descubrimiento de registros, documentos, organizaciones, personas, servidores y otros recursos de Internet. Estaba relacionada con el registro porque los datos completados tenían que estar disponibles para los usuarios, pero AT&T no se convirtió por ello en una segunda ruta para obtener una asignación de número de red.

General Atomics, operando a través de CERFnet, recibió el componente de información y referencia. Su función era la orientación: responder preguntas sobre el uso y conexión a Internet, mantener recursos de información y derivar a los usuarios a servicios u organizaciones de soporte apropiados. Un mostrador de referencia podía ayudar a un solicitante a encontrar la ruta de registro; no podía sustituir al actor autorizado para procesar una asignación.

Otras instituciones permanecieron fuera de este trío de contratistas. La NSF ostentaba los contratos, proporcionaba financiación, supervisaba el rendimiento, aprobaba acciones específicas, evaluaba el progreso y coordinaba disputas entre los gestores. El Instituto de Ciencias de la Información de la USC (USC/ISI) continuaba la función de coordinación de IANA, incluyendo la responsabilidad por encima o junto a los registros y la autoridad para delegar partes de la administración de números. El DDN NIC conservaba su ruta para usuarios militares. Los acuerdos regionales y locales ya empezaban a cambiar qué registro atendía a una población determinada.

Este era el mapa de abril de 1993, no una descripción estable de todo el período hasta 1998. Lareproducción de archivo de la Enmienda 4, fechada el 13 de septiembre de 1995, dice que se eliminó una referencia a General Atomics para reflejar la reciente terminación de su acuerdo. La reproducción también contiene una aparente inconsistencia en el número de contrato: asocia a General Atomics con NCR-9218179, mientras que el texto base reproducido asigna NCR-9218179 a AT&T y NCR-9218749 a General Atomics. El material accesible no justifica corregir silenciosamente esa inconsistencia ni determinar a partir de ella la historia legal completa del contrato terminado. Sí establece que la descripción original de tres gestores ya no estaba completa en septiembre de 1995.

Ese cambio afecta a la pregunta central del artículo. Network Solutions no gobernó un sistema de tres contratistas sin cambios durante cinco años. La dependencia del registro debe fecharse independientemente de la organización más amplia de InterNIC. Sus sistemas siguieron siendo importantes, pero la disposición circundante de servicios de información, la jerarquía regional y la supervisión federal evolucionaron durante el período del contrato.

La división inicial también evita una fusión engañosa de funciones. Un nombre no es una dirección. Un ASN no es un dominio. El DNS inverso vincula la administración de números al sistema de nombres sin colapsar ambos. La publicación en directorio no es autoridad de asignación. La derivación de información no es una adjudicación. La coordinación de la zona raíz no puede utilizarse como sustituto de la experiencia en asignación de direcciones. Cada función tenía su propia evidencia, población de solicitantes y posibles modos de fallo.

Antes de leer el contrato, una advertencia sobre el contrato

El material del acuerdo disponible es útil pero no está autenticado como un registro federal completo y ejecutado.

Latranscripción privada de Cavebeares una transcripción privada. Elescaneo de 31 páginas alojado en el espejo de Freespeeches un escaneo alojado en un espejo sin una cadena de custodia autenticada. Lareproducción de archivo de ICANNes una reproducción de archivo en lugar de una copia canónica de la NSF. Ninguna es una copia canónica de la NSF. Estas fuentes permiten comparar y localizar cláusulas; no establecen que el conjunto accesible contenga el acuerdo ejecutado completo, todo el material de propuesta incorporado, todos los anexos, el historial completo de firmas, un conjunto de páginas verificado o la cadena completa de enmiendas.

Esas limitaciones son visibles a simple vista en el conjunto superviviente. El acuerdo reproducido se refiere a la propuesta de Network Solutions de septiembre de 1992, un suplemento colaborativo de octubre de 1992 y las fórmulas de calidad en la propuesta. Esos materiales no están completamente disponibles en la reproducción base. Las condiciones generales aparecen en el escaneo del espejo, mientras que la página de ICANN reproduce principalmente condiciones especiales y enmiendas posteriores. La Enmienda 4 incorpora otra propuesta y anexos por referencia. Un lector de archivo puede reconstruir términos importantes, pero no autenticar todo el paquete operativo.

En consecuencia, lo que sigue es una lectura de reproducciones provisionales. “La reproducción de archivo indica” y “el escaneo del espejo parece proporcionar” son calificaciones probatorias, no cautela estilística. Un tribunal o relato gubernamental posterior puede corroborar un componente, fecha o cálculo sin demostrar que cada página reproducida es completa y genuina.

La advertencia más obvia es un conflicto de 1.000.000 USD en la cantidad estimada. La reproducción de la portada indica un total estimado de4.219.339 USD. La reproducción del Artículo 8 indica5.219.339 USD. El escaneo del espejo parece desglosar la cifra del Artículo 8 en4.854.061 USD de costo estimado más una tarifa fija de 365.278 USD, lo que aritméticamente equivale a 5.219.339 USD.

La discrepancia entre el total de la portada y el total del Artículo 8 es exactamente de1.000.000 USD. La aritmética interna no puede determinar qué cifra principal representó el contrato completo ejecutado. Solo muestra que los componentes del Artículo 8 suman el total del Artículo 8. Unadescripción de un tribunal federal de distrito de 1998repitió de forma independiente el componente de reembolso de 4.854.061 USD y la tarifa fija de 365.278 USD. Eso corrobora la aritmética de los componentes; no autentica la copia completa del acuerdo, sus anexos ni su historial de enmiendas.

Se pueden recalcular varias proporciones útiles a partir de las cifras del Artículo 8, siempre que se identifiquen como cálculos y no como tarifas contractuales. La tarifa fija de 365.278 USD es aproximadamente el7,5252%del costo estimado reproducido de 4.854.061 USD y aproximadamente el6,9985%del total reproducido de 5.219.339 USD del Artículo 8. La asignación inicial provisional fue de1.162.245 USDhasta el 31 de marzo de 1994, aproximadamente el22,2680%del total del Artículo 8.

Por lo tanto, la reproducción de la portada y la reproducción del Artículo 8 deben permanecer una al lado de la otra. Elegir una en silencio crearía una precisión falsa. La afirmación defendible es que las fuentes entran en conflicto en el total, mientras que los componentes del Artículo 8 son matemáticamente coherentes y posteriormente repetidos judicialmente.

Lo que el contrato provisional intentaba controlar

Con esas limitaciones en mente, la reproducción de archivo describe un instrumento de adquisición de duración limitada vigente desde el 1 de enero de 1993 hasta el 30 de septiembre de 1998. Divide el período en una fase de incorporación de tres meses, cinco años de apoyo operativo a partir del 1 de abril de 1993, y un período de flexibilidad de seis meses sin costo adicional.

Las disposiciones de financiación reproducidas describen el reembolso de costos más una tarifa fija. Esa estructura no implica desperdicio, indiferencia o desempeño deficiente. Solo significa que el pago no se basaba exclusivamente en un producto verificado, como una asignación completada con precisión dentro de un período medido de extremo a extremo. La disciplina del servicio debía provenir de los requisitos, informes, supervisión de la NSF, decisiones de financiación anual, revisión del rendimiento y la posibilidad de enmienda o reemplazo.

Network Solutions aparece en la reproducción como principal responsable de la calidad, puntualidad y gestión eficaz de los servicios de registro. La NSF retuvo la planificación de apoyo, la supervisión, el monitoreo y la evaluación. El oficial de programa podía revisar el progreso y participar en discusiones técnicas o de programación, pero la reproducción limitaba la capacidad de ese oficial para ordenar trabajo fuera del alcance, aumentar el costo estimado, extender el período de desempeño o cambiar términos expresos. Los cambios materiales requerían el canal de subvenciones y contratos y una acción por escrito.

El mecanismo de financiación otorgaba a la NSF un apalancamiento recurrente. La asignación inicial cubría el desempeño hasta el 31 de marzo de 1994, con fondos adicionales previstos de forma incremental. El texto reproducido requería notificación si los costos esperados durante los siguientes 60 días, sumados a los costos ya incurridos, excedían el 85% de la cantidad asignada. El apoyo futuro estaba vinculado a la revisión anual, un plan de programa propuesto, negociación y fondos disponibles.

El monitoreo se diseñó como un proceso recurrente en lugar de una inspección al final del período. La reproducción de archivo exige revisiones semanales de transición durante la fase de incorporación y después hasta que la NSF indicara lo contrario. Se contemplaban reuniones conjuntas entre los gestores al menos trimestralmente durante el primer año. Los informes trimestrales debían cubrir el estado técnico, los logros, los problemas, la colaboración, los cambios en los planes, las aprobaciones pendientes y los gastos. Las presentaciones anuales debían identificar los objetivos cumplidos, superados o no alcanzados y explicar las desviaciones significativas del plan.

El requisito del informe final reproducido contemplaba un relato del trabajo y los problemas lo suficientemente detallado como para que una organización razonablemente informada pudiera replicar el trabajo. También contemplaba la entrega de software y datos si se solicitaba. Ese lenguaje expresa una ambición de continuidad, pero la existencia de una cláusula de entrega no prueba si otro operador podría asumir un servicio en vivo con sus colas, correspondencia, conocimiento tácito de políticas y rutinas del personal intactos.

La Enmienda 4 agregó otro mecanismo de visibilidad. Su reproducción de archivo exigía la disponibilidad pública, a partir de noviembre de 1995, de las medidas de rendimiento de los servicios de registro, los tiempos de respuesta y el rendimiento frente a esas medidas. También pedía que el informe de revisión del rendimiento se pusiera a disposición para revisión pública. Esto indica que la evidencia del rendimiento público se había convertido en una preocupación explícita. No proporciona las cifras faltantes por sí mismo.

El contrato también separaba la coordinación de la revisión de solicitudes. El lenguaje de colaboración reproducido permitía al oficial de programa de la NSF resolver disputas técnicas, de gestión o de programación entre los gestores de InterNIC. Eso podía abordar un desacuerdo entre Network Solutions y AT&T sobre una transferencia, u otro conflicto de gestión dentro del proyecto. No se expresó como una audiencia para un solicitante que impugnara una decisión sobre números.

El diseño de principal-agente era, por lo tanto, más sustancial que un subsidio pasivo. La NSF retenía dinero, informes, aprobación, evaluación y herramientas de coordinación. Network Solutions aún controlaba los sistemas diarios y el personal a través de los cuales avanzaban las solicitudes centrales. La pregunta importante no es si existía una supervisión formal; existía. Es si la evidencia conservada muestra con qué prontitud, consistencia o eficacia esos controles protegieron a los solicitantes de números. En ese punto, el registro público es escaso.

El reloj de tres días que comienza después de la finalización

Las reproducciones del acuerdo provisional incluyen requisitos de tiempo de respuesta distintos para las asignaciones de números de red con clase:3 días laborables para la Clase C,5 días laborables para la Clase By22 días laborables para la Clase A. Estos son requisitos reproducidos, no resultados de cumplimiento autenticados ni observaciones del servicio real.

Su denominador es crucial. La definición reproducida inicia el reloj al recibir unasolicitud completada, incluyendo cualquier información específicamente solicitada sobre la topología de red y el uso del espacio de direcciones previamente asignado. Termina en la asignación de un número.

Eso excluye varias etapas que un solicitante podría experimentar. La primera recepción queda fuera del período medido si el envío no se considera completo. El rechazo y la corrección del analizador están fuera. El tiempo de espera de la verificación del solicitante está fuera. Los intercambios adicionales sobre topología, utilización existente o necesidad proyectada pueden preceder a la finalización. El retraso en la publicación después de la asignación también está fuera del reloj, al igual que los envíos abandonados antes de alcanzar la finalización.

Un contratista podría, por lo tanto, cumplir un requisito de tres días laborables para la Clase C después de la finalización, mientras que el solicitante experimentaba un intervalo más largo desde el primer envío hasta el registro utilizable. Esa posibilidad no es evidencia de que ocurrieran largas demoras. Lo contrario también importa: un intercambio prolongado antes de la finalización podría reflejar evidencia faltante o inadecuada proporcionada por el solicitante, en lugar de un fallo del contratista.

Una evaluación seria requeriría al menos cuatro marcas de tiempo: primera recepción, primera respuesta del analizador o del personal, reconocimiento de la finalización y asignación o rechazo final. También necesitaría el tipo y tamaño de la solicitud, cualquier evidencia adicional solicitada, el tiempo de respuesta del solicitante, las pausas para coordinación y el momento en que los datos de registro resultantes estuvieron disponibles.

La reproducción hace referencia a fórmulas de calidad en una propuesta que no está presente en el conjunto accesible del acuerdo. Sin esas definiciones, el investigador no puede determinar si la calidad se muestreó entre nombres, números, ASN y actualizaciones de registros; si se utilizó una media, mediana, percentil o umbral; ni cómo se trataron los envíos rechazados, corregidos, caducados y abandonados.

Las cifras de 3, 5 y 22 días siguen siendo valiosas. Muestran que la adquisición intentó hacer del tiempo de respuesta de números una obligación especificada. No revelan cuántas solicitudes entraron en cada clase, cuántas cumplieron el estándar, ni si el reloj se aplicó de manera consistente.

Mayo de 1994: escala en unidades que no deben mezclarse

La evidencia contemporánea más sólida de la carga de trabajo proviene de una sección presentada por el contratista en elInforme Mensual de Internet de mayo de 1994. Registra varios tipos diferentes de actividad:

• 5.009 correos electrónicos al hostmaster
• 251 solicitudes postales o por fax
• 2.047 llamadas telefónicas
• 1.316 dominios registrados
• 565 entradas de dirección inversa
• 12.645 unidades de números de red Clase C asignadas
• 20 unidades de números de red Clase B asignadas
• 57 ASN asignados

Ninguna de estas unidades puede sumarse para obtener un total significativo llamado “solicitudes”. Un correo electrónico puede ser una solicitud, corrección, consulta de estado o pregunta sobre políticas. Una llamada telefónica puede referirse a cualquiera de varias funciones. Una entrada de dirección inversa no es una nueva asignación. Un registro de dominio no es una asignación de ASN.

Lo más importante es que las 12.645 unidades de Clase C no representan 12.645 solicitantes. El informe dice por separado que bloques de 256 redes Clase C se asignaron a múltiples organizaciones y al DDN NIC. Una sola acción de solicitud o asignación podría, por lo tanto, dar cuenta de muchas de las unidades reportadas. La cifra demuestra la escala de unidades de direcciones registradas en el mes, no el número de solicitantes o adjudicaciones únicas.

El mismo informe enumera el uso de los servicios de información en mayo sin resolver el denominador de registro. Indica211.257 consultas de cliente WHOISy785.015 consultas de servidor WHOIS. Por separado, informa de48.859 conexiones Gopher,24.748 conexiones WAIS,8.779 conexiones FTPy1.387 conexiones Mailserv. Las consultas, conexiones, solicitudes, asignaciones y contactos telefónicos siguen siendo distintos.

Estas cifras constituyen un sólido argumento de eficiencia para una infraestructura común. Una oficina puramente manual se habría enfrentado a una presión creciente del correo, llamadas, actualizaciones de bases de datos, consultas y múltiples tipos de identificadores. Los formularios estándar permitieron mecanizar las comprobaciones repetitivas. El análisis podía mantener los campos mal formados fuera de la cola del personal. Los mensajes de error podían informar al solicitante lo que el sistema rechazaba. La verificación podía detectar un malentendido de la máquina antes de que se convirtiera en un registro público. El estado del ticket podía reducir la incertidumbre y evitar algunos contactos de soporte.

El informe mensual demuestra actividad a escala. No proporciona una tasa de finalización para las solicitudes de números, una tasa de rechazo del analizador, una tasa de abandono, una distribución de tiempos de respuesta ni una muestra independiente de precisión. No revela si un solicitante generó muchos correos electrónicos o si una llamada se refería a varios registros. Es evidencia operativa, no una auditoría de equidad.

Lo que añade el relato del contratista de 1996

Una transcripción alojada privadamente delInforme Anual de Progreso de los Servicios de Registro de InterNIC de 1996proporciona afirmaciones de rendimiento posteriores. Su procedencia es más débil que un informe de contratista autenticado, y sus estadísticas siguen siendo autoinformadas. Aun así, es más informativo que reemplazar el período solo con preguntas hipotéticas.

La transcripción dice que, a31 de diciembre de 1996, el 95% de las nuevas solicitudes de registro se estaban procesando en 24 horas. No proporciona un numerador, ni una población por tipo de solicitud, ni una regla de medición. “Nuevas solicitudes de registro” no se desglosa en dominios, trabajo de números IP, ASN, contactos u otras plantillas. La afirmación no puede reportarse como una tasa de finalización del 95% para números IP.

Un pasaje separado se refiere específicamente a los dominios. Dice quemás de 85.000 dominiosse registraron ennoviembre de 1996y quemás del 90% de esas solicitudesfueron procesadas automáticamente por el analizador en 24 horas. Esa declaración solo sobre dominios no puede mezclarse con la afirmación del 95% de fin de año. Es evidencia de una automatización sustancial de dominios en un mes, no una medida del tiempo de respuesta de asignación de direcciones o de la equidad.

La misma transcripción registra evidencia de soporte general menos halagüeña. Durante1996, las tasas de abandono de llamadas autoinformadas oscilaron entremenos del 8% y más del 50%. Las tasas fueron típicamentedel 10% al 20% durante la última parte del año. Las esperas promedio de los clientes fueron de aproximadamentecuatro minutos, y el tiempo promedio para devolver las solicitudes de correo de voz no se midió. El relato también dice que los problemas en los enlaces troncales telefónicos identificados en diciembre hicieron que muchos llamantes recibieran señales de ocupado.

Estas cifras ofrecen una visión limitada de la presión sobre el servicio. No proporcionan el número subyacente de llamadas, la distribución por mes o día, la duración de las llamadas, ni la proporción atribuible a los solicitantes de números. Una persona que llama buscando una asignación de IP no puede separarse de alguien que pregunta sobre un dominio, facturación o un registro de contacto. La evidencia respalda una conclusión general de que el soporte telefónico experimentó una presión sustancial y variable en 1996. No puede convertirse en una tasa de perjuicio en la asignación de números.

La transcripción anual también ilustra por qué los totales de actividad son un sustituto inestable de la calidad del servicio. La automatización podía procesar una alta proporción de dominios rápidamente mientras que los llamantes enfrentaban un acceso variable a la ayuda. Una afirmación de procesamiento en un día podía coexistir con retrasos de siete días en los correos de facturación o tiempos de manejo más largos para plantillas manuales seleccionadas. Diferentes funciones tenían diferentes colas, y una tasa de éxito agregada podía ocultar a la población más dependiente del juicio del personal.

Para el trabajo de números, el denominador necesario sigue ausente. No se puede calcular ninguna tasa de finalización reproducible sin el recuento de solicitudes completadas, solicitantes únicos, plantillas rechazadas, solicitudes corregidas, caducidades, abandonos, rechazos sustantivos y resultados de cumplimiento específicos por clase o prefijo. Ninguna distribución de tiempo transcurrido conecta la primera recepción, la finalización, la asignación y la publicación. Las fuentes tampoco proporcionan una duración de interrupción verificada ni una tasa de quejas específicas de números.

La evidencia conservada respalda así dos proposiciones a la vez. Network Solutions construyó y operó automatización capaz de manejar un volumen reportado sustancial. El registro público no permite una estimación confiable de con qué frecuencia los solicitantes de números experimentaron demora, corrección, rechazo o revisión exitosa.

Dónde se asentó realmente la concentración

La cadena central puede analizarse sin calificar cada requisito administrativo como un daño.

En la recepción, Network Solutions controlaba la dirección electrónica publicada, la plantilla aceptada y el analizador. Un formulario mal formado u obsoleto no podía avanzar por la vía automatizada hasta ser corregido. Los canales manuales permanecían, pero el mismo contratista de registro operaba en última instancia el servicio central no DDN.

En la verificación, el solicitante debía confirmar que la máquina había interpretado correctamente el envío. Esto era una protección contra errores silenciosos. También ponía la finalización del ciclo en el solicitante en un plazo de siete días. Se desconoce la incidencia de la caducidad, por lo que la regla demuestra dependencia y una posible consecuencia de reenvío, en lugar de una carga medible en una población.

La completitud era el siguiente límite. Una solicitud de número podía requerir información de topología y uso previo. Tal evidencia no era un adorno burocrático: la conservación de direcciones y la agregación de enrutamiento requerían que los registros evaluaran la necesidad operativa. El problema de gobernanza es que la determinación de completitud del contratista controlaba cuándo comenzaba el reloj de tiempo de respuesta reproducido. Sin registros de solicitudes con marcas de tiempo, es imposible saber si esa discreción se ejerció con prontitud o de manera inconsistente.

Seguía el procesamiento sustantivo. El personal de Network Solutions manejaba el trabajo central de números de red no DDN y ASN dentro del marco de delegación y técnico aplicable. Esto era más trascendental que dirigir a un usuario a un documento. El procesamiento del personal contribuía a si se asignaría un identificador solicitado, en qué cantidad y tras qué información de respaldo.

Después de la asignación venían el registro y la publicación. La reproducción provisional define la disponibilidad como la provisión de los datos de registro al adjudicatario del directorio y la base de datos. Network Solutions iniciaba la transferencia; AT&T ocupaba la capa de publicación y acceso en el lanzamiento. Una asignación y su registro público estaban conectados pero eran institucionalmente distintos.

Esa distinción crea un posible límite de falla. Un retraso podía surgir en el procesamiento, transmisión, publicación o corrección. Sin embargo, ninguna serie de conciliación recuperada muestra con qué frecuencia diferían los registros, con qué rapidez se resolvían los problemas de transferencia o si los usuarios podían identificar al gestor responsable. Las disposiciones de coordinación entre gestores del acuerdo reconocen la necesidad de gobernar esas costuras, pero no miden el fallo.

La revisión constituía la etapa final. El procedimiento administrativo público inicial era explícito sobre la corrección del analizador, el contacto con el hostmaster y el estado del ticket. Era mucho menos explícito sobre la revisión independiente de las decisiones sustantivas sobre números. El silencio en el RFC 1400 no puede probar que la reconsideración del personal, el contacto con IANA o la escalada informal nunca ocurrieron. Significa que el documento no proporciona un procedimiento de apelación orientado al solicitante que pueda evaluarse.

El hallazgo demostrado es, por lo tanto, unadependencia concentrada de recepción y procesamiento central. Network Solutions ocupaba etapas consecutivas en la ruta central no DDN: recepción, análisis, corrección, completitud, procesamiento por personal, asignación y actualización del registro. La evidencia no identifica una clase precisa de solicitantes para la cual el servicio DDN, RIPE NCC, APNIC, un registro local, espacio asignado por el proveedor o la escalada al registro superior estuviera demostrablemente no disponible. Tampoco proporciona un perjuicio operativo documentado causado por esa ausencia de elección.

Esto es más limitado que un punto de estrangulamiento universal, pero sigue siendo institucionalmente significativo. Concentrar etapas consecutivas puede hacer que la automatización sea coherente y los registros consistentes. También puede hacer que la calidad de la ruta central dependa en gran medida de los sistemas, la dotación de personal, las definiciones y las transferencias de un solo operador. El registro histórico respalda el análisis de esa dependencia sin presuponer abuso.

La geografía y la clase de solicitante cambiaron la ruta

El servicio central nunca tuvo una relación uniforme con cada solicitante de Internet a lo largo de 1993-1998.

Europa ya ofrecía el contraejemplo más claro. Lapropia historia de RIPE NCCdistingue su creación formal enabril de 1992de la distribución de direcciones, que no fue una actividad inicial sino que se añadió más tarde en1992. Para la transición de InterNIC, la administración de números europea había comenzado a moverse a través de una estructura regional.

ElRFC 1466, publicado en mayo de 1993, describía el Registro de Internet como el registro por defecto donde no existía una autoridad de registro delegada. Argumentaba a favor de distribuir el registro porque los registros geográficamente más cercanos podían atender mejor a las comunidades, idiomas y costumbres locales. Señalaba que RIPE NCC ya había recibido un bloque de espacio Clase C para la asignación europea.

El RFC 1466 no describía rutas comerciales intercambiables. Decía que un solicitante de red podía contactar directamente al Registro de Internet central y, según las circunstancias, podría ser remitido a un registro regional. El registro central debía estar preparado para atender a un suscriptor cuando fuera necesario. A nivel regional, el documento favorecía un único registro reconocido para cada área geográfica. La distribución reducía la dependencia central, pero podía crear una dependencia regional no intercambiable.

La ruta de Asia-Pacífico surgió en un calendario diferente. Lahistoria institucional de APNICdice que su piloto estaba previsto para comenzar enseptiembre de 1993y continuó hasta junio de 1994. IANA reconoció públicamente a APNIC enabril de 1994al delegar los rangos IPv4202/8 y 203/8. Por lo tanto, la ruta disponible para un solicitante de Asia-Pacífico dependía de la fecha, la geografía, la madurez del piloto y la delegación aplicable.

Para elRFC 2050, en noviembre de 1996, el mapa publicado de administración de números era explícitamente jerárquico: IANA, registros regionales y registros locales. Identificaba a InterNIC con América del Norte, a RIPE NCC con Europa y a APNIC con la región de Asia-Pacífico. Los registros locales operaban por debajo del nivel regional.

Las relaciones con los proveedores creaban otra ruta. El RFC 2050 aconsejaba a muchos ISP obtener espacio de direcciones de un proveedor ascendente para apoyar el enrutamiento jerárquico y la agregación. Ciertos proveedores multihomed o conectados a puntos de intercambio podían solicitar directamente a un registro regional. Los solicitantes en áreas sin un registro regional designado podían contactar a un registro regional, el cual podía manejar o remitir la solicitud.

El espacio asignado por un proveedor no equivalía a un registro central competidor. Podía conllevar implicaciones de reasignación de números si el cliente cambiaba de proveedor de conectividad. El espacio directo del registro tampoco garantizaba el enrutamiento global. La elección dependía de las circunstancias operativas, no meramente de la preferencia.

La ruta DDN permaneció separada para su población elegible durante la transición de 1993. A un usuario militar se le indicó que continuara con el DDN NIC. Esa ruta es evidencia contra un servicio único que abarcara a todos los solicitantes, pero no era una alternativa general abierta a todas las organizaciones no militares.

Para 1996, la descripción más precisa no era que Network Solutions sirviera como la única puerta global de números. InterNIC era un registro regional dentro de una jerarquía que también incluía a RIPE NCC, APNIC, registros locales y asignaciones basadas en proveedores. Anteriormente, el registro central seguía siendo el predeterminado para áreas sin delegado y conservaba importantes funciones de coordinación.

La regionalización redujo la población expuesta al proceso de solicitud central. No creó un mercado en el que cada solicitante pudiera cambiar de registro tras un mal servicio. Un operador europeo no podía necesariamente elegir el registro de América del Norte como sustituto; un cliente de proveedor podría tener que aceptar espacio ascendente; una solicitud grande o excepcional podría requerir coordinación de nivel superior. Las alternativas eran específicas en cuanto a fecha y población, y su no intercambiabilidad es central para entender tanto la resiliencia como la dependencia.

Cuatro remedios que no deben confundirse

El registro contiene cuatro tipos diferentes de corrección o revisión. Tratarlos como uno solo exageraría la protección del solicitante.

El primer carril era la corrección operativa. El RFC 1400 documentaba mensajes de error del analizador, formularios de verificación corregidos, reenvío, estado del ticket y contacto con el personal del hostmaster. Estos mecanismos abordaban entradas mal formadas, formularios obsoletos, interpretación del analizador y estado de la solicitud. El personal también podría haber reconsiderado un envío informalmente. El documento no revela la frecuencia, duración o resultado de esas interacciones.

El segundo carril se refería a disputas entre los gestores de InterNIC. La reproducción del acuerdo de archivo establece que el oficial de programa de la NSF podía resolver disputas técnicas, de gestión o de programación entre los colaboradores. Esto apoyaba la coordinación dentro del servicio contratado. No era una apelación del solicitante contra una decisión numérica.

El tercer carril se refería a los desacuerdos entre el adjudicatario y la NSF. Las condiciones generales alojadas en el espejo parecen disponer que las disputas de hecho no resueltas informalmente recibirían una decisión por escrito de un oficial de subvenciones de la NSF, con el adjudicatario pudiendo solicitar revisión dentro de los30 díasde recibir esa decisión. Debido a que las condiciones generales completas incorporadas y su procedencia no han sido autenticadas dentro del conjunto accesible de contratos ejecutados, esto sigue siendo evidencia contractual provisional. En todo caso, era un proceso de partes contratantes disponible para el adjudicatario, no un remedio otorgado a un solicitante de red.

El cuarto carril era la jerarquía de registros orientada al solicitante establecida en el RFC 2050. Una organización insatisfecha con el desempeño del registro que asigna podía apelar al registro superior. El registro asignador debía poner a disposición la documentación pertinente. Una apelación adicional podía pasar al superior del superior y, tras agotarse otras vías, en última instancia a IANA. Se esperaba que cada registro documentara su procedimiento de apelación.

El RFC 2050 mejoró la arquitectura publicada de revisión. Separaba el registro asignador de un revisor de nivel superior y se aplicaba específicamente a decisiones de direcciones. Era una Mejor Práctica Actual escrita por representantes asociados con InterNIC, APNIC, RIPE NCC e IANA, no una auditoría de cómo funcionaban las apelaciones en la práctica.

Ninguno de los materiales conservados proporciona una serie de apelaciones específicas de números. No hay un recuento recuperado de impugnaciones, duración promedio, tasa de revocación, distribución de resultados o evidencia de que solicitantes en situaciones similares recibieran una revisión consistente. La ausencia de dicha serie no demuestra que las apelaciones no se usaran o fueran ineficaces; impide una conclusión medida en cualquier sentido.

El mapa de remedios cambia, por lo tanto, con el tiempo y según el actor. En 1993, los solicitantes podían corregir formularios y contactar al personal, mientras que la NSF gestionaba a sus contratistas. Las condiciones generales provisionales proporcionaban un carril de revisión contractual para el adjudicatario. Para noviembre de 1996, el sistema de registro de números articuló una ruta orientada al solicitante a través de los registros superiores hasta IANA. Cada uno abordaba una disputa diferente.

Evidencia de rendimiento y continuidad al final de la cadena

Una afirmación sólida de perjuicio sistemático a los solicitantes de números requeriría varios conjuntos de datos que no se han recuperado juntos.

Los recuentos de solicitudes tendrían que identificar solicitudes de números completadas y solicitantes únicos, en lugar de unidades de direcciones, mensajes o llamadas. Los registros de tiempo de respuesta necesitarían marcas de tiempo de extremo a extremo, no solo el intervalo después de la finalización. Los datos de corrección necesitarían plantillas rechazadas, formularios corregidos, solicitudes caducadas y envíos abandonados. Los datos de decisión necesitarían rechazos sustantivos, reducciones y resultados específicos por clase o prefijo.

La fiabilidad requeriría interrupciones del servicio verificadas y sus duraciones. La rendición de cuentas requeriría recuentos de quejas, tasas de escalada, revocaciones y tiempos de resolución. La portabilidad requeriría evidencia que mostrara con qué rapidez otro operador podría asumir el servicio, incluido el software, los datos, las colas pendientes, la correspondencia, el historial de políticas y el conocimiento del personal.

El acuerdo reproducido contemplaba informes capaces de abordar algunas de estas preguntas. La Enmienda 4 exigía medidas de rendimiento públicas. La transcripción de 1996 hace referencia a datos de rendimiento y procesamiento, mientras que la presentación pública conservada es incompleta para el análisis específico de números. La existencia de un sistema de informes previsto no es lo mismo que la posesión de su serie completa.

Laopinión legal de 2016 de la GAOproporciona evidencia retrospectiva limitada sobre la transición posterior. Dice que, cuando la administración se trasladó al Departamento de Comercio en 1998, una disposición añadida exigía a Network Solutions entregar copias del software, los datos y la documentación generados en virtud del acuerdo hasta octubre. La GAO informó de la entrega de archivos de bases de datos endiez cartuchos de 8 milímetros, un archivador con la lista de las bases de datos y varios archivadores adicionales que contenían documentación de datos y software.

Esa evidencia demuestra una obligación de transición y una entrega física. No establece que los materiales fueran lo suficientemente completos como para operar el servicio, que capturaran el estado de la cola activa o la correspondencia histórica, o que un sucesor realizara una toma de control probada a partir de ellos. La reemplazabilidad operativa sigue siendo una inferencia que debe examinarse, no un fallo demostrado.

La investigación de la GAO era principalmente sobre la propiedad gubernamental y la posterior transición de IANA. Su relato se ocupa en gran medida de cuestiones de nombres de dominio y zona raíz y no proporciona ningún denominador de solicitudes de números. No puede llenar el registro faltante de solicitudes de direcciones, demoras o apelaciones.

Las tarifas de dominio posteriores, los litigios de marcas, la competencia entre registradores y las disputas sobre la propiedad de la zona raíz están igualmente delimitados. Pueden iluminar la historia de la misma empresa o contrato, pero no prueban que los solicitantes de números fueran rechazados, retrasados o se les negara un remedio. La evidencia específica de cada función sigue siendo necesaria.

Las métricas faltantes se concentran en los puntos donde la tesis del artículo se volvería causal. No hay una tasa de finalización de solicitudes de números reproducible, una duración de interrupción verificada, una tasa de quejas específicas de números, una tasa de escalada, una tasa de revocación ni un tiempo de conmutación. La evidencia muestra una dependencia administrativa y una observabilidad incompleta, no una pérdida de bienestar estimada.

Contrafactual: un solo gestor para los tres servicios

Considérese una alternativa construida por un analista en la que la NSF adjudicara el registro, el acceso al directorio y la base de datos, y los servicios de información a un único proveedor integrado. Este es un contrafactual para probar la estructura de la contratación, no una afirmación de que tal modelo fuera históricamente factible o preferible en 1993.

La integración podría reducir los costos de coordinación. Los datos de registro podrían pasar de la recepción a la publicación dentro de una misma organización. Un solo equipo de operaciones podría rastrear una falla a través del análisis, el procesamiento por personal, la disponibilidad de la base de datos, la consulta pública y el soporte general. Los usuarios no tendrían que identificar si un problema en la transferencia correspondía a Network Solutions o a AT&T.

La inversión en automatización también podría ser más coherente. Un solo sistema de identidad y tickets podría conectar a los solicitantes, organizaciones, dominios, números, ASN, contactos, registros de publicación e historial de soporte. Los cambios en los formatos de datos no requerirían acuerdo entre contratos. El personal de información general podría ver el estado de un registro sin necesidad de una derivación separada.

El riesgo es una contención de fallos más amplia. El mismo proveedor recibiría solicitudes, procesaría asignaciones, publicaría registros, respondería preguntas e informaría sobre su propio rendimiento. Una interrupción del sistema o una transición organizativa fallida podría afectar a la vez la recepción, el procesamiento autorizado, la publicación y la orientación.

El monitoreo también sería menos modular. Las organizaciones separadas creaban fronteras donde la NSF podía comparar los relatos de la entrega y comprobar si los datos pasaban del registro a la publicación. La separación no hacía que ninguno de los gestores fuera independiente de la financiación federal ni garantizaba informes veraces, pero un proveedor totalmente integrado eliminaría incluso ese contraste organizativo.

El reemplazo implicaría un paquete más amplio de sistemas y experiencia. Cambiar el servicio de registro ya requería continuidad de software, datos, colas y políticas. Reemplazar un InterNIC integrado añadiría infraestructura de directorio, herramientas de acceso público, archivos, servicios de información y una operación de soporte más amplia.

El contrafactual refuerza el argumento de eficiencia a favor de la división de la NSF. Los contratos separados limitaban la amplitud del rol formal de cualquier proveedor y permitían operaciones especializadas. También aclara por qué la concentración permanecía dentro del componente de registro: la división separaba servicios distintos en lugar de crear sustitutos para el mismo acto autorizado.

Contrafactual: varios proveedores de registro reemplazables

Una segunda alternativa construida por un analista permitiría que varios proveedores de registro atendieran a la misma población de solicitantes compartiendo un libro mayor autorizado y una función central de resolución de conflictos.

Cada proveedor podría aceptar una solicitud estándar, verificar el formato, reunir información de respaldo y enviar una transacción aprobada a un servicio central. Los solicitantes podrían cambiar a otro proveedor cuando el soporte fuera inaccesible. Una interrupción de un proveedor no necesariamente detendría todos los canales de recepción. La NSF podría comparar los tiempos de respuesta, las tasas de corrección y la experiencia de los solicitantes entre proveedores.

El núcleo autorizado aún necesitaría una serialización estricta. Dos proveedores no podían asignar el mismo bloque de números. Un sistema compartido tendría que gestionar el espacio disponible, las reservas pendientes, las asignaciones completadas, las excepciones y las revocaciones sin estados conflictivos. Una replicación retrasada podría ser operativamente peligrosa.

La consistencia plantearía un segundo desafío. Los proveedores podrían interpretar los requisitos de topología, utilización y agregación de manera diferente. Los solicitantes podrían buscar la decisión más permisiva. Serían necesarias una política común, evidencia estándar, registros de transacciones y un revisor vinculante. La distribución de la recepción, por lo tanto, desplazaría la autoridad central en lugar de eliminarla.

La inversión en automatización podría fragmentarse. Múltiples proveedores podrían duplicar analizadores, sistemas de estado e infraestructura de soporte, o depender de la NSF para construir una plataforma común. La interoperabilidad, la seguridad, la responsabilidad, los formatos de auditoría, las reglas de reserva y los procedimientos de migración tendrían que definirse antes de que la experiencia operativa hiciera obvios los requisitos.

El monitoreo podría mejorar si los proveedores generaran registros comparables, pero solo si el principal controlara las reglas de medición. Un proveedor podría iniciar su reloj en la primera recepción mientras que otro lo haría en la finalización. Uno podría contar los reenvíos como nuevas solicitudes. Sin denominadores estándar, la competencia aparente podría producir afirmaciones de rendimiento incomparables.

La revisión de los solicitantes también requeriría un diseño institucional. Una elección de servicio al cliente no es un sustituto de la apelación cuando el servicio central de políticas rechaza una asignación. Un cambio de proveedor podría ayudar con la explicación o la preparación del formulario, mientras que la decisión autorizada permanecería inalterada. El revisor compartido necesitaría documentación, plazos y autoridad sobre cada proveedor.

La contención de fallos sería mejor en la capa de recepción, pero incierta en el libro mayor. Varias puertas de entrada podrían sobrevivir a la interrupción de un proveedor. Un servicio central de reserva o unicidad fallido podría detenerlas todas. La arquitectura distribuiría parte del riesgo operativo preservando un núcleo no competitivo.

No se puede asumir la viabilidad histórica. Las limitaciones de enrutamiento de principios de los años 90, el espacio de direcciones escaso, la estandarización de políticas incompleta y el costo de la coordinación en tiempo real pueden haber favorecido un propietario claro para cada dominio de decisión. La delegación regional abordó la escala mediante una jerarquía geográfica en lugar de proveedores competidores que compartieran un mismo fondo.

Esta alternativa, sin embargo, expone preguntas de diseño útiles. ¿Podría la recepción ser reemplazable sin fragmentar el libro mayor? ¿Podrían los solicitantes cambiar de proveedor de soporte mientras las decisiones se mantenían consistentes? ¿Podrían los registros comparables hacer que la revisión del rendimiento fuera más creíble? ¿Podría separarse el revisor central del procesamiento de primera línea? La evidencia conservada de InterNIC no prueba esas posibilidades, por lo que no se deriva ninguna estimación de bienestar, demora o costo de cambio.

La conclusión proporcional

El diseño de InterNIC de la NSF de 1993 combinaba especialización con una identidad pública común. Network Solutions manejaba el registro central no DDN; AT&T manejaba el acceso al directorio y la base de datos; General Atomics/CERFnet manejaba la información y referencia. La NSF retenía la financiación, el monitoreo, las aprobaciones, la evaluación y la coordinación entre gestores. USC/ISI continuaba la coordinación de IANA, y el DDN NIC conservaba la ruta militar.

El sistema de registro ofrecía una administración útil. Los formularios estructurados, el análisis automatizado, los errores explícitos, la confirmación del solicitante, el estado del ticket, la infraestructura común y el procesamiento final humano eran respuestas plausibles al rápido aumento del volumen. Los totales operativos de mayo de 1994 y la posterior afirmación de automatización de dominios muestran una actividad sustancial, aunque no una prueba independiente de la calidad del servicio de números.

Dentro de la institución dividida, Network Solutions controlaba etapas consecutivas de la ruta central de registro. Esa concentración hacía que una solicitud dependiera del canal aceptado, el analizador, el ciclo de corrección, la determinación de completitud, el procesamiento por personal y la actualización del registro de un solo contratista. Se describe adecuadamente como dependencia concentrada de recepción y procesamiento central.

El sistema circundante cambió. RIPE NCC distribuía direcciones en Europa, APNIC surgió en Asia-Pacífico, los registros locales y los proveedores atendían a poblaciones adicionales, los usuarios DDN conservaban otro canal, y el RFC 2050 situaba a InterNIC dentro de una jerarquía regional con una ruta de apelación al registro superior. Estas alternativas eran específicas en cuanto a tiempo, geografía y clase de solicitante, en lugar de opciones intercambiables.

La evidencia de supervisión y remedio está incompleta pero no ausente. La NSF tenía herramientas contractuales; los solicitantes tenían corrección y contacto con el personal; las condiciones generales provisionales describían una revisión entre adjudicatario y NSF; y el RFC 2050 posteriormente articuló la apelación del solicitante a través de los registros superiores hasta IANA. Lo que falta es la serie de resultados necesaria para juzgar esos mecanismos en casos de números.

El “precio” del título es, por lo tanto, una pregunta de investigación más que una pérdida cuantificada. La administración central proporcionaba escala y consistencia mientras colocaba múltiples etapas de una cadena definida en un solo contratista. El registro conservado no prueba que esta dependencia fuera universalmente inevitable, abusada sistemáticamente o responsable de un daño medible a los solicitantes de números.