O contrato InterNIC e o preço de um ponto de passagem administrativo único

Resumo

• Em abril de 1993, a NSF lançou a InterNIC, com a Network Solutions gerenciando o registro central não DDN de domínios, números de rede e ASNs, recebimento, processamento e atualizações; a AT&T cuidando do acesso a diretórios e bancos de dados; e a General Atomics/CERFnet fornecendo informação e orientação. Reproduções do acordo provisório também estabeleciam prazos de 3, 5 e 22 dias úteis para atribuições de classes C, B e A uma vez que a solicitação estivesse completa, mas as evidências disponíveis não medem a conformidade.
• O processo de solicitação documentado da Network Solutions utilizava 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 críveis em escala, consistência e visibilidade das correções.
• As cópias do acordo disponíveis são reproduções não autenticadas, os relatórios de desempenho carecem de denominadores decisivos sobre o número de solicitações, e os caminhos documentados de correção, gestão intergestores, recurso para as partes contratantes e apelação de registro não fornecem nenhuma série recuperada sobre frequência, duração, cancelamentos ou resultados.
• O dossiê estabelece uma dependência do recebimento e processamento centrais para os trabalhos de registro não DDN definidos, mas não uma inevitabilidade universal, exclusão sistemática, dano quantificado para os solicitantes, nem a prova de que os caminhos regionais, militares, de registros locais e de provedores estavam indisponíveis para uma população específica afetada.

1º de abril de 1993: uma solicitação utiliza o novo canal

Uma solicitação de registro não militar que se aproximava do serviço central da Internet em 1º de abril de 1993 seguia um percurso deliberadamente estruturado. A mudança era visível primeiro em instruções banais: qual caixa de correio usar, qual formulário preencher, para onde telefonar e o que aconteceria se o formulário falhasse em uma verificação automática.

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 contratada que assumia o registro. O documento é, portanto, um relato em primeira mão da transição planejada e do processo de solicitação, e não uma revisão independente de desempenho. No entanto, é incomumente preciso sobre a sequência administrativa.

Durante a transição até 31 de março, os usuários não DDN podiam enviar os modelos existentes do Centro de Informação de Rede DDN para o antigo endereço NIC DDN ou para o novo endereço hostmaster InterNIC. As submissões por e-mail, fax e correio físico recebidas em qualquer um dos locais deveriam ser processadas. Os usuários DDN permaneciam em uma via militar separada e deveriam continuar enviando suas solicitações de registro ao NIC DDN. A transição dividia as populações de serviços; não fechava 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 de registro automatizado da Network Solutions utilizando o novo modelo. Um modelo obsoleto que chegasse seria devolvido com erros de análise e o formulário de substituição anexado. A caixa de correio hostmaster continuaria a aceitar 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 processamento automatizado e despojado de referências específicas ao DDN. Uma vez enviado, um servidor de e-mail analisava o modelo e realizava uma verificação rápida das informações que podiam ser verificadas. A RFC 1400 usava um conflito de nome de domínio como exemplo. O sistema então retornava um formulário de verificação ou uma rejeição acompanhada de mensagens de erro.

Uma verificação não era o resultado final. O solicitante deveria examinar a interpretação da máquina. Se as informações analisadas estivessem corretas, o solicitante reenviava 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 deveria ser ajustada e submetida novamente pelo sistema automatizado. Os dados de verificação corrigidos eram verificados novamente e outro formulário de verificação era emitido.

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

Essa sequência combinava o trabalho da máquina e do humano. O analisador gerenciava o recebimento, as verificações de formato, a verificação selecionada e um loop de confirmação. A equipe de registro mantinha a etapa de processamento final. A RFC 1400 não revela o processo decisório interno completo para uma solicitação de número de rede. Não mostra como a equipe avaliava um plano de topologia específico, como considerações técnicas concorrentes eram resolvidas, nem qual explicação acompanhava uma redução ou recusa substancial. Seu exemplo de ticket de domínio também não estabelece o tratamento do trabalho sobre números IP ou ASNs.

O solicitante tinha sete dias para reenviar o formulário de verificação. Se nenhuma verificação chegasse dentro desse prazo, a solicitação inicial expirava e deveria ser submetida novamente. A regra de expiração identifica uma consequência processual, mas o documento não fornece nenhuma taxa de incidência. Não mostra quantas solicitações expiravam, se mensagens eram perdidas, quantas vezes um erro do analisador exigia outro ciclo, nem se o reenvio produzia um atraso significativo. A conformidade do formulário era uma condição para 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 dificuldade. Um usuário podia consultar o estado da solicitação com o utilitáriofingerou conectando-se interativamente ao host de registro. O exemplo mostrava se um ticket estava pendente, como chegou, quando foi aberto e qual conta interna era responsável. 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.

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

A descrição revela a concentração exata que importa. No serviço central não DDN, a Network Solutions operava a entrada eletrônica aceita, os modelos, o analisador, o loop de rejeição e correção, a etapa de processamento pela equipe, o sistema de estado de tickets e o sistema de registro. Isso é evidência de uma dependência administrativa consecutiva. Ainda não é evidência de que todo solicitante no mundo devia usar esse caminho, de que uma classe particular carecia de alternativas, ou de que a contratada exercia sua posição para causar dano.

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 adquiriu por meio de organizações distintas. Oanúncio de 1º de abril de 1993 dos serviços InterNIC operacionaisdescrevia um design de lançamento distribuído 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 destinava-se a mascarar as costuras desnecessárias sem apagar a distribuição subjacente de responsabilidades.

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

A AT&T recebeu os 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 ligada ao registro porque os dados concluídos precisavam se tornar acessíveis aos usuários, mas a AT&T não se tornou, por isso, um segundo caminho 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 orientação. Sua função era o aconselhamento: responder a perguntas sobre uso e conexão à Internet, manter recursos de informação e orientar usuários para os serviços ou organizações de assistência apropriados. Um escritório de referência podia ajudar um solicitante a encontrar o caminho de registro; não podia substituir o ator autorizado a processar uma atribuição.

Outras instituições permaneciam fora desse trio de contratados. A NSF detinha as subvenções, fornecia o financiamento, monitorava o desempenho, aprovava ações especificadas, avaliava o progresso e coordenava disputas entre os gestores. O Information Sciences Institute da USC continuou a função de coordenação da IANA, incluindo a responsabilidade acima ou ao lado dos registros e o poder de delegar partes da administração de números. O NIC DDN mantinha seu caminho para usuários militares. Os arranjos regionais e locais já começavam a modificar o registro que servia a uma população particular.

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

Essa mudança afeta a questão central do artigo. A Network Solutions não governou um sistema de três contratados inalterado por cinco anos. A dependência do registro deve ser datada independentemente da organização InterNIC mais ampla. Seus sistemas permaneceram importantes, mas o arranjo dos serviços de informação circundantes, a hierarquia regional e a supervisão federal evoluíram durante o período de subvençã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. O DNS reverso liga a administração de números ao sistema de nomes sem fundir os dois. A publicação de diretório não é autoridade de atribuição. A orientação de informação não é uma adjudicação. A coordenação da zona raiz não pode ser usada como indicador da experiência em alocação de endereços. Cada função tinha suas próprias evidências, sua população de solicitantes e seus modos possíveis de falha.

Antes de ler o contrato, um aviso sobre o contrato

O material do acordo disponível é útil, mas não é autenticado como um dossiê federal executado completo.

Atranscrição privada Cavebearé uma transcrição privada. Oscan de 31 páginas hospedado pela Freespeeché um scan hospedado em um espelho sem cadeia de rastreabilidade 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 comparar e localizar cláusulas; não estabelecem que o conjunto acessível contém o acordo 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.

Essas limitações são visíveis no conjunto preservado. O acordo reproduzido faz referência à proposta da Network Solutions de setembro de 1992, um suplemento colaborativo de outubro de 1992 e fórmulas de qualidade na proposta. Esses documentos não estão totalmente disponíveis na reprodução base. Os termos gerais aparecem no scan hospedado em espelho, enquanto a página da ICANN reproduz principalmente os termos especiais e as emendas posteriores. A emenda 4 incorpora outra proposta e anexos por referência. Um leitor de arquivos pode reconstituir termos importantes, mas não autenticar todo o dossiê operacional.

Consequentemente, o que se segue é uma leitura de reproduções provisórias. "A reprodução de arquivo indica" e "o scan hospedado em espelho parece fornecer" são ressalvas probatórias, não cautela estilística. Um relato judicial ou governamental posterior pode corroborar um item, uma data ou um cálculo sem provar que cada página reproduzida é completa e autêntica.

O aviso mais óbvio é um conflito de 1.000.000 USD no valor estimado. A reprodução da capa indica um total estimado de4.219.339 USD. A reprodução do artigo 8 indica5.219.339 USD. O scan hospedado em espelho parece decompor o valor do artigo 8 em4.854.061 USD de custo estimado mais honorários fixos de 365.278 USD, o que aritmeticamente dá 5.219.339 USD.

A diferença entre o total da capa e o do artigo 8 é exatamente de1.000.000 USD. A aritmética interna não pode determinar qual valor global representava a atribuição executada completa. Apenas mostra que os componentes do artigo 8 somam o total do artigo 8. Umadescrição de um tribunal distrital federal de 1998repetiu independentemente o componente de reembolso de 4.854.061 USD e os honorários fixos de 365.278 USD. Isso corrobora a aritmética dos componentes; não autentica a cópia completa do acordo, seus anexos ou seu histórico de emendas.

Vários índices úteis podem ser recalculados a partir dos números do artigo 8, desde que identificados como cálculos e não como taxas contratuais. Os honorários fixos de 365.278 USD representam aproximadamente7,5252%do custo estimado reproduzido de 4.854.061 USD e aproximadamente6,9985%do total reproduzido do artigo 8 de 5.219.339 USD. A alocação inicial provisória era de1.162.245 USD até 31 de março de 1994, ou aproximadamente22,2680%do total do artigo 8.

A reprodução da capa e a do artigo 8 devem, portanto, permanecer lado a lado. Escolher silenciosamente uma criaria uma falsa precisão. A afirmação defensável é que as fontes estão em conflito sobre o total, enquanto os componentes do artigo 8 são matematicamente consistentes e posteriormente repetidos judicialmente.

O que a atribuição provisória tentava controlar

Com essas limitações em mente, a reprodução de arquivo descreve um instrumento de contrato por prazo determinado, em vigor de 1º de janeiro de 1993 a 30 de setembro de 1998. Ela divide o período em uma fase de inicializaçã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 disposições de financiamento reproduzidas descrevem reembolso de custos mais honorários fixos. Essa estrutura não estabelece desperdício, indiferença ou desempenho medíocre. Significa apenas que o pagamento não era baseado exclusivamente em um resultado verificado, como uma atribuição corretamente realizada dentro de um prazo medido de ponta a ponta. A disciplina de serviço deveria vir dos requisitos, relatórios, supervisão da NSF, decisões de financiamento anual, revisão de desempenho e possibilidade de emenda ou substituição.

A Network Solutions aparece na reprodução como principalmente responsável pela qualidade, pontualidade e gestão eficiente dos serviços de registro. A NSF mantinha o planejamento de suporte, supervisão, monitoramento e avaliação. O agente de programa podia examinar o progresso e participar de discussões técnicas ou de cronograma, mas a reprodução limitava a capacidade desse agente de ordenar trabalhos fora do escopo, aumentar custos estimados, estender o período de execução ou modificar os termos expressos. Modificações significativas exigiam o canal de subvenções e contratos e ação por escrito.

O mecanismo de financiamento dava à NSF uma alavanca recorrente. A alocação inicial cobria a execução até 31 de março de 1994, com outros fundos sendo considerados incrementalmente. O texto reproduzido exigia aviso se os custos previstos para os 60 dias seguintes, somados aos custos já incorridos, excedessem 85% do valor alocado. O suporte futuro estava vinculado a uma revisão anual, um plano de programa proposto, negociação e fundos disponíveis.

O monitoramento foi projetado como um processo recorrente, não uma inspeção no final do período. A reprodução de arquivo pede revisões de transição semanais durante a fase de inicialização e depois até que a NSF decida 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 de planos, aprovações pendentes e despesas. As submissões anuais deveriam identificar objetivos alcançados, excedidos ou perdidos e explicar desvios significativos do plano.

A exigência reproduzida de relatório final previa um relato dos trabalhos e problemas suficientemente detalhado para que uma organização razoavelmente competente pudesse reproduzir o trabalho. Também previa a entrega de software e dados mediante solicitação. Essa linguagem expressa uma ambição de continuidade, mas a existência de uma cláusula de entrega não constitui um teste para saber se outro operador poderia retomar um serviço ao vivo com suas filas, correspondência, conhecimento tácito sobre políticas e rotinas de equipe intactas.

A emenda 4 adicionou outro mecanismo de visibilidade. Sua reprodução de arquivo exigia disponibilidade pública, a partir de novembro de 1995, das medidas de desempenho do serviço de registro, dos prazos de execução e do desempenho em relação a essas medidas. Também solicitava que o relatório de revisão de desempenho fosse disponibilizado para exame público. Isso indica que a evidência de desempenho público se tornara uma preocupação explícita. Não fornece os números faltantes por si só.

A atribuição também dividia a coordenação da revisão das solicitações. A linguagem de colaboração reproduzida permitia ao agente de programa da NSF resolver disputas técnicas, de gestão ou de cronograma entre os gestores da InterNIC. Isso podia tratar de um desacordo entre Network Solutions e AT&T sobre uma transferência, ou outro conflito de gestão dentro do projeto. Isso não era expresso como uma audiência para um solicitante contestar uma decisão sobre números.

O design principal-agente era, portanto, mais substancial do que uma subvenção passiva. A NSF mantinha ferramentas de financiamento, relatório, aprovação, avaliação e coordenação. A Network Solutions ainda controlava os sistemas e a equipe do dia a dia pelos quais as solicitações centrais progrediam. A questão importante não é se existia supervisão formal; ela existia. É se as evidências disponíveis mostram com que rapidez, consistência ou eficácia esses controles protegiam os solicitantes de números. Sobre isso, o dossiê público é escasso.

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

As reproduções provisórias do acordo incluem requisitos de prazo distintos para atribuições de números de rede por classe:3 dias úteis para a classe C,5 dias úteis para a classe Be22 dias úteis para a classe A. Estes são requisitos reproduzidos, não resultados de conformidade autenticados ou observações do serviço real.

Seu denominador é crucial. A definição reproduzida faz o prazo começar no recebimento de umasolicitação completa, incluindo qualquer informação especificamente solicitada sobre a topologia da rede e o uso do espaço de endereçamento anteriormente atribuído. Termina na atribuição de um número.

Isso exclui várias etapas que um solicitante poderia enfrentar. 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 são excluídas. O tempo de espera pela verificação do solicitante é excluído. Trocas adicionais sobre topologia, uso existente ou necessidades projetadas podem preceder a conclusão. O prazo de publicação após a atribuição também está fora do prazo, assim como submissões abandonadas antes de atingir a conclusão.

Um contratado poderia, portanto, satisfazer um requisito de três dias úteis para a classe C após a conclusão, enquanto o solicitante experimenta um intervalo mais longo entre a primeira submissão e o registro utilizável. Essa possibilidade não é evidência de que longos atrasos ocorreram. O inverso também conta: uma troca pré-conclusão prolongada poderia refletir evidências faltantes ou inadequadas fornecidas pelo solicitante, em vez de uma falha do contratado.

Uma avaliação séria exigiria pelo menos quatro carimbos de data/hora: primeiro recebimento, primeira resposta do analisador ou da equipe, reconhecimento da conclusão e atribuição final ou recusa. Também seriam necessários o tipo e tamanho da solicitação, qualquer evidência adicional solicitada, 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 faz referência a fórmulas de qualidade em uma proposta que não está presente no conjunto de acordos acessível. Sem essas definições, o pesquisador não pode determinar se a qualidade foi amostrada em 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 atribuição de números uma obrigação especificada. Não revelam quantas solicitações entraram em cada classe, quantas atenderam ao padrão ou se o prazo foi aplicado de forma consistente.

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

A evidência contemporânea mais sólida da carga de trabalho vem de uma seção submetida pelo contratado doRelatório Mensal da Internet de maio de 1994. Ela registra vários tipos diferentes de atividade:

• 5.009 e-mails para o hostmaster
• 251 solicitações por correio físico ou fax
• 2.047 chamadas telefônicas
• 1.316 domínios registrados
• 565 entradas de endereço reverso
• 12.645 unidades de números de rede classe C atribuídas
• 20 unidades de números de rede classe B atribuídas
• 57 ASNs atribuídos

Nenhuma dessas unidades pode ser somada para produzir um total significativo chamado de "solicitações". Um e-mail pode ser uma solicitação, uma correção, um pedido de status ou uma pergunta de política. Uma chamada telefônica pode dizer respeito a uma de várias funções. Uma entrada de endereço reverso não é uma nova alocação. Um registro de domínio não é uma atribuição de ASN.

Mais importante ainda, as 12.645 unidades de classe C não representam 12.645 solicitantes. O relatório indica separadamente que blocos de 256 redes classe C foram atribuídos a várias organizações e ao NIC DDN. Uma única solicitação ou ação de atribuição poderia, portanto, representar um grande número das unidades declaradas. Esse número demonstra a escala das unidades de endereço registradas durante o mês, não o número de solicitantes únicos ou adjudicações.

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

Esses números defendem fortemente uma infraestrutura comum para eficiência. Um escritório puramente manual teria enfrentado pressão crescente de e-mails, chamadas, atualizações de banco de dados, consultas e vários tipos de identificadores. Formulários padrão permitiram mecanizar verificações repetitivas. A análise pôde impedir que campos mal formatados chegassem à fila da equipe. As mensagens de erro podiam indicar ao solicitante o que o sistema estava rejeitando. A verificação podia detectar 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 grande escala. Não fornece uma taxa de conclusão para solicitações de números, taxa de rejeição pelo analisador, taxa de abandono, distribuição de prazos ou uma amostra de precisão independente. Não revela se um solicitante gerou muitos e-mails ou se uma chamada dizia respeito a vários registros. É uma evidência de operações, não uma auditoria de equidade.

O que o relato de 1996 do contratado acrescenta

Uma transcrição hospedada privadamente doRelatório Anual de Progresso dos Serviços de Registro InterNIC de 1996fornece afirmações de desempenho posteriores. Sua proveniência é mais fraca do que um relatório de contratado autenticado, e suas estatísticas permanecem auto-declaradas. No entanto, é mais informativa do que substituir o período apenas por perguntas hipotéticas.

A transcrição indica que em31 de dezembro de 1996, 95% das novas solicitações de registro eram 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 é decomposto em domínios, trabalho em números IP, ASNs, contatos ou outros modelos. A afirmação não pode ser relatada como uma taxa de conclusão de 95% para números IP.

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

A mesma transcrição registra evidências menos lisonjeiras sobre o suporte geral. Durante o ano de1996, as taxas de abandono de chamadas auto-declaradas variavam demenos de 8% a mais de 50%. As taxas eram tipicamente de10% a 20% na última parte do ano. Os tempos médios de espera eram de cerca dequatro minutos, e o tempo médio para responder a mensagens de voz não era medido. O relato também indica que problemas de circuitos telefônicos identificados em dezembro levaram muitos chamadores a receber sinais de ocupado.

Esses números oferecem uma visão limitada da tensão no 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 IP não pode ser distinguido de alguém perguntando sobre um domínio, faturamento ou um registro de contato. As evidências apoiam uma conclusão geral de que o suporte telefônico sofreu pressão substancial e variável em 1996. Isso não pode ser convertido em uma taxa de dano para atribuição de números.

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

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

As evidências disponíveis, portanto, apoiam duas proposições ao mesmo tempo. A Network Solutions construiu e operou uma automação capaz de lidar com um volume declarado substancial. O dossiê público não permite uma estimativa confiável da frequência com que os solicitantes de números sofreram atrasos, correções, recusas ou revisões bem-sucedidas.

Onde a concentração realmente estava

A cadeia central pode ser analisada sem qualificar cada exigência administrativa como dano.

No recebimento, a Network Solutions controlava o endereço de e-mail publicado, o modelo aceito e o analisador. Um formulário mal formatado ou obsoleto não podia progredir no caminho automatizado até ser corrigido. Canais manuais subsistiam, mas o mesmo contratado de registro, em última análise, operava o serviço central não DDN.

Na verificação, o solicitante devia confirmar que a máquina havia interpretado corretamente a submissão. Era uma proteção contra erros silenciosos. Também colocava a conclusão do ciclo sobre o solicitante dentro de sete dias. A incidência de expirações é desconhecida, portanto a regra demonstra uma dependência e uma possível consequência de reenvio, em vez de um ônus medido sobre uma população.

A completude era a fronteira seguinte. Uma solicitação de número podia exigir informações sobre topologia e uso anterior. Essas evidências não eram um ornamento burocrático: a conservação de endereços e a agregação de roteamento exigiam que os registros avaliassem as necessidades operacionais. O problema de governança é que a determinação da completude pelo contratado controlava quando o prazo reproduzido começava a correr. Sem registros de solicitações com data/hora, é impossível dizer se esse poder discricionário foi exercido rapidamente ou de forma inconsistente.

O processamento substancial seguia. A equipe da Network Solutions processava o trabalho central não DDN sobre números de rede e ASNs no quadro aplicável de delegação e técnica. Era mais consequente do que direcionar um usuário a um documento. O processamento pela equipe contribuía para decidir se um identificador solicitado seria atribuído, em que quantidade e após quais informações justificativas.

Após a atribuição, vinham o registro e a publicação. A reprodução provisória define a 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 eram ligados, mas institucionalmente distintos.

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

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

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

Isso é mais estreito do que um gargalo universal, mas permanece institucionalmente significativo. Concentrar etapas consecutivas pode tornar a automação consistente e os registros coerentes. Também pode tornar a qualidade do caminho central fortemente dependente dos sistemas, pessoal, definições e transferências de um único operador. O dossiê histórico apoia a análise dessa dependência sem presumir abuso.

A geografia e a classe do solicitante modificavam o caminho

O serviço central nunca teve uma relação uniforme com cada solicitante da Internet ao longo de 1993-1998.

A Europa já oferecia o contraexemplo mais claro. Ahistória do próprio RIPE NCCdistingue sua criação formal emabril de 1992da distribuição de endereços, que não era uma atividade inicial, mas foi adicionada posteriormente em1992. No momento da transição da InterNIC, a administração de números na Europa havia começado a passar por uma estrutura regional.

ARFC 1466, publicada em maio de 1993, descrevia o registro da Internet como o registro padrão onde nenhuma autoridade de registro delegada existia. Ela defendia a distribuição do registro porque registros geograficamente mais próximos podiam servir melhor às comunidades, línguas e costumes locais. Notava que o RIPE NCC já havia recebido um bloco de espaço classe C para alocação europeia.

A RFC 1466 não descrevia caminhos comerciais intercambiáveis. Dizia que um solicitante de rede podia contatar diretamente o registro central da Internet e poderia, dependendo das circunstâncias, ser encaminhado a um registro regional. O registro central devia estar pronto para atender um assinante quando necessário. No nível regional, o documento favorecia um registro único reconhecido para cada zona 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 emergiu em um cronograma diferente. Ahistória institucional do APNICindica que seu projeto piloto deveria começar emsetembro de 1993e continuou até junho de 1994. A IANA reconheceu publicamente o APNIC emabril de 1994ao delegar as faixas IPv4202/8 e 203/8. O caminho disponível para um solicitante da região da Ásia-Pacífico dependia, portanto, da data, da geografia, da maturidade do projeto piloto e da delegação aplicável.

De acordo com aRFC 2050 de 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 o APNIC com a região da Ásia-Pacífico. Os registros locais operavam abaixo do nível regional.

As relações com provedores criavam outro caminho. A RFC 2050 aconselhava muitos ISPs a obter espaço de endereçamento de um provedor upstream para apoiar o roteamento hierárquico e a agregação. Alguns provedores multi-conectados ou conectados a um ponto de troca podiam solicitar diretamente a um registro regional. Solicitantes em áreas sem registro regional designado podiam contatar um registro regional, que poderia processar ou encaminhar a solicitação.

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

O caminho DDN permaneceu separado para sua população elegível durante a transição de 1993. Dizia-se a um usuário militar que continuasse com o NIC DDN. Esse caminho é uma evidência contra um serviço único abrangendo todos os solicitantes, mas não era uma alternativa geral aberta a qualquer organização não militar.

Em 1996, a descrição mais precisa não era que a Network Solutions servia como única porta global para números. A InterNIC era um registro regional dentro de uma hierarquia que também incluía o RIPE NCC, o APNIC, os registros locais e as atribuições por provedores. Anteriormente, o registro central permanecia o padrão para zonas sem delegado e mantinha funções importantes de coordenação.

A regionalização reduziu a população exposta ao processo de solicitação central. Não criou um mercado no qual cada solicitante pudesse mudar de registro após um mau serviço. Um operador europeu não podia necessariamente escolher o registro norte-americano como substituto; um cliente de provedor podia ter que aceitar o 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 dossiê contém quatro tipos diferentes de correção ou revisão. Tratá-los como um único exageraria a proteção dos solicitantes.

O primeiro caminho era a correção operacional. A RFC 1400 documentava as mensagens de erro do analisador, os formulários de verificação corrigidos, o reenvio, o status do ticket e o contato com a equipe hostmaster. Esses mecanismos tratavam de entradas mal formatadas, modelos obsoletos, interpretação do analisador e status das solicitações. A equipe também podia ter reexaminado uma submissão informalmente. O documento não revela a frequência, duração ou resultado dessas interações.

O segundo caminho dizia respeito a disputas entre os gestores da InterNIC. A reprodução do acordo de arquivo indica que o agente de programa da NSF podia resolver disputas técnicas, de gestão ou de cronograma entre os colaboradores. Isso apoiava a coordenação dentro do serviço contratado. Não era uma apelação para um solicitante contra uma decisão sobre números.

O terceiro caminho dizia respeito a desacordos entre o beneficiário e a NSF. Os termos gerais hospedados em espelho parecem prever que disputas de fato não resolvidas informalmente receberiam uma decisão por escrito de um agente de subvenções da NSF, podendo o beneficiário solicitar reexame no prazo de30 diasapós o recebimento dessa decisão. Como os termos gerais incorporados completos e sua proveniência não foram autenticados no conjunto da atribuição executada acessível, isso permanece uma evidência contratual provisória. Em todo caso, era um processo para a parte contratante acessível ao beneficiário, não um recurso concedido a um solicitante de rede.

O quarto caminho era a hierarquia de registros orientada a solicitantes estabelecida na RFC 2050. Uma organização insatisfeita com o desempenho do registro de atribuição podia apelar ao registro pai. O registro de atribuição devia disponibilizar a documentação pertinente. Uma apelação adicional podia subir ao pai do pai e, uma vez esgotados os outros caminhos, finalmente à IANA. Cada registro deveria documentar seu procedimento de apelação.

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

Nenhum dos documentos preservados fornece uma série de apelações específicas a números. Não há número recuperado de contestações, duração média, taxa de cancelamento, distribuição de resultados ou evidência de que solicitantes em situações similares recebiam revisão consistente. A ausência de tal série não mostra que as apelações eram não utilizadas ou ineficazes; impede uma conclusão medida em um sentido ou no outro.

O mapa de recursos, portanto, muda ao longo do tempo e conforme o ator. Em 1993, os solicitantes podiam corrigir formulários e contatar a equipe, enquanto a NSF geria seus contratados. Os termos gerais provisórios forneciam um caminho de recurso contratual para o beneficiário. Em novembro de 1996, o sistema de registro de números publicado articulava um caminho orientado a solicitantes através dos registros pais até a IANA. Cada um tratava de uma disputa diferente.

Evidências de desempenho e continuidade no fim da cadeia

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

As contagens de solicitações deveriam identificar solicitações de números concluídas e solicitantes únicos, em vez de unidades de endereço, mensagens ou chamadas. Os registros de prazos precisariam de carimbos de data/hora de ponta a ponta, não apenas o intervalo após a conclusão. Os dados de correção precisariam de modelos rejeitados, formulários corrigidos, solicitações expiradas e submissões abandonadas. Os dados de decisão precisariam de recusas substanciais, reduções e resultados específicos por classe ou prefixo.

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

O acordo reproduzido previa relatórios capazes de responder a algumas dessas perguntas. A emenda 4 exigia medidas de desempenho públicas. A transcrição de 1996 faz referência a dados de desempenho e processamento, enquanto a apresentação pública preservada é incompleta para uma análise específica a números. A existência de um sistema de relatório planejado não é o mesmo que possuir sua série completa.

Oparecer jurídico do GAO de 2016fornece evidências retrospectivas limitadas sobre a transição posterior. Indica que, quando a administração passou para o Departamento de Comércio em 1998, uma disposição adicionada exigia que a Network Solutions entregasse cópias do software, dados e documentação gerados sob o acordo 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 outros fichários contendo dados e documentação de software.

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

A investigação do GAO concentrava-se principalmente na propriedade governamental e na 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 para solicitações de números. Não pode preencher o dossiê faltante de solicitações de endereço, atrasos ou apelações.

As taxas de domínio posteriores, disputas de marcas, concorrência de registradores e disputas sobre a propriedade da zona raiz são igualmente delimitados. Podem iluminar a história da mesma empresa ou atribuição, mas não provam que solicitantes de números foram recusados, atrasados ou privados de recurso. Evidências específicas a funções permanecem necessárias.

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

Contrafactual: um único gestor para os três serviços

Consideremos uma alternativa construída por um analista na qual a NSF teria atribuído os serviços de registro, diretório e acesso a bancos de dados, e serviços de informação a um único provedor integrado. É um contrafactual para testar a estrutura da contratação, não uma afirmação de que tal modelo era historicamente viável ou preferível em 1993.

A integração poderia reduzir os custos de coordenação. Os dados de registro poderiam passar do recebimento à publicação dentro de uma única 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, consultas públicas e suporte geral. Os usuários não precisariam identificar se a Network Solutions ou a AT&T era responsável por um problema no nível da transferência.

O investimento em automação também poderia se tornar mais consistente. 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 as atribuições. A equipe de informação geral poderia ver o estado de um registro sem referência separada.

O risco é um confinamento de falhas mais amplo. O mesmo provedor receberia as solicitações, processaria as atribuições, publicaria os registros, responderia a perguntas e reportaria seu próprio desempenho. Uma falha de sistema ou uma transição organizacional mal-sucedida poderia afetar o recebimento, o processamento autoritativo, a publicação e a orientação ao mesmo tempo.

A supervisão também se tornaria menos modular. Organizações separadas criavam fronteiras onde a NSF podia comparar os 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 conjunto mais amplo de sistemas e expertise. Trocar o serviço de registro já exigia continuidade de software, dados, filas e políticas. Substituir uma InterNIC integrada adicionaria a 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 reforça o argumento de eficiência da divisão pela NSF. Atribuições separadas limitavam a amplitude do papel formal de um provedor e permitiam operações especializadas. Isso também esclarece por que a concentração permanecia dentro do componente de registro: a divisão separava serviços diferentes, em vez de criar substitutos para o mesmo ato de autoridade.

Contrafactual: vários provedores de registro substituíveis

Uma segunda alternativa construída por um analista permitiria que vários provedores de registro servissem à mesma população de solicitantes enquanto compartilhavam 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 o formato, coletar as informações justificativas e submeter uma transação aprovada a um serviço central. Os solicitantes poderiam mudar para outro provedor quando o suporte estivesse inacessível. Uma falha de provedor não pararia necessariamente todos os canais de recebimento. A NSF poderia comparar prazos, taxas de correção e experiência dos solicitantes 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 deveria gerenciar o espaço disponível, reservas pendentes, atribuições concluídas, exceções e cancelamentos sem estados conflitantes. A replicação atrasada poderia ser operacionalmente perigosa.

A consistência colocaria um segundo desafio. Os provedores poderiam interpretar diferentemente a topologia, o uso e os requisitos de agregação. Os solicitantes poderiam buscar a decisão mais permissiva. Uma política comum, evidências padrão, registros de transações e um examinador vinculante seriam necessários. A distribuição do recebimento, portanto, deslocaria, em vez de eliminar, a autoridade central.

O investimento em automação poderia se fragmentar. Vários provedores poderiam duplicar analisadores, sistemas de estado 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 evidentes.

A supervisão poderia melhorar se os provedores gerassem registros comparáveis, mas apenas se o mandante controlasse as regras de medição. Um provedor poderia iniciar seu cronômetro no primeiro recebimento, enquanto outro iniciaria 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 das solicitações também exigiria design institucional. Uma escolha de atendimento ao cliente não é um substituto para uma apelação quando o serviço central de política rejeita uma atribuição. Uma mudança de provedor poderia ajudar com a explicação ou preparação do formulário, enquanto a decisão autoritativa permanecia inalterada. O examinador compartilhado precisaria de documentação, prazos e autoridade sobre cada provedor.

O confinamento de falhas seria melhor no nível do recebimento, mas incerto no nível do livro-razão. Várias portas de entrada poderiam sobreviver a uma falha de um provedor. Uma falha do serviço central de reserva ou unicidade poderia parar todas elas. A arquitetura distribuiria parte do 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 tratou a escala por uma hierarquia geográfica, em vez de provedores concorrentes compartilhando um pool único.

Essa alternativa, no entanto, expõe questões de design úteis. O recebimento poderia ser substituível sem fragmentar o livro-razão? Os solicitantes poderiam mudar de provedor de suporte enquanto mantinham decisões consistentes? Registros comparáveis poderiam tornar a revisão de desempenho mais crível? O examinador central poderia ser separado do processamento de primeira linha? As evidências da InterNIC preservadas não testam essas possibilidades, portanto nenhuma estimativa de bem-estar, atraso ou custo de mudança se segue.

A conclusão proporcionada

O design da InterNIC pela NSF em 1993 combinava especialização com uma identidade pública comum. A Network Solutions geria o registro central não DDN; a AT&T geria o acesso a diretórios e bancos de dados; a General Atomics/CERFnet geria informação e orientação. A NSF mantinha financiamento, monitoramento, aprovações, avaliação e coordenação intergestores. O USC/ISI continuava a coordenação da IANA, e o NIC DDN mantinha o caminho militar.

O sistema de registro oferecia uma administração útil. Formulários estruturados, análise por máquina, erros explícitos, confirmação do solicitante, status do ticket, infraestrutura comum e processamento final humano eram respostas plausíveis a um volume em rápido aumento. Os totais operacionais de maio de 1994 e a afirmação posterior de automação de domínios mostram atividade substancial, embora não evidência independente da qualidade do serviço de números.

Dentro da instituição dividida, a Network Solutions controlava as etapas consecutivas do caminho central de registro. Essa concentração tornava uma solicitação dependente do canal aceito, do analisador, do loop de correção, da determinação de completude, do processamento pela equipe e da atualização do registro de um único contratado. É corretamente descrita como uma dependência concentrada no recebimento e processamento centrais.

O sistema circundante mudou. O RIPE NCC distribuía endereços na Europa, o APNIC emergia na Ásia-Pacífico, os registros locais e provedores serviam populações adicionais, os usuários DDN mantinham outro canal, e a RFC 2050 colocava a InterNIC em uma hierarquia regional com um caminho 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; os termos gerais provisórios descreviam um reexame beneficiário-NSF; e a RFC 2050 articulou posteriormente a apelação dos solicitantes através dos registros pais até a IANA. O que falta é a série de resultados necessária para julgar esses mecanismos nos casos de números.

O 'preço' do título é, portanto, uma questão de investigação, em vez de uma perda quantificada. A administração central trouxe escala e consistência, enquanto colocava várias etapas de uma cadeia definida em um único contratado. O dossiê preservado não prova que essa dependência era universalmente inevitável, sistematicamente abusiva ou responsável por um dano mensurável para os solicitantes de números.