> AmministrazioneGerarchia

Il GCN e l'amministrazione della gerarchia it.*

Indice

  1. Introduzione e scopi del presente documento
  2. Il Gruppo Coordinamento Newsgroup (GCN): struttura e funzioni
  3. Usenet, gerarchie e gerarchi
    1. Usenet, ieri e oggi
      1. Accordi comuni
    2. Gerarchie
      1. C'è spazio per tutti
      2. Amministrazione automatica
    3. Gerarchi
  4. Il Name Space
    1. Il Routing
    2. Il DNS
  5. Il GCN e le politiche di gestione
  6. Ringraziamenti
  7. Bibliografia
  8. Legalese
  9. Storia delle revisioni


1. Introduzione e scopi del presente documento

Accade alle volte che il ruolo e la funzione del GCN non vengano adeguatamente compresi, e questo finisce per generare una serie di equivoci e lunghe discussioni che periodicamente sorgono nei newsgroup della gerarchia. La ragione di tutto ciò è probabilmente legata al fatto che, senza conoscere i rudimenti del funzionamento di Usenet, è facile equivocare certe situazioni; inoltre, per capire davvero la cultura che si è sviluppata attorno a questo media, è necessario conoscere almeno in parte sia le radici storiche del fenomeno sia la tecnologia alla base della Usenet di oggi. Ora, data la proverbiale complessità dell'intera baracca, non è banale afferrarne i meccanismi di base senza conoscere almeno alcuni dei dettagli tecnici. Fornire tutte queste informazioni senza dare nulla per scontato richiederebbe lo spazio di un libro alquanto voluminoso.

Malgrado questo voglio provare a chiarire che cos'è il GCN, quali sono le sue funzioni e qual è il suo reale potere, fornendo nei limiti del possibile le informazioni storiche e tecniche di contorno necessarie per la comprensione. Il filo conduttore del testo parte dall'introduzione, prosegue per le parti che vengono ben evidenziate con un titolo alla fine dei vari paragrafi e infine termina con il paragrafo "Il GCN e le politiche di gestione". Tutto quello che si trova in mezzo assieme alle note serve solo a dare le informazioni tecniche e i cenni storici di cui parlavo prima.

Una nota stilistica: i termini tecnici quali server, client, newsgroup ecc... non sono stati tradotti negli equivalenti termini italiani, ma piuttosto usati come delle estensioni gergali del dizionario utilizzato in questo documento.

2. Il Gruppo Coordinamento Newsgroup (GCN): struttura e funzioni

Il Gruppo Coordinamento Newsgroup si occupa di amministrare la gerarchia it.* ed è attualmente costituito da sei membri permanenti e un forum via email, aperto al contributo dei volontari.

Il manifesto (reperibile presso il [WWW]sito web del GCN) spiega dettagliatamente la nostra filosofia, che in ultima analisi si riassume nella missione di diffondere la cultura Usenet in Italia. Ci occupiamo quindi di gestire it.*, il che vuol dire essenzialmente controllare lo sviluppo dell'albero dei newsgroup che costituisce la gerarchia: in pratica creiamo e cancelliamo i gruppi di discussione. Inoltre, come attività correlate, ci occupiamo di fornire assistenza agli utenti finali e ai provider, gestiamo le strutture che permettono l'esistenza dei gruppi moderati 1, e cerchiamo di mantenere un rapporto segnale/rumore ottimale 2, combattendo attivamente il fenomeno dello spam e cercando in questo di stimolare la collaborazione di utenti e provider; infine, occasionalmente e solo su esplicita richiesta, interveniamo per mediare situazioni di conflitto nei gruppi moderati.

Svolgiamo tutte queste attività cercando di interferire nella vita dei newsgroup il meno possibile, lasciando cioè gli utenti liberi di comunicare a loro piacimento. Inoltre il nostro interesse si concentra piuttosto sulla gerarchia che sui singoli gruppi, al contrario degli utenti finali dove questi valori sono ribaltati. Abbiamo quindi preparato il seguente documento nella speranza di fornire ai curiosi tutti gli elementi informativi necessari a capire il nostro punto di vista.

Nei paragrafi successivi si intende quindi chiarire i punti più oscuri e sfuggenti del lavoro di amministrazione di una gerarchia. Per prima cosa ci occuperemo di spiegare alcuni particolari legati al funzionamento della rete Usenet, quindi della struttura e funzione delle gerarchie, inquadrando il tutto in una prospettiva storica che aiuterà poi a capire meglio perché e di cosa ci definiamo dittatori. In seguito spiegheremo che cosa c'entra il GCN in tutto questo, e verranno così trattati e chiariti alcuni argomenti di discussione, a volte polemica, che ricorrono periodicamente nei newsgroup (come l'idea che it.* occupi uno spazio pubblico, limitando di fatto l'esistenza di gerarchie alternative, e che per questo debba aver degli obblighi di "democraticità").

3. Usenet, gerarchie e gerarchi

In passato abbiamo ripetuto molte volte un importante concetto:

Che vuol dire esattamente siamo dittatori? Facciamo prima un passo indietro e vediamo rapidamente cos'è Usenet e come funziona.

3.1. Usenet, ieri e oggi

Usenet è fondamentalmente un immenso spazio virtuale di comunicazione, costituito da un numero molto grande di aeree di discussione, che al giorno d'oggi esiste prevalentemente, ma non esclusivamente, su Internet. Assodato ciò, bisogna però ricordarsi che Usenet e Internet sono due realtà distinte. Su Internet esistono infatti sin dagli albori dei tempi le liste di discussione via email 3, che in maniera diversa servivano (e tuttora servono) allo stesso scopo di Usenet, e questo tende a confondere il ruolo delle NetNews 4con le mailing list, cioè le liste di discussione che viaggiano in Internet mediante la posta elettronica.

Usenet e la posta elettronica con le sue mailing list sono dunque due realtà diverse. Entrambe sono esempi di messaggistica telematica organizzate per aree di discussione e basate su un formato comune e coerente, ma mentre la posta elettronica serve a trasmettere dei messaggi da un utente ad un altro utente, o a un loro limitato gruppo, Usenet è stata concepita per permettere lo scambio di articoli 5 tra un numero decisamente molto più grande di persone. Per raggiungere questo scopo venne utilizzato un algoritmo di distribuzione, denominato "flooding algorithm" (cioè algoritmo a cascata), particolarmente efficiente nel propagare con rapidità un articolo nell'intera Usenet una volta che questo venga immesso in circolo tramite uno dei server partecipanti alla Rete. In tempi più recenti tale argoritmo è stato perfezionato e adattato ad un uso esclusivo su Internet mediante la definizione del protocollo denominato NNTP (Network News Transfer Protocol) 6 che ha stabilito le linee guida e il modo di funzionare di Usenet su Internet nei tempi più recenti.

Una piccola digressione nel discorso: occorre distinguere Usenet da Internet per ragioni storiche oltre che tecniche. ARPANET, figlia dell'organizzazione governativa americana di ricerca e sviluppo DARPA7 era l'embrione dell'Internet a venire ed era riservata ai pochi eletti che potevano accedere ai finanziamenti necessari per pagarsi la costosa connessione alla rete che avveniva per lo più su linee dedicate. Usenet invece si è sviluppata su una struttura parallela, basata sul protocollo UUCP8 e le preesistenti linee telefoniche, per scambiare messaggi in maniera simile alle mailing list di ARPANET, ma con spese molto più limitate. Proprio per questo Usenet venne chiamata l'ARPANET dei poveri e fu un fattore determinante nella diffusione di massa di un sistema di rete omogeneo. Infatti poco tempo dopo la nascita di Usenet i due sistemi vennero messi in collegamento da dei gateway e nel tempo si fusero assieme.

Usenet dagli inizi degli anni '90 è andata raddoppiando ogni 18 mesi circa, ma negli ultimi anni questo profilo di crescita è aumentato sino a raggiungere l' attuale valore di un raddoppiamento all' anno. Le sue dimensioni 9 sono tali che, malgrado la disponibilità di hardware molto potente, amministrare un server news con un feed completo 10 è uno dei compiti più complessi che un amministratore di rete può trovarsi ad affrontare.

Torniamo a noi. Vediamo nelle successive figure 1 e 2 come è fatta una mailing list e come invece è strutturata Usenet.

Una lista email è costituita da un unico server, rappresentato al centro della struttura raggiata in figura 1 il quale gestisce la lista e che ridistribuirà degli iscritti (le estremità dei raggi). Il server quindi spinge (push) le email alle caselle degli utenti, dalle quali vengono poi prelevate (pull) per essere lette.

Una variazione sul tema, simile nella struttura, anche se con protocollo di tipo pull per tutto il percorso, è quello dei forum su web. C'è infatti, come nel caso precedente, un unico server web su cui risiede l'intera messaggistica, al quale gli utenti si collegano e prelevano o inviano i messaggi.

    \     |      /
      \   |    /    (1)
      /---+---\
   --- server  ---
      \---+---/
     /    |   \
   /      |     \

(1) Nei raggi sono rappresentati i server di posta dove risiedono le caselle 
    elettroniche degli utenti, a cui il server (al centro della figura) invia 
    le email della lista. Il protocollo di trasmissione è l'SMTP ed è di tipo push.
  
Figura 1

Usenet invece funziona diversamente dalle mailing list. La necessità di distribuire una massa enorme di messaggistica crea la necessità di avere una rete di server, piuttosto che uno singolo, ciascuno con la sua aliquota di client a cui distribuire a richiesta (pull) parte del feed. In pratica ciascuno degli esagoni della figura 2 potrebbe essere paragonato al singolo esagono della figura 1, qui rappresentato senza la struttura radiale che indica i client, omessa per semplicità. Il protocollo di comunicazione tra server è di tipo push, cioè ogni server è collegato ad un certo numero di altri server, i peer, ai quali reindirizza gli articoli via via che questi arrivano, dopo averne fatta una copia per esaudire le eventuali richieste dai client con i quali quindi comunica con un altro protocollo di tipo pull, precisamente l'NNRP, Network News Reading Protocol). L'NNTP è quindi usato per lo scambio di articoli tra i server, mentre invece l'NNRP tra client e server.

                *         *                  *          ---+
                |         |                  |             |
                |         |                  |             |
              /-+-\     /-+-\        /---\   |             |
       *------  6  -----  7  --------  4     |             |
              \---/     \-+-/        \-+-/   |             |
                 \        |            |     |             |
                  \       |            |     |             |
                   \      +------------|-----|-------+     |
                    \                  |     |       |     | (1)
        /---\      /---\     /---\     |   /-+-\     |     |
   *----  8  ------  1         5   ----+---  2  -----+     |
        \-+-/      \---/     \-+-/     |   \---/           |
          |           \        |       |                   |
          |            \       |       |                   |
          |             +------|-+     |                   |
          |    +---------------+  \    |                   |
        /-+-\ /                    \ /-+-\                 |
   *----  9  +                      +  3  --------*        |
        \---/                        \-+-/              ---+

(1) Spaccato di Usenet; ogni esagono è un server che scambia il proprio feed 
    con i peer (gli altri esagoni) a cui è collegato. Sebbene ogni server abbia 
    come peer un numero limitato di altri server, l'intreccio di collegamenti 
    fa sì che un articolo uscito da uno specifico punto di iniezione si propaghi 
    rapidamente, mediante l'algoritmo a cascata, al resto della rete.

Figura 2

Le differenze tecniche tra mailing list e Usenet che abbiamo appena visto si riflettono in una maggiore complessità di gestione di quest'ultima e nella sua intrinseca necessità di avere definiti degli accordi molto precisi tra gli amministratori per far funzionare l'intera baracca. Questo concetto è molto importante e verrà ampliato alla fine del capitolo, ma lasciate che adesso mi soffermi su un paio di conseguenze che da qui scaturiscono:

3.1.1. Accordi comuni

Usenet è una entità virtuale creata dalla connessione di N reti, ciascuna con il suo proprietario, il quale può legittimamente rivendicare il possesso solo del suo piccolo orticello in seno alla totalità della rete, e che però è al tempo stesso anche responsabile, nei confronti dei suoi peer, di tutto il flusso di informazioni uscente dalla sua proprietà e indirizzato verso quella degli altri.

3.2. Gerarchie

Un sistema di messaggistica così grande introduce un altro problema: l'organizzazione razionale degli articoli. Usenet venne creata nel 1979 da Tom Truscott e Jim Ellis; a quell'epoca, i due studenti decisero di organizzare gli articoli 11secondo uno schema gerarchico, nel quale essi venissero accorpati logicamente per argomento in gruppi specifici i quali, a loro volta, potessero essere inseriti in insiemi di complessità superiore; il tutto ripetuto per un certo numero di livelli 12. Questo approccio si rivelò vincente anche per un altro motivo: la strutturazione tassonomica risultava immediata e autoesplicativa.

Ogni articolo quindi, a seconda dell'argomento, doveva essere inviato nel newsgroup appropriato, il cui nome mostrava tutti i livelli gerarchici della sua struttura, elencati da sinistra a destra secondo un criterio di maggiore specificità e separati ognuno da un punto. Il contenitore più a sinistra indicava il nome generico della gerarchia, quello più a destra la parte più specifica del nome del gruppo, 13 di conseguenza la notazione "nome.*" indicava l'insieme di tutti i gruppi, cioè l'intera gerarchia.

Questo tipo di organizzazione tassonomica è tuttora in uso, e nella figura 3 possiamo vedere un esempio reale tratto dalla gerarchia it.*.

                   it.comp.aiuto  (1)
                    |   |    |
                   it.news.aiuto  (2)
                    |   |    |
                    |   |    |
                    |   |    |
    I livello ------+   |    |
  (nome della gerarchia)|    |
                        |    |
   II Livello ----------+    |
                             |
                             |
  III Livello ---------------+


(1) it.comp è un newsgroup, nel senso che è da solo un argomento di 
    discussione, ma contiene anche altri newsgroup più specifici, come 
    appunto it.comp.aiuto. Da notare che non necessariamente ogni livello 
    deve corrispondere ad un newsgroup, infatti potrebbe benissimo esistere 
    it.comp.aiuto senza it.comp. In quel caso nel gergo in uso si dice che 
    manca il "gruppo padre". I gruppi di uno stesso sottolivello (per esempio 
    i gruppi di it.comp.*) sono definiti "gruppi fratelli".

(2) it.news.aiuto rivela l'argomento di discussione col suo nome di gerarchia, e 
    renderà evidente così che lì ci si occuperà delle richieste di aiuto sulle 
    News e non sui computer (che è argomento dell'altro gruppo).

Figura 3

Con la crescita mozzafiato di Usenet, alle big8 14 si sono affiancate nel tempo moltissime altre gerarchie, per un numero totale di svariate decine di migliaia di newsgroup. Tutto questo ha due importanti conseguenze:

3.2.1. C'è spazio per tutti

Può esistere su Usenet un numero contemporaneo di gerarchie teoricamente illimitato, cioè l'esistenza di una gerarchia non pregiudica quella di un'altra.

3.2.2. Amministrazione automatica

È praticamente impossibile per un amministratore seguire, tutte o anche solo in parte, le gerarchie; altresì sarebbe impossibile amministrarle in maniera centralizzata, quindi è necessario un sistema di amministrazione automatizzato e decentrato.

3.3. Gerarchi

Finalmente arriviamo al dunque: chi comanda su Usenet? E che c'entra il GCN in tutto ciò? Ancora una volta seguiamo la storia.

Nel 1991 venne creato soc.culture.italian nella gerarchia che in seno alle big8 si occupa delle problematiche sociali. Praticamente questo divenne l'unico angolo di Usenet nel quale fosse possibile discutere in italiano.

Questa situazione nel corso degli anni divenne piuttosto limitativa e un gruppo di amministratori di news server, nel 1994 costituì il GCN e creò it.* 15.

L'intera storia è raccontata altrove da alcuni dei protagonisti di allora, ma adesso a noi interessa vedere esattamente in cosa consiste la creazione di una gerarchia per poi tornare al GCN.

Nella cultura Usenet c'è un detto che spiega molto bene un concetto chiave:

Infatti, sin dalla sua creazione chi gestiva i vari nodi della rete (e quindi pagava la costosa bolletta per il trasporto delle news) aveva poi una voce importante nelle decisioni che riguardavano la gestione dei newsgroup. Inizialmente, almeno fino al Great Renaming, il gruppo degli amministratori dei principali server news si riunì in una mailing list e costitui la "Backbone Cabal", che sotto la guida del carismatico Gene Spafford ebbe uno strettissimo controllo sullo sviluppo di Usenet.

Nel corso degli anni, con il continuo potenziamento della tecnologia e la diffusione sempre più estesa di Internet, certe ristrettezze tecniche sono venute a mancare e quando il protocollo NNTP (che si basa sulla tecnologia TCP-IP e regola la diffusione delle News attraverso Internet) iniziò a giocare un ruolo di primo piano nella diffusione di Usenet, l'importanza della Cabal che controllava la rete UUCP venne grandemente ridotta, fino a sparire del tutto.

Quello che accadde poi fu la messa a punto di un sistema per la creazione dei newsgroup16 decentralizzato ma la cui supervisione veniva comunque effettuata da individui, come Gene Spafford, che riscuotevano la fiducia della gran parte degli utenti e, soprattutto, degli amministratori di news.

Le cose sotto questo aspetto non sono cambiate. Usenet è cresciuta, sono nate altre gerarchie, molte di queste di interesse nazionale a causa di una precisa scelta linguistica e culturale, e il numero di server news è aumentato a dismisura. Questo fatto ha comportato la conseguenza che i news administrator non sono più in grado di controllare quello che accade su tutto lo spazio di Usenet. Si è quindi spontaneamente evoluta la necessità di creare un "web of trust", cioè una rete di fiducia dove i gestori dei server news delegano il coordinamento delle varie gerarchie che costituiscono Usenet a dei gruppi di volontari che generalmente si occupano esclusivamente di un certo spazio gerarchico.

Questa è la realtà odierna di come viene amministrata la struttura tassonomica di Usenet. La USEFOR (ovvero il gruppo di lavoro che si occupa di Usenet in seno alla IETF) sta cercando a fatica di formalizzare nei documenti della IETF che sostituiranno la RFC 1036 le pratiche amministrative correnti di Usenet e uno dei documenti in corso d'opera recita a proposito dell'amministrazione delle gerarchie:

Quindi quello che dice il "draft" è che Usenet appartiene a chi amministra i server che la compongono, e che non esiste una autorità centrale, ma esiste piuttosto un'amministrazione delegata a gruppi di volontari che stabiliscono le loro regole di gestione per coloro che tra i news administrator sceglieranno di riconoscere tale autorità, accettandone gli articoli di controllo firmati elettronicamente. I server news ovviamente possono essere configurati in modo da declinare lo scambio di articoli con chi non accetta questo tipo di policy.

Il GCN è una di queste "agency" e si occupa di amministrare la struttura gerarchica di it.*.

Dopo aver fatto quindi un po' di luce su qual è il ruolo del GCN, nel prossimo paragrafo passeremo a chiarire un equivoco in cui spesso si cade quando si osserva la nomenclatura della gerarchia it.*, cioè confondere il DNS con Usenet e attribuire alla Usenet sfera 17 delle gerarchie un'importanza ed un ruolo che esse di fatto non hanno.

4. Il Name Space

Internet oggi funziona mediante due meccanismi strettamente legati tra loro: il routing e la risoluzione dei nomi a dominio. Vediamo che cosa sono.

4.1. Il Routing

Ogni computer su Internet ha un indirizzo IP, cioè un numero univoco formato da 32 bit, solitamente rappresentato in forma decimale da quattro numeri compresi tra 0 a 255 e separati da punti (ad esempio 192.186.20.10). L'IP serve ad identificare univocamente ogni singola macchina all'interno dello spazio virtuale che costituisce la totalità di Internet. Ogni computer deve poter essere in grado di raggiungere un qualsiasi altro elaboratore elettronico in quel momento collegato al sistema; la tecnologia che consente ciò viene chiamata "routing".

La registrazione dello spazio IP è stata curata da una organizzazione di esperti del settore, la IANA (Internet Assigned Number Authority) che, sotto contratto dal governo degli Stati Uniti, in passato ha letteralmente organizzato la topologia di tutto Internet. Oggi un'altra organizzazione, l'ICANN, si occupa dell'assegnazione degli indirizzi IP, nonché del controllo dei Root Server del sistema DNS. Vediamo che cosa sono esattamente questi ultimi e cosa c'entrano col GCN.

4.2. Il DNS

Gli indirizzi IP, in quanto numeri, sono per l'essere umano di difficile memorizzazione. Per ovviare a questo inconveniente Internet è stata "mappata" con un sistema complementare all'IP, ovvero mediante il DNS (Domain Name System), che di fatto è un archivio nel quale agli indirizzi IP viene associato un "nome" corrispettivo. Esso viene formato secondo un'organizzazione gerarchica simile a quella di Usenet, cioè da stringhe di caratteri (delle "parole", se vogliamo) ognuna divisa da un punto, proprio come avviene per i nomi dei newsgroup. Per facilitare l'organizzazione logica di questo modo "alternativo" di rappresentare la topografia di Internet, tale spazio nominale è stato organizzato in strutture gerarchiche. La parte più a destra del nome definisce la categoria gerarchica più generale e per questo viene chiamato il Top Level Domain o TLD. Per esempio www.example.com, appartiene al "name space" definito dal TLD '.com', che raggruppa tutte le macchine che sul web sono state registrate sotto il TLD ".com", originariamente destinato per le attività tipicamente commerciali.

Ora accade che tale archivio non solo sia immenso, ma venga anche ad essere anche interrogato quasi ogni volta che ci sia uno scambio di informazioni su Internet. Questo perché la tecnologia del Routing capisce solo i numeri IP. Tra la macchina di un utente e il resto di Internet occorre quindi uno strato software, che da un lato comunichi con l'essere umano mediante il sistema di coordinate "nominali", e dall'altro col Routing mediante le coordinate numeriche. Tale strato software quindi fa da traduttore tra l'essere umano e la Tecnologia di "routing" alla base di Internet e per fare ciò questo consulta il DNS ogni volta che risulti necessario.

Considerando la dimensione e il traffico di Internet è facile capire che con queste premesse un sistema centralizzato collasserebbe all'istante. Si è escogitata quindi una diversa soluzione al problema: il database è stato spezzettato in maniera logica e distribuito tra un numero adeguato di macchine.

Vediamo come.

L'organizzazione gerarchia del DNS (Figura 4) prevede che ci siano un certo numero di ROOT server (attualmente 13) controllati direttamente dall'ICANN, che in base al TLD, cioè la stringa che segue l'ultimo punto nel nome associato all'IP (nel nostro esempio '.com'), sappiano localizzare un altro DNS, il MASTER DNS, specifico per quel particolare TLD.

In altre parole ci sarà un Master DNS per il TLD .com, .net, .org, ecc... e uno specifico per ogni paese come '.it' per l'Italia, '.fr' per la Francia ecc... Il master DNS a sua volta conosce i DNS di chi controlla i nomi che precedono il TLD, per es. "example" in 'example.com'. Sono questi infine ad avere l'informazione finale, cioè l'assegnazione tra i computer che condividono il nome 'example.com' (es. 'ftp.example.com'e 'www.example.com') e il loro corrispettivo indirizzo IP. Essi quindi costituiscono l'ultimo livello di questo sistema gerarchico.

Quando un utente di Internet cerca di contattare un qualsiasi nodo della Rete fornendo il suo nome (per esempio cerca una pagina web su www.example.com), attiva automaticamente e in modo trasparente una ricerca che parte dal suo computer, passa per il DNS locale e, se l'informazione non è gia presente come "memoria cache" di una passata ricerca, da qui si instrada per il Root server, poi prosegue per il MASTER name server di quel TLD e infine giungere al DNS server che ha autorità per quel particolare dominio (chiaramente tale zona di autorità deve essere stata preventivamente registrata presso l'autority che gestisce il MASTER name server) e da qui finalmente, dopo aver fatto fare all'informazione lo stesso percorso nell'altra direzione, arriva l'indirizzo IP cercato. Ottenuto il dato, il computer dell'utente può finalmente instradare le informazioni verso il suo destinatario.

In realtà il sistema è molto più complesso di così: esistono per esempio delle ottimizzazioni come il "caching" del database in locale, che non sono state rappresentate in Figura 4, ma lo scopo di questo paragrafo era solo quello di dare un'idea approssimativa di cosa sia il DNS, e non ha certo la pretesa di trattare un argomento sul quale sono stati scritti svariati libri, peraltro molto voluminosi. Adesso quindi vediamo che c'entra tutto questo con Usenet e in particolare con il GCN.

  1  Livello             [ROOT server]                          --+
                      /   |       |   \                           |
                    /     |       |     \                         |
                  /       |       |       \                       |
  2  Livello   [.com]   [.net]   [.org]   [.it]    [...]          | (1)
      (TLD)      |                                                |
                 |                                                |
                 |                                                |
  3 Livello  [ Name Server per]                                   |
             [ "example.com"  ]                                 --+

(1) Struttura gerarchia del DNS: al primo livello abbiamo i ROOT Server, 
    ridondanti per dare robustezza al sistema. A seguire troviamo i server 
    dei vari TLD, ognuno gestito da una diversa autority, i quali organizzano 
    il loro spicchio di Internet, cioè indirizzano le richieste ai server dei 
    singoli provider, o comunque di chi abbia registrato un dominio sotto il 
    loro controllo.

Figura 4

Come ho già ricordato, nell'organizzare il DNS vennero creati non solo dei TLD generici (com, net, org, edu, mil, ecc.), ma anche dei TLD specifici per nazioni geografiche, cioè i ccTLD o country code TLD. Per assegnare coerentemente dei nomi a questi ultimi si decise di utilizzare il database ISO 3166-1 creato da una organizzazione indipendente, la ISO3166MA. Questo è uno dei tre database da lei gestiti, infatti basandosi sulle indicazioni delle Nazioni Unite viene mantenuto un database consistente di codici a 2 cifre (ALPHA-2) e a 3 cifre (ALPHA-3), nonché uno numerico per ogni nazione riconosciuta dalla UN. Tale database è lì presente ad uso e consumo di chiunque voglia utilizzarlo, e infatti così fece la IANA che definì i ccTLD in base al codice ALPHA-2.

Alcuni gestori di gerarchia tra cui anche il GCN, hanno incidentalmente fatto la stessa scelta di usare il codice ISO 3166-1 ALPHA-2, generando così una gerarchia il cui spazio nominale somiglia a quello del DNS per il corrispondente ccTLD. Quello che però spesso sfugge è che tale somiglianza finisce esattamente là dove comincia: col nome.

A parte il fatto che la struttura gerarchica è rigirata (nell'uno va dal più generico al più specifico e nell'altro fa esattamente l'opposto; cioè it.* è diverso da *.it), l'intera struttura e lo scopo dei due spazi nominali sono completamente diversi. Usenet infatti usa quei nomi per organizzare gli articoli in modo coerente, informativo e consistente tra i vari server news, mentre il DNS li utilizza come database mnemonico per gli indirizzi IP.

Questo ha una serie di importanti conseguenze. La prima è che non esiste NESSUNO standard, regola, rfc, draft di rfc, nessun tipo di documento, che stabilisce o persino suggerisce come convenzione generale quella di usare il codice ALPHA-2 nella definizione del namespace di Usenet, tanto che molti hanno scelto sistemi diversi (esiste uk.* ed esiste england.*, esiste malta.* ed è esistita ita.*, tanto per fare solo alcuni esempi). La seconda è che le agenzie che amministrano lo spazio nominale del DNS sono di fatto monopolistiche. Essendo infatti il processo di risoluzione dei nomi legato al contenuto dei root DNS, chi amministra questi ha il potere assoluto su tutto il resto. Esistono dei tentativi di creare delle alternative ma, a parte l'enorme costo che richiede una cosa del genere, ci sono delle problematiche tecniche che limitano pesantemente il successo di queste iniziative.

Su Usenet invece una gerarchia non influenza in alcun modo la diffusione di una qualsiasi altra gerarchia. L'amministrazione dello spazio nominale di Usenet è infatti decentrata, e questo implica che chiunque può creare e far diffondere una gerarchia; tutto quello che deve fare infatti è investire il suo tempo nel progetto. Per quanto riguarda i costi, l'unica cosa veramente necessaria è una normale connessione a Internet, anche un modem a 56 K è adeguato.

Data la sua natura distribuita e paritetica, su Usenet non esiste tecnicamente il modo di imporre un monopolio.

5. Il GCN e le politiche di gestione

Alla fine di tutta questa lettura abbiamo scoperto che it.* è una gerarchia gestita in maniera dittatoriale dal GCN, e che la sua gestione avviene tramite dei normali articoli, i "control message" (newgroup che serve a creare un nuovo gruppo, rmgroup che invece cancella i gruppi e i checkgroup che contengono la lista completa dei nomi dei newsgroup e il loro corrispondente titolo). Tutto il potere di questa "agency" risiede solo nel fatto che c'è un numero rilevante di amministratori di server news che ha deciso di affidare al GCN il controllo sul proprio server dello spazio nominale dei gruppi che iniziano per "it.".

Emerge quindi finalmente la verità, cioè che il GCN è solo il dittatore delle proprie opinioni, e le esprime tramite dei semplici articoli firmati; cosa che chiunque può fare con la spesa di una semplice connessione dial-up (cioè via modem).

Per essere più precisi su questo ultimo punto esistono tre servizi supplementari, ma non indispensabili, che il GCN utilizza per migliorare it.*:

È quindi possibile per chiunque creare una nuova gerarchia in lingua italiana, come è infatti già avvenuto in passato, o addirittura sarebbe anche possibile convincere gli amministratori news ad accettare i control message per uno spazio nominale che inizi per 'it.', purché non ci sia uno scambio diretto di articoli tra i siti che accettano le due diverse policy. In entrambi i casi infatti il GCN non possiede alcun mezzo per impedire o reprimere delle simili iniziative. Tra l'altro questo conflitto si è già verificato e per puro caso due gerarchie diverse, la Slovacchia e quella di uno stato canadese si sono fuse nello stesso albero, sk.*.

6. Ringraziamenti

Questo documento nasce come risposta alle ricorrenti polemiche che vorrebbero una gestione diversa o più "democratica" di it.*, tutte accomunate dalla richiesta che il GCN faccia le cose diversamente da come avviene adesso, e dalla assoluta indisponibilità ad impegnarsi in prima persona per realizzare una gerarchia distinta da it.* e pensata con regole alternative. A costoro vanno certamente attribuite le motivazioni che mi hanno spinto alla stesura del presente testo.

Un sentito ringraziamento ai colleghi del GCN, e in particolare Alessio "Sleepers" Bellazzi, Marco d'Itri e Mamo, che con la loro competenza e disponibilità mi hanno permesso di eliminare una lunga lista di imprecisioni ed errori.

Voglio ricordare inoltre i preziosi contributi critici di Mario Benvenuti, sempre disponibile a dare un aiuto quando si tratta di Usenet, di Roberto Corda, Seastorm e tutti gli amici di it.cultura.cybersocieta che hanno svolto la preziosa funzione di "beta tester". Infine vorrei dedicare tutto questo sproloquio (non è molto lo so, ma a me è costata parecchia fatica) a tre persone che non ho mai incontrato in vita mia, ma verso le quali ho un grosso debito di gratitudine per avermi introdotto allo strano e straordinario mondo delle NetNews. Parlo dei tre ex-membri del GCN che dopo anni di dedizione alla crescita di it.* ne hanno avuto infine abbastanza e che hanno deciso di dedicarsi ad altre imprese: MaurizioCodogno, la cui presenza ancora aleggia nel sito web del GCN tramite i numerosissimi documenti da lui prodotti, Marco "Gattestro" Scozzafava e infine StefanoSuin, che per lungo tempo è stato il manutentore ufficiale della gerarchia.

7. Bibliografia

Netizens: On the History and Impact of Usenet and the Internet. Quasi tutte le informazioni riguardanti la storia di Usenet riportate nell'articolo sono state ricavate da questo libro disponibile on line. http://www.columbia.edu/~hauben/netbook/

Usenet Software: History and Sources. Questa è una FAQ molto famosa, scritta da uno dei padri fondatori di Usenet, Gene Spafford, che delinea la storia di Usenet attraverso il software utilizzato per crearla. http://www.faqs.org/faqs/usenet/software/part1/

The Network Administrators' Guide: Usenet History. Capitolo dedicato a Usenet che descrive brevemente la sua storia, un'ottima introduzione ma alquanto sintetica. http://en.tldp.org/LDP/nag/node256.html

The Living Internet: How The Usenet Was Invented. Sito web interamente dedicato alla storia di Internet, con foto, aneddoti, citazioni, note tecniche, trucchi e informazioni di tutti i tipi. In particolare questo è il capitolo dedicato alla storia Usenet. Non è centrato intorno alla storia del software ma affronta l'argomento con un più ampio respiro, sebbene alquanto sinteticamente. I link forniti sono la parte migliore del sito. http://www.livinginternet.com/u/ui.htm

The Great Renaming FAQ. La storia di come vennero rinominate le prime tre gerarchie nelle big7 (oggi big8) della Usenet moderna. http://www.vrx.net/usenet/history/rename.html

Le RFC rilevanti per Usenet. Una raccolta di tutte le RFC che in qualche modo sono collegate ad Usenet. Le più importanti storicamente sono la RFC 850, la RFC 1036, e la son-of-1036. Quella attualmente in fase di completamento è il draft derivato da son-of-1036 che verrà diviso in cinque documenti indipendenti. Inoltre sono rilevanti per la definizione del protocollo NNTP la RFC 997, il draft che la sostituirà e la RFC 2980 che, in attesa del nuovo standard, elenca le ultime estensioni al protocollo. http://www.tin.org/docs.html

Linux Network Administrators Guide: Chapter 20. Netnews. Una breve introduzione tecnica a Usenet in questo libro online, che è già stato citato a proposito della storia di Usenet. http://www.linuxdoc.org/LDP/nag2/x-087-2-news.html

Internet Software Consortium. Il sito web dell'Internet Software Consortium, un'organizzazione preposta allo sviluppo di tecnologie chiave per Internet dove viene attivamente sviluppato INN. Ha tra i fondatori Paul Vixie e vi lavora David C. Lawrence, che assieme a Russ Allbery (il coordinatore del gruppo di volontari che sviluppa INN), ha una grossa influenza su come vengono configurati i server news (e quindi sulla propagazione delle gerarchie). Qui viene mantenuto il database centralizzato dei gruppi moderati. http://www.isc.org

Il sito della IANA. http://www.iana.org

8. Legalese

Copyright © 2002-2003 Gruppo Coordinamento Newsgroup (GCN)

Questo documento viene rilasciato secondo la licenza GNU GPL versione 2 e successive, considerando come forma modificabile preferita il sorgente in formato wiki ed è proprietà del Gruppo Coordinamento Newsgroup (GCN) che ne mantiene il copyright. Si concede l'autorizzazione a copiare, distribuire e modificare i presente documento esattamente entro i termini stabiliti dalla licenza entro il quale esso viene rilasciato. Si declina ogni responsabilità derivante dal contenuto del presente documento. L'uso delle informazioni qui reperibili è ad esclusivo rischio del lettore.

9. Storia delle revisioni

Versione e data Commento
V 0.1 05/02 Prima stesura di Carlo Fusco
V 0.2 05/02 Corrette varie imprecisioni soprattutto riguardo il DNS, utilizzo dei segnaccenti
V 0.3 10/02 Aggiunto un paragrafo introduttivo, i ringraziamenti e revisionate alcune parti minori
V 0.4 11/02 Correzione generale del testo (punteggiatura, accenti, refusi...) di Sleepers
V 0.5 06/03 Portato il documento nel GCN Wiki, alcune modifiche minori sul testo