Arquivo

Archive for the ‘IAOC’ Category

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.

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

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:
%d blogueiros gostam disto: