By connecting the world,
collaborating with others,
and advocating for equal access to the Internet,
the Internet Society strives to make the world a better place.
At the foundation of our work are a vision and a mission.

The Internet is for everyone.

Introdução

Até agora, neste blogue tenho escrito sobre assuntos pontuais da Infraestrutura da Internet, em particular com o foco em Sistemas Autônomos e no principal protocolo envolvido, o BGP. Com a proximidade do IETF 86, em Orlando (Flórida) rever o processo de funcionamento da Infraestrutura da Internet, em detalhes e no seu aspecto global parece oportuno.

Este trabalho tem como sua principal motivação, o esforço de Paul Hoffman¹, com uma versão em espanhol aqui. As regras desta referência estão descritas na RFC6722² seguindo aquelas do IETF, em relação às suas publicações. A primeira publicação de O Tao do IETF foi a RFC4677³, em 2006.

Tao (pronuncia-se dao), no Taoismo⁴ (pronuncia-se daoismo), se refere a algo que é tanto a fonte quanto a força motriz por trás de tudo que existe. Seu ideogama é o yang-ying, representado pela conhecida figura à direita.

O Tao do IETF dá ênfase aos três eventos anuais no aspecto referente à organização, orientando o recém chegado sobre o comportamento esperado na ocasião. Das trinta e oito páginas, oito são dedicadas à organização da Infraestrutura da Internet e o restante, indiretamente exibe a forma como são construídos os padrões utilizados na Internet.

A sopa de termos

Aqui ou em qualquer lugar na Internet, em livros e documentos aparecerão acrônimos e abreviações que algumas vezes trará uma certa dificuldade de leitura. A tabela abaixo, adaptada de Hoffman¹ e do Glossário do IETF, ajudará a torná-los mais conhecidos. Uma tradução livre, do significado em português foi adicionada, para facilitar a compreensão, e poderá sofrer mudanças à medida que as contribuições forem recebidas.

Também, na tabela, as referências para informações adicionais de cada item. Tais referências, básicas, não se esgotam na tabela, pelo contrário. A quantidade de informações é imensa!

Interação entre as atividades

Este texto tem como objetivo a descrição do processo de formação dos padrões da Internet. Isto significa que o principal foco está no funcionamento do IETF. O IETF está relacionado com um conjunto de outras organizações e/ou atividades, as quais, incluindo o IETF possuem forte ligação funcional com a ISOC. A Figura 1 exibe as relações entre as que mais interessam para este texto, onde a ISOC é a peça fundamental, em todo o conjunto.

A relação mostradas na Figura 1 é complexa. Muitas vezes a comunidade age, simplificando, com o objetivo de facilitar o entendimento, como por exemplo, referir-se ao IETF como sendo a representação do próprio IETF, em conjunto com IAB, IESG, IRSG, IRTF e RFC Editor. A principal referência que esclarece, detalhadamente, os mecanismos e caminhos da padronização é a RFC2026¹⁹. ICANN e W3C são independentes, e possuem protocolos assinados com a ISOC para compor seus interesses, inclusive de autonomia e independência. A W3C é abrigada pelo MIT enquanto que a IANA foi entregue à administração da ICANN pelo governo dos EEUU, que não interfere diretamente. Alexis Simoneli²⁰, descreve cada um dos componentes da Figura 1, com razoável detalhe e complementa este texto, neste quesito.

A ISOC representa uma blindagem completa sobre a capacidade de auto-gestão, do IETF. O modelo foi arquitetado de forma inteligente e serena pelo grupo de pessoas que participaram da criação inicial dos componentes técnicos envolvendo redes de computadores e os protocolos TCP/IP, muito bem abordado no texto escrito por nove deles, “Brief history of the Internet”¹⁴, onde mostram a linha de tempo, reproduzida na Figura 2.

A Figura 2, mostra a formação do primeiro grupo de trabalho em 1968 (ARPANET WG) e a evolução até a fundação da ISOC, com o estrito objetivo de garantir a independência da Internet, culminando com a criação do W3C.

O funcionamento do IETF

O IETF foi criado em 1986 e é constituído de pessoas, não por empresas. O trabalho no IETF é dividido em áreas (atualmente 8) e cada área, em grupos de trabalho (WGs) ativos (atualmente, 126). Alguns grupos de trabalho foram concluídos e continuam disponíveis para acesso. Existem listas que não são WGs. Eis alguns pontos que ilustram como o IETF se comporta:

A formação de um WG depende de um bom projeto e de massa crítica (um grupo de pessoas interessadas). Para convencer um AD ou vários é necessário um projeto bastante claro sobre a ideia envolvida. A forma adequada de fazer isto é escrever um I-D, estruturado objetivamente. Em alguns casos, o I-D é acompanhado por um código que funcione. O texto, mais o código já são suficientes para garantir sucesso, na aprovação do WG. Se, entretanto conseguir interessados, o processo pode ser bem mais rápido, intensificado pela estrutura da ideia no I-D. O caminho para o WG pode ser longo, mas o BOF é um dos ambientes mais propícios a avançar. Às vezes a criação formal do BOF é antecedida por apresentações locais e / ou BOFs informais (o BOF formal, em um encontro do IETF, geralmente é de uma única sessão).

Um exemplo interessante e que pode ser acompanhado é a proposta que está sendo elaborada por Danton Nunes²¹. Danton, está preocupado em recomendar algumas alternativas para melhorar o protocolo SPF: “…um mecanismo para endereço IP pode ou não enviar email de um dado domínio”. Após perfeiçoado sua ideia, Danton colocou-a na lista do GTER e recebeu inúmeras sugestões que lhe permitiu refiná-la. Sua próxima etapa foi desenvolver um código para testar a recomendação. Feito isto, apresentou o projeto na segunda reunião anual do GTER de maneira bastante consistente. O próximo passo, certamente será um BOF em encontro do IETF, pois ele já possui o I-D (ainda não formatado nos padrões desejáveis pelo IETF). A criação do WG será bem rápida, imagina-se. Mais rápido ainda, se ele fizer um debate informal com alguns participantes do IETF que foram importantes no desenvolvimento do protocolo original, pois sob a ótica da meritocracia do IETF, a opinião deles será relevante!

No exemplo do parágrafo anterior, a formatação do I-D será fundamental. O IETF divulga um conjunto de ferramentas, desenvolvidas por seus participantes, para facilitar o trabalho do autor, nesta etapa, e que podem ser vistas em IETF Tools.

Um exemplo final, que ilustra a informalidade das ideias dentro do IETF, na expectativa de que os participantes trabalhem sobre elas está em um I-D disponibilizado por Ammar J. Salih, relacionado com a adição de localização por GPS no cabeçalho do IPv6 e que pode ser visto aqui: Adding GPS location to IPv6 header. Ammar divulgou seu projeto no Linkedin, no grupo do IETF. Apesar de bastante claro, o I-D está, ainda, escrito informalmente, o que é admissível. Como se pode ver, o I-D permanecerá no sítio do IETF, por 6 meses, caso não siga em frente, da forma exibida na Figura 3.

Como se pode verificar, o BOF é um componente importantíssimo no processo. Ele ajuda a consolidar a ideia, nos arredores do problema. A RFC5434²² é o documento que recomenda o que se deve fazer para que o BOF seja um sucesso. No LACNIC XVIII vi propostas de algumas sessões de BOF, o que indica o fato de que o BOF pode ser considerado informal (isto é, fora dos encontros do IETF). Voltemos ao exemplo do Danton Nunes. A sua palestra foi, de certa forma, um BOF, do qual “compulsoriamente” pessoas de diversas correntes de pensamento participaram. Alguns, portanto, sem interesse no assunto. A ausência da noção de existência ou não de massa crítica no Brasil, não foi respondida naquele momento. O GTER poderia pensar na possibilidade de permitir os “GTER-GTS-BOFs”, sem prejuízo da apresentação normal. A recomendação partiria do interessado ou da coordentação do GTER / GTS. Isto poderia estimular a participação da comunidade brasileira no IETF. Se o assunto for considerado relevante, pela comunidade presente, o Nic.br poderia apoiar a participação do(s) “dono(s)” da ideia, no IETF. A proposta do Danton, não foi a única apresentada no GTER, e provavelmente, no GTS.

Nota 1: S. Moonesamy, da República do Maurício, ISOC Fellow e, bastante ativo no IETF, lembrou que já existe um WG para o SPF. Moonesamy, também, recomendou algumas correções importantes no texto, a quem o autor agradece.

Como participar do IETF

Existem, basicamente, duas maneiras de participar no IETF: encontros e WGs. A Figura 4, abaixo apresenta um resumo geral e os pré-requisitos (quando for o caso). Complementarmente, a Figura 4 exibe os locais nos quais ocorrerão os três eventos principais durante os anos de 2013 e 2014.

Os encontros (“meetings”), do IETF são as oportunidades em que os participantes dos WGs encontram-se para consolidar as idéias e se conhecerem. A participação pode ser remota. As várias formas de participação remota estão descritas na documentação de cada encontro, como por exemplo, em “Agendas and Meeting Materials” do IETF 86 que, aos poucos vai se delineando. Um panorama dos recursos que são colocados para a participação remota pode ser visto, quando da realização do IETF 85.

A participação presencial, além da forma tradicional (inscrever, pagar, viajar e participar), a ISOC oferece bolsas (“Fellowships”) para que diversos tipos de pessoas tenham oportunidade de participar, até em duas oportunidades. Estas bolsas incluem a estada no hotel do encontro, despesas de passagem e uma ajuda de custos. Todas as informações estão disponíveis em “Education and Leadership Programmes“. Há alguns pré-requisitos para concorrer a uma bolsa que estão descritos em “Selection Criteria for Fellowships to the IETF“. Um dos mais importantes é ser associado da ISOC, onde existe uma forma de se associar, sem necessidade de contribuição.

A participação efetiva e duradoura é através dos WGs. Como já foi dito, o IETF divide suas atividades operacionais em 8 áreas às quais são associados respectivos WGs. A Figura 4 exibe as oito áreas, com uma pequena descrição dos interesses relacionados. Detalhes, entretanto, dos interesses de cada área e respectivos grupos podem ser encontrados em “Active IETF Working Groups“.

Às vezes, a interpretação do domínio de uma das oito áreas do IETF pode parecer confusa, principalmente, durante as sessões de um encontro. Existe um conjunto de tutoriais que ajudam no entendimento de tópicos específicos. Alvaro Retana e Fernando Gont, em [18] comentam sobre as áreas e fatos interessantes dos respectivos grupos, incluindo estatísticas.

Conclusões

Este é um texto introdutório sobre o IETF, seu funcionamento, sua relação com a ISOC e demais organizações associadas, além de mostrar como são construídos os documentos que dão origem às RFCs. As regras do IETF são bem definidas e oferecem uma flexibilidade suficiente para que os participantes se sintam à vontade livres para desenvolver o trabalho, que não é pequeno. Há anos funciona muito bem e as idéias são consolidadas em um ambiente de “múltiplas partes interessadas”. Um verdadeiro caos organizado! O IETF tira o máximo do conhecimento de milhares de pessoas, que agem soberana, e prazeirosamente, em benefício dos usuários da Internet.

O assunto não se esgota já que é bastante complexo. Os três encontros anuais do IETF constituem o exercício culminante dos esforços que são feitos pela comunidade que deles participam, antes e durante. O próximo será o IETF 86, em Orlando, Flórida. A sua organização já está em franco andamento e pode ser vista aqui, em constante e rápida atualização.

Este texto, além de ser uma introdução incompleta do funcionamento do IETF, contêm referências que, também, não são completas. A quantidade de material disponível, seja em RFCs, no sítio do IETF ou em outras fontes, são inesgotáveis. Em The IETF Process: an Informal Guide, editado por Brian Carpenter tem-se uma excelente referência complementar, como ele mesmo diz diz: “…is an informal guide to various IETF process documents, intended mainly to assist IETF participants in navigating the labyrinth. …”, que vale a pena acompanhar.

Já é possível antever que – antes, durante e depois do IETF 86 -, a experiência será maravilhosa! Sob o ponto de vista técnico, uma oportunidade dos Deuses que, minimamente deve ser divulgada, e recomendado, para quem ainda não o fez, que se associe à ISOC: aqui e / ou aqui.

Em resumo, vale esclarecer que a exposição acima é a visão de um “First Time Fellow” preparando-se para o que será uma experiência inesquecível.

Artigos relacionados

• IETF => D-75: O comitê de nomeação

• IETF => D-58: Como participar dos encontros do IETF

• Entendendo RFCs

Referências

1. Paul Hoffman (Editor). The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force. IETF 2012. Acessado em 08/11/2012.

2. RFC6722, Publishing the “Tao of the IETF” as a Web Page P. Hoffman [ August 2012 ] (TXT = 6192) (Obsoletes RFC4677) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.

3. RFC4677, The Tao of IETF – A Novice’s Guide to the Internet Engineering Task Force P. Hoffman, S. Harris [ September 2006 ] (TXT = 127383) (Obsoletes RFC3160) (Obsoleted-By RFC6722) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.

4. Wikipédia. Taoismo. Acessado em 08/11/2012.

5. RFC3797. Publicly Verifiable Nominations Committee (NomCom) Random Selection D. Eastlake 3rd [ June 2004 ] (TXT = 39883) (Obsoletes RFC2777) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.

6. RFC3777. IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin [ June 2004 ] (TXT = 76395) (Obsoletes RFC2727) (Updated-By RFC5078, RFC5633, RFC5680) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: nomcom). Acessado em 08/11/2012.

7. ISOC Escritório Brasileiro. http://www.isoc.org.br/. Acessado em 08/11/2012.

8. Messages from the IAB/IESG Nominating Committee. https://datatracker.ietf.org/ann/nomcom/. Acessado em 08/11/2012.

9. List of IAB/IESG Nominating Committee Members (by year). https://www.ietf.org/nomcom/committee.html/. Acessado em 08/11/2012.

10. Scott Bradner. IETF Structure and Internet Standards Process. 85th IETF Atlanta, Georgia, USA, 2012. Disponível em: http://www.ietf.org/proceedings/85/slides/slides-85-edu-newcomers-0.pdf. Acessado em 02/01/2013.

11. RFC4071 (BCP101). Structure of the IETF Administrative Support Activity (IASA) R. Austein, B. Wijnen [ April 2005 ] (TXT = 48614) (Updated-By RFC4371) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 08/11/2012.

12. RFC2026. The Internet Standards Process — Revision 3 S. Bradner [ October 1996 ] (TXT = 86731) (Obsoletes RFC1602, RFC1871) (Updated-By RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC5657, RFC5742, RFC6410) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: poised95). Acessado em 10/11/2012.

13. Vint Cerf. IETF and the Internet Society: A bit of history. 18 July, 1995. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/ietf-and-internet-society. Acessado em 10/11/2012.

14. Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Larry G. Roberts, Stephen Wolff. Brief History of the Internet. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet. Acessado em 10/11/2012.

15. IETF. A Brief History of the Internet & Related Networks. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet-related-networks. Acessado em 10/11/2012.

16. Bruce Sterling. February 1993. Short History of the Internet. Disponível em http://www.internetsociety.org/internet/what-internet/history-internet/short-history-internet. Acessado em 10/11/2012.

17. Thomas Narten. IETF 81, Quebec City, Quebec. July 24, 2011. Bringing New Work to the IETF. Disponível em http://www.ietf.org/edu/documents/81IETF-New-Work.pdf. Acessado em 02/01/2012.

18. Alvaro Retana, Fernando Gont. Areas y Grupos de Trabajo en IETF. Lacnic XVIII, 2012. Disponível em https://www.dropbox.com/sh/4358z9df8dykn8l/GHZSPMjoSj/Acosta_28102012_IETF.pdf. Acessado em 03/01/2013.

19. RFC2026. The Internet Standards Process — Revision 3 S. Bradner [ October 1996 ] (TXT = 86731) (Obsoletes RFC1602, RFC1871) (Updated-By RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC5657, RFC5742, RFC6410) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: poised95). Acessado em 03/01/2013.

20. Alexis Simoneli. A Concise Guide to the Major Internet Bodies. January 2005. Disponível em http://ubiquity.acm.org/article.cfm?id=1071915. Acessado em 02/01/2012.

21. Danton Nunes. Proposta de um novo protocolo anti−spam
    complementar ao SPF. 34ª Reunião do GETER, 07/12/2012, São Paulo, SP. Disponível em ftp://ftp.registro.br/pub/gter/gter34/03-SPFrev.pdf. Acessado em 06/01/2013.

22. RFC5434. Considerations for Having a Successful Birds-of-a-Feather (BOF) Session T. Narten [ February 2009 ] (TXT = 33887) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 07/01/2013.

23. RFC2014. IRTF Research Group Guidelines and Procedures A. Weinrib, J. Postel [ October 1996 ] (TXT = 27507) (Also BCP0008) (Status: BEST CURRENT PRACTICE) (Stream: Legacy). Acessado em 13/01/2013.

24. RFC1690. Introducing the Internet Engineering and Planning Group (IEPG) G. Huston [ August 1994 ] (TXT = 3013) (Status: INFORMATIONAL) (Stream: Legacy) . Acessado em 10/02/2013.