Arquivo

Archive for the ‘IETF’ Category

WordIETF

Introdução

Este texto evolui as preocupações, grosso modo, em dar “inteligência” aos agentes (ou IEs – Intelligents Elements} do modelo AEASD (Autonomous Elements Architecture for Specific Domains), cuja origem foi na dissertação de mestrado e em discussões posteriores (Braga-Filho, 2015) (Braga; Omar; Granville, 2015).

Trata-se de uma evolução, e natural aperfeiçoamento, da contextualização e da maneira de enxergar o problema. É um processo de aprendizagem, contínuo, permanente e natural, na vida de um pesquisador. Como a visão de Charles Darwin1, na sua celebrada e incontestável teoria. Se eu vivesse eternamente, chegaria a um consenso preciso, sobre a questão principal. Não sendo eterno, a contribuição pode interessar aos mais jovens.

A Figura 1 do meu texto “Preparando as RFCs para o UIMA” (https://ii.blog.br/2016/01/08/preparando-as-rfcs-para-o-uima/) sofreu uma pequena alteração e apresenta-se como a Figura 1, a seguir.

 tese-modeloprincipalFigura 1. Novo modelo global.

O que mudou foram as ferramentas (item 5, na figura). O Apache UIMA não é a única ferramenta disponível. Em algumas etapas, mas simples, ele é dispensável. Existem muitas outras! O que torna mais complexo, o tratamento de textos, um assunto muitíssimo difícil, como falam inúmeros autores. Com a linguagem natural nem se fala. Basta ouvir o pensamento de Noam Chomsky1 de que a linguagem natural não constitui um domínio sobre o qual se podem construir teorias científicas coerentes, como escreve Neil Smith2 em seu longo prefácio do “Novos horizontes no estudo da linguagem e da mente” (Chomsky, 2005).

Trata-se neste texto, portanto, incorporar outras reflexões e mostrar a necessidade de se criar um dicionário léxico sobre as RFCs, como o objetivo de facilitar os trabalhos futuros. Este dicionário, em um domínio específico (sobre as RFCs) é similar ao WordNet3, que se nomeou de WordIETF.

Contextualização

Resumindo, o conjunto de dados (textos não estruturados), isto é, o corpora que se deseja incluir no projeto é mostrado na Figura 2.

tese-corpusFigura 2. Corpora que interessa ao projeto final e que deve ser tratado.

Por razões de simplicidade, os exercícios preliminares serão reduzidos a um único corpus, como mostra a Figura 3

tese-corpusunico
Figura 3. Corpus sob o qual a experiência preliminar será feita.

Simplificando, fica mais fácil seguir a proposta mostrada na Figura 4, que mostra a evolução atual do que se tem em mente, para o futuro.

tese-proposta
Figura 4. A atual evolução do modelo e as questões de pesquisa envolvidas: (2), (3) e (4).

O item (1) da figura acima está desenhado na Figura 2 do texto “Preparando as RFCs para o UIMA” (https://ii.blog.br/2016/01/08/preparando-as-rfcs-para-o-uima/). O item (2) representa uma das três questões de pesquisa que, de imediato, leva à criação de um dicionário léxico, WordIETF, consignado a partir do corpus, parte do RFC Editor4.

Como estabelecer o WordIETF

Em um livro bastante interessante sobre processamento de textos (Ingersoll; Morton; Farris, 2013), ferramentas do Apache são indicadas: Hadoop5, Lucene+Solr6 com o PyLucene, Mahout7 e o openNLP8. Tais ferramentas são, realmente, suficientes para resolver desafios no domínio de um texto, como mostra a Figura 5.

tamming-desafios
Figura 5. Desafios na mantipulação de textos.

O UIMA já foi parcialmente testado e as outras propostas da Apache serão verificadas. A Python, com o seu NLTK (Natural Languange Tool Kit), permite sem maiores esforços, a construção do WordIETF e resolver os desafios da Figura 5. Oportunamente serão descritas as experiências.

Uma outra ferramenta, que pode ser até mesmo complementar é o Mathematica4. Pode o Mathematica resolver os desafios e contribuir para a construção do WordIETF? A resposta é sim, com veremos em novos documentos mais à frente.

Conclusões

Trata-se de um projeto de pesquisa que exige a construção de um dicionário léxico, o WordIETF. Observa-se a necessidade de cooperação e contribuições de eventuais interessados.

Uma das maneiras de receber colaboração e contribuições é a divulgação no âmbito do IETF e de outras comunidades interessadas. Neste sentido, caso haja tempo hábil será enviado um I-D para o IETF 96 (Berlim), em julho próximo.

Resultados parciais e dificuldades encontradas, evolução e outras informações úteis serão postas neste blogue.

Referências

BRAGA-FILHO, L. J. Modelo para Implementação de Elementos Inteligentes em
Domínios Restritos da Infraestrutura da Internet
. Dissertação (Mestrado) — Universidade Presbiteriana Mackenzie, São Paulo, SP, 8 2015.

BRAGA, J.; OMAR, N.; GRANVILLE, L. Z. Uma proposta para o uso de elementos
inteligentes em domínios restritos da infraestrutura da internet. In: Anais CSBC, WPIETFIRTF. Recife, Pernambuco, Brasil: [s.n.], 2015

CHOMSKY, N. Novos horizontes no estudo da linguagem e da mente. [S.l.]: Unesp, 2005.

INGERSOLL, G. S.; MORTON, T. S.; FARRIS, A. L. Taming text: how to find, organize,
and manipulate it. [S.l.]: Manning Publications Co., 2013.


1. https://pt.wikipedia.org/wiki/Charles_Darwin
2. https://en.wikipedia.org/wiki/Neil_Smith_%28linguist%29
3. https://wordnet.princeton.edu/
4. https://www.rfc-editor.org/
5. http://hadoop.apache.org/
6. http://lucene.apache.org/index.htm
7. http://mahout.apache.org/
8. https://opennlp.apache.org/index.html
9. http://www.wolfram.com/

Anúncios
Categorias:Apache, IETF, Modelos, TCP/IP, WordIETF

Um Guia para modelar ontologias usando OWL-DL (GOL)

“…A atmosfera moral é magnífica para batráquios.
Não imaginas como andam propícios os tempos a todas as mediocridades. Estamos no período hilariante dos grandes homens-pulhas, dos Pachecos empavesados e dos Acácios triunfantes…”

Euclides da Cunha, em 1909, numa carta ao seu cunhado.

 

Apresentação

 

Web Ontology Language (OWL), (Hitzler, et al., 2009) é uma linguagem para Semantic Web, desenvolvida pelo World Wide Web Consortium (W3C) e está descrita formalmente por (Patel-Schneider, et al., 2004). A OWL é uma extensão da linguagem RDF Schema, (Hayes, 2004), com significativos recursos adicionais de expressividade, no aspecto da representação do conhecimento, objetivo da ontologia e usa a XML. Em relação à expressividade do conhecimento a OWL é classificada em OWL Full, OWL-DL e OWL Lite. A OWL Full é usada quando se deseja o máximo de expressividade e liberdade sintática, em relação à RDF Schema, mas que, na mesma proporção de seu poder, incorpora o fato de ser indecidível. A OWL-DL, menos poderosa do que a OWL Full, consegue compor recursos de expressividade satisfatórios, sem perder a completude e decidibilidade computacionais. Finalmente, a OWL Lite é uma linguagem com poder de expressividade extremamente pobre, muito embora seja de compreensão simples e é fácil de implementar em procedimentos automáticos. Neste contexto, a OWL-DL é a linguagem preferida para modelar ontologias.

Modelar, ou construir modelos que representem um domínio de interesse é um processo complicado e muitas vezes difícil. Isto se torna uma tarefa monumental e a recomendação é que seja um trabalho incremental (baseado em refinamentos sucessivos) e, sobretudo, que se siga um roteiro sistemático, o qual somente uma metodologia efetivamente consistente poderia satisfazer. Existem muitas propostas de metodologias e, a maioria delas é derivada de outras metodologias conhecidas, liderando com vantagens as áreas de desenvolvimento de software e de projetos em geral.

EagleOwl

O presente trabalho propõe um guia para o desenvolvimento de ontologias em OWL-DL, ao qual se dá o nome de GOL. Adicionalmente o trabalho segue o OpenStand descrito em (OpenStand, 2013) e, em seus princípios (OpenStand, 2012). Para estabelecer a proposta do GOL será desenvolvida uma abordagem orientada ao domínio de conhecimento associado à Infraestrutura da Internet.

O GOL responde às questões subjacentes à Figura 1, a qual exibe dois ambientes:

  • Seleção de ferramentas e técnicas para trabalhar na modelagem de ontologias.
  • Seleção e modificação de metodologias para o projeto, implementação e teste de ontologias.

 

guidetoModelOntology

Figura 1. As escolhas de um guia para modelar ontologias (GOL).

 

Os ambientes são derivados de metodologias conhecidas no desenvolvimento de sistemas e programas, como já foi dito acima, coincidindo o primeiro ambiente com o tópico Requirements and Analysis, e, o segundo ambiente associa-se ao tópico Design, Implement and Test, ambos baseados no Unified Process (UP), de (Jacobson, et al., 1999). Esta relação está bem caraterizada em uma das metodologias analisadas para o GOL, chamada Unified Process for ONtology (UPON), descrita por (Nicola, et al., 2009).

Após as avaliações sobre os recursos disponíveis nos dois ambientes, o trabalho propõe o GOL, conforme a Figura 2 com as escolhas possíveis entre as alternativas estudadas.

Por outro lado, o GOL, ao indicar uma metodologia, atenta para o fato de que ela seja versátil, o suficiente, e capaz de permitir mudanças, a critério das habilidades e perfis de grupos e pessoas envolvidas no desenvolvimento de ontologias sem, contudo descaracterizar o resultado final que se espera quando é usada a OWL-DL.

 

guidetoModelOntology-final

Figura 2. A estrutura final (enxuta), do EOWL.

 

Para validar o GOL, um projeto envolvendo um subdomínio do imenso domínio de conhecimento agregado à Infraestrutura da Internet. A escolha recai sobre os recursos de numeração, cuja atribuição / distribuição é feita pelo IANA. Propositalmente, a escolha origina um estudo para aplicação da Web Semântica, na direção de tornar os administradores de recursos da Internet, confortáveis diante de suas responsabilidades.

 

Bibliografia

 

  • Fernández López M. Overview of Methodologies For Building Ontologies [Conference] // Proceedings of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5) / ed. Benjamins V. R. [et al.]. – Stockholm, Sweden : [s.n.], August 2, 1999.
  • Hayes, P., 2004. RDF Semantics. [Online] Available at: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
    [Acesso em 18 maio 2013].
  • Hitzler, P., Krötzsch, M., Parsia, B. & Patel-Schneider, P. F., 2009. OWL 2 Web Ontology Language Primer. [Online] Available at: http://www.w3.org/TR/2009/REC-owl2-primer-20091027/ [Acesso em 19 maio 2013].
  • IANA, 2013. Autonomous System (AS) Numbers. [Online] Available at: http://www.iana.org/assignments/as-numbers/as-numbers.xml [Acesso em 17 maio 2013].
  • Jacobson, I., Booch, G. & Rumbaugh, J., 1999. The Unified Software Develop-. s.l.:Addison Wesley, USA.
  • Nicola, A. D., Missikoff, M. & Navigli, R., 2009. A Software Engineering Approach to Ontology Building. Information Systems, 34(2), Elsevier, pp. 258-275.
  • OpenStand, 2012. Principles. [Online] Available at: http://open-stand.org/principles/ [Acesso em 17 maio 2013].
  • OpenStand, 2013. About. [Online] Available at: http://open-stand.org/about-us/ [Acesso em 2013].
  • Patel-Schneider, P. F., Hayes, P. & Horrocks, I., 2004. OWL Web Ontology Language Semantics and Abstract Syntax. [Online] Available at: http://www.w3.org/TR/2004/REC-owl-semantics-20040210.

Entendendo RFCs

 

Introdução

 

Por várias vezes foi falado neste blogue, que não dá para procurar e ler um RFC, sem a listagem do RFC Index, em ordem numérica, numa tela de navegador. É o que mostra a Figura 1, parcialmente.

 

PaginaRFCs

Figura 1. Listagem parcial de RFCs, por número.

 

O RFC mais importante, para entender RFCs é o RFC20264. A Figura 2 mostra como a referência aparece no RFC Index. Tudo o que é apresentado nas três linhas da Figura 2, está explicado no início da página do RFC Index, e seria muito proveitoso, entender, principalmente o que está em vermelho.

 

trecho2026

Figura 2. A referência de um RFC.

 

Não marcado na Figura 2, está (TXT = 86731), que diz estar o RFC20264, no formato ASCII, com 86.731 caracteres. Outros formatos possíveis para um RFC são o PostScript (PS) e o PDF. Já marcado, na sequência está Obsoletes indicando que o RFC20264 torna obsoleto ou substitui dois outros RFCs. Mas, uma palavra parecida e muito mais importante é Obsoleted by, que embora não apareça na descrição do RFC2026 poderia, quando for o caso, evitar perda de tempo, sabendo que um determinado RFC foi substituído por outro. Duas importantes informações, que geralmente não são consideradas, Status e Stream são as principais motivações deste texto.

Na medida do possível, não será apresentado neste texto, a interpretação de siglas, como por exemplo, a sigla RFC. Mas se necessário pode-se recorrer à Tabela 1 do artigo A ISOC, o IETF e a infraestrutura da Internet. Uma outra dúvida que aparece é o tratamento dado ao RFC. Está sendo usado “o”, ao invés de “a”. Tanto faz. O artigo masculino está sendo preferido indicando que a tradução para “Request” será “Pedido”. Esta correção de gênero está sendo feita somente a partir do presente artigo, já que nos artigos passados do blogue, foi dado preferência ao gênero feminino. No início irá parecer um pouco estranho, na língua portuguesa.


Nota: Experimentalmente há um espelhamendo do RFC Index, em ordem decrescente pelo número do RFC, aqui. Foi usado a recomendação contida em How to use rsync to download documents from the RFC Editor Repository, e um programa em PHP analisa o arquivo em XML, rfc-index.xml, para obter um formato bem próximo ao do RFC Index, mostrado na Figura 1.


 

Quem pode escrever um RFC?

 

Qualquer ser humano pode escrever um RFC, desde que o faça, em inglês e siga a formatação recomendada. Para ser publicada, entretanto, ela deve passar por algumas etapas bem definidas. Tais etapas, a formatação e os tipos de RFCs estão descritas em dezenas de RFCs…

A publicação e o repositório de RFCs são de responsabilidade do RFC Editor, embora não pareça à primeira vista é formado por um conjunto de pessoas (e, de organizações), que atuam sobre um emaranhado complexo de normas, regras e definições, para eficazmente expor, de maneira simples, um imenso conhecimento sobre a Internet, seus protocolos e milhares de outras informações úteis a pessoas e instituições envolvidas e / ou interessadas. No passado, entretanto, o RFC Editor era uma única pessoa: Jon Postel. Foi Postel quem estabeleceu o perfeito funcionamento do RFC Editor, e em FAQs2 tem-se um bom lugar para entender muito a respeito. Um cenário simplificado em torno do RFC Editor é mostrado na Figura 3.

 

rfcEditor

Figura 3. O cenário em torno do RFC Editor.

 

O RFC Editor cuida da publicação e o repositório de RFCs. Este pode ou não se tornar um RFC. O repositório dos RFCs está no ambiente do RFC Editor, enquanto que o repositório de Internet-Drafts está no ambiente dos Grupos de Trabalhos. No passado já tivemos outros tipos de documentos, como os chamados FYI (For You Information), que desde o RFC636010, não existem mais. As regras de um Internet-Draft estão muito claras em Guidelines to Authors of Internet-Drafts.

Os membros do RFC Editor são determinados pelo IAB e pelo IAOC, que usam, quando necessário, o NomCom. O suporte financeiro e administrativo é dado pelo IASA. Este relacionamento do RFC Editor como o IAB, IAOC e IASA, estão muito bem definidos em RFCs. O IAB exerce funções de supervisão e monitoramento do RFC Editor, também, caracterizadas em RFCs.

Os I-Ds, ao longo do tempo, após uma sequência de encaminhamentos transformam-se em RFCs. O I-Ds são produzidos pelos participantes dos WGs ou individualmente (produção independente). O IESG é a organização envolvida na autorização final para que o RFC Editor publique formalmente um I-D, como um RFC.

O IAB tem privilégios na publicação de documentos, exceto aqueles que envolvam propostas diretamente ligadas ao IETF. Neste caso, o documento é enviado para o IETF, submetido a avaliações e debates tradicionais, para em seguida ser autorizado pelo IESG. O IESG tem sempre a palavra final, pois mesmo um documento informal ou que veio de uma submissão independente pode estar em conflito com alguma norma, regra ou padrão envolvendo a Internet. O RFC Editor é muito cuidadoso e hábil em relação a isto, envolvendo-se sistematicamente com o IESG, o que dá segurança a todo o repositório.

 

Tipos de documentos e as submissões (“stream“)

 

O RFC é dividido em outros tipos, denominados sub-séries. Algumas outras formas de identificar os documentos do RFC Editor podem ser usados, como por exemplo em RFCs by Category.

Na Figura 3 são três as sub-séries identificadas pela categoria Standard Track: Proposed Standard, Draft Standard e Internet Standard, este recentemente denominado, simplesmente Standard. São, tipicamente, documentos produzidos pelo IETF, cujo caracterização é definida no RFC202, item 4, e são identificados como níveis de maturidade. Complementarmente, o RFC5000, detalha o tratamento dado pelo RFC Editor, aos documentos dos níveis de maturidade. O RFC20264, também, regula as publicações do tipo Internet-Draft, que na prática podem anteceder os níveis de maturidade e são produzidos dentro dos WGs do IETF. Da mesma forma, a RFC2026, inclui em suas caracterizações, as séries Informational e Experimental, o que faz com que o RFC Editor adote critérios que podem envolver o IAB e o IESG. Neste sentido, estes dois tipos de documentos (Informational e Experimental) podem sofrer um processo de quarentena, adequado período de avaliação e debates. Se os documentos destes dois tipos são produzidos pelos WGs, necessariamente devem ser submetidos ao IESG, por uma razão de motivos, descritos no item 4.2.3, do RFC20264. Mais recentemente, uma atualização do RFC20264, o RFC6410, propõe dois níveis de maturidade, ao invés de três.

A sub-série Historic está caracterizada no item 4.2.4 da RFC20264. Da mesma forma, a sub-série Best Current Practice, descrita no item 5 é considerada um nível de maturidade elevado, representando o ponto de vista de uma comunidade sobre o que é melhor, no que diz respeito ao domínio de sua aplicação. Muitos RFCs aparecem a palavra “unknown“, no “status“, o que significa que foram publicadas antes da definição formal.

As submissões independentes foram atualizadas pelo RFC5742, onde os critérios de revisão a serem adotados pelo IESG estão bem qualificados.

Finalmente é bom lembrar que a palavra submissão é uma tradução livre para stream. Stream está caracterizado na referência de um RFC, como mostrado na Figura 2. No exemplo, da Figura 2, o RFC20264 foi submetido pelo IETF. Quando a submissão vem do IETF, a palavra “Area” é adicionada, para identificar a área do IETF e o respectivo WG, que deu origem ao documento. A Figura 4 exibe as possíveis submissões ou valores do “stream”.

 

stream

Figura 4. Submissões possíveis.

 

As submissões do IRTF estão reguladas pelo RFC5743, também, complementadas pelo RFC48446.

As submissões independentes estão reguladas pelo RFC4846. A submissão independente deve ser feita diretamente ao RFC Editor, na forma de Internet-Drafts.

 

Como escrever um RFC ou Internet-Draft

 

Existem ferramentas que facilitam a criação de documentos, seguindo as normas do RFC Editor. Existe disponível, o completo Tutorial: Tools for Creating I-Ds, e mais um outro, RFCs & the RFC Editor: A Tutorial. Complementarmente, o RFC2360 é um guia para quem pretende escrever um documento sobre padrões, que pode ser complementado pelo RFC2223 e o RFC57418.

 

Conclusões

 

É importante lembrar, que o começo para o entendimento completo sobre os documentos do RFC Editor está no RFC20264 e na sua página principal. Entender detalhadamente, as regras que norteiam o trabalho do RFC Editor, apesar de muitíssimo importante é uma tarefa árdua, senão impossível. A Figura 3, juntamente com este texto é apenas uma demonstração da complexidade, mas caracteriza muito bem a isenção e confiabilidade da documentação que faz a Internet funcionar. O melhor que se tem a fazer é, após a identificação do trabalho a ser realizado, partir para efetivamente escrever o documento. Nesta oportunidade, as coisas ficarão mais claras e fáceis de entender, em particular, o percurso que um documento até chegar a um RFC publicado.

 

Artigos Relacionados

 

 

Referências

 

  1. RFC Editor FAQs. Acessado em 02/02/2013.

  2. RFC1796 Not All RFCs are Standards C. Huitema, J. Postel, S. Crocker [ April 1995 ] (TXT = 7049) (Status: INFORMATIONAL) (Stream: Legacy). Acessado em 02/02/2013.

  3. RFC Editor FAQs. Acessado em 02/02/2013.

  4. 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 02/02/2013.

  5. RFC2119 Key words for use in RFCs to Indicate Requirement Levels S. Bradner [ March 1997 ] (TXT = 4723) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (Stream: Legacy). Acessado em 01/02/2013.

  6. RFC4844 The RFC Series and RFC Editor L. Daigle, Internet Architecture Board [ July 2007 ] (TXT = 38752) (Updated-By RFC5741) (Status: INFORMATIONAL) (Stream: IAB). Acessado em 01/02/2013.

  7. RFC4845 Process for Publication of IAB RFCs L. Daigle, Internet Architecture Board [ July 2007 ] (TXT = 9228) (Status: INFORMATIONAL) (Stream: IAB). Acessado em 01/02/2013.

  8. RFC5741 RFC Streams, Headers, and Boilerplates L. Daigle, O. Kolkman, IAB [ December 2009 ] (TXT = 32160) (Updates RFC2223, RFC4844) (Status: INFORMATIONAL) (Stream: IAB). Acessado em 02/02/2013.

  9. RFC5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions H. Alvestrand, R. Housley [ December 2009 ] (TXT = 21067) (Obsoletes RFC3932) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 02/02/2013.

  10. RFC6360 Conclusion of FYI RFC Sub-Series R. Housley [ August 2011 ] (TXT = 4729) (Obsoletes RFC1150) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP). Acessado em 01/02/2013.

Categorias:IAB, IAOC, IESG, IETF, ISOC, RFCs, TCP/IP

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

Atualizado em 10/11/2013 17:20.

 

Introdução

 

Atualmente os encontros do IETF tem sido em número de três, por ano, geralmente realizados nos seguintes locais, do mundo: América do Norte, Europa e Ásia. A Tabela 1 exibe os encontros do IETF já programados.

Encontro
Ano
Mês
Local
IETF 89 2014 Março Londres
IETF 90 2014 Julho Toronto
IETF 91 2014 Novembro Honolulu
IETF 92 2015 Março Dalas
IETF 93 2015 Julho Praga
IETF 94 2015 Novembro Yokohama
IETF 95 2016 Abril Europa
IETF 96 2016 Julho América do Norte
IETF 97 2016 Novembro Ásia

Tabela 1. Próximos encontros do IETF
Fonte: IETF Upcoming IETF Meetings.

 

Maneiras de participar

 

Pode-se participar dos encontros do IETF, presencialmente ou remotamente. A participação presencial implica em arcar com todas as despesas de viagem e estada, incluindo a taxa de registro no evento (Figura 2). A Internet Society oferece algumas bolsas para a participação presencial. A participação remota é gratuita e completa, no sentido de participação efetiva, apenas exigindo o uso de ferramentas apropriadas. Presencial, remota ou como bolsista, o IETF oferece um conjunto de facilidades para quem participa pela primeira vez. A melhor maneira de enxergar tais alternativas é acessar a página do evento. A Figura 1 exibe a programação parcial do IETF 86, que irá acontecer em março de 2013. Os anais e resultados completos das reuniões passadas possuem suas próprias páginas disponíveis em Past Meetings.

 

ProgramacaoIETF86

Figura 1. Visão parcial da programação do IETF 86. Fonte: IETF 86 – Orlando, FL, USA.

 

Na Figura 2, estão anotados em vermelho, os pontos importantes. Em particular, a ênfase dada aos participantes de primeira vez (New Attendees), os quais são chamados a compor uma série de eventos preliminares (um dia antes do encontro), com o objetivo de indicar o funcionamento do encontro do IETF, para que a oportunidade seja proveitosa e maximizada. Uma referência importante e exclarecedora é The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force, com sua tradução em português, aqui.

 

Participação presencial

 

Em Register aparecem as instruções e regras para a inscrição, conforme mostra a Figura 2, seguindo do respectivo formulário. Estão visíveis, os valores das taxas de inscrição, que variam de acordo com datas. Atenção ao fato de que estudantes são favorecidos por uma taxa de inscrição bem mais em conta.

 

Participação remota

 

Cada encontro possui uma completa facilidade para participação remota e estão disponíveis, para o IETF 86, em Remote Participation at IETF 88. A informação é extensiva, no sentido de que tudo é muito bem documentado. As facilidades passivas (audio e vídeo) são complementadas pelas facilidades ativas (Jabber/XMPP Groupchat, WebEx e Meetecho), com os respectivos tutoriais referenciados. São facilidades que atendem, na plenitude, o participante remoto, inclusive, com mobilidade. No máximo exige uma pequena preparação antecipada. A organização dos recursos remotos está bem estruturada e orientada pela Agenda.

 

Bolsas

 

A ISOC (Internet Society) oferece diversas bolsas voltadas à participação em suas atividades, uma delas para apoiar diretamente a presença em encontros do IETF (The Internet Society Fellowship to the Internet Engineering Task Force (IETF) Programme). A participação em outros programas de bolsas agregam valor ao pedido de bolsa para participação no IETF.

A bolsa para participação nos encontros do IETF são de dois tipos: primeira participação (em um dos eventos do ano) e retorno (a um evento no próximo ano). Não há limite de idade e inclui:

  • Passagens, acomodação (no hotel do evento), taxas de inscrição e entrada para o evento social do encontro;
  • Disponibilidade de um mentor, que ajudará o bolsista a se preparar para participar na área de interesse, facilitar o relacionamento com outros participantes e garantir a movimentação no encontro, durante toda a semana de duração;
  • Uma ajuda financeira para despesas diversas (~ US$400.00);
  • Certificado de participação.

O critério de seleção é bastante competitivo (mais de 200 candidatos para, aproximadamente 10 bolsas). Os requisitos para a qualificação (Selection Criteria for Fellowships to the IETF) são, resumidamente, os seguintes:

  • Ser membro da Internet Society;
  • Possuir grau universitário em ciência da computação, tecnologia da informação, ou equivalente, ou ainda, demonstrar experiência relevante nestas áreas;
  • Ser membro de uma organização com atividades associadas a redes, instituição de ensino, pesquisa e participante de programas de mestrado e doutorado com objetivos afins;
  • Possuir completa noção da influência do IETF no seu contexto de interesse ou demonstrar a importância de áreas do IETF sobre seu trabalho atual;
  • Demonstrar uma forte razão para participar de encontros do IETF relatando a influência dos trabalhos do IETF sobre seu próprio trabalho, estudo ou pesquisa, quando retornar a seu país;
  • Apresentar um plano para compartilhar a experiência e conhecimento adquiridos no encontro do IETF, com outras pessoas na sua área ou região locais;
  • Residir em um país em desenvolvimento e que tenha baixa frequência de participação no IETF;
  • Necessitar de apoio para participar de um encontro do IETF e mesmo que não tenha sido selecionado em tentativa anteriores;
  • Seguir um ou mais Grupos de Trabalho (WGs) do IETF.

O inglês é a língua oficial do IETF. Ouvir, escrever e falar com razoável fluência é um requisito essencial. Por outro lado, a sistemática participação em atividades promovidas por instituições locais, responsáveis por aplicações de recomendações ou de gerenciar recursos de rede de dados (LACNIC, NI.br, etc.) é fortemente positiva na seleção.

 


Nota 1: O IETF apoia diversas outras formas de participação, identificadas como IETF and OIS Programmes que, além das bolsas incluem: reguladores, mentores e participação no Centro de Engajamento Remoto (IETF Remote Engagement Hub). Acompanhe as atividades, resumidas, do IETF e da ISOC em http://ietf.protocolos.net.br.


 

Participantes dos encontros do IETF

 

Os anais de todos os encontros, exceto do IETF 5 encontram-se em Past Meetings

A primeira participação de brasileiros, em encontros do IETF aconteceu no IETF 36, realizado entre os dias 24 e 28 de junho de 1996 em Montreal, Quebec, CA.

 

Ano
Participantes
Brasileiros
1986
95
0
1987
280
0
1988
308
0
1989
589
0
1990
1025
0
1991
1107
0
1992
1840
0
1993
1767
0
1994
2574
0
1995
2607
0
1996
4314
2
1997
4526
5
1998
6005
3
1999
5794
1
Ano
Participantes
Brasileiros
2000
6585
2
2001
5739
1
2002
5111
3
2003
4216
5
2004
4161
3
2005
3823
6
2006
3766
7
2007
3496
7
2008
3451
8
2009
3814
16
2010
4006
24
2011
3627
17
2012
4249
20
2013
4171
32

Tabela 1. Participação presencial geral e de brasileiros nas reuniões anuais do IETF.
Fonte: IETF Past Meetings.


Nota 2: Foram realizados 88 encontros desde 1986 até 2013. A partir de 1991, as reuniões anuais passaram a ser em número de 3. Em cada um dos anos de 1986, 1987, 1989 e 1990 ocorreram 4 encontros. Em 1988, foram 3 encontros. Os anais do IETF 5, em 1987 não foram encontrados, até o momento. Muito embora seja cedo para afirmar, houve um aumento na participação dos brasileiros em 2013, ano em que houve diversas iniciativas de divulgar o IETF, no Brasil e na América Latina (foi criada a lista IETF-LAC – ietf-lac@lacnog.org – pelo Lacnic). Para o próximo ano poderemos ter certeza se esta tendência será mantida, pois várias outras iniciativas estão em andamento, como o Livro do IETF – em português e espanhol, promovido pelo CGI.br -, e as provocações de reuniões complementares do IETF, não oficiais, associadas aos eventos da América Latina.


 

IETF-Atendees1

Figura 3. Participação presencial anual, nos encontros do IETF. Fonte: IETF Past Meetings.

 

 

Uma das principais conclusões após a análise do gráfico da Figura 3 é o fato de que a participação brasileira ser muito pequena (embora, crescente em 2013). Também, de imediato, observa-se um declínio na participação global nas reuniões do IETF, embora com pequeno avanço em 2012. Estas avaliações nos levam a desejar um debate no sentido melhorar as duas participações, global e brasileira. Este debate poderia, por exemplo, partir de uma proposta para diminuir para dois encontros anuais e acrescentar dois eventos anuais por região do planeta digamos, no domínio dos RIRs, que antecederiam em três meses, a cada um dos dois encontros do IETF. Naturalmente, tal proposta deverá conter argumentos suficientes para ser exposta aos participantes de encontros do IETF, que decidiriam por sua viabilidade e interesse nas mudanças. Os encontros regionais, promovidos por instituições relevantes – por exemplo, o LACNIC, quando se tratar da América Latina – iriam encontrar respaldo, também, para o aumento dos recursos de bolsas oferecendo oportunidades para candidatos avaliados regionalmente, que seguindo as regras já estabelecidas sejam qualificados para os encontros centrais.

O movimento das inscrições no IETF 86, por país e pelos RIRs, está disponível em tempo real na página RIR and Country Participation in IETF 86, IPv6 (preferencialmente) e IPv4, com base no IETF Meeting Registration System. Complementarmente, o levantamento das participações nos encontros que ocorreram a partir dos dois últimos do ano de 2008 até o ano de 2012, encontra-se disponível em RIR and Country Participation in IETF, com base nas informações contidas em Past Meetings, possíveis de se obter automaticamente. Estatísticas de atividades relacionadas com a participação em trabalhos podem ser encontradas em Document Statistics (What’s Going on in the IETF?), que embora muito importantes, fogem do escopo inicial deste texto, uma vez que ele se concentra nas inscrições presenciais dos encontros do IETF. Além do mais, sendo o IETF uma organização que depende do trabalho voluntário e, portanto, extremamente importante, também, não foi considerado. As considerações sobre o que não mereceu atenção, no presente texto devem, naturalmente, chamar atenção especial do autor ou de terceiros, em futuras observações. As informações coletadas estão disponíveis em base de dados MySQL e podem ser solicitadas, por quem as solicitar ou podem ser obtidas nas páginas referenciadas, construídas para facilitar esse trabalho.

 

Artigos Relacionados

 

Categorias:IETF, ISOC, TCP/IP Tags:,

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

 

Introdução

 

Para quem atua na infraestrutura da Internet pela primeira vez e até mesmo depois de anos de experiência consegue compreender parte do funcionamento e da estrutura do IETF. Mas não consegue entender como funciona o IETF, na prática. A principal dificuldade é não imaginar, de imediato, que o IETF NÃO é uma instituição ou organização privada. A dificuldade aumenta um pouco mais, quando se percebe que o IETF não tem endereço fixo ou um representante central para onde flui o que lhe diz respeito. Piora um pouco quando percebe-se que o IETF é um grupo de pessoas que participam de suas atividades, independentemente, sem influências de qualquer entidade organizada (pública ou privada). Este grupo de pessoas tem uma instituição que preserva esta independência, abrigando suas atividades, sem exercer nenhuma influência: a ISOC. Mas, as pessoas chaves que coordenam seus interesses e ajuda no entendimento sereno de todos os participantes estão ligadas ao IESG. Estas pessoas são os Presidentes das áreas (8) e os responsáveis pelos WGs. Tais responsáveis (pelas áreas e pelos WGs) não possuem nenhuma influência sobre o IETF (isto é, sobre o grande grupo). São abnegados e experientes profissionais, que encaminham para que tudo dê certo no objetivo final de definir os comportamentos adequados para a Internet. Em outras palavras, para a criação de normas, recomendações e práticas, que por serem efetivas e eficazes, se tornam padrões.

Quando uma proposta é considerada pronta, pelo grupo, ela é encaminhada a um outro grupo chamado IESG, que seguindo regras pré-estabelecidas, conduz a avaliação técnica da proposta. O IESG também possui pessoas que coordenam, sem influência pessoal, o prosseguimento sob as normas estabelecidas.

Com um olhar mais técnico e cuidadoso, o IAB, outro grupo intimamente ligado ao IETF e ao IESG, também, sob o guarda chuva da ISOC, refina os trabalhos do IETF, encaminhados através do IESG, de forma que se garanta a sua aplicabilidade ou viabilidade de divulgação (através das RFCs).. O IAB possui diversas pessoas que dão suporte às suas atividades e responsabilidades.

Por fim, para que as reuniões do IETF possam funcionar adequadamente, os recursos sejam disponibilizados sem problemas e, no geral, liberar as pessoas (os grupos que formam IETF, IESG e IAB), de preocupações de natureza administrativa e financeira, existe o IAOC. O IAOC, por seu lado possui pessoas que cuidam de seus afazeres adequadamente, e também, seguindo regras bem definidas.

A nomeação dos dirigentes do IESG, IAB e IAOC, incluindo os impedimentos são de responsabilidade de um outro grupo denominado Comitê de Nomeações (Nominating Committee), ou como é mais conhecido, NomCom, cuja descrição é feita a seguir.

 


Nota 1: Alguns e-mails trocados com S. Moonesamy, da República do Maurício, ISOC Fellow ajudaram na compreensão mais refinada do IETF.

Nota 2: D-75, significa que faltam 75 dias para o início do IETF 86.


 

O NomCom

 

O NomCom está apresentado em IETF NomCom, no sítio do IETF. O NomCom foi criado com o objetivo de analisar cada cargo disponível no IESG, IAB, e IAOC, e providenciar seu preenchimento, em datas de nomeções normais ou por impedimento. A estrutura funcional do NomCom possui os seguintes componentes: um Presidente (chair), sem direito a voto, 10 voluntários com direito a voto, 2-3 elementos de ligação (liaison) e um conselheiro (advisor). As obrigações de cada um, suas respectivas funções bem como as regras para se candidatar ao preenchimento das vagas disponíveis são definidas pela RFC37771. A RFC3777 possui quatro atualizações, que substituem alguns de seus itens, aperfeiçoando o processo. São elas: a RFC50782, a RFC56333, a RFC56804, e a RFC56806

NomCom

O Presidente do NomCom é nomeado pelo Presidente da ISOC. Os candidatos voluntários (10) são escolhidos através de um complexo mecanismo randômico, como caracterizado pela RFC37975, a partir de indicações dos próprios interessados. Há algumas poucas restrições para que uma pessoa se candidate como voluntário, na pressuposição de que ele tenha uma experiência mínima no IETF. Os elementos de ligações são indicados pelo IESG, pelo IAB e, eventualmente, pelo Conselho de Curadores (Board of Trustees) da ISOC. O conselheiro é o Presidente da gestão anterior.

Assim, o NomCom exerce um papel muito importante, na organização do caos!

 


Observações: O IETF utiliza-se dos elementos de ligações (liaisons) em diversas atividades, principalmente, naquelas que se relacionam com outras organizações responsáveis por padrões. Nestes casos, o NomCom, não é acionado, mas sim o IAB, que coordena todas as atividades que os envolvem. As regras e normas associadas são definidas pela RFC4052 e a referência inicial pode ser vista em Liaisons. A lista dos atuais participantes está apresentada em Liaison Managers e os documentos que estabelecem as iniciativas formais, em Liaison Statements.


 

Artigos Relacionados

 

 

Referências

 

  1. 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).

  2. RFC5078. IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline S. Dawkins [ October 2007 ] (TXT = 19870) (Updates RFC3777) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP).

  3. RFC5633. Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers S. Dawkins [ August 2009 ] (TXT = 11117) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP).

  4. RFC5680. The Nominating Committee Process: Open Disclosure of Willing Nominees S. Dawkins [ October 2009 ] (TXT = 14296) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP).

  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).

  6. RFC6859. Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership B. Leiba [ January 2013 ] (TXT = 5619) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP).

Categorias:IAB, IAOC, IESG, IETF, ISOC, liaison, TCP/IP Tags:

A ISOC, o IETF e a infraestrutura da Internet

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.

Ideogama yang-ying, do Taoismo

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

Tao (pronuncia-se dao), no Taoismo4 (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 Hoffman1 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!

Sigla Inglês Português
AD Area Director Diretor de Área. Cada área (dividida em WGs) possui uma AD com um ou mais membros. O AD é responsável pela orientação / gerenciamento dos respectivos WGs. Os membros de cada AD podem ser vistos aqui
BCP Best Current Practice Melhores práticas correntes
BOF Birds of a Feather

Grupo de debate informal. Geralmente precede a formação de um WG. Um BOF pode ser convocado para debates sobre uma questão que, eventualmente, não será transformada em um WG.

FAQ Frequently Asked Question(s) Perguntas mais frequentes
FYI For Your Information Para sua informação
IAB6,9,10 Internet Architecture Board Conselho de arquitetura da Internet. Na criação de WGs, o IAB recomenda ou “aconselha”, a respeito.
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.
IASA12 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

Esboço da Internet. São os documentos de trabalho do IETF, de suas áreas, e de seus grupos. Durante o desenvolvimento de uma especificação, versões preliminares do documento estarão disponíveis no diretório de I-Ds do IETF, para revisão informal e comentários. Isso faz com que um documento de trabalho esteja disponível a um público amplo facilitando o processo de avaliação, revisão e, consequentemente, de evolução. No diretórios estão os I-Ds atuais e passados.

IEPG24 Internet Engineering and Planning Group

Grupo de Engenharia e Planejamento da Internet. É um encontro informal que se reúne no domingo, antes das reuniões da IETF em que são abordados temas de relevância operacional, além de avaliar outros temas, que despertam interesse, no momento.

IESG6,9,10 Internet Engineering Steering Group

Grupo de direção de engenharia da Internet. O IESG é responsável pelo gerenciamento técnico das atividades do IETF e do processo de desenvolvimento de padrões. Como parte da ISOC o IESG administra os processos de acordo com as regras e procedimentos ratificados pelos membros da administração superior da ISOC. O IESG é diretamente responsável pelas ações associadas ao acompanhamento do movimento dos padrões, incluindo a aprovação final das especificações.

IETF Internet Engineering Task Force Força de tarefas de engenharia da Internet
IPR Intellectual Property Rights Direitos de propriedade intelectual
IRSG Internet Research Steering Group Grupo de orientação de pesquisa da Internet
IRTF23 Internet Research Task Force

Força tarefa de pesquisa da Internet. A missão da IRTF é promover investigação de importância para a evolução da Internet do futuro, criando focos, grupos de pesquisa de longo e curto prazos, que trabalham em temas relacionados aos protocolos de Internet, aplicações, arquitetura e tecnologia.

ISOC7 Internet Society

Internet Society. É uma associação sem fins lucrativos, criada em 1992, com atuação internacional, que tem por objetivo promover liderança no desenvolvimento dos padrões Internet, bem como fomentar iniciativas educacionais e políticas públicas ligadas à rede mundial entre computadores. O escritório brasileiro da ISOC possui diversas informações adicionais, entre as quais, os estatutos e formas de associação.

NomCom5,6,8 Nominating Committee

Comitê de nomeação. Seu objetivo é analisar cada posição (cargo) em aberto no IESG, IAB e IAOC e nomear respectivos candidatos. Ele é composto de pelo menos um coordenador (“chair”), nomeado pelo Presidente da ISOC, 10 voluntários votantes, 2 a 3 membros de contatos (“liaisons”), e um assessor. O presidente do NomCom é apontado entre as primeira e segunda reuniões do ano, e um novo NomCom começa oficialmente o seu trabalho. Associar-se à ISOC é o primeiro passo para participar, efetivamente, do IETF, muito embora não seja mandatório.

RFC Request for Comments RFC
STD Standard (RFC) Padrões (RFC)
W3C World Wide Web Consortium Consórcio do WWW.
WG Working Group

Grupo de trabalho. É onde tudo começa no IETF. WGs são o mecanismos primários para o desenvolvimento de especificações do IETF e diretrizes, muitas das quais se destinam a ser os padrões ou recomendações. WGs são tipicamente criados para resolver um problema específico ou para a produção de um ou mais resultados específicos (uma diretriz, especificação de normas, etc.).Um WG possui uma existência temporária e é mantido o histórico dos WGs concluídos aqui. Em 05/01/2013 haviam 126 WGs ativos: veja aqui.

WGLC Working Group Last Call

Grupo de Trabalho Última Chamada. É uma última chamada dentro de um WG (realizada na lista), antes de um documento ser enviado ao IESG para consideração.

 

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.

 

ISOC-ICANN-W3C

Figura 1. A relação da ISOC e as atividades que influenciam no comportamento da Internet.

 

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 RFC202619. 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 Simoneli20, 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”14, onde mostram a linha de tempo, reproduzida na Figura 2.

 

Figura 2. Linha do tempo da formação da estrutura mostrada na Figura 1. Reproduzida de [14].

 

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:

  1. É constituído de participantes e não de membros.
  2. Os padrões que saem do trabalho executado pelo IETF, não são padrões impostos sobre uma área técnica ou sobre instituições públicas ou privadas. São padrões porque as pessoas ou organizações, simplesmente, os usam. Por outro lado, instituições oficiais / formais, criadas para definir padrões no mundo acabam recomendando ou “oficializando” os resultados do IETF.
  3. Existe um coordenador, nomeado pela comunidade, que é também membro do IAB e o AD da área geral (General Area).
  4. Cada área possui dois ADs, exceto a General Area. São responsáveis pela coordenação, e aprovam a criação de BOFs e WGs, além revisar os documentos do WG antes de serem enviados ao IESG.
  5. A administração do IETF é de responsabilidade da IASA que, não possui autoridade sobre os procedimentos que desenvolvem padrões.
  6. O trabalho do IETF é feito nos WGs ou durante os encontros, por iniciativa dos participantes e segue um esquema de baixo para cima, muitas vezes iniciando-se em um BOF (mas, não necessariamente).
  7. O BOF, geralmente precede um WG e é criado a partir do interesse de um grupo de participantes (ou mesmo de um só participante), por um determinado assunto.

  8. Para se criar um BOF é necessário convencer um AD. Feito isto o BOF é agendado e, usualmente ocorre uma única reunião. No final, o BOF pode resultar ou não, na criação de um WG.
  9. O WG é formado por participantes. Nada é votado em um WG. A aprovação é por consenso (ou um código funcionando), e não há necessidade de unanimidade, pois o coordenador é quem decide se há consenso (apesar de ser um fato reconhecido pelos participantes). Se houver disputas, então prevalece o debate entre os participantes, na lista do grupo ou nos encontros do IETF. A última palavra, entretanto é da comunidade (isto é, de todo o IETF e não somente do WG).
  10. A língua oficial do IETF é o inglês. A “linguagem” das listas é o ASCII ou em formatos reconhecidos e aceitáveis.
  11. Proposta técnica de um WG é publicada como um I-D, e enviada ao IESG após a avaliação do AD do WG. Uma vez revisada pelo IESG poderá ser retornada ao WG, para se tornar uma RFC.
  12. Todo documento do IETF é público. I-D é o documento de trabalho do IETF e, também, documento do WG. O I-D permanece arquivado no IETF por 6 meses (pode haver exceções por parte do IESG), de onde é automaticamente excluído do ambiente original. Um I-D, após avaliado, favoravelmente, em várias instâncias da comunidade dá origem a uma RFC.
  13. Existem vários tipos de RFCs e nem toda RFC é um padrão. RFCs são caracterizadas pelo RFC Editor.
  14. O IETF é uma meritocracia. Algumas vozes (técnicas, não políticas) são mais importantes do que outras. Grandes esforços podem ser barrados por razão de uma opinião técnica relevante.

 

ietfxWG

Figura 3. BOFs e WGs. Fonte: Elaborado pelo autor, com base nas informações em [10] e [17].

 

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 Nunes21. 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 RFC543422 é 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.

 

Participacoes

Figura 4. Como participar do IETF e os eventos programados (2013 / 2014). Fonte: Adaptado de vários textos do IETF.

 

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

 

 

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.
Categorias:IAB, IANA IPv4, IESG, IETF, ISOC, TCP/IP, W3C Tags:, ,