Bilješka 64: Minimalna početna specifikacija, lokalne buduće odluke i dobrovoljno usvajanje za sistem koordinacije interneta

Sažetak

Ovaj dokument opisuje obrazac dizajna za internetske koordinacijske sustave čija je svrha pružiti zajedničke tehničke referentne točke bez stvaranja kontinuiranog ovlaštenja iznad sudionika koji pokreću sustav. Definira tri povezana načela: minimalnu početnu specifikaciju, lokaliziranu buduću odluku i dobrovoljno usvajanje.

Prema ovom modelu, početna specifikacija definira samo deterministička, lokalno provjerljiva pravila potrebna za jedinstvenost, interoperabilnost, zajedničku sigurnost i sigurnost. Nakon inicijalne specifikacije, buduće promjene ne odobrava središnje tijelo. Usvajaju ih, zanemaruju, račvaju ili napuštaju sudionici koji pokreću kod.

Neposvajanje nije prekršaj. Sudionik koji ne usvoji kasniju promjenu ostaje u svom postojećem skupu kompatibilnosti. Sudionik koji emitira stanje koje nije važeće prema determinističkim pravilima koje je prihvatio drugi sudionik može biti lokalno zanemaren od strane tog sudionika. Učinak je odabir kompatibilnosti, račvanje, izolacija ili selektivna međuoperacija, a ne institucionalna kazna.

Ovaj dokument ne definira žičani protokol. Određuje najbolju trenutnu praksu za dizajn protokola, registara, sustava identifikatora i mehanizama koordinacije koji ne smiju postati stalne upravljačke institucije.

1. Uvod

Mnogi internetski sustavi počinju s uskom tehničkom svrhom: omogućiti neovisnim akterima međusobnu suradnju dijeljenjem zajedničke referentne točke, identifikacijskog prostora, pravila provjere valjanosti ili zapisa nalik registru. S vremenom takvi sustavi često akumuliraju ovlasti koje nisu bile potrebne za početnu interoperabilnost.

To se obično događa u tri koraka.

Prvo, buduća pitanja postavljaju se u temeljni sloj prije nego što postanu tehnički potrebna.

Drugo, izbori koje trebaju donijeti sudionici koji vode svoje vlastite sustave postaju ovisni o priznavanju, tumačenju ili statusnim odlukama od strane stalnog tijela.

Treće, objava, registracija, preporuka ili proceduralno odobrenje smatra se dostatnim za stvaranje operativne obveze, čak i kada sudionici nisu prihvatili promjenu u sustavima koji rade.

Rezultat je krhki sustav. Tehnički referentni sloj postaje upravljački sloj. Zapisničar postaje vratar. Artefakt koordinacije postaje izvor buduće kontrole.

Ovaj dokument predlaže drugačiju disciplinu dizajna:

– Minimalna početna specifikacija: specificirati samo deterministička zajednička pravila potrebna za osnovnu međuoperabilnost, jedinstvenost, zajedničku sigurnost i sigurnost.
– Lokalizirana buduća odluka: nakon početne specifikacije, zadržite buduće izbore sa sudionicima koji izvode kod. Sudionik može usvojiti, odbiti, rastaviti, prekinuti vezu ili selektivno interoperirati. Nijedan sudionik ne može promijeniti interoperabilnost drugih sudionika koji nastavljaju primjenjivati ​​međusobno kompatibilna pravila.
– Dobrovoljno posvajanje: učiniti kasniju promjenu stvarnom samo kroz implementaciju, rad, provjeru valjanosti i usvajanje od strane sudionika koji pokreću kod.

Ova su načela povezana. Sustav koji specificira previše na početku unaprijed učitava buduću kontrolu u zajednički sloj. Sustav koji napušta kontinuirani sloj prepoznavanja omogućuje ponovno pojavljivanje ovlaštenja nakon postavljanja. Sustav koji objavu tretira kao stvarnost pretvara dokumentaciju u naredbu.

Intuicija dizajna je jednostavna: valjanost se mora odrediti determinističkim pravilima koja sudionici mogu provjeriti lokalno. Sudionik može usvojiti kasniju promjenu, odbiti je, račvati se, prekinuti vezu ili selektivno interoperirati. Može se najviše ukloniti iz skupa kompatibilnosti. Ne može, odbijajući promjenu, prekinuti interoperabilnost drugih sudionika koji nastavljaju pokretati međusobno kompatibilan kod.

Ovo je ista opća lekcija vidljiva u sustavima kao što je Bitcoin: pravila konsenzusa provode oni koji pokreću validacijski kod, a ne institucija koja stoji iznad njih.

2. Opseg

Ovaj se dokument odnosi na internetske koordinacijske sustave, uključujući, ali ne ograničavajući se na zajedničke registre, sustave identifikatora, okvire imenovanja i numeriranja, mehanizme proširenja protokola, sustave dokaza kontrole, sustave prenosivosti i druge arhitekture u kojima se neovisni akteri oslanjaju na zajedničku tehničku referentnu točku.

Ovaj dokument ne osporava uobičajena pravila. Tvrdi da bi zajednička pravila trebala biti deterministička, minimalna, lokalno provjerljiva i ograničena na ono što sustav zapravo treba da radi.

Ovaj dokument ne zahtijeva blockchain, distribuiranu knjigu ili bilo koju posebnu tehnologiju. Zahtijeva svojstvo dizajna: sudionici bi trebali moći odrediti valjanost lokalnom primjenom početne specifikacije, bez traženja dopuštenja ili statusa od stalnog tijela.

3. Konvencije i definicije

3.1. Zahtjevi Jezik

Zahtjevi napisani velikim slovima u ovom dokumentu trebaju se tumačiti u smislu definiranom BCP 14, posebno RFC 2119 i RFC 8174.

3.2. Nazivlje

Početna specifikacija:
Skup pravila, struktura podataka, formata, invarijanti, postupaka provjere valjanosti i prijelaznih pravila potrebnih za prvu implementaciju sustava.

Uobičajeni sloj:
Minimalni zajednički skup pravila ili referentna struktura potrebna za međusobnu suradnju neovisnih sudionika. Zajednički sloj nije institucija. To je tehnička supstanca koju sudionici provode i provjeravaju.

Pravilo determinističke provjere valjanosti:
Pravilo koje omogućuje sudioniku da odluči, lokalnim računanjem ili lokalnom provjerom, jesu li stanje, zapis, prijelaz, tvrdnja ili poruka valjani pod određenim skupom pravila.

Globalna invarijanta:
Svojstvo koje mora ostati zajedničko unutar skupa kompatibilnosti kako bi se očuvala jedinstvenost, osnovna interoperabilnost, zajednička sigurnost ili sigurnost.

sudionik:
Operater, implementacija, čvor, mreža, organizacija ili drugi akter koji pokreće, provjerava, implementira ili se oslanja na sustav.

Skup kompatibilnosti:
Grupa sudionika čija im implementirana pravila provjere dopuštaju međusobnu suradnju. Kasnija promjena može stvoriti novi skup kompatibilnosti ako ga neki sudionici usvoje, a drugi ne.

Usvajanje:
Stvarna implementacija, implementacija, provjera valjanosti i korištenje od strane sudionika koji pokreću sustav.

Neusvajanje:
Izbor sudionika da ne implementira ili ne koristi predloženu promjenu. Neusvajanje ne stvara nevažeći status. To samo znači da se sudionik nije pridružio skupu kompatibilnosti stvorenom tom promjenom.

Lokalno odbijanje:
Lokalna odluka sudionika da zanemari, odbije ili ne interoperira sa stanjem, porukom, zapisom ili prijelazom koji je nevažeći ili nekompatibilan prema pravilima provjere valjanosti koje pokreće.

Vilica:
Razlika u pravilima provjere valjanosti ili operativnoj praksi koja stvara dva ili više skupova kompatibilnosti.

Artefakt koordinacije:
Dokument, unos u registar, preporuka, bilješka o implementaciji, profil, referentna implementacija ili drugi artefakt koji pomaže sudionicima u koordinaciji. Artefakt koordinacije ne stvara obvezujuću operativnu stvarnost osim ako ga sudionici ne usvoje u sustavima koji rade.

4. Izjava problema

Dizajneri često pokušavaju smanjiti buduću neizvjesnost upisivanjem previše u temeljni sloj ili ostavljanjem kontinuiranog tijela za tumačenje budućih pitanja. Ovo se čini razboritim. Često je opasno.

Prevelika specifikacija na temeljnom sloju ima tri cijene.

Prvo, pomiče buduće izbore u zajednički sloj gdje je promjena teža i gdje hvatanje ima veći učinak.

Drugo, stvara dvosmislenost između tehničke valjanosti i institucionalnog priznanja.

Treće, potiče tijelo koje vodi evidenciju, objavljuje dokumente ili saziva sudionike da te radnje tretira kao autoritet nad budućom stvarnošću.

Isti se problem pojavljuje nakon postavljanja. Ako sustav zahtijeva stalno tijelo za odobravanje promjena, određivanje statusa ili tumačenje uobičajenog rada, sustav je stvorio kontrolni sloj nakon osnivanja. Taj sloj može započeti kao administracija. To može postati vladanje. Tada može postati točka gušenja.

Cilj dizajna ovog dokumenta nije bolja institucionalna diskrecija. Cilj dizajna je izbjeći potrebu za tom diskrecijom.

Dobro osmišljen internetski koordinacijski sustav trebao bi na početku definirati deterministička, lokalno provjerljiva pravila valjanosti; treba ostaviti neinvarijantne izbore izvan zajedničkog sloja; i trebao bi omogućiti kasnijim promjenama da postanu stvarne tek kada ih sudionici dobrovoljno usvoje u sustavima koji rade.

5. Načelo 1: Minimalna početna specifikacija

5.1. Izjava

Početna specifikacija TREBA definirati samo minimalna deterministička zajednička pravila potrebna za osnovnu međuoperabilnost, jedinstvenost, zajedničku sigurnost i sigurnost.

5.2. Zahtjevi

Dizajn koji koristi ovo načelo:

1. MORA eksplicitno identificirati svoje globalne invarijante.
2. MORA definirati deterministička pravila provjere valjanosti za svaku globalnu invarijantu.
3. NE SMIJE postaviti pravilo u početnu specifikaciju osim ako je pravilo potrebno za očuvanje navedene globalne invarijante ili za omogućavanje prve implementacije.
4. MORA odvojiti pravila provjere valjanosti od preferencija politike, poslovnih dogovora, institucionalnih uloga, težnji upravljanja i diskrecijske prosudbe.
5. MORA dopustiti sudionicima da lokalno provjere redovnu valjanost bez pitanja bilo koje institucije, registra, odbora, političkog tijela ili drugog tijela.
6. TREBA definirati strukture podataka, potpise, dokaze, pravila prijelaza stanja, pravila sukoba ili druge mehanizme potrebne za lokalnu provjeru.
7. TREBA definirati signalizaciju proširenja, određivanje verzija, označavanje kompatibilnosti ili identifikaciju račvanja tamo gdje su buduće varijacije predvidljive.
8. MORA osigurati da su potrebni koordinacijski artefakti prenosivi, provjerljivi, ponovljivi i zamjenjivi.
9. TREBALI bi dati prednost objektivnim strojno provjerljivim uvjetima u odnosu na subjektivnu procjenu zasluga.
10. NE SMIJE buduće institucionalno priznavanje učiniti jedinim putem kojim se valjano stanje može upoznati, zabilježiti ili koristiti.

5.3. Implikacije dizajna

Minimalna početna specifikacija ne znači nejasnu specifikaciju. To znači strogu specifikaciju samo onoga što mora biti zajedničko.

Sustav još uvijek treba dovoljno zajedničke strukture za rad. Disciplina je razlikovati između:

– što mora biti zajedničko za jedinstvenost, interoperabilnost, zajedničku sigurnost i sigurnost; i
– što može ostati izvan zajedničkog sloja jer se tiče preferencija operatera, poslovne prakse, vremena postavljanja ili kasnijeg izbora usvajanja.

Dizajn koji ne može jasno navesti svoje globalne invarijante i deterministička pravila valjanosti trebao bi pretpostaviti da ima previše diskrecije i premalo sadržaja koji se može provjeriti.

6. Načelo 2: Lokalizirana buduća odluka

6.1. Izjava

Nakon početne specifikacije, buduće odluke TREBALE bi ostati lokalne za sudionike koji pokreću kod. Buduća odluka stupa na snagu samo za skup kompatibilnosti čiji je sudionici usvoje. Za njegovo odobrenje nije potrebno daljnje ovlaštenje, a neposvojenje ne stvara nevažeći status.

6.2. Zahtjevi

Dizajn koji koristi ovo načelo:

1. NE SMIJE zahtijevati od sudionika da dobiju dopuštenje od postojeće institucije, registra, odbora, odbora, političkog tijela ili drugog autoriteta za izbore koji ne mijenjaju deterministička pravila provjere valjanosti skupa kompatibilnosti u kojem sudjeluju.
2. NE SMIJE stvoriti stalno tijelo čije je prepoznavanje jedini put kojim kasnija promjena može postati operativno stvarna.
3. MORA se razlikovati valjanost prema Početnoj specifikaciji od kompatibilnosti s kasnijom opcijskom promjenom.
4. NE SMIJE neusvajanje kasnije promjene tretirati kao nevaljanost.
5. MORA omogućiti sudionicima da ostanu u postojećem skupu kompatibilnosti kada ne usvoje kasniju promjenu.
6. MORA omogućiti sudionicima da se pridruže novom skupu kompatibilnosti usvajanjem novih pravila provjere valjanosti ili operativnih profila.
7. MORA dopustiti sudionicima da lokalno odbiju stanja, zapise, prijelaze ili poruke koje su nevažeće ili nekompatibilne prema pravilima provjere valjanosti koja pokreću.
8. NE SMIJE ovlastiti nijednu instituciju, registar, odbor, političko tijelo ili drugog aktera da proglasi sudionika nevažećim samo zato što je odbio kasniju promjenu.
9. TREBALI bi eksplicitno navesti forkove, verzije, profile ili skupove kompatibilnosti kako bi sudionici znali koja pravila pokreću i s kojim drugim sudionicima mogu surađivati.
10. TREBA izbjegavati svaki dizajn u kojem službeni zapisničar može spriječiti inače valjane sudionike da nastave međudjelovati.

6.3. Implikacije dizajna

Lokalizirana buduća odluka ne znači da središnja vlast dodjeljuje buduće odluke lokalnim akterima. To znači da je sustav dizajniran tako da, nakon početne specifikacije, obični budući izbori ne trebaju takvu dodjelu.

Početna specifikacija obavlja ograničavajući posao unaprijed. Definira minimalne invarijante potrebne za jedinstvenost, interoperabilnost, zajedničku sigurnost i sigurnost. Sve ostalo ostaje izvan zajedničkog sloja.

Buduće promjene ne odobravaju se centralno. Usvajaju ga, ignoriraju, račvaju ili napuštaju sudionici koji pokreću kod.

Sudionik koji odbije promjenu može ostati izvan skupa kompatibilnosti stvorenog tom promjenom. Može se isključiti od drugih. Može se nastaviti u starijem skupu kompatibilnosti. Može se račvati. Može interoperirati selektivno. Ali ne može prekinuti interoperabilnost drugih sudionika koji nastavljaju primjenjivati ​​međusobno kompatibilna pravila.

Učinak nevaljanog ili nekompatibilnog stanja je lokalno odbacivanje, a ne kazna. Nitko ne treba odlučivati ​​da je sudionik u lošem stanju. Sudionik koji izvodi kompatibilna pravila provjere jednostavno ne prihvaća nevažeće ili nekompatibilno stanje.

7. Načelo 3: Dobrovoljno posvajanje

7.1. Izjava

Promjene u sustavu internetske koordinacije TREBALE bi postati operativno stvarne kroz implementaciju, provjeru valjanosti, implementaciju i usvajanje od strane sudionika, a ne samo kroz objavu ili deklaraciju.

7.2. Zahtjevi

Dizajn koji koristi ovo načelo:

1. NE SMIJE tretirati objavu, registraciju, preporuku, odobrenje sastanka ili proceduralno odobrenje kao dostatno za stvaranje univerzalne operativne obveze.
2. MORA dopustiti postupnu implementaciju novih pravila, proširenja, profila ili procedura od strane sudionika koji ih odluče pokrenuti.
3. MORA dopustiti sudionicima da odbiju kasniju promjenu bez stjecanja nevažećeg statusa, sve dok njihovi vlastiti prijelazi stanja zadovoljavaju pravila determinističke provjere valjanosti njihovog skupa kompatibilnosti.
4. MORA dopustiti sudionicima da nastave koristiti stariji skup kompatibilnosti tamo gdje početna specifikacija dopušta takav kontinuitet.
5. MORA dopustiti sudionicima koji pokreću jedan skup kompatibilnosti da lokalno odbiju ili ignoriraju stanje iz drugog skupa kompatibilnosti gdje su pravila nekompatibilna.
6. TREBA definirati putove usvajanja za velike promjene, uključujući signaliziranje verzije, označavanje kompatibilnosti, smjernice prijelaza i testne vektore.
7. TREBA definirati puteve odbijanja velikih promjena, uključujući kako sudionici koji ne usvajaju nastavljaju s radom, identificirati njihov skup kompatibilnosti i izbjegavati dvosmislenu međuoperativnost.
8. MORA osigurati da se potrebni artefakti koordinacije mogu izaći, prenijeti, zrcaliti, ponovno implementirati ili zamijeniti bez nemogućih troškova prijelaza.
9. TREBALO bi imati registre, zapise, preporuke i artefakte koordinacije koji opisuju usvojenu stvarnost, a ne proglašavaju postojanje neusvojene buduće stvarnosti.
10. MORA izbjegavati dizajniranje sustava u kojem je jedini način da promjena postane stvarna prethodno priznavanje od strane nadležnog tijela.

7.3. Implikacije dizajna

Dobrovoljno usvajanje operativni je test je li promjena korisna, podnošljiva i kompatibilna sa stvarnom implementacijom.

Prijedlog nije stvarnost. Preporuka nije stvarnost. Ažuriranje registra nije stvarnost. Dokument nije stvarnost. Stvarnost se pojavljuje kada sudionici implementiraju, potvrde, implementiraju i oslanjaju se na promjenu.

Neusvajanje ne stvara status kršenja. To stvara samo činjenicu: sudionik se nije pridružio skupu kompatibilnosti stvorenom promjenom.

Ovo ne eliminira standardne procese, registre, dokumentaciju ili pregled. Ograničava njihov zahtjev. Oni mogu pomoći sudionicima u koordinaciji. Oni mogu objaviti referentni materijal. Mogu opisati usvajanje. Oni mogu preporučiti. Oni ne smiju, samom deklaracijom, učiniti neusvojenu buduću stvarnost obvezujućom za sudionike koji je ne vode.

8. Odnos između tri principa

Tri načela se međusobno osnažuju i nisu učinkovita zasebno.

Minimalna početna specifikacija osigurava da zajednički sloj sadrži deterministička pravila provjere valjanosti, a ne diskrecijsko ovlaštenje.

Lokalizirana buduća odluka osigurava da budući izbori ostanu kod sudionika koji pokreću kod, umjesto da ih ponovno uhvati središnji sloj odobrenja.

Dobrovoljno usvajanje osigurava da kasnije promjene moraju preživjeti kontakt s implementacijom i korištenjem.

Sustav koji prihvaća samo jedno ili dva od ovih načela može reproducirati istu centralizaciju drugim sredstvima.

– Minimalna početna specifikacija bez lokalizirane buduće odluke još uvijek može dopustiti akumulaciju ovlaštenja nakon postavljanja.
– Lokalizirana buduća odluka bez minimalne početne specifikacije može proizvesti dvosmislenost jer sudionici ne mogu lokalno odrediti valjanost.
– Dobrovoljno usvajanje bez determinističke validacije može proizvesti zabunu jer sudionici ne mogu razlikovati kompatibilnu varijaciju od nevažećeg stanja.
– Deterministička provjera valjanosti bez izlaza, prenosivosti ili zamjenjivosti još uvijek može proizvesti zaključavanje ako artefakte čuvanja zapisa postane nemoguće napustiti.

Zajedno, načela stvaraju sustav u kojem je zajednički sloj tanak, valjanost se može lokalno provjeriti, buduće promjene su dobrovoljne i nije potrebna nikakva stalna institucija koja bi odlučivala o uobičajenom radu.

9. Preporučeni uzorak dizajna

9.1. Deterministički zajednički sloj

Zajednički sloj TREBA biti ograničen na:

– stabilna semantika identifikatora;
– deterministička pravila valjanosti;
– pravila za rješavanje sukoba potrebna za očuvanje jedinstvenosti;
– zahtjeve interoperabilnosti na razini žica ili na razini protokola;
– zajedničke sigurnosne invarijante;
– mehanizmi dokaza kontrole, ako je potrebno;
– prijenosni i revizijski formati zapisa, gdje su zapisi potrebni;
– signalizacija proširenja i identifikacija skupa kompatibilnosti.

Zajednički sloj NE SMIJE sadržavati:

– pravila poslovnog modela;
– pravila o cijenama;
– regionalne političke preferencije;
– ideologija prihvatljivosti koja nije povezana s tehničkim invarijantama;
– diskrecijske ovlasti provedbe;
– subjektivne procjene zasluga;
– proširenje institucionalne misije;
– svako pravilo čija je primarna funkcija očuvanje ovlasti tijela na vlasti.

9.2. Operator Decision Površina

Sljedeće TREBA ostati izvan zajedničkog sloja osim ako izravno ne mijenja navedenu globalnu invarijantu:

– vrijeme postavljanja;
– komercijalna uporaba;
– geografija kupaca;
– ugovore o leasingu, financiranju ili prijenosu;
– prednost lokalne podobnosti;
– operativno sekvenciranje;
– praksa usmjeravanja nije potrebna za zajedničku valjanost;
– poslovni model;
– organizacijska struktura;
– vrijeme dobrovoljne migracije;
– izborni profili ili proširenja.

Sudionici MOGU usvojiti različite izbore u ovim područjima. Ti izbori mogu proizvesti različite skupove kompatibilnosti, poslovne odnose, ravnopravne dogovore ili operativne zajednice. Oni ne stvaraju nevaljanost osim ako ne krše pravila determinističke provjere valjanosti u skupu kompatibilnosti.

9.3. Petlja usvajanja

Gdje je to moguće, preferirani redoslijed za promjenu sustava materijala je:

1. prijedlog;
2. provedba;
3. test vektori ili deterministička metoda verifikacije;
4. ograničeno raspoređivanje voljnih sudionika;
5. promatranje interoperabilnosti i sigurnosnih učinaka;
6. označavanje skupa kompatibilnosti;
7. dokumentacija ili preporuka koja opisuje usvojenu stvarnost.

Artefakt koordinacije TREBAO bi uslijediti nakon usvajanja, a ne pokušati ga spriječiti.

9.4. Izlaz, vilica i prenosivost

Sukladan dizajn TREBA tretirati izlaz, račvanje i prenosivost kao normalne zahtjeve dizajna, a ne kvarove.

Sustav bi TREBAO definirati kako sudionik može:

– nastavak u starijem skupu kompatibilnosti;
– usvojiti noviji skup kompatibilnosti;
– račvanje u drugi skup kompatibilnosti;
– lučke evidencije, identifikatore, dokaze ili operativno stanje;
– provjeriti valjanost zapisa bez oslanjanja na službenog zapisničara;
– selektivno interoperirati gdje kompatibilnost dopušta.

Sustav iz kojeg se ne može izaći ili račvati bez uništavanja važeće operacije vjerojatno ima skrivenu moć upravljanja unutar svoje funkcije čuvanja zapisa.

10. Primjenjivost i ograničenja

Ovaj obrazac dizajna posebno je primjenjiv gdje:

– sustav ima više aktera i više jurisdikcija;
– pitanja neovisnog raspoređivanja;
– koordinacijski sloj treba ostati tanak;
– buduće varijacije su vjerojatne, ali se ne mogu detaljno predvidjeti;
– zaključavanje bi stvorilo rizik upravljanja;
– valjanost se može učiniti determinističkom ili lokalno provjerljivom.

Može biti manje izravno primjenjivo gdje:

– jedna administrativna domena je namjeravana arhitektura;
– jaka sprega u stvarnom vremenu zahtijeva ujednačeno ponašanje u svakom trenutku;
– briga o životnoj sigurnosti zahtijeva neposrednu globalnu uniformnost;
– valjanost se ne može lokalno provjeriti nikakvim praktičnim mehanizmom.

Čak i u takvim slučajevima, dizajneri bi ipak TREBALI minimizirati zajednički sloj i izbjegavati diskrecijsku buduću kontrolu gdje god je to moguće.

11. Ne-golovi

Ovaj dokument ne:

– zabraniti svaku koordinaciju;
– zabraniti sve zajedničke registre;
– zahtijevaju blockchain ili tehnologiju distribuirane knjige;
– jamstvo konsenzusa;
– jamče političku neutralnost;
– zahtijevati od svih sudionika da usvoje svaku kasniju promjenu;
– tretirati odbijanje posvojenja kao nevaljanost;
– legitimizirati nekompatibilno lokalno ponašanje uz tvrdnju o kompatibilnosti;
– eliminirati potrebu za zajedničkim pravilima kritičnim za sigurnost.

12. Sigurnosna razmatranja

Tanji koordinacijski sloj može smanjiti rizik zarobljavanja, smanjiti radijus eksplozije institucionalne pogreške i poboljšati zamjenjivost. Međutim, povećana lokalna diskrecija također može stvoriti nedosljedno sigurnosno stanje, putanje prema nižim verzijama, pritisak fragmentacije, dvosmislene tvrdnje o kompatibilnosti i nesigurne račve.

Dizajneri koji primjenjuju ovaj dokument stoga MORAJU eksplicitno navesti sigurnosne invarijante. Posebno:

– zahtjevi za autentifikaciju i autorizaciju koji su potrebni za zajedničku valjanost MORAJU biti deterministički i lokalno provjerljivi;
– pregovaranje o verziji i rukovanje proširenjem MORA izbjegavati tiho vraćanje na stariju verziju gdje je ugrožena sigurnost;
– putanje odbijanja, račvanja i zamjene MORAJU se analizirati radi zlouporabe i rizika od uskraćivanja usluge;
– oznake kompatibilnosti TREBAJU biti dovoljno jasne da spriječe slučajnu međuoperaciju između nekompatibilnih skupova pravila;
– lokalnoj varijaciji NE SMIJE biti dopušteno da lažno tvrdi da je kompatibilna sa skupom pravila koji ne zadovoljava.

Postojanje sigurnosnih iznimaka ne opravdava opći sloj dopuštenja. Opravdava samo deterministička sigurnosna pravila neophodna za očuvanje navedenih globalnih invarijanti.

13. IANA Razmatranja

Ovaj dokument nema radnje IANA.

14. Literatura

14.1. Normativne reference

– RFC 2119 – Bradner, S., Ključne riječi za upotrebu u RFC-ovima za označavanje razina zahtjeva, BCP 14, RFC 2119.
– RFC 8174 – Leiba, B., Dvosmislenost između velikih i malih slova u ključnim riječima RFC 2119, BCP 14, RFC 8174.

14.2. Informativne reference

– RFC 6709 – Carpenter, B. i B. Aboba, Razmatranja dizajna za proširenja protokola, RFC 6709.
– RFC 7282 – Resnick, P., O konsenzusu i pjevušenju u IETF-u, RFC 7282.

Dodatak A. Popis za provjeru dizajna

Dizajn koji tvrdi da je usklađen s ovim dokumentom TREBA jasno odgovoriti na sljedeća pitanja:

1. Što su globalne invarijante?
2. Koja deterministička pravila provjere valjanosti čuvaju te globalne invarijante?
3. Koja su pravila u početnoj specifikaciji nužno potrebna za prvu implementaciju?
4. Koja buduća pitanja su namjerno ostavljena izvan zajedničkog sloja?
5. Koje buduće izbore mogu napraviti sudionici bez mijenjanja skupa kompatibilnosti u kojem se nalaze?
6. Kako sudionik usvaja kasniju promjenu?
7. Kako sudionik odbija kasniju promjenu, a da mu se ne dodijeli nevažeći status?
8. Kako se skupovi kompatibilnosti označavaju ili otkrivaju?
9. Kako funkcionira lokalno odbijanje kada je stanje nevažeće ili nekompatibilno prema pravilima koje sudionik vodi?
10. Što je račvanje puta?
11. Što je prijenosni put?
12. Koji je izlazni put iz bilo kojeg potrebnog koordinacijskog artefakta?
13. Mogu li sudionici provjeriti redovnu valjanost bez oslanjanja na službenog zapisničara?
14. Opisuju li zapisi i koordinacijski artefakti usvojenu stvarnost ili pokušavaju proglasiti postojanje neusvojene buduće stvarnosti?
15. Je li sustav minimizirao broj odluka ugrađenih u zajednički sloj?
16. Je li sustav izbjegao kontinuirano ovlaštenje koje određuje status običnog sudionika?

## Adresa autora

H. Lu
[TBD]