Názory k článku Poslední volný bit IP hlavičky: jak signalizovat zahlcenou linku

Povinnost zapisujícího nastavovat tam nulu ale neznamená pro čtecí stranu povinnost kontrolovat, že tam nula je, a dokonce to nedává čtecí straně ani možnost pakety s něčím jiným než nulou zahazovat.

To byste pak nemohl zahazovat žádný packet s nevalidními hlavičkami. Must právě definuje, že druhá strana se na to může spolehnout a smí to kontrolovat (ale nemusí, když nechce).

Rozhodně snahu detekovat nevalidní packety bych nepovažoval za chybnou. Přečtu si specifikaci a vytvořím si matici flagů, které se smí v kombinací objevit. Cokoliv vím, že se objevit nesmí, můžu vyhodnotit jako nevalidní a naložit s tím podle uvážení (drop, reject, tarpit, forward).

Rozdíl je tedy ve vyhodnocení: muset / moci / nesmět.
Pokud flag nesmí nebo musí být nastaven => pak můžu, ale nemusím vyhodnocovat při zpracování
Jedině pokud flag smí, ale nemusí být nastaven => pak nesmím vyhodnocovat

26. 2. 2020, 13:20 editováno autorem komentáře

To byste pak nemohl zahazovat žádný packet s nevalidními hlavičkami.
Ale mohl. Stačí například když je ve specifikaci napsáno, že to je možné kontrolovat a pakety s nevalidními daty je možné zahodit.

Must právě definuje, že druhá strana se na to může spolehnout
Právě že ne. Must prostě znamená must, nic jiného.

Rozhodně snahu detekovat nevalidní packety bych nepovažoval za chybnou.
O tom se tady ale nebavíme. Tady je záměrně v nějaké verzi specifikace vynechané rezervované místo v paketu pro pozdější využití. A aby bylo možné později ho využít, mají odesílající povinnost tam v této verzi specifikace nastavovat nuly. Příjemce ty vyhrazené bity musí ignorovat. To je princip rezervovaných bitů – příjemce se teď o ně vůbec nezajímá, tím pádem v nich nemůže být nic, co by vyhodnotil jako nevalidní. No a pak se v pozdější verzi specifikace může dát těm rezervovaným bitům význam. Díky tomu, že tam do teď všichni museli nastavovat nulu, je jasné, že nenulovou hodnotu musela nastavit jen implementace, která zná ten nový standard. A díky tomu, že příjemci ta data ignorovali, je jasné, že příjemce, který nezná novou verzi standardu, bude údaje ignorovat, ať budou jakékoli. Teprve příjemce, který novou verzi standardu implementuje, se těmi bity bude zabývat.

Díky tomu je zajištěno, že se dá postupně přejít na novou verzi standardu – protože proti sobě budou fungovat libovolné dvě kombinace staré × nové. Což je na internetu zásadní, protože tam opravdu není možné říct, že v jeden okamžik všichni najednou začnou používat nový standard.

Rozdíl je tedy ve vyhodnocení: muset / moci / nesmět.
Nikoli, rozdíl je ve známém pravidle „buď striktní v tom, co generuješ/odesíláš, ale buď benevolentní v tom, co čteš/přijímáš“.

Pokud flag nesmí nebo musí být nastaven => pak můžu, ale nemusím vyhodnocovat při zpracování
Tím byste ovšem úplně zabil koncepci rezervovaných částí struktur. Právě proto existují tyhle případy, kdy jedna strana něco musí udělat, ale druhá se na to nesmí spoléhat. V jedné verzi standardu je to zdánlivě nelogické, ale jakmile začnete uvažovat o tom, že se ten standard v budoucnosti může opravit, objevíte to kouzlo.

Tady je záměrně v nějaké verzi specifikace vynechané rezervované místo v paketu pro pozdější využití. A aby bylo možné později ho využít, mají odesílající povinnost tam v této verzi specifikace nastavovat nuly. Příjemce ty vyhrazené bity musí ignorovat...

... V jedné verzi standardu je to zdánlivě nelogické, ale jakmile začnete uvažovat o tom, že se ten standard v budoucnosti může opravit, objevíte to kouzlo.

Dívejte se na to z druhé strany. Pokud se jedná o rezervovaný bit, tak v době implementace druhá strana nemůže vědět jestli a jak bude bit v praxi zavedený. V budoucnu v něm může být i zásadní hodnota - a úplně stejně by dnes mohl být článek o tom, jak některá zařízení chybně přijímají i packety, které je podle nového standardu potřeba zpracovávat odlišně.

Je proto naprosto správné, že pokud tady a teď standard ukládá povinnost nastavit bit na nulu, spadá to do kontrol validity na druhé straně.

To, co popisujete Vy by mělo být popsáno: reserved bit; sending party should set the bit to zero; receiving party must ignore the value. Slovo must je ve standardu uvedeno chybně a nelze to svalovat na ty, co ten standard četli.

V budoucnu v něm může být i zásadní hodnota
Nemůže. Autoři standardů nejsou magoři.

Je proto naprosto správné, že pokud tady a teď standard ukládá povinnost nastavit bit na nulu, spadá to do kontrol validity na druhé straně.
Ne, je to naprosto špatně. Pokud teď standard ukládá povinnost nastavit bit na nulu, neříká to vůbec nic o tom, že se má na druhé straně validovat. A pokud je ten bit výslovně určen jako rezervovaný pro budoucí použití, nesmí ho druhá strana nijak validovat. Ještě jednou – na tomhle je založen princip rezervovaných bitů (nebo jiných rezervovaných částí struktur).

To, co popisujete Vy by mělo být popsáno: reserved bit; sending party should set the bit to zero; receiving party must ignore the value. Slovo must je ve standardu uvedeno chybně a nelze to svalovat na ty, co ten standard četli.
Nikoli, už jsem vám to vysvětloval. Aby bylo možné rezervované bity v budoucnosti použít, musí být zajištěno, že tam teď nebude nikdo dávat nic jiného než nuly. Když povolíte vkládat tam cokoli jiného, nemůžete už nikdy v budoucnosti změnit význam těch bitů – protože byste nedokázal rozlišit, zda tam je nenulová hodnota podle starého standardu a někdo prostě jen využil té možnosti nedávat tam nulu, nebo za tam je nenulová hodnota podle nového standardu.

Možná si zkuste nejdřív nastudovat, co jsou rezervované bity a promyslet si, jak se v budoucnosti začnou používat. Pak nebudete psát takovéhle nesmysly. Chápu, že musíte být v opozici vždy a za každou cenu. Ale je hloupé, když napíšete své „správné“ řešení, které je zjevně nesmyslné a nefunkční.

Ale je hloupé, když napíšete své „správné“ řešení, které je zjevně nesmyslné a nefunkční.

Chtít, aby autoři standardů klarifikovali texty je hloupé, nesmyslné a nefunkční? Podle mě se oprávněně očekává, že autor textu standardu píše jednoznačně a ve své oblasti by měl být na vyšší úrovni, než ti, kteří standard následují. Variant, jak naformulovat větu správně je víc - zvolili ji nešťastně.

Chtít, aby autoři standardů klarifikovali texty je hloupé, nesmyslné a nefunkční?
Vy jste chtěl, aby tam místo must bylo should. To je hloupé a bylo by to nefunkční.

Podle mě se oprávněně očekává, že autor textu standardu píše jednoznačně a ve své oblasti by měl být na vyšší úrovni, než ti, kteří standard následují.
Nezapomněl jste, že se bavíme o standardu z roku 1980? Ten standard byl zamýšlen pro propojení stovek, možná tisíců zařízení ve specifické sféře. Dnes je o 40 let později, ten standard se používá pro propojení miliard zařízení, streamuje se pomocí něj 4K video, dělají se pomocí něj živé hovory přes celou planetu, řídí se přes něj auta, provádějí operace. Našel byste málo takhle úspěšných standardů.

Variant, jak naformulovat větu správně je víc - zvolili ji nešťastně.
Já jsem ale kritizoval to, že váš návrh na „opravu“ je ještě mnohem horší a nefunkční. V tom standardu je napsána ta výše parafrázovaná věta: „In general, an implementation should be conservative
in its sending behavior, and liberal in its receiving behavior.“ Dále je to rozvedené „should
accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)“. Ano, mohlo by to to u jednotlivých rezervovaných bitů být explicitně uvedené, že se na přijímající straně má jejich obsah ignorovat. Nicméně žádná jiná interpretace celého standardu stejně není možná, to explicitní uvedení by bylo opravdu jen pro ty, kterým se nechce nad tím ani trošinku přemýšlet a potřebují jen návod, který mohou slepě následovat.

In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.

Pokud to tam je, pak je to opravdu chyba implementace a beru svá tvrzení zpět.

Ono je tam toho víc. Např. přímo v RFC je mimo jiné přímo nad tabulkou s layoutem napsáno "Bit 6-7: Reserved for Future Use.". A třeba už RFC 1122 (říjen 1989) ty dva nejnižší bity zahrnuje do pole označeného "TOS" (bez bližší specifikace využití).

Tak především každá slušná norma by měla význam těchto klíčových slov někde v záhlaví definovat, případně se na definice odvolat (třeba na něco jako RFC2119 - https://www.ietf.org/rfc/rfc2119.txt), a poté to ctít. Alespoň v oblastech, kde se pohybuji, tomu tak je. Smutné pak ovšem je, že i přesto existují vykladači norem, kteří význam těchto klíčových slov odvozují z jejich významu v běžné angličtině a nepřistupují k nim "po právnicku". Pokud takový vykladač sedí někde ve vývojovém oddělení firmy, je na problém zaděláno.

Tak především každá slušná norma by měla význam těchto klíčových slov někde v záhlaví definovat, případně se na definice odvolat

Zrovna to, co je v odkazované RFC2119 je obecně přijímaný výklad a u slova must jsem ještě neviděl jiný. Většinou se vysvětluje právě should [not], kde se určuje, jestli to znamená libovůli (nastavte jak chcete), nebo jestli to znamená že existuje (třeba v jiné normě nebo v jiné části normy) specifikace či výjimka, jak s tím zacházet.

Samotné slovo must dává jistotu oběma stranám, že se na to mohou spolehnout - to byla první část diskuse s Filipem. Posléze se však vyjasnilo, že v normě je stanoveno, že určuje pravidla pro odeslání packetu strikně, zatímco pro příjem se vyžaduje volnost.

I v tom pak ale zůstává výkladová nejasnost. Dá se to vykládat tak, že přijímající strana nesmí spoléhat ani na to, co je označeno jako must have. Nebo to může znamenat, že must [not] nepřipouští libovůli ani na jedné straně, zatímco should [not] se má na straně odesílatele vykládat úžeji (striktněji), zatímco na straně příjemce šířeji (méně striktně). Nebo to může i znamenat to, že si má člověk domyslet, že u specifikovaných částí je to rigidní podmínka, zatímco u rezervovaných částí je flexibilní.

Technicky vzato, must [not] by mělo dávat jistotu oběma stranám. Proti tomu stojí logický argument, že tím pádem by nemohly být rezervované bity nikdy v budoucnu použity, nebo pouze s přijetím faktu, že je potřeba vyměnit zařízení ve chvíli, kdy se stane tato část normy obsoletní.

26. 2. 2020, 21:09 editováno autorem komentáře