Policy internazionale di Fidonet
Documento postato, in piu' parti, in Forum Alcei da Giovanni Lopes.
SEZIONE 1 - Premessa ed introduzione
SEZIONE 2 - Procedure riguardanti i sysop
SEZIONE 3 - Procedure generali per i coordinatori
SEZIONE 4 - Procedure per i coordinatori di net
SEZIONE 5 - Procedure per i coordinatori regionali
SEZIONE 6 - Procedure per i coordinatori di zona
SEZIONE 7 - Procedure per il coordinatore internazionale
SEZIONE 8 - Procedure di referendum
SEZIONE 9 - Risoluzione delle dispute
SEZIONE 10 - Appendici
Integrazione italiana (Region 33)
From: Giovanni Lopes
Date: 24 Jul 95 10:26:00 +0000
Subject: Policy Fidonet - Sezione I (1/2)
Message-Id: <104_9507242002@abeline.it>
Organization: Abeline
To: alcei@inet.it
Sender: owner-alcei@venere.inet.it
Precedence: bulk
+---------------------------------------------------------------+
| _ |
| / \ |
| International /|oo \ |
| FidoNet Association (_| /_) |
| _`@/_ \ _ |
| | | \ \\ |
| P. O. Box 41143 | (*) | \ )) |
| Saint Louis, MO 63141 ______ |__U__| / \// |
| United States of America / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (tm) |
+---------------------------------------------------------------+
F I D O N E T
Policy
Norme di comportamento e guida operativa
Versione 4.8 (Italiana)
traduzione di Giorgio Rutigliano
Coordinatore Regionale FidoNet Italia
nodo 33/1
Fido e FidoNet sono marchi registrati della Fido Software, Inc.
SEZIONE 1
PREMESSA ED INTRODUZIONE
Premessa di Giorgio Rutigliano.
Questo documento, tradotto dall'originale Policy4 (ex P4V8), con-
tiene la normativa internazionale dell'Associazione FidoNet. Ogni
CBBS che richiede l'ingresso alla rete implicitamente si impegna
a rispettare le norme stabilite in questa normativa, e nei docu-
menti ad essa associati PolicyZ2 e Policy33, che contengono le
estensioni della Zona 2 e della Region 33.
Nel presente documento vengono mantenuti inalterati tutti i ter-
mini anglosassoni che tradotti in italiano potrebbero creare con-
fusione.
(Agosto 1989)
Premessa dell' IFNA.
Questo documento stabilisce le linee politiche operative dei
Sysop membri dell'organizzazione FidoNet di sistemi di Bulletin
Board Elettronici. La FidoNet e' definita dalla lista dei nodi
(Nodelist) edita settimanalmente dal Coordinatore Internazionale.
Documenti separati possono essere definiti a livello di Zona,
Regione o Network (di seguito abbreviato in Net) per fornire det-
tagli aggiuntivi sulle procedure locali. In via ordinaria, questi
documenti integrativi non debbono contraddire questa Policy. Na-
turalmente, previa approvazione del Coordinatore Internazionale,
tali documenti integrativi possono essere usati per implementare
differenze motivate da condizioni locali, senza tuttavia aggiun-
gere restrizioni ai membri FidoNet che eccedano quelle incluse in
questo documento, escluso l'imposizione di periodi 'mail' locali.
1.0 Lingua.
La lingua ufficiale della rete FidoNet e' l'Inglese. Tutti i do-
cumenti debbono essere disponibili in Inglese. E' incoraggiata la
traduzione in altre lingue.
1.1 Introduzione.
La FidoNet e' un sistema amatoriale di posta elettronica. In base
a questo tutti i suoi partecipanti ed operatori sono volontari
non retribuiti. Dai suoi inizia come interconnessione tra pochi
amici (1984), oggi (1989) include oltre 5000 sistemi in sei con-
tinenti.
La FidoNet non e' un vettore commerciale: e' una rete pubblica
solo in quanto i nodi indipendenti costituenti la rete possono
individualmente fornire accesso pubblico a tale rete attraverso i
loro sistemi.
La FidoNet e' abbastanza grande da crollare sotto il proprio peso
senza una struttura operativa, fornita dalla suddivisione in Net,
ed un controllo decentrato. Questo documento descrive le procedu-
re che sono state messe a punto per gestire la rete.
1.2 Organizzazione.
I sistemi FidoNet sono raggruppati in vari livelli, e l'ammi-
nistrazione e' decentrata ad ognuno di questi. Di seguito e' una
brave descrizione della struttura; piu' in avanti saranno discus-
si i compiti dei vari Coordinatori.
1.2.1 Sistemi Individuali e Operatori di Sistema (Sysop).
La piu' piccola suddivisione della rete FidoNet e' il sistema
individuale, corrispondente ad un rigo della nodelist. L'Operato-
re del Sistema, detto Sysop, formula una politica di gestione del
BBS e di interazione con gli utenti. Il Sysop deve interagire con
il resto della rete per ricevere ed inviare messaggi, e le poli-
tiche di gestione debbono essere in accordo con quelle degli
altri livelli FidoNet.
1.2.1.1 Utenti.
Il Sysop e' responsabile delle azioni degli utenti che si riper-
cuotono sul resto della rete. Tutto il traffico immesso in rete
da un nodo e' considerato generato da un utente se non e' creato
dal Sysop, ma e' sotto la responsabilita' di quest'ultimo (vedi
la sezione 2.1.3).
1.2.1.2 Points.
Un Point e' un sistema FidoNet compatibile che non e' riportato
nella nodelist, ma che comunica con la rete attraverso un nodo
definito 'Boss'. Un Point e' generalmente considerato alla pari
di un utente per cui il suo nodo 'Boss' e' responsabile della
posta originata dal Point (vedi sezione 2.1.3). I Point sono in-
dirizzati utilizzando il numero di nodo del Boss: ad esempio un
Point con Boss 114/15 potrebbe essere il 114/15.12. I messaggi
destinati al Point devono essere inviati al Boss, che provvedera'
ad instradarli a destinazione.
Per la gestione dei Point, il Boss deve utilizzare un numero pri-
vato di net che generalmente non deve essere visibile al di fuori
della relazione Boss-Point. Sfortunatamente, nel caso il point
chiami un altro sistema direttamente (in una file-request, ad
esempio) il numero privato appare nell'indirizzo del nodo chia-
mante. In questo i Point differiscono dagli utenti, in quanto
operano sistemi FidoNet compatibili che sono in grado di entrare
in contatto con sistemi diversi da quello del Boss.
1.2.3 Net e Coordinatori di Net.
Un Net e' un raggruppamento di nodi in una Zona geografica, nor-
malmente definita da un'area di bassi costi telefonici. I Net
coordinano la loro attivita' di scambio messaggi in modo da dimi-
nuirne i costi.
Il Coordinatore di Net ha il compito di mantenere una lista dei
nodi del Net, e di instradare ai nodi del Net tutti i messaggi
ricevuti da altri nodi FidoNet. Il Coordinatore di Net puo' pren-
dere accordi per gestire i messaggi in uscita dal Net, ma non e'
obbligato a farlo.
Il Coordinatore di Net e' nominato dal Coordinatore Regionale.
1.2.3.1 Hub.
Gli Hub esistono solo in alcuni Net. Possono essere nominati dal
Coordinatore di Net per contribuire alla gestione di grosse reti.
La definizione dei compiti e delle procedure degli Hub sono a
carico del Coordinatore di Net, e non saranno discussi in questa
sede. Il Coordinatore di Net non puo' comunque delegare la pro-
pria responsabilita' di mediare dispute.
1.2.4 Regioni e Coordinatori Regionali.
Una Regione e' una Zona geografica ben definita contenente nodi
che possono o no essere combinati in Net. Una tipica Regione con-
tiene un gran numeri di nodi raggruppati in Regioni ed un piccolo
numero di nodi indipendenti che non sono parte di Net.
Il Coordinatore Regionale ha il compito di mantenere la lista dei
nodi indipendenti della Regione e di ricevere le sotto-liste dai
Coordinatori di Net della Regione. Tutti questi dati vengono fusi
per creare la lista dei nodi della Regione, che viene inviata al
Coordinatore della Zona. Il Coordinatore della Regione non effet-
tua alcun servizio di instradamento dei messaggi per nessun nodo
della Regione.
Il Coordinatore Regionale e' nominato dal Coordinatore di Zona.
1.2.5 Zone e Coordinatori di Zona.
Una Zona e' una grande area geografica contenete molte Regioni,
che copre uno o piu' paesi e/o continenti.
Il Coordinatore di Zona compila la lista dei nodi di tutte le
Regioni della Zona, e crea la lista principale (NODELIST) ed i
file di differenza (NODEDIFF), che sono distribuite attraverso la
rete FidoNet nella Zona. Il Coordinatore di Zona non effettua
servizi di instradamento della posta per nessun nodo della Zona.
Il Coordinatore di Zona e' eletto dai Coordinatori Regionali di
quella Zona.
1.2.6 Zone Coordinator Council.
In determinati casi i Coordinatori di Zona operano in consiglio
per fornire supporto al Coordinatore Internazionale. Questo tipo
di organizzazione e' simile a quella di un consiglio di ammi-
nistrazione, formato da un presidente e dai consiglieri. In par-
ticolare il consiglio opera sulle questioni interzonali; cio'
include, ad esempio, la messa a punto della generazione della
nodelist, la mediazione di dispute interzonali e tutto cio' che
non e' di competenza dei livelli inferiori della FidoNet.
1.2.7 Coordinatore Internazionale.
Il Coordinatore Internazionale e' il Coordinatore di Zona "primo
tra pari" e coordina la generazione della lista principale dei
nodi da parte dei Coordinatori di Zona.
Il Coordinatore Internazionale agisce come presidente dello Zone
Coordinator Council e sovraintende alle elezioni - organizzando
l'annuncio dei referendum, la raccolta ed il conteggio dei voti,
la proclamazione dei risultati - nei casi in cui queste riguardi-
no l'intera rete FidoNet.
Il Coordinatore Internazionale e' eletto dai Coordinatori di Zo-
na.
1.2.8 Organizzazione Top-Down.
Questi livelli hanno lo scopo di distribuire l'amministrazione ed
il controllo della rete FidoNet al livello piu' basso possibile e
nel contempo consentire azioni Coordinate dell'intera rete.
L'amministrazione e' resa possibile da una organizzazione top-
down, ove ogni livello e' responsabile per quello immediatamente
inferiore.
Ad esempio, un Coordinatore Regionale e' responsabile verso il
Coordinatore di Zona di cio' che accade nella sua Regione. Dal
punto di vista del Coordinatore di Zona, il Coordinatore Regiona-
le e' totalmente responsabile della correttezza delle operazioni
della Regione. Lo stesso tipo di rapporto esiste tra il Coordina-
tore Regionale e quello di Net.
Se una persona di un livello superiore a quello di Sysop non e'
in grado di osservare i suoi compiti, la persona a livello imme-
diatamente superiore puo' rimpiazzarla. Ad esempio, se un Coordi-
natore Regionale non effettua in modo corretto i suoi compiti, il
Coordinatore di Zona puo' rimpiazzarlo.
Per fornire una migliore organizzazione dei livelli superiori
della rete FidoNet vi sono due eccezioni a questa organizzazione
Top-Down. I Coordinatori di Zona e il Coordinatore Internazionale
sono eletti a maggioranza dei voti dei Coordinatori di livello
immediatamente inferiore. Allo stesso modo, le decisioni prese
dal Coordinatore Internazionale possono essere modificate dallo
Zone Coordinator Council, e quelle di quest' ultimo dai Coordina-
tori Regionali (vedi le sezioni 6 e 7 per ulteriori dettagli). Le
decisioni prese da altri Coordinatori non possono essere modifi-
cate da votazioni a livello inferiore, mentre sono soggette a
processo di appello cosi' come descritto al punto 9.5.
1.3 Definizioni.
1.3.1 FidoNews.
La FidoNews e' un bollettino settimanale distribuito in forma
elettronica attraverso la rete. E' un mezzo importante, attraver-
so il quale comunicano i Sysop della rete. La FidoNews danno il
senso di essere una comunita' di persone unite da un interesse
comune; pertanto Sysop e utenti sono incoraggiati a contribuire
alle FidoNews. Articoli e notizie debbono essere inviate al nodo
1:1/1; un file contenente descrizioni sul formato da utilizzare
e' disponibile su tale nodo e su molti altri sistemi.
1.3.2 Geografia.
Ogni livello della rete FidoNet e' geograficamente contenuto dal
livello immediatamente superiore. Ogni localita' geografica e'
coperta da una Zona e da una Regione della Zone, mentre puo' es-
sere o no coperta da un Net. Non puo' mai accadere che due Zone o
due Regioni o due Net coprano la stessa area geografica.
Se un nodo e' nell'area di un Net questo deve essere parte di
quel Net e non un nodo indipendente della Regione (l'eccezione
principale e' un nodo che riceve abnormi quantita' di messaggi
host-routed; vedi la sezione 4.2). I confini dei Net sono deline-
ati in base alle aree definite dalle compagnie telefoniche loca-
li; anche in caso di aree in cui la densita' dei nodi e' tale da
richiedere l'impementazione di piu' Net per una singola area,
considerazioni geografiche stabiliscono se un nodo debba apparte-
nere all'uno o all'altro Net.
L'affiliazione ad un Net e' basata esclusivamente su basi geogra-
fiche e/o tecniche e non e' ___ basata su fattori personali o
sociali.
Vi sono casi in cui la distribuzione delle aree telefoniche
portano a situazioni in cui la logica impone che un nodo fisica-
mente appartenente ad una Regione debba in effetti essere asse-
gnato ad un'altra. In questi casi, e previo accordo dei Coordina-
tori delle Regioni e della Zona interessati, e' possibile fare
delle eccezioni. Queste eccezioni sono descritte alla sezione
5.6.
1.3.3 Zone Mail Hour.
E' denominato Zone Mail Hour (ZMH) il periodo di tempo durante il
quale tutti i nodi debbono essere in grado di ricevere messaggi
dalla rete. Ogni Zona FidoNet definisce una ZMH e comunica la sua
ZMH a tutte le altre Zone FidoNet. Vedi i punti 2.1.8 e 10.2.
Precedentemente la ZMH era denominata NMH (National Mail Hour o
Net Mail Hour): il termine Zone Mail Hour e' piu' appropriato.
1.3.4 Lista dei nodi (Nodelist).
La lista dei nodi e' un file, aggiornato settimanalmente, che
contiene gli indirizzi di tutti i nodi FidoNet riconosciuti.
Questo file e' al momento reso disponibile dal Coordinatore di
ogni Zona non piu' tardi della ZMH del sabato, ed e' distribuito
in forma elettronica per mezzo di download o di file request
senza alcun costo. Per essere inclusi nella nodelist i sistema
devono soddisfare le caratteristiche minime definite in questo
documento. Nessuna caratteristica aggiuntiva puo' essere imposta.
Nodelist parziali (di una singola Zona, ad esempio) possono esse-
re disponibili ai differenti livelli della rete FidoNet. L' elen-
co completo, pubblicato dal Coordinatore Internazionale, e' la
lista dei nodi ufficiale della rete FidoNet, ed e' utilizzato in
circostanze quali la determinazione del diritto di voto in caso
di elezioni. Tutte le parti che contribuiscono alla creazione
della nodelist totale sono disponibili sui sistemi di ogni Coor-
dinatore di Zona e Regionale.
1.3.5 Comportamento troppo seccante.
Ci sono riferimenti in questo documento al "comportamento troppo
seccante", particolarmente nella sezione 9 (Risoluzione delle
dispute). E' difficile definire questo termine, in quanto basato
sul libero giudizio della struttura di coordinamento. In generale
il comportamento seccante irrita, secca o causa danno ad altre
persone: non e' necessario infrangere la legge per essere seccan-
te.
C'e' una distinzione tra un "comportamento troppo seccante" e il
(semplice) comportamento seccante. Ogni nuovo sysop, ad esempio,
segue una curva di apprendimento, sia dal punto di vista tecnico
(su come mettere a punto il software) che dal punto di vista so-
ciale (come interagire con la rete FidoNet). E' facile che duran-
te questo periodo capiti di seccare qualcun altro. Solo quando
questo tipo di comportamento persiste, anche dopo aver chiarito
la situazione, che diventa "troppo seccante". Questo non toglie
che sia possibile "seccare" anche senza ripetizione (ad esempio,
deliberate falsificazioni nell'invio di messaggi possono facil-
mente diventare troppo seccanti fin dal primo tentativo), ma
semplicemente illustra come una certa tolleranza sia giustifica-
ta. Per maggiori informazioni fare riferimento alla sezione 9 e
ai casi riportati (sezione 10.3).
1.3.6 Uso commerciale.
FidoNet e' una rete amatoriale, i cui partecipanti investono tem-
po e moneta per farla funzionare, a favore di tutti gli utenti.
Non e' giusto che imprese commerciali sfruttino questi sforzi,
gratuiti, per perseguire i propri interessi. D'altro canto Fido-
Net fornisce una via efficace per lo scambio di informazioni tra
imprese ed utenti, con il mutuo beneficio di tutti.
I Coordinatori di Net potrebbero essere costretti a sostenere
operazioni commerciali instradando messaggi host-routed, persino
trovarsi implicati in azioni legali nel caso siano state date
garanzie sui tempi e sui metodi di inoltro dei messaggi.
E' quindi politica FidoNet che i "messaggi commerciali" non siano
inviato attraverso i Coordinatori: questo termine include tutti i
messaggi che hanno specifico interesse di affari senza essere di
beneficio al Net in quanto tale. Esempi includono i messaggi
interni ad una organizzazione od azienda e tra organizzazioni o
aziende, richieste su prodotti specifici (come informazioni sui
prezzi), ordini e messaggi ad essi associati, e tutto cio' che e'
specificatamente in relazione con gli affari.
SEZIONE 2
PROCEDURE RIGUARDANTI I SYSOP
2.1 Generalita'.
2.1.1 Le Basi.
Il Sysop, come operatore di un nodo individuale, puo' in generale
agire come meglio preferisce se osserva gli eventi di scambio
messaggi, non secca troppo gli altri nodi FidoNet, non promuove o
partecipa alla distribuzione di software piratato e non ha altri
tipi di comportamento illegale via FidoNet.
2.1.2 Familiarita' con la Policy.
Per potere meglio comprendere il termine "comportamento troppo
seccante" e' necessario che tutti i Sysop occasionalmente rileg-
gano il documento di politica FidoNet. I nuovi Sysop debbono fa-
miliarizzarsi con la Policy prima di richiedere un numero di no-
do.
2.1.3 Responsabilita' per il traffico di messaggi.
Ogni Sysop elencato nella nodelist e' responsabile per tutto il
traffico di messaggi che viene introdotto nella rete attraverso
il suo nodo come, ad esempio, tutto i messaggi introdotti dagli
utenti, Point e ogni altra rete per cui il nodo agisca come cana-
le di transito. Se il Sysop consente che messaggi generati in
altre reti entrino in FidoNet attraverso il suo nodo, il canale
di transito (gateway) deve essere chiaramente identificato, con
il suo indirizzo FidoNet, come punto di origine di quel messag-
gio, e deve inoltre agire anche in senso inverso. Se tali messag-
gi dovessero violare la Policy e' compito del Sysop correggere la
situazione.
2.1.4 Crittografazione e lettura dei messaggi.
FidoNet e' un sistema amatoriale; la nostra tecnologia e' tale da
non garantire la riservatezza dei messaggi. Ogni Sysop, in quanto
tale, ha il diritto di leggere il traffico che transita sul
proprio sistema, se non altro per assicurarsi che il suo nodo non
sia utilizzato per scopi illegali o commerciali. La crittografa-
zione dei messaggi rende ovviamente impossibile questa verifica.
Inoltre, traffico crittografato e/o commerciale inviato per
l'inoltro (forwarding) senza espresso permesso di tutti i nodi
costituenti il sistema di smistamento costituisce comportamento
seccante. (Vedi la sezione 1.3.6 per la definizione di traffico
commerciale).
2.1.5 Integrita' del traffico in transito.
Il Sysop non puo' modificare alcun messaggio, matrix o EchoMail,
in transito sul proprio sistema, oltre quanto richiesto per
l'inoltro o per altri fini tecnici. Se offeso dal contenuto di un
messaggio, il Sysop deve seguire la procedura descritta alla
sezione 2.1.7.
2.1.6 Messaggi Net Privati.
La parola "privato" deve essere utilizzata con molta cura, specie
con gli utenti di un BBS. Alcuni Stati hanno leggi che riguardano
i "messaggi privati", e dovrebbe essere fatto notare che la paro-
la "privato" non implica il fatto che nessun altra persona, oltre
il destinatario, sia in grado di leggere il messaggio.
I Sysop che non possono offrire questa distinzione dovrebbero
considerare la possibilita' di non offrire tale opzione.
Se un utente invia un "messaggio privato" non ha controllo sul
numero di sistemi intermedi attraverso cui tale messaggio sara'
distribuito. Un Sysop che invia un tale messaggio ad un altro
Sysop, invece, puo' controllare questo aspetto del problema in-
viando il messaggio direttamente al nodo di destinazione, garan-
tendosi in tal modo che solo il Sysop (o altra persona autoriz-
zata) puo' effettuarne la lettura.
2.1.6.1 Riservatezza dei messaggi in transito.
La diffusione o l'uso in qualsiasi forma delle informazioni
contenute in traffico net privato in transito, non avente il
Sysop come mittente o destinatario, e' considerato comportamento
seccante a meno che il messaggio non sia stato rilasciato
dall'autore o dal destinatario come parte di una protesta forma-
le.
Questo punto non si applica nel caso dell'EchoMail, che per defi-
nizione e' un mezzo di distribuzione generale e dove l'uso di
messaggi privati e' utilizzato per restringerne la diffusione ai
soli Sysop.
2.1.6.2 Messaggi privati indirizzati al Sysop.
La diffusione di messaggi privati indirizzati al Sysop e' un pro-
blema piu' complesso di quello trattato al punto precedente. E'
comune opinione legale che i messaggi privati diventino proprie-
ta' del destinatario e questi abbia il diritto legale di farne
cio' che desidera. Ovviamente tale diritto legale non giustifica
un 'comportamento seccante'
Messaggi riservati non dovrebbero generalmente essere inviati
attraverso la rete FidoNet. Questo concetto e' spesso sottovalu-
tato, in quanto la rete FidoNet e' il nostro mezzo principale di
comunicazione. Come indicazione generale il diffondere al pubbli-
co messaggi che il mittente considera confidenziali e' da consi-
derarsi comportamento seccante.
Ci sono ovviamente eccezioni: ad esempio potrebbe capitare di
ricevere un messaggio privato in cui il mittente contraddice
quanto ha gia' detto in un messaggio pubblico; in questo caso il
destinatario non dovrebbe farsi scrupoli solo perche' il mittente
ha richiesto di tenere riservato tale messaggio. Giudizio e buon
senso devono essere usati in questo caso cosi' come in tutti gli
altri aspetti del comportamento sulla rete FidoNet.
2.1.7 Instradamento dei messaggi.
Il Sysop non e' obbligato ad instradare messaggi per conto di
altri nodi, a meno che non sia un Coordinatore di Net o di Hub,
allo stesso modo non e' obbligato ad inoltrare messaggi a mezzo
terzi se non desidera farlo. L'inoltro di messaggi attraverso un
nodo non obbligato all'instradamento senza il preventivo consenso
di tale nodo e' considerato comportamento seccante; questo caso
include l'inoltro di EchoMail non richiesta.
Se per un qualsiasi motivo un Sysop non instrada un messaggio pur
esistendo un accordo in tal merito, tale messaggio deve essere
rispedito al mittente con la spiegazione del perche' non e' stato
instradato. Non e' necessario restituire messaggi indirizzati a
nodi non esistenti nella nodelist. Il blocco intenzionale di mes-
saggi in transito senza l'uso di questa procedura costituisce
comportamento seccante. Nel caso la mancanza di instradamento
dipenda da problemi tecnici, il blocco diventa causa di 'compor-
tamento seccante' solo dopo aver avvertito il Sysop dell'esisten-
za di tale problema.
2.1.8 Esclusivita' della Zone Mail Hour.
La ZMH e' il cuore della rete FidoNet, in quanto momento in cui i
sistemi appartenenti alla rete si mettono in contatto per
scambiare i messaggi. Ogni sistema che desidera essere parte del-
la rete FidoNet ____________________ di ricevere messaggi utiliz-
zando il protocollo definito dal Comitato Tecnico degli Standard
FidoNet (al momento FTS-0001). E' consentito avere capacita' ad-
dizionali, come supportare altri protocolli o supportare periodi
aggiuntivi di scambio messaggi, ma la __________________________
e' il ______________________ durante tale ora del giorno.
Questo tempo __________________________________________. Molti
sistemi addebitano i loro utenti sulla base della chiamata,
indipendentemente dal fatto se ha avuto o meno luogo una connes-
sione. Per questa ragione ogni attivita' diversa dal normale
traffico di messaggi netmail che blocchi un sistema durante la
ZMH e' considerato comportamento scorretto. _____________________
___________________________________________.
Un Sysop membro di un Net deve inoltre rispettare tutti gli even-
ti mail addizionali definiti dal Coordinatore di Net. Le eventua-
li restrizioni di accesso nei periodi addizionali sono lasciate
alla discrezione dei Coordinatori di Net.
2.1.9 Nodi Privati.
Le persone che richiedono nodi privati dovrebbero essere
supportate come Points ove possibile. Un nodo privato e' giusti-
ficato se il sistema deve essere interfacciato con molti altri
come, ad esempio, un nodo di distribuzione EchoMail. In questo
caso i metodi precisi e gli orari di inoltro dei messaggi sono
frutto di accordo tra il nodo privato e gli altri sistemi.
Un nodo privato deve essere parte di un Net, e non puo' esistere
come nodo indipendente in una Regione.
I nodi privati hanno influsso su ogni membro FidoNet in quanto
rubano spazio nella nodelist. I nodi privati creati per la
convenienza di un Sysop (alle spese di tutti gli altri Sysop
FidoNet) sono un lusso che non e' piu' possibile permettersi. I
numeri di nodo ridondanti (ovvero piu' di un indirizzo per la
stesso numero telefonico, eccetto quanto definito dagli standard
FTSC) ricadono nella stessa categoria. I Sysop che richiedono
nodi privati o ridondanti devono presentare una dichiarazione che
spieghi come tale richiesta produca effetti benefici al net o
alla rete. I Coordinatori di Regionali e/o di Net possono rivede-
re queste dichiarazioni in ogni momento e rimuovere i nodi che
ritengano non giustificati.
2.1.10 Osservanza degli eventi di Mail.
L'inosservanza degli eventi di mail e' motivo sufficiente per
l'esclusione del nodo dalla rete senza preavviso, dato che questo
e' normalmente inviato in Netmail.
2.1.11 Uso della Lista dei Nodi.
I sistemi di gestione dei messaggi operano normalmente senza
supervisione umana, ed effettuano chiamate nel cuore della notte;
quindi ogni sistema FidoNet e' nelle condizioni di provocare gra-
ve disturbo in abitazioni private, nel caso adoperi numeri tele-
fonici errati od obsoleti.
Pertanto ogni Sysop che operi un sistema che invia messaggi e'
_________ a prelevare ed utilizzare la ____________ edizione del-
la lista dei nodi.
2.1.12 Scomunica.
Un sistema che e' stato escluso della rete e' detto scomunicato
(ovvero escluso dalle comunicazioni). Se un Sysop si accorge che
il suo sistema e' stato scomunicato senza preavviso, probabilmen-
te il suo Coordinatore non e' stato in grado di entrare in
contatto con lui. In tal caso e' necessario eliminare i problemi
e rientrare in contatto con il Coordinatore.
I sistemi possono essere esclusi anche per giusta causa. Vedi la
sezione 9 ed i punti 4.3 e 5.2.
E' considerato comportamento seccante assistere un sistema scomu-
nicato in modo date da aggirarne l'esclusione; ad esempio invian-
do EchoMail. In questo caso e' probabile che anche il nodo che
fornisce aiuto venga rimosso dalla nodelist.
2.1.13 Orari della Zone Mail Hour.
Gli orari esatti della ZMH sono fissati dal Coordinatore di ogni
Zona. Vedi il punto 10.2
2.1.14 Ora Legale.
La rete FidoNet non segue l'ora legale. Nel periodo di applica-
zione dell'ora legale gli eventi di mail devono essere modificati
nella stessa direzione del cambiamento dell'ora. Alternativamente
e' possibile semplicemente lasciare immutato l'orario del calco-
latore.
2.2 Come richiedere un numero di nodo.
Per prima cosa e' necessario ottenere la lista dei nodi, in modo
da sapere a chi inviare la richiesta. Il numero di nodo equivale
all' "indirizzo" del sistema, in modo che possa ricevere i mes-
saggi.
Il primo passo per ottenere la lista dei nodi e' individuare un
CBBS che operi nella rete. La maggior parte delle liste include
almeno alcuni sistemi FidoNet, e normalmente li identifica per
tali, per cui questa fase non dovrebbe costituire un ostacolo
insormontabile.
Se il Sysop di un sistema FidoNet non ha una lista nodi disponi-
bile per il trasferimento, potra' probabilmente indicare dove
prenderla.
Una volta in possesso della lista, bisogna determinare a quale
Coordinatore fare riferimento. Le Regioni sono numerate da 1 a
99, i Net hanno numero superiori al 99. I Net hanno area limitata
rispetto alle Regioni, ma sono da preferirsi in quanto migliorano
il flusso dei messaggi nell'area e forniscono assistenza ai loro
membri. Se non e' possibile localizzare un Net che copra la Zona
e' necessario fare riferimento alla Regione.
I messaggi devono essere indirizzati al Coordinatore di livello
piu' basso presenti nell'area. Un sistema localizzato vicino al
centro di un Net, ad esempio, deve fare riferimento al Coordina-
tore del Net. Se non ci sono Net nelle vicinanze e' invece neces-
sario entrare in contatto con il Coordinatore della Regione.
Dopo aver localizzato a quale Net o Regione appartiene la Zona e'
necessario inviare una richiesta di affiliazione al nodo zero di
quel Net o Regione. La richiesta ____ essere inviata via FidoMail
in quanto prova che il sistema che chiede l'affiliazione e' in
grado di operare in rete.
E' altresi' necessario programmare il software in modo che
l'indirizzo del mittente non crei problemi a colui che ricevera'
la richiesta di affiliazione. E' necessario quindi evitare numeri
di nodi gia' esistenti. L'indirizzo tradizionale da utilizzare
per le richieste e' -1/-1, ma se il software non e' in grado di
gestirlo si puo' usare Net/9999 (es: per richiedere l'affiliazio-
ne al net 123 si usa 123/9999). Molti Net hanno istruzioni speci-
fiche per i potenziali Sysop, e spesso indicano quale numero bi-
sogna usare per indirizzare le richieste.
Il messaggio di richiesta del numero di nodo deve includere al-
meno i seguenti elementi:
1) Il nome del Sysop.
2) Il nome del sistema.
3) La citta' dove e' impiantato il sistema.
4) Il numero di telefono dati del CBBS.
5) Gli orari di funzionamento.
6) Il massimo baud rate del modem.
Il Coordinatore puo' richiedere informazioni aggiuntive, in
questo caso entrera' in contatto con il Sysop. Tutte le informa-
zioni sono confidenziali e non saranno rilasciate a terzi se non
all'eventuale successore del Coordinatore di Net.
____ inoltre essere chiaramente indicato che il Sysop ha letto ed
accetta le norme contenute nei documenti di Policy FidoNet.
E' necessario attendere non meno di due o tre settimane perche'
il numero di nodo possa essere assegnato. Nel caso la richiesta
sia stata inviata al Coordinatore Regionale e' possibile che
questa venga smistata al Coordinatore del Net competente per Zo-
na.
2.3 Se e' necessario andare fuori servizio.
Se si prevede che il nodo sara' fuori servizio per un periodo
esteso (piu' di un giorno o due), e' necessario darne comunica-
zione al Coordinatore __________________________. Trascurando
questa precauzione, gli altri sistemi cercheranno di entrare in
contatto con il sistema fuori servizio, con molto disturbo per
tutti. Non collegare _________________ dispositivi telefonici con
risposta automatica (tipo segreterie telefoniche, o faxsimili)
sulla linea del sistema FidoNet quando questo e' fuori servizio.
Ignorando questa disposizione, i sistemi FidoNet chiamando ripe-
tutamente il CBBS troverebbero questo apparecchio a rispondere,
con grande sperpero di soldi in bolletta telefonica, cosa _____
seccante. Leggi la sezione Soluzione delle dispute per maggiori
informazioni su cosa si va incontro seccando il prossimo.
Se si prevede, inoltre, di lasciare il sistema senza supervisore
per un periodo di tempo esteso (ad esempio, durante il periodo di
ferie), e' altresi' importante darne comunicazione preventiva al
Coordinatore. I sistemi di elaborazione dati talvolta tendono a
bloccarsi, per cui e' preferibile che il Coordinatore sappia che
e' una condizione temporanea e che e' accaduta in assenza del
Sysop.
2.4 Come formare un Net.
Se ci sono molti nodi in una determinata area, ma nessun Net,
puo' nascere l'esigenza di crearne uno. Puo' anche essere il Co-
ordinatore Regionale a richiedere la costituzione di un Net. Un
Sysop che voglia farsi promotore della creazione di un nuovo Net
deve seguire questa procedura.
Il primo passo e' quello di entrare in contatto con gli altri
Sysop dell'area, decidere quali nodi faranno parte del Net, e
quale di questi sara' il Coordinatore. Il passo successivo e'
informare il Coordinatore Regionale, attraverso un messaggio
FidoNet contenente le seguenti informazioni:
1) Il numero della Regione, o il numero del Net se un Net si di-
vide, che sono implicati nella formazione del Net. Il Coordi-
natore Regionale dara' notizia ai Coordinatori dei Net inte-
ressati che un nuovo Net e' in creazione.
2) Il nome proposto per il nuovo Net, cercando possibilmente di
scegliere un nome che abbia un nesso con il raggruppamento
come, ad esempio, SoCalNet per i nodi della California del
Sud. Nomi fantasiosi non aiutano ad individuare in quale area
e' collocato il nuovo gruppo.
3) Una copia della lista dei nodi proposta. Il file contenente la
lista deve essere chiamato Frrr-nnn.Net, dove rrr e' il numero
del del Regione o del Net del Coordinatore proposto, mentre
nnn e' il numero del suo nodo. Ad esempio, se il Coordinatore
proposto ha il nodo 5 della Regione 13, il nome del file sara'
F013-005.Net. Il file deve essere inviato come allegato (file
attach) al messaggio di richiesta del numero di Net.
ESEMPIO DI UN FILE Frrr-nnn.Net
Host,xxx,St_Louis_Area, St_Louis_MO,Ken_Kaplan, 1-314-432-4129,2400
Pvt ,076,Ben's_Bakery, Godfrey_IL, Ben_Baker, -Unpublished-, 1200
,482,Dirty_Ole_Man, Wood_Riv_IL,Ervin_Cole, 1-618-254-2763,1200
,010,MDC_RCC, St_Louis_MO,Terry_Mueller, 1-314-232-6881,2400
,016,Mikes_Board, St_Louis_MO,Mike_Mellinger,1-314-726-3448,2400
,022,PCLUG, St_Louis_MO,Ken_Kaplan, 1-314-576-2743,2400
,051,DECUS_Central, St_Louis_MO,Ken_Kaplan, 1-314-432-4129,2400
,339,Midnight_Cnct, St_Louis_MO,Ray_Weil, 1-314-961-1585,1200
Pvt ,492,Neu's_Node, Omaha_NB, Paul_Neu, -Unpublished-, 2400
Pvt ,500,Alex'_Fido, St_Louis_MO,Alex_Hartley, -Unpublished-, 1200
,501,ZIGGY's_Castle,Fenton_MO, Mike_Cravens, 1-314-225-9684,1200
,502,ALADINs_Castle,St_Louis_MO,Bob_Russ, 1-314-741-3050,1200
L'assegnazione di un numero di Net ___ e' automatica. Il Coordi-
natore Regionale analizzera' tale richiesta e rendera' poi note
le sue decisioni. ___ inviare le domande al Coordinatore di Zona
in quanto queste debbono essere elaborate dal Coordinatore Regio-
nale.
SEZIONE 3
PROCEDURE GENERALI PER I COORDINATORI
3.1 Rendere disponibili File di differenza e FidoNews.
Ogni Coordinatore ha il compito di ottenere e rendere disponibi-
le, su base settimanale, i file di differenza della nodelist e le
FidoNews.
3.2 Elaborazione delle nodelist ed inoltro delle stesse.
Ogni Coordinatore ha il compito di raccogliere le variazioni del-
la nodelist dal livello immediatamente inferiore, elaborarle e
passarne il risultato al livello immediatamente superiore. Le
tempistiche di tale processo sono determinate dalle necessita'
imposte dal livello superiore.
3.3 Assicurare la disponibilita' della Policy aggiornata.
Ogni Coordinatore ha il compito di rendere disponibile l'ultima
versione del documento di Policy al livello immediatamente infe-
riore, e stimolare la familiarizzazione con esso.
Deve, inoltre, inviare tutte le integrazioni alla Policy al
livello superiore, e studiare tali documenti. Sebbene non obbli-
gatorio, regole di cortesia impongono il coinvolgimento del
livello superiore nella stesura delle Policy locali.
3.4 Minimizzare il numero delle funzioni.
I Coordinatori sono stimolati a limitare il numero delle funzioni
svolte in ambito FidoNet. Un Coordinatore che mantiene due
posizioni compromette la procedura di appello. Ad esempio se un
Coordinatore di Net e' nel contempo Coordinatore Regionale, ai
Sysop di tale Net viene sottratto un livello di appello.
I Coordinatori sono inoltre invitati a non agire come nodi di
distribuzione software o EchoMail, o di utilizzare un sistema per
tale distribuzione ed un altro per gli incarichi amministrativi.
Il sistema di un Coordinatore dovrebbe essere facilmente disponi-
bile per i livelli immediatamente inferiori e superiori.
Un' altra ragione per scoraggiare la coesistenza di incarichi e'
la difficolta' di coprire i servizi se qualcuno lascia la rete.
Ad esempio, se un Coordinatore e' contemporaneamente nodo distri-
buzione EchoMail e nodo distribuzione software, in caso di sue
dimissioni sarebbe difficile coprire rapidamente tutti e tre gli
incarichi.
3.5 Essere membro dell'area amministrata.
I Coordinatori devono essere membri dell'area amministrata.
I Coordinatori di Net devono risiedere nell'area geografica co-
perta dal Net. I Coordinatori Regionali devono essere membri di
un Net o essere nodi indipendenti di tale Regione.
3.6 Incoraggiare i nuovi Sysop ad entrare nella rete FidoNet.
Ogni Coordinatore e' incoraggiato ad operare un BBS pubblico
liberamente disponibile allo scopo di distribuire la Policy, le
FidoNews e le nodelist a potenziali nuovi Sysop. La diffusione di
informazioni a potenziali Sysop e' importante per la crescita
della rete FidoNet; tutti i Coordinatori dovrebbero incoraggiare
la creazione di nuovi sistemi.
3.7 Tradizioni e precedenti.
I Coordinatori non sono vincolati a seguire le metodologie
impostate dai predecessori.
Inoltre ogni nuovo Coordinatore ha il diritto di rivedere ogni
decisione presa dal suo predecessore se in disaccordo con la
Policy, e prendere ogni azione reputi necessaria per correggere
le situazioni discordanti.
3.8 Gestione Tecnica.
La responsabilita' primaria del Coordinatore e' la gestione
tecnica delle operazioni della rete. Le decisioni debbono essere
prese in base a considerazioni di tipo puramente tecnico.
SEZIONE 4
PROCEDURE PER I COORDINATORI DI NET
4.1 Compiti.
Ogni Coordinatore di Net ha i seguenti compiti:
1) Ricevere i messaggi in arrivo destinati ai nodi del Net ed
organizzarne la distribuzione ai destinatari.
2) Assegnare nuovi numeri ai nodi del Net.
3) Gestire la lista dei nodi del Net, ed inviarne copia al
Coordinatore Regionale in concomitanza di ogni variazione.
4) Rendere disponibili ai nodi del Net i files di differenza
della nodelist, le FidoNews e le nuove revisioni della Po-
licy, cosi' come sono ricevuti, e verificare periodicamente
che i nodi del Net utilizzino versioni aggiornate della
lista dei nodi.
4.2 Inoltro dei messaggi in arrivo.
E' compito del Coordinatore di Net coordinare la ricezione e
l'inoltro dei messaggi host-routed per tutti i nodi del Net. La
scelta del metodo piu' efficiente e' lasciata alla sua discrezio-
ne.
Se un nodo del Net riceve grossi volumi di traffico, il Coordina-
tore puo' chiedere a tale nodo di entrare in contatto con il
sistemi che generano tale traffico e richiedere che questo non
venga instradato attraverso il nodo del Coordinatore. In caso di
persistenza del problema, il Coordinatore di Net puo' richiedere
al Coordinatore Regionale di assegnare al nodo lo status di
'indipendente' e, quindi, escludere il nodo dal Net.
Occasionalmente un nodo puo' effettuare un "bombing run" (ovvero
inviare lo stesso messaggio ad un gran numero di destinatari). Se
un nodo di un altro net effettua un "bombing run" utilizzando
l'instradamento attraverso il Coordinatore, questi puo' presenta-
re una protesta al Coordinatore del net da cui e' partito tale
"bombing run" (o al Coordinatore Regionale, nel caso in cui il
nodo originante sia indipendente). L'invio di "bombing run" e'
considerato comportamento seccante.
Altra fonte di sovraccarico e' l'EchoMail. Non e' consentibile
che il traffico EchoMail possa degradare la capacita' della rete
FidoNet di gestire il normale traffico di messaggi. Se un nodo
del Net gestisce grossi volumi di traffico EchoMail, il Coordina-
tore puo' chiedere al suo Sysop o di limitare la quantita' di
EchoMail gestita, o di terminarne l'istradamento.
Il Coordinatore di Net non e' obbligato ad instradare messaggi
crittografati, commerciali o illegali. Ovviamente e' necessario
seguire le procedure descritte al punto 2.1.7 nel caso non venga
instradato un messaggio.
4.3 Assegnazione dei numeri di nodo.
E' compito del Coordinatori di Net assegnare nuovi numeri di nodo
nell'area assegnata. Il Coordinatore puo' inoltre modificare il
numero a nodi esistenti, previo accordo con i nodi interessati.
Il Coordinatore puo' assegnare qualsiasi numero desideri, purche'
sia unico nell'ambito del Net.
Per assegnare un numero di nodo e' indispensabile che il nodo
richiedente invii un messaggio FidoNet di richiesta originato dal
sistema che chiede l'affiliazione. Il Coordinatore non deve asse-
gnare un numero fino alla ricezione di tale richiesta formale.
Questo assicura che il sistema richiedente e' operativo almeno a
livello minimo. La stretta osservanza di questa norma e' stata
una delle grandi forze della rete FidoNet.
E' anche consigliato, sebbene non richiesto, che il Coordinatore
chiami un BBS che richiede l'affiliazione prima della assegnazio-
ne del numero di nodo.
Il Coordinatore non puo' assegnare numeri di nodo in aree coperte
da Net esistenti. Se un Coordinatore ha nodi in una area coperta
da un Net in formazione, questi debbono essere trasferiti al nuo-
vo Net.
Il Coordinatore dovrebbe comunicare al nuovo Sysop il numero as-
segnato a mezzo messaggio FidoNet, dato che questo prova che il
sistema e' in grado di ricevere messaggi.
Qualora un nodo del net abbia comportamenti seccanti, il Coordi-
natore puo' prendere qualsiasi azione reputi appropriata alle
circostanze.
4.4 Manutenzione della Nodelist.
E' compito del Coordinatore implementare ogni cambiamento (nome,
numero di telefono, etc.) nel proprio segmento della nodelist non
appena possibile dopo aver ricevuto comunicazione delle variazio-
ni dal nodo interessato. Occasionalmente dovrebbe inviare un mes-
saggio ad ogni nodo del Net per verificare che questo sia ancora
operativo. Se un nodo sospende l'attivita' senza preavviso, il
Coordinatore puo' mettere il nodo 'down' o rimuoverlo dalla lista
dei nodi. I nodi dovrebbero essere marcati 'down' per non piu' di
due settimane, dopo questo periodo dovrebbero essere rimossi dal-
la lista.
Il Coordinatore puo', a sua discrezione, distribuire parte di
questo lavoro agli Hub; in questo caso raccogliera' le liste dai
Coordinatori di Hub del suo Net, sara' pero' necessario avere
memorizzata una lista per ogni Hub in quanto e' improbabile che
ogni Coordinatore di Hub invii un aggiornamento alla settimana.
Il Coordinatore di Net deve quindi assemblare una nodelist
dell'intero net ed inviarla al Coordinatore Regionale entro il
termine stabilito. E' consigliabile effettuare questa operazione
il piu' tardi possibile, in modo da inglobare le ultime variazio-
ni, ma evitando il rischio di inviarla troppo tardi al Coordina-
tore Regionale, rinviando in tal modo l'aggiornamento di una set-
timana.
4.5 Rendere disponibili NodeList, FidoNews e Policy.
Il Coordinatore di Net deve ottenere l'aggiornamento della Node-
list e la nuova edizione delle FidoNews ogni settimana dal Co-
ordinatore della sua Regione. Il file di differenze della node-
list e' al momento disponibile ogni sabato, mentre le FidoNews
sono pubblicate il lunedi'. Il Coordinatore deve rendere questi
files disponibili a tutti i nodi della rete, ma e' incoraggiato a
metterli a disposizione di tutti gli utenti per il download.
E' altresi' necessario che ottenga la piu' recente versione del
documento di Policy che vincola i membri del Net. Nuove versioni
sono rilasciate ad intervalli sporadici, quindi e' consigliabile
che il Coordinatore comunichi ai suoi nodi l'avvenuta pubblica-
zione delle nuove Policy e si assicuri che gli stessi nodi acqui-
stino familiarita' con le modifiche apportate.
La Policy, le FidoNews e la nodelist sono la colla che ci tiene
uniti; senza di essi cesseremmo di essere una comunita' per di-
ventare una accozzaglia di Bulletin Boards.
SEZIONE 5
PROCEDURE PER I COORDINATORI REGIONALI
5.1 Compiti.
Un Coordinatore Regionale ha i seguenti compiti:
1) Assegnare nuovi numeri ai nodi indipendenti della Regione.
2) Incoraggiare i nodi indipendenti ad entrare nei Net
esistenti o a formare nuovi Net.
3) Assegnare numeri di net ai Net della Regione e definire le
rispettive aree di influenza.
4) Gestire la lista dei nodi della Regione, ed inviarne copia
al Coordinatore di Zona in concomitanza di ogni variazione.
5) Assicurare la corretta operazione dei Net della propria
Regione.
6) Rendere disponibili ai Coordinatori di Net i files di dif-
ferenza della nodelist, le FidoNews e le nuove revisioni
della Policy, non appena possibile.
5.2 Assegnazione dei numeri di nodo.
E' compito del Coordinatore Regionale assegnare nuovi numeri ai
nodi indipendenti della propria Regione. Previo accordo con i
nodi assegnati il Coordinatore puo' modificare il numero a nodi
esistenti. Il Coordinatore puo' assegnare qualsiasi numero desi-
deri, purche' sia unico nell'ambito del Net.
Per assegnare un numero di nodo e' indispensabile che il nodo
richiedente invii un messaggio FidoNet di richiesta originato dal
sistema che chiede l'affiliazione. Il Coordinatore non deve asse-
gnare un numero fino alla ricezione di tale richiesta formale.
Questo assicura che il sistema richiedente e' operativo almeno a
livello minimo. La stretta osservanza di questa norma e' stata
una delle grandi forze della rete FidoNet.
E' anche consigliato, sebbene non richiesto, che il Coordinatore
chiami un BBS che richiede l'affiliazione prima della assegnazio-
ne del nodo.
Il Coordinatore dovrebbe comunicare al nuovo Sysop il numero as-
segnato a mezzo messaggio FidoNet, dato che questo prova che il
sistema e' in grado di ricevere messaggi.
Qualora un nodo del net abbia comportamenti seccanti, il Coordi-
natore puo' prendere qualsiasi azione reputi appropriata alle
circostanze.
Se un Coordinatore Regionale riceve una richiesta di nodo da un
Sysop esterno all'area della Regione, deve inviare tale richiesta
al Coordinatore piu' vicino al richiedente. Se la richiesta viene
da un nodo che si trova in un'area coperta da un Net esistente la
richiesta deve essere inoltrata al Coordinatore di tale Net.
Se viene a formarsi un Net in un'area in cui sono collocati nodi
indipendenti questi ultimi debbono essere trasferiti al Net non
appena possibile.
5.3 Incoraggiare la creazione e la crescita dei Net.
Uno dei compiti principali del Coordinatore Regionale e' promuo-
vere lo sviluppo dei Net nella Regione.
E' necessario evitare di avere nodi indipendenti che sono
nell'area di copertura del Net. Ci sono, ovviamente, dei casi in
cui un nodo dovrebbe non essere membro di un net, come nel caso
di sistemi che abbiano grande volume di messaggi (vedi il punto
4.2).
Se vari nodi indipendenti nella Regione sono raggruppati e'
necessario che il Coordinatore Regionale li incoraggi (o se
necessario li obblighi) a formare un net; vedi il punto 2.4.
Questo non significa che si debba incoraggiare la creazione di
Net insignificanti: ovviamente un solo nodo non fa un Net. Il
numero esatto di nodi richiesti per la creazione di un Net deve
essere valutato in relazione alle circostanze, ed e' lasciato
alla discrezione del Coordinatore Regionale.
5.4 Assegnazione dei numeri di Net.
E' compito del Coordinatore Regionale di assegnare i numeri ai
nuovi Net che si formano nella Regione; a questo scopo il Coordi-
natore di Zona assegna ad ogni Regione un pool di numeri. Come
parte di questa funzione e' altresi' compito del Coordinatore
Regionale definire i confini e le aree di influenza dei vari Net.
5.5 Manutenzione della lista dei nodi.
Il Coordinatore Regionale ha un doppio compito nella manutenzione
della lista dei nodi della Regione.
Innanzitutto deve tenere la lista dei nodi indipendenti della
Regione, implementando tutti i cambiamenti (nomi, numeri telefo-
nici) non appena possibile dopo esserne venuto a conoscenza dai
nodi interessati. Occasionalmente dovrebbe inviare un messaggio
ad ogni nodo indipendente in modo da verificarne l'operativita'.
Se un nodo sospende le operazioni senza preavviso puo' essere
marcato come 'down' o essere rimosso dalla lista. Da notare che i
nodi dovrebbero rimanere 'down' per un massimo di due settimane e
dopo tale periodo essere rimossi dalla lista.
Poi il Coordinatore deve ricevere le nodelist dai Coordinatori
dei Net della Regione. E' necessario che mantenga una copia della
lista dei nodi di ogni Net essendo improbabile che ogni Coordina-
tore di Net invii un aggiornamento ogni settimana. Deve poi
assemblare settimanalmente una lista globale della Regione ed
inviarla al Coordinatore di Zona entro il termine prefissato.
E' consigliabile effettuare questa operazione il piu' tardi pos-
sibile, in modo da inglobare le ultime variazioni, ma evitando il
rischio di inviarla troppo tardi al Coordinatore Regionale,
rinviando gli aggiornamenti di una settimana.
5.6 Eccezioni Geografiche.
Vi sono casi in cui la geografica 'telefonica' non segue la
distribuzione delle Regioni FidoNet. In casi eccezionali e' pos-
sibile stabilire delle eccezioni alla regola generale, previo
accordo dei Coordinatori delle Regioni e della Zona interessati.
Queste eccezioni non sono un diritto e non sono permanenti. Nel
caso della creazione di un Net nell'area in cui e' collocato il
nodo esentato, l'eccezione viene a terminare. Tutte le eccezioni
possono essere rivedute e revocate in ogni momento da uno dei
Coordinatori interessati.
5.7 Supervisione delle operazioni dei Net.
Il Coordinatore della Regione ha il compito di nominare i Coordi-
natori dei Net della sua Regione. Se un Coordinatore di Net
dimissionario indica un successore, il Coordinatore Regionale non
e' obbligato ad accettarlo, sebbene la prassi normale sia questa.
Allo stesso modo non e' obbligato ad accettare una persona eletta
dai membri di un net, nonostante sia prassi normale.
Ha inoltre il compito di assicurare che i Net della Regione ope-
rino in maniera accettabile. Questo non significa che debba
coordinare direttamente il Net, essendo cio' compito del Coordi-
natore di Net, ma di assicurarsi che questi ultimi svolgano il
loro compito con responsabilita'.
Nel caso che il Coordinatore di un Net non svolga correttamente i
compiti delineati nella sezione 4, il Coordinatore della Regione
puo' prendere ogni azione reputi valida per correggere la situa-
zione.
Se un Net raggiunge dimensioni tali da non poter ragionevolmente
smaltire il traffico mail durante la ZMH, il Coordinatore Regio-
nale puo' decretarne la suddivisione in due o piu' Net. Questi
nuovi Net, anche se ricadenti nella stessa area telefonica debbo-
no comunque ispirarsi a criteri di suddivisione geografica nella
determinazione delle affiliazioni.
Il Coordinatore Regionale e' obbligato a mantenere diretti e
ragionevolmente frequenti contatti con i Net della Regione. Il
metodo esatto per raggiungere tale risultato e' lasciato alla sua
discrezione.
5.8 Rendere disponibili Nodelist, FidoNews e Policy.
Il Coordinatore Regionale deve ottenere l'aggiornamento della
Nodelist, la nuova edizione delle FidoNews ed ogni aggiornamento
della Policy non appena pubblicati, e renderli disponibili ai
Coordinatori dei Net della Regione. La nodelist e' pubblicata
ogni sabato dal Coordinatore di Zona, mentre le FidoNews sono
pubblicate il lunedi' dal nodo 1:1/1. Per avere maggiori informa-
zioni e' necessario entrare in contatto i succitati nodi.
Il metodo di distribuzione di tali files e' lasciato alla discre-
zione del Coordinatore. L'obbligo non si estende ai nodi
indipendenti della Regione. I Coordinatori Regionale sono
incoraggiati a rendere questi documenti disponibili per il
download da parte del pubblico.
SEZIONE 6
PROCEDURE PER I COORDINATORI DI ZONA
6.1 Generalita'.
Un Coordinatore di Zona ha il compito primario di effettuare la
manutenzione della lista dei nodi della Zona, inviarla ai Coordi-
natori delle altre Zone e assicurare la distribuzioni della lista
principale dei nodi (e dei file di differenza) ai Coordinatori
delle Regioni della Zona. Il Coordinatore di Zona ha anche il
compito di coordinare la distribuzione dei documenti di Policy
FidoNet e delle FidoNews ai Coordinatori delle Regioni della Zo-
na.
Il Coordinatore di Zona ha il compito di gestire la lista dei
nodi amministrativi della Regione. Un nodo amministrativo ha lo
stesso numero della Zona, e consiste di nodi assegnati per scopi
amministrativi, cioe' diversi dall'invio o dalla ricezione di
normali messaggi mail.
Il Coordinatore di Zona ha la responsabilita' di assicurare il
corretto funzionamento della Zona; e cio' e' ottenuto nominando i
Coordinatori Regionale ed effettuando la supervisione della loro
attivita'.
Se il Coordinatore di Zona determina che un Coordinatore Regiona-
le non svolge correttamente i propri compiti, delineati nella
sezione 5, e' necessario trovarne un sostituto.
Il Coordinatore di Zona definisce i confini geografici delle Re-
gioni nell'ambito della Zona e fissa la ZMH per la sua Zona.
Il Coordinatore di Zona ha il compito di analizzare ed approvare
ogni richiesta di esenzione geografica descritta al punto 5.6.
Il Coordinatore di Zona e' responsabile del corretto funzionamen-
to dei gates tra la sua Zona e le altre per il trasferimento dei
messaggi interzonali..
I Coordinatori di Zona hanno il compito di eleggere il Coordina-
tore Internazionale, selezionandolo tra i propri ranghi.
6.2 Elezione.
Il Coordinatore di Zona e' eletto a maggioranza assoluta dei voti
dei Coordinatori delle Regioni della Zona.
SEZIONE 7
PROCEDURE PER IL COORDINATORE INTERNAZIONALE
7.1 Generalita'.
Il Coordinatore Internazionale e' il Coordinatore di Zona "primo
tra pari", suo compito primario e' il coordinamento della
creazione della lista principale dei nodi gestendo la distribu-
zione della lista di ogni Zona. Il Coordinatore Internazionale ha
il compito di definire le nuove Zone e di negoziare gli accordi
per la comunicazione con altre reti.
Il Coordinatore Internazionale ha anche il compito di coordinare
la distribuzione delle Policy e delle FidoNews ai Coordinatori di
Zona, di coordinare le attivita' dello Zone Coordinator Council,
e di agire come portavoce di questo organismo, di esprimere
interpretazioni specifiche o estensioni di questa Policy nei casi
non coperti da questo documento. Lo Zone Coordinator Council puo'
annullare tali pronunciamenti con votazione a maggioranza.
7.2 Elezione.
Il Coordinatore Internazionale e' eletto (e rimosso) con votazio-
ne a maggioranza assoluta dai Coordinatori di Zona.
SEZIONE 8
PROCEDURE DI REFERENDUM
Le procedure di seguito descritte vengono utilizzate per ratifi-
care una nuova versione della Policy, qualunque sia la causa di
modifica del documento stesso. La stessa procedura e' anche uti-
lizzata per la destituzione di un Coordinatore di Zona.
8.1 Istituzione.
Per istituire un referendum sulla modifica del documento di Poli-
cy e' necessario che la maggioranza dei Coordinatori Regionali
FidoNet comunichino al Coordinatore Internazionale che desiderano
valutare la proposta di una nuova versione del documento di Poli-
cy.
8.2 Proclamazione e notifica dei risultati.
Le modifiche proposte vengono diffuse attraverso la stessa strut-
tura che e' utilizzata per la distribuzione dei files di
differenza e delle FidoNews. I risultati e le proclamazioni con-
nesse al referendum sono distribuiti dalla struttura di coordina-
mento come parte del file settimanale di differenza (nodediff).
Il Coordinatore Internazionale provvedera' inoltre alla pubblica-
zione sulle FidoNews, sebbene le proclamazioni ufficiali e le
date di votazione sono legate alla distribuzione della nodelist.
Allo stesso modo il Coordinatore Internazionale fissa la data di
entrata in vigore per le proposte accettate, dandone comunicazio-
ne attraverso il file settimanale di differenza; tale data deve
essere collocata nel mese che segue la chiusura delle votazioni.
8.3 Diritto di Voto.
Ogni membro della struttura di coordinamento a partire dal
Coordinatore di Net ha diritto ad un voto (non votano i Coordina-
tori di Hub). Nel caso di trapasso di funzioni nel periodo di
votazione il diritto di voto spetta o al vecchio o al nuovo Co-
ordinatore, ma mai ad entrambi. Se una persona ha piu' di un
incarico di coordinamento ha diritto comunque ad un solo voto.
I Coordinatori di Net debbono esprimere le opinioni dei membri
del loro net, e votare di conseguenza. Non e' richiesta una
elezione formale, ma i Coordinatori debbono informare il net del-
la votazione in atto, e sollecitarne i commenti. Il Coordinatore
ha la funzione di rappresentante della base FidoNet.
8.4 Meccanismo di Voto.
L'effettivo meccanismo di voto (voto segreto o no, metodi di rac-
colta, verifica e conteggio dei voti) sono lasciate alla
discrezione del Coordinatore Internazionale. Idealmente la rac-
colta dovrebbe essere effettuata attraverso un sistema di messag-
gi protetto, gestito sulla rete FidoNet.
Per consentire un equo tempo di dibattito, l'annuncio di ogni
votazione deve essere fatto almeno due settimane prima della data
prevista per la votazione. Il periodo di voto deve essere di
almeno due settimane.
8.5 Votazione di un intero documento di Policy.
Una relativamente semplice variazione alla Policy puo' portare, a
causa della complessita' della sua struttura, a profonde altera-
zioni del documento. Per semplificare le cose la votazione viene
effettuata sulla base dell'intero documento e non su ogni singolo
emendamento. Nel caso piu' semplice questo significa votare si o
no al documento. Se debbono essere scelte varie alternative,
queste debbono comunque essere presentate come interi documenti,
tra cui sceglierne uno solo.
8.6 Decisione del voto.
Un emendamento alla Policy e' considerato approvato se, alla fine
del periodo di voto, ha ricevuto la maggioranza dei voti espres-
si. Ad esempio se su una base di 350 aventi diritto 100 esprimono
un voto, sono richiesti 51 voti favorevoli per approvare l'emen-
damento.
Nel caso di cambiamenti multipli da valutare nella stessa vota-
zione, una delle versioni deve ricevere comunque oltre il 50% dei
voti per essere considerata approvata. "Astenuto" e' un voto va-
lido ed e' in effetti a favore del mantenimento della Policy in
vigore, in quanto aumenta il numero dei voti richiesti per l'ap-
provazione delle modifiche.
8.7 Destituzione di un Coordinatore di Zona.
8.7.1 Istituzione.
In casi estremi un Coordinatore di Zona puo' essere destituito
per referendum. La destituzione non e' legata alla violazione
della Policy. La procedura di destituzione e' avviata da una ri-
chiesta al Coordinatore Internazionale da parte della maggioranza
dei Coordinatori della Zona.
8.7.2 Procedura.
I punti 8.2 e 8.3 si applicano anche in questo caso, cosi' come
la definizione di "maggioranza" del punto 8.6. Hanno diritto al
voto solo i Coordinatori della Zona interessata, anche se il Co-
ordinatore di Zona e' anche Coordinatore Internazionale.
8.7.3 Meccanismo di voto.
Le procedure di voto sono definite ed espletate da un Coordinato-
re Regionale scelto dal Coordinatore di Zona di cui si chiede la
destituzione; questa diviene operativa due settimane dopo il ter-
mine del voto, ovviamente se questo ha esito positivo.
8.7.4 Limite annuale.
La rimozione di un Coordinatore di Zona e' un meccanismo con cui
la rete puo' esprimere la disapprovazione verso il metodo di
interpretazione della Policy. D'altro canto c'e' sempre un momen-
to, prima o poi, in cui ognuno e' insoddisfatto di tale interpre-
tazione. Per tenere le cose equilibrate e' imposto un limite mas-
simo di una votazione per anno solare, indipendentemente da quan-
te persone occupino la posizione di Coordinatore di Zona durante
tale periodo.
Se un Coordinatore di Zona dovesse rassegnare le dimissioni
durante lo svolgimento della procedura di destituzione, questa e'
da considerarsi nulla e quindi non intacca la "quota annuale".
SEZIONE 9
RISOLUZIONE DELLE DISPUTE
9.1 Generalita'.
La filosofia di giudizio FidoNet puo' essere riassunta in due
regole:
1) Non si deve disturbare troppo gli altri.
2) Non ci si deve seccare troppo facilmente.
In altre parole non ci sono regole rigide da seguire, ma si at-
tende da tutti un comportamento corretto. Inoltre in ogni disputa
________ le parti vengono esaminate, ed una azione puo' essere
intrapresa sia verso una sola che verso entrambe le controparti.
La struttura di coordinamento ha il compito di definire il "com-
portamento troppo seccante". Come la definizione comune di
'pornografia' ("non e' delineabile, ma si riconosce a vederla"),
non e' possibile fornire una definizione semplice ed efficace del
comportamento FidoNet. Le norme generali di questa Policy sono
deliberatamente vaghe, per dare la liberta' che la struttura di
coordinamento richiede per poter rispondere alle richieste di una
struttura che cresce e cambia.
Il primo passo da compiere in qualsiasi disputa tra Sysop e' di
cercare di comunicare direttamente, almeno via netmail, ma pre-
feribilmente a voce. Tutte le proteste formali che trascurano
questo primo importante passo saranno rigettate.
L'invio di una protesta formale non e' una azione da prendere con
leggerezza. Le indagini e le risposte alle proteste richiedono
tempo che il Coordinatore preferirebbe passare espletando attivi-
ta' piu' costruttive. L'invio continuo di proteste banali puo'
mettere l'estensore dalla parte del torto. Le proteste, inoltre,
debbono essere accompagnate da prove verificabili, generalmente
copie di messaggi.
La mancata osservanza delle procedure descritte (in particolare
il saltare un Coordinatore o coinvolgerne uno non facente parte
della catena gerarchica) e' di per se comportamento seccante.
9.2 Problemi con altri Sysop.
In caso di problemi con altri Sysop la prima cosa da fare e'
entrare in contatto, via matrix o a voce, con l'altro Sysop.
Se questa mossa non sortisce effetti e' necessario inviare una
protesta formale al Coordinatore del Net (o ai Coordinatori dei
Net, nel caso l'altro Sysop non faccia parte dello stesso Net);
nel caso si tratti di un nodo indipendente la competenza e' del
Coordinatore Regionale. Se questo metodo non e' risolutore e'
possibile proseguire con la procedura descritta al punto 9.5.
9.3 Problemi con il Coordinatore del Net.
Come per tutte le dispute, il primo passo e' entrare in contatto
diretto con il Coordinatore.
Il secondo passo e' entrare in contatto con il Coordinatore della
Regione. Se il caso lo giustifica, vi sono molte azioni che e'
possibile intraprendere, come la sostituzione del Coordinatore
del Net o lo scioglimento del Net. In caso di scomunica, la deci-
sione puo' essere annullata ed il nodo reintegrato nel Net.
Se questo metodo non e' risolutore e' possibile proseguire con la
procedura descritta al punto 9.5.
9.4 Problemi con altri Coordinatori.
Le proteste riguardanti comportamenti scorretti da parte dei
Coordinatori sono trattate come al punto 9.2 e debbono essere
inviati al Coordinatore di grado immediatamente superiore. In
caso di comportamento scorretto del Coordinatore Regionale, ad
esempio, la protesta deve essere inviata al Coordinatore di Zona.
Proteste riguardanti il corretto espletamento dei compiti imposti
dalla Policy sono accettati solo dal livello immediatamente infe-
riore. Ad esempio le proteste riguardanti la funzionalita' del
Coordinatore Regionale saranno accettati solo da uno dei
Coordinatori di Net della Regione. Queste proteste dovrebbero
essere indirizzate al Coordinatore della Zona dopo ragionevoli
tentativi di risoluzione locale a mezzo contatti diretti.
9.5 Procedura di appello.
Ogni decisione presa da un Coordinatore puo' essere appellata al
livello superiore. Gli appelli debbono essere presentati entro
due settimana dalla decisione a cui si riferiscono, e devono
seguire la catena di coordinamento, pena il rigetto.
Gli appelli non sono basati su indagini, ma sulla documentazione
fornita dalle parti del livello inferiore. Ad esempio un appello
ad una decisione del Coordinatore di Net sara' inoltrato al Coor-
dinatore di Regione che basera' la sua decisione sulle informa-
zioni fornite dal Coordinatore di Net e dai Sysop interessati.
La struttura di appello e' la seguente:
* per le decisioni del Coordinatore di net l'appello deve essere
inoltrato al Coordinatore Regionale.
* per le decisioni del Coordinatore Regionale l'appello deve
essere inoltrato al Coordinatore di Zona. Questi prendera' una
decisione che sara' comunicata ai Coordinatori Regionali della
Zona. Questa decisione puo' essere annullata da un voto a mag-
gioranza dei Coordinatori Regionali.
* per le decisioni del Coordinatore di Zona l'appello deve esse-
re inoltrato al Coordinatore Internazionale. Questi Zona
prendera' una decisione che sara' comunicata allo Zone Coordi-
nator Council, che puo' annullarla con una votazione a maggio-
ranza.
9.6 Limitazioni.
Una protesta formale non puo' essere inviata piu' di 60 giorni
dopo la data della scoperta della causa dell'infrazione, sia per
ammissione che per evidenza tecnica, o 120 giorni dopo un
incidente, sempre che non riguardi espliciti comportamenti
illegali.
9.7 Diritto ad una decisione rapida.
Ogni Coordinatore deve prendere una decisione finale e comunicar-
la agli interessati entro 30 giorni dal ricevimento della
protesta o della richiesta di appello.
9.8 Ritorno al Net originario.
Dopo la risoluzione della disputa ogni nodo ripristinato in ap-
pello deve ritornare al net locale o alla Regione a cui appartie-
ne, geograficamente o tecnicamente.
9.9 EchoMail.
L'EchoMail e' una forza importante ed efficace nella rete
FidoNet. Ai fini delle dispute riguardanti la Policy l'EchoMail
e' da considerarsi una tipo particolare di netmail, ed e' quindi
coperta dalla Policy. A causa della sua natura l'EchoMail ha
risvolti sociali e tecnici che vanno oltre quanto previsto in
questo documento. A causa di queste considerazioni I Coordinatori
FidoNet riconoscono una Policy EchoMail (che estende
e non contraddice la Policy generale, che viene gestita dai
Coordinatori EchoMail e approvata con procedimento simile a quel-
lo previsto per questo documento) come valida struttura per la
risoluzione delle dispute che hanno come oggetto l'EchoMail. In
futuro la Policy EchoMail potra' essere fusa con questo documen-
to.
9.10 Casistica.
La maggior parte della Policy FidoNet e' soggetta ad interpreta-
zione. Nessuno puo' prevedere il futuro in un ambiente, come il
nostro, cosi' soggetto ad evoluzione. La Policy stessa e' solo
uno degli elementi utilizzati per la mediazione delle dispute.
Per seguire tale evoluzione, singoli esempi casistici possono
essere rimossi o aggiunti dal Coordinatore Internazionale, con
possibilita' annullamento di tali decisioni da parte dello Zone
Coordinator Council. Nel caso la Policy sia emendata in modo da
invalidate uno di questi precedenti, la Policy ha ovviamente pre-
valenza sul 'caso'.
Sebbene l'esempio casistico possa essere rimosso, il testo non
puo' esserne in alcun modo alterato. Tali note, infatti, sono
state scritte al tempo della decisione, dalle persone interessa-
te. Modificare un caso equivarrebbe a riscrivere la storia, cosa
non appropriata per una organizzazione che ha lo scopo di trasfe-
rire informazioni.
SEZIONE 10
APPENDICI
10.1 Generalita'.
Le appendici di questo documento sono eccezioni alla normale pro-
cedura di ratifica. Il punto 10.2 puo' essere modificato dal Co-
ordinatore di Zona di competenza, mentre il 10.3 dal Coordinatore
Internazionale (vedi il punto 9.10).
10.2 Orari della Zone Mail Hour.
La Zone Mail Hour e' osservata tutti i giorni, sabato e festivi-
ta' inclusi. L'ora e' basata sull' Universal Coordinated Time
(UTC) detto anche Greenwich Mean Time (GMT). Nelle aree che os-
servano l'ora legale la ZMH (misurata in ora locale) slitta as-
sieme alla variazione dell'ora. L'orario esatto della ZMH e' de-
finito singolarmente per ogni Zona dal rispettivo Coordinatore.
Nella Zona 1 FidoNet la ZMH e' osservata dalle 09:00 alle 10:00
GMT.
Nella Zona 2 FidoNet la ZMH e' osservata dalle 02:30 alle 03:30
GMT.
Nella Zona 3 FidoNet la ZMH e' osservata dalle 18:00 alle 19:00
GMT.
10.3 Casistica.
Questa casistica su dispute passate sono esempio per mostrare
metodi e procedure generali. Ogni pronunciamento puo' essere
incluso in questo documento a maggioranza dei voti dello Zone
Coordinator Council o dei Coordinatori Regionali.
La Policy4 ha imposto cambiamenti notevoli alle funzioni dei Co-
ordinatori di Zona ed internazionali. Nei casi seguenti, le cui
decisioni sono state prese sulla base della Policy3, e' necessa-
rio sostituire "Coordinatore di Zona" ad ogni "Coordinatore In-
ternazionale (*)".
10.3.1 Il caso del nodo disonesto.
Un Sysop di un nodo locale utilizzava la mail per effettuare at-
tivita' lavorative eticamente discutibili. Il Coordinatore del
suo Net si secco' non poco, e cancello' il nodo dalla sua lista
dei nodi.
Il nodo si appello' al Coordinatore Regionale per avere l'asse-
gnazione di un nodo indipendente. Il Coordinatore Regionale, dopo
aver consultato il Coordinatore di Net, decise questi aveva ope-
rato correttamente, e rifiuto' lo status di nodo indipendente.
Il Coordinatore Internazionale (*) non intervenne.
10.3.2 Il caso del furto via mail.
Il Sysop di un nodo locale faceva uso di file attach ad utenti
extra per farsi inviare il file USER.BBS da vari BBS locali. I
Sysop di questi BBS si adirarono, e fecero appello al Coordinato-
re del Net, che fu solidale con questi e cancello' il nodo dalla
lista dei nodi.
Il Coordinatore Regionale non fu consultato.
Il Coordinatore Internazionale(*) non intervenne.
10.3.3 Il caso del Sysop seccato.
Un nodo locale si secco' del fatto che il Coordinatore del suo
Net offriva scarsa assistenza. Ripetute istanze non ottennero i
risultati voluti, cosi' decide di portare la questione all'atten-
zione del Coordinatore Internazionale(*).
Il Coordinatore Internazionale(*), vedendo che il Coordinatore
Regionale non era stato consultato, rigetto' la richiesta.
Il nodo locale sottomise la questione al Coordinatore Regionale,
che indago' sulla vicenda e scopri' che c'era una base di veri-
ta'. Entro' in contatto con il Coordinatore del Net e l'aiuto' a
configurare il suo sistema in maniera da migliorare il funziona-
mento del suo nodo.
Il Coordinatore Regionale decise inoltre che il nodo locale si
era adirato stato troppo facilmente, dato che richiedeva servizi
normalmente non richiesti ad un Coordinatore di Net. Al nodo lo-
cale vennero fatti presente quali fossero i doveri di un Coordi-
natore di Net, e gli fu richiesto di limitare le aspettative.
10.3.4 Il caso dello stacanovista.
Un nodo locale, gestito da una azienda commerciale, aveva inizia-
to ad inviare messaggi a tutto spiano per inviare pubblicita'
commerciale sulla rete FidoNet. Questo disturbo' molto il Coordi-
natore del suo Net, dato che non voleva gestire il traffico di
una operazione commerciale, e chiese al nodo di lasciare il Net.
Il nodo locale si rivolse al Coordinatore Regionale, e gli fu
assegnato lo status di nodo indipendente nella Regione.
10.3.5 Il segno del Diavolo.
Un Sysop locale, il cui sistema era utilizzato per supporto a
riti voodoo, hacking, diffusione di materiale osceno, chiese al
Coordinatore del Net un numero di nodo. Il Coordinatore decise
che tale sistema fosse inadatto, e nego' il numero.
Il Coordinatore Regionale non venne consultato.
Il Coordinatore Internazionale(*), constatato che il Coordinatore
Regionale non era stato consultato, rigetto' il caso.
10.3.6 Il caso del Sysop sciocco.
Un utente di vari nodi locali era stato riconosciuto da tutti i
Sysop come uno sciocco. L'utente mise in funzione un proprio
sistema, divenne Sysop e fece richiesta di un numero di nodo. Il
Coordinatore del Net rifiuto' la richiesta. Non venne inoltrato
appello.
10.3.7 Il caso del sovraccarico EchoMail.
Un nodo locale si innamoro' dell'EchoMail e si associo' a molte
conferenze, trasferendo i suoi dati attraverso il Net. Avvio' una
conferenza e inizio' a inviare l'EchoMail a molti sistemi, sempre
attraverso il suo Net.
Il Coordinatore del suo Net osservo' che le prestazioni del Net
erano seriamente compromesse, e venne raggiunto un compromesso:
la maggior parte del traffico non venne piu' trasferita via Net,
mentre il numero dei messaggi transitanti per il Net venne limi-
tata a venti per notte. Non furono fatti appelli.
10.3.8 Il caso del sistema inaffidabile.
Un utente locale decide di impiantare un nodo per promuovere una
meritevole opera di carita'. Il calcolatore era utilizzato duran-
te il giorno per altre varie attivita', ed il Sysop era spesso
fuori sede. I suoi aiutanti dimenticavano frequentemente di met-
tere in funzione il BBS alla fine della giornata, cosi' molte
volte il sistema era fuori servizio per lunghi periodi. Il
Coordinatore del Net, vedendo che il nodo non era in grado di
ricevere dati, lo metteva down. Il Sysop, una volta ritornato,
riavviava il sistema e chiedeva di essere reinserito come nodo.
Il Coordinatore del Net alla fine decise che il Sysop non era in
grado di gestire il sistema in maniera affidabile, e lo rimosse
dalla lista dei nodi definitivamente. Le successive richieste da
parte dello stesso Sysop vennero rifiutate. Non furono inoltrati
appelli.
[Integrazione italiana (Region 33)]