CZF-RFC-BASE: Porovnání verzí
Z CZFree Wiki
(Čeština, překopání, upravení. Kamenujte v diskuzi.) |
|||
| Řádek 1: | Řádek 1: | ||
| − | == CZF-RFC-BASE definuje | + | == CZF-RFC-BASE definuje základy společné pro všechny [[CZF-RFC]]== |
| + | === Co je to RFC === | ||
| − | + | '''RFC''' je zkratka anglického výrazu request for comments (žádost o komentáře), která se používá pro označení řady standardů a dalších dokumentů popisujících Internetové protokoly, systémy apod. Jak už název napovídá, RFC jsou oficiálně považovány spíše za doporučení než normy v tradičním smyslu, přesto se podle nich řídí drtivá většina Internetu. | |
| − | + | Na rozdíl od klasických norem a standardů vydávaných klasickými normotvornými instuticemi (jako např. ISO, ANSI apod.) vznikají RFC poněkud jiným způsobem. Původními autory jednotlivých RFC jsou obvykle konkrétní experti, kteří se snaží řešit konkrétní problém, jehož řešení nabídnou ve formě návrhu RFC Internetové veřejnosti (jako tzv. Internet Draft). Pokud je dané řešení (často již dobře fungující v rámci nějakého pilotního provozu) uznáno za přínosné, dokument se vydá jako RFC. | |
| − | + | Toto pragmatické řešení standardů sestavovaných jednotlivci či malými skupinami na základě praktických zkušeností má mnohé výhody oproti formálnějším procesům standardizačních komisí u úřadů typu ISO. Standardy vytvořené pomocí RFC jsou kupodivu (vzhledem k neexistenci jakékoli skutečné moci na jejich vynucování) až na výjimky dodržovány, přičemž pomohly rozšíření Internetu do dnešních celosvětových rozměrů. | |
| − | + | Jistá neformálnost procesu vytváření RFC dokumentů se zrcadlí v tradici vydávání žertovných RFC (například [http://www.rfc-archive.org/getrfc.php?rfc=2324 HTCPTP] nebo [http://www.rfc-archive.org/getrfc.php?rfc=rfc1149 Standard for the transmission of IP datagrams on avian carriers] později rozšířený o speciální [http://www.rfc-archive.org/getrfc.php?rfc=rfc1149 QoS]), které jsou publikovány obvykle na apríla každého roku. | |
| − | + | Bližší informace o procesu tvorby RFC jsou uvedeny v [http://tools.ietf.org/html/rfc2026 RFC 2026] (The Internet Standards Process, Revision 3). | |
| − | |||
| − | |||
| − | + | První RFC dokument (RFC 1, Host Software) napsal Steve Crocker z Kalifornské univerzity a byl vydán 7. dubna 1969. | |
| − | + | ''Zdroj'': [http://cs.wikipedia.org/wiki/RFC] | |
| + | === CZF-RFC === | ||
| − | * | + | Na výše uvedeném principu je založena i myšlenka CZF-RFC. CZF-RFC jsou dokumenty, konkrétně rozpracovávající "standardy" používané v síti [[CzFree]] a vycházející z myšlenky [[CZF-Ustava|Ústavy CZF]]. CZF-RFC by měly obsahovat konkrétní realizační postupy včetně okomentovaných funkčních programů,skriptů či postupů výroby. Mohou obsahovat více způsobů realizace, včetně případné preference jednotlivých postupů. Nejmenší funkční jednotka [[CZF-síť|sítě CZF]] je uzel neboli [[CZF-RFC-NODE|node]]. |
| − | * | + | |
| − | * | + | ===Struktura CZF-RFC=== |
| − | * | + | CZF-RFC musí být zdokumentováno na této wikipedii pod označením CZF-RFC-xxx. Při tvorbě dokumentace by autor měl dbát na doporučení [[CZF-RFC-WIKI]]. |
| − | * '''neNODE''' - NODE, ktery | + | Každé CZF-RFC by mělo mít 3 základní části: |
| − | * | + | |
| + | * úvod srozumitelný i pro Laiky - co a proč RFC definuje | ||
| + | * způsob realizace nezávislý na konkrétnim technickém provedeni | ||
| + | * konkrétní příklady funkční konfigurace - nejlépe detailně okomentomentované příkazy nebo/a konfigurační soubory | ||
| + | |||
| + | ===Slovníček hojně používaných pojmů=== | ||
| + | |||
| + | * ([[CzFree] či [[CZF]]), '''síť''' - počítačová síť CZFree.Net využívající protokoly IPv4 a IPv6 | ||
| + | * [[POINT]], [[BOD]], klient = síťové zařízení, které [[routing|nesměruje]] dál žádné pakety. Typicky uživatelská stanice. | ||
| + | * [[AP]], [[Access Point]], [[Pripojny Bod]] - zařízení, umožňující připojení [[Point|POINTu]] do [[Node|NODE]]. Typicky je soustava složena z antény, kabeláž, bleskojistek, pigtailu, HW AP nebo WiFi karet. Nebo Ronja. | ||
| + | * [Node|NODE]], '''UZEL''' - soustava zařízeni, která umožňuje připojení [[Point|POINTu]] a [[routing|směruje]] pakety v ramci [[Cloud|CLOUDu]] podle [[CZF-RFC-ROUTING]]. Typicky soustava několika [[AP]], [[switch|switchů]], PC [[router|routerů]], krabice na PC, ... lokalizovaná v jednom domě. | ||
| + | * '''neNODE''' - NODE, ktery odmitá splnit všechny požadaky definované jako povinné v CZF-RFCs, nicméně neškodící a mající fyzicky spoj s CZF. Komunikace mezi CZF a neNODE muze byt QoSena, viz [[CZF-RFC-QoS]] | ||
| + | * [[Cloudy|CLOUD]], '''OBLAST''', '''REGION''' = Autonomní Systém v rámci CZF - administrativně vydělená soustava vzájemně komunikujících [[Node|uzlů]]. Uvnitř routují pomoci [[OSPF]], vzajemne pres [[BGP]], viz [[CZF-RFC-ROUTING]]. | ||
* '''CBR''' - CLOUD Border Router - BGP router na hranici CLOUDu | * '''CBR''' - CLOUD Border Router - BGP router na hranici CLOUDu | ||
| − | * ''' | + | * '''páteř CZF''', backbone = Infrastruktura - soustava vzajemně komunikujicich CLOUDu. |
| − | * '''[N]KT''' = [ne]komercni traffic - data, jejichz | + | * '''[N]KT''' = [ne]komercni traffic - data, jejichz směrováním se [ne]vytváří žádný finanční zisk, směrování [ne]zpoplatněných služeb |
| − | * | + | * [[iGW]] = Internet GateWay - router, který umožňuje připojení do Internetu za podmínek odpovídajicích Ústavě a [[CZF-RFC-ROUTING]] |
| − | * '''CZF''' | + | * '''CZF''' [[stable|Stabilní]] - taková verze programu, která je ozkoušena s konfigurací podle [[CZF-RFC]] a je dostupná z CZFree CVS serveru |
| − | + | === Klíčová slova pro specifikování úrovně požadavku=== | |
| − | + | * '''musí''' - Toto slovo, nebo termín 'požadovaný' znamenají, ze tato definice je absolutní požadavek specifikace. | |
| + | * '''nesmí''' - Toto slovo znamená, ze tato definice je pro specifikaci absolutně nepřípustná. | ||
| + | * '''měl by''' - Tato fráze, nebo přídavné jméno 'doporučený' znamená, že zde mohou existovat za určitých okolností důvody pro zanedbání konkrétní věci, ale veškeré důsledky musí být důkladně zváženy před odchýlením se od specifikace. | ||
| + | * '''neměl by''' - Tato fráze, nebo fráze 'není doporučeno' znamená, že zde mohou existovat za určitých okolností důvody, kdy je dané chování přijatelné nebo dokonce užitečné, ale veškeré důsledky v daném případě musí být důkladně zváženy před implementaci jakéhokoliv chování, které je takto označeno. | ||
| + | * '''může''' - Toto slovo, nebo přídavné jméno 'volitelný' znamená, že tato věc je skutečně volitelná. Někdo může danou věc zahrnout, protože ji príslušný účel vyžaduje nebo se mu proste líbí a někdo na tu samou věc nemusí brát vůbec zřetel. Implementace, která v sobě neobsahuje danou volitelnost musí být připravena fungovat s jinou implementací, která ji má, i přes sníženou funkcionalitu. Stejně tak musí být implementace zahrnující nepovinné funkce připravena fungovat s jinou implementaci, která je nemá. | ||
| − | + | == Externí odkazy == | |
| − | + | [http://cs.wikipedia.org/wiki/RFC] | |
| − | |||
| − | |||
| − | |||
Verze z 1. 8. 2008, 19:53
Obsah
CZF-RFC-BASE definuje základy společné pro všechny CZF-RFC
Co je to RFC
RFC je zkratka anglického výrazu request for comments (žádost o komentáře), která se používá pro označení řady standardů a dalších dokumentů popisujících Internetové protokoly, systémy apod. Jak už název napovídá, RFC jsou oficiálně považovány spíše za doporučení než normy v tradičním smyslu, přesto se podle nich řídí drtivá většina Internetu.
Na rozdíl od klasických norem a standardů vydávaných klasickými normotvornými instuticemi (jako např. ISO, ANSI apod.) vznikají RFC poněkud jiným způsobem. Původními autory jednotlivých RFC jsou obvykle konkrétní experti, kteří se snaží řešit konkrétní problém, jehož řešení nabídnou ve formě návrhu RFC Internetové veřejnosti (jako tzv. Internet Draft). Pokud je dané řešení (často již dobře fungující v rámci nějakého pilotního provozu) uznáno za přínosné, dokument se vydá jako RFC.
Toto pragmatické řešení standardů sestavovaných jednotlivci či malými skupinami na základě praktických zkušeností má mnohé výhody oproti formálnějším procesům standardizačních komisí u úřadů typu ISO. Standardy vytvořené pomocí RFC jsou kupodivu (vzhledem k neexistenci jakékoli skutečné moci na jejich vynucování) až na výjimky dodržovány, přičemž pomohly rozšíření Internetu do dnešních celosvětových rozměrů.
Jistá neformálnost procesu vytváření RFC dokumentů se zrcadlí v tradici vydávání žertovných RFC (například HTCPTP nebo Standard for the transmission of IP datagrams on avian carriers později rozšířený o speciální QoS), které jsou publikovány obvykle na apríla každého roku.
Bližší informace o procesu tvorby RFC jsou uvedeny v RFC 2026 (The Internet Standards Process, Revision 3).
První RFC dokument (RFC 1, Host Software) napsal Steve Crocker z Kalifornské univerzity a byl vydán 7. dubna 1969.
Zdroj: [1]
CZF-RFC
Na výše uvedeném principu je založena i myšlenka CZF-RFC. CZF-RFC jsou dokumenty, konkrétně rozpracovávající "standardy" používané v síti CzFree a vycházející z myšlenky Ústavy CZF. CZF-RFC by měly obsahovat konkrétní realizační postupy včetně okomentovaných funkčních programů,skriptů či postupů výroby. Mohou obsahovat více způsobů realizace, včetně případné preference jednotlivých postupů. Nejmenší funkční jednotka sítě CZF je uzel neboli node.
Struktura CZF-RFC
CZF-RFC musí být zdokumentováno na této wikipedii pod označením CZF-RFC-xxx. Při tvorbě dokumentace by autor měl dbát na doporučení CZF-RFC-WIKI. Každé CZF-RFC by mělo mít 3 základní části:
- úvod srozumitelný i pro Laiky - co a proč RFC definuje
- způsob realizace nezávislý na konkrétnim technickém provedeni
- konkrétní příklady funkční konfigurace - nejlépe detailně okomentomentované příkazy nebo/a konfigurační soubory
Slovníček hojně používaných pojmů
- ([[CzFree] či CZF), síť - počítačová síť CZFree.Net využívající protokoly IPv4 a IPv6
- POINT, BOD, klient = síťové zařízení, které nesměruje dál žádné pakety. Typicky uživatelská stanice.
- AP, Access Point, Pripojny Bod - zařízení, umožňující připojení POINTu do NODE. Typicky je soustava složena z antény, kabeláž, bleskojistek, pigtailu, HW AP nebo WiFi karet. Nebo Ronja.
- [Node|NODE]], UZEL - soustava zařízeni, která umožňuje připojení POINTu a směruje pakety v ramci CLOUDu podle CZF-RFC-ROUTING. Typicky soustava několika AP, switchů, PC routerů, krabice na PC, ... lokalizovaná v jednom domě.
- neNODE - NODE, ktery odmitá splnit všechny požadaky definované jako povinné v CZF-RFCs, nicméně neškodící a mající fyzicky spoj s CZF. Komunikace mezi CZF a neNODE muze byt QoSena, viz CZF-RFC-QoS
- CLOUD, OBLAST, REGION = Autonomní Systém v rámci CZF - administrativně vydělená soustava vzájemně komunikujících uzlů. Uvnitř routují pomoci OSPF, vzajemne pres BGP, viz CZF-RFC-ROUTING.
- CBR - CLOUD Border Router - BGP router na hranici CLOUDu
- páteř CZF, backbone = Infrastruktura - soustava vzajemně komunikujicich CLOUDu.
- [N]KT = [ne]komercni traffic - data, jejichz směrováním se [ne]vytváří žádný finanční zisk, směrování [ne]zpoplatněných služeb
- iGW = Internet GateWay - router, který umožňuje připojení do Internetu za podmínek odpovídajicích Ústavě a CZF-RFC-ROUTING
- CZF Stabilní - taková verze programu, která je ozkoušena s konfigurací podle CZF-RFC a je dostupná z CZFree CVS serveru
Klíčová slova pro specifikování úrovně požadavku
- musí - Toto slovo, nebo termín 'požadovaný' znamenají, ze tato definice je absolutní požadavek specifikace.
- nesmí - Toto slovo znamená, ze tato definice je pro specifikaci absolutně nepřípustná.
- měl by - Tato fráze, nebo přídavné jméno 'doporučený' znamená, že zde mohou existovat za určitých okolností důvody pro zanedbání konkrétní věci, ale veškeré důsledky musí být důkladně zváženy před odchýlením se od specifikace.
- neměl by - Tato fráze, nebo fráze 'není doporučeno' znamená, že zde mohou existovat za určitých okolností důvody, kdy je dané chování přijatelné nebo dokonce užitečné, ale veškeré důsledky v daném případě musí být důkladně zváženy před implementaci jakéhokoliv chování, které je takto označeno.
- může - Toto slovo, nebo přídavné jméno 'volitelný' znamená, že tato věc je skutečně volitelná. Někdo může danou věc zahrnout, protože ji príslušný účel vyžaduje nebo se mu proste líbí a někdo na tu samou věc nemusí brát vůbec zřetel. Implementace, která v sobě neobsahuje danou volitelnost musí být připravena fungovat s jinou implementací, která ji má, i přes sníženou funkcionalitu. Stejně tak musí být implementace zahrnující nepovinné funkce připravena fungovat s jinou implementaci, která je nemá.
