Odkud pochází Internetové standardy (aneb bylo jednou jedno RFC)

V minulém článku o organizační struktuře IETF jsme zmínili roli RFC Editora. Nyní si povíme, co RFC editor dělá a jak vznikají Internetové standardy RFC.

reklama

Vůbec první dokument RFC vznikl na popud Steva Crockera v březnu 1969 na setkání pracovní skupiny Network Working Group (NWG), což bylo takové neformální setkání lidí, kteří se podíleli na ARPANETu. Toto první RFC pojednává o „HOST Software“ a docela vtipné je, že teprve RFC 03 definuje pár základních pravidel tvorby těchto dokumentů. Pokud vás historie RFC zajímá více, můžete si o ni přečíst například v dokumentech RFC1000, který mapuje prvních tisíc RFC, nebo RFC2995, který obsahuje shrnutí 30 let RFC. Ale teď nechme historii za námi a podívejme se na to, odkud dokumenty RFC pochází, jaké jsou jejich typy a jaký je celý jejich životní cyklus.

Kategorie RFC dokumentů

Dokumenty RFC je možné rozdělit do tří hlavních kategorií. První a nejdůležitější kategorií je kategorie Standardy, která se ještě dělí na Proposed, Draft a Standard, podle vyspělosti dokumentu. Proposed Standard je počáteční úroveň, kdy neexistuje dostatek zkušeností z praxe a ač dokument může být kompletní z hlediska specifikace, může dojít ke změnám na základě zkušeností s nasazením nebo psaním implementace standardu. Příkladem RFC ve stavu Proposed Standard je například RFC2535, které definuje první verzi technologie DNSSEC. Toto RFC bylo na základě zkušeností s implementací nahrazeno sadou nových RFC definující novější verzi technologie DNSSEC, která se nyní používá pro zabezpečení doménových jmen.

Draft Standard klade na specifikace mnohem vyšší nároky. Pro dané specifikace musí existovat minimálně dvě nezávislé implementace, které spolu dokážou spolupracovat, a zároveň existuje dostatečná zkušenost s provozem takových systémů. Z hlediska implementátorů je možné Draft Standard již považovat za finální specifikaci a nemusí existovat obavy, že se design návrhu nějak zásadně změní. Jako příklad Draft Standardu je možné uvést například specifikaci směrovacího protokolu BGPv4. Finální úroveň standardizace nazývána prostě jen Standard (nebo také Internet Standard) nepřidává již žádné další speciální požadavky, ale jen klade větší důraz na vyspělost implementací a dlouhodobější zkušenosti s provozem. RFC, které se dostane do kategorie Internet Standard je považováno za plně vyzrálé. Takových RFC není mnoho, ale jako příklad bych uvedl třeba poštovní protokoly SMTP nebo POP3, z „novějších“ pak specifikaci kódování UTF-8. Důležitá poznámka – samotný obsah dokumentu RFC již po publikačním procesu není možné měnit, kromě zařazení do kategorie, kterou je možné provést bez změny obsahu (aktuální kategorie všech RFC lze nalézt v souboru rfc-index.txt). Pokud jsou v RFC po publikaci nalezeny chyby menšího rozsahu, je možné publikovat errata, které obsahuje opravy chyb technického i formálního charakteru. Pokud je nutné RFC opravit ve větším rozsahu (a i to se stává), oprava probíhá publikací nového standardu, který zneplatní a nahradí předchozí RFC.

Další velkou kategorií bychom mohli nazvat Ne-standardy, která obsahuje Experimentální, Informativní a Historická RFC. Experimentální RFC, jak už jejich jméno naznačuje, jsou většinou součástí nějakého výzkumu nebo vývoje; Experimentální RFC je připraveno jako dokumentace pro internetovou technickou veřejnost nebo jen čistě z archivních důvodů. Dokumenty označené jako Experimentální nejsou příliš vhodné pro stabilní implementaci, ale je možné (a někdy i velmi pravděpodobné), že z nich časem vznikne nový dokument již v kategorii Standards. Příkladem takového dokumentu je část specifikace MIME, která nejprve vznikla jako RFC 1872 v kategorii Experimental, pak následovalo RFC  2112 v kategorii Proposed Standard, a i tento dokument byl nahrazen dalším RFC 2387. V kategorii Experimental je také zařazen protokol přenosu IP datagramů přes poštovní holuby (RFC 1149). Do kategorie Informativní jsou zařazeny takové dokumenty, které nepředstavují širší konsenzus nebo jsou prostě jen typu „Na vědomí se dává“. V kategorii Informativní mohou také vyjít popisy standardů, které vznikly mimo internetovou komunitu IETF. V kategorii Historická RFC jsou zařazeny všechna RFC, která byla nahrazena novějšími.

Poslední kategorie je pak něco mezi – dokumenty Best Current Practice, které obsahují popis nejlepší současné praxe, tedy nedefinují žádný konkrétní standard, ale spíše říkají, jak by se věci měly dělat, aby dobře fungovaly. Dokumenty BCP mají dvojí číslování – kromě standardního čísla RFC dostávají přiděleno ještě samostatné číslo v číselné řadě BCP. Například dokument BCP 38, který popisuje ingress filtrování, které pokud by bylo správně nasazeno na hraničních směrovačích, tak by výrazně přispělo k ochraně před DoS útoky (existuje také pod číslem RFC 3704). Do kategorie BCP by také mohlo spadnout připravované Informativní RFC o provozních zkušenostech s DNSSECem, do kterého přispěl i CZ.NIC zkušenostmi v části 4.1.5, jež popisuje výměnu algoritmu KSK klíče.

Zjednodušený obrázek procesu schvalování RFC dokumentù

Zjednodušený obrázek procesu schvalování RFC dokumentù

Kdo může napsat RFC?

Od jednotlivých kategorií RFC se dostáváme k zajímavějšímu tématu. Kdo a jak může navrhnout a prosadit nový internetový standard. Internetové standardy mohou pocházet ze čtyř možných zdrojů – IETF, IAB, IRTF nebo Nezávislé podání. Pokud dokument přichází přes IETF, dělí se ještě na dva podzdroje – buď přichází z pracovní skupiny, nebo jej přímo sponzoruje ředitel oblasti (AD).

Jednotlivé zdrojové oblasti se liší v tom, které kategorie dokumentů mohou kde vznikat. V rámci IETF mohou vzniknout dokumenty, jenž budou v kategorii Standardů, Informativní nebo Experimentální. Pro IAB a IRTF platí speciální pravidla, např. IAB vydává některá RFC, která definují standardizační proces – RFC 2300. Jistě již odhadnete, že většina dokumentů pocházejících z výzkumné skupiny IRTF skončí v kategorii Experimentální nebo Informativní. Individuální nezávislé podání nového dokumentu RFC může být pouze v kategoriích Experimentální, Informativní nebo Historické.

Samotný proces schvalování dokumentů před publikací je poměrně komplikovaný a liší se jednak dle zdroje dokumentu a jednak dle jejich kategorie. Pochopitelně nejsložitější proces se týká kategorie Standardů, a proto v tomto článku popíšu jen ten.

Návrh dokumentu (nazývaný Internet Draft neboli I-D) musí nejprve projít pracovní skupinou a již tam může dojít k první komplikaci. Každá pracovní skupina má své stanovy, které hovoří o tom, co spadá do její náplně. Pokud nápad, který autor představí pracovní skupině, nezapadá do její náplně, může dojít k zamítnutí ze strany předsedů pracovní skupiny (WG chairs). V takovém případě si může autor najít nějakou jinou vhodnější pracovní skupinu, podat svůj návrh přímo řediteli oblasti nebo si může založit vlastní pracovní skupinu (o tom, jak se taková pracovní skupina zakládá, si povíme v další části tohoto seriálu o IETF).

Každopádně pokud návrh projde skrz pracovní skupinu, musí ustát často ostrou kritiku ze strany ostatních členů pracovní skupiny. Někdy je kritika oprávněná a na jejím základě může autor dokument (nebo i ostatní členové pracovní skupiny) upravit nebo případně úplně stáhnout. Někdy však může být za kritikou jen odpor k novotám nebo jiné zájmy – i když by jednotliví „členové“ IETF měli vystupovat jen za sebe a pro obecné blaho internetové komunity, tak je celkem jednoduše představitelné a vcelku pochopitelné, že někdy může dojít spíše k hájení osobních či firemních zájmů. V první fázi dochází k úpravám pouze ze strany autora, ale pokud je dokument akceptován pracovní skupinou na základě konsenzu, může být vybrán editor textu, který nebude shodný s autorem návrhu (i když k tomu dochází jen málo často).

Zde bych udělal malou odbočku k tomu, jak je chápán konsenzus v IETF. Pokud si vzpomenete, tak jsem v předchozím článku mluvil o tom, že neexistuje nic jako členství v IETF. Kdokoliv přijde a má zájem pracovat, tak může přijít a pracovat. To s sebou ovšem nese i velkou názorovou pluralitu, která by mohla nakonec vést k zablokování rozhodovacího procesu. Proto pracovní skupiny na IETF pracují na základě něčeho, co je nazýváno hrubý konsenzus (rough consensus). Hrubý konsenzus je definován jako dominantní názor skupiny, přičemž dominantní neznamená hlasitý, ale spíše obecné přijetí většinou členů. O tom, zda bylo dosaženo hrubého konsenzu, rozhodují předsedající pracovní skupiny.

Většina rozhodnutí je učiněna v rámci poštovních konferencí, ale někdy k výzvě ke konsenzu dochází na IETF mítincích, kde mohou mít formu „hučení“ (humming). Mnohdy je to zábavný pohled, když místnost plná vousatých inženýrů hučí jako roj rozlobených včel. Pokud se hučení výrazně přikloní na jednu nebo na druhou stranu, je dosaženo konsenzu. Pokud je hučení nevýznamné (tj. účastníci o téma vlastně nemají zájem nebo zatím nemají názor), případně pokud je rozdíl v hučení mezi opačnými tábory malý, tak se záležitost, o které se rozhodovalo, většinou vrací do poštovní konference, kde je dále bouřlivě (a mnohdy i zuřivě) diskutována.

Hučící odbočka je za námi a my se nyní vracíme k dokumentu, který byl úspěšně akceptován pracovní skupinou. Na základě dalších připomínek, obsahových i formálních, editor postupně upravuje a vydává jednotlivé revize Internetového Draftu, a pokud se pracovní skupina dohodne, tak její předsedající vyhlásí takzvanou Poslední výzvu (WG Last Call). Bohužel se stává, že mnoho lidí čeká až na WGLC a teprve pak si dokument přečtou a vygenerují další připomínky, takže není neobvyklé mít několik Posledních výzev.

Pokud dokument projde Poslední výzvou, což mimo jiné znamená, že jej přečetlo významnější množství lidí a souhlasili s jeho obsahem, je poslán ke schválení IESG. O něm jsme se bavili v minulém článku, že je takovým kormidelníkem IETF, který je složen s ředitelů jednotlivých oblastí. V první fázi IESG, resp. zodpovědný ředitel oblasti, dokument schválí, tedy pokud k němu nemá připomínky, a předkládá jej širšímu plénu v IETF – tento krok se nazývá Poslední výzva IETF (IETF Last Call). V rámci IETF LC je dokument podroben širší kritice, která zahrnuje různé jednotlivce, ale také týmy z jiných oblastí, kterých by se standard mohl dotknout.

Pokud jsou všechny připomínky uspokojivě vyřešeny, případně k navrhovanému standardu nemá nikdo žádné připomínky, tak dokument putuje zpět do IESG, kde je posouzena poslední verze návrhu. Další organizace, která se může vyjádřit k návrhu, je IANA. K tomu dochází v případě, že dokument obsahuje například nový číselník, který bude muset IANA spravovat. Nyní jsme již skoro na konci celého životního cyklu dokumentu, a nacházíme se v posledním místě, kdy ještě IESG může dokument vrátit k přepracování pracovní skupině.

Návrh nového standardu úspěšně prošel schválením IESG a nyní se dostává do fronty k RFC Editorovi. RFC Editor má za úkol zajistit formální přesnost dokumentu, proto autor může dostat terminologické, citační nebo formální připomínky. Je důležité, aby výsledný dokument byl jasný, čitelný a tak byl dostupný širokému publiku, které může mít – od zainteresované internetové veřejnosti, přes výzkumníky, po implementátory standardů. Obzvláště u poslední skupiny je důležité, aby byly standardy dobře pochopeny a zařízení spolu dokázala správně komunikovat. Nejasný nebo nesrozumitelný popis může vést i k implementaci, která se nejenže nechová dle standardu, ale také může vykazovat přesně opačné chování.

Po finální úpravě nastává proces nazývaný AUTH48, kdy mají autoři poslední šanci udělat drobné změny v dokumentu a schválit jeho výslednou podobu. Tento proces trvá minimálně 48 hodin (proto AUTH48) a na jeho konci čeká publikace navrhovaného standardu jako RFC. Finální publikace zahrnuje rozeslání dokumentu do poštovní konference ietf-announce@ietf.orgrfc-dist@rfc-editor.org, přidělení čísla RFC a zveřejnění dokumentu na stránkách http://www.rfc-editor.org/rfc/rfcXXX­X.txt (včetně mirroru na stránkách IETF a dalších). Pokud se někdy se svým návrhem propracujete až do této fáze, tak předem přijměte mé gratulace.

CIF_1

       

Na závěr článku bych vás rád upozornil na aprílová RFC, která vychází pravidelně a většina z nich je velmi vtipná. Přenos IP paketů poštovními holuby (RFC 1149) jsem již zmiňoval, mezi další patří „Zlý bit“ (RFC 3514) signalizující, že IPv4 přichází se zlým úmyslem, a tím ulehčuje práci firewallům, nebo mých oblíbených dvanáct pravd o síťování (RFC 1925), mezi které patří i závažná pravda o tom, že prasata mohou létat, pokud použijete dostatečnou sílu. Nicméně létající prasata nemusí být až zas tak dobrým nápadem, protože a) nevíte, kde dopadnou, b) stát pod přelétajícím prasetem může být dost nebezpečné.

Doufám, že se mi alespoň trochu povedlo vás přesvědčit o tom, že nové internetové standardy (včetně onoho nyní aktuálního IPv6) nevydávají nějací mystičtí „inženýři“, ale že je to poměrně komplikovaný proces, do kterého je však možné se velmi jednoduše zapojit a výslednou podobu ovlivnit. V dalším díle si povíme něco o zakládání pracovních skupin v IETF, když přijdete s tématem, které nepasuje nikde jinde.


Ondřej Surý

Autor je technickým ředitelem CZ.NIC, z.s.p.o. a studentem FSS MU. Zajímá se o DNS, DNSSEC, Linux. Jeho nepočítačový blog najdete na adrese blog.rfc1925.org.

Školení PPC reklamy pro začátečníky

  •  
    Principy fungování PPC reklamy.
  • PPC nejsou jen ve vyhledávačích.
  • Zjednodušte si správu šikovnými nástroji.

Detailní informace o školení PPC reklamy »

       
5 názorů Vstoupit do diskuse
poslední názor přidán 25. 1. 2011 10:46

Tento text je již více než dva měsíce starý. Chcete-li na něj reagovat v diskusi, pravděpodobně vám již nikdo neodpoví. Pro řešení aktuálních problémů doporučujeme využít naše diskusní fórum.

Zasílat nově přidané příspěvky e-mailem