Primazia del codice in esecuzione: la patch necessaria per preservare il design originale di Internet

Le sette note Heng.lu precedenti in questa sequenza sono:

1. Nota 52: Quando il potere del registro si stacca dalla responsabilità: perché l'attuale modello di coordinamento RIR non può sopravvivere nella sua forma attuale
2. Nota 53: Sul perché le risorse numeriche Internet non sono proprietà politica
3. Nota 56: Su come la spessa governance dei registri Internet regionali trasforma l’unicità in una doppia estrazione
4. Nota 58: Dalla doppia estrazione all'inversione della sovranità: come le nazioni perdono il controllo sovrano a RIRs per 100 dollari
5. Nota 59: La sanzione della povertà: come il modello RIR tassa i poveri chiamandola uguaglianza
6. Nota 61: Tradimento del codice in esecuzione: come il sistema RIR ha trasformato il consenso contro la comunità tecnica
7. Nota 62: Riciclaggio dei mandati: dalla fantasia di RIR all'architettura di transizione

I sette saggi precedenti non costituivano un programma di riforma dei Registri Internet Regionali.

Erano un'autopsia.

Hanno tracciato la stessa patologia istituzionale attraverso diversi strati: responsabilità svincolata dalle conseguenze; numero di risorse rietichettate come proprietà politica; l’unicità si è trasformata in doppia estrazione; sovranità invertita; povertà tassata in nome dell’uguaglianza; il consenso si rivoltò contro le reti che avrebbe dovuto servire; e infine mandato riciclato finché un impiegato non cominciò a sembrare un sovrano. La sequenza è importante perché il fallimento non è stato causato da un cattivo consiglio di amministrazione, da un cattivo registro, da una causa legale o da un evento di mercato scomodo. Era un difetto di sistema che si manifestava sotto vesti diverse. La pagina dell'autore di CircleID ora mostra chiaramente quella sequenza, incluso Tradimento del codice in esecuzione e Mandato di riciclaggio. (circleid.com)

Questo saggio non riguarda la creazione di governatori RIRs migliori.

Si tratta di spiegare perché l’attuale ordine di registro non può essere il punto finale e perché la riparazione meno distruttiva è un supplemento al progetto tecnico originale di Internet.

Quel supplemento lo è Primazia del codice in esecuzione.

La sua necessità non è più teorica. In un recente scambio di CircleID, John Curran ha fornito la forma più forte del caso in carica. La sua tesi è che l’autorità del sistema RIR non è semplicemente un sottoprodotto di un ristretto coordinamento tecnico, ma il risultato di una catena storica: il Libro bianco, ICANN, l’ASO, ICP-2, la transizione della stewardship IANA e la continua governance multistakeholder del settore privato. Afferma che l’autorità del sistema RIR è il risultato dell’operare all’interno del modello multistakeholder del settore privato diretto dal governo degli Stati Uniti. (circleid.com)

Questo argomento è utile perché rende visibile la controversia.

La questione non è più se esistesse o meno la delegazione storica. Naturalmente lo ha fatto. La questione è se una funzione di coordinamento storicamente delegata potrà successivamente ampliarsi fino a diventare un mandato di governance permanente attraverso lo stesso meccanismo di processo che controlla. La risposta che spetta è sì: la delega, il riconoscimento, la continuità istituzionale e la procedura comunitaria diventano un mandato che si rinnova automaticamente.

La risposta richiesta dal progetto tecnico originale di Internet è no.

La tradizione originale di Internet era più ristretta, più difficile e migliore. La RFC 3935 afferma che l’obiettivo dell’IETF è “far funzionare meglio Internet”; fonda il lavoro sulla competenza tecnica, sull’implementazione nel mondo reale e sul “consenso approssimativo e sul codice in esecuzione”. Si afferma inoltre che quando l'IETF non è responsabile di un protocollo o di una funzione, non tenta di esercitarne il controllo. (rfc-editor.org) RFC 7282 ripete la vecchia linea di David Clark: “Rifiutiamo: re, presidenti e voto” e “Crediamo in: consenso approssimativo e codice in vigore”. (rfc-editor.org) RFC 9592 rende il punto anti-sovrano ancora più chiaro: l’IETF non gestisce, controlla o pattuglia Internet e non è “la polizia del protocollo”. (rfc-editor.org)

Quella tradizione non ha mai significato che i documenti fossero magici. Significava che i documenti contavano quando aiutavano il funzionamento dei sistemi. Significava che il processo era tollerato perché serviva alla distribuzione. Significava che una stanza era utile solo quando si disciplinava rispetto alla realtà operativa.

Il livello del registro ha preso in prestito quella legittimità.

Non ha mai accettato completamente quella disciplina.

Questa è la patch mancante.

Cosa significa primazia del codice in esecuzione

Running-Code Primacy significa che i sistemi di coordinamento di Internet devono essere interpretati in modo restrittivo facendo riferimento alla funzione tecnica minima originariamente giustificata dalla gestione delle reti.

Il livello delle risorse numeriche esiste per proteggere i sistemi in esecuzione: unicità, interoperabilità, continuità del routing adiacente, asserzioni di sicurezza, prova di controllo e la semantica comune minima necessaria affinché le reti indipendenti lavorino insieme.

Non esiste per fabbricare autorità politica.

Non esiste per vigilare sulla moralità commerciale.

Non esiste per convertire la geografia del servizio in titolo.

Non esiste la possibilità di trasformare una mailing list in una legislatura.

Non esiste la possibilità che un registro privato faccia scomparire le risorse di rete già in funzione perché la sua teoria della politica interna cambia.

Un registro non è uno stato.

Un contatto del database non è una procura aziendale.

Una regione di servizio non è un popolo.

Una policy room non è una legislatura.

Un record del registro può descrivere la realtà operativa. Non lo crea.

Questo non è conservatorismo. Running-Code Primacy non dice che i sistemi distribuiti non possano mai cambiare. Afferma che il potere istituzionale sul cambiamento non deve essere giustificato da delegazioni storiche, riconoscimenti circolari o procedure rituali. Deve essere giustificato da regole deterministiche che gli operatori possono verificare localmente e mediante adozione nei sistemi in esecuzione.

L'ordine corretto è: specifica iniziale, stato del registro distribuito, convalida locale, implementazione in esecuzione, adozione volontaria, set di compatibilità, quindi documentazione.

L’ordine sbagliato è: policy room, dichiarazione, obbligo rivendicato, etichetta di conformità, conformità operativa forzata.

Il sistema RIR ha fallito perché ha scelto sempre più il secondo ordine.

La correzione fondamentale è questa: dopo la specificazione iniziale, non vi è alcuna istituzione continua a presentare petizioni. Nessun comitato decide se la mancata adozione costituisce una violazione. Nessun registro dichiara invalido un partecipante semplicemente perché rifiuta una modifica successiva. Esistono solo codice, stato del registro, convalida, adozione, compatibilità, rifiuto locale, fork e interoperazione selettiva.

Un operatore che rifiuta una modifica successiva non rompe Internet. Potrebbe rimanere in un set di compatibilità precedente. Potrebbe biforcarsi. Potrebbe disconnettersi. Potrebbe non riuscire a interagire con i partecipanti che hanno adottato regole incompatibili. Ma non può interrompere l’interoperabilità di altri che continuano a eseguire codice reciprocamente compatibile.

L’intuizione progettuale è la stessa che rende utili i registri distribuiti: non è necessaria alcuna istituzione permanente per decidere la validità ordinaria. I partecipanti convalidano le transizioni statali a livello locale secondo regole deterministiche. Lo stato invalido non è punito da un'istituzione. Viene ignorato dai partecipanti che non lo accettano.

Questa è la patch essenziale che manca al coordinamento numero-risorse.

Il fallimento della progettazione era presente fin dall'inizio

Il primo progetto RIR presupponeva un mondo di basso valore.

Le risorse numeriche sembravano tecniche, abbondanti, impiegatizie e a basso conflitto. In quel mondo, l’informalità sembrava efficiente. Le mailing list aperte sembravano rappresentative. L'amministrazione basata sui contatti sembrava adeguata. I contratti a responsabilità limitata sembravano innocui. Un registro regionale potrebbe assomigliare ad una rubrica.

La scarsità di IPv4 ha distrutto quella premessa.

Gli indirizzi IPv4 sono diventati scarsi, trasferibili, finanziabili, affittati, capitalizzati, oggetto di controversie, sanzionati e incorporati in reti attive. Il livello del registro non si trovava più sopra le voci degli impiegati. Si trovava sopra le infrastrutture produttive. Si trovava al di sopra del valore patrimoniale. Si collocava al di sopra della continuità del cliente, dell’implementazione del cloud, delle operazioni di telecomunicazione, della connettività nazionale, delle ordinanze dei tribunali e dell’allocazione del capitale.

La forma istituzionale non si è contratta per far fronte a quel nuovo rischio.

Si è espanso.

Il risultato è un sistema che parla ancora il linguaggio del coordinamento tecnico pur esercitando gli effetti della governance delle infrastrutture. Chiede agli operatori di considerare il processo di registrazione come neutrale mentre le decisioni relative al registro influiscono sul destino commerciale. Chiama i suoi partecipanti “comunità” mentre molti di coloro che ne sopportano le conseguenze non hanno mai dato una chiara rappresentanza legale alle persone presenti nella stanza.

NRS espone chiaramente il problema strutturale: i registri dei numeri Internet sono stati progettati come organismi di coordinamento tecnico, ma una volta che la scarsità di IPv4 ha trasformato gli indirizzi in risorse preziose, la discrezione del registro è diventata potere economico; quando i sistemi di coordinamento controllano il capitale, la centralizzazione diventa un rischio strutturale e la decentralizzazione diventa ingegneria dei sistemi piuttosto che ideologia. NRS afferma anche la direzione progettuale opposta: una sola Internet, un’infrastruttura aperta e autonoma e una governance decentralizzata con una partecipazione umana minima al centro. (nrs.aiuto)

Questo è il vero problema. Il livello del registro non è mai stato aggiornato nel momento in cui una tabella di coordinamento è diventata un asset gate.

Running-Code Primacy è quella patch.

Non è una dottrina migliore-RIR.

È una disciplina post-RIR.

Le tre regole della patch

La grammatica costruttiva è quella rivista Nota 64: Specifica minima iniziale, decisione futura localizzata e adozione volontaria per i sistemi di coordinamento Internet: Specifica iniziale minima, Decisione futura localizzata, e Adozione volontaria.

I nomi rimangono invariati. La logica deve essere precisa.

Specifica iniziale minima significa che lo strato comune contiene solo regole deterministiche e verificabili a livello locale necessarie per l'unicità, l'interoperabilità, la prova del controllo, la sicurezza condivisa e la protezione. Non contiene preferenze sui modelli di business, teorie sui prezzi, sentimento politico regionale, poteri discrezionali di applicazione o espansione della missione istituzionale.

Decisione futura localizzata non significa che un’istituzione decida quali decisioni future siano locali. Ciò reintrodurrebbe già il livello di autorità. Significa che la specifica iniziale esegue il lavoro di limitazione in anticipo. Dopo la distribuzione, le normali scelte future restano ai partecipanti che eseguono il codice. Un partecipante può adottare, rifiutare, biforcare, disconnettersi o interoperare selettivamente. Nessun partecipante può alterare l'interoperabilità degli altri che continuano a eseguire regole reciprocamente compatibili.

Adozione volontaria significa che il cambiamento successivo diventa reale solo attraverso l'implementazione, la convalida, la distribuzione e l'utilizzo. La pubblicazione non è la realtà. La raccomandazione non è la realtà. Il riconoscimento incombente non è la realtà. La mancata adozione non crea nessuno stato non valido. 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 di un altro partecipante può essere ignorato localmente. L’effetto è una selezione di compatibilità, non una punizione istituzionale.

Queste tre regole non ristabiliscono la sovranità del registro.

Impediscono che riapparisca con un nuovo nome.

APNIC: La struttura legale era il rischio

APNIC mostra il primo errore: il minimo non è mai stato specificato con sufficiente precisione all'inizio.

Questa non è una storia di codice di condotta. Non è una storia di etichetta. Non è una storia sul fatto se un critico sia stato abbastanza gentile nei confronti di un’istituzione in carica.

È una storia di struttura legale.

Nel marzo 2023, LARUS ha pubblicato una revisione legale avvertendo che la struttura di governance di APNIC creava rischi non solo per una società a Brisbane, ma per la governance di Internet in tutta la regione Asia-Pacifico. La revisione afferma che il Direttore generale di APNIC aveva il potere legale ultimo di chiudere APNIC e rimuovere il Consiglio esecutivo eletto e che erano necessari urgenti emendamenti alla governance. Ha inoltre affermato che la struttura ha sollevato dubbi sulla sicurezza della governance di Internet per oltre un miliardo di utenti Internet dell'Asia-Pacifico. (larus.net)

Il primo allegato, l'estratto aziendale ASIC, fornisce la baseline aziendale. APNIC Pty Ltd è stata quotata come società a responsabilità limitata australiana, registrata nel Queensland. Paul Byron Wilson era indicato come direttore e segretario. Le informazioni sulle azioni mostravano un'azione ordinaria emessa e Paul Byron Wilson era indicato come il membro che deteneva tale azione. (larus.net)

Questo non è il modo normale di ospitare una funzione critica di coordinamento regionale di Internet.

Il secondo allegato, il parere legale del dottor Peter Felter, ha tratto la conclusione in materia di governance. Descriveva la struttura pubblica di APNIC (membri, elezioni, consiglio esecutivo, direttore generale e segretariato) come un comitato speciale basato sull'articolo 9.3 dello statuto di APNIC Pty Ltd. Affermava che APNIC Pty Ltd era stata una società proprietaria controllata da un direttore, un azionista e un segretario, tutti la stessa persona, per 25 anni. (larus.net)

Questa distinzione è importante.

L’istituzione pubblica rivolta alla comunità non era il contenitore legale finale. Era un edificio costruito su una struttura aziendale privata.

Il parere legale ha poi spiegato perché la distinzione è importante. Lo statuto di APNIC è stato dichiarato soggetto allo Statuto e ai poteri della società e dei suoi amministratori, funzionari e membri. Secondo tale lettura, la struttura pubblica di APNIC potrebbe essere modificata dalla delibera del direttore di APNIC Pty Ltd; il parere descriveva APNIC come, in effetti, un dipartimento di APNIC Pty Ltd. (larus.net)

Il punto più dannoso dell’opinione non era che APNIC fosse tecnicamente illegale. Il fatto è che legalità e correttezza non sono la stessa cosa. Il parere sosteneva che l’accordo fiduciario non risolveva il problema perché i poteri del Consiglio esecutivo derivavano ancora dalla delibera del direttore che istituiva il comitato speciale. Ha inoltre osservato che APNIC Pty Ltd era una società per azioni privata la cui struttura e i cui oggetti non assomigliavano al modello no-profit non azionario che la maggior parte delle persone assocerebbe a un registro regionale di interesse pubblico. (larus.net)

Questo è il primo fallimento progettuale nella sua forma più pulita.

Un sistema di coordinamento dei numeri su scala regionale non dovrebbe dipendere da una struttura che richiede agli avvocati di spiegare perché una società con una sola azione, un comitato speciale, un atto di fiducia e un consiglio eletto si combinano in qualche modo per ottenere il controllo legittimo del registro dei numeri dell’Asia-Pacifico.

Uno strato di coordinamento critico dovrebbe essere leggibile dall'esterno.

Non dovrebbe richiedere la fiducia nei documenti dietro i documenti.

Non dovrebbe obbligare i membri a scoprire, dopo anni di dipendenza istituzionale, che il livello eletto potrebbe non essere il livello giuridico definitivo.

Non dovrebbe dare l’apparenza di una governance dei membri lasciando il potere formale altrove.

Questo è il motivo per cui la Specifica Iniziale Minima deve includere la validità distribuita, non la fiducia istituzionale. Non perché una futura istituzione necessiti di una migliore governance. Perché un futuro sistema post-RIR deve evitare del tutto di aver bisogno di tale istituzione.

Il livello comune non dovrebbe dipendere dalla struttura di controllo nascosta di una società proprietaria. Dovrebbe definire regole di convalida deterministiche, stato di prova del controllo, regole di transizione di stato, regole di conflitto, replica del registro, percorsi di uscita, percorsi di fork e set di compatibilità. Se APNIC scompare, si auto-acquisisce, cambia posizione legale o rifiuta di riconoscere uno stato valido, la rete in esecuzione non dovrebbe dipendere dal continuo riconoscimento di APNIC per sapere chi controlla quale numero di risorse.

Il registro non dovrebbe essere la fonte di validità.

Lo stato del registro distribuito, convalidato in base alla specifica iniziale, dovrebbe essere.

ARIN: la politica ha incontrato la realtà patrimoniale

L’ARIN mostra il secondo fallimento: la realtà giuridica e di mercato può superare la teoria dei registri.

L'evento decisivo è stata la transazione Nortel/Microsoft. Quando Nortel dichiarò bancarotta, i suoi 666.624 indirizzi IPv4 divennero beni preziosi nel procedimento. Gli indirizzi sono stati venduti a Microsoft per 7,5 milioni di dollari. L'ARIN è intervenuta partendo dall'ipotesi che gli indirizzi non fossero di proprietà e non potessero essere venduti liberamente e al di fuori delle norme anagrafiche. Industry Canada ha sostenuto questo punto di vista. Il tribunale fallimentare lo ha respinto; Microsoft ha successivamente firmato un accordo legacy; e il risultato pratico è stato chiaro: la politica dei registri non poteva rimanere l’unica fonte di realtà una volta che i tribunali e i mercati avessero trattato le risorse numeriche come risorse. (comunque.media)

La lezione importante non è che l’ARIN fosse l’unico difettoso.

La lezione è che il livello del registro è entrato in una nuova categoria.

Un registro è prezioso perché gli operatori, i tribunali, gli acquirenti, i venditori, i creditori e le reti fanno affidamento su di esso. Non diventa autorevole negando tale dipendenza. Rimane utile solo se segue la realtà legale, di mercato e operativa abbastanza da vicino da poter essere attendibile.

Una volta che IPv4 è diventato scarso, il processo di registro è diventato un'interfaccia di mercato. Le regole di trasferimento, le valutazioni dei bisogni, i ritardi nel riconoscimento e le restrizioni regionali hanno smesso di essere dettagli clericali. Sono diventati attriti patrimoniali. L’analisi pubblica ora descrive un regolamento RIR frammentato in cui cinque sistemi regionali governano un mercato scambiato a circa 18-45 dollari per indirizzo, con regole contrastanti in grado di bloccare asset, ritardare fusioni e costringere strutture aziendali separate semplicemente a detenere blocchi di numeri. (comunque.media)

Questo non è un coordinamento neutrale.

Si tratta di un effetto normativo senza responsabilità normativa.

ARIN dimostra perché l'adozione volontaria è importante. La politica del registro rimane credibile solo finché descrive ciò che gli attori effettivamente implementano, commerciano, finanziano, litigano e su cui fanno affidamento. Diventa pericoloso quando la pubblicazione viene considerata sufficiente a fabbricare la realtà.

Un registro che rifiuta la realtà non diventa sovrano.

Diventa un database obsoleto.

In un progetto Running-Code Primacy, la lezione è ancora più acuta. I tribunali e i mercati non hanno bisogno di un registro in carica per decidere se esiste valore. Gli operatori non hanno bisogno di un comitato per sapere se un blocco è in rotta. I partecipanti necessitano di regole deterministiche che consentano la prova del controllo, la risoluzione dei conflitti, le transizioni di stato visibili nel registro e la compatibilità. Il vecchio registro potrebbe pubblicare una vista. Un client software può visualizzare una vista. Un esploratore del registro può visualizzare una vista. Nessuna è la fonte della validità.

Non è presente alcun registro in cui spostarsi.

Non c'è nessun registro a cui chiedere.

Esiste solo uno stato distribuito da cui i partecipanti convalidano, accettano, rifiutano, effettuano il fork o con cui interagiscono.

AFRINIC: Quando la teoria del registro minacciava le risorse in esecuzione

AFRINIC è il caso centrale perché ha ridotto il problema all'essenziale.

La storia sbagliata è che un membro problematico abbia paralizzato un registro regionale.

Questo è il gioco morale attuale.

La storia strutturale è diversa. AFRINIC ha cercato di convertire l'uso commerciale, la geografia del cliente, il leasing, le relazioni con i membri e l'interpretazione delle politiche interne in un potere dichiarato di annullare la registrazione delle risorse numeriche già in esecuzione. Una volta avanzata tale affermazione, il conflitto non poteva più rimanere un disaccordo in sede politica. È diventato un test per verificare se un registro privato potesse utilizzare la retorica regionale e il silenzio politico per minacciare le risorse integrate a livello operativo.

I fatti non richiedono inflazione teatrale. I resoconti pubblici hanno descritto la controversia AFRINIC come una semplice disputa commerciale sugli indirizzi IP che è diventata la più grande storia di governance di Internet in Africa. È stato inoltre riferito che Cloud Innovation era stato spesso dipinto come il cattivo, mentre materiale documentario successivo indicava forze distruttive all'interno dello stesso AFRINIC e contenziosi ritardati, prolungati e portati avanti dai rappresentanti di AFRINIC a spese di AFRINIC. (comunque.media)

Questo è importante perché ribalta la solita storia.

Il contenzioso non ha creato il fallimento strutturale.

Il contenzioso lo ha scoperto.

Il fallimento rilevante era già presente quando un registro privato considerava l’assenza di un permesso esplicito come base per un controllo coercitivo. Il leasing non rappresentava una minaccia all’unicità. La geografia del cliente non era un'assegnazione duplicata. L'uso commerciale non è stato un fallimento nella sicurezza del routing. Un modello di business non gradito da un registro non era un'invariante globale.

Eppure la denuncia del registro ha collocato queste questioni all’interno di un quadro di revoca.

Questo è il momento in cui il coordinamento diventa governance.

Reporting registra che AFRINIC ha inviato a Cloud Innovation una lettera nel marzo 2021 in cui denunciava violazioni delle politiche e minacciava la cessazione dell'iscrizione; che nel luglio 2021 la Corte Suprema di Mauritius ha vietato a AFRINIC di revocare l'adesione a Cloud Innovation; e che un ulteriore tentativo da parte di AFRINIC di annullare l'iscrizione è stato bloccato nel dicembre 2021. (comunque.media). Questa sequenza non è la storia di un registro che protegge tranquillamente Internet. È una storia di autorità anagrafe che incontra la legge ordinaria.

Né il più ampio collasso istituzionale è stato causato da uno scarso potere di registrazione. Il problema più profondo era il lock-in. Se un registro detiene il monopolio su beni di valore, ogni fallimento interno diventa un rischio per la continuità di Internet. Se i membri non possono uscire dal sistema di riconoscimento, il fallimento del registro diventa un potere in ostaggio.

Un registro può correggere frodi di registrazione dimostrabili nei propri archivi.

Potrebbe impedire l'assegnazione duplicata mentre il modello di registro esiste ancora.

Potrebbe mantenere le asserzioni di sicurezza mentre i partecipanti continuano a fare affidamento su di esso.

Ma quelle sono funzioni transitorie di una vecchia architettura.

In un'architettura successiva a RIR, tali funzioni non vengono eseguite da un registro. Sono codificati in stati di contabilità distribuita, regole di prova di controllo, regole di conflitto e transizioni verificabili a livello locale.

Un ente privato non dovrebbe trasformare il leasing in un tradimento regionale.

Non dovrebbe trasformare la geografia del cliente in un fattore scatenante di revoca.

Non dovrebbe trattare il disaccordo commerciale come invalidità tecnica.

Non dovrebbe convertire la continuità patrimoniale in autorizzazione.

AFRINIC dimostra la necessità di una decisione futura localizzata correttamente compresa. Non esiste un organo centrale che decida se una futura decisione commerciale “appartiene al locale”. Piuttosto, la specificazione iniziale deve garantire che queste decisioni non entrino mai nello strato comune. Il leasing, la geografia del cliente, l'uso commerciale, i prezzi, il finanziamento, il mix di clienti e la strategia di implementazione rimangono al di fuori delle regole di validità deterministica a meno che non incidano direttamente sull'unicità, sulla sicurezza, sulla prova del controllo o sull'interoperabilità.

Un operatore non può interrompere l’interoperabilità di altri operatori affittando indirizzi.

Un operatore non può compromettere l’interoperabilità di altri operatori servendo clienti al di fuori di una regione storica del registro.

Un operatore non può compromettere l’interoperabilità di altri operatori utilizzando un modello di business che non piace a un registro.

Al massimo, un operatore può non riuscire a soddisfare le regole deterministiche applicate dagli altri partecipanti. In tal caso, gli altri partecipanti rifiutano localmente lo stato non valido. Non esiste uno strato di punizione. Non esiste un tribunale di conformità. Non esiste un sovrano regionale.

Questa linea non è ideologica.

È operativo.

Il problema proxy non è un dettaglio

La controversia elettorale di AFRINIC ha reso visibile un secondo difetto: la rappresentanza.

NRS dichiara la sua base rappresentativa in termini giuridici diretti. Si afferma che i membri elencati hanno affidato a NRS il compito di rappresentarli nelle questioni di governance di RIR e che ciascun membro elencato ha fornito una procura. (nrs.aiuto) Durante la disputa elettorale di AFRINIC, NRS ha chiesto ai membri di riferire se i loro nomi fossero apparsi sulle liste elettorali o se i voti fossero stati registrati senza la loro partecipazione, e ha affermato che tale segnalazione fattuale sarebbe stata gestita attraverso canali legali. (nrs.aiuto)

Ciò è importante perché mostra la differenza tra rappresentanza legale e retorica comunitaria.

Il sistema RIR spesso comprime diverse categorie in una: rappresentante aziendale, contatto del database, contatto tecnico, dipendente, consulente, procuratore, partecipante alla politica, utente abituale della mailing list. Queste non sono la stessa cosa.

Un contatto del database può aiutare ad amministrare i record.

Una procura può autorizzare la rappresentanza se valida e nell'ambito di applicazione.

Un partecipante alla politica può apportare competenze.

Un relatore della mailing list può esprimere un'opinione.

Nessuno di questi diventa automaticamente un soggetto giuridico per ogni azienda, cliente, stato, creditore, finanziatore, acquirente, locatario o rete che porta le conseguenze di una decisione del registro.

Questa distinzione può essere ignorata solo finché lo strato comune rimane sottile. Una volta che il registro rivendica il potere su revoca, trasferimento, locazione, accesso al mercato, trattamento delle sanzioni, continuità patrimoniale o rischio infrastrutturale nazionale, la rappresentanza diventa costituzionale.

Una stanza non è un mandato.

Una mailing list non è un popolo.

Un record di contatto non è una procura aziendale.

Una regione di servizio non è una circoscrizione elettorale sovrana.

Questa non è meticolosità procedurale.

È la differenza tra coordinazione e regola.

Un sistema Running-Code Primacy evita questa trappola riducendo il numero di decisioni che richiedono una rappresentanza. Se la validità è deterministica e locale, c’è meno su cui votare. Se il cambiamento futuro è volontario, non è necessario decidere se un non adottante è in cattiva reputazione. Se lo stato è rappresentato su un registro distribuito, non è necessario chiedere al registro in carica di riconoscere la continua esistenza di uno stato. Se gli insiemi di compatibilità sono espliciti, i partecipanti sanno con chi possono interagire senza chiedere spazio politico.

Il miglior problema di governance è quello che la progettazione del sistema rimuove.

RIPE NCC and LACNIC: The Club and the Choke Point

RIPE NCC and LACNIC do not prove that some RIRs are more civilised than others. They prove that the RIR model has two enforcement layers beyond the technical function: the club e il punto di strozzatura.

Il club decide chi è rispettabile. The choke point decides whose registry status can move.

RIPE NCC’s refusal to accept LARUS sponsorship for RIPE 90 showed the club layer plainly. Un membro ha offerto la sponsorizzazione. The registry-side ecosystem rejected it because of an unrelated dispute in another region. Non è stata una decisione relativa alla sicurezza del routing. Non è stata una decisione di unicità. Non era una regola di convalida deterministica. It was private blacklisting through conference access. Anche il LACNIC ha rifiutato la mia sponsorizzazione. Regione diversa, stesso istinto: il club anagrafico si tutela controllando spazi, visibilità, sponsorizzazioni, reputazione e legittimità sociale.

Questa non è comunità. È un servizio di controllo.

Il livello delle sanzioni è peggiore perché mostra il punto di strozzatura centrale nella forma giuridica. RIPE NCC afferma che, poiché ha sede nei Paesi Bassi, deve rispettare le sanzioni dell'UE; quando si applicano sanzioni, congela la registrazione nel database RIPE, blocca l'acquisizione e il trasferimento e può trattare i casi come congelati quando una parte non può fornire documentazione sufficiente. Esamina anche gli elenchi OFAC perché i rapporti bancari influiscono sui pagamenti. (RIPE NCC sancisce la trasparenza)

Questa non è una critica a RIPE NCC per aver obbedito alla legge. Un'entità olandese deve rispettare la legge olandese e dell'UE. Il problema è l’architettura: perché un ente privato olandese dovrebbe essere il punto di riconoscimento centrale per la mobilità delle risorse numeriche in molti paesi, operatori e sistemi legali?

Le sanzioni possono vincolare una banca. Le sanzioni possono vincolare un'entità olandese. Le sanzioni possono vincolare una controparte che sceglie di non effettuare transazioni. Non dovrebbero diventare una condizione di validità tecnica globale per tutti gli altri.

Questo è il fallimento della progettazione.

La stessa centralità che consente a un club di escludere un critico consente anche a una giurisdizione di congelare la mobilità dei registri. Uno è l’applicazione sociale. L'altro è l'applicazione della legge. Entrambi funzionano solo perché il registro si trova dove non dovrebbe trovarsi la validità.

Ciò si collega direttamente ai tre principi.

Specifica iniziale minima: la rispettabilità del club, l’idoneità alla sponsorizzazione, la politica regionale, la classificazione delle sanzioni e la reputazione non devono mai entrare nello strato comune. Lo strato comune dovrebbe contenere solo regole deterministiche per l’unicità, la prova del controllo, la gestione dei conflitti, la transizione di stato e la sicurezza.

Decisione futura localizzata: Il rischio legale, la scelta della controparte, la sponsorizzazione, la fiducia commerciale e l'esposizione alle sanzioni appartengono agli attori che li sopportano. Un'entità olandese può rifiutare una transazione. Una banca può rifiutare il pagamento. Una controparte può rifiutarsi di negoziare. Niente di tutto ciò dovrebbe diventare la verità del registro universale.

Adozione volontaria: i partecipanti accettano le controparti eseguendo il codice, convalidando lo stato e scegliendo con chi interagire. La mancata adozione non è una cattiva condotta. Il rifiuto locale non è invalidità globale. Il rifiuto di un club non dovrebbe cancellare lo stato valido. Un obbligo di sanzioni dovrebbe vincolare l’attore soggetto ad esso, non riscrivere il registro delle risorse numeriche del mondo.

Questo è il motivo per cui è necessaria la progettazione di registri distribuiti. In un sistema post-RIR, la validità ordinaria non è decisa da RIPE NCC, LACNIC, un ufficio sanzioni, un comitato di riunione o un ufficio sponsor. I partecipanti convalidano lo stato a livello locale. Le controparti accettano o rifiutano volontariamente. Le forche sono visibili. I set di compatibilità sono espliciti. Il registro centrale scompare come fonte di verità.

La soluzione non è una migliore etichetta.

La soluzione non è una coda di sanzioni più trasparente.

La soluzione è rimuovere la validità sia dal club che dal punto di strozzatura.

Stato distribuito. Convalida locale. Accettazione volontaria della controparte. Nessun registro come fonte di validità.

La lettera NRO: fuga verso l'alto

La prova più seria non è il tentativo di esagerazione di AFRINIC.

È la risposta collettiva del sistema.

Nel 2022, la Number Resource Organization ha scritto al governo di Mauritius. La lettera descriveva l’NRO come l’organismo di coordinamento per RIRs mondiale e affermava che RIRs gestisce numerose risorse nelle rispettive regioni. Ha affermato che tutti e cinque i registri svolgono la funzione di amministrare le risorse numeriche secondo regole adottate a livello regionale o politiche globali adottate all'unanimità. (nro.net)

La stessa lettera criticava il contenzioso di Cloud Innovation, affermava che erano state intentate più di 25 cause legali, si lamentava di ordinanze del tribunale che avevano congelato i conti di AFRINIC e interrotto le elezioni, e affermava che AFRINIC aveva ripetutamente chiesto a Mauritius di riconoscerlo come organizzazione internazionale. L’NRO ha esortato il governo ad adottare misure per preservare l’indipendenza di AFRINIC e la stabilità di Internet in Africa. (nro.net)

Questo è il documento più rivelatore di tutta la storia.

Quando un registro privato si è scontrato con i tribunali ordinari, il riflesso del sistema è stato quello di non restringere il mandato.

Non era per rimuovere il blocco del registro.

Non si trattava di separare la tenuta dei registri dall'applicazione delle norme.

Non si trattava di definire la convalida distribuita.

Non si trattava di chiedersi se il potere di cancellazione unilaterale sui beni in gestione fosse stato illegittimo fin dall’inizio.

Il riflesso era la fuga verso l'alto.

Un organismo di coordinamento privato non può essere tecnico quando vuole discrezione, basato sulla comunità quando vuole legittimità, contrattuale quando vuole compensi, non patrimoniale quando vuole evitare la responsabilità della proprietà e quasi internazionale quando vuole isolamento dai tribunali.

Quel pacchetto non è governance.

Si tratta di riciclaggio di mandato a livello di sistema.

Se RIRs vuole i privilegi di diritto pubblico, deve accettare la responsabilità di diritto pubblico. Se vogliono la flessibilità del diritto privato, devono accettare il contenzioso di diritto privato. Ciò che non possono razionalmente chiedere è la discrezione privata, l’importanza delle infrastrutture pubbliche, la bassa responsabilità, la debole rappresentanza, lo status di monopolio e l’isolamento quasi diplomatico allo stesso tempo.

Questo è il percorso del disastro.

Running-Code Primacy lo rifiuta.

Quando un registro incontra resistenza legale, non deve sfuggire all’immunità. L'architettura deve contrarsi verso il basso nella ristretta funzione del codice in esecuzione che la giustifica.

Meno sovranità.

Nessun registro come fonte di validità.

Meno applicazione.

Convalida più distribuita.

La revisione dell’ICP-2 non è sufficiente

Il sistema attuale sa che qualcosa si è rotto.

La pagina di commento pubblico di ICANN per la seconda bozza del documento di governance di RIR afferma che la proposta fisserebbe regole e criteri per il riconoscimento del nuovo RIRs, obblighi operativi e requisiti di RIRs e regole di cancellazione; se adottato, sostituirebbe l’ICP-2. La stessa pagina afferma che il processo è stato avviato dopo che l'NRO ha chiesto all'ASO di proporre aggiornamenti per fornire al sistema RIR una maggiore responsabilità nei confronti della comunità Internet. (icann.org)

Ciò potrebbe essere necessario come misura di continuità.

Non è sufficiente come teoria della legittimità.

Le regole di riconoscimento e cancellazione rispondono a una domanda tardiva: quando un registro ha fallito abbastanza gravemente da essere rimosso?

La domanda precedente è più importante: perché un registro dovrebbe essere abbastanza potente da fallire in modo catastrofico?

Un successore dell’ICP-2 che si limiti a rafforzare il riconoscimento, l’audit, il trasferimento e l’eliminazione del riconoscimento potrebbe migliorare l’igiene istituzionale preservando l’errore di categoria. Si presuppone ancora che RIR sia la forma sovrana primaria di coordinamento numero-risorse.

Running-Code Primacy pone una serie diversa di domande.

Come continua Internet se un RIR crolla?

In che modo le richieste relative alle risorse numeriche rimangono verificabili senza il permesso dell'operatore storico?

Come sopravvive l’unicità senza la discrezionalità monopolistica?

Come si può evitare che i documenti diventino armi di controllo?

In che modo le decisioni commerciali vengono mantenute al di fuori della validità deterministica a meno che non sia a rischio una vera invariante globale?

In che modo il coordinamento rimane utilizzabile senza alcun registro autorevole?

Come fa un operatore a convalidare lo stato ordinario senza chiedere lo status ad un organismo permanente?

In che modo il rifiuto evita di diventare un'etichetta di violazione?

Queste non sono questioni di riforma.

Sono domande post-RIR.

Perché questa è la toppa del design originale

La questione non è se piacciano o meno i registri in carica.

La questione è se il livello delle risorse numeriche segue ancora la disciplina di progettazione che ha fatto funzionare Internet: regole minime comuni, convalida locale, adozione volontaria e codice funzionante.

Running-Code Primacy non è una strategia di pubbliche relazioni né un compromesso istituzionale. È la riparazione tecnica implicita nel progetto originale. Se Internet è stata costruita per rifiutare re, presidenti e votazioni come fonti di verità tecnica, allora il livello delle risorse numeriche non può ricreare quelle forme attraverso il processo di registrazione, la delega storica o il teatro comunitario.

Solo il consenso può essere ritualizzato. Il solo codice in esecuzione può essere subordinato se il livello del registro si trova a monte del riconoscimento. La regola mancante è interpretativa e architettonica: laddove il processo istituzionale entra in conflitto con la funzione tecnica minima richiesta dai sistemi in esecuzione, il codice in esecuzione ha la priorità; e laddove venga proposto un cambiamento successivo, questo diventa reale solo attraverso l'adozione volontaria da parte dei partecipanti che applicano regole di convalida.

In questo modo il design originale viene preservato e non abbandonato.

Internet ha avuto importanza perché è diventato il primo sistema di comunicazione globale che non richiedeva il permesso preventivo di un singolo sovrano, ministero, chiesa, azienda o custode. Se vale ancora la pena difendere questo risultato, il livello del registro non può diventare l’eccezione che inghiotte la regola.

Un sistema costruito per evitare i re non può consentire a un contabile di fare un provino per il ruolo di re.

La patch ripristina la gerarchia originale: prima il codice, prima gli operatori, prima la validazione deterministica, prima lo stato distribuito; le istituzioni, se ce ne sono, rimangono durante la transizione solo come artefatti non autorevoli, mai come fonti di validità.

Cosa richiede il coordinamento post-RIR

Il coordinamento post-RIR non significa caos.

Ciò significa che lo strato comune diventa più sottile, più oggettivo, più deterministico e più distribuito rispetto all’attuale monopolio RIR.

Non è presente alcun registro in cui spostarsi.

Non esiste un nuovo registro da incoronare.

Non esiste un sacerdozio sostitutivo.

Esiste un registro distribuito dello stato delle risorse numeriche, con regole di convalida deterministiche, meccanismi di prova di controllo, gestione dei conflitti, set di compatibilità, cronologia delle transizioni di stato e verifica locale da parte dei partecipanti.

Il livello comune dovrebbe preservare l'unicità dell'identificatore, la prova del controllo, lo stato del trasferimento, lo stato della delega, le asserzioni di sicurezza adiacenti al routing, la verificabilità, i metadati dei conflitti e la visibilità del fork.

Il livello operatore dovrebbe controllare l’uso commerciale, il leasing, la geografia del cliente, le pratiche di instradamento, il finanziamento, la selezione della controparte e le regole aziendali non invarianti.

Il livello di adozione dovrebbe determinare ciò che diventa reale. Una regola di coordinamento è importante solo se gli operatori possono attuarla, le controparti possono accettarla, i mercati possono fare affidamento su di essa, i tribunali possono capirla e l’interoperabilità è preservata senza fare del riconoscimento dominante l’unica fonte di realtà.

Il livello di applicazione non deve essere fuso con il livello di stato. Un registro distribuito può registrare lo stato. Può convalidare le transizioni. Potrebbe esporre conflitti. Potrebbe rendere la prova portatile. Non deve diventare allo stesso tempo pubblico ministero, giudice, autorità sanzionatoria, regolatore del mercato, moralista commerciale e custode di beni.

Ancora più importante, la portabilità deve essere compresa correttamente.

In un mondo di registri distribuiti, portabilità non significa spostarsi da un registro a un altro. Questo è ancora il pensiero del registro. Non è presente alcun registro in cui spostarsi. La prova del controllo, la storia dello stato e la capacità di trasferimento del titolare non sono intrappolati in un database storico. Esistono in uno stato verificabile condiviso che i partecipanti convalidano localmente e le controparti accettano volontariamente.

Senza ciò, ogni registro è un punto di blocco.

Con esso il registro scompare come fonte di validità.

Il coordinamento post-RIR necessita pertanto di quattro proprietà di progettazione.

Innanzitutto, validità deterministica. Un partecipante dovrebbe sapere se una transizione di stato, una prova, una delega, un trasferimento o un'asserzione è valida applicando la specifica localmente.

In secondo luogo, i set di compatibilità. Se i partecipanti adottassero regole future diverse, il sistema dovrebbe descrivere chiaramente il confine di compatibilità piuttosto che trattare il dissenso come una cattiva condotta.

Terzo, prova di controllo distribuita. Un titolare non dovrebbe “spostare” le proprie risorse in un altro registro; dovrebbe dimostrare il controllo attraverso uno stato di validità del registro che qualsiasi controparte può verificare senza la benedizione del titolare.

In quarto luogo, visibilità della forcella. Se le serie di regole divergono, la divergenza dovrebbe essere esplicita. I partecipanti decidono quale set di compatibilità eseguire e quali controparti accettare. Un fork può isolare i partecipanti. Non conferisce a una parte il potere istituzionale di cancellare l’altra.

Questo non è un argomento a favore di cinque monopoli migliori.

È un argomento contro il monopolio come fonte di validità.

Perché il percorso del fallimento è prevedibile

Se non cambia nulla, il percorso del fallimento è chiaro.

In primo luogo, sempre più controversie si sposteranno dalle aule politiche ai tribunali. Le risorse scarse attirano il controllo legale. Ai tribunali verrà chiesto di congelare i conti, conservare i registri, bloccare elezioni improprie, nominare curatori fallimentari, riconoscere i trasferimenti o determinare chi può agire per un registro.

In secondo luogo, gli stati smetteranno di trattare RIRs come associazioni tecniche innocue. La continuità della numerazione tocca la connettività nazionale, le sanzioni, le forze dell’ordine, la resilienza delle telecomunicazioni, l’infrastruttura cloud e la sicurezza economica. Nessuno stato accetterà per sempre un registro privato straniero come punto a monte non esaminato della continuità delle comunicazioni nazionali.

In terzo luogo, gli operatori eviteranno, ove possibile, l'autorità di registrazione. Se i registri del registro diventano politici, non sicuri, non rappresentativi o distaccati dalla realtà patrimoniale, gli operatori faranno affidamento su contratti privati, trasferimenti sostenuti da contenziosi, attestazioni alternative, riconoscimento nazionale o realtà di routing de facto.

In quarto luogo, ICANN e il livello NRO saranno tentati di centralizzare. Ciò produrrebbe una versione più complessa dello stesso problema, a meno che il mandato stesso non venga ristretto.

In quinto luogo, i governi saranno tentati di nazionalizzare. Sarebbe prevedibile e pericoloso. Se i registri privati ​​rivendicassero un’autorità quasi sovrana senza responsabilità pubblica, gli stati alla fine reclamerebbero la sovranità. Il risultato potrebbe essere frammentazione, ritorsioni, registri contrastanti e pressioni politiche.

Internet non fallisce solo quando i pacchetti smettono di muoversi.

Fallisce anche quando le istituzioni che descrivono chi può utilizzare gli identificatori perdono la fiducia degli operatori che spostano i pacchetti.

Un registro distribuito non risolve tutti i problemi politici. Fa qualcosa di più importante: rimuove il registro permanente come fonte ordinaria di validità. Ciò restringe la superficie di attacco. Riduce il potere istituzionale in ostaggio. Trasforma il disaccordo futuro in una selezione di compatibilità piuttosto che in una guerra amministrativa.

La domanda cambia

Il vecchio sistema chiede: chi ha il mandato?

Questa è la domanda sbagliata.

La domanda migliore è: cosa richiede effettivamente l'esecuzione del codice?

Questa regola tutela l’unicità?

Preserva l’interoperabilità?

Corregge le frodi di registrazione dimostrabili attraverso prove deterministiche?

Protegge la sicurezza del routing adiacente?

Mantiene l'accuratezza della prova di controllo?

Abilita la convalida locale?

Elimina la dipendenza da un operatore storico?

Descrive la realtà adottata o dichiara un obbligo non adottato?

Un partecipante può rifiutarlo senza che gli venga assegnato lo stato non valido?

Un partecipante può verificare la validità ordinaria senza chiedere lo status ad un'anagrafe?

Una controparte può accettare o rifiutare volontariamente lo Stato?

Può verificarsi un bivio senza che una parte venga cancellata da un’istituzione?

Se la risposta non è legata alla necessità deterministica del codice in esecuzione, il potere non dovrebbe risiedere nello strato comune.

Questa è la primazia del codice in esecuzione.

Per la discussione

Questa proposta è oggetto di discussione. Non è una soluzione definitiva.

Il passo successivo dovrebbe essere un documento serio in stile Internet-Draft o BCP che definisca la Running-Code Primacy per i sistemi di coordinamento di Internet, iniziando con le risorse numeriche. La bozza non dovrebbe chiedere come riabilitare il monopolio di RIR. Dovrebbe chiedersi come costruire il coordinamento post-RIR attraverso lo stato dei registri distribuiti, la convalida deterministica, l’adozione volontaria, l’accettazione della controparte e set di compatibilità espliciti.

Dovrebbe essere testato da operatori, avvocati, economisti, ingegneri di protocollo, esperti di sicurezza del routing, partecipanti al mercato, governi e critici.

La bozza dovrebbe porre domande difficili.

Quali sono gli invarianti globali?

Quali regole di validazione sono deterministiche?

Quali transizioni di stato devono essere visibili a livello globale?

Quali vecchi poteri anagrafici sono residui storici?

Quali decisioni spettano agli operatori?

Quali decisioni non richiedono alcuna rappresentanza perché non dovrebbero mai entrare nello strato comune?

Qual è il percorso di rifiuto?

Qual è il percorso del bivio?

Qual è il percorso di rifiuto locale?

Come fa un titolare a dimostrare il controllo senza un registro storico?

Come fa una controparte a verificare lo stato senza un registro?

Internet può continuare se un RIR crolla?

Le risorse numeriche possono rimanere uniche senza l'autorizzazione del titolare?

Un partecipante può convalidare lo stato ordinario senza un'istituzione permanente?

Può un processo politico distinguere un’invariante del codice corrente dall’appetito istituzionale?

Il vecchio livello del registro può scomparire senza perdere lo stato verificabile?

Può un documento descrivere la realtà senza diventarne sovrano?

Chi fosse interessato può contattarmi tramite LinkedIn. Ricercatori seri, autori tecnici, istituzioni o esperti politici che vogliono contribuire a trasformare questo in una prima bozza Internet ed eventualmente in una discussione RFC o BCP, se la comunità lo ritiene utile, dovrebbero contattarmi. LARUS Foundation e sono disposto a sostenere e finanziare una ricerca seria in questa direzione.

Il primo progetto del sistema RIR fallì perché non chiedeva mai quale codice in esecuzione richiedesse effettivamente.

Si chiedeva chi potesse parlare nella stanza.

Il prossimo sistema dovrà invertire quell’ordine.

Non imporre il riciclaggio.

Non è un tradimento del codice in esecuzione.

Primazia del codice in esecuzione.

Appendice: Specifica minima iniziale, Decisione futura localizzata e Adozione volontaria per i sistemi di coordinamento Internet

Nota 64

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 localmente richieste per l'unicità, l'interoperabilità, la prova del controllo, 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.

Il modello di progettazione previsto è un registro distribuito di stato valido o un meccanismo di stato verificabile distribuito equivalente, non una gerarchia di registro. Non esiste un registro permanente che ne decida la validità ordinaria. I partecipanti convalidano lo stato a livello locale, accettano volontariamente le controparti e decidono quali set di compatibilità eseguire.

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, sistemi di identificazione, registri distribuiti 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, uno stato del registro o un record di prova di controllo. 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 prova del controllo, 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 rispetto allo stato condiviso. 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 lezione generale della progettazione dei registri distribuiti: le regole di consenso vengono applicate dai partecipanti che eseguono il codice di convalida e decidono quale stato accettare, 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 sistemi di identificazione, strutture di denominazione e numerazione, meccanismi di estensione dei protocolli, sistemi di prova di controllo, sistemi di portabilità, registri distribuiti 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 alcuna implementazione specifica della contabilità distribuita. Richiede una proprietà di progettazione: i partecipanti dovrebbero essere in grado di determinare la validità applicando la Specifica Iniziale localmente a uno stato condiviso o replicabile, 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, regole di transizione di stato e regole di conflitto necessarie 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.

Registro distribuito:
Una registrazione replicata o altrimenti distribuita delle transizioni di stato che consente ai partecipanti di verificare la validità ordinaria senza fare affidamento su un registro permanente, un comitato o altra autorità. Il termine non richiede alcun algoritmo o implementazione di consenso particolare.

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:
Una proprietà che deve rimanere comune all'interno di un set di compatibilità per preservare l'unicità, l'interoperabilità di base, l'integrità della prova di controllo, 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.

Accettazione della controparte:
La decisione volontaria di un partecipante di accettare, effettuare transazioni, interagire o fare affidamento sullo stato di un altro partecipante in base alle regole di convalida da esso applicate.

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 raccomandazione, una nota di implementazione, un profilo, un'implementazione di riferimento, un esploratore del registro, uno specchio 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; rappresentare uno stato valido in forma distribuita o altrimenti replicabile; lasciare le scelte non invarianti al di fuori dello strato comune; e consentire che i cambiamenti successivi diventino reali solo quando i partecipanti li adottano volontariamente nei sistemi in esecuzione.

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 prova del controllo, 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. DEVE definire come lo stato valido viene rappresentato, replicato, verificato e aggiornato.
4. 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.
5. DEVONO separare le regole di convalida dalle preferenze politiche, dagli accordi aziendali, dai ruoli istituzionali, dalle aspirazioni di governance e dal giudizio discrezionale.
6. DEVE consentire ai partecipanti di verificare la validità ordinaria a livello locale senza chiedere ad alcuna istituzione, registro, comitato, organo politico o altra autorità.
7. DOVREBBE definire strutture di dati, firme, prove, regole di transizione di stato, regole di conflitto o altri meccanismi necessari per la verifica locale.
8. 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.
9. DEVE garantire che gli artefatti di coordinamento richiesti siano portabili, verificabili, riproducibili e sostituibili.
10. DOVREBBE preferire condizioni oggettive verificabili dalla macchina rispetto al giudizio di merito soggettivo.
11. 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 prova del controllo, la sicurezza condivisa e la protezione; E
• cosa può rimanere al di fuori del livello comune perché riguarda la preferenza dell’operatore, la pratica commerciale, la scelta della controparte, 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 un'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 trattare 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 convalida 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. DEVONO consentire ai partecipanti di scegliere volontariamente le controparti in base alle regole di convalida e ai set di compatibilità che accettano.
9. 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.
10. 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.
11. DOVREBBE evitare qualsiasi progetto in cui un custode 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 prova del controllo, 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, l'accettazione delle controparti e l'adozione da parte dei partecipanti, non attraverso la sola pubblicazione o dichiarazione.

7.2. Requisiti

Un progetto che utilizza questo principio:

1. NON DEVE considerare la pubblicazione, la raccomandazione, l'approvazione della riunione o l'approvazione procedurale come sufficiente a creare un obbligo operativo universale.
2. DEVE consentire l'implementazione incrementale di nuove regole, estensioni, profili o procedure da parte dei partecipanti che scelgono di eseguirli.
3. DEVE consentire ai partecipanti di rifiutare una modifica successiva senza acquisire uno 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à, le linee guida per la 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 interoperazioni ambigue.
8. DEVE garantire che gli artefatti di coordinamento richiesti possano essere eliminati, rispecchiati, reimplementati o sostituiti senza costi di transizione impossibili.
9. DOVREBBE avere registrazioni, raccomandazioni e artefatti 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 documento non è la realtà. La realtà appare quando i partecipanti implementano, convalidano, implementano, accettano le controparti 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, la documentazione, le note di implementazione, gli esploratori, i mirror 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, la verifica, l'accettazione della controparte e l'utilizzo.

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

• La specifica minima iniziale senza una futura decisione localizzata può 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 stato distribuito può comunque lasciare i partecipanti dipendenti da un custode dei registri privilegiato.
• Lo stato distribuito senza visibilità del fork può nascondere il disaccordo fino al fallimento operativo.
• Lo stato distribuito senza l’accettazione volontaria della controparte può ricreare la coercizione attraverso un’altra interfaccia.

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

9. Modello di progettazione consigliato

9.1. Strato comune distribuito deterministico

Lo strato comune DOVREBBE essere limitato a:

• semantica dell'identificatore stabile;
• regole di validità deterministiche;
• regole di risoluzione dei conflitti necessarie per preservare l'unicità;
• meccanismi di prova del controllo;
• regole di transizione tra stati;
• requisiti di interoperabilità a livello di cavo o di protocollo;
• invarianti di sicurezza condivise;
• formati di stato portabili e verificabili;
• visibilità dello stato distribuito o replicato;
• segnalazione dell'estensione e identificazione del set di compatibilità.

Il livello comune NON DOVREBBE contenere:

• regole del modello di business;
• regole sui prezzi;
• preferenze politiche regionali;
• ideologia di ammissibilità estranea agli invarianti tecnici;
• poteri esecutivi discrezionali;
• valutazioni soggettive di merito;
• espansione 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 distribuzione;
• 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;
• tempi di migrazione volontaria;
• profili o estensioni opzionali;
• scelta della controparte.

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. implementazione;
3. vettori di test o metodo di verifica deterministico;
4. dispiegamento 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 che descriva la realtà adottata.

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

9.4. Fork, rifiuto locale e accettazione della controparte

Un progetto conforme DOVREBBE considerare il fork, il rifiuto locale e l'accettazione della controparte 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;
• verificare lo stato senza fare affidamento su un custode del registro in carica;
• accettare volontariamente le controparti;
• rifiutare lo stato non valido o incompatibile a livello locale;
• interagire selettivamente laddove la compatibilità lo consente.

Un sistema che non può essere biforcato, verificato localmente o accettato selettivamente senza distruggere operazioni valide ha probabilmente nascosto il 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 di distribuzione indipendente;
• lo strato di coordinazione è 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;
• lo stato distribuito può ridurre il rischio di cattura istituzionale.

Potrebbe essere meno direttamente applicabile laddove:

• un unico dominio amministrativo è l'architettura prevista;
• 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;
• richiedere qualsiasi implementazione specifica di 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 rivendicando 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 discrezionalità locale e uno stato distribuito possono anche creare atteggiamenti di sicurezza incoerenti, percorsi di downgrade, pressione sulla frammentazione, dichiarazioni di compatibilità ambigue, fork non sicuri, controversie sullo stato del registro e tentativi di prova di contraffazione.

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;
• i meccanismi di prova del controllo DEVONO resistere alla falsificazione, alla riproduzione e al trasferimento non autorizzato;
• la negoziazione della versione e la gestione delle estensioni DEVONO evitare il downgrade silenzioso laddove la sicurezza è compromessa;
• i percorsi di rifiuto, biforcazione e sostituzione DEVONO essere analizzati per 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;
• lo stato distribuito DOVREBBE essere verificabile e sufficientemente riproducibile da rilevare visualizzazioni incoerenti;
• la variazione locale NON DEVE essere autorizzata a 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 quelle Invarianti Globali?
3. Quali regole nelle Specifiche Iniziali sono strettamente necessarie per la prima implementazione?
4. Come viene rappresentato e verificato lo stato valido?
5. Lo stato è distribuito, replicato o altrimenti verificabile in modo indipendente?
6. Quali domande future vengono intenzionalmente lasciate fuori dallo strato comune?
7. Quali scelte future possono essere fatte dai partecipanti senza alterare il set di compatibilità in cui si trovano?
8. Come fa un partecipante ad adottare una modifica successiva?
9. Come fa un partecipante a rifiutare una modifica successiva senza che gli venga assegnato lo stato non valido?
10. Come vengono etichettati o rilevati i set di compatibilità?
11. Come funziona il rifiuto locale quando lo stato non è valido o incompatibile con le regole applicate da un partecipante?
12. Qual è il percorso del bivio?
13. Come fa un detentore a dimostrare il controllo senza un detentore del registro in carica?
14. Come fa una controparte a verificare lo stato senza un registro?
15. I partecipanti possono verificare la validità ordinaria senza affidarsi a un custode in carica?
16. Le registrazioni e gli artefatti di coordinamento descrivono la realtà adottata o tentano di dichiarare esistente la realtà futura non adottata?
17. Il sistema ha ridotto al minimo il numero di decisioni integrate nello strato comune?
18. Il sistema ha evitato qualsiasi autorità continuativa che determini lo status di partecipante ordinario?
19. I partecipanti possono accettare o rifiutare volontariamente le controparti?
20. Il sistema può continuare se tutti i registri esistenti scompaiono?

Indirizzo dell'autore

1. Lu
   [TBD]