Specifica iniziale minima, decisioni future locali e adozione volontaria per un sistema di coordinamento di Internet

Estratto

Questo documento descrive un modello di progettazione per i sistemi di coordinamento di Internet il cui scopo è fornire punti di riferimento tecnici condivisi senza creare un'autorità continua al di sopra dei partecipanti che gestiscono il sistema. Definisce tre principi collegati: specifica iniziale minima, decisione futura localizzata e adozione volontaria.

Secondo questo modello, la Specifica Iniziale definisce solo le regole deterministiche e verificabili a livello locale richieste per l'unicità, l'interoperabilità, la sicurezza condivisa e la protezione. Dopo la Specifica Iniziale, le modifiche future non vengono approvate da un organismo centrale. Vengono adottati, ignorati, biforcati o abbandonati dai partecipanti che eseguono il codice.

La non adozione non è una violazione. Un partecipante che non adotta una modifica successiva rimane nel suo set di compatibilità esistente. Un partecipante che emette uno stato non valido secondo le regole deterministiche accettate da un altro partecipante può essere ignorato localmente da quel partecipante. L’effetto è la selezione della compatibilità, la biforcazione, l’isolamento o l’interoperazione selettiva, non la punizione istituzionale.

Questo documento non definisce un protocollo di filo. Specifica una migliore pratica attuale per la progettazione di protocolli, registri, sistemi di identificazione e meccanismi di coordinamento che non devono diventare istituzioni di governance permanenti.

1. Introduzione

Molti sistemi Internet iniziano con uno scopo tecnico ristretto: consentire ad attori indipendenti di interoperare condividendo un punto di riferimento comune, uno spazio identificatore, una regola di convalida o un record simile a un registro. Nel corso del tempo, tali sistemi spesso accumulano autorità che non era necessaria per l'interoperabilità iniziale.

Questo di solito avviene in tre passaggi.

Innanzitutto, le domande future vengono inserite nello strato fondativo prima che siano tecnicamente necessarie.

In secondo luogo, le scelte che dovrebbero essere fatte dai partecipanti che gestiscono i propri sistemi diventano dipendenti dal riconoscimento, dall’interpretazione o dalle decisioni sullo status da parte di un organismo continuativo.

In terzo luogo, la pubblicazione, la registrazione, la raccomandazione o l’approvazione procedurale sono considerate sufficienti per creare un obbligo operativo, anche laddove i partecipanti non hanno adottato il cambiamento nei sistemi in corso.

Il risultato è un sistema fragile. Un livello di riferimento tecnico diventa un livello di governance. Un custode del registro diventa un custode. Un artefatto di coordinamento diventa una fonte di controllo futuro.

Questo documento propone una diversa disciplina di progettazione:

– Specifica iniziale minima: specificare solo le regole comuni deterministiche richieste per l’interoperabilità di base, l’unicità, la sicurezza condivisa e la protezione.
– Decisione futura localizzata: dopo la specifica iniziale, mantenere le scelte future con i partecipanti che eseguono il codice. Un partecipante può adottare, rifiutare, biforcare, disconnettersi o interoperare selettivamente. Nessun partecipante può alterare l'interoperabilità di altri partecipanti che continuano a eseguire regole reciprocamente compatibili.
– Adozione volontaria: rendere reali le modifiche successive solo attraverso l'implementazione, il funzionamento, la convalida e l'adozione da parte dei partecipanti che eseguono il codice.

Questi principi sono correlati. Un sistema che specifica troppo all'inizio precarica il controllo futuro nello strato comune. Un sistema che lascia uno strato di riconoscimento continuo consente all’autorità di riapparire dopo l’implementazione. Un sistema che tratta la pubblicazione come realtà converte la documentazione in comando.

L’intuizione progettuale è semplice: la validità deve essere determinata da regole deterministiche che i partecipanti possono verificare localmente. Un partecipante può adottare una modifica successiva, rifiutarla, effettuare un fork, disconnettersi o interagire selettivamente. Al massimo potrebbe rimuoversi da un set di compatibilità. Non può, rifiutando una modifica, interrompere l'interoperabilità di altri partecipanti che continuano a eseguire codice reciprocamente compatibile.

Questa è la stessa lezione generale visibile in sistemi come Bitcoin: le regole di consenso vengono applicate da coloro che eseguono il codice di convalida, non da un’istituzione che sta sopra di loro.

2. Ambito

Il presente documento si applica ai sistemi di coordinamento di Internet, inclusi ma non limitati a registri condivisi, sistemi di identificatori, strutture di denominazione e numerazione, meccanismi di estensione dei protocolli, sistemi di prova di controllo, sistemi di portabilità e altre architetture in cui attori indipendenti fanno affidamento su un punto di riferimento tecnico comune.

Questo documento non si oppone alle regole comuni. Sostiene che le regole comuni dovrebbero essere deterministiche, minime, verificabili a livello locale e limitate a ciò di cui il sistema ha effettivamente bisogno per funzionare.

Questo documento non richiede una blockchain, un registro distribuito o alcuna tecnologia specifica. Richiede una proprietà di progettazione: i partecipanti dovrebbero essere in grado di determinare la validità applicando la Specifica Iniziale localmente, senza chiedere il permesso o lo status a un'autorità permanente.

3. Convenzioni e definizioni

3.1. Requisiti Lingua

I termini relativi ai requisiti in maiuscolo contenuti nel presente documento devono essere interpretati nel senso definito dal BCP 14, in particolare RFC 2119 e RFC 8174.

3.2. Terminologia

Specifica iniziale:
L'insieme di regole, strutture dati, formati, invarianti, procedure di validazione e regole di transizione richieste per la prima implementazione di un sistema.

Livello comune:
Il set minimo di regole condivise o la struttura di riferimento richiesta affinché i partecipanti indipendenti possano interagire. Lo strato comune non è un’istituzione. È la sostanza tecnica che i partecipanti implementano e verificano.

Regola di convalida deterministica:
Una regola che consente a un partecipante di decidere, mediante calcolo locale o verifica locale, se uno stato, un record, una transizione, un'asserzione o un messaggio è valido in un insieme di regole specificato.

Invariante globale:
Proprietà che deve rimanere comune all'interno di un set di compatibilità per preservare l'unicità, l'interoperabilità di base, la sicurezza condivisa o la protezione.

Partecipante:
Un operatore, un'implementazione, un nodo, una rete, un'organizzazione o un altro attore che esegue, verifica, distribuisce o fa affidamento sul sistema.

Insieme di compatibilità:
Un gruppo di partecipanti le cui regole di validazione implementate consentono loro di interoperare. Una modifica successiva potrebbe creare un nuovo set di compatibilità se alcuni partecipanti lo adottano e altri no.

Adozione:
Implementazione effettiva, distribuzione, convalida e utilizzo da parte dei partecipanti che gestiscono il sistema.

Non adozione:
La scelta di un partecipante di non implementare o utilizzare una modifica proposta. La mancata adozione non crea stati di invalidità. Significa solo che il partecipante non ha aderito al set di compatibilità creato da tale modifica.

Rifiuto locale:
La decisione locale di un partecipante di ignorare, rifiutare o non interagire con uno stato, un messaggio, un record o una transizione che non è valida o incompatibile in base alle regole di convalida eseguite.

Forcella:
Una divergenza nelle regole di convalida o nella pratica operativa che crea due o più set di compatibilità.

Artefatto di coordinazione:
Un documento, una voce di registro, una raccomandazione, una nota di implementazione, un profilo, un'implementazione di riferimento o un altro elemento che aiuta i partecipanti a coordinarsi. Un artefatto di coordinamento non crea una realtà operativa vincolante a meno che i partecipanti non lo adottino nei sistemi in funzione.

4. Dichiarazione del problema

I progettisti spesso cercano di ridurre l’incertezza futura scrivendo troppo nello strato fondante o lasciando che un corpo continuativo interpreti le domande future. Ciò appare prudente. Spesso è pericoloso.

Una specifica eccessiva allo strato fondante ha tre costi.

In primo luogo, sposta le scelte future in uno strato comune dove il cambiamento è più difficile e dove la cattura ha un effetto maggiore.

In secondo luogo, crea ambiguità tra validità tecnica e riconoscimento istituzionale.

In terzo luogo, incoraggia un organismo che conserva registri, pubblica documenti o convoca partecipanti a trattare tali atti come autorità sulla realtà futura.

Lo stesso problema si presenta dopo la distribuzione. Se un sistema richiede che un organismo continuo approvi il cambiamento, determini lo stato o interpreti il ​​funzionamento ordinario, il sistema ha creato un livello di controllo post-fondazione. Questo livello può iniziare come amministrazione. Può diventare governance. Può quindi diventare un punto di strozzatura.

L’obiettivo progettuale di questo documento non è una migliore discrezionalità istituzionale. L’obiettivo della progettazione è evitare la necessità di tale discrezione.

Un sistema di coordinamento di Internet ben progettato dovrebbe definire fin dall’inizio regole di validità deterministiche e verificabili a livello locale; dovrebbero lasciare le scelte non invarianti al di fuori dello strato comune; e dovrebbe consentire che i cambiamenti successivi diventino reali solo quando i partecipanti li adottano volontariamente nei sistemi in corso.

5. Principio 1: Specificazione iniziale minima

5.1. Dichiarazione

Una specifica iniziale DOVREBBE definire solo le regole comuni deterministiche minime richieste per l'interoperabilità di base, l'unicità, la sicurezza condivisa e la protezione.

5.2. Requisiti

Un progetto che utilizza questo principio:

1. DEVE identificare esplicitamente le sue invarianti globali.
2. DEVE definire regole di validazione deterministiche per ogni invariante globale.
3. NON DEVE inserire una regola nella Specifica Iniziale a meno che la regola non sia richiesta per preservare un'Invariante Globale dichiarata o per consentire la prima distribuzione.
4. DEVONO separare le regole di convalida dalle preferenze politiche, dagli accordi aziendali, dai ruoli istituzionali, dalle aspirazioni di governance e dal giudizio discrezionale.
5. DEVE consentire ai partecipanti di verificare la validità ordinaria a livello locale senza chiedere ad alcuna istituzione, registro, comitato, organo politico o altra autorità.
6. DOVREBBE definire strutture di dati, firme, prove, regole di transizione di stato, regole di conflitto o altri meccanismi necessari per la verifica locale.
7. DOVREBBE definire la segnalazione dell'estensione, il controllo delle versioni, l'etichettatura di compatibilità o l'identificazione del fork laddove sia prevedibile una variazione futura.
8. DEVE garantire che gli artefatti di coordinamento richiesti siano portabili, verificabili, riproducibili e sostituibili.
9. DOVREBBE preferire condizioni oggettive verificabili dalla macchina rispetto al giudizio di merito soggettivo.
10. NON DEVE rendere il futuro riconoscimento istituzionale l’unico percorso attraverso il quale uno stato valido può essere conosciuto, registrato o utilizzato.

5.3. Implicazioni sulla progettazione

La Specifica Iniziale Minima non significa una specifica vaga. Significa specificare rigorosamente solo ciò che deve essere comune.

Un sistema necessita ancora di una struttura comune sufficiente per funzionare. La disciplina consiste nel distinguere tra:

– cosa deve essere comune per l’unicità, l’interoperabilità, la sicurezza condivisa e la protezione; e
– cosa può rimanere al di fuori dello strato comune perché riguarda la preferenza dell’operatore, la pratica commerciale, i tempi di implementazione o la scelta di adozione successiva.

Un progetto che non può dichiarare chiaramente le sue invarianti globali e le regole di validazione deterministica dovrebbe presupporre di aver specificato troppa discrezione e troppo poca sostanza verificabile.

6. Principio 2: Decisione futura localizzata

6.1. Dichiarazione

Dopo la specifica iniziale, le decisioni future DOVREBBERO rimanere locali per i partecipanti che eseguono il codice. Una Decisione Futura diventa efficace solo per l'insieme di compatibilità i cui partecipanti la adottano. Non è richiesta alcuna autorità continuativa per approvarlo e la mancata adozione non crea uno stato non valido.

6.2. Requisiti

Un progetto che utilizza questo principio:

1. NON DEVE richiedere ai partecipanti di ottenere il permesso da un'istituzione, un registro, un comitato, un consiglio, un organo politico o altra autorità in carica per scelte che non alterano le regole di convalida deterministica dell'insieme di compatibilità a cui partecipano.
2. NON DEVE creare un organismo permanente il cui riconoscimento sia l'unica via attraverso la quale un successivo cambiamento possa diventare operativamente reale.
3. DEVE distinguere la validità secondo la Specifica Iniziale dalla compatibilità con una successiva modifica facoltativa.
4. NON DEVE considerare la mancata adozione di una modifica successiva come invalidità.
5. DEVE consentire ai partecipanti di rimanere in un set di compatibilità esistente quando non adottano una modifica successiva.
6. DEVE consentire ai partecipanti di unirsi a un nuovo set di compatibilità adottando nuove regole di validazione o profili operativi.
7. DEVE consentire ai partecipanti di rifiutare localmente stati, record, transizioni o messaggi che non sono validi o incompatibili secondo le regole di convalida che eseguono.
8. NON DEVE autorizzare alcuna istituzione, registro, comitato, organismo politico o altro attore a dichiarare un partecipante non valido semplicemente perché ha rifiutato una modifica successiva.
9. DOVREBBE rendere espliciti fork, versioni, profili o set di compatibilità in modo che i partecipanti sappiano quali regole stanno eseguendo e con quali altri partecipanti possono interagire.
10. DOVREBBE evitare qualsiasi progetto in cui un conservatore storico possa impedire ai partecipanti altrimenti validi di continuare a interoperare.

6.3. Implicazioni sulla progettazione

Decisione futura localizzata non significa che un’autorità centrale assegna le decisioni future agli attori locali. Significa che il sistema è progettato in modo tale che, dopo la Specificazione Iniziale, le scelte ordinarie future non necessitino di tale allocazione.

La Specifica Iniziale svolge il lavoro di limitazione in anticipo. Definisce gli invarianti minimi richiesti per l'unicità, l'interoperabilità, la sicurezza condivisa e la protezione. Tutto il resto rimane fuori dallo strato comune.

Future change is not approved centrally. Viene adottato, ignorato, biforcato o abbandonato dai partecipanti che eseguono il codice.

Un partecipante che rifiuta una modifica può rimanere fuori dal set di compatibilità creato da tale modifica. It may disconnect itself from others. It may continue in an older compatibility set. Potrebbe biforcarsi. It may interoperate selectively. Ma non può infrangere l’interoperabilità degli altri partecipanti che continuano a applicare regole reciprocamente compatibili.

L'effetto dello stato non valido o incompatibile è il rifiuto locale, non la punizione. Nessuno ha bisogno di decidere che un partecipante è in cattiva reputazione. Un partecipante che esegue regole di convalida compatibili semplicemente non accetta lo stato non valido o incompatibile.

7. Principio 3: Adozione volontaria

7.1. Dichiarazione

I cambiamenti in un sistema di coordinamento di Internet DOVREBBERO diventare operativamente reali attraverso l'implementazione, la validazione, l'implementazione e l'adozione da parte dei partecipanti, non solo attraverso la pubblicazione o la dichiarazione.

7.2. Requisiti

Un progetto che utilizza questo principio:

1. NON DEVE considerare la pubblicazione, la registrazione, la raccomandazione, l’approvazione della riunione o l’approvazione procedurale come sufficienti per creare un obbligo operativo universale.
2. DEVE consentire che nuove regole, estensioni, profili o procedure vengano implementate in modo incrementale dai partecipanti che scelgono di eseguirle.
3. DEVE consentire ai partecipanti di rifiutare una modifica successiva senza acquisire lo stato non valido, purché le proprie transizioni di stato soddisfino le regole di convalida deterministiche del loro set di compatibilità.
4. DEVE consentire ai partecipanti di continuare a utilizzare un set di compatibilità precedente laddove la Specifica Iniziale consente tale continuità.
5. DEVE consentire ai partecipanti che eseguono un set di compatibilità di rifiutare o ignorare localmente lo stato di un altro set di compatibilità in cui le regole sono incompatibili.
6. DOVREBBE definire percorsi di adozione per i cambiamenti più importanti, tra cui la segnalazione della versione, l'etichettatura della compatibilità, la guida alla transizione e i vettori di test.
7. DOVREBBE definire percorsi di rifiuto per cambiamenti importanti, incluso il modo in cui i partecipanti che non adottano continuano l'operazione, identificano il loro insieme di compatibilità ed evitano un'interoperazione ambigua.
8. DEVE garantire che gli artefatti di coordinamento richiesti possano essere eliminati, trasferiti, rispecchiati, reimplementati o sostituiti senza costi di transizione impossibili.
9. DOVREBBE avere registri, registrazioni, raccomandazioni e strumenti di coordinamento che descrivano la realtà adottata piuttosto che dichiarare esistente una realtà futura non adottata.
10. DEVE evitare di progettare un sistema in cui l’unico modo perché un cambiamento diventi reale è il riconoscimento preventivo da parte di un organismo in carica.

7.3. Implicazioni sulla progettazione

L’adozione volontaria è la prova operativa per verificare se un cambiamento è utile, tollerabile e compatibile con la reale implementazione.

Una proposta non è la realtà. Una raccomandazione non è la realtà. Un aggiornamento del registro non è la realtà. Un documento non è la realtà. La realtà appare quando i partecipanti implementano, convalidano, implementano e fanno affidamento sul cambiamento.

La mancata adozione non crea alcuno stato di violazione. Crea solo un fatto: il partecipante non ha aderito al set di compatibilità creato dalla modifica.

Ciò non elimina i processi standard, i registri, la documentazione o la revisione. Limita la loro pretesa. Possono aiutare i partecipanti a coordinarsi. Possono pubblicare materiale di riferimento. Possono descrivere l'adozione. Potrebbero raccomandare. Essi non possono, con la sola dichiarazione, rendere vincolante la realtà futura non adottata per i partecipanti che non la gestiscono.

8. Rapporto tra i tre principi

I tre principi si rafforzano a vicenda e non sono efficaci presi singolarmente.

La specifica iniziale minima garantisce che il livello comune contenga regole di convalida deterministiche anziché autorità discrezionale.

La decisione futura localizzata garantisce che le scelte future rimangano nelle mani dei partecipanti che eseguono il codice anziché essere ricatturate da un livello di approvazione centrale.

L'adozione volontaria garantisce che il cambiamento successivo sopravviva al contatto con l'implementazione e l'uso.

Un sistema che adotta solo uno o due di questi principi può riprodurre la stessa centralizzazione con altri mezzi.

– Le specifiche iniziali minime senza una futura decisione localizzata potrebbero comunque consentire l’accumulo dell’autorità dopo la distribuzione.
– La decisione futura localizzata senza specificazione iniziale minima può produrre ambiguità, perché i partecipanti non possono determinare localmente la validità.
– L’adozione volontaria senza validazione deterministica può produrre confusione, perché i partecipanti non sono in grado di distinguere la variazione compatibile dallo stato non valido.
– La convalida deterministica senza uscita, portabilità o sostituibilità può comunque produrre un lock-in se gli artefatti di tenuta dei registri diventano impossibili da abbandonare.

Insieme, i principi producono un sistema in cui lo strato comune è sottile, la validità è verificabile a livello locale, il cambiamento futuro è volontario e non è necessaria alcuna istituzione permanente per decidere il funzionamento ordinario.

9. Modello di progettazione consigliato

9.1. Strato comune deterministico

Lo strato comune DOVREBBE essere limitato a:

– semantica stabile degli identificatori;
– regole di validità deterministiche;
– regole di risoluzione dei conflitti necessarie per preservare l’unicità;
– requisiti di interoperabilità a livello di cavo o di protocollo;
– invarianti di sicurezza condivise;
– meccanismi di prova del controllo, ove necessario;
– formati di registrazione trasferibili e verificabili, laddove i registri siano necessari;
– segnalazione dell'estensione e identificazione del set di compatibilità.

Il livello comune NON DOVREBBE contenere:

– regole del modello di business;
– regole di prezzo;
– preferenze politiche regionali;
– ideologia dell’ammissibilità estranea alle invarianti tecniche;
– poteri esecutivi discrezionali;
– valutazioni soggettive di merito;
– ampliamento della missione istituzionale;
– qualsiasi norma la cui funzione primaria sia quella di preservare l'autorità di un organismo in carica.

9.2. Superficie decisionale dell'operatore

Quanto segue DOVREBBE rimanere al di fuori dello strato comune a meno che non alterino direttamente un'invariante globale dichiarata:

– tempi di implementazione;
– uso commerciale;
– geografia del cliente;
– accordi di leasing, finanziamento o trasferimento;
– preferenza di ammissibilità locale;
– sequenziamento operativo;
– pratica di instradamento non richiesta per la validità condivisa;
– modello di business;
– struttura organizzativa;
– tempistica della migrazione volontaria;
– profili o estensioni opzionali.

I partecipanti POSSONO adottare scelte diverse in queste aree. Tali scelte possono produrre diversi insiemi di compatibilità, relazioni commerciali, accordi di peering o comunità operative. Non creano invalidità a meno che non violino le regole di convalida deterministica in un set di compatibilità.

9.3. Ciclo di adozione

Ove fattibile, l'ordine preferito per la modifica del sistema dei materiali è:

1. proposta;
2. attuazione;
3. vettori di prova o metodo di verifica deterministico;
4. impiego limitato da parte di partecipanti disponibili;
5. osservazione dell'interoperabilità e degli effetti sulla sicurezza;
6. etichettatura del set di compatibilità;
7. documentazione o raccomandazione descrittiva della realtà adottata.

Un artefatto di coordinamento DOVREBBE seguire l'adozione piuttosto che tentare di anticiparla.

9.4. Uscita, biforcazione e portabilità

Un progetto conforme DOVREBBE considerare l'uscita, la biforcazione e la portabilità come normali requisiti di progettazione piuttosto che come fallimenti.

Il sistema DOVREBBE definire come un partecipante può:

– continuare in un set di compatibilità precedente;
– adottare un set di compatibilità più recente;
– eseguire il fork in un set di compatibilità diverso;
– registri portuali, identificatori, prove o stato operativo;
– verificare la validità dei registri senza fare affidamento su un custode dei registri in carica;
– interoperare selettivamente laddove la compatibilità lo consente.

Un sistema da cui non è possibile uscire o biforcarsi senza distruggere operazioni valide ha probabilmente nascosto un potere di governance all’interno della sua funzione di tenuta dei registri.

10. Applicabilità e Limiti

Questo modello di progettazione è particolarmente applicabile dove:

– il sistema è multiattore e multigiurisdizionale;
– questioni relative alla distribuzione indipendente;
– lo strato di coordinamento è destinato a rimanere sottile;
– la variazione futura è probabile ma non può essere prevista in dettaglio;
– il lock-in creerebbe un rischio di governance;
– la validità può essere resa deterministica o verificabile localmente.

Potrebbe essere meno direttamente applicabile laddove:

– l’architettura prevista è un unico dominio amministrativo;
– un forte accoppiamento in tempo reale richiede un comportamento uniforme in ogni momento;
– le preoccupazioni per la sicurezza della vita richiedono un’immediata uniformità globale;
– la validità non può essere verificata localmente mediante alcun meccanismo pratico.

Anche in questi casi, i progettisti DOVREBBERO comunque ridurre al minimo lo strato comune ed evitare, ove possibile, futuri controlli discrezionali.

11. Non gol

Questo documento non:

– vietare ogni coordinamento;
– vietare tutti i registri condivisi;
– richiedono tecnologia blockchain o registro distribuito;
– garantire il consenso;
– garantire la neutralità politica;
– richiedere a tutti i partecipanti di adottare ogni modifica successiva;
– considerare il rifiuto di adottare come invalidità;
– legittimare comportamenti locali incompatibili rivendicandone la compatibilità;
– eliminare la necessità di norme comuni fondamentali per la sicurezza.

12. Considerazioni sulla sicurezza

Uno strato di coordinamento più sottile può ridurre il rischio di cattura, abbassare il raggio d’azione dell’errore istituzionale e migliorare la sostituibilità. Tuttavia, una maggiore discrezione locale può anche creare un livello di sicurezza incoerente, percorsi di downgrade, pressione sulla frammentazione, dichiarazioni di compatibilità ambigue e fork non sicuri.

I progettisti che applicano questo documento DEVONO quindi specificare esplicitamente le invarianti di sicurezza. In particolare:

– i requisiti di autenticazione e autorizzazione richiesti per la validità condivisa DEVONO essere deterministici e verificabili localmente;
– la negoziazione della versione e la gestione delle estensioni DEVONO evitare il downgrade silenzioso laddove la sicurezza è compromessa;
– i percorsi di rifiuto, fork e sostituzione DEVONO essere analizzati per quanto riguarda il rischio di abuso e di negazione del servizio;
– le etichette di compatibilità DOVREBBERO essere sufficientemente chiare da impedire l'interoperabilità accidentale tra set di regole incompatibili;
– NON DEVE essere consentito alla variazione locale di dichiarare falsamente la compatibilità con un insieme di regole che non soddisfa.

L'esistenza di eccezioni di sicurezza non giustifica un livello di autorizzazione generale. Giustifica solo le regole di sicurezza deterministiche necessarie per preservare le Invarianti Globali dichiarate.

13. Considerazioni su IANA

Questo documento non contiene azioni IANA.

14. Riferimenti

14.1. Riferimenti normativi

– RFC 2119 – Bradner, S., Parole chiave da utilizzare nelle RFC per indicare i livelli di requisiti, BCP 14, RFC 2119.
– RFC 8174 – Leiba, B., Ambiguità tra maiuscolo e minuscolo nelle parole chiave RFC 2119, BCP 14, RFC 8174.

14.2. Riferimenti informativi

– RFC 6709 — Carpenter, B. e B. Aboba, Considerazioni sulla progettazione per le estensioni del protocollo, RFC 6709.
– RFC 7282 – Resnick, P., Sul consenso e sul ronzio nell'IETF, RFC7282.

Appendice A. Lista di controllo della progettazione

Un progetto che dichiara la conformità a questo documento DOVREBBE essere in grado di rispondere chiaramente alle seguenti domande:

1. Cosa sono gli Invarianti Globali?
2. Quali regole di validazione deterministica preservano tali Invarianti Globali?
3. Quali regole nelle Specifiche Iniziali sono strettamente necessarie per la prima implementazione?
4. Quali domande future vengono intenzionalmente lasciate fuori dallo strato comune?
5. Quali scelte future possono essere fatte dai partecipanti senza alterare l'insieme di compatibilità in cui si trovano?
6. In che modo un partecipante adotta una modifica successiva?
7. Come fa un partecipante a rifiutare una modifica successiva senza che gli venga assegnato lo stato non valido?
8. Come vengono etichettati o scoperti i set di compatibilità?
9. Come funziona il rifiuto locale quando lo stato non è valido o incompatibile con le regole applicate da un partecipante?
10. Qual è il percorso della biforcazione?
11. Qual è il percorso di portabilità?
12. Qual è il percorso di uscita da qualsiasi artefatto di coordinamento richiesto?
13. I partecipanti possono verificare la validità ordinaria senza affidarsi ad un conservatore in carica?
14. Le registrazioni e gli artefatti di coordinamento descrivono la realtà adottata o tentano di dichiarare esistente la realtà futura non adottata?
15. Il sistema ha ridotto al minimo il numero di decisioni integrate nello strato comune?
16. Il sistema ha evitato qualsiasi autorità continuativa che determini lo status di partecipante ordinario?

## Indirizzo dell'autore

H. Lu
[TBD]