O Tao do IETF: Guia destinado aos novos participantes do Internet Engineering Task Force

Paul Hoffman, Editor


About This Document

Copyright © 2013 IETF Trust. All rights reserved.

The current version of this web page can always be found at http://www.ietf.org/tao.html; that page can also be retrieved protected by TLS. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2013-07-20.

Esta página web é em Português. Há uma lista de traduções do Tao do IETF.


1. Introdução

Desde os seus primeiros anos, a participação presencial nos encontros do Internet Engineering Task Force (IETF) tem crescido de forma surpreendente. Muitos são novos participantes, entre os quais, vários se tornam participantes regulares. Quando os encontros eram menores, não haviam dificuldades para que um recém-chegado entendesse o seu funcionamento. Hoje em dia, um novo participante encontra muitos rostos novos, conhecidos, muito mais pelos documentos que escrevem ou pela participação intensa em mensagens de e-mail.

Este documento descreve diversos aspectos do IETF, com o objetivo de explicar, ao novo participante, como o IETF trabalha. Isto permite encorajar, preparar, e dar segurança, ao recém-chegado, ao participar mais ativamente, na primeira vez, nas discussões presenciais (face-a-face) dos grupos de trabalho (WGs) tornando essa participação, mais eficaz.

Sem dúvida, muitos participantes do IETF, não vão a todas as reuniões. Em vez disso, eles ficam ativos nas listas de discussões dos diversos grupos de trabalho. O funcionamento interno dos WGs pode-se tornar obscuro, para os recém-chegados entenderem. O Tao fornece as informações básicas, necessárias, para que eles se tornem participantes ativos.

O IETF está em constante mudança. Embora os princípios descritos neste documento devam permanecer inalterados ao longo do tempo, detalhes práticos podem ter sofrido mudanças no momento da leitura, por exemplo, em uma ferramenta de Web alterou-se um endereço de e-mail para criar uma ação.

Muitos tipos de documentos do IETF podem ser encontrados nas referências do Tao: BCPs, RFCs e STDs. As BCPs (Best Currents Practices) fornecem recomendações sobre as melhores práticas da Internet, os RFCs (Request for Comments) são os principais documentos técnicos do IETF e, os STDs (de "Standard") são RFCs caracterizados por proporem padrões aos recursos da Internet. Na verdade, os três tipos são RFCs. Consulte Section 6 para maiores informações a respeito.

Esta página é uma continuação da série de RFCs sobre o "Tao do IETF". Consulte o [RFC6722] para uma explicação de como o último RFC da série se tornou esta página web. A versão do Tao, aqui exibida é baseada no [RFC4677], escrito em coautoria com Susan Harris. A versão original deste documento, publicado em 1994, foi escrita por Gary Malkin.

Finalmente, por que "Tao"? Pronuncia-se "Daow", em Inglês. Tao é o princípio básico por trás dos ensinamentos do conhecido mestre chinês chamado Lao-Tsé. Seu símbolo familiar é um círculo em preto-e-branco representando o Yin e o Yang. O Taoísmo concebe o universo como um único organismo, e os seres humanos como partes interdependentes de um todo cósmico. Tao é às vezes traduzido como "o caminho", mas de acordo com a filosofia taoísta o seu verdadeiro significado não pode ser expresso em palavras.

1.1 Acrônimos e Abreviações Usadas no Tao

Algumas das abreviaturas e siglas deste documento estão listados abaixo.

Termo Significado
AD Area Director (diretor de área)
BCP Best Current Practice (melhores práticas atuais)
BOF Birds of a Feather (reuniões rápidas entre pessoas, com interesses comuns)
FAQ Frequently Asked Question(s) (perguntas mais frequentes)
FYI For Your Information (RFC) (documento para sua informação)
IAB Internet Architecture Board (conselho de arquitetura da Internet)
IAD IETF Administrative Director (diretor administrativo do IETF)
IANA Internet Assigned Numbers Authority (autoridade para atribuição de números da Internet)
IAOC IETF Administrative Oversight Committee (comitê administrativo de supervisão do IETF)
IASA IETF Administrative Support Activity (atividade administrativa de suporte ao IETF)
ICANN Internet Corporation for Assigned Names and Numbers (corporação da Internet para atribuição de nomes e números)
I-D Internet-Draft (documento de trabalho)
IESG Internet Engineering Steering Group (grupo diretor de engenharia da Internet)
IETF Internet Engineering Task Force (grupo de trabalho em engenharia da Internet)
IPR Intellectual property rights (direitos de propriedade intelectual)
IRTF Internet Research Task Force (grupo de trabalho em pesquisa da Interne)
ISOC Internet Society (sociedade da Internet)
RFC Request for Comments (documento para solicitação de comentários)
STD Standard (RFC) (padrões)
WG Working Group (grupo de trabalho)

2. O que é o IETF?

O IETF é um grupo informal e auto organizado, cujos membros contribuem para a engenharia e evolução das tecnologias de Internet e, também é o principal órgão envolvido no desenvolvimento de especificações para os novos padrões da Internet. O IETF é incomum no sentido de que consiste em uma série de eventos, sem estrutura ou diretoria estatutária e, sem membros ou candidatos. Consulte [BCP95] sobre "uma declaração de missão para o IETF", onde se encontra maiores detalhes disponíveis.

Sua missão inclui o seguinte:

Um encontro do IETF não é uma conferência, embora nela existam apresentações técnicas. O IETF não é um organismo de padronização tradicional, embora muitas especificações que são produzidas tornem-se padrões. O IETF é composto de voluntários, muitos dos quais se reúnem três vezes por ano com o objetivo de cumprir a missão do IETF.

Não há adesão formal ao IETF. Qualquer pessoa pode se inscrever para um encontro e, em seguida, participar. Tornar-se membro do IETF é acima de tudo participar das listas de discussão ou grupos de trabalho do IETF (ver Section 2.3) com o fim de acessar todas informações sobre as atividades e debates.

É claro que nenhuma organização pode ser tão bem sucedida como o IETF sem ter algum tipo de estrutura. No caso da IETF, a estrutura é fornecida por outras organizações, como descrito em [BCP11]: "As organizações envolvidas no processo de padronização do IETF". Se decidir em participar do IETF e, se fosse ler uma BCP, deverá ser esta, a escolhida!

O site do IETF, http://www.ietf.org, é a melhor fonte de informações sobre reuniões, grupos de trabalho, Rascunhos da Internet (I-Ds), RFCs, endereços de email do IETF, e muito mais.

De muitas maneiras, o IETF é baseado nas crenças de seus participantes. Uma das crenças fundamentais está incorporada em uma citação de David Clark: "Nós rejeitamos reis, presidentes e votação. Nós acreditamos em um consenso aproximado e no código executável". Outra citação que se tornou, também, uma crença comum no IETF vem de Jon Postel: "Seja conservador no que você enviar e liberal no que você aceita".

O IETF realmente existe, pelos seus participantes. Por não haver medidas restritivas na adesão, as pessoas chegam para participar, de todo o mundo e de diferentes partes da indústria da Internet. O IETF opera apenas em Inglês. Consulte Section 3.12 para obter informações sobre como participar do IETF.

Mais uma coisa importante para os novatos: o IETF não detém o monopólio da Internet, apesar de algumas pessoas pensarem que sim, erroneamente. O IETF cria padrões voluntáriamente, que são frequentemente adotados por usuários da Internet, mas não controla, ou mesmo patrulha a Internet. Se o seu interesse no IETF é porque deseja ser parte de alguma supervisão, você se desapontará com o IETF.

2.1 Começos modestos

A primeira reunião do IETF foi realizada em janeiro de 1986, no Linkabit em San Diego, com 21 participantes. A quarta, realizada no SRI, em Menlo Park, em Outubro de 1986, a primeira, na qual a iniciativa privada compareceu. O conceito de Grupos de Trabalho, (WGs) foi apresentado na quinta reunião do IETF, no Centro de Pesquisa AMES, da NASA, na Califórnia, em fevereiro de 1987. A 7ª IETF foi realizada no MITRE, em McLean, Virginia, em julho de 1987, então, a primeira reunião, com mais de 100 participantes.

A décima quarta reunião do IETF foi realizada na Universidade de Stanford, em julho de 1989. Ela marcou uma mudança radical na estrutura do IETF. O IAB, na época, Internet Ativities Board, e agora, Internet Architecture Board, que até então supervisionava as reuniões dos grupos (WGs) foi reorganizada em duas áreas principais: o IETF e o IRTF. O IRTF é responsável pelas pesquisas de longo prazo sobre a Internet. O IETF, também evoluiu durante este período.

Após a criação da Internet Society (ISOC), em janeiro de 1992, o IAB propôs que a ISOC assumisse suas próprias atividades. Durante a reunião do INET 92, em Kobe, no Japão, os membros do Conselho da ISOC aprovaram proposta ficando o IAB sob suas asas, a partir dai.

O IETF reuniu-se em Amsterdã, na Holanda, em julho de 1993. Esta foi a primeira reunião do IETF na Europa e a proporção de participantes dos Estados Unidos foi reduzida pela metade. A primeira reunião do IETF na Ásia foi realizada em 2000, em Adelaide, Austrália.

Atualmente, o IETF promove encontros na América do Norte, Europa e Ásia. A intenção é reunir-se uma vez por ano em cada região, mas devido a problemas de agenda, muitas vezes há mais reuniões na América do Norte e, menos na Ásia e Europa. A proporção de participantes fora dos EUA continua a ser elevado - cerca da metade, mesmo nas reuniões em solo americano.

2.2 A Hierarquia

2.2.1 ISOC (Internet Society)

A Internet Society (ISOC) é uma organização internacional, sem fins lucrativos, com o objetivo de promover o desenvolvimento da Internet. Uma das maneiras que a ISOC faz isto é por meio de apoio financeiro e jurídico aos outros grupos, chamados grupos "I", aqui descritos, particularmente, o IETF. A ISOC fornece segurança para muitos participantes envolvidos no trabalho do IETF e apoia as relações públicas, quando um dos grupos "I" tem de relacionar com a imprensa. A ISOC é um dos principais heróis anônimos da Internet.

Desde sua estréia na primavera de 2005, a ISOC tem sido a sede dos membros executivos do IETF. Isto está descrito em maior detalhe, na [BCP101]: "Structure of the IETF Administrative Support Activity (IASA)". Inicialmente, o escritório tinha apenas um Diretor Executivo (IAD) trabalhando em tempo integral para supervisionar a organização das reuniões do IETF, os aspectos operacionais dos serviços de apoio, a secretaria do IANA (Internet Assigned Numbers Authority), o Editor de RFC, conforme descrito posteriormente neste capítulo e, do orçamento. Ele ou ela (atualmente) dirige o IASA (IETF Administrative Support Activity), que lida com tarefas como recolhimento de taxas e pagamento de contas, e subsidia as ferramentas de trabalho dos grupos de trabalho do IETF, IESG, IAB e IRTF (informações adicionais sobre este assunto, mais adiante, neste capítulo).

O Comitê de Controle Administrativo do IETF (IAOC - IETF Administrative Oversight Committee) é composto de voluntários, todos escolhidos direta ou indiretamente pela comunidade IETF, bem como membros ex-ofício da ISOC e a direção do IETF. IASA e o IAD são dirigidos pelo IAOC.

O IAD e, tampouco o IAOC interferem sobre o desenvolvimento de padrões do IETF, dos quais trataremos neste texto.

2.2.2 IESG (Internet Engineering Steering Group)

O IESG é responsável pela gestão técnica das atividades do IETF e o processo de padronização da Internet. Ele administra o processo de acordo com as regras e procedimentos que foram ratificados pelo Conselho da ISOC. O IESG não tem, no entanto, a liderança visível em outros organismos de padronização. Como o próprio nome sugere, o seu papel é definir os objetivos, e não o de dar ordens. O IESG ratifica ou corrige os resultados dos grupos de trabalho do IETF, opina sobre a criação e extinção de WGs e garante a qualidade dos documentos produzidos fora dos WGs, destinados a se tornarem RFCs.

Confira as páginas da web IESG, http://www.ietf.org/iesg.html, para encontrar informações atualizadas sobre rascunhos processados, RFCs publicados, e documentos em Última Chamada (Last Call), bem como os relatórios mensais de estado do IETF.

O IESG é composto pelos Diretores de Áreas (Area Directors ou, "AD"), selecionados por um comitê de nomeação (Nominations Committee, muitas vezes chamado de "Nomcom") e nomeados por dois anos. O processo de designação dos membros do IESG é detalhado em [BCP10]: "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees".

As atuais Áreas e respectivas abreviações, são mostradas abaixo.

Area Description
Applications (APP) Protocolos visto por programas do usuário, tais como e-mail e Web
General (GEN) Processos do IETF e processos conexos a vários grupos de trabalho ou que não se encaixam em nenhuma das categorias disponíveis (o que é raro)
Internet (INT) As diferentes maneiras de rotear pacotes IPs e informações de DNS
Operations and Management (OPS) Aspectos operacionais, monitoramento e configuração de redes
Real-time Applications and Infrastructure (RAI) Comunicações interpessoais sensíveis a atrasos
Routing (RTG) Roteamento de pacotes para o seu destino
Security (SEC) Autenticação e privacidade
Transport (TSV) Serviços especiais para pacotes especiais

Pelo fato do IESG ter uma grande influência sobre a decisão de rascunhos da Internet (I-Ds) tornar-se ou não um RFC, muitas pessoas tendem a considerar o AD como um semideus. Os participantes do IETF, por vezes, dirigem-se a ele com reverência para pedir sua opinião sobre um determinado tema. No entanto, a maioria dos ADs não são diferentes, dos meros mortais e raramente se comunicam de um pedestal. Na verdade, quando se pede um parecer técnico particular, o AD muitas vezes depende dos participantes do IETF que possuem mais conhecimento do que ele, naquela área específica.

Supõe-se que os ADs conhecem como ninguém, o conjunto de trabalhos que estão sendo debatidos nos respectivos WGs da Área que lhes dizem respeito. Também, todo o IESG analisa cada I-D proposto, candidato a um RFC. Qualquer AD pode registrar um impedimento para uma proposta e retorná-la ao debate, se ele ou ela tiver sérias preocupações, a respeito. Se tais questões não podem ser resolvidas por meio da discussão, um procedimento de substituição é definido de tal forma que obrigam, pelo menos que dois membros IESG expressem suas posições antes de um projeto ser impedido de avançar. Tais procedimentos ajudam a garantir que "projeto de estimação" de um AD não retorne para o caminho de se tornar padrão se ele pode produzir um efeito negativo sobre o resto dos protocolos do IETF ou que a eventual "implicância" de um AD, por outro lado, não bloqueie indefinidamente algum projeto relevante.

Não se pode concluir, entretanto, que o IESG nunca exerce o seu poder. Quando o IESG observa que um grupo de trabalho está se afastando de regras de comportamento ou quando um grupo de trabalho pede para transformar um protocolo tosco em um RFC, o IESG reage, imediatamente. Na verdade, por causa de sua pesada carga de trabalho, o IESG muitas vezes atua reativamente. Ele aceita a maioria dos pedidos feitos pelos WGs para transformar um I-D em RFC e intervém apenas quando um problema real aparece. Por outro lado, como dizem, os ADs são eleitos para pensar e não apenas para administrar a atividade do WG. O padrão de qualidade definido pelo IETF vem dos revisores que recebem os trabalhos dos WGs e das avaliações e / ou críticas que os WGs fazem dos ADs, ao longo do tempo.

O IETF trabalha sob o critério de consenso "aproximado" e é o IESG quem decide se um WG resultou de um verdadeiro consenso. (Veja a Section 4.2 para mais informações sobre o consenso nos WGs.) Assim, uma das principais razões que podem levar IESG a bloquear o trabalho de um WG é a inexistência real de um consenso entre todos os participantes do IETF, isto é, de todos WGs, de todas as Áreas. Por exemplo, o resultado produzido por um WG pode estar em desacordo com outra tecnologia desenvolvida em um WG, talvez de uma outra área. Uma tarefa importante do IESG é garantir que o trabalho de todos os WGs não cause inconsistências entre os protocolos definidos pelo IETF. É por esta razão que o AD se preocupa em rever o que está sendo realizado nas suas respectivas Áreas.

2.2.3 IAB (Internet Architecture Board)

O IAB é responsável por manter uma visão global da Internet, além de se concentrar no planejamento e coordenação de longo prazo das diferentes áreas do IETF. O IAB é a vigilância contínua sobre as questões fundamentais da Internet e informa ao público em geral, tudo o que julgar necessário.

Os membros do IAB prestam especial atenção às atividades emergentes do IETF. Quando um novo WG é criado no IETF, o IAB verifica a integridade, coerência e consistência de sua arquitetura, definida na especificação de sua proposta de criação. Antes mesmo da especificação ser definida, os membros do IAB estão sempre disponíveis para discutir novas ideias com os propositores do WG.

O IAB também patrocina e organiza o Internet Research Task Force (IRTF), na forma de seminários, que oferecem profundidade em algumas questões relativas a estudos sobre à arquitetura da Internet. Estes seminários fazem recomendações para o IETF e o IESG.

O IAB, também::

Como o IESG, os membros do IAB são nomeados por dois anos, pelo Nomcom, e aprovado pelo Conselho da ISOC.

2.2.4 IANA (Internet Assigned Numbers Authority)

O registro central das atividades do IETF é o IANA (ver http://www.iana.org). Muitos protocolos de Internet exigem o acompanhamento de itens que são associados a estes protocolos após a sua aprovação. Os exemplos típicos de tais registros são os números de porta TCP e os tipos MIME. O IAB designou o IANA para executar tais tarefas. As atividades do IANA são apoiados financeiramente pelo ICANN (Internet Corporation for Assigned Names and Numbers). As atividades do IANA são gratuitas conforme especificado no [RFC2860].

Há 10 anos, ninguém teria imaginado um dia ver o IANA aparecer na primeira página de um jornal. O papel do IANA até então tinha sido muito pequeno. O fato de o IANA ter passado a cuidar da raíz (root) dos servidores de nomes de domínios levou-o para frente do palco, onde foi alvo de críticas injustificadas de pessoas que não tinham examinado a importância de sua verdadeira função. Hoje, o IETF não está mais atento às atividades do IANA, que passaram a ser supervisionadas pelo ICANN.

Apesar de um registro não parecer interessante, muitos participantes do IETF irão testemunhar o quão importante foi o IANA, para a Internet. Ter um repositório estável e de longo prazo geridos por operadores cuidadosos e conservadores torna muito mais fácil para as pessoas experimentar sem se preocupar em estragar as coisas. O fundador do IANA, Jon Postel, foi fortemente invocado, para manter as coisas em ordem, enquanto a Internet foi crescendo aos trancos e barrancos. Jon Postel fez um maravilhoso trabalho, até sua morte prematura em 1998.

2.2.5 O Editor de RFC

O Editor de RFC (RFC Editor), edita, formata e publica I-Ds como RFCs, trabalhando em conjunto com o IESG. Um papel secundário importante é fornecer um repositório definitivo para todos os RFCs (ver http://www.rfc-editor.org). Uma vez que um RFC foi publicado, ele nunca é revisado. Quando uma nova especificação que exige alterações é aprovada, um novo documento será publicado (com as alterações), em outro RFC, que torna "obsoleta" o RFC anterior.

Um dos equívocos mais populares na comunidade do IETF é de que o papel do RFC Editor seria realizado pelo IANA. Isto aconteceu porque, tanto o RFC Editor e IANA envolviam as mesmas pessoas durante muitos anos, embora o o trabalho do RFC Editor fosse separado. Hoje, esses esforços são realizados por organizações distintas. O IAB aprova a organização que irá atuar como RFC Editor e sua política geral. O RFC Editor é financiado pelo IASA.

Até o final de 2009, o RFC Editor era uma entidade separada. Em colaboração com os membros do IETF, o IAB tem dividido seu papel em várias funções que podem ser realizadas por diferentes indivíduos ou organizações, liderados pelo Editor de RFC nomeado pelo IAB. O modelo do RFC Editor é descrito no [RFC6635].

2.2.6 A Secretaria do IETF

Algumas poucas pessoas são pagas para cuidar do IETF. A Secretaria do IETF fornece apoio logístico do dia-a-dia, principalmente para coordenar as reuniões face-a-face e gerenciar listas de discussão específicas para o IETF. A Secretaria também é responsável pela manutenção e apresentação do diretório oficial de I-Ds, manter o site do IETF e auxiliar o IESG no cumprimento de sua missão . Ela oferece várias ferramentas a serem utilizadas pela comunidade e pelo IESG. A Secretaria do IETF está sob contrato do IASA, que por sua vez é financiado por taxas arrecadadas na participação de reuniões presenciais.

2.2.7 IETF Trust

No final de 2005, o IETF Trust foi criado para lidar com a propriedade intelectual do IETF. A razão de sua criação do IETF Trust é pelo fato de que quem deve possuir a propriedade intelectual do IETF deve ser uma entidade estável e legalmente constituída. Os curadores da IETF são oo mesmos membros do IAOC, em um determinado ponto no tempo. Poucos participantes do IETF fazem contato com o IETF Trust, o que comprova a eficácia do seu trabalho. Você pode encontrar mais informações sobre o IETF Trust em seu sítio http://trustee.ietf.org.

2.3 Listas de e-mail do IETF

Para aqueles que desejam participar de uma reunião do IETF, é fortemente aconselhado a se registar na lista de discussão de anúncios: https://www.ietf. org/mailman/listinfo/IETF-Announce. Ela fornece todas as informações sobre as reuniões e a publicação do RFC. Também são encaminhados nesta lista, os planos de ação sobre os protocolos do IESG (IESG Protocol Actions) e as últimas chamadas (Last Calls), para comentários. Àqueles envolvidos em nível técnico e que pretendam aderir ao IETF recomenda-se a lista https://www.ietf.org/ mailman/listinfo/ietf. Esta é onde se discute assuntos de importância cósmica (WGs possuem suas próprias listas para discutir questões afetas às suas atividades). Outra lista de discussão publica os I-Ds, na versão final: https://www.ietf. org/mailman/listinfo/I-D-Announce.

As inscrições para as listas acima e para qualquer outra lista do IETF é gerenciado por um programa chamado "mailman". Mailman tende a mostrar-se um pouco exigente sobre o formato das mensagens de registro. Por esta razão, recomenda-se que não envie para ele, mensagens em formato HTML, durante o registro mas, sim no formato texto (como ele gosta), oportunidade em que se mostrará bastante dócil.

As listas de discussão do IETF não são moderadas. Isto significa que todos podem expressar suas opiniões sobre questões relacionadas com a Internet. Portanto, não é de todo adequado para empresas ou indivíduos enviar mensagens de cunho ou interesse exclusivamente pessoal ou da empresa que representa. O [BCP45]: "IETF Discussion List Charter" é uma ótima leitura antes de enviar a primeira mensagem na lista de discussão. Na verdade, cada lista contém dois "sargentos de armas" que monitoram itens inadequados, e existe um processo para excluir os infratores, felizmente, raríssimo de acontecer.

Apenas a secretaria e alguns líderes do IETF podem aprovar mensagens enviadas com anúncios, mesmo que essas mensagens venham de diversas pessoas.

Mesmo que as listas de discussão "aparentem" pertencer aos participantes do IETF em geral, é importante observar que, participando de uma reunião IETF não significa que será automaticamente adicionado a qualquer lista de discussão. É necessário registrar-se!


3. Reuniões do IETF

A indústria de computadores está repleta de conferências, seminários, exposições, e toda sorte de outros tipos de reuniões. As reuniões presenciais do IETF não são como essas. As reuniões, realizadas três vezes por ano, é de uma semana onde ocorrem "encontros de tribos", cujo principal objetivo é revigorar os WGs para considerar suas tarefas prontas, e cujo objetivo secundário é o de promover uma boa quantidade de mistura entre os WGs e as Áreas. O custo das reuniões é pago pelas pessoas presentes e pelo acolhimento empresarial de cada reunião (se houver), embora IASA entre em recursos adicionais para as coisas tais como a transmissão de áudio, em algumas sessões do Grupo de Trabalho.

Para muitas pessoas, as reuniões do IETF representam uma lufada de ar fresco em comparação com as conferências da indústria de computadores. Não há sala de exposições, pouco trabalho prático, e nenhuma indústria de renome. Há sim um monte de trabalho e um monte de tempo para reuniões informais dos participantes. As reuniões do IETF são de pouco interesse para os especialistas comerciais ou de marketing, uma vez que são destinadas a engenheiros e desenvolvedores.

Geralmente, uma reunião do IETF começa com o trabalho prático e um encontro informal no domingo, seguido por reuniões de grupos de trabalho e BoFs, de segunda a sexta-feira. As reuniões dos WGs ocupam entre 1:00 e 2:30 cada uma, e alguns grupos de trabalho fazem várias reuniões durante a semana, dependendo da quantidade de trabalho a desenvolver.

Há duas sessões plenárias, uma técnica e outra administrativa à noite, durante a semana. A reunião plenária técnica é organizado pelo IAB e, normalmente, tem um ou dois painéis de especialistas abordando temas de interesse para muitos grupos de trabalho e áreas. Reunião plenária administrativa é organizada pelo Presidente do IETF e abrange elementos tais como relatórios de progresso, editor de RFC e anúncios relacionados às próximas reuniões. As sessões plenárias são um bom momento para compartilhar com o IESG e IAOC. O elogio é bem-vindo mas, mais frequentemente, preocupações e reclamações é que são levantadas.

Atualmente, o IETF reúne-se na América do Norte, Europa e Ásia, cerca de uma vez por ano em cada região. As últimas reuniões foram assistidas por cerca de 1.200 participantes. Foram mais de 80 reuniões IETF até hoje e uma lista de próximas reuniões está disponível em http://www.ietf.org/ meeting/upcoming.html.

Novos participantes a um encontro presencial do IETF recebem o impacto da surpresa. Eles esperam que ela se desenrole como um corpo de padronizadores ou como uma conferência de computador. Felizmente, depois de um dia ou dois, a surpresa dá lugar ao entusiasmo, gerado pelo lado agradável do evento. Por outro lado, os participantes do IETF podem ser, também, surpreendentemente rudes, às vezes levantando a voz durante uma apresentação no micro ou correndo no meio da multidão atenta à comida ou bebidas. Este tipo de comportamento anti-social parece ser mais comum durante as reuniões do IETF do que em conferências de informática.

3.1 Inscrição

Para participar de uma reunião IETF, você tem que se inscrever e pagar a taxa de inscrição. O local da reunião e da inscrição antecipada são anunciados cerca de dois meses antes da reunião - antes, se possível. Um anúncio sai via e-mail para a lista de discussão IETF-Announce, e a informação é postada no sítio do IETF: http://www.ietf.org, nesse mesmo dia.

Você pode se cadastrar e pagar na Web antes da reunião, ou pessoalmente na reunião. Para receber o desconto, o registro deve ser feito antes de um prazo (cerca de uma semana antes da reunião). A taxa de inscrição inclui o acesso a todas as reuniões da semana, a recepção de boas vindas na noite de domingo (bebidas não são cobertas), pequenos almoços e as paradas para café (coffee breaks), durante a tarde.

As inscrições estão abertas durante toda a semana da reunião. No entanto, a Secretaria aconselha aos participantes a fazê-la na abertura do registro, o que geralmente ocorre a partir de domingo meio-dia até o final da tarde um pouco antes do início da recepção de abertura. A recepção é um momento popular durante o qual você pode fazer um lanche e conhecer as primeiras pessoas que chegam.

É importante notar que informação sobre os participantes ou listas nunca são vendidos.

Antes de se inscrever, visite a página intitulada "Note Well" (note bem). Leia-a atentamente. Lá estão as normas relativas aos direitos de propriedade intelectual do IETF.

Se precisar de deixar mensagens para outros participantes, poderá fazê-lo nos quadros de avisos que estão próximos da recepção. Nesses quadros também aparecem avisos de alterações de última hora e mudanças na hospedagem, entre outros.

Objetos encontrados podem ser deixados na recepção. No final da reunião, tais objetos, não reclamados são geralmente entregues ao hotel ou devolvidos à secretaria.

Além disso, o local de registro das reuniões do IETF é frequentemente utilizado como um ponto de encontro. Se alguém lhe pede para encontrá-lo na recepção, pergunte se é no IETF ou no balcão de registro do hotel. Muitas oportunidades são perdidas devido à falta de precisão.

3.2 Mergulhe-se no IETF e fique a semana toda!

As reuniões dos WGs, no IETF estão programadas a partir de segunda-feira até sexta-feira à tarde. Outras reuniões que não os WGs são frequentemente realizados em formatos semanais, antes ou depois. É preferível estar presente durante toda a semana para apreciar os intercâmbios entre os WGs e as discussões informais. Você verá a seguir, que o programa é simples. Muitos dos participantes que perdem reuniões importantes por causa de alterações de última hora, que ocorreram após a programação de sua viagem. Estar presente durante toda a semana é a única maneira de evitar isso.

Se não encontrar reuniões interessantes ao longo da semana, poderá sempre aproveitar ao máximo a reunião IETF trabalhando entre as sessões. Muitos participantes do IETF levam seu laptop e não é raro ver vários deles na sala de terminal ou nos corredores durante as reuniões de trabalho. Há, muitas vezes, uma boa cobertura de Internet sem fio em muitos lugares que possuem espaço para reuniões informais (restaurantes, cafés, etc.). Leitura de e-mail tornou-se uma prática comum entre os participantes do IETF.

3.3 Treinamento para os novatos

Os novatos são encorajados a participar da reunião de orientação na tarde de domingo, especialmente concebida para eles. Esta reunião de orientação é organizada pela equipe EDU IETF, que transmite as informações úteis e em primeira mão. O encontro aborda temas como o significado das bolas coloridas sobre os crachás, a estrutura dos outros elementos essenciais IETF e muitas outras dicas úteis para os iniciantes no IETF.

No final da tarde há uma recepção de boas-vindas exclusivamente para os recém-chegados e os presidentes dos WGs. Este é um ótimo lugar para encontrar pessoas certas nas áreas de seu interesse. Não hesite em pedir a um presidente de um WG, não necessariamente o da área de interesse, para conhecer mais sobre um determinado WG ou para receber ajuda na procura de alguém que pertença a ele.

3.4 Código da vestimenta (ou, Como se vestir?)

Uma vez que os participantes devem usar seus crachás com seu nome, espera-se que vistam camisetas ou blusas. Calças ou saias também são altamente recomendadas. Mais grave ainda, muitos participantes que chegam pela primeira vez têm vergonha de chegar em trajes de segunda-feira de manhã, quando eles descobrem que todo mundo está de camisetas, jeans (ou bermuda, se o tempo o permitir), e sandálias. Há claro, participantes que se recusam a usar algo diferente do seu habitual. Felizmente, eles serão perdoados por este particularismo a favor do reconhecimento do seu trabalho. A regra geral é vestir-se para o clima, a menos que você pretenda trabalhar tão duro que irá permanecer enclausurado. Neste caso a regra que se aplica é "vista-se como em casa!"

3.5 Reuniões dos Grupos de Trabalho

O coração de um encontro do IETF são reuniões dos WGs. Os presidentes dos diferentes WGs, cada um com seu próprio estilo, tornam impossível generalizar como uma reunião de um WG ocorrerá. Embora quase todos os grupos possuam agenda de trabalho, alguns a seguem firmemente, enquanto outros agem livremente.

Existem alguns elementos importantes que são verdadeiros para todas as reuniões dos WGs, nos encontros do IETF. No início da reunião, o presidente distribui as chamadas, "fichas azuis", onde cada participante coloca o nome e endereço de e-mail. Elas são arquivadas e usadas para determinar o número de participantes naquela reunião, e em casos raros, ser capaz de identificá-los. Geralmente, você tem de olhar para onde estão seguindo as folhas azuis e ir na mesma direção.

Para falar em uma reunião, você deve ir aos microfones colocados na sala. Nos temas controversos, as pessoas estarão enfileiradas ao microfone, mas não hesite em ser o primeiro, se você tiver uma pergunta ou uma contribuição a dar para a discussão. O presidente do grupo de trabalho ou apresentador irá dizer quando você poderá falar. Embora seja mais fácil simplesmente levantar as mãos no lugar que está sentado, os microfones são muito úteis e permitem que os participantes remotos e, também, os presentes na sala ouçam suas perguntas ou comentários. Lembre-se também de informar seu nome antes de intervir, para permitir à pessoa que escreverá o relatório do WG saiba com quem está falando.

3.6 Significado dos pontos diante de seus olhos

Algumas pessoas, durante o IETF possuem um pequeno ponto de cor em seu crachá. Apenas uma pequena minoria tem vários pontos. Estas pelotas identificam aqueles que são loucos o suficiente, para doar muito trabalho extra. As cores possuem os seguintes significados.

Cor Significado
Azul Presidente de um WG/BOF
Verde Grupo acolhedor
Vermelho Membro do IAB
Amarelo Membro do IESG
Laranja Membro do Comitê de Nomeação (NomCom)
Violeta IAOC
Rosa IRSG
Verde azulado RSE

(Jornalistas usam crachás em laranja.)

Pessoas do grupo acolhedor são aquelas que podem responder sobre sala de terminal, restaurantes e pontos de interesses na área do evento.

É importante, quando estiver em sua primeira vez, não hesitar em conversar com as pessoas que usam estes emblemas coloridos. Se os membros do IAB, do IESG e os presidentes dos WGs não quisessem se comunicar, não estariam usando estes emblemas em destaque. Note, porém, que as reuniões do IETF são, geralmente, momentos intensos para os gestores de áreas (ADs). Se você conversar com um AD durante uma reunião do IETF, na maioria dos casos ele irá pedir para lhe enviar um e-mail cerca de duas semanas mais tarde. Da mesma forma, quando você começa uma conversa informal com um AD (ou mesmo um presidente de WG para qualquer assunto), muitas vezes é bom dar-lhes cerca de 30 segundos para que possam se situar no contexto da conversa.

3.7 Sala de Terminal

Uma das coisas essenciais (dependendo do seu ponto de vista) que o acolhedor fornece é o acesso à Internet a todos os participantes. Em geral, conectividade sem fio é excelente em todas as salas e áreas públicas, mas cabo de energia está disponível na sala do terminal. Todas as pessoas e empresas que fornecem equipamentos, serviços e tempo merecem calorosos agradecimentos e cumprimentos.

Mesmo sendo as reuniões preparadas com antecedência, pode haver trabalho inesperado, de última hora. A sala de terminal é o local adequado. Ela, também pode ser usada para preparar um relatório ou um relato da reunião, enquanto as coisas ainda estão frescas em nossas mentes.

É necessário o crachá, para entrar na sala de terminal. A sala de terminal fornece filtros de linha, portas Ethernet para laptops, rede sem fio (para as pessoas que não precisam de Ethernet), geralmente, uma impressora de uso público e, por vezes, estações de trabalho. O que não há na sala são os terminais - o nome é histórico. O balcão de ajuda, na sala de terminal é um bom lugar para fazer perguntas sobre falhas de rede, embora possam indicar outras pessoas para resolver o problema ou para reclamar.

3.8 Alimentos e outros prazeres

Marshall Rose observou uma vez, que o IETF era um lugar para "muitos almoços e jantares finos". Embora seja verdade, que algumas pessoas comem muito bem no IETF, o fazem por conta própria. Almoços e jantares não estão incluídos na taxa de inscrição. A Secretaria organiza aperitivos no domingo à noite, recepção de boas vindas (não pretende ser um substituto para o jantar), café da manhã continental de segunda-feira a sexta-feira, de manhã (dependendo do local da reunião) e, o melhor de todos: os "cookies", "brownies", frutas e outras delicias, durante alguns dos intervalos da tarde. Esses são muitas vezes pagos pelo organizador ou patrocinador do encontro.

Se preferir sair do hotel para as refeições, o acolhedor, geralmente fornece uma lista de lugares para comer a uma curta distância do local do encontro.

3.9 Evento Social

O evento social do IETF é outro aspecto importante dos serviços prestados pela organização acolhedora. Pode ser um evento relacionado a tecnologia, pode ser em um museu de arte ou uma recepção. Observe, entretanto, que nem todas as reuniões da IETF oferecem o evento social.

O IETF incentiva a participação dos novos membros no evento social. Recomenda-se usar o crachá e deixar seu laptop para trás. O evento social foi concebido para permitir que as pessoas se reúnam de uma maneira amigável, fora do contexto técnico.

3.10 Agenda

O calendário de reuniões do IETF é muito flexível. Ele está disponível na Web algumas semanas antes da reunião. Resumo da agenda está disponível na recepção para aqueles com boa visão e queiram manter uma cópia em seu bolso ou na parte de trás do seu crachá. Obviamente, "final" não tem o mesmo significado no IETF do que em qualquer outro lugar do mundo. O programa final significa, simplesmente, a liberação enviada para a impressora. A secretaria irá programar mudanças em quadro perto da recepção (da reunião, e não do hotel). Essas mudanças tardias, não são sensíveis aos participantes: elas são feitas, "just in time", já que os presidentes e as partes interessadas demoram para passar as informações. O IETF é muito dinâmico, contrapondo-se a programas planejados e definidos com semanas de antecedência.

Uma planta do local da reunião e, as respectivas salas, também constam da agenda. A alocação das salas pode afetar a agenda e provocar alterações. Alguns WGs se reúnem várias vezes por semana e, na medida do possível será alocada uma sala permanente para eles, durante toda a semana.

3.11 EDU salvando a pátria

Se você ainda tiver dúvidas sobre certos aspectos da IETF (mesmo depois de ler o Tao), deverá ficar atento à solução de treinamento, proposta pela equipe de educação (EDU). Estas atividades dirigem-se, tanto aos novatos, quanto aos antigos participantes do IETF. Além do treinamento para iniciantes, a equipe EDU oferece pequenos seminários para ensinar como escrever documentos, para presidentes de WGs, além de tutoriais de segurança essenciais aos novos e antigos membros do IETF. Os cursos do EDU são, geralmente realizadas aos domingos à tarde. Você pode encontrar mais informações sobre o trabalho e a equipe EDU em http://www.ietf.org/edu/.

3.12 Onde é o meu lugar?

O IETF não significa o mesmo para todos. Muitas pessoas são ativas sem nunca terem participado de uma única reunião. Você não deve se sentir obrigado a vir a uma reunião só para ter uma ideia do IETF. As informações que seguem (com base em uma classificação de agentes do setor) podem ajudá-lo a decidir como usar melhor o seu tempo, quando da primeira vez, no IETF.

3.12.1 Gerentes industriais

Como mencionado acima, uma reunião do IETF não é comparável a feiras profissionais que você conhece. As reuniões IETF são o último lugar em que você deverá ir, se sua intenção é descobrir quais serão os próximos desafios industriais da Internet. Em vez disso, assistir ao trabalho dos WGs só irá tornar mais confuso o cenário atual e o futuro da indústria.

Isso não quer dizer que os atores do setor industrial não tenham espaço nas reuniões do IETF. Para o gerente industrial, pode ser apropriado conhecer as tecnologias por trás do esforço de desenvolvimento, no IETF. Se consultar o trabalho em andamento (I-Ds) e participar nas listas de discussão dos WGs de interesse, os participantes serão capazes de indicar como sua presença será importante para a empresa ou para os próprios WGs.

3.12.2 Operadores de rede e provedores de acesso à Internet

Gestão de redee é complexa, o suficiente sem que tenhamos de lidar com novos protocolos ou novas versões de protocolos com os quais você está familiarizado. Se você trabalha com tipos de redes que requerem desenvolvimento constante, máquinas mais poderosas e software e, ainda se você segue, sistematicamente, os WGs associados a este seu trabalho, certamente irá considerar as reuniões do IETF muito importantes. Grande parte do trabalho do IETF, também aborda diversos outros aspectos da operação de provedores de Internet, de pequenas, médias e grandes empresas. A contribuição das operadoras é muito valiosa para tornar o trabalho dinâmico e relevante. A maioria dos documentos de qualidade no IETF vem da contribuição dos operadores e não de prestadores ou acadêmicos.

3.12.3 Produtores de hardware e software de rede

A imagem do IETF, diante de algumas realidades do passado, era vista por alguns acadêmicos, como uma torre de marfim. Entretanto, hoje a maioria dos participantes são da indústria. Na maioria das áreas do IETF são os funcionários dos produtores que escrevem protocolos e animam os WGs. Se você é ou representa um fabricante de hardware ou software para a Internet e sua empresa nunca participou de uma reunião IETF, cabe a você participar e constatar, o quanto as reuniões são relevantes para o negócio de sua empresa.

Isto não significa que as empresas interessadas devam fechar as portas durante a semana de reunião do IETF para que todos seus funcionários participem. O pessoal de marketing e até mesmo aqueles do marketing técnico não precisam participar, ao contrário do pessoal efetivamente técnico. Não é, realmente, oportuno enviar toda a equipe de um departamento técnico, considerando que nem todos leem os documentos ou não seguem os WGs em suas listas de discussão. A maioria das empresas escolhem algumas pessoas com base na sua capacidade de fornecer relatórios detalhados e registros valiosos de sua participação. Além disso, muitas empresas têm métodos de coordenação interna e estratégia de padronização. Uma empresa que depende da Internet para realizar alguns ou todos seus negócios, certamente participará intensamente do IETF.

3.12.4 Mundo acadêmico

As reuniões IETF são muito úteis para o pessoal da área de computação interessados, principalmente, nas novidades sobre protocolos, que estão acabando de sair do forno. Professores e alunos de pós-graduação que realizam suas pesquisas na área de rede e comunicação de dados terão oportunidadee de conhecer uma riqueza de informações e conhecimento ao participarem nos WGs relacionados. Caminhando de um WG para outro será tão gratificante como ir a um simpósio ou seminário dentro de seu departamento. Os pesquisadores, também, se interessarão pelas atividades do IRTF.

3.12.5 Imprensa especializada

Se você é membro da imprensa e quer participar do IETF, nós preparamos uma seção especial só para você Tao - Veja Section 8.2.

3.13 Anais

Os anais do IETF são compilados no prazo de dois meses após cada reunião e disponibilizados na web. Não perca - eles contêm informações sobre o IETF que não encontrará em nenhum outro lugar. Por exemplo, você encontrará as especificações mais atualizadas dos WGs, em vigor na data da reunião, para entender melhor a evolução do trabalho executado.

Os anais iniciam com um editorial esclarecedor (e muito divertido). Cada edição contém a agenda final (retrospectivamente atualizada), uma apresentação do IETF, relatórios de atividades de trabalho de Área e de grupo, bem como apresentações de "slides" e protocolos técnicos. Apresentações e relatórios dos WGs são, por vezes, incompletos enquando os documentos não foram entregues, a tempo, de serem publicados, pela secretaria.

Os relatórios também contêm a lista de participantes com seu nome e endereço, como inseridos no formulário de inscrição. Para informações sobre como obter uma cópia dos relatórios, acesse o endereço http://www.ietf.org/meeting/proceedings.html.

3.14 Outros temas gerais

Os membros da IETF são, geralmente, facilmente acessíveis. Não hesite em se aproximar deles e se apresentar. Além disso, não tenha medo de fazer perguntas, especialmente se for para entender o jargão e acrônimos.

Conversas informais são muito importantes. Uma parte significativa do trabalho é feito de forma bastante eficaz por pessoas que conversam entre as reuniões ou durante o almoço e jantar. A cada minuto o IETF pode ser considerado um trabalho (para o desgosto de alguns).

Reunião paralela (historicamente, mas incorretamente chamado de "bar BOF") é um encontro informal entre os participantes dos WGs, no final da noite, durante a qual se trabalha muito. Tais "bar BOF" surgem em restaurantes, cafés, em espaços não utilizados e, ao redor da piscina (se você tiver sorte).

É desaconselhável ficar entre um participante com fome (que frequentemente é o caso) e os "brownies" e biscoitos que servem durante a pausa para o café, independentemente do interesse da conversa. Steve Coya, o primeiro Diretor Executivo do IETF, costumava dizer: "Pegue seu biscoito e caia fora".

Os membros do IETF são ferozmente independentes. Ao pedir uma opinião, ofereça alternativas e não espere que eles sigam ordens.

As reuniões do IETF, em particular, a sessão plenária, não são lugares para vendedores tentarem vender seus produtos. As pessoas podem, certamente, responder a perguntas sobre a sua empresa e seus produtos, mas tenha em mente que o IETF não é uma feira de negócios. Mais sucesso teria se tentasse vender produtos relacionados com o IETF, tais como camisetas, botões e protetores de bolso.

Há sempre uma mesa para a distribuição de materiais junto da recepção. Esta documentação inclui toda a informação relevante para os participantes (por exemplo, uma cópia do trabalho atual em um WG ou uma descrição do conteúdo disponível no site do IETF). Por favor, consulte a secretaria, antes de disponibilizar suas informações. A secretaria reserva-se no direito de remover qualquer material considerado impróprio.

Se você usar seu laptop em reuniões, pense em levar uma bateria extra. Nem sempre é fácil encontrar uma tomada disponível em algumas salas de reuniões e o acesso sem fio descarrega a bateria mais rápido do que você imagina. Se estiver sentado próximo a uma sala de reuniões será obrigado a ligar e desligar os equipamentos de seus vizinhos. Algumas pessoas trazem uma extensão com uma régua de energia, o que representa uma boa maneira de fazer amigos em uma reunião. Se você precisar de um adaptador, tente comprar com antecedência, no lugar mais fácil de encontrar: seu país de origem.


4. Grupos de Trabalho

Grande parte do trabalho realizado no IETF acontece nos WGs. Até a data em que este texto foi escrito eles eram em número de 115. A [BCP25], "IETF Working Group Guidelines and Procedures" é, uma excelente referência a qualquer pessoa envolvida ou que queira se envolver nos debates de um WG.

Um grupo de trabalho nada mais é do que uma lista de e-mail moderada. Você participa de um grupo de trabalho, registrando-se em uma lista. Todas as listas são públicas. Algumas delas só exigem que os usuários se registrem, antes de postar mensagens. Outras estão abertas a contribuições externas, não sendo necessário o registro. Cada grupo de trabalho é liderado por um ou dois (raramente três), presidentes.

Mais importante ainda, cada grupo de trabalho tem uma especificação que deve ser respeitada. Esta especificação estabelece o escopo e os objetivos do grupo. A lista de discussão de um grupo e os encontros presenciais devem manter o foco definido na especificação fugindo do envolvimento com outros temas, muitas vezes, fascinantes. Um olhar de vez em quando, para fora da especificação pode ser útil, mas a grande maioria das discussões deve se restringir aos assuntos identificados na especificação. De fato, alguns WG, não hesitam em incluir na especificação, o que não será discutido evitando, assim as ideias tentadoras. As especificações de todos os WGs é uma leitura interessante, pois permite conhecer as atividades de outros grupos em andamento, para eventualmente, participar.

4.1 O trabalho dos presidentes de grupos

O papel dos presidentes dos grupos de trabalho é descrito nas [BCP11] e [BCP25].

Como voluntário, a principal tarefa de um presidente é determinar os objetivos e medidas de consenso do WG mantendo em dia, as especificações. Então, muitas vezes, com a ajuda dos secretários o presidente administra as discussões, tanto na lista, com nas reuniões convocadas (se necessário). Algumas discussões tendem ao infinito e cabe ao presidente adequar o debate a uma interação proveitosa. Diz-se que se não houver um consenso, o melhor a fazer é acabar com a discussão. Muitas vezes, os presidentes realizam entendimentos com não-participantes do WG ou com membros do IESG, especialmente quando se aproxima a data de publicação de um documento. Os presidentes são responsáveis ​​pela qualidade técnica e não técnica dos resultados do WG. Como você pode imaginar, dada a variedade de demandas administrativas, técnicas e interpessoais, presidentes dos WGs são mais, ou menos confortáveis, ​​do que outros, no seu trabalho.

Os presidentes de WGs são fortemente aconselhados a participar de um treinamento sobre liderança em WGs, que geralmente acontece no domingo que antecede a reunião do IETF. Também, geralmente os presidentes se reunem no meio da semana durante um almoço, com o objetivo de discutir temas específicos e direcionados a tornar seu trabalho mais confortável. Se você está interessado no que eles debatem nesta reuniões, dê uma olhada nos slides disponíveis em http://edu.ietf.org.

4.2 Progressos em um WG

Um fato que intriga os novatos é que as reuniões presenciais de um WG são muito menos importantes no IETF do que seriam na maioria das outras organizações. Qualquer decisão tomada em uma reunião presencial, também, deve ganhar consenso na respectiva lista de discussão. Existem inúmeros exemplos de decisões importantes tomadas em reuniões de WG, que são posteriormente derrubadas na lista de discussão, muitas vezes, porque alguém que não pôde comparecer à reunião apontou uma falha grave na lógica usada para chegar à decisão. Por outro lado, as reuniões do WG não são sessões para elaboração de I-Ds, como o são, em alguns outros organismos de padronização: no IETF, a elaboração de I-D é feita em outro local.

Outro aspecto nos WGs que confundem muitas pessoas é o fato de que não existe o voto formal. A regra geral sobre os temas em disputa é que o WG para chegar ao "consenso aproximado", o que significa que uma grande maioria das pessoas deve concordar. O método exato de determinar um consenso aproximado varia de WG para WG. Às vezes, o consenso é determinado por um "zumbido" — se você concorda com a proposta, emita um zumbido, assim que solicitado pelo Presidente. Na maioria das questões, os zumbidos acontecem em duas etapas: você zumbe para na primeira etapa, caso concorde com a proposta, ou zumbe na segunda etapa se você não concordar com a proposta. Os novatos acham este comportamento bastante peculiar, mas funciona. Cabe ao presidente decidir quando o WG chegou ao consenso aproximado.

A falta de votação formal tem causado longos atrasos para algumas propostas, mas a maioria dos participantes do IETF são testemunhas de que o consenso aproximado após debates cáusticos, muitas vezes resultam em melhores protocolos. (E, se pensar sobre isso, como você poderia ter "voto" em um grupo que convida todas as pessoas interessadas em participar, sendo impossível contar os participantes?). Consenso aproximado tem sido definido de muitas maneiras. Uma versão simples é que as objeções fortemente arraigadas devem ser debatidas até que a maioria das pessoas convença a si mesmas, de que tais objeções estão erradas.

Um problema relacionado é que algumas pessoas pensam que as suas propostas devem ser discutidas no WG, mesmo quando os Presidentes do WG não queiram. Por exemplo, se o trabalho proposto não está conforme as especificações os Presidentes do WG podem restringir a discussão da proposta, a fim de manter o WG focado no trabalho essencial. As pessoas que pensam que um WG deve aceitar um tema que é considerado fora das especificações pelos Presidentes, então que levem para o AD responsável. O AD pode concordar em incluir o tema na especificação, ou admitir que o tema está na especificação, ou mesmo, concordar que os presidentes do WG estão corretos e, ainda, se o(s) participante(s) deve(m) trabalhar sobre a proposta, fora do WG em questão.

Quando um documento de um WG foi examinado cuidadosamente, ele segue para uma revisão final no chamado WGLC (Grupo de Trabalho Last Call). É para o WG, a oportunidade de ver o documento ser avaliado pela última vez (espera-se). Às vezes a avaliação do WGLC sobre o documento é tão negativa, que se pode exigir um segundo WGLC para reanalisar o documento. Não existem regras formais para a realização de um WGLC, ou mesmo se WGLC é necessário: cabe aos presidentes dos WG decidirem.

Outra abordagem usada por alguns WG é adotar a figura de um "secretário" para lidar com o malabarismo dos documentos e suas respectivas mudanças. O secretário pode tratar o acompanhamento das questões, se necessário, ou, simplesmente, garantir que todas as decisões da lista de discussão tenham sido relatadas nas novas versões do documento.

Quando um grupo de trabalho cumpre os objetivos definidos na sua especificação supõe-se que suas atividades devem ser suspensas. (A maioria das listas de discussão continuará a existir após o fim de um grupo de trabalho, sempre tratando do mesmo assunto). No IETF, o fechamento de um grupo é sinônimo de sucesso, o que significa ter cumprido sua missão proposta na especificação. Este é um dos aspectos mais confusos para quem participa do IETF tendo como experiência a participação em outros organismos de padronização. No entanto, acontece que alguns presidentes de WGs não conseguem finalizar seus respectivos WG ou deixam de adicionar novas ações na especificação, neste caso, prolongando a vida do grupo por vários anos (em alguns casos, décadas). Os resultados produzidos por tais grupos mais antigos são menos relevantes do que eram no início e determinam uma aparência por vezes turva, fixando um comportamento que se convencionou chamar de "síndrome da degeneração do WG".

4.3 Documentos do Grupo de Trabalho

Há uma distinção oficial entre os documentos denominados rascunhos de WG e rascunhos independentes. Mas, na prática, esta diferença nem sempre é visível. Por exemplo, muitas listas de discussão de WGs, também, discutem rascunhos independentes (a critério do presidente do WG). Os presidentes de WGs chegam a tomar decisões sobre rascunhos que se tornarão rascunhos de WG. Você, os autores ou editores desses rascunhos, usualmente serão consultados, na lista de discussão do WG. Às vezes do AD da Área afeta ao WG, também é consultado. Este processo pode ser complicado, nos casos em que muitas pessoas desejam ser o autor de um rascunho e, mais complicado, se ninguém quer ser o autor do rascunho, que está perfeitamente adequado à especificação do WG. O procedimentos para I-D, abordados acima, serão detalhado mais à frente neste documento.

Alguns WGs possuem documentos complexos ou conjuntos de documentos complexos (ou ambos). Corrigir todos os erros nesses documentos não é uma tarefa fácil. Para resolver este problema, alguns WGs servem-se dos chamados "rastreadores de problemas", os quais são relações das questões em aberto sobre os documentos, o estado do problema, as correções propostas, etc. O uso de um "rastreador de problema" permite que o WG não se esqueça de nada importante e, também mantenha o controle preparando-se para esclarecer porque algo foi feito de uma determinada maneira.

O editor de documentos do WG está sujeito aos caprichos do Presidente. É comum que haja mais de um editor de documentos, principalmente, quando existem documentos complexos. O editor tem de assegurar-se de que o conteúdo do documento siga decisões do WG, especialmente na criação de um novo protocolo ou extensão. Se um editor não respeitar o consenso do WG, o presidente sente-se na obrigação de fazer as alterações adequadas ou, substituir o editor por alguém mais sensível à expectativa dos participantes do WG. Durante o desenvolvimento de um documento, os participantes fazem sugestões usando a lista do WG. Os editores devem, portanto, estar atentos aos movimentos da lista e providenciar alterações naquilo que houver um acordo.

Se um participante faz contribuições significativas, o editor ou o presidente pode convidar este participante para ser tornar co-autor ou co-editor desse documento. Esta mudança deve ser aprovada pelo(s) presidente(s) do WG. Na realidade, um WG precisa avaliar um conjunto de alternativas antes de considerar um documento como sendo o I-D oficial. O presidente determina quem será ou serão os autores listados na página inicial do documento e, também, quais os participantes deverão receber os agradecimentos no corpo do documento, com base em sua efetiva participação.

Quando um documento está pronto para seguir para além do WG, o(s) presidente(s) irá(ão) designar um "pastor" para assumir o processo final. O papel do pastor do documento é descrito no [RFC4858].

4.4 Preparando-se para as reuniões de Grupos de Trabalho

A coisa mais importante que todos deveriam fazer (novatos e especialistas temporários), antes de ir a um encontro face-a-face é ler antecipadamente os I-Ds e RFCs, do WG escolhido. Reuniões de WG não são, exatamente, sessões de treinamento: são reuniões para desenvolver os documentos do grupo. Mesmo se não tiver a intenção de intervir na reunião, você deve ler, ou, pelo menos, analisar os documentos antes das reuniões. Desta forma entenderá o que está sendo discutido.

O presidente do WG é responsável pela definição da agenda da reunião, em princípio, com algumas semanas de antecedência. Se você desejar abordar um assunto na reunião, informe-o ao presidente do WG. As agendas de todas as reuniões do WG estarão disponíveis, antecipadamente, no sítio do IETF, embora haja alguma negligência (se não, negligência total), quando se trata de comunicar aos interessados.

A secretaria planeja os horários das reuniões do WG com poucas semanas de antecedência. Como ela depende de informações de terceiros, pode haver pequenas alterações, geralmente, uma semana antes de começar. Portanto, se depender destas informações para planejar voos, hotel, etc. fique atento, a eventuais mudanças no cronograma dos WGs que lhe interessam. Provavelmente, você não irá ao encontro do IETF somente para participar de um WG. Finalmente, vale lembrar que sua participação nos WGs será eficaz e útil para todos os participantes, se você estudou, com antecedência, os respectivos I-Ds e RFCs.

Se você está na agenda, para falar em encontro face-a-face, provavelmente trará alguns slides através dos quais irá se comunicar com os presentes. Não leve, entretanto, um tutorial, pois não terão paciência de lhe dar atenção. Presuma que seus ouvintes, já leram os I-Ds e RFCs, relacionados. Em todas as salas de reuniões encontrará disponíveis, os recursos para sua apresentação, compatíveis com seu laptop.

E aqui vai uma dica para a sua apresentação em WGs ou em sessões plenárias: não coloque o logotipo da empresa nos slides, mesmo que seja uma prática comum fora do IETF. Os participantes do IETF, não veem com bons olhos, este tipo de publicidade (exceto para o patrocinador, na reunião plenária de apresentação). A maioria dos apresentadores nem sequer colocam o logotipo no slide de abertura. O IETF está interessado em conteúdo técnico, e não no proselitismo corporativista. Os slides são, em sua maioria, em preto e branco, contribuindo para legibilidade objetiva e, cores são usadas, apenas para tornar a apresentação mais clara. Mais uma vez, o conteúdo é o mais importante elemento dos slides e, não a forma como eles se apresentam visualmente.

Uma coisa que será útil, e possivelmente, divertido, durante as sessões do WG é seguir os comentários em tempo real, em uma sala do Jabber, associado ao WG. Estes comentários são frequentemente utilizados como base para a ata da reunião, mas também pode incluir piadas, suspiros e outras conversas paralelas. O Jabber é uma tecnologia XML "streaming" usado principalmente para mensagens instantâneas. Você encontrará referências de clientes Jabber para muitas plataformas em http://xmpp.org/xmpp-software/clients. As salas de bate papo do Jabber tem o nome do WG, seguido de "@jabber.ietf.org". Essas salas estão, de fato, disponíveis durante todo o ano e, não apenas durante as reuniões do IETF, e algumas são usadas ​​pelos participantes do WG ativo, durante o desenvolvimento do protocolo.

4.5 Lista de Discussão do Grupo de Trabalho

Como mencionado anteriormente, as listas de anúncio e as listas de discussões são essenciais para as atividades do IETF. No entanto, existem várias outras listas relacionadas com o trabalho do IETF. Por exemplo, já é conhecido o fato de que cada WG tem a sua própria lista de discussão. Além disso, há discussões técnicas de longa duração, que são transferidas das listas do IETF para listas criadas, especificamente, para tratar destes temas. É altamente recomendável, que você siga as discussões nas listas de discussão de WGs, dos quais deseja participar. Quanto mais você trabalhar nas listas dos WGs, menos trabalho terá para fazer nas reuniões, propriamente ditas. Desta forma, durante as reuniões presenciais, poderá dedicar-se a um relacionamento mais próximo e ortogonal, com os participantes (o que lhe permitirá ampliar as perspectivas seus interesses pessoais, de conhecimento, além das fronteiras do debate estreito, do WG).

As listas, também, proporcionam um fórum para aqueles que desejam seguir, ou contribuir para os esforços dos WGs, mas não podem assistir às reuniões do IETF. É por isso que os procedimentos do IETF exigem que todas as decisões sejam confirmadas "na lista", e você ira ouvir, muitas vezes, um presidente de WG dizer: "Vamos levá-lo para a lista" para fechar a discussão.

Muitas listas de discussão do IETF usam o "mailman" ou o "Majordomo". Eles geralmente possuem um endereço, "request-", que disponibiliza algumas funções administrativas, do tipo entrar e sair da lista. (Veja Section 2.3 para maiores informações sobre mailman). Os membros das listas não aprovam, geralmente, quando solicitações de saída ou de entrada são postadas nas listas.

Todas as listas de discussão do IETF são arquivadas. Ou seja, todas as mensagens enviadas para uma lista são automaticamente armazenadas em um servidor HTTP ou FTP, anônimos. Muitos desses arquivos ficam disponíveis online em ftp://ftp.ietf.org/ietf-mail-archive ou visíveis via web. Se você não encontrar a lista que está procurando, envie uma mensagem para o endereço da lista "-request" (não para a própria lista!). A especificação do WG, em http://datatracker.ietf.org/wg, sem dúvida é uma fonte muito útil. As antigas listas, referentes aos WGs concluídos estão em http://www.ietf.org/wg/concluded.

Algumas listas de WG estabelecem limites para o tamanho das mensagens, em especial, para evitar grandes documentos ou apresentações, eliminando excessos no espaço de armazenamento e incomodo nas caixas de entrada dos participantes. Vale a pena lembrar que nem todos os participantes possuem conexões de banda larga (e mesmo aqueles com conexões de banda larga, por vezes, obtem seus e-mails, via conexões lentas, quando viajam). Assim, mensagens mais curtas são muito apreciadas. Os documentos podem ser enviados como IDs, e material de apresentação poderia ficar em um sítio controlado pelo remetente ou enviados pessoalmente, para as pessoas que lhe solicitam fazê-lo. Alguns WGs configuram sítios especiais de hospedagem de tais documentos, que os remetentes devem usar. Na maioria dos casos bastará enviar somente a URL do documento.

4.6 Reuniões Intermediárias de Grupos de Trabalho

Alguns WGs realizam reuniões intermediárias entre as reuniões do IETF. Tais reuniões, não são substitutivas das reuniões que ocorrem como parte dos encontros do IETF -, um WG não pode decidir pular uma reunião em um local que não está interessado, e se reunir em Cancun (ou até mesmo em algum lugar mundano), três semanas mais tarde, por exemplo. Reuniões intermediárias requerem aprovação do AD e precisa ser anunciada pelo menos, com um mês de antecedência. É necessário permitir o acesso justo a todos os participantes, no que diz respeito à localidade, data e hora. Como nas reuniões regulares do IETF, alguém precisa tomar notas e o WG deve se preocupar com a recepção adequada dos participantes. Decisões, mesmo que provisórias feitas durante uma reunião intermediária do WG devem ser ratificadas na lista de discussão, como se exige, nas reuniões regulares.

Nos últimos anos, os WGs tem procurado fazer "reuniões intermediárias virtuais", que acontecem por telefone e / ou online em vez de face-a-face. Reuniões intermediárias virtual podem ser úteis para garantir a atenção ao trabalho que está sendo conduzido e fortalecer a reunião regular e presencial no encontro do IETF. Além disto, possuem custos muito menores do que o comparecimento presencial. As reuniões intermediárias virtuais têm de atender aos mesmos requisitos de documentação exigidos nas reuniões virtuais face-a-face.

O IESG possui regras bem definidas em relação ao local e data / hora das reuniões intermediárias do WG. Tais regras se estendem em exigências relacionadas os relatórios sobre os resultados das reuniões. A preocupação do IESG, com estas regras é garantir que os encontros intermediários sejam acessíveis pelo maior número possível de participantes do WG e manter a transparência do processo.


5. BOFs

Para formar um WG, você precisa de uma especificação e alguém disposto a ser o presidente. Para obter essas coisas, você deve encontrar pessoas interessadas, que possam ajudá-lo a dar consistência à especificação e convencer um AD, que o projeto vale a pena. A reunião face-a-face é útil para isso. Na verdade, muito poucos WGs começam via um AD. A maioria se inícia após um BOF face-a-face, desde que os participantes demonstrem interesse pelo tema.

Um BOF (Birds of a Feather) é uma reunião, aprovada por um AD da área na qual ele se insere, antes de ser agendado. Se você acha que realmente precisa de um novo WG, aborde um AD, informalmente, com a sua proposta e sinta o que ele ou ela acha ou pensa a respeito. O próximo passo é solicitar um espaço para reunião na próxima reunião face-a-face do IETF. Claro, você não precisa esperar por essa reunião para obter algum trabalho resultado, como a criação de uma lista de discussão e, até mesmo, começar a discutir uma especificação.

As reuniões do tipo BOF são bem diferentes das reuniões de um WG. O propósito de um BOF é ter certeza de que uma boa especificação, com metas consistentes possa ser criada e, principalmente, que haja um número de interessados suficientes e dispostos a fazer o trabalho necessário para criar padrões. Alguns BOFs já começam com um I-D, enquanto que outros se iniciam a partir do zero.

Ter um I-D, antes do BOF tem vantagens consideráveis e a principal é a perspectiva de manter o foco na reunião com os interessados já sabendo do que se trata. Mas, por outro lado, a presença de um projeto tende a limitar o que as outras pessoas presentes no BOF desejam apresentar na especificação. É importante lembrar que a maioria dos BOFs são realizados a fim de obter apoio para a criação de um WG e, não para obter o apoio sobre um documento particular.

Muitos BOFs não se transformam em WGs, por uma variedade de razões. Uma razão é o fato de que não bastam as pessoas concordarem com uma proposta de trabalho. Outro motivo comum é que o trabalho não iria acabar sendo um padrão -, se, por exemplo, os autores do documento realmente não desejam abrir mão do controle para um WG (iremos discutir controle de mudanças mais adiante neste documento). Por outro lado, apenas duas reuniões de um BOF podem ser programadas, em um determinado assunto. Nestas duas reuniões, se um WG não for constituído, o tópico deve ser abandonado.


6. RFCs e Internet-Drafts

Se você é novato no IETF e está procurando um RFC particular ou por um Internet-Draft, visite as páginas web do RFC Editor: http://www.rfc-editor.org/rfc.html. Esse sítio, também contém links para outras coleções de RFCs, muitos deles com recursos de pesquisa. Se sabe qual o número do RFC que está procurando, vá para as páginas de RFCs, do RFC Editor: http://www.rfc-editor.org/rfc.html. Para I-Ds, um ótimo recurso é procurar no sítio do IETF: https://datatracker.ietf.org/doc, onde poderá pesquisar a partir do título e de uma palavra-chave.

6.1 Conseguir publicar um RFC

Uma das perguntas mais comuns aos participantes do IETF feitas por recém-chegados é: "Como faço para publicar um padrão IETF?". Mas, a melhor pergunta seria: "Devo escrever um padrão IETF?". A resposta, neste caso, nem sempre é "sim". Se você decidir tentar elaborar um documento que virá a se tornar um padrão do IETF é bom estar alerta para o fato de que o processo, como um todo, poderá ser difícil, apesar das etapas individuais serem bastante simples. Muitas pessoas passam pelo processo sem arranhões. Por outro lado existem muitas orientações por escrito para ajudar os autores manter seu ego mais ou menos intacto.

Uma das primeiras coisas que terá de decidir é se deseja que seu documento seja considerado por um WG, ou se você deseja que ele seja considerado uma apresentação individual (isto é, não seja de um WG) fez para o IETF. Embora a maioria dos padrões do IETF resulte de WGs, alguns surgem de esforços individuais porque pode, não existir algum WG adequado no contexto de seu interesse ou, quando existe um WG adequado, ele está demasiado ocupado em outra atividade, não podendo atender à sua demanda.

Cada padrão IETF é publicado como um RFC ("Request for Comments"), e cada RFC começa como um Internet-Draft (muitas vezes chamado de "ID", "I-D" ou apenas "rascunho"). Os passos básicos para se ter algo publicado como um padrão IETF são os seguintes:

  1. Publicar o documento como Internet-Draft.
  2. Receber comentários sobre o rascunho.
  3. Editar o I-D baseado nos comentários.
  4. Repetir, tanto quanto necessário, os passos de 1 a 3.
  5. Solicitar a um Diretor de Área, que encaminhe seu projeto ao IESG (se for uma apresentação individual). Se o projeto é um produto oficial de um Grupo de Trabalho, o presidente do WG pedirá ao AD, que o encaminhe, ao IESG.
  6. Se o AD aceita o documento, eles farão a sua própria análise inicial e, talvez, perguntar-lhe se há atualizações antes de encaminhá-lo à próxima etapa.
  7. Obter revisões de participantes do IETF. Em particular, algumas das Áreas do IETF formaram equipes de revisão com o objetivo de examinar projetos que estejam prontos para serem encaminhados ao IESG. Duas das equipas de avaliação são mais ativas: a Direção de Segurança ("SecDir") e o Equipe de Revisão da Área Geral ("Gen-Art"). Lembre-se que os comentários vindos das revisões, certamente irão contribuir, em muito, na melhora da qualidade, do eventual RFC.
  8. Discutir as suas preocupações com os membros do IESG. Suas preocupações podem ser resolvidas com uma resposta simples, ou podem precisar de alterações no documento.
  9. Espere que o RFC Editor publique seu documento.

Uma explicação muito mais completa destes passos está contida em [BCP9]: "The Internet Standards Process". Aqueles que escrevem I-Ds, os quais espera que se tornem padrões IETF devem ler a BCP 9, e seguir o progresso do seu documento durante este processo. Este progresso pode ser acompanhado através do programa Datatracker do IETF: http://datatracker.ietf.org. A BCP 9 (e outros documentos que se mantêm atualizado), detalha sobre um assunto que muitas vezes é mal compreendido, mesmo por participantes experientes do IETF: diferentes tipos de RFCs seguem diferentes processos e possuem diferentes classificações. Existem seis tipos de RFCs:

Somente os dois primeiros, propostos e completos, são padrões do IETF. Um ótimo sumário sobre isto pode ser encontrado no [RFC1796], apropriadamente intitulada "Nem Todos RFCs São Padrões".

Há, também, duas subséries de RFCs, conhecido como BCPs e STDs. Melhores práticas recomendadas são documentos descrevem a aplicação de diversas tecnologias na Internet e também são comumente usados ​​para documentar as diversas etapas do processo do IETF. A subsérie FYIs são compostas de "documentos informativos", no sentido da relação acima, com marcação especial. (Havia também uma subsérie de RFCs, chamada "Para sua Informação", criada para implementar documentos com visões e tópicos introdutórios, orientados a um público mais amplo. No entanto, esta série foi oficialmente fechada).

A subsérie STD foi criada, com a intenção de identificar RFCs que de fato especificam Padrões da Internet. Algumas STDs são, na verdade, conjuntos de mais de um RFC, e a designação "padrão" se aplica a todo o conjunto destes documentos.

6.2 Deixem o Conhecimento Fluir Elegantemente!

A principal razão de algumas pessoas não permitir que seus escritos sejam inseridos no curso de padronização do IETF é porque eles devem abrir mão do controle para alterar o protocolo. Em outras palavras, assim que você propõe que um protocolo seja um padrão IETF, você deve abandonar completamente o controle sobre o protocolo. Se há um acordo geral, algumas partes do protocolo podem ser completamente mudadas e, segmentos inteiros podem ser removidos, além da possibilidade de novos recursos serem adicionados e, inclusive o nome pode ser mudado.

Alguns autores acham difícil abandonar o controle sobre seu brinquedo. Se você é uma dessas pessoas, nem tente transformar o seu protocolo em um padrão do IETF. Por outro lado, se o seu objetivo é a implementação da mais amplo e melhor padrão possível esteja certo de que o IETF terá um procedimento que irá lhe satisfazer.

Aliás, a mudança de controle nos Padrões da Internet não termina quando o protocolo entra no processo de padronização. O protocolo pode ser modificado mais tarde, por várias razões, sendo a mais comum, quando os implementadores descobrem algum problema na aplicação do padrão. Tais mudanças, de última hora acontecem sob o controle do IETF, e não dos editores dos documentos de padrões.

Os padrões do IETF existem para que as pessoas as utilizem no desenvolvimento de programas que interagem com outros programas na Internet. Eles não existem para documentar ideias de seus autores (presumivelmente maravilhosas) ou para que uma empresa diga: "nós temos um padrão do IETF!". Se um RFC do tipo, Padrão Proposto tem uma implementação (já que são necessárias duas implementações), é, provavelmente, uma insensatez tentar priorizá-la na fila de processos em padronização.

Observe que novos autores não podem assumir a autoria sobre documentos de terceiros. Veja [BCP78], seção 5.6, alínea (a).

6.3 Rascunhos da Internet

As primeiras coisas, em primeiro lugar. Cada documento que termina no repositório de RFCs iniciou-se como um rascunho da Internet (I-D). I-Ds são projetos de documentos - que se destinam a serem objetos de comentários dos leitores, de modo que os autores possam pensar sobre tais comentários e escolher aqueles que irão participar do projeto. Lembrando às pessoas de sua natureza provisória, os I-Ds são automaticamente removidos dos diretórios on-line ativos, depois de seis meses. Os I-Ds não são padrões. Tal como dito na [BCP9]:

"Um I-D não significa que houve a publicação da especificação; especificações são publicados sob as regras de um RFC... I-Ds não possuem a qualificação formal e podem estar sujeito a mudanças ou mesmo podem ser removidos a qualquer momento. Um I-D não deve ser referenciado por um artigo, relatório ou solicitação de proposta, sob nenhuma circunstância. Nem tampouco, uma companhia pode usar as especificações de um I-D, em uma implementação."

É sempre possível dizer a uma pessoa que ela não entende o IETF (se, deliberadamente tentar enganar as pessoas), quando ele ou ela afirma ter publicado um I-D. I-D não requer nenhum esforço especial.

Quando você encaminha um Internet-Draft, você transfere alguns direitos de publicação para o IETF. Isto é para que o seu I-D possa tornar-se disponível gratuitamente para todos os interessados, que poderão, também, comentar sobre ele. Os direitos que você transfere ao IETF estão descritos em [BCP78], "Direitos do IETF sobre as Contribuições".

Há uma ferramenta de verificação muito útil em http://tools.ietf.org/tools/idnits. Usar esta ferramenta antes de enviar um I-D irá ajudar a prevenir erros de forma e formatação que rejeitariam o projeto.

Um I-D deve estar, aproximadamente, no mesmo formato de um RFC. Ao contrário do que muitas pessoas acredita, um I-D não precisa ter a mesma aparência do RFC, e se possível use os mesmos procedimentos de formatação propostos pelo RFC Editor. Isso irá simplificar o trabalho do editor de RFC quando o seu rascunho for publicado como RFC. O [RFC2223], "Instruções para Autores de RFCs", descreve o formato da apresentação. Há também uma ferramenta chamada "xml2rfc" disponível em, http://xml.resource.org, que lê um arquivo XML (o seu I-D em XML), e transforma-o em um documento adequadamente formatado.

Um Internet-Draft pode ter sua origem em um WG ou, em uma iniciativa individual. I-D de grupos são, geralmente revisados pelos seus participantes, antes de ser aceito como um documento do grupo, muito embora, o presidente tenha a palavra final.

Se você está interessado em verificar o como está a movimentação de um I-D em particular, mas não me lembra o nome exato ou, se quiser descobrir quais I-Ds, um WG está trabalhando, duas ferramentas úteis para fazer isto estão disponíveis. A "Interface do banco de dados de Internet-Drafts", em https://datatracker.ietf.org/doc, lhe oferece a oportunidade de pesquisar um I-D, por autor, WG, data e/ou por nome do arquivo. Isto é especialmente útil para os autores que desejam acompanhar o andamento de seus projetos, durante o processo de publicação.

Existem algumas regras informais para dar nomes a I-Ds que evoluíram ao longo do tempo. Se o I-D é uma nova revisão ou proposta de um RFC, seu nome possui a palavra "bis" (novo ou duas vezes). Assim, o nome de um I-D poderá ser assim: "draft-alguém-rfc2345bis-00.txt".

6.3.1 Leitura Recomendada para Autores

Antes de criar seu primeiro I-D, recomenda-se que leia os seguintes documentos:

Não deixe de visitar a páginas de Ferramentas do IETF, em http://tools.ietf.org, onde irá encontrar muitas referências de ferramentas que serão úteis para o seu trabalho, no IETF.

6.3.2 Nomes de arquivos e outros assuntos

Quando você estiver com a primeira versão de seu I-D pronta, submeta-o em http://datatracker.ietf.org/submit. As instruções nessa página web orientá-lo-ão, através dos passos necessários. Nela há, também, um endereço de e-mail, caso de você precise de ajuda personalizada.

Quando você submeter a primeira versão do projeto, também dirá ao administrador do projeto o nome que propõe para o I-D. Se o I-D é resultado formal de um WG, o nome começa com "draft-IETF-" seguido pela designação do WG e, por uma ou duas palavras descritivas e finalizado por "00.txt".

Por exemplo, um I-D do WG S/MIME, sobre a criação de chaves, pode ser chamado de "draft-IETF-smime-keying-00.txt". Se não é o produto de WG, o nome começa com "draft-" e, o último nome de um dos autores seguidos por uma ou duas palavras descritivas e finalizado por "00.txt". Por exemplo, um I-D que alguém chamado Smith escreveu pode ser chamado de "draft-smith- keying-00.txt". Se um I-D é uma apresentação individual, mas se refere a um WG, em particular, os autores, por vezes, seguem o seu nome com o nome do WG, como "draft-smith-smime-keying-00.txt". Se você seguir as diretrizes de nomenclatura dada em http://www.ietf.org/ietf/1id-guidelines.txt, as chances são muito grandes de que o nome que sugeriu esteja adequado.

Após a primeira edição de um I-D, o número no nome do arquivo é incrementado, por exemplo, o nome da segunda edição do I-D, do S/MIME, acima mencionado seria "draft-IETF-smime-keying-01.txt". Note-se, que há casos, em que as mudanças de nome de arquivo, após uma ou mais versões, como quando ocorre um esforço pessoal no WG, quando um projeto tem seu nome alterado, o número reverte para -00. Neste caso, o presidente do WG informará ao administrador de I-Ds, também, o nome anterior do I-D, para que os bancos de dados possam ser mantidos, precisamente.

6.4 Procedimentos de Continuidade dos RFCs de Padrões

Os procedimentos para criar e dar continuidade a padrões é descrito pela [BCP9]. Depois que um I-D foi suficientemente discutido e, há um consenso aproximado sobre sua viabilidade de se tornar um padrão, ele é encaminhado ao IESG, para as devidas considerações. Se o I-D foi chancelado por um WG, o presidente do WG envia-o para o AD da Área ao qual o WG está associado. Se o I-D veio de uma proposta individual, o autor ou editor, submete-o ao AD da Área, a qual ele considera como sendo pertinente. A BCP 9, também, descreve o processo de apelação contra decisões presumivelmente equivocadas, tanto do presidente do WG, como do AD ou, do próprio IESG.

Após a submissão de um I-D ao IESG, este anuncia um "IETF-wide Last Call" (frequentemente abreviado para "LC"). Este procedimento tem o objetivo de chamar a atenção das pessoas que não estavam acompanhando o progresso do I-D e que poderão propor alterações, para aperfeiçoar o documento. É, também, uma maneira de permitir aos membros do WG se pronunciarem, principalmente, aqueles que não conseguiram ser ouvidos durante as reuniões do WG para fazerem suas considerações, apropriadamente. O LC do IETF dura pelo menos, duas semanas para cada I-D oriundo de WGs e de 4 semanas para aqueles originados de submissões individuais.

O objetivo do LC do IETF é oferecer uma oportunidade de uma ampla discussão (para toda a comunidade do IETF!), sobre os documentos, antes de o IESG apreciá-los. Cuidado com a palavra "discussão" neste contexto. É, geralmente considerado impróprio enviar comentários na LC do IETF, sobre documentos que você não leu. Também, mais inadequado, se você envia comentários sobre questões que você não está preparado para discutir. Não existe votação na LC e, portanto, não faz sentido alguém conclamar as pessoas a darem seu apoio ou se oporem a um documento. O efeito pode ser perverso. Dito isto, os comentários na LC, de pessoas que acabaram de ler o documento pela primeira vez devem abordar problemas que o IETF ou WG não perceberam durante os debates intensos. Com objetividade, as intervenções podem resultar em pontos positivos para o IESG. Esta é a expectativa, já que a discussão está aberta para os membros do IETF, em todo o mundo.

Se o IESG aceita um I-D como um padrão, ele o encaminha, para que RFC Editor o publique como Padrão Proposta (Proposed Standard). Em geral, várias coisas acontecem neste momento. Em primeiro lugar, é comum perceber que há necessidade de reescrever algumas das especificações, se aparecerem ambiguidades de interpretação entre implementadores, completamente diferentes entre si. Outro caso comum é a falta de implementação de algumas funções presentes no padrão. Isto gera a necessidade de eliminar tais funções, não porque alguém a desaprovou mas, porque são, simplesmente desnecessárias.

Não se surpreenda se um padrão particular não progrida de Padrão Proposto, para Padrão da Internet. Para se tornar um Padrão da Internet, um RFC deve possuir múltiplas implementações interoperáveis e os recursos não utilizados no Padrão Proposto devem ser removidos, além de outras condições relacionadas na [BCP9]. Muitos dos padrões utilizados são Padrões Propostos e, elas nunca dão prosseguimento. Parece que isto acontece porque, ninguém quer gastar seu tempo transformando-as para Padrões da Internet ou, talvez, todo mundo tenha coisas mais importantes a fazer.

6.4.1 Dizendo como as coisas são — Usando DEVE e PODERIA e PODE

Especificar, para que as implementações sejam feitas de acordo com o que você quer é uma arte. Se optar por uma especificação muito concisa, com apenas uma lista de requerimentos, dará aos desenvolvedores, uma enorme liberdade, estimulando-lhes a criatividade, muitas vezes à beira da ineficiência. Se, por outro lado, você elaborar uma especificação com o mínimo de detalhes, os desenvolvedores, provavelmente irão se perder nos requisitos (e irão, em qualquer caso, discordar de suas recomendações). A especificação ideal é a que se ajusta entre as duas alternativas acima.

Uma maneira de incentivar os desenvolvedores a criar implementações de padrões interoperáveis ​é ser claro sobre o que está sendo definido pela especificação. Os RFCs mais antigos usavam todo o tipo de expressões para explicar o que é necessário. Isto confundia os implementadores pois, eles não conseguiam distinguir o que eram sugestões do que eram requerimentos. Como resultado desta constatação, os autores de padrões, do IETF, geralmente concordam em limitar o palavreado, a poucas palavras especiais, com alguns significados específicos.

O RFC [STD3], "Requerimentos para Servidores da Internet -- Aplicação e Suporte", escrito em 1989, exibiu uma pequena lista de palavras que pareceram ser úteis: "deve", "deveria" e "pode". Tais propostas foram atualizadas e aperfeiçoadas na [BCP14], "Palavras Chaves para usar em RFCs para Indicar Níveis de Requerimento", que é amplamente referenciada nos atuais Padrões da Internet. A BCP 14 também define especificamente, "não deve" e "não deveria", e relaciona alguns sinônimos para as palavras definidas.

Em um padrão, no sentido de tornar claro que está usando as definições da BCP 14, você deveria fazer duas coisas. Primeiro, referir-se à BCP 14 (apesar de muitas pessoas referirem ao RFC 2119, porque isto é o que a BCP 14 diz para fazer), de tal maneira que o leitor entenda como você está definindo as palavras. Segundo, você deveria indicar quais as instâncias das palavras, da BCP 14 está usando. A prática usual de fazer isto é capitalizando as palavras. Por esta razão, você vê "MUST" e "SHOULD", nos padrões do IETF.

A BCP 14 é um documento curto e, ela deveria ser lida por todos que leem ou escrevem padrões do IETF. Embora, as definições de "deve" e "não deve" sejam bastante claras, as definições de "deveria" e "não deve" levam a intermináveis discussões em muitos WG. Analisar um I-D, surge muitas vezes uma questão: "Essa sentença deve ter um MUST ou um SHOULD?" Na verdade, é uma boa pergunta, porque as especificações não devem abusar da palavra "MUST" mas, também, não deve usar "SHOULD" onde um "MUST" é necessário, para efeitos da interoperabilidade. Isso nos leva ao cerne da questão sobre de sobre especificar ou sub especificar alguns requisitos da norma.

6.4.2 Referências Normativas em Padrões

Um aspecto que confunde muitos novatos, ao escreverem padrões do IETF (e alguns autores experientes, também) é a regra de como fazer as chamadas "referências normativas", de documentos que não são documentos do IETF ou de outros RFCs. Uma referência normativa é uma referência a um documento que tem de ser seguido, para que o padrão possa ser implementado. A referência não normativa (às vezes chamada de "referência de informação") é uma referência que ajuda o programador, mas não é essencial.

Um padrão IETF pode fazer referência a qualquer outro RFC Padrão que esteja no mesmo nível de padrão ou superior. Pode, também, fazer referência a qualquer "padrão aberto", que tenha sido desenvolvido fora do IETF. A regra "nível igual ou superior" significa que antes de um documento prosperar, na sequência do IETF, todos os RFCs para as quais há uma referência normativa devem estar classificados no mesmo nível ou superior, em relação as etapas descritas anteriormente. Esta regra está descrita em [BCP97]. É uma regra que dá aos implementadores, a garantia de que tudo o que está contido no padrão é estável, mesmo que referenciado fora do padrão. Isto pode, certamente, atrasar a publicação do I-D ou padrões, por vários meses (às vezes até anos), enquanto que outros documentos estão sendo encaminhados e não atingiram ou ultrapassaram o mesmo nível do documento que os estão referenciando.

Não existe uma regra absoluta definindo o que é um "padrão aberto", mas em geral, corresponde a um padrão estável, para o qual todos podem obter uma cópia (mesmo que tenha de pagar) e foi escrito por um grupo reconhecido como desenvolvedores de padrões. Se o padrão externo sofre mudanças, você deve fazer referência à instância particular daquele padrão, com a designação da data do padrão. Alguns organismos de padronização externa não colocam os padrões antigos disponíveis, o que é um problema para os padrões IETF a serem utilizados no futuro. Em caso de dúvida, o autor de um I-D deve pedir ao presidente do WG ou ao AD, se um padrão externo particular pode ser usado em um padrão IETF.

6.4.3 Considerações sobre o IANA

Cada vez mais, os padrões do IETF requerem o registro de diversos parâmetros de protocolos, genericamente, referenciados como as opções de protocolo. Como podemos observar em Section 2.2.4, o principal registro para todos os padrões IETF tem sido o IANA. Por causa dos diversos tipos de registros, exigidos pelos padrões, o IANA precisa caracterizar algumas informações específicas relacionadas a como registrar tais parâmetros, o que não registrar, quem (se alguém) irá decidir o que deve ser registrado e, assim por diante.

Qualquer autor de padrões poderá, em algum momento depender de um novo registro ou de incluir novos valores em um registro já existente no IANA. Sendo assim, recomenda-se a leitura da [BCP26], "Guia para Escrever considerações sobre o IANA em uma Seção de RFCs", que descreve como autores de RFCs devem de forma correta pedir ao IANA para iniciar ou desenvolver um registro. O IANA, também, mantém registros que foram iniciados muito antes da BCP 26 ser escrita.

6.4.4 Considerações de Segurança

Todo I-D ou todo RFC, obrigatoriamente tem de ter uma seção denominada "Considerações de Segurança". Esta seção irá descrever todas as vulnerabilidades conhecidas do protocolo, as possíveis ameaças, mecanismos ou estratégias para enfrentá-los. Não se pode escrever algo simples como: "Pode-se garantir a segurança do protocolo descrito usando o IPsec". Isso não fará diferença, porque ele não responde a questão de como IPsec interage com o protocolo, e vice-versa. O melhor é ler a [BCP72], "Orientações para a do texto sobre considerações de segurança no RFC", para obter as informações adequadas para escrever uma seção coerente sobre "Considerações de Segurança".

6.4.5 Patentes nos Padrões da IETF

Os problemas de propriedade intelectual surgiram com muita frequência nos últimos anos, particularmente, no que diz respeito a patentes. O objetivo do IETF é ter seus padrões amplamente utilizados e validados pelo mercado. Se a criação de um produto que usa um padrão requer obtenção de uma licença de patente, as pessoas são menos propensos a implementar o padrão. Não surpreenda, portanto, que a regra geral seja: "sempre e onde for possível use tecnologia não patenteada".

Claro que, isto nem sempre é possível. Às vezes patentes aparecem após o padrão ter sido estabelecido. Às vezes há uma patente sobre algo que é tão valioso que não há um equivalente não patenteado. Outras vezes, o titular da patente é generoso e promete dar a todos os implementadores, uma licença sem cobrar nada pela patente tornando-a quase tão fácil de implementar como teria sido se não houvesse patente.

Os métodos do IETF para lidar com patentes em padrões são um assunto de muito debate. As regras oficiais para todos os direitos de propriedade intelectual ou, IPR (Intellectual Property Rights), em documentos IETF (e não apenas patentes) são abordados na [BCP78] e na [BCP79], "Direitos de Propriedade Intelectual em Tecnologia do IETF" . Todos os que participam em grupos de trabalho do IETF, provavelmente irão considerar esses documentos interessante, porque eles exibem as regras que todos concordam em seguir.

Detentores de patentes que permitem o seu uso, livremente, pelos implementadores de padrões do IETF, recebem muita simpatia e gratidão por parte dos participantes. Essa generosidade é mais comum do que se pode imaginar. Por exemplo, o RFC 1822 é uma licença da IBM para uma de suas patentes de segurança em um contexto particular de protocolo e, a comunidade de segurança reage muito favoravelmente a IBM, por esta razão (enquanto uma série de outras empresas foram excluídas pela mesma comunidade, por sua inflexibilidade em relação às suas patentes).

Se ao escrever um I-D, você percebe que uma patente aplica-se à tecnologia que está propondo, não referencie a patente no documento. Em vez disso, consulte a página do IPR no IETF, http://www.ietf.org/ipr, para saber como deverá proceder. Direitos de propriedade intelectual não são mencionados em RFCs porque RFCs nunca mudam, depois de serem publicadas, mas o conhecimento dos IPR, pode mudar a qualquer momento. Assim, uma lista de direitos de propriedade intelectual incompleta, em um RFC, pode causar dúvidas ao leitor. A [BCP79], orienta sobre um texto específico, que deve ser adicionado aos RFCs, quando o autor reconhece a presença de possíveis ofensas ao direito de propriedade intelectual ou, IPR.

6.5 RFCs Informativo e Experimental

Como falamos anteriormente, nem todas as RFCs são padrões. Na verdade, muitas RFCs importantes, não são padrões e nem pertencem à sequência, para serem padrões. Atualmente, existem duas designações para RFC não padrão: informativos, como o Tao, e experimentais. (Na verdade, há uma terceira designação, a histórica, que é reservada aos documentos que estavam na lista de padrões, mas foram removidos, devido à sua falta de uso ou, porque, o pensamento recente indica que é prejudicial para a tecnologia da Internet).

O papel do RFC informativa é muitas vezes debatido no IETF. Muitas pessoas gostam de tê-los, especialmente para as especificações, que foram criadas fora do IETF, mas referenciados em documentos IETF. Elas, também são úteis para as especificações precursoras dos trabalhos que estão sendo realizados nos Grupos de Trabalho. Por outro lado, algumas pessoas se referem aos RFCs informativas como "padrões", embora os RFCs não o sejam. Geralmente, esta atitude é tomada por pessoas que estão vendendo alguma coisa ou necessitam de apoio. Quando isso acontece, o debate sobre RFCs informativos é renovado.

RFCs experimentais são para as especificações que podem ser interessantes, mas ainda não está claro se merecem uma implementação ou, se a sua implementação funcionaria. Ou seja, uma especificação pode resolver um problema, mas não há um consenso entre as pessoas se é um problema importante ou, se acham que o problema será resolvido com a sua implementação. Então, o RFC é classificado como Experimental. Se, mais tarde, a especificação tornar-se popular (ou provar que funciona bem), o RFC pode ser publicado novamente e entrar na sequência para aprovação como padrão. RFCs experimentais, também são usados ​​para levar as pessoas a experimentar uma tecnologia que parece ser um bom material para entrar na sequência de padrões, e para o qual, ainda não há respostas prontas, por completo.

O IESG criou diretrizes de como ele irá escolher entre o estado Informativo e o Experimental: http://www.ietf.org/iesg/informational-vs-experimental.html. Se você estiver criando um documento e, supõe que este documento se tornará um RFC Experimental, o conhecimento da posição atual, no encaminhamento para se tornar um padrão, justificará a sua escolha.


7. Como Contribuir para o IETF

7.1 O que Você Pode Fazer

Read — Reveja os I-Ds que se encaixam em sua áre de interesse e fale sobre eles, nos WGs. Participe dos debates, de forma amistosa tendo sempre em mente, o objetivo de obter o melhor padrão possível para a Internet. Ouça, mais do que fale. Se você discordar, discuta os problemas técnicos: não ataque as pessoas.

Implemente — Escreva programas usando padrões da Internet, mais recentes. Os padrões são inúteis, a menos que eles estejam disponíveis para os usuários da Internet. Escolha, principalmente o padrões "menos importantes", pois tornarão mais importantes, se estiverem acoplados a muitos programas. Relatar quaisquer problemas encontrados com os padrões, para o WG, afim de que ele possa melhorar as próximas versões. Um dos princípios mais citados do IETF é "o código executável é o vencedor", portanto, você pode ajudar a sustentar os padrões que queremos popularizar, criando mais códigos executáveis. Você pode participar do desenvolvimento de protocolos antes deles se tornarem padrões de execução (mas não a implantação), a partir de I-D, para assegurar que os autores fizeram um bom trabalho. Se você encontrar erros ou omissões, já estará oferecendo melhorias, com base na sua experiência de implementação.

Escreva — Edite ou seja coautor de I-Ds em sua área de especialização. Faça isso, para o benefício da comunidade da Internet e, não simplesmente, para ter seu nome (ou, pior ainda, o nome da sua empresa) em um documento. Autores de I-Ds estão sujeitos a todos os tipos de críticas técnicas (e, por vezes pessoal). Receba-as com serenidade e use-as, para melhorar o seu projeto, na direção de torná-lo um padrão melhor e mais interoperável.

7.2 O que sua Empresa Pode Fazer

Compartilhe — Evite padrões proprietários. Se você é um implementador exiba, sempre, uma forte preferência por padrões do IETF. Se os padrões do IETF não são tão bons quanto os padrões proprietários, trabalhe para tornar os padrões do IETF, os melhores. Se você é um comprador, evite produtos que utilizam padrões proprietários que competem com os padrões abertos do IETF e conte a seus fornecedores, porque sua empresa se comporta deta maneira.

Abra — Se a sua empresa controla uma patente usada em um padrão IETF, convença a empresa a tornar patente disponível sem custo para todos que estão implementando o padrão. Nos últimos anos, as patentes têm causado uma série de problemas graves aos padrões da Internet, pois inibem a implementação, livre, nos padrões. Felizmente, muitas empresas têm oferecido generosamente licenças ilimitadas para determinados patentes, a fim de ajudar os padrões IETF florescerem. Essas empresas geralmente são recompensadas ​​com publicidade positiva mostrando que não são gananciosas ou míopes, como outros detentores de patentes.

Junte-se — Torne-se um membro da ISOC. Mais importante ainda, incite qualquer empresa que tenha se beneficiado da Internet, a se tornar um membro corporativo da ISOC, uma vez que este tem o maior benefício financeiro para o grupo. E irão beneficiar a Internet como um todo.


8. O IETF e o Resto do Mundo

8.1 O IETF e os Outros Grupos de Padronização

Embora muitos participantes do IETF pensem de outra forma, o IETF não existe em um vácuo de padrões. Há muitos outros (talvez muitos, mesmo), organismos de padronização, cujas decisões afetam Internet. Há também uma série de organismos de padrões que ignoraram a Internet por um tempo e agora querem participar.

Em geral, o IETF procura ter relações cordiais com outros organismos de padronização. Isso nem sempre é fácil, já que muitos outros destes organismos possuem estruturas bem diferentes do IETF. O IETF é principalmente dirigido por voluntários, que provavelmente preferem escrever padrões, ao invés de encontrar-se com representantes de outros organismos. Mesmo assim, alguns organismos de padronização fazem um grande esforço para interagir, firmemente, com o IETF, apesar das diferenças culturais óbvias.

No momento da redação deste artigo, o IETF tinha algumas ligações com grandes organismos de padronização, incluindo a ITU-T (Telecommunication Standardization Sector of the International Telecommunication Union), o W3C (World Wide Web Consortium), o IEEE (Institute of Electrical e Electronics Engineers) e o Unicode Consortium. Como afirmado pelo IAB, na [BCP39], "Colaboração são mantidas tão informais quanto possível e devem ser de valor comprovado na melhoria da qualidade das especificações IETF". Na prática, o IETF prefere elementos de ligações, ao invés de agir directamente a nível de WG, atuando como apoio, lançando mão de relações formais e documentos de cooperação.

Algumas destas tarefas de relacionamento são de responsabilidade do IESG, outras recaem sobre o IAB. Leitores detalhistas irão aprender muito sobre os métodos formais para lidar com outros organismos de padronização na [BCP102], "Processos IAB para a Gestão da IETF dos relacionamentos dos elementos de ligação" e, na [BCP103], "Procedimentos para a Tratar Declarações de Ligações de e para o IETF". O melhor lugar para verificar com quem o IETF possui ligação formal é a lista de ligações do IETF, http://www.ietf.org / ligação. A lista mostra que há muitas ligações diferentes com a ISO / IEC e subcomissões do JTC1.

8.2 Cobertura da Imprensa no IETF

Uma vez que o IETF é uma das entidades mais conhecidas que ajudam o avanço da Internet, é natural que a imprensa da computação (e até mesmo a imprensa especializada) queira cobrir seus movimentos. Nos últimos anos, um número pequeno de revistas designou repórteres e editores para cobrir o IETF em profundidade, durante um longo período de tempo. A passagem destes jornalistas foi marcada por inúmeros artigos com erros, declarações contendo interpretações incorretas sobre o estado dos I-Ds, referências a pessoas que não relacionadas com o trabalho do IETF e assim por diante.

Os principais erros da imprensa podem ser classificados em duas categorias: informar que o IETF está considerando alguma coisa, quando na verdade não passa de um I-D sendo discutido em um WG ou, escrevendo que o IETF aprovou alguma coisa, quando tudo o que aconteceu foi a publicação de um RFC Informativa. Em ambos os casos, não se pode culpar, totalmente a imprensa, já que eles geralmente são alertados para a história por uma empresa que está tentando obter publicidade para um protocolo que desenvolveu ou por alguma razão associada. Claro, uma pequena pesquisa feita pelos repórteres, provavelmente levariam a um contato mais seguro, dentro do IETF, que validasse a informação, como um presidente de um WG ou um AD. A informação para a imprensa tem um local bem definido: <http://www.ietf.org/media.html>.

O fato dos repórteres retornarem às reuniões do IETF, mesmo tendo obtido informações erradas descobrirá que é possível obter a informação correta. No entanto, as reuniões do IETF não são, definitivamente, para repórteres alheios ao processo do IETF. Claro, que se você é um repórter e está lendo o Tao é um ótimo sinal! Além disso, se você acha que você terá uma história quente, assistindo reuniões do IETF, irá se decepcionar, provavelmente.

Considerando tudo isso, não é surpreendente que alguns participantes IETF preferiram a imprensa, o mais longe possível de reuniões. Ter um pouco de publicidade para os protocolos próximos da conclusão e, que irão se tornar significativos para a indústria da Internet pode ser uma coisa boa. Contudo é raro, que o repórter resista em exagerar na descrição de um protocolo nascente, como o próximo salvador da pátria. Tais histórias, entretanto, são ruins tanto para os leitores, quanto para o IETF.

Repórteres que desejam saber mais sobre "o que o IETF está fazendo" sobre um determinado tema devem procurar mais de uma pessoa, efetivamente ativa e, sem dúvida devem, adicionalmente procurar o presidente do WG. É impossível determinar o que vai acontecer com um I-D, somente olhando para ele. Felizmente, todos os WGs possuem arquivos disponíveis publicamente, sobre os quais, repórteres podem se debruçar e analisar, com alguma ajuda. Mas, infelizmente, alguns jornalistas não têm tempo ou inclinação para fazer esse tipo de pesquisa. O IETF não tem um relacionamento direto com a imprensa e, portanto, quem interpretou e/ou escreveu alguma coisa errada poderá fazê-lo novamente, caso não atente às recomendações, aqui mencionadas.


9. Consideração de Segurança

Section 6.4.4 aborda porque cada RFC requer a sessão de Considerações de Segurança e, dá alguma ideia do que pode ou não pode conter. Além desta informação, este documento não toca em questões de segurança da Internet.

10. Informative References

[BCP9] Bradner, S., “The Internet Standards Process -- Revision 3”, BCP 9, RFC 2026, RFC 6410, October 1996.
[BCP10] Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees”, BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, “The Organizations Involved in the IETF Standards Process”, BCP 11, RFC 2028, October 1996.
[BCP14] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[BCP22] Scott, G., “Guide for Internet Standards Writers”, BCP 22, RFC 2360, June 1998.
[BCP25] Bradner, S., “IETF Working Group Guidelines and Procedures”, BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
[BCP39] Internet Architecture Board and B. Carpenter, “Charter of the Internet Architecture Board (IAB)”, BCP 39, RFC 2850, May 2000.
[BCP45] Harris, S., “IETF Discussion List Charter”, BCP 45, RFC 3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, July 2003.
[BCP78] Bradner, S., “IETF Rights in Contributions”, BCP 78, RFC 5378, November 2008.
[BCP79] Bradner, S., “Intellectual Property Rights in IETF Technology”, BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., “A Mission Statement for the IETF”, BCP 95, RFC 3935, October 2004.
[BCP97] Bush, R. and T. Narten, “Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level”, BCP 97, RFC 3967, December 2004.
[BCP101] Austein, R. and B. Wijnen, “Structure of the IETF Administrative Support Activity (IASA)”, BCP 101, RFC 4071, April 2005.
[BCP102] Daigle, L. and Internet Architecture Board, “IAB Processes for Management of IETF Liaison Relationships”, BCP 102, RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, “Procedures for Handling Liaison Statements to and from the IETF”, BCP 103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, “Not All RFCs are Standards”, RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, “Instructions to RFC Authors”, RFC 2223, October 1997.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority”, RFC 2860, June 2000.
[RFC6635] Kolkman, O. and J. Halpern, “RFC Editor Model (Version 2)”, RFC 6635, March 2012.
[RFC4677] Hoffman, P. and S. Harris, “The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force”, RFC 4677, September 2006.
[RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, “Document Shepherding from Working Group Last Call to Publication”, RFC 4858, May 2007.
[RFC6722] Hoffman, P., “Publishing the "Tao of the IETF" as a Web Page”, RFC 6722, August 2012.
[STD3] Braden, R., “Requirements for Internet Hosts - Application and Support”, STD 3, RFC 1123, October 1989.

A. IETF: Princípios orientaddores

Se você chegou até aqui lendo o TAO, aprendeu muito sobre o trabalho do IETF. Neste apêndice encontrará um resumo da maior parte do que leu e, alguns novos pontos a ponderar. Não deixe de ler todos os princípios pois, eles lhe darão, uma nova perspectiva sobre o que é o IETF.

A.1 Generalidades

O IETF trabalha em processo aberto e por consenso aproximado. Isto se aplica a todos os aspectos do funcionamento do IETF, incluindo a criação de documentos IETF e as decisões sobre os processos que são utilizados. Mas o IETF, também observa experiências e código executável, com interesse e, isto também se aplica aos processos operacionais da organização.

O IETF trabalha em áreas onde ele tem ou pode encontrar competências técnicas.

O IETF depende de um grupo muito ativo de voluntários.

Não há taxas para participação no IETF ou seus WGs e, tal participação não é definida em termos organizacionais. Mas é baseada em auto identificação e participação ativa de pessoas, indivídualmente.

A.2 Gestão e Liderança

O IETF reconhece as posições de liderança e garante poder de decisão a seus líderes, mas decisões são passíveis de apelação.

Delegação de poder e de responsabilidades são essenciais para o trabalho efetivo do IETF. Tantos indivíduos quanto possíveis serão incentivados a assumir liderança nas tarefas do IETF.

Diferenças de opinião, reivindicações e apelação são eventos próprios do IETF e devem ser considerados como eventos normais mas, em última análise, devemos reconhecer que não se pode apelar de algumas decisões.

Posições de liderança possuem mandatos fixos (por outro lado, não há limitações sobre os números de mandatos, que podem ser exercidos).

É importante o desenvolvimento de futuros líderes entre a comunidade ativa.

Um processo comunitário é usado para selecionar líderes.

Os líderes têm o poder de julgar se o consenso aproximado foi atingido. Sem uma filiação formal, não existem regras formais para o consenso.

A.3 Processo

Embora o IETF tenha necessidade de regras de processo, claras e documentadas publicamente para casos normais, há flexibilidade suficiente para casos incomuns, que são tratados com bom senso. Nós usamos nosso julgamento pessoal, para só escrever código quando estamos seguros. (Mas, identificamos as pessoas que podem tomar decisões pessoais).

O trabalho de desenvolvimento técnico deve ser feito fortemente especificado e focado nos WGs.

As partes do processo que mostraram impraticáveis devem ser removidas ou indicadas como opcionais.

A.4 Grupos de Trabalho

Grupos de Trabalho (WGs) são os principais responsáveis pela qualidade de sua produção. Os presidentes de um WG, líderes apoiados pela liderança do IETF agem como garantidores da qualidade.

O WG tem a responsabilidade de avaliar o impacto negativo do seu trabalho na Internet e, portanto, obter opiniões de revisores pertencentes a várias áreas. Neste sentido, a liderança IETF apoia as interações entre as diversas áreas.

Uma análise inicial dos documentos, nomeadamente pelos WGs é mais eficaz para lidar com grandes problemas, geralmente encontrados na avaliação final.

Os Diretores de Área (ADs) são responsáveis ​​por orientar a formação e a criação de WGs dando instruções, sempre que necessário, além de terminar um WG. O presidente do WG está sob as ordens do AD, no qual o WG está afeto.

Os presidentes dos WGs são responsáveis por assegurar que a execução das especificações está conforme, promovendo reuniões e garantindo que documentos sejam entregues e estejam prontos para publicação. Os editores dos documentos estão sob a responsabilidade do presidente do WG.

Os ADs são responsáveis ​​pela organização e acompanhamento das avaliações de qualidade e aprovação dos documentos finais.

A.5 Documentos

Os padrões IETF muitas vezes começam como rascunhos pessoais e podem tornar-se um I-D de um WG. É aprovado para publicação por um grupo formado por lideres, independentes do WG ou pessoas que o produziram.

Os padrões do IETF pertencem à comunidade e, não aos seus autores. Mas autoria é reconhecida e valorizada, assim como outras contribuições menores, também são valorizadas.

As qualidade técnica e a correção são os principais critérios para se conseguir o consenso sobre documentos.

As especificações do IETF podem ser publicado como Informativo, Experimental, Padrões, Histórico ou, como Melhores Práticas Atuais (BCP).

As especificações dos padrões IETF não são considerados satisfatórias, até que uma implementação independente e interoperável tenha sido demonstrada. (É a aplicação do que se convencionou chamar de "código executável"). No entanto, o IETF não assume responsabilidade por testes de interoperabilidade e nem certifica a interoperabilidade.

Os processos do IETF são publicados com BCPs (Best Current Practices).

Informações úteis que não são uma especificação ou um processo, são publicadas como Informativo.

Especificações e processos, obsoletos ou preteridos podem ser rebaixados para Hístorico.

Os padrões são distinguidos pela demonstração de que as especificações são interoperáveis.

Documentos Padrões e BCPs são submetidos ao consenso aproximado, no IETF (LC - Last Call). O consenso aproximado, no âmbito do WG é, normalmente, suficiente para os outros documentos.

Alterações significativas ocorridas durante o processo LC do IETF ou, da avaliação do IESG devem retornar ao WG.

O IETF estabelece as regras e exigências para uma publicação e arquivamento de seus documentos.