La prima domanda per divulgare con chiarezza "che cos'e' un RFC" e', probabilmente, "che cosa e' la Internet Engineering Task Force -IETF, quando e' nata, come e' organizzata, da chi e' composta" ...

• La miglior definizione della Internet Engineering Task Force (IETF) e' probabilmente "gruppo informale di esperti tecnici di reti che utilizzano il protocollo TCP/IP" - quello usato da Internet.
• Non esiste il concetto di "membro" o "socio" di IETF: chiunque partecipi alle attivita' dell'IETF e' un membro di IETF.
• IETF e' nata nel lontano (preistorico) Gennaio 1986, riunendo 21 persone, che avevano come scopo la standardizzazione del protocollo TCP/IP, nonche' dei servizi di rete e di alcune applicazioni di base.
• Da allora si riunisce fisicamente mediamente 3 volte all'anno, ma e' una organizzazione "sempre attiva" perche' buona parte del lavoro viene fatto via posta elettronica, sulle mailing list dei gruppi di lavoro.
• Da allora la cosa si e' evoluta moltissimo in termini di partecipazione: mentre sino al 1992 il numero di partecipanti al lavoro ed alle riunioni era limitato quasi solo a "univeristari/ ricercatori/ accademici" (mai piu' di 350 persone), con la nascita dell'Internet commerciale la composizione si e' molto evoluta, e sono comparsi gli esperti tecnici delle varie ditte che producono h/w e s/w (all'inizio quasi tutti ex ricercatori passati a fondare queste ditte stesse!), ed anche il numero di partecipanti ha seguito l'evoluzione dell'internet commerciale stessa.
• A mio modesto parere gli anni "bui" sono stati tra il 1988 ed il 2001, quando la ".com bubble" portava quasi 2500 persone ai meeting, buona parte delle quali non aveva le caratteristiche "tecniche" per apportare contributi validi al lavoro di IETF, ma solo la necessita' commerciale di dichiarare che il proprio "prodotto" - spesso nulla piu' che una applicazione scritta per il WEB - era stato sviluppato in base ad un RFC.
• Oggi siamo ritornati all'IETF tecnica originale, anche se il numero di partecipanti e' ovviamente superiore (circa un migliaio).
• Lo scopo di IETF e' sempre rimasto lo stesso: produrre gli standard di comunicazione che permetto ad Internet ed a tutte le sue innumerevoli applicazioni di funzionare.
• Il lavoro di IETF e' organizzato in grandi "aree", che vanno dai protocolli di base per il trasporto dei dati, alla sicurezza, alle applicazioni, ... ed ogni area ha un paio di supervisori (gli "Area Director") che hanno il compito di coordinare il lavoro dei gruppi di lavoro che esistono dentro quell'area.
• I gruppi di lavoro sono insiemi di esperti che discutono come creare i nuovi protocolli.
• I documenti prodotti dai gruppi di lavoro sono appunti le "Request For Comments" (RFC): infatti un gruppo non produce "uno standard assoluto", ma una proposta di standard, che viene sottoposta ai commenti pubblici affinche venga raffinata, valutata, eventualmente modificata, e, dopo un lungo processo di verifiche sul campo, eventualmente solo alla fine adottata come "Standard Internet".
• Ogni gruppo di lavoro ha un paio di coordinatori (chairman), il cui scopo e' di guidare il gruppo nel raggiungere un consenso (rough consensus) sui documenti da proporre, nonche' di collaborare con gli Area Director nel processo di pubblicazione/discussione/revisione dei documenti proposti.
• L'insieme degli Area Director costituisce l'Internet Engineering Steering Group (IESG) che ha il compito di approvare, mantenendoli coerenti e compatibili, i documenti (e di consceguenza i protocolli) che i vari gruppi di lavoro propongono.
• Un RFC viene pubblicato soltanto quando l'IESG da il suo consenso.
• Al di sopra di tutto vi e' l'Internet Architecture Board (IAB) che ha lo scopo di dare le direttive generali per lo sviluppo del lavoro, di coordinare le attivita' di IETF con gli altri organismi che emanano standard (ad esempio IEEE, ITU, ISO, ...) e di risolvere eventuali dispute che dovessero verificarsi nel corso della discussione di un documento.
• Vi e' poi il "chairman" di IETF, che ha come scopo di coordinare il funzionamento di IETF stessa.
• Tutte le "cariche" di IETF (dal chairman del gruppo di lavoro, al chaiman di IETF) sono "per nomina" (NON per elezione!) da parte delle comunita' stessa, in base ai meriti ed alle conoscenze delle persone, e vengono effettuate anche queste per "rough consensus" da parte di appositi comitati scelti con estrazione casuale tra coloro che si rendono disponibili a farne parte (e' un gran lavoro!).
• http://www.ietf.org

Che cos' e' un Request For Comments c'e' scritto ... in qualche rfc (a partire dallo 2026): ma cosi' ci mordiamo la coda :-) quindi ... mi rendi una definizione completa col numero minimo di parole ?

• Una "Richiesta pubblica di commenti" (appunto!); puo' essere una richiesta pubblica di commenti su una specifica tecnica di un protocollo, oppure su una procedura di utilizzo di qualche servizio, o di Internet stessa, oppure semplicemente un documento informativo per la comunita' che utlizza Internet in generale.
• Un RFC quindi NON e' uno standard, in nessun modo.
• Alcuni RFC, quelli che definiscono una specifica tecnica di un protocollo, e che sono passati attraverso una lunga serie di revisioni, prove sul campo, aggiornamenti, etc. diventano poi "Internet Standard", ma sono classificati anche in modo diverso "STD nn" (nn e' un numero progressivo).
• Altri RFC sono "proposte per standard" in vari stadi di sviluppo (vedi dopo).
• Un RFC puo' anche descrivere le regole del gioco dell'oca, se e' di categoria "informativa", e l' IESG lo giudica utile per la comunita' Internet (nel caso del gioco dell'oca lo dubito!).

Da "informativo" a "obsoleto": quali sono le categorie o "stati di efficienza" (per cosi' dire) di un rfc ? Come si "passa" da una categoria all' altra ?

• Gli RFC sono in tre grossi "gruppi":
• Quelli "informativi", che non specificano solitamente un protocollo, oppure che hanno come scopo la descrizione di un protocollo "proprietario" (ad esempio, un produttore s/w puo' decidere di scrivere un RFC informativo per descrivere come funziona uno dei suoi prodotti). In ogni caso questi RFC NON hanno alcun valore di standard, anche perche' non vengono sottoposti ad alcun processo di verifica tecnica, di discussione tecnica, di coerenza e completezza dell'informazione e sopratutto non vengono sottoposti al processi di consenso pubblico sul documento che e' fondamentale per le altre categorie di RFC. E' una categoria che spesso viene usata, in modo assolutamente improprio e scorretto, da parte del marketing per dichiarare che "il proprio prodotto e' conforme ad un RFC" (RFC che spesso e' scritto dalla ditta stessa).
• Quelli "sperimentali" che descrivono una specifica tecnica non ancora matura per una implementazione di produzione, e come tale va sottoposta a "sperimentazione" prima di decidere se e' valida per entrare nel processo di standardizzazione. Un RFC "experimental" viene comunque valutato dai gruppi di lavoro che lo propongono, dall' IESG etc... ma semplicemente e' in uno stadio di sviluppo tale che puo' produrre solo delle applicazioni o servizi "prototipo", con il rischio che non vi sia compatibilita' tra versioni successive, etc etc...
• Quelli "standard track", ovverosia quelli che specificano un protocollo che con il tempo potrebbe diventare uno Standard Internet. Questi sono tutti discussi dai gruppi di lavoro, rivisti da IESG etc etc. - vi sono i 3 stadi:
• - proposed standard: la prima bozza, da sottoporre a sperimentazione sul campo e verifica. Se questa sembra valida, e ci sono almeno due implementazioni indipendenti che sembrano funzionare bene tra loro, si passa a
• - draft standard: quando si e' gia' fatta la prima verifica. E' uno stadio molto stabile, ma che pero' deve ancora passare l'esame finale: quello delle grande comunita' Internet: se la specifica viene adottata universalmente, e sul campo si guadagna la medaglia di funzionare sempre, comuque ed e' usata da quasi tutti coloro che usano Internet, si passa a
• - Standard Internet. Sono pochi gli "standard Internet" (SMTP, FTP, telnet, ...)...
• Moltissimo protocolli "stabili" sono "Draft standard", in ogni caso.

Mi metti ulteriormente a fuoco il ruolo dello Steering Group nello accreditare gli RFC?

• Deve verificare che la specifica sia "coerente" con le altre specifiche internet, in tutte le aree di applicazione, ad esempio che non vi siano buchi di sicurezza nella specifica, che non vada a duplicare o peggio a rendere ambigue altre specifiche gia' esistenti, e deve assicurarsi che il processi di discussione (in collaborazione con il chairman del gruppo di lavoro) sia stato coerente, completo e corretto.

Non spararmi ... ci sono oggi circa 4500 rfc ... te la senti di indicarne una dozzina di *fondamentali*, a puro uso didattico, per chi volesse approcciare la problematica ?

• Piu' facile di quello che sembra: basta prendere i pochi che hanno passato l'esame di Internet Standard:
• http://www.ietf.org/rfc/std/

Questioni "editoriali": con che regole e procedure si scrive e si propone un rfc ?

• Discussione preventiva nel gruppo di lavoro (quasi tutta sulla mialing list), seguita da una serie di Internet-draft che vengono rivisti dal gruppo stesso. chiunque puo' proporre ad un gruppo di lavoro un Internet-draft, e se il gruppo lo riterra' valido, lo si passera' nella catena di approvazione descritta prima.
• Le regole di scrittura di un RFC, quelle proprio "editoriali tipografiche" sono in un RFC stesso: RFC 2223, uno degli ultimi scritti di Jon Postel.

Claudio ... non voglio farla tanto lunga ma consentimi una essenziale premessa alla richiesta di commenti :-) che ora ti pongo sulla straordinaria concatenazione degli RFC riguardanti il Domain Name System ...

Internet ha "sfondato nel mondo" ... e a me sembra si debba estendere con particolare forza alla telematica la "lungimirante proposta" [Gianfranco Capriz] che il maestro di Trumpy, Alfonso Caracciolo di Forino, lanciava alla informatica: bisogna aggiungere alla considerazione di grammatiche, sintassi e semantiche anche un capitolo di *pragmatica*.

Gli RFC dns_centrati risolvono i numeri in "parole" (e viveversa); con cio' stesso entrano in gioco le "lingue", e con cio' stesso nazioni e popoli ... cosi' e solo cosi' internet e' transcontinentale e davvero ... "for everyone" ... Mi rendi una guida di lettura pls al significato essenziale di:

DNS rfc 1033, rfc 1034, RFC 1035 (November 1987) ...

• All'inizio la Terra era piatta... poi arrivo' qualcuno che mise in dubbio questo concetto, ed i navigatori del XV e XVI secolo provarono a tutti che era rotonda
• Forse si puo' cominciare cosi'... anche per il DNS. Era chiaro dall'inizio che i "numeri" sono una cosa difficile da ricordare, e quindi il file hosts.txt era stato il primo rimedio a questo problema tutto umano del preferire i nomi ai numeri.
• Ma un file locale e "piatto" era diverso da luogo a luogo, e quindi bisognava organizzare il mondo. Ognuno nel proprio "dominio di competenza", ovverosia io do' i nomi alle MIE macchine/risorse, e gli altri alle loro, e faccio il nodo che tutti li usino e vedano. Ma anche questo era fatto di "isole piatte", e se le isole erano troppo grandi, anche il "governante locale" doveva delegare a vassalli e valvassori le proprie provincie...
• Ci volle poco quindi ad arrivare alla gerarchia a piramide, che e' propria del DNS, ed e' invece del tutta estranea agli indirizzi IP (v4). I concetti spiegati li' sono ancora oggi fondamentali, e andrebbero ricordati ogni volta che si cerca di richiedere qualcosa al DNS: ognuno e' il padrone del PROPRIO dominio e NON DEVE interferire con il dominio degli altri, dai quali deve semplicemente accettare le informazioni che ne provengono. Al massimo puo' decidere di non usarle.
• Anche l'idea che la "punta" della piramide e' unica e' da tenere ben presente.

DNS Structure and Delegation rfc 1591 (March 1994)

• Quando la "buona volonta' dei singoli" non bastava piu' a coprire il mondo, si dovette ricorrere ad alcuni principi scritti, per decidere almeno chi fossero i gestori dell'albero principalre (vicino alla radice). Jon Postel lo fece in questo breve, ma tuttora valido documento.

IDN rfc 3490, rfc 3491, rfc 3492 (March 2003)

• ... una delle cose di cui si erano dimenticati i padri del DNS... e' che in giro per il mondo non ci sono solo i nomi scrivibili in alfabeto latino, senza accentti etc...
• Devo dire che se ne erano dimenticati in generale anche quasi tutti gli europei che usano l'alfabeto latino, ma ovviamente provate ad immaginare se il DNS fosse stato concepito gia' solo in Europa orientale dove si usa il Cirillico o peggio in Asia dove a volte non c'e' nemmeno il concetto di "alfabeto", ma di "ideogramma".
• Che effetto avrebbe fatto su di noi? Avremmo trovato i nomi del DNS semplici e di aiuto? Oppure sarebbero stati ostici con gli indirizzi IP originali?
• Questa era la situazione di una grande parte del "mondo internet" che si stava espandendo. Quindi si cerco' di permettere di codificare anche alfabeti/scritture diverse dentro il DNS, in modo da risultare "naturali" anche per questi altri utenti. Da non dimenticare anche la spinta "commerciale" che ormi premeva forte sulle richieste tecniche, e la non sempre felice interazione tra "nomi dei domini" e "segni di riconoscimento" noti...
• Queste specifiche (nate con non poca discussione in un campo in cui la parola d'ordine era comunque "compatibilita' con il DNS in ASCII!") sono state la soluzione "alla Internet", cosi' come MIME era stato la soluzione alla Internet per il mail multimediale (dentro un mail nato puramente testuale).

DNS sec rfc 4033, rfc 4034, rfc 4035 (March 2005)

• .... se torniamo al punto iniziale, dove "ognuno e' responsabile del proprio dominio e non deve interferire con i domini degli altri", e' evidente che sotto sotto c'e' il principio generale che "la gerarchia dei gestori si comporta in modo eticamente corretto".... ma quando la base degli utenti e gestori si espande... e' ovvio che la natura umana entra in gioco.
• Quindi bisogna difendersi da chi cerca di fare il bluff... di far finta di essere un altro, per circuire l'utenza. E il DNS e' il posto piu' vulnerabile, perche' un utente parte quasi sempre da un "nome" (oggi sarebbe piu' corretto dire da una URL, ma sempre un nome contiene) per raggiungere una risorsa. Cercare di infilarsi nel mezzo, e da un nome vero portare l'utente alla risorsa "falsificata" e' quindi una tecnica efficace per i poco onesti.
• Da cui la soluzione di rendere "sicura" la catena di delegazione tra i server DNS, in modo che non sia cosi' facile fare il "man in the middle". Tra l'altro, da ricordare che se tutto il DNS fosse gia' "sicuro" buona parte delle attuali tecniche di circuizione dell'utente (phishing in testa) diventerebbero molto piu' difficili da attuare.

La data (2005) fa capire che siamo ancora lontani dall'avere il DNS Sec implementato dovunque... purtroppo.

Terz' ultima domanda:

... Internet non "sta' in piedi" su "Comandamenti" scolpiti a fuoco sulla pietra (modello religioso) ... su "Manifesti" (modello ideologico) ... su "Costituzioni" (modello statuale) ...

... sembra piuttosto, anche nei suoi formalismi, un universo in espansione, "under construction". Un commento, pls, se vuoi pure con riferimento ed esempio alla evoluzione di qualche protocollo.

• Internet E' perennemente under construction, ed e' per quello che funziona e si espande.
• All'inizio "parlava" con gli altri attraverso gateway.
• Oggi "gli altri" li ingloba, facendogli usare TCP/IP come base per i propri servizi.
• Gli stessi RFC, che sono quasi tutti "DRAFT", sono la prova che si tratta di lavoro in evoluzione.
• L'esempio piu' facile per me, ma anche il piu' eclatante: la messaggistica elettronica
• SMTP, poche cosa, semplici, insicure, solo in ASCII, ma si parlava con tutti
• Aggiunta di MIME, ed ecco il multimedia (anche se un po grezzo, ma cosi' flessibile MIME nella specifica, che ancor aoggi ne vengono aggiunte nuove parti)
• Aggiunta della sicurezza, con S/MIME e PGP, nonche' con i protocolli di comunicazione sicura client/server
• Integrazione dentro il servizio mail dei servizi di messaggistica per la telefonia (3GPP, MMS, UMTS, ....)

Penultima domanda: a me sembra che "il sistema tenga", pure ora che siamo sul filo di un miliardo di corrispondenti nel mondo e 29 milioni di corrispondenti in Italia. Tu che dici ?

• Tiene benssimo, anche se IETF si sta dando una struttura amministrativa e di gestione... perche' ormai e' troppo lavoro perche lo facciano sempre e solo i volontari.

Strutture che comunque sono di aiuto: il nucleo di IETF ed il sistema di lavoro restano gli stessi.

Radici della rete ... una memoria personale, a ruota libera, sul tuo primo rfc ...

• RFC 1405... pubblicato in gennaio 1993, ma discusso (a lungo) tra il 1991 ed il 1992, ancora nella preistoria, quando tutti si conoscevano di persona ad IETF, e quindi una pubblicazione di in RFC era ancora un fatto che implicava "l'aver convinto tutti gli altri che avevi proposto una cosa sensata".
• Ed era pure un RFC che un' altra organizzazione avrebbe definito "eretico ed inammissibile", in quanto ammetteva implicitamente che all'epoca Internet NON era la piu' grande rete di comunicazione, ma solo una bozza in sviluppo ancora molto embrionale, mentre le comunicazioni e le reti in produzione era altre, come quella specificata da OSI (avevamo appena finito di scrivere gli RFC per X.400 mail e come interfacciarla a qulla misera cosa che a confronto era SMTP, senza multimedia, senza caratteri accentati, senza niente), oppure quelli proprietari IBM (BITNET) o Digital (DECnet).
• Ma i mail si spedivano con DECnet, e qualcuno con X.400 e qualcuno con BITNET, per cui ad IETF non ci volle molto a convincere tutti che il mail serve solo se arriva "a tutti", anche se questi hanno deciso che si fidano di piu' di un protocollo proprietario con DECnet che di una roba un po' ancora cosi' cosi' some SMTP e TCP/IP.
• E non era detto chi avrebbe vinto la battaglia per la rete. L'IETF aveva pero' adottato la filosofia "noi intanto parliamo con gli altri" ed accettiamo i gateway...
• Ricordo che ad esempio per l'altro lavoro appena concluso (gateway X.400 con SMTP) la Digital ci aveva convocato al suo quartier generale per avere lumi su come i suoi prodotti (OSI) avrebbero dovuto interfacciarsi con "questa cosa chiamata TCP/IP", ed in quella occasione gli avevamo detto che anche i loro prodotti proprierari potevano fare lo stesso; "that's seems a good idea" fu la risposta, ed allora il gruppo di eretici protocol agnostici si mise al lavoro... ed ecco RFC1405.

Internet e' "in prima generazione" ... con un grande rimpianto ... mi rifiuto assolutamente :-) di risolvere una intervista a Claudio Allocchio su IETF, RFC, DNS ... senza chiederti in fine una memoria personale su Jon Postel ...

• Jon aveva alcune caratteristiche tutte sue, a partire dalla folta barba incolta, dall'amore per le camicie a righe, ad un profondo (e saggio) conservatorismo da "papa' di Internet".
• Quindi per poter introdurre qualcosa di nuovo nella rete, e specialmente nel DNS, il passo iniziale e preliminare era "convincere Jon che si puo' fare e che Internet non collassera' per questo".
• Nel 1991, quando iniziai insieme a pochi altri europei a frequentare IETF, e quando ancora ad IETF si andava in 150 persone al massimo, ovviamente Jon era considerato "il capo da rispettare" ma un capo saggio e che sapeve ascoltare. Io ero uno di quei giovinastri sbarcati in nord america che volevano "civilizzare gli indigeni" spiegando loro che con qualche protocollo inventato dalle parti di Ginevra (OSI) forse si poteva fare qualcosa in piu' se lo si integrava con l'invenzione dei nativi americani (il TCP/IP). Come tutti gli invasori quindi dovevo superare anche una ulteriore diffidenza iniziale.
• Figuriamoci quando andai a spiegare a Jon che avevo pensato, insieme ad alcuni nativi aperti alle novita' ed agli altri invasori venuti dall'est, che si poteva usare il DNS per trasporare l' informazione di traduzione tra gli indirizzi e-mail OSI (X.400) e quelli Internet (RFC822)...
• La prima cosa che mi disse fu che eravamo completamente pazzi. Ma Jon non era persona "chiusa alle novita' ", anzi... era solo prudente e voleva ben capire che cosa volessimo davvero fare. Ci vollero molte riunioni, tutte rigorosamente attorno ad un tavolino con una buona birra in mezzo, e parecchio tempo prima che Jon dicesse un "va bene... potete provare un un esperimento... e se questo riesce, poi vediamo di migliorare la cosa".
• Non aveva torto... certo l'idea di inserire nel DNS un nuovo "resoruce record" e' semplice... ma poi questa nuova cosa andava implementata, e diffusa su TUTTE le installazioni esistenti... che gia' allora erano "tante", ed era questa la grande preoccupazione di Jon: non creare "dialetti tecnologici nelle implementazioni" ma mantenere la lingua comune nel DNS.
• Soprendentemente bastarono solo 6 mesi perche in modo spontaneo la diffusione della nuova "feature" si diffondesse praticamente dappertutto... e devo dire che in quesro fummo molto aiutati dal fatto che allo stesso tempo era stata scoperto un "bug" dentro l'implementazione piu' diffusa (BIND) per cui tutti si affrettarono a sostituire le vecchie versioni con quelle nuove (che contenevano il nuovo resoruce record sperimentale).
• Quando alla fine tirammo le somme... la birra la pago Jon a tutti noi... il DNS si poteva anche modificare, se lo si faceva con attenzione.

E capimmo che in realta' non era quella persona diffidente che poteva sembrare al primo impatto, e che sotto quella barba e quegli occhiali un po' da professore un po' da figlio dei fiori c'era un sorriso... un sorriso che, un brutto giorno improvviso, ci dissero che non c'era piu', mentre aspettavamo di dirci "Hi Jon, how're you?", solo poche settimane dopo, al prossimo meeting.