O Contrato InterNIC e o Preço de um Único Ponto de Estrangulamento Administrativo

Resumo

• Em abril de 1993, a NSF lançou a InterNIC com a Network Solutions cuidando do registro central de domínios não DDN, números de rede e ASNs, recebimento, processamento e atualizações; AT&T cuidando do acesso a diretório e banco de dados; e General Atomics/CERFnet cuidando de informações e referências; as reproduções do contrato provisório também estabeleciam prazos de 3, 5 e 22 dias úteis para atribuições de Classe C, B e A após a conclusão de uma solicitação, mas as evidências remanescentes não medem o cumprimento.
• O processo de solicitação documentado da Network Solutions usava modelos padrão, análise automatizada, mensagens de erro, verificação do solicitante, uma janela de confirmação de sete dias, processamento final humano e status de ticket visível, oferecendo ganhos credíveis em escala, consistência e visibilidade de correção.
• As cópias remanescentes do contrato são reproduções não autenticadas, os relatórios de desempenho carecem de denominadores decisivos de número de solicitações, e as rotas documentadas de correção, entre gestores, entre partes contratantes e de recurso ao registro não fornecem uma série recuperada de uso, duração, reversão ou resultado.
• O registro estabelece uma dependência concentrada de recebimento e processamento central para o trabalho definido de registro não DDN, mas não a inevitabilidade universal, exclusão sistemática, dano quantificado ao solicitante ou prova de que as rotas regional, militar, de registro local e de provedor estavam indisponíveis para uma população afetada específica.

1 de abril de 1993: uma solicitação entra no novo canal

Uma solicitação de registro não militar que chegava ao serviço central da Internet em 1 de abril de 1993 encontrava um caminho deliberadamente estruturado. A mudança era visível primeiro em instruções cotidianas: qual caixa de correio usar, qual formulário preencher, para onde telefonar e o que aconteceria quando o formulário falhasse em uma verificação automatizada.

A descrição contemporânea mais detalhada é aRFC 1400, publicada em março de 1993. Seu autor, Scott Williamson, trabalhava para a Network Solutions, a nova contratada de registro. O documento é, portanto, um relato de primeira mão da transição pretendida e do processo de solicitação, não um exame independente do desempenho. Ainda assim, é extraordinariamente preciso sobre a sequência administrativa.

Durante a transição até 31 de março, usuários não DDN podiam enviar modelos existentes do DDN Network Information Center para o endereço antigo do DDN NIC ou para o novo endereço hostmaster da InterNIC. Envios por e-mail, fax e correio recebidos em qualquer um dos sites deveriam ser processados. Os usuários DDN permaneciam em uma rota militar distinta e eram instruídos a continuar enviando suas solicitações de registro ao DDN NIC. A transição dividiu as populações de serviço; não fechou a instituição anterior de uma só vez.

A partir de 1 de abril, uma nova solicitação de registro não DDN deveria ser enviada para a caixa de correio automatizada de registro da Network Solutions usando o novo modelo. Um modelo obsoleto que chegasse lá seria devolvido com erros de análise e o formulário substituto anexado. A caixa de correio hostmaster continuaria aceitando o formato antigo até 30 de junho. Após essa data, o formato antigo seria devolvido em vez de processado.

O novo formulário foi projetado para manipulação automatizada e sem referências específicas do DDN. Uma vez enviado, um servidor de correio analisava o modelo e realizava uma verificação rápida das informações que podiam ser verificadas. A RFC 1400 usou um conflito de nome de domínio como exemplo. O sistema então retornava um formulário de verificação ou uma rejeição com mensagens de erro.

Uma verificação não era, por si só, o resultado final. O solicitante precisava inspecionar a interpretação da máquina. Se as informações analisadas estivessem corretas, o solicitante devolvia o formulário para uma caixa de correio de verificação separada. Se estivessem erradas, o solicitante as corrigia antes de responder. Uma solicitação rejeitada precisava ser ajustada e reenviada pelo sistema automatizado de entrada. Os dados de verificação corrigidos eram verificados novamente, e outro formulário de verificação era emitido.

Somente após os Serviços de Registro receberem uma verificação aceitável, a solicitação passava para o processamento final pela equipe da InterNIC.

Essa sequência combinava trabalho de máquina e humano. O analisador geria a entrada, verificações de formatação, verificação selecionada e um ciclo de confirmação. A equipe de registro mantinha a etapa de processamento final. A RFC 1400 não revela o caminho interno completo de decisão para uma solicitação de número de rede. Ela não mostra como a equipe avaliava um plano de topologia específico, como considerações técnicas conflitantes eram resolvidas ou que explicação acompanhava uma redução ou recusa significativa. Nem seu exemplo de ticket de domínio estabelece o tratamento de trabalho com números IP ou ASNs.

O solicitante tinha sete dias para devolver o formulário de verificação. Se nenhuma verificação chegasse nesse período, a solicitação original expirava e precisava ser submetida novamente. A regra de expiração identifica uma consequência processual, mas o documento não fornece uma taxa de incidência. Ele não mostra com que frequência as solicitações expiravam, se mensagens eram perdidas, com que frequência um erro do analisador exigia outro ciclo ou se a reenvio produzia atraso material. A conformidade do formulário era uma condição de progresso; as evidências disponíveis não transformam essa condição em um custo medido para os solicitantes.

A sequência também oferecia benefícios notáveis. Uma mensagem de confirmação incluía um número de ticket de problema. Um usuário podia consultar o status da solicitação com o utilitáriofingerou conectando-se interativamente ao host de registro. O exemplo exibia se um ticket estava pendente, como havia chegado, quando foi aberto e qual conta interna o possuía. Para um serviço em expansão, isso substituía parte da incerteza de uma caixa de correio não rastreada por um estado administrativo visível.

O suporte manual permanecia disponível por telefone, e-mail, fax e correio. O serviço WHOIS operava tanto no site do DDN NIC quanto no da InterNIC durante a transição. A partir de 1 de abril, o servidor DDN deveria conter informações do DDN, enquanto o servidor InterNIC mantinha registros referentes a endereços IP, domínios, ASNs e pontos de contato associados. Distribuição da zona raiz, registro de domínios, atribuição de números, registros de contato e acesso WHOIS compartilhavam partes do mesmo ambiente operacional, mas não eram a mesma função.

A análise revela a concentração exata que importa. No serviço central não DDN, a Network Solutions operava a entrada eletrônica aceita, modelos, analisador, ciclo de rejeição e correção, etapa de processamento pela equipe, sistema de status de tickets e sistema de registro de dados. Isso é evidência de dependência administrativa consecutiva. Ainda não é evidência de que todo solicitante no mundo tivesse que usar essa rota, de que uma classe específica carecia de alternativas, ou de que a contratada exerceu sua posição para causar danos.

O mapa de lançamento — e a data em que deixou de estar completo

A InterNIC foi apresentada aos usuários como um serviço coordenado, mas a NSF a contratou por meio de organizações separadas. Oanúncio de 1 de abril de 1993 dos serviços operacionais da InterNICdescrevia um design de lançamento dividido entre serviços de registro, serviços de diretório e banco de dados e serviços de informação. Uma identidade pública unificada visava ocultar emendas desnecessárias sem apagar a alocação subjacente de responsabilidade.

A Network Solutions recebeu o componente de registro. Seu trabalho central não DDN incluía registro de nomes de domínio, registro de servidores de nomes de domínio, atribuição de números de rede e atribuição de ASNs. Ela aceitava candidaturas, operava os sistemas de processamento, mantinha dados de registro e encaminhava dados para publicação e acesso.

A AT&T recebeu serviços de diretório e banco de dados. Essa função dizia respeito ao armazenamento, recuperação e descoberta de registros, documentos, organizações, pessoas, servidores e outros recursos da Internet. Estava relacionada ao registro porque os dados concluídos precisavam se tornar disponíveis aos usuários, mas a AT&T não se tornou, assim, uma segunda rota para obter uma atribuição de número de rede.

A General Atomics, operando por meio da CERFnet, recebeu o componente de informação e referência. Sua função era orientação: responder perguntas sobre uso e conexão à Internet, manter recursos de informação e encaminhar usuários para serviços apropriados ou organizações de suporte. Um balcão de referência podia ajudar um solicitante a encontrar a rota de registro; não podia substituir o agente autorizado a processar uma atribuição.

Outras instituições permaneciam fora desse trio de contratadas. A NSF detinha as concessões, fornecia financiamento, monitorava o desempenho, aprovava ações especificadas, avaliava o progresso e coordenava disputas entre os gestores. O Information Sciences Institute da USC continuava a função de coordenação da IANA, incluindo responsabilidade acima ou ao lado dos registros e autoridade para delegar partes da administração de números. O DDN NIC mantinha sua rota para usuários militares. Arranjos regionais e locais já começavam a mudar qual registro atendia uma determinada população.

A estrutura de lançamento pode ser declarada de forma compacta:

Este era o mapa de abril de 1993, não uma descrição estável de todo o período até 1998. Areprodução de arquivo da Emenda 4, datada de 13 de setembro de 1995, diz que uma referência à General Atomics estava sendo excluída para refletir o recente término de seu acordo. A reprodução também contém uma aparente inconsistência no número da concessão: ela associa a General Atomics com NCR-9218179, enquanto o texto base reproduzido atribui NCR-9218179 à AT&T e NCR-9218749 à General Atomics. O material acessível não justifica corrigir silenciosamente essa inconsistência nem determinar a partir dela o histórico jurídico completo da concessão encerrada. Estabelece que a descrição original de três gestores não estava mais completa em setembro de 1995.

Essa mudança afeta a questão central do artigo. A Network Solutions não governou um sistema imutável de três contratadas por cinco anos. A dependência do registro deve ser datada independentemente da organização mais ampla da InterNIC. Seus sistemas permaneceram importantes, mas o arranjo circundante de serviços de informação, a hierarquia regional e a supervisão federal evoluíram durante o período da concessão.

A divisão inicial também impede uma fusão enganosa de funções. Um nome não é um endereço. Um ASN não é um domínio. DNS reverso vincula a administração de números ao sistema de nomes sem colapsar os dois. Publicação de diretório não é autoridade de atribuição. Encaminhamento de informações não é uma adjudicação. A coordenação da zona raiz não pode ser usada como um proxy para a experiência de alocação de endereços. Cada função tinha suas próprias evidências, população de solicitantes e possíveis modos de falha.

Antes de ler o contrato, um aviso sobre o contrato

O material contratual disponível é útil, mas não autenticado como um registro federal completo e executado.

Atranscrição privada Cavebearé uma transcrição privada. Oscan de 31 páginas espelhado no Freespeeché um scan espelhado sem uma cadeia de custódia autenticada. Areprodução de arquivo da ICANNé uma reprodução de arquivo, não uma cópia canônica da NSF. Nenhuma é uma cópia canônica da NSF. Essas fontes permitem que cláusulas sejam comparadas e localizadas; não estabelecem que o conjunto acessível contenha o contrato executado completo, todo o material de proposta incorporado, cada anexo, o histórico completo de assinaturas, um conjunto de páginas verificado ou a cadeia completa de emendas.

Esses limites são visíveis na superfície do conjunto remanescente. O contrato reproduzido refere-se à proposta de setembro de 1992 da Network Solutions, um suplemento colaborativo de outubro de 1992 e fórmulas de qualidade na proposta. Esses materiais não estão totalmente disponíveis na reprodução base. As condições gerais aparecem no scan espelhado, enquanto a página da ICANN reproduz principalmente condições especiais e emendas posteriores. A Emenda 4 incorpora outra proposta e anexos por referência. Um leitor de arquivo pode reconstruir termos importantes, mas não autenticar todo o pacote operacional.

Assim, o que se segue é uma leitura de reproduções provisórias. “A reprodução de arquivo afirma” e “o scan espelhado parece fornecer” são ressalvas probatórias, não cautela estilística. Um relato judicial ou governamental posterior pode corroborar um componente, data ou cálculo sem provar que cada página reproduzida é completa e genuína.

O aviso mais óbvio é um conflito de USD 1.000.000 no valor estimado. A reprodução da capa indica um total estimado deUSD 4.219.339. A reprodução do Artigo 8 indicaUSD 5.219.339. O scan espelhado parece decompor o valor do Artigo 8 emUSD 4.854.061 de custo estimado mais uma taxa fixa de USD 365.278, o que aritmeticamente equivale a USD 5.219.339.

A discrepância entre o total da capa e o total do Artigo 8 é exatamenteUSD 1.000.000. A aritmética interna não pode determinar qual valor principal representava a concessão completa executada. Apenas mostra que os componentes do Artigo 8 somam o total do Artigo 8. Umadescrição de 1998 de um tribunal distrital federalrepetiu independentemente o componente de reembolso de USD 4.854.061 e a taxa fixa de USD 365.278. Isso corrobora a aritmética dos componentes; não autentica a cópia completa do contrato, seus anexos ou seu histórico de emendas.

Várias proporções úteis podem ser recalculadas a partir dos números do Artigo 8, desde que sejam identificadas como cálculos e não como taxas contratuais. A taxa fixa de USD 365.278 é aproximadamente7,5252%do custo estimado reproduzido de USD 4.854.061 e aproximadamente6,9985%do total reproduzido de USD 5.219.339 do Artigo 8. A dotação inicial provisória era deUSD 1.162.245até 31 de março de 1994, aproximadamente22,2680%do total do Artigo 8.

Portanto, a reprodução da capa e a reprodução do Artigo 8 devem permanecer lado a lado. Escolher uma silenciosamente criaria falsa precisão. A afirmação defensável é que as fontes conflitam quanto ao total, enquanto os componentes do Artigo 8 são matematicamente coerentes e posteriormente repetidos judicialmente.

O que a concessão provisória tentou controlar

Com essas limitações mantidas, a reprodução de arquivo descreve um instrumento de contratação com prazo determinado, efetivo de 1 de janeiro de 1993 a 30 de setembro de 1998. Ela divide o período em uma fase de implementação de três meses, cinco anos de suporte operacional a partir de 1 de abril de 1993 e um período de flexibilidade de seis meses sem custo adicional.

As provisões de financiamento reproduzidas descrevem reembolso de custos mais uma taxa fixa. Essa estrutura não estabelece desperdício, indiferença ou desempenho fraco. Significa apenas que o pagamento não era baseado exclusivamente em um produto verificado, como uma atribuição concluída com precisão dentro de um período ponta a ponta medido. A disciplina do serviço precisava vir de requisitos, relatórios, supervisão da NSF, decisões anuais de financiamento, revisão de desempenho e a possibilidade de emenda ou substituição.

A Network Solutions aparece na reprodução como principal responsável pela qualidade, pontualidade e gestão eficaz dos serviços de registro. A NSF retinha planejamento de suporte, supervisão, monitoramento e avaliação. O oficial de programa podia revisar o progresso e participar de discussões técnicas ou de cronograma, mas a reprodução limitava a capacidade desse oficial de ordenar trabalho fora do escopo, aumentar o custo estimado, estender o período de desempenho ou alterar termos expressos. Mudanças materiais exigiam o canal de concessões e contratos e ação por escrito.

O mecanismo de financiamento dava à NSF alavancagem recorrente. A dotação inicial cobria o desempenho até 31 de março de 1994, com mais fundos previstos de forma incremental. O texto reproduzido exigia notificação se os custos esperados nos 60 dias seguintes, somados aos custos já incorridos, excedessem 85% do valor alocado. O suporte futuro estava vinculado à revisão anual, a um plano de programa proposto, negociação e fundos disponíveis.

O monitoramento foi projetado como um processo recorrente, e não uma inspeção de final de período. A reprodução de arquivo exige revisões semanais de transição durante a implementação e depois, até que a NSF orientasse de outra forma. Reuniões conjuntas entre gestores eram previstas pelo menos trimestralmente durante o primeiro ano. Relatórios trimestrais deveriam cobrir status técnico, realizações, problemas, colaboração, mudanças nos planos, aprovações pendentes e gastos. As submissões anuais deveriam identificar metas cumpridas, superadas ou não atingidas e explicar desvios significativos do plano.

O requisito reproduzido de relatório final previa um relato do trabalho e dos problemas detalhado o suficiente para que uma organização razoavelmente conhecedora pudesse replicar o trabalho. Também previa a entrega de software e dados, se solicitado. Essa linguagem expressa uma ambição de continuidade, mas a existência de uma cláusula de entrega não é um teste para saber se outro operador poderia assumir um serviço ativo com suas filas, correspondências, conhecimento tácito de políticas e rotinas de equipe intactos.

A Emenda 4 adicionou outro mecanismo de visibilidade. Sua reprodução de arquivo exigia disponibilidade pública, a partir de novembro de 1995, de medidas de desempenho dos serviços de registro, tempos de resposta e desempenho em relação a essas medidas. Também exigia que o relatório de revisão de desempenho fosse disponibilizado para análise pública. Isso indica que as evidências de desempenho público haviam se tornado uma preocupação explícita. Não fornece por si só os números ausentes.

A concessão também separava a coordenação da revisão de solicitantes. A linguagem de colaboração reproduzida permitia que o oficial de programa da NSF resolvesse disputas técnicas, gerenciais ou de cronograma entre os gestores da InterNIC. Isso poderia resolver um desacordo entre a Network Solutions e a AT&T sobre uma transferência, ou outro conflito gerencial dentro do projeto. Não era expresso como uma audiência para um solicitante contestando uma decisão sobre números.

O desenho principal-agente era, portanto, mais substancial do que um subsídio passivo. A NSF retinha dinheiro, relatórios, aprovação, avaliação e ferramentas de coordenação. A Network Solutions ainda controlava os sistemas e a equipe diários pelos quais as solicitações centrais avançavam. A questão importante não é se a supervisão formal existia; ela existia. É se as evidências remanescentes mostram com que prontidão, consistência ou eficácia esses controles protegiam os solicitantes de números. Nesse ponto, o registro público é escasso.

O relógio de três dias que começa após a conclusão

As reproduções do contrato provisório incluem requisitos de prazo distintos para atribuições de números de rede com classes:3 dias úteis para Classe C,5 dias úteis para Classe Be22 dias úteis para Classe A. Esses são requisitos reproduzidos, não resultados de conformidade autenticados ou observações do serviço real.

Seu denominador é crucial. A definição reproduzida inicia o cronômetro no recebimento de umasolicitação completa, incluindo qualquer informação especificamente solicitada sobre topologia de rede e o uso do espaço de endereçamento previamente atribuído. Termina na atribuição de um número.

Isso exclui várias etapas que um solicitante poderia experimentar. O primeiro recebimento está fora do período medido se a submissão não for considerada completa. A rejeição e correção pelo analisador estão fora dele. O tempo de espera pela verificação do solicitante está fora dele. Trocas adicionais sobre topologia, utilização existente ou necessidade projetada podem preceder a conclusão. O atraso na publicação após a atribuição também está fora do cronômetro, assim como as submissões abandonadas antes de chegar à conclusão.

Portanto, uma contratada poderia satisfazer um requisito de três dias úteis para Classe C após a conclusão enquanto o solicitante experimentava um intervalo mais longo desde a primeira submissão até o registro utilizável. Essa possibilidade não é evidência de que ocorreram longos atrasos. O inverso também importa: uma troca prolongada antes da conclusão poderia refletir evidências ausentes ou inadequadas fornecidas pelo solicitante, e não uma falha da contratada.

Uma avaliação séria exigiria pelo menos quatro registros de tempo: primeiro recebimento, primeira resposta do analisador ou da equipe, reconhecimento da conclusão e atribuição ou recusa final. Também precisaria do tipo e tamanho da solicitação, quaisquer evidências adicionais solicitadas, o tempo de resposta do solicitante, pausas para coordenação e o momento em que os dados de registro resultantes se tornaram disponíveis.

A reprodução refere-se a fórmulas de qualidade em uma proposta que não está presente no conjunto acessível do contrato. Sem essas definições, o pesquisador não pode determinar se a qualidade foi amostrada entre nomes, números, ASNs e atualizações de registros; se uma média, mediana, percentil ou limite foi usado; ou como as submissões rejeitadas, corrigidas, expiradas e abandonadas foram tratadas.

Os números de três, cinco e 22 dias permanecem valiosos. Eles mostram que a contratação tentou tornar o prazo de processamento de números uma obrigação especificada. Não revelam quantas solicitações entraram em cada classe, quantas satisfizeram o padrão ou se o cronômetro foi aplicado de forma consistente.

Maio de 1994: escala em unidades que não devem ser misturadas

A evidência contemporânea mais forte da carga de trabalho vem de uma seção submetida pela contratada doRelatório Mensal da Internet de maio de 1994. Ele registra vários tipos diferentes de atividade:

• 5.009 e-mails de hostmaster
• 251 solicitações postais ou por fax
• 2.047 chamadas telefônicas
• 1.316 domínios registrados
• 565 entradas de endereço inverso
• 12.645 unidades de número de rede Classe C atribuídas
• 20 unidades de número de rede Classe B atribuídas
• 57 ASNs atribuídos

Nenhuma dessas unidades pode ser somada para produzir um total significativo chamado “solicitações”. Um e-mail pode ser uma candidatura, correção, consulta de status ou questão de política. Uma chamada telefônica pode referir-se a qualquer uma de várias funções. Uma entrada de endereço inverso não é uma nova alocação. Um registro de domínio não é uma atribuição de ASN.

Mais importante, as 12.645 unidades de Classe C não representam 12.645 solicitantes. O relatório diz separadamente que blocos de 256 redes Classe C foram atribuídos a várias organizações e ao DDN NIC. Uma única candidatura ou ação de alocação poderia, portanto, ser responsável por muitas das unidades relatadas. O número demonstra a escala de unidades de endereço registradas no mês, não o número de solicitantes únicos ou adjudicações.

O mesmo relatório lista o uso do serviço de informação em maio sem resolver o denominador de registro. Ele fornece211.257 consultas de cliente WHOISe785.015 consultas de servidor WHOIS. Relata separadamente48.859 conexões Gopher,24.748 conexões WAIS,8.779 conexões FTPe1.387 conexões Mailserv. Consultas, conexões, candidaturas, atribuições e contatos telefônicos permanecem distintos.

Esses números fazem um forte argumento de eficiência para uma infraestrutura comum. Um escritório puramente manual teria enfrentado pressão crescente de correspondências, chamadas, atualizações de banco de dados, consultas e vários tipos de identificadores. Formulários padronizados permitiam que verificações repetitivas fossem mecanizadas. A análise podia manter campos malformados fora da fila da equipe. Mensagens de erro podiam informar a um solicitante o que o sistema rejeitou. A verificação podia capturar um mal-entendido da máquina antes que se tornasse um registro público.

O status do ticket podia reduzir a incerteza e evitar alguns contatos de suporte.

O relatório mensal demonstra atividade em escala. Não fornece uma taxa de conclusão para solicitações de números, uma taxa de rejeição do analisador, uma taxa de abandono, uma distribuição de prazos ou uma amostra independente de precisão. Não revela se um solicitante gerou muitos e-mails ou se uma chamada dizia respeito a vários registros. É evidência operacional, não uma auditoria de equidade.

O que o relato da contratada de 1996 acrescenta

Uma transcrição hospedada privadamente doRelatório Anual de Progresso dos Serviços de Registro da InterNIC de 1996fornece alegações de desempenho posteriores. Sua procedência é mais fraca do que um relatório autenticado da contratada, e suas estatísticas permanecem autorrelatadas. Ainda assim, é mais informativo do que substituir o período apenas por perguntas hipotéticas.

A transcrição diz que, em31 de dezembro de 1996, 95% das novas solicitações de registro estavam sendo processadas em 24 horas. Não fornece numerador, população por tipo de solicitação ou regra de medição. “Novas solicitações de registro” não é dividido em domínios, trabalho com números IP, ASNs, contatos ou outros modelos. A alegação não pode ser relatada como uma taxa de conclusão de 95% para números IP.

Uma passagem separada diz respeito especificamente a domínios. Diz quemais de 85.000 domíniosforam registrados emnovembro de 1996e quemais de 90% dessas solicitaçõesforam processadas automaticamente pelo analisador em 24 horas. Essa afirmação somente sobre domínios não pode ser combinada com a alegação de 95% no final do ano. É evidência de automação substancial de domínios em um mês, não uma medida de prazo de alocação de endereços ou equidade.

A mesma transcrição registra evidências de suporte geral menos lisonjeiras. Durante1996, as taxas de abandono de chamadas autorrelatadas variaram demenos de 8% a mais de 50%. As taxas eram tipicamente de10% a 20% na última parte do ano. A espera média dos clientes era de cerca dequatro minutos, e o tempo médio para retornar solicitações de correio de voz não foi medido. O relato também diz que problemas de tronco telefônico identificados em dezembro fizeram com que muitos chamadores recebessem sinais de ocupado.

Esses números oferecem uma visão limitada da tensão do serviço. Não fornecem o número subjacente de chamadas, a distribuição por mês ou dia, a duração das chamadas ou a parcela atribuível a solicitantes de números. Um chamador buscando uma alocação de IP não pode ser separado de alguém perguntando sobre um domínio, cobrança ou registro de contato. As evidências apoiam uma conclusão geral de que o suporte telefônico experimentou pressão substancial e variável em 1996. Não podem ser convertidas em uma taxa de danos na alocação de números.

A transcrição anual também ilustra por que os totais de atividade são um proxy instável para a qualidade do serviço. A automação podia processar uma alta parcela de domínios rapidamente enquanto os chamadores enfrentavam acesso variável à ajuda. Uma alegação de processamento em um dia podia coexistir com atrasos de sete dias em e-mails de cobrança ou manuseio mais longo para modelos manuais selecionados. Funções diferentes tinham filas diferentes, e uma taxa de sucesso agregada podia ocultar a população mais dependente do julgamento da equipe.

Para o trabalho com números, o denominador necessário ainda está ausente. Nenhuma taxa de conclusão reproduzível pode ser calculada sem a contagem de candidaturas concluídas, solicitantes únicos, modelos rejeitados, solicitações corrigidas, expirações, abandonos, recusas substantivas e resultados de conformidade específicos por classe ou prefixo. Nenhuma distribuição de tempo decorrido conecta o primeiro recebimento, conclusão, atribuição e publicação. As fontes também não fornecem duração verificada de interrupções ou taxa de reclamações específica de números.

As evidências remanescentes apoiam, assim, duas proposições ao mesmo tempo. A Network Solutions construiu e operou automação capaz de lidar com um volume substancial relatado. O registro público não permite uma estimativa confiável de com que frequência os solicitantes de números experimentaram atraso, correção, recusa ou revisão bem-sucedida.

Onde a concentração realmente se situava

A cadeia central pode ser analisada sem chamar cada requisito administrativo de dano.

Na entrada, a Network Solutions controlava o endereço eletrônico publicado, o modelo aceito e o analisador. Um formulário malformado ou obsoleto não podia avançar pelo caminho automatizado até ser corrigido. Canais manuais permaneciam, mas a mesma contratada de registro operava, em última análise, o serviço central não DDN.

Na verificação, o solicitante precisava confirmar que a máquina havia interpretado a submissão corretamente. Isso era uma proteção contra erros silenciosos. Também colocava a conclusão do ciclo no solicitante em sete dias. A incidência de expiração é desconhecida, então a regra demonstra dependência e uma possível consequência de reenvio, em vez de um fardo medido em uma população.

A completude era o próximo limite. Uma solicitação de número podia exigir informações de topologia e uso prévio. Essas evidências não eram ornamento burocrático: a conservação de endereços e a agregação de rotas exigiam que os registros avaliassem a necessidade operacional. A questão de governança é que a determinação de completude pela contratada controlava quando o cronômetro de prazo reproduzido começava. Sem registros de solicitação com carimbo de tempo, é impossível dizer se essa discricionariedade foi exercida prontamente ou de forma inconsistente.

Seguia-se o processamento substantivo. A equipe da Network Solutions cuidava do trabalho central de números de rede e ASNs não DDN dentro da delegação e estrutura técnica aplicáveis. Isso era mais consequencial do que direcionar um usuário a um documento. O processamento pela equipe contribuía para se um identificador solicitado seria atribuído, em que quantidade e após quais informações de suporte.

Após a atribuição, vinham o registro e a publicação. A reprodução provisória define disponibilidade como o fornecimento de dados de registro ao beneficiário do diretório e banco de dados. A Network Solutions iniciava a transferência; a AT&T ocupava a camada de publicação e acesso no lançamento. Uma atribuição e seu registro público estavam conectados, mas eram institucionalmente distintos.

Essa distinção cria um possível limite de falha. Um atraso podia surgir no processamento, transmissão, publicação ou correção. No entanto, nenhuma série de reconciliação recuperada mostra com que frequência os registros diferiam, com que rapidez os problemas de transferência eram resolvidos ou se os usuários podiam identificar o gestor responsável. As disposições de coordenação entre gestores do contrato reconhecem a necessidade de governar essas emendas, mas não medem falhas.

A revisão formava a etapa final. O procedimento administrativo público inicial era explícito sobre correção pelo analisador, contato com o hostmaster e status do ticket. Era muito menos explícito sobre a revisão independente de decisões substantivas sobre números. O silêncio na RFC 1400 não pode provar que reconsideração pela equipe, contato com a IANA ou escalada informal nunca ocorreram. Significa que o documento não fornece um procedimento de apelação voltado ao solicitante que possa ser avaliado.

A constatação demonstrada é, portanto,dependência concentrada de entrada e processamento central. A Network Solutions ocupava etapas consecutivas na rota central não DDN: entrada, análise, correção, completude, processamento pela equipe, atribuição e atualização de registro. As evidências não identificam uma classe precisa de solicitantes para a qual o serviço DDN, RIPE NCC, APNIC, um registro local, espaço atribuído por provedor ou escalada ao registro pai estivesse comprovadamente indisponível. Também não fornecem um dano operacional documentado causado por essa ausência de escolha.

Isso é mais restrito do que um ponto de estrangulamento universal, mas permanece institucionalmente significativo. Concentrar etapas consecutivas pode tornar a automação coerente e os registros consistentes. Também pode fazer a qualidade do caminho central depender fortemente dos sistemas, pessoal, definições e transferências de um operador. O registro histórico apoia a análise dessa dependência sem presumir abuso.

A geografia e a classe do solicitante mudavam a rota

O serviço central nunca teve uma relação uniforme com todos os solicitantes da Internet ao longo de 1993–1998.

A Europa já oferecia o contraexemplo mais claro. Aprópria história do RIPE NCCdistingue seu estabelecimento formal emabril de 1992da distribuição de endereços, que não era uma atividade inicial, mas foi adicionada posteriormente em1992. Na transição da InterNIC, a administração de números europeia já havia começado a se mover por meio de uma estrutura regional.

ARFC 1466, publicada em maio de 1993, descrevia o Internet Registry como o registro padrão onde não existia autoridade de registro delegada. Argumentava a favor da distribuição do registro porque registros geograficamente mais próximos podiam atender melhor às comunidades, idiomas e costumes locais. Observava que o RIPE NCC já havia recebido um bloco de espaço Classe C para alocação europeia.

A RFC 1466 não descrevia rotas comerciais intercambiáveis. Dizia que um solicitante de rede podia contatar o Internet Registry central diretamente e poderia, dependendo das circunstâncias, ser encaminhado a um registro regional. O registro central deveria estar preparado para atender um assinante quando necessário. No nível regional, o documento favorecia um único registro reconhecido para cada área geográfica. A distribuição reduzia a dependência central, mas podia criar uma dependência regional não intercambiável.

O caminho da Ásia-Pacífico surgiu em um cronograma diferente. Ahistória institucional da APNICdiz que seu piloto foi planejado para começar emsetembro de 1993e continuou até junho de 1994. A IANA reconheceu publicamente a APNIC emabril de 1994, delegando os intervalos IPv4202/8 e 203/8. A rota disponível para um solicitante da Ásia-Pacífico dependia, portanto, da data, geografia, maturidade do piloto e delegação aplicável.

NaRFC 2050, em novembro de 1996, o mapa publicado da administração de números era explicitamente hierárquico: IANA, registros regionais e registros locais. Identificava a InterNIC com a América do Norte, o RIPE NCC com a Europa e a APNIC com a região da Ásia-Pacífico. Registros locais operavam abaixo do nível regional.

Os relacionamentos com provedores criavam outra rota. A RFC 2050 aconselhava muitos ISPs a obter espaço de endereçamento de um provedor upstream em apoio ao roteamento hierárquico e agregação. Certos provedores multihomed ou conectados a pontos de troca podiam solicitar diretamente a um registro regional. Solicitantes em áreas sem um registro regional designado podiam contatar um registro regional, que poderia tratar ou encaminhar a solicitação.

O espaço atribuído por provedor não era equivalente a um registro central concorrente. Podia trazer implicações de renumeração se o cliente mudasse de provedor de conectividade. O espaço de registro direto também não garantia roteabilidade global. A escolha dependia das circunstâncias operacionais, não apenas da preferência.

A rota DDN permaneceu separada para sua população elegível durante a transição de 1993. Um usuário militar era instruído a continuar com o DDN NIC. Essa rota é evidência contra um único serviço abrangendo todos os solicitantes, mas não era uma alternativa geral aberta a todas as organizações não militares.

Em 1996, a descrição mais precisa não era de que a Network Solutions servia como o único portal global de números. A InterNIC era um registro regional dentro de uma hierarquia que também incluía RIPE NCC, APNIC, registros locais e atribuições baseadas em provedor. Anteriormente, o registro central permanecia o padrão para áreas sem um delegado e retinha funções importantes de coordenação.

A regionalização reduziu a população exposta ao processo central de solicitação. Não criou um mercado em que cada solicitante pudesse trocar de registro após um serviço ruim. Um operador europeu não podia necessariamente escolher o registro da América do Norte como substituto; um cliente de provedor podia ter que aceitar espaço upstream; uma solicitação grande ou excepcional podia exigir coordenação de nível superior. As alternativas eram específicas à data e à população, e sua não intercambialidade é central para entender tanto a resiliência quanto a dependência.

Quatro recursos que não devem ser confundidos

O registro contém quatro tipos diferentes de correção ou revisão. Tratá-los como um só exageraria a proteção ao solicitante.

A primeira via era a correção operacional. A RFC 1400 documentava mensagens de erro do analisador, formulários de verificação corrigidos, reenvio, status do ticket e contato com a equipe do hostmaster. Esses mecanismos abordavam entradas malformadas, formulários obsoletos, interpretação do analisador e status da solicitação. A equipe também podia ter reconsiderado uma submissão informalmente. O documento não revela a frequência, duração ou resultado dessas interações.

A segunda via dizia respeito a disputas entre os gestores da InterNIC. A reprodução de arquivo do contrato afirma que o oficial de programa da NSF podia resolver disputas técnicas, gerenciais ou de cronograma entre os colaboradores. Isso apoiava a coordenação dentro do serviço contratado. Não era uma apelação do solicitante contra uma decisão sobre números.

A terceira via dizia respeito a desacordos entre a beneficiária e a NSF. As condições gerais espelhadas parecem dispor que disputas de fato não resolvidas informalmente receberiam uma decisão por escrito de um oficial de concessões da NSF, podendo a beneficiária solicitar revisão dentro de30 diasapós receber essa decisão. Como as condições gerais incorporadas completas e sua procedência não foram autenticadas no conjunto acessível da concessão executada, isso permanece como evidência contratual provisória. De qualquer forma, era um processo da parte contratante disponível para a beneficiária, não um recurso concedido a um solicitante de rede.

A quarta via era a hierarquia de registro voltada ao solicitante, declarada na RFC 2050. Uma organização insatisfeita com o desempenho do registro atribuidor podia apelar ao registro pai. O registro atribuidor deveria disponibilizar a documentação relevante. Apelações posteriores podiam ir para o pai do pai e, depois de esgotadas outras vias, em última instância para a IANA. Esperava-se que cada registro documentasse seu procedimento de apelação.

A RFC 2050 melhorou a arquitetura de revisão publicada. Separou o registro atribuidor de um revisor de nível superior e aplicava-se especificamente a decisões sobre endereços. Era uma Melhor Prática Atual escrita por representantes associados à InterNIC, APNIC, RIPE NCC e IANA, não uma auditoria de como as apelações funcionavam na prática.

Nenhum dos materiais remanescentes fornece uma série de apelações específica de números. Não há contagem recuperada de contestações, duração média, taxa de reversão, distribuição de resultados ou evidência de que solicitantes em situação semelhante receberam revisão consistente. A ausência de tal série não mostra que as apelações não foram usadas ou foram ineficazes; impede uma conclusão medida em qualquer sentido.

O mapa de recursos, portanto, muda com o tempo e por ator. Em 1993, os solicitantes podiam corrigir formulários e contatar a equipe, enquanto a NSF gerenciava suas contratadas. As condições gerais provisórias forneciam uma via de revisão contratual para a beneficiária. Em novembro de 1996, o sistema de registro de números publicado articulava uma rota voltada ao solicitante através dos registros pais até a IANA. Cada uma abordava uma disputa diferente.

Evidências de desempenho e continuidade no final da cadeia

Uma alegação forte de dano sistemático aos solicitantes de números exigiria vários conjuntos de dados que não foram recuperados juntos.

As contagens de solicitações teriam que identificar candidaturas de números concluídas e solicitantes únicos, em vez de unidades de endereço, mensagens ou chamadas. Registros de prazo precisariam de carimbos de tempo ponta a ponta, não apenas o intervalo após a conclusão. Dados de correção precisariam de modelos rejeitados, formulários corrigidos, solicitações expiradas e submissões abandonadas. Dados de decisão precisariam de recusas substantivas, reduções e resultados específicos por classe ou prefixo.

A confiabilidade exigiria interrupções de serviço verificadas e suas durações. A responsabilização exigiria contagens de reclamações, taxas de escalada, reversões e tempos de resolução. A portabilidade exigiria evidências mostrando com que rapidez outro operador poderia assumir o serviço, incluindo software, dados, filas pendentes, correspondências, histórico de políticas e conhecimento da equipe.

O contrato reproduzido previa relatórios capazes de abordar algumas dessas questões. A Emenda 4 exigia medidas de desempenho público. A transcrição de 1996 refere-se a dados de desempenho e processamento, enquanto a apresentação pública remanescente está incompleta para análise específica de números. A existência de um sistema de relatórios pretendido não é o mesmo que a posse de sua série completa.

Oparecer jurídico do GAO de 2016fornece evidências retrospectivas limitadas sobre a transição posterior. Diz que, quando a administração se moveu para o Departamento de Comércio em 1998, uma disposição adicional exigia que a Network Solutions entregasse cópias de software, dados e documentação gerados sob o contrato até outubro. O GAO relatou a entrega de arquivos de banco de dados emdez cartuchos de 8 milímetros, um fichário listando os bancos de dados e vários fichários adicionais contendo dados e documentação de software.

Essa evidência demonstra uma obrigação de transição e entrega física. Não estabelece que os materiais fossem completos o suficiente para operar o serviço, que capturavam o estado ativo da fila ou correspondências históricas, ou que um sucessor realizou uma transferência testada a partir deles. A substituibilidade operacional permanece uma inferência a ser examinada, não uma falha demonstrada.

A investigação do GAO era principalmente sobre propriedade governamental e a transição posterior da IANA. Seu relato está fortemente preocupado com questões de nomes de domínio e zona raiz e não fornece denominador de solicitação de números. Não pode preencher o registro ausente de candidaturas de endereço, atrasos ou apelações.

Taxas de domínio posteriores, litígios de marcas registradas, competição entre registradores e disputas sobre propriedade da zona raiz são igualmente limitados. Podem iluminar a história da mesma empresa ou concessão, mas não provam que solicitantes de números foram recusados, atrasados ou tiveram um recurso negado. Evidências específicas de função permanecem necessárias.

As métricas ausentes estão concentradas nos pontos onde a tese do artigo se tornaria causal de outra forma. Não há taxa de conclusão de solicitação de números reproduzível, duração de interrupção verificada, taxa de reclamação específica de números, taxa de escalada, taxa de reversão ou tempo de troca. As evidências mostram uma dependência administrativa e observabilidade incompleta, não uma perda de bem-estar estimada.

Contrafactual: um gestor para todos os três serviços

Considere uma alternativa construída pelo analista na qual a NSF concedeu registro, acesso a diretório e banco de dados e serviços de informação a um único provedor integrado. Este é um contrafactual para testar a estrutura da contratação, não uma alegação de que tal modelo era historicamente viável ou preferível em 1993.

A integração poderia reduzir custos de coordenação. Os dados de registro poderiam ir da entrada à publicação dentro de uma organização. Uma única equipe de operações poderia rastrear uma falha através da análise, processamento pela equipe, disponibilidade de banco de dados, consulta pública e suporte geral. Os usuários não teriam que identificar se a Network Solutions ou a AT&T era responsável por um problema na transferência.

O investimento em automação também poderia se tornar mais coerente. Um único sistema de identidade e tickets poderia conectar solicitantes, organizações, domínios, números, ASNs, contatos, registros de publicação e histórico de suporte. Mudanças nos formatos de dados não exigiriam acordo entre concessões. A equipe de informações gerais poderia ver o estado de um registro sem um encaminhamento separado.

O risco é uma contenção de falhas mais ampla. O mesmo provedor receberia solicitações, processaria atribuições, publicaria registros, responderia perguntas e relataria seu próprio desempenho. Uma interrupção do sistema ou uma transição organizacional fracassada poderia afetar a entrada, o processamento autoritativo, a publicação e a orientação de uma só vez.

O monitoramento também se tornaria menos modular. Organizações separadas criavam limites onde a NSF podia comparar relatos de entrega e testar se os dados passavam do registro para a publicação. A separação não tornava nenhum gestor independente do financiamento federal nem garantia relatórios verdadeiros, mas um provedor totalmente integrado eliminaria até mesmo esse contraste organizacional.

A substituição envolveria um pacote maior de sistemas e conhecimentos. Trocar o serviço de registro já exigia continuidade de software, dados, filas e políticas. Substituir uma InterNIC integrada acrescentaria infraestrutura de diretório, ferramentas de acesso público, arquivos, serviços de informação e uma operação de suporte mais ampla.

O contrafactual fortalece o argumento de eficiência para a divisão da NSF. Concessões separadas limitavam a amplitude do papel formal de qualquer provedor e permitiam operações especializadas. Também esclarece por que a concentração permaneceu dentro do componente de registro: a divisão separava serviços distintos em vez de criar substitutos para o mesmo ato autoritativo.

Contrafactual: vários provedores de registro substituíveis

Uma segunda alternativa construída pelo analista permitiria que vários provedores de registro atendessem a mesma população de solicitantes, compartilhando um livro-razão autoritativo e uma função central de resolução de conflitos.

Cada provedor poderia aceitar uma solicitação padrão, verificar a formatação, reunir informações de suporte e submeter uma transação aprovada a um serviço central. Os solicitantes poderiam migrar para outro provedor quando o suporte estivesse inacessível. Uma interrupção de um provedor não necessariamente paralisaria todos os canais de entrada. A NSF poderia comparar prazos, taxas de correção e experiência do solicitante entre os provedores.

O núcleo autoritativo ainda precisaria de serialização estrita. Dois provedores não poderiam atribuir o mesmo bloco de números. Um sistema compartilhado teria que gerenciar espaço disponível, reservas pendentes, atribuições concluídas, exceções e reversões sem estados conflitantes. A replicação atrasada poderia ser operacionalmente perigosa.

A consistência representaria um segundo desafio. Os provedores poderiam interpretar requisitos de topologia, utilização e agregação de forma diferente. Os solicitantes poderiam buscar a decisão mais permissiva. Política comum, evidências padronizadas, registros de transações e um revisor vinculante seriam necessários. A distribuição da entrada, portanto, moveria, em vez de eliminar, a autoridade central.

O investimento em automação poderia se fragmentar. Vários provedores poderiam duplicar analisadores, sistemas de status e infraestrutura de suporte, ou depender da NSF para construir uma plataforma comum. Interoperabilidade, segurança, responsabilidade, formatos de auditoria, regras de reserva e procedimentos de migração precisariam ser definidos antes que a experiência operacional tornasse os requisitos óbvios.

O monitoramento poderia melhorar se os provedores gerasse registros comparáveis, mas apenas se o principal controlasse as regras de medição. Um provedor poderia iniciar seu cronômetro no primeiro recebimento, enquanto outro começaria na conclusão. Um poderia contar reenvios como novas solicitações. Sem denominadores padrão, a concorrência aparente poderia produzir alegações de desempenho incomparáveis.

A revisão do solicitante também exigiria desenho institucional. Uma escolha de atendimento ao cliente não substitui uma apelação quando o serviço central de políticas rejeita uma atribuição. Uma troca de provedor poderia ajudar com explicação ou preparação de formulários, enquanto a decisão autoritativa permaneceria inalterada. O revisor compartilhado precisaria de documentação, prazos e autoridade sobre cada provedor.

A contenção de falhas seria melhor na camada de entrada, mas incerta no livro-razão. Várias portas de entrada poderiam sobreviver a uma interrupção de um provedor. Um serviço central de reserva ou unicidade com falha poderia parar todas elas. A arquitetura distribuiria algum risco operacional enquanto preservava um núcleo não competitivo.

A viabilidade histórica não pode ser presumida. As restrições de roteamento do início dos anos 1990, a escassez de espaço de endereçamento, a padronização incompleta de políticas e o custo da coordenação em tempo real podem ter favorecido um proprietário claro para cada domínio de decisão. A delegação regional abordou a escala por meio de hierarquia geográfica, em vez de provedores concorrentes compartilhando um pool.

Esta alternativa, no entanto, expõe questões de design úteis. A entrada poderia ser substituível sem fragmentar o livro-razão? Os solicitantes poderiam trocar de provedor de suporte enquanto as decisões permanecessem consistentes? Registros comparáveis poderiam tornar a revisão de desempenho mais credível? O revisor central poderia ser separado do processamento de linha de frente? As evidências remanescentes da InterNIC não testam essas possibilidades, então nenhuma estimativa de bem-estar, atraso ou custo de troca se segue.

A conclusão proporcional

O design da InterNIC da NSF de 1993 combinava especialização com uma identidade pública comum. A Network Solutions cuidava do registro central não DDN; a AT&T cuidava do acesso a diretório e banco de dados; a General Atomics/CERFnet cuidava de informação e referência. A NSF retinha financiamento, monitoramento, aprovações, avaliação e coordenação entre gestores. A USC/ISI continuava a coordenação da IANA, e o DDN NIC retinha a rota militar.

O sistema de registro oferecia administração útil. Formulários estruturados, análise automática, erros explícitos, confirmação do solicitante, status de ticket, infraestrutura comum e processamento final humano eram respostas plausíveis ao volume rapidamente crescente. Os totais operacionais de maio de 1994 e a alegação posterior de automação de domínios mostram atividade substancial, embora não sejam prova independente da qualidade do serviço de números.

Dentro da instituição dividida, a Network Solutions controlava etapas consecutivas do caminho central de registro. Essa concentração tornava uma solicitação dependente do canal aceito, analisador, ciclo de correção, determinação de completude, processamento pela equipe e atualização de registro de uma única contratada. É adequadamente descrito como dependência concentrada de entrada e processamento central.

O sistema circundante mudou. O RIPE NCC distribuía endereços na Europa, a APNIC surgiu na Ásia-Pacífico, registros locais e provedores atendiam populações adicionais, os usuários DDN mantinham outro canal, e a RFC 2050 colocava a InterNIC dentro de uma hierarquia regional com uma rota de apelação ao registro pai. Essas alternativas eram específicas ao tempo, geografia e classe de solicitante, em vez de escolhas intercambiáveis.

As evidências de supervisão e recurso são incompletas, mas não ausentes. A NSF tinha ferramentas contratuais; os solicitantes tinham correção e contato com a equipe; as condições gerais provisórias descreviam uma revisão beneficiária–NSF; e a RFC 2050 posteriormente articulou a apelação do solicitante através de registros pais à IANA. O que está faltando é a série de resultados necessária para julgar esses mecanismos em casos de números.

O “preço” do título é, portanto, uma questão investigativa, em vez de uma perda quantificada. A administração central proporcionou escala e consistência, ao mesmo tempo em que colocava várias etapas de uma cadeia definida em uma única contratada. O registro remanescente não prova que essa dependência era universalmente inevitável, sistematicamente abusada ou responsável por danos mensuráveis aos solicitantes de números.