Che cos’è il tradimento del codice funzionante nella governance dei RIR?

La critica di Lu Heng parte dal momento in cui una procedura pensata per sostenere reti funzionanti diventa una fonte di potere su di esse.

Immaginiamo una rete che serve normalmente i propri clienti. Gli apparati funzionano, le connessioni funzionano e le altre reti riescono a raggiungerla. Poi l’organizzazione che ne mantiene i registri degli indirizzi cambia le condizioni alle quali riconosce quella rete. I cavi non si sono mossi, ma l’operatore deve ora difendere il fondamento amministrativo su cui altri fanno affidamento.

È questo il conflitto che Lu Heng chiama tradimento del codice funzionante: le istituzioni richiamano una tradizione nata per aiutare le reti a funzionare, poi la usano per giustificare il proprio potere sulle reti stesse. Nella Nota 61, la sua critica va oltre la correttezza di una riunione. Si chiede perché quella riunione debba avere quel potere in primo luogo.

Che cosa significa qui «codice funzionante»?

Per codice funzionante si intendono software e sistemi effettivamente realizzati e utilizzati. Per un servizio Internet, questo comprende il lavoro concreto di collegare le reti e mantenere raggiungibili i clienti. Un progetto proposto va verificato alla luce di questa realtà operativa.

La dichiarazione di missione dell’IETF lega il giudizio ingegneristico all’esperienza di implementazione e messa in esercizio delle specifiche. La sua discussione sul consenso approssimativo spiega perché contare i sostenitori non possa sostituire l’esame delle obiezioni tecniche. Sono metodi per produrre soluzioni ingegneristiche utili, non un mandato generale a governare chiunque sia interessato da Internet.

Lu Heng applica questa distinzione ai registri Internet regionali, o RIR. Un registro aiuta a coordinare le risorse numeriche affinché le reti possano distinguere una risorsa dall’altra. La sua utilità deriva dal sostegno a questa funzione condivisa. La sua tesi è che tale funzione non conferisca all’istituzione un’autorità illimitata su chi la utilizza.

Il rovesciamento: la rete comincia a servire la procedura

Consideriamo una regola concepita per impedire a due reti indipendenti di rivendicare lo stesso numero. Quella regola affronta un problema tecnico comune. Consideriamo ora una regola che decida quali clienti un operatore possa servire, quali accordi commerciali possa adottare o se le sue risorse debbano restare legate a un determinato amministratore.

Queste decisioni hanno una portata ben maggiore. Affermare che i partecipanti le abbiano approvate non dimostra che ogni operatore o cliente interessato li abbia autorizzati a prenderle.

Il rovesciamento avviene quando l’operatore deve riorganizzare un servizio funzionante secondo le preferenze di un’istituzione, mentre quest’ultima considera l’aver completato la propria procedura una risposta sufficiente alle conseguenze. Il processo continua a funzionare. A cambiare è l’interesse che serve.

Perché una decisione sul database può contare anche al di fuori del database

Un registro non trasporta ogni pacchetto. Modificare un dato non equivale a spegnere tutti i router. L’influenza passa attraverso la dipendenza: fornitori, clienti e altri sistemi consultano i registri e le prove correlate quando riconoscono una risorsa e decidono come trattarla.

Si crea così una catena fra una decisione amministrativa e un servizio utilizzato dalle persone. Le conseguenze dipendono dal dato specifico, dai sistemi tecnici coinvolti e dalle decisioni delle organizzazioni che vi fanno affidamento.

Per vedere questa catena, seguiamo un blocco di indirizzi attraverso un’attività d’impresa. Chi ne mantiene i contatti di registrazione? Chi ne pubblica le autorizzazioni di instradamento? Quali reti ne trasportano il traffico? Quali clienti hanno inserito quegli indirizzi nelle proprie configurazioni? Un disaccordo sul piano della tenuta dei registri può richiedere interventi lungo tutte queste relazioni.

Il contributo della discussione su AFRINIC

La Nota 61 usa la controversia AFRINIC per sviluppare una critica precisa: secondo Lu Heng, un ruolo circoscritto di coordinamento è stato ampliato attraverso interpretazioni dell’uso regionale, del riconoscimento istituzionale e delle condizioni di trasferimento. Contesta anche la difesa di quell’ampliamento da parte del più ampio sistema dei registri.

La sua analisi distingue il luogo in cui scorre il traffico dalla possibilità, per un titolare, di trasferire il proprio rapporto amministrativo. Un vincolo all’uscita può creare dipendenza anche mentre l’instradamento ordinario prosegue. Per questo considera la portabilità una questione strutturale, anziché una comodità marginale.

La Nota contiene la sua lettura dettagliata della documentazione sulle policy, delle dichiarazioni istituzionali e del contenzioso. La domanda più ampia di questa introduzione è comprensibile senza accettare ogni affermazione delle istituzioni: quando il coordinatore è contestato o indisponibile, chi gestisce la rete può mantenere il servizio senza dipendere dal suo continuo permesso?

Perché migliorare la partecipazione non basta

Riunioni più accessibili, spiegazioni più chiare e strumenti migliori per sollevare obiezioni possono migliorare un processo. Da soli, però, non dicono che cosa l’istituzione abbia il diritto di decidere.

La critica di Lu Heng non è quindi soltanto che il consenso debba rispecchiare più partecipanti. È che il coordinamento debba restare circoscritto dal lavoro che è chiamato a sostenere. Una procedura non può conferirsi un mandato illimitato dichiarando che i suoi partecipanti sono d’accordo.

È anche per questo che sostituire un comitato con un altro lascerebbe intatto il problema centrale, se il nuovo comitato restasse la fonte indispensabile del riconoscimento.

L’alternativa proposta: rendere la validità verificabile in modo indipendente

La Nota 65 sviluppa la risposta costruttiva: il primato del codice funzionante. Il livello comune proposto contiene le regole minime necessarie per l’unicità, la prova del controllo, la sicurezza e l’interoperabilità. I partecipanti dovrebbero poter verificare localmente queste regole rispetto a uno stato distribuito.

Le modifiche successive diventano operative attraverso l’implementazione e l’adozione volontaria. I partecipanti che mantengono regole precedenti compatibili non devono chiedere a un’istituzione permanente il permesso di continuare. Un partecipante può rifiutare uno stato che non rispetta le regole che esegue; questo rifiuto tecnico è diverso dalla punizione inflitta da un’istituzione a chi non accetta una policy successiva.

Si tratta di un’architettura proposta. Per farla funzionare servono la gestione dei conflitti, prove sicure, compatibilità verificabile e percorsi praticabili di transizione. Pubblicare un documento o copiare un file del registro non basta, da solo, a far accettare un successore alle altre reti.

Perché prepararsi mentre la rete funziona ancora?

La continuità non si improvvisa cambiando un’etichetta durante una crisi. Gli operatori e le loro controparti hanno bisogno di registri utilizzabili, di modi per verificarli e di una comprensione, messa alla prova, di ciò che sopravvive a una transizione.

La verifica per il lettore è semplice: una regola protegge qualcosa di cui le reti hanno davvero bisogno in comune, oppure conserva la capacità dell’amministratore di decidere al loro posto? Poi bisogna chiedersi se il coordinamento utile possa continuare qualora quell’amministratore scompaia.

Leggi la Nota 61 per la critica, la Nota 65 per il progetto proposto e la Nota 72 per la dichiarazione dei diritti. Insieme, passano da ciò che è andato storto a ciò che il livello condiviso dovrebbe effettivamente fare.