Os artigos da equipaMais artigos

Descubra a Internet Engineering Task Force (IETF)

Como ajuda a IETF as redes a trabalhar em conjunto? Compreenda as RFC, as normas voluntárias e a distinção de Lu Heng entre coordenação e controlo.

Índice

Dois engenheiros em miniatura aproximam conectores azuis correspondentes entre dispositivos construídos de forma independente.

Especificações comuns ajudam sistemas construídos de forma independente a trabalhar em conjunto. A sua utilidade depende do que as pessoas conseguem implementar e testar.

O seu navegador pode abrir um sítio operado por uma empresa do outro lado do mundo. O navegador, o servidor e as redes entre ambos podem ser de fornecedores diferentes. Uma das razões pelas quais conseguem trabalhar em conjunto é o facto de os engenheiros terem acordado a forma como os seus sistemas devem trocar informação.

A Internet Engineering Task Force, ou IETF, desenvolve muitas dessas especificações técnicas. O seu trabalho ajuda sistemas construídos de forma independente a cooperar. Isso coloca uma questão útil: como podem regras comuns tornar possível uma rede global, deixando simultaneamente os seus participantes independentes?

O que a IETF faz realmente

A própria introdução da IETF descreve uma comunidade de normas abertas. As pessoas contribuem enquanto indivíduos, inclusive através de listas de correio de grupos de trabalho. Examinam problemas técnicos, debatem propostas e desenvolvem especificações que outros podem implementar. Se procura o sítio oficial da organização, essa ligação leva-o até lá.

Pense numa especificação como num conjunto partilhado de instruções. Empresas diferentes podem construir os seus próprios produtos com base nela e depois verificar se esses produtos funcionam em conjunto. O valor resulta de tornar possível a comunicação entre fronteiras organizacionais.

Uma RFC é um documento, não é automaticamente uma norma

Muitos leitores deparam-se pela primeira vez com a IETF através de um número de RFC. RFC significa Request for Comments, uma designação histórica para uma série de documentos publicados. Como explica o guia de RFC da IETF, a série inclui normas, boas práticas atuais, trabalho experimental e documentos informativos. Também inclui publicações de outros fluxos que não são da IETF.

Antes de dizer “a norma exige isto”, verifique o estado do documento e se documentos posteriores o atualizam ou substituem. O facto de uma proposta se tornar uma RFC publicada não transforma, por si só, todas as ideias nela contidas num requisito universal.

Como deve funcionar o acordo

A tradição da IETF combina o juízo de engenharia com a experiência de implementações funcionais. A sua explicação do consenso aproximado salienta a consideração das objeções técnicas, incluindo as objeções minoritárias. Contar apoiantes não substitui dar resposta a um problema de conceção.

A declaração de missão da IETF estabelece também uma distinção importante: uma norma descreve como fazer algo de forma consistente; por isso, a IETF não impõe nem fiscaliza a sua utilização. A adoção dá alcance prático a uma especificação. A publicação, por si só, não confere a uma organização autoridade sobre a Internet.

Onde Lu Heng traça o limite

Na Nota 65, sobre a primazia do código funcional, Lu Heng utiliza esta tradição de engenharia para contestar a autoridade reivindicada pelos Registos Regionais da Internet. A sua crítica diz respeito ao que acontece quando a administração dos registos de recursos de numeração se transforma em poder sobre as redes que deles dependem.

A distinção é importante: escrever uma especificação de protocolo e administrar os registos de endereços de um operador são funções diferentes. Uma discussão técnica aberta pode produzir trabalho de engenharia útil. No argumento de Lu Heng, não pode fabricar um mandato para governar operadores que não tenham autorizado essa função política.

A direção que propõe é um sistema de coordenação que as redes possam verificar por si próprias. Registos partilhados e um pequeno conjunto de regras comuns impediriam a utilização duplicada, estabeleceriam quem controla cada recurso e protegeriam a segurança. Por exemplo, os participantes poderiam verificar uma transferência de endereços contra regras públicas, em vez de depender da aprovação discricionária de um registo.

Os operadores fariam as escolhas seguintes através do código que executam e das alterações que adotam. Escolher regras incompatíveis pode limitar as redes que funcionam em conjunto; a sua proposta torna esse limite visível, em vez de transformar o desacordo em punição administrativa.

Por que razão a distinção importa antes de uma crise

Quando uma rede se torna dependente do reconhecimento de uma instituição, substituir essa dependência é difícil precisamente quando a continuidade é mais importante. A posição de Lu Heng é que se devem incorporar cedo no projeto registos verificáveis e validação independente, para que a cooperação possa sobreviver à falha ou captura de uma instituição.

A questão seguinte é concreta: em que deve um operador poder confiar e que poder nunca deve adquirir um organismo de coordenação? Comece pela Nota 72 mais curta: A Carta de Direitos da Coordenação da Unicidade.