Resumo

  • Em agosto de 2001, o RIPE NCC publicou o formulário RIPE-224 para pedidos de espaço IPv6 de pontos de troca de tráfego. Timothy Lowe, Nurani Nimpuno e Sabrina Waschke assinaram o documento; Nimpuno anunciou que solicitações pendentes passariam a usá-lo.
  • Fearghas McKay e David Kessens, presidentes de dois grupos de trabalho da RIPE, pediram a suspensão da política proposta porque faltava submeter um texto final à comunidade. Operadores relataram serviços à espera; Nimpuno explicou por que o RIPE NCC havia interpretado as discussões anteriores como concluídas.
  • Em 10 de setembro, os presidentes disseram que a proposta provisória superara o prazo de comentários e pediram sua publicação e o início das atribuições. O tamanho padrão do prefixo e outros detalhes continuaram em discussão.

Quem preenchia as lacunas do formulário

O RIPE-224 começava com uma advertência prática. Um pedido sem o identificador correto do registro seria devolvido. Alterações no modelo poderiam atrasar a resposta. Quem já lidou com solicitações de recursos reconhece o som de uma repartição pronta para trabalhar: o envelope pode chegar, mas precisa chegar do jeito certo.

O modelo havia sido escrito por Timothy Lowe, Nurani Nimpuno e Sabrina Waschke, com data de 15 de agosto de 2001. A organização que pedia endereços IPv6 precisava explicar sua finalidade e apresentar documentação mostrando que facilitava a troca de tráfego entre provedores. Precisava ainda demonstrar uma política clara e aberta de entrada de membros. O nome “ponto de troca” vinha acompanhado de regras de acesso que o RIPE NCC poderia examinar.

Outras perguntas entravam na rede física. A lista de membros deveria incluir números de sistemas autônomos. Ao menos três participantes precisavam manter relações de peering BGP na zona livre de rota padrão, segundo a definição do próprio documento. O registro podia conferir os dados na RIPE Database e consultar os pares citados. Também exigia informação sobre uso anterior de espaço IPv4 e IPv6, sub-redes fisicamente distintas e um plano de infraestrutura para agora, um ano e dois anos adiante. O exemplo de planejamento mostrava uma malha neutra de peering em /64.

Esses campos davam ao atendente condições de distinguir um IXP operacional de uma etiqueta conveniente. O espaço pedido serviria à infraestrutura compartilhada de troca de tráfego. Um endereço independente do bloco de qualquer membro ajudaria o ponto de troca a funcionar como lugar comum entre provedores. A discussão de 2001 nas listas da RIPE mostra que operadores e participantes ainda debatiam qual tamanho atribuir e quanta prova pedir.

O anúncio correu na frente da última página

Em 17 de agosto, Nimpuno, então gerente de política de endereços do RIPE NCC, comunicou que o registro estava começando a fazer atribuições IPv6 a pontos de troca interessados. Solicitantes que já aguardavam seriam orientados a preencher o novo formulário. Ela apresentou o passo como consequência de um consenso obtido nas discussões da comunidade. A relação entre debate e atendimento parecia resolvida para quem administrava a fila.

Quatro dias depois, Fearghas McKay, presidente do grupo de trabalho de pontos de troca, e David Kessens, presidente do grupo IPv6, responderam em um fio público. Eles entendiam que a comunidade ainda não havia aprovado uma proposta final. Pediram ao registro que suspendesse a política até a conclusão de uma última discussão. Para Kessens, o problema tinha um endereço documental: existia um formulário que descrevia como pedir, mas faltava o texto definitivo da política que explicaria como o pedido seria julgado.

O pedido de pausa foi contestado por gente que precisava de números. Robert Kiessling disse que a conversa já durara demais. Steve Walker relatou clientes querendo tráfego IPv6 e esperando o processo de aplicação. Gert Doering contou que DECIX usava provisoriamente endereços do bloco IPv6 da SpaceNet. Hans Petter Holen perguntou se seria possível conceder espaço de forma interina e rever as informações quando o consenso se fechasse. Essas mensagens dão rosto operacional ao prazo: havia redes para conectar enquanto a redação da regra seguia aberta.

Kessens respondeu com uma distinção útil. Os presidentes não exigiam unanimidade, e sim um texto final que incorporasse as observações já recebidas. A lista teria então uma última oportunidade de apontar problemas grandes. Um formulário publicado mostrava o funcionamento desejado pelo registro; a aprovação explícita da política tornaria reconhecível a origem daqueles critérios. Os operadores, por sua vez, queriam saber quando a decisão lhes permitiria abandonar soluções improvisadas.

A explicação de Nurani

Nimpuno expôs o entendimento do RIPE NCC em 23 de agosto. O assunto havia sido discutido intensamente em reunião e nas listas. Mirjam Kühne enviara uma síntese em junho. Algumas observações de redação tinham aparecido, sem nova oposição à definição proposta. Vários pedidos de IXPs aguardavam desde abril. Diante dessa sequência, o registro considerou apropriado implementar a política e atender a fila.

Ela acrescentou que o RIPE NCC precisava aplicar a política realmente acordada pela comunidade e melhorar a coordenação com os presidentes dos grupos. Também convidou os participantes a seguir contribuindo. Sua resposta não apagou a divergência; mostrou como ela havia surgido. A equipe do registro lia uma longa discussão seguida de silêncio como sinal suficiente para trabalhar. Os presidentes responsáveis por declarar o resultado queriam que a comunidade visse uma versão final antes da primeira decisão sobre um pedido.

O próprio formulário mostra por que a diferença importava. A organização candidata teria de provar três membros com peering BGP, expor suas regras de entrada e projetar a infraestrutura futura. Uma vez em vigor, essas exigências podiam aprovar ou atrasar uma atribuição. A pergunta dos presidentes era quando essa combinação de testes passara a ser a regra da comunidade, com oportunidade real para objeções ao texto completo.

Setembro colocou uma etiqueta no provisório

Os dois presidentes voltaram à lista em 10 de setembro. O prazo para comentar uma proposta interina havia terminado e a direção do debate não mudara de modo fundamental. McKay e Kessens disseram que o RIPE NCC podia publicar a política provisória e começar as primeiras atribuições. Ao mesmo tempo, enumeraram questões ainda abertas: /64 ou /48 como padrão, origem do bloco, documentação e registro na base RIPE.

Uma precaução técnica tornava a decisão reversível. As atribuições /64 iniciais seriam feitas dentro de limites /48 reservados, permitindo ampliar o prefixo se o grupo depois escolhesse outra dimensão. O operador receberia um caminho de atendimento, e a política preservaria espaço para mudar. Esse desenho responde ao relógio da fila sem fingir que todas as perguntas desapareceram.

O relatório anual de 2001 do RIPE NCC registrou a política para IXPs entre os desenvolvimentos daquele ano e apontou tanto para a discussão interina quanto para o formulário. É o balanço posterior da instituição. A mensagem de setembro mostra o instante em que os presidentes pediram a publicação e o começo das atribuições.

Em 2002, o RIPE-256 apresentou uma formulação mais estável. Definiu o ponto de troca como infraestrutura física de camada 2 operada por uma entidade, com pelo menos três provedores conectados e política aberta para novas adesões. Se a organização tivesse certeza de nunca precisar de mais de uma rede, receberia /64; em outro caso, /48. O documento também advertia que aquele espaço poderia não ser globalmente roteável e remetia ao formulário. A versão posterior confirma a importância de ler a sequência de documentos, não apenas o desfecho.

Um balcão com três donos de tempo

Nimpuno estava entre as autoras do instrumento administrativo e era a gerente que anunciou sua utilização. McKay e Kessens tinham a tarefa de conduzir e concluir o processo de política. Os operadores tinham clientes, equipamentos e uma malha de peering esperando. A disputa surgiu porque esses três calendários não coincidiam em agosto.

O RIPE NCC precisava de dados para reconhecer um IXP e dimensionar seu pedido. A comunidade precisava de um ato identificável que autorizasse aplicar os critérios. O operador precisava de uma resposta enquanto sua rede continuava usando um bloco emprestado ou adiando o serviço. Setembro reuniu essas necessidades sob uma política expressamente interina, deixando o tamanho e a documentação sujeitos a revisão.

O humor está no detalhe de escritório. O formulário avisava que devolveria ao remetente um pedido sem número de registro. Poucos dias depois, os presidentes pediram ao registro a folha que faltava do lado de dentro: a versão final da política. Quando essa folha ganhou um caminho provisório aprovado, as caixas do formulário puderam enfim fazer seu trabalho.