bbsfidonet

bbsfidonet #020

bbsfidonet@gmail.com (Vicente Fons) — Sat, 4 Aug 2007 18:02:00 +0200

Hoy vamos a hablar sobre FIC BBS que está situada en la Facultad de Informática de La Coruña en España

Su Sysop actual es Emilio J. Padrón

FiC BBS forma parte de FidoNet como nodo 2:348/105. También es el nodo 9:348/105 de VirNet, y el 13:348/1 de FiCNet, su propia red

Existen muchas formas de acceder a FiC BBS. La más clásica es como punto, usando un mailer y programas específicos para redes FTN. Como ayuda, Fic BBS cuenta con paquetes de punto preconfigurados. También se puede encontrar más información sobre cómo hacerse punto.

Otra forma de acceder a Fic BBS es a través de news (o grupos de noticias).

Tal vez la forma más sencilla de acceder a Fic BBS es vía web, usando cualquier navegador.

FiC BBS recibe varias áreas de ficheros de las redes FidoNet y VirNet. De Fido llegan sobre todo ficheros administrativos (nodelists, normas, etc.), mientras que VirNet distribuye software antivirus. Aunque no se sea punto de esas redes, se pueden acceder a los ficheros desde Fic BBS.

Desde finales del 2004, FiC está montado sobre un Digital Server 3200, con dos procesadores Pentium II a 266 Mhz y 128 MB de RAM. Como software de base se usa Debian GNU/Linux, y en particular, para lo que es la BBS, programas del proyecto Husky, además de Ifmail para el gate de news, News-Portal para el acceso web, y Binkd como mailer vía Internet.

Típicamente, un punto utiliza tres programas. Un lector o editor de correo, que es con el que lee y escribe los mensajes, un tosser, para empaquetar el correo que envía y desempaquetar el que recibe, y un mailer, para llamar a la BBS (para enviar y recibir los paquetes de correo).

Seguramente el editor más popular sea el GoldED, o su variante el GoldED+. Entre los tossers estarían el Crashmail y el HPT. Se puede usar casi cualquier mailer para conectar con FiC, tanto al estilo clásico (por RTB), llamando al teléfono (+34)-981-167162, como a través de Internet, usando los protocolos raw de ifcico (puerto 60179), telnet/vmodem (puerto 60177), o el popular binkp. Este último lo soporta el Binkd. También, comentar que existe un paquete de punto para Windows, que integra editor, tosser y mailer, el APoint.

Para ampliar informaciónsobre esta BBS, visitar su web en http://www.ficbbs.org

bbsfidonet #019

bbsfidonet@gmail.com (Vicente Fons) — Wed, 1 Aug 2007 11:30:00 +0200

Hola a todos de nuevo,

Esto es bbsfidonet en su episodio número 19 para el 2 de Agosto de 2007

Ante todo y primeramente pedirles disculpas por el largo paréntesis en la publicación, pero además de problemas personales, he intentado hacer alguna entrevista a un par de sysops de BBS para que les ilustraran de primera mano sobre sus BBS, pero ha sido imposible, así que voy a intentar de irles presentando algunas BBS, su forma de acceso, sus características principales y desde aquí invito a cualquier sysop a ponerse en contacto conmigo para realizar una entrevista vía Skype charlando sobre su BBS.

Y vamos ya con la BBS de hoy.

Se trata de Hidrasoft BBS que está situada en Brasil.

Su Sysop es Renato Zambon y está afiliada a las redes RBT y a FidoNet.

Tiene servicios de BBS, Fax y Mailer vía telefónica con el prefijo 5511 y número 4564-2024

Tambien se puede acceder por telnet en hidrasoft.dyndns.org

Se puede acceder a la BBS como Visitante o Guest sin necesidad de resgistrarse previamente, aunque supongo que el acceso de esta forma será limitado.

Dispone de servicio QWK/BlueWave para acceso off-line.

Mas de 1000 áreas de mensajes en Brasileño, Español, Aleman y otros lenguajes.

Echomail y Ficheros de FidoNet.

Juegos: GlobalWar, Lord y Teos

Download totalmente libre y gratuito sin necesidad de obligación de subir nada ni imposición de ratios.

El idioma es el Portugués y también el Ingles.

Y esto es todo por hoy. Gracias a todos los que han permanecido con el RSS activo durante todo este tiempo.

BBSFidonet volvió y está disponible como siempre en http://bbsfidonet.info

Se pueden poner en contacto conmigo en la dirección electrónica: bbsfidonet@gmail.com

Hasta el próximo episodio.

bbsfidonet #018

bbsfidonet@gmail.com (Vicente Fons) — Sun, 1 Oct 2006 10:54:00 +0200

10 Apéndices

10.1 Generalidades

Los Apéndices de éste documento son excepciones al proceso
normal de ratificación. La sección 10.2 puede ser modificada por
el Coordinador de Zona apropiado, y la sección 10.3 puede ser
modificada por el Coordinador Internacional (vea la Sección 9.10).

10.2 Período de la Hora de Correspondencia de la Zona (ZMH)

La Hora de Correspondencia de la Zona (ZMH) se observa
todos los días, inclusive durante los fines de semana y días
festivos y feriados.
La hora se establece en base al Tiempo Universal
Coordinado (UTC en inglés), también conocido como tiempo del
Meridiano de Greenwich (GMT en inglés).
En áreas que observen Períodos de Ahorro de Luz Solar
(Daylight Saving) durante parte del año, la hora local
correspondiente a la Hora de Correspondencia de la Zona (ZMH)
cambiará, porque FidoNet no observa dichos períodos. El momento
exacto de la Hora de Correspondencia de Zona es dispuesto, para
cada zona, por el Coordinador de Zona.
En la Zona 1 de FidoNet, la Hora de Correspondencia de la
Zona es observada desde las 0900 hasta las 1000 UTC. En cada una
de las zonas de tiempo, esto se traduce en:

Tiempo Estándar Oriental 4 A.M. a 5 A.M.
Tiempo Estándar Central 3 A.M. a 4 A.M.
Tiempo Estándar Cordillerano 2 A.M. a 3 A.M.
Tiempo Estándar del Pacífico 1 A.M. a 2 A.M.
Tiempo Estándar de Hawai 11 P.M. hasta Medianoche

En la Zona 2 de FidoNet, la Hora de Correspondencia de la
Zona es observada desde las 0230 hasta las 0330 UTC.

En la Zona 3 de FidoNet, la Hora de Correspondencia de la
Zona es observada desde las 1800 hasta las 1900 UTC.
En cada una de las Zonas de tiempo involucradas esto es:

GMT +12 Zona 6:00 A.M. a 7:00 A.M.
(Nueva Zelandia)

GMT +10 Zona 4:00 A.M. a 5:00 A.M.
(Australia Oriental)
(Papua Nueva Guinea)
(Micronesia)

GMT +9.5 Zona 3:30 A.M. a 4:30 A.M.
(Australia Central)

GMT +9 Zona 3:00 A.M. a 4:00 A.M.
(Japón)
(Corea)
(Indonesia Oriental)

GMT +8 Zona 2:00 A.M. a 3:00 A.M.
(Hong Kong)
(Taiwan )
(Indonesia Central)
(Filipinas)

GMT +7 Zona 1:00 A.M. a 2:00 A.M.
(Malasia)
(Singapur)
(Tailandia)
(Australia Occidental)
(Indonesia Occidental)

10.3 Historias De Casos

Las historias de casos de disputas del pasado son
instructivas para mostrar la aplicación de los procedimientos y
métodos generales.
Cualquier decisión puede ser incluida en éste documento
por un voto mayoritario; ya sea del Consejo de Coordinadores de
Zona o bien por los Coordinadores Regionales.
El Reglamento 4 cambia significativamente las funciones
del Coordinador de Zona y de los Coordinadores Internacionales.
En los siguientes casos, que fueron decididos utilizando
el Reglamento 3, sustituya "Coordinador Internacional" por
"Coordinador de Zona" en todos los casos.

10.3.1 El Caso del Nodo Pícaro (Crooked Node)

El operador de un nodo local utilizó NetMails para
dedicarse a prácticas comerciales faltas de ética.
El Coordinador de la Red se sintió muy perturbado por esta
actitud, y dio de baja del NodeList al nodo local.
El nodo local apeló al Coordinador Regional para que se le
asignara el status de nodo independiente.
El Coordinador Regional, después de consultar con el
Coordinador de la Red, decidió que el mismo tuvo razón al estar
perturbado. El status de nodo independiente le fue denegado.
El Coordinador Internacional (*) no intervino.

10.3.2 El Caso del "Hacker" del Correo (Hacker Mailer)

El operador de un nodo local hizo uso de archivos adosados
o "file attaches" para conseguir enviarse a sí mismo el archivo
USER.BBS (N. del T.: en este archivo, algunos programas, almacenan
la información sobre los usuarios del BBS: datos personales,
contraseña, etc.). de varios tableros locales (BBS). Los
operadores de estos tableros (BBS) se sintieron perturbados por
éste comportamiento, y llamaron la atención a su Coordinador de
Red, que decidió dar de baja del NodeList al nodo ofensor.
El Coordinador Regional no fue consultado.
El Coordinador Internacional (*) no intervino.

10.3.3 El Caso del Nodo Quejoso (Bothered Barker)

Un nodo local se consideró perturbado con su Coordinador
de Red por fallar en proveerle servicios. Las respuestas del
Coordinador de Red a sus quejas reiteradas no le satisficieron, de
modo que llamó la atención al Coordinador Internacional (*).
El Coordinador Internacional (*) desestimó la queja
debido a que el Coordinador Regional no había sido consultado.
El nodo local presentó la queja a su Coordinador Regional,
que investigó el caso y descubrió que había algo de justicia en la
queja. Aconsejó y ayudó al Coordinador de Red a configurar su
sistema para proveer un mejor nivel de servicios a sus nodos
locales.
El Coordinador Regional también decidió que el nodo local
estaba sintiédose perturbado muy fácilmente, ya que estuvo
reclamando servicios que normalmente no son requeridos de un
Coordinador de Red.
El nodo local fue informado en cuanto a las tareas
específicas de un Coordinador de Red, y se le aconsejó que
disminuyera sus expectativas al respecto.

10.3.4 El Caso "Busy Beaver"

Un nodo local,, que era operado por un establecimiento
comercial minorista, fue acusado de la realización de "corridas de
bombardeo" para enviar su propaganda a través de FidoNet.
El Coordinador de la Red se sintió perturbado al tener que
manejar el tráfico de salida de correspondencia para una operación
comercial, y le pidió al nodo local que abandonara la red.
El nodo local apeló al Coordinador Regional, y le fue
garantizado su status como un nodo independiente en la región.

10.3.5 La Marca del Diablo

Un operador cuyo tablero era utilizado para actividades de
ritos vudú, "hacking", "phreaking", y distribución de material
obsceno apeló a un Coordinador de Red para obtener un número de
nodo.
El Coordinador de Red consideró que el comportamiento de
ese tablero (BBS) era excesivamente perturbador, y le denegó su
solicitud.
El Coordinador Regional no fue consultado.
El Coordinador Internacional (*), al ver que el
Coordinador Regional no había sido consultado, desestimó el caso
inmediatamente.
Ninguna otra apelación fue hecha.

10.3.6 El Caso del SysOps Inútil (Twit)

Un usuario de diversos nodos locales, que funcionaban como
BBS, había sido rotundamente reconocido por todos los de los
mismos como un inútil.
El usuario obtuvo su propio sistema, se transformó en
operador de un BBS, y solicitó un número de nodo.
El Coordinador de Red negó la solicitud.
No se hicieron apelaciones.

10.3.7 El Caso del Adicto al Echomail (EchoMail Junkie)

Un nodo local se "enamoró" del EchoMail y se unió a varias
conferencias, ruteando su correspondencia a través de su red.
Luego creó una conferencia de EchoMail propia y comenzó a rutear
EchoMail entre varios sistemas, ruteando todo el tráfico de
correspondencia nuevamente a través de su red.
Su Coordinador de la red observó que el desempeño de la
misma se estaba viendo seriamente afectado. Al nodo ofensor se le
ordenó detener sus actividades.
Se llegó a un compromiso, donde gran parte del tráfico del
EchoMail no fue enviado más a través de la red y el EchoMail
ruteado fue limitado a veinte mensajes por noche.
No se hicieron apelaciones.

10.3.8 El Caso del Tablero Embustero (Bouncing Board)

Un usuario local decidió establecer un nodo para promover
una obra de caridad. La computadora fue también utilizada para
otras actividades diversas durante el día, y el operador del
sistema era, con frecuencia, requerido lejos de su lugar de
residencia. Sus colaboradores frecuentemente olvidaban poner en
marcha el tablero (BBS) al cabo del día mientras él estaba lejos,
de modo que el nodo estaba sin funcionar por períodos extendidos.
El Coordinador de la Red, al encontrar al nodo incapaz de
recibir correspondencia, lo marcaba como "de baja". Cuando el
operador del nodo regresaba, ponía en marcha el tablero, y pedía
ser restablecido.
Con el tiempo, el Coordinador de la Red decidió que el
operador del nodo no había sido capaz de mantener su sistema
funcionando confiablemente, y lo retiró del NodeList
definitivamente. Fueron rechazadas posteriores solicitudes del
mismo operador para un número de nodo.
No se hicieron apelaciones.

bbsfidonet #017

bbsfidonet@gmail.com (Vicente Fons) — Thu, 28 Sep 2006 13:37:00 +0200

9 Resolución de Disputas

9.1 Generalidades

La filosofía judicial de FidoNet puede ser resumida en dos reglas:

1) No molestes excesivamente a otros.

2) No te molestes demasiado fácilmente.

En otras palabras: no hay reglas de conducta rígidas y
expeditivas, pero se espera un comportamiento razonablemente
cortés. Además, en cualquier disputa, ambos lados son examinados,
y la acción puede tomarse contra una o ambas partes.

("No juzgues,
si no quieres ser juzgado!")

La estructura de coordinadores tiene la responsabilidad de
definir el término "excesivamente perturbador". Tal como una
definición muy común de pornografía: "No puedo definirla, pero la
reconozco cuando la veo.", es imposible una definición rígida y
expeditiva del comportamiento aceptable en FidoNet.
Los lineamientos generales en este reglamento son
deliberadamente vagos, para proveer a la estructura de
coordinadores con la libertad que requiere para responder a las
necesidades de una comunidad creciente y cambiante.
El primer paso, en cualquier disputa, entre operadores de
nodos es intentar comunicarse directamente: preferiblemente por
teléfono en forma oral o al menos por medio de NetMails. de la red
(NetMail ), preferiblemente por voz.
Cualquier queja que haya salteado este paso básico de
comunicación, será rechazada.
El hecho de requerir una queja formal no es una acción que
debería ser tomada a la ligera. La investigación y las respuestas
a las quejas requieren tiempo, que los coordinadores deberían
preferir usar en actividades más constructivas. Las personas que
persistan en quejas triviales acerca del reglamento, pueden
encontrarse en el lado equivocado de una queja por comportamiento
excesivamente perturbador.
Las quejas deben ser acompañadas con evidencia
verificable, generalmente copias de mensajes; una queja acerca de
una simple mala palabra será inmediatamente descartada.
La falta en seguir los procedimientos aquí descriptos (en
particular: saltear un coordinador o involucrar a un coordinador
que no esté en la cadena de apelaciones) es en sí mismo un
comportamiento perturbador.

9.2 Problemas con Otro Operador

Si tiene problemas con otro operador, en primer lugar
debería tratar de resolverlo a través de NetMails o conversando
con él telefónicamente.
Si esto fallase para resolver el problema, deberá quejarse
con su Coordinador de Red y con el Coordinador de Red del otro
operador. Si uno o ambos no fuesen miembros de una red, entonces
quéjese al Coordinador Regional que corresponda.
Si esto también fallase en proveerle una satisfacción,
tiene el derecho de seguir el proceso de apelación descrito en la
sección 9.5.

9.3 Problemas con su Coordinador de Red

Si tiene problemas con su Coordinador de Red y considera
que no está siendo tratado adecuadamente por él, tiene el derecho
a una revisión de su situación.
Al igual que con todas las disputas, el primer paso es
comunicarse directamente para intentar resolver el problema. El
siguiente paso es contactar a su Coordinador Regional.
Si su caso lo ameritase, hay varios cursos posibles de
acción, incluyendo un cambio del Coordinador de la Red o hasta el
desbande de su red.
Si hubiera sido excomunicado por su Coordinador de Red,
ese juicio puede ser revertido, al punto tal que usted será
restablecido en su red.
Si fallase en obtener el auxilio de su Coordinador
Regional, tiene el derecho de seguir el proceso de apelación
descrito en la sección 9.5.

9.4 Problemas con Otros Coordinadores

Las quejas concernientes al comportamiento perturbador por
parte de cualquier coordinador se tratan como en la sección 9.2 y
deberían ser elevadas al siguiente nivel de coordinador.
Por ejemplo, si considerara que su Coordinador Regional
fuera culpable de comportamiento perturbador (como contraposición
a un fallo del mismo que le impidiera desempeñar sus tareas como
coordinador de red; por ejemplo), deberá elevar su queja con el
Coordinador de Zona.
Las quejas concernientes al desempeño de un coordinador al
llevar a cabo las tareas encomendadas por el reglamento se aceptan
solamente cuando proceden del nivel inmediatamente inferior. Por
ejemplo, quejas concernientes al desempeño de los Coordinadores
Regionales podrían ser aceptadas cuando emanen de Coordinadores de
Red y/o de nodos independientes de esa región. Tales quejas
deberán dirigirse al Coordinador de Zona después de un apropiado
intento para solucionarlas a través de comunicaciones directas
entre los involucrados.

9.5 Proceso de Apelación

Una decisión tomada por un coordinador puede ser apelada
en el siguiente nivel de coordinación.
Los apelaciones deben hacerse dentro de las dos semanas en
que se tomó la decisión que es apelada. Todas las apelaciones
deben seguir la vía jerárquica; si los niveles fuesen salteados la
apelación será inmediatamente desestimada.
Una apelación no resultará en una investigación completa,
pero se basará en la documentación suministrada por las partes en
conflicto del nivel inferior. Por ejemplo, una apelación a una
decisión del Coordinador de Red será decidida por el Coordinador
Regional, basada en información suministrada por el coordinador y
el operador del nodo involucrado; no se espera que el Coordinador
Regional realice un intento independiente para recopilar
información.
La estructura de la apelación es como sigue:

Las decisiones del Coordinador de Red pueden ser apeladas al
Coordinador de Región apropiado.

Las decisiones de Coordinadores Regionales pueden ser
apeladas al Coordinador de Zona apropiado. En este punto, el
Coordinador de Zona tomará una decisión y la comunicará a los
Coordinadores Regionales en esa zona. Esta decisión puede ser
a su vez revertida por un voto mayoritario de Coordinadores
Regionales.

Las decisiones del Coordinador de Zona pueden ser apeladas
al Coordinador Internacional. El Coordinador Internacional
tomará una decisión y la comunicará al Consejo de
Coordinadores de Zona, que puede revertirla por voto
mayoritario.

Si su problema es per-se con un Coordinador de Zona, o sea,
un Coordinador de Zona ha cometido una violación del
Reglamento contra usted, su queja deberá ser elevada al
Coordinador Internacional, que tomará una decisión y la
presentará al Consejo de Coordinadores de Zona para su
posible reversión, como se describe anteriormente.

9.6 Estatuto de Limitaciones

Una queja no puede estar archivada más de 60 días,
contados a partir de la fecha de descubrimiento de la fuente de la
infracción, ya sea por razones de admisión de la misma o de
evidencia técnica.
Las quejas no pueden estar archivadas más de 120 días
después de mediar el incidente a menos que involucren un
comportamiento explícitamente ilegal.

9.7 Derecho a una Rápida Decisión

Se requiere que el coordinador tome una decisión final y
notifique a las partes involucradas en un plazo de 30 días a
partir del recibo de la queja o apelación.

9.8 Regreso a la Red Original

Una vez que una disputa de la política está resuelta,
cualesquiera de los nodos restablecidos por la apelación son
regresados a la red o región local a la cual geográficamente o
técnicamente pertenecen.

9.9 Correo de Echomail

El Echomail es una fuerza importante y poderosa en
FidoNet.
Para los propósitos de Disputas Reglamentarias, el
EchoMail es simplemente un sabor diferente del NetMail, y está por
lo tanto cubierto por este Reglamento.
Por su naturaleza, el EchoMail da cabida a demandas
técnicas y sociales únicas en la red, por encima de aquellas
cubiertas por esta versión del Reglamento. En reconocimiento de
este hecho, un Reglamento para el EchoMail (que extienda y no
contradiga la aplicación del Reglamento general), que sea
propuesto por los Coordinadores de Echomail, y ratificado por un
proceso similar al de éste documento, será reconocido por los
Coordinadores de FidoNet como una herramienta válida para la
resolución de disputas en asuntos pertinentes al EchoMail. En
alguna fecha futura el reglamento del EchoMail puede fusionarse
con éste.

9.10 Historias de Casos

La mayor parte del Reglamento de FidoNet es interpretativo
por naturaleza. Nadie puede saber qué puede ocurrir en nuestro
cambiante entorno. El Reglamento mismo, es solamente una parte de
las reglas básicas para mediar en disputas; tanto o más
importantes que él son los precedentes.
Para ordenar este proceso, las historias de casos pueden
ser agregadas o retiradas de éste documento por el Coordinador
Internacional, estando tal revisión sujeta a ser, a su vez,
revertida por el Consejo de Coordinadores de Zona.
Si una enmienda del Reglamento invalidase un precedente,
el Reglamento reemplazará a dicho precedente. (Una enmienda
cuidadosamente preparada haría esto retirando al precedente de
referencia como parte de la misma.). Aunque un caso puede ser
retirado del reglamento, el texto de la historia del caso no podrá
ser modificado por ningún mecanismo.
En caso de que la historia del caso esté escrita en una
época cercana a la decisión, por los involucrados en ella,
enmendar el texto de la historia del mismo, es lo mismo que
revisar la historia, algo bastante impropio en una organización
dedicada a intercambiar información.

bbsfidonet #016

bbsfidonet@gmail.com (Vicente Fons) — Thu, 28 Sep 2006 13:37:00 +0200

8 Referéndum

Los procedimientos descritos en esta sección son
utilizados para ratificar una nueva versión del reglamento de
FidoNet, que es el mecanismo por medio del cual el mismo es
cambiado. Este procedimiento es también utilizado para acusar a un
Coordinador de Zona.

8.1 Introducción

Un referéndum para la modificación del reglamento es
invocado, cuando una mayoría de los Coordinadores Regionales de
FidoNet informa, al Coordinador Internacional, que desea
considerar una nueva versión propuesta del Reglamento.

8.2 Anuncios y Notificación de los Resultados

Los cambios propuestos al Reglamento se distribuirán
utilizando la misma estructura que se usa para distribuir los
archivos diferenciales (NodeDiff) del listado de nodos (NodeList)
y FidoNews.

Los resultados y anuncios relacionados con el referéndum
son distribuidos por la estructura de coordinadores como una parte
del archivo diferencial semanal (NodeDiff) del listado de nodos
(NodeList). El Coordinador Internacional provee las copias al
editor de FidoNews para incluir los resultados en ella, aunque el
anuncio oficial y las fechas de votación están ligadas a la
distribución del listado de nodos (NodeList).

Una vez que la nueva versión ha sido adoptada, el
Coordinador Internacional establece la fecha de entrada en vigor
de la nueva política a través de un anuncio en el archivo
diferencial (NodeDiff) semanal del listado de nodos (NodeList). La
fecha de entrada en vigor será, a más tardar, un mes después del
cierre de las votaciones.

8.3 Elegibilidad para Votar

Cada miembro de la estructura de coordinadores de FidoNet
que esté en, o por encima del cargo de Coordinador de Red, tiene
derecho a un voto. Los coordinadores de conectores (hub) no votan.
En el caso de que el cargo cambie de manos durante el proceso de
votación, uno de ambos, ya sea el beneficiado o el nuevo
coordinador podrá votar, pero no ambos.

Si una persona tiene más de un cargo de coordinador, aún
emite un solo voto.

De los coordinadores de red se espera que evalúen las
opiniones de los miembros de su red, y voten de conformidad a las
mismas.

Una elección formal no es necesaria, pero el coordinador
de red debe informar a su red de los resultados de las elecciones,
y solicitar su ingreso como nuevo coordinador de la misma.

El coordinador de red es el representante de las
jerarquías y de los miembros de FidoNet.

8.4 Mecanismo de Votación

El mecanismo de votación real, incluyendo: si el voto será
o no secreto o cómo las boletas electorales van a ser recopiladas,
verificadas, y contadas, se deja librado a la discreción del
Coordinador Internacional. Idealmente, la colecta de los votos
debería ser transmitida sobre la estructura de FidoNet mismo por
medio de algún sistema seguro de mensajes.

Para proveer de un período de discusión, el anuncio de
cualquier votación debe hacerse al menos dos semanas antes de la
fecha de comienzo de la misma.

El período de votación debe ser de al menos dos semanas.

8.5 Votación del Reglamento como un todo

Dado que el Reglamento está entretejido y
autoreferenciado, un cambio relativamente simple puede requerir
varias alteraciones del mismo. Para simplificar el proceso, la
votación se hará seleccionando entre varios documentos globales,
más bien que entre varias enmiendas sobre temas específicos. En el
caso más simple, esto significa votar por sí o por no a un nuevo
documento. Si deben considerarse numerosas alternativas, ellas
tienen que ser presentadas como documentos globales, de los cuales
uno será el elegido.

8.6 Decisión de la votación

Se aceptará una enmienda del Reglamento vigente si, al
cabo del período de votación, esta ha recibido la mayoría de los
votos emitidos.

Por ejemplo, si hubieran 350 votantes habilitados, 100 de
los cuales emiten su voto; entonces, al menos 51 votos afirmativos
serían necesarios para declarar a la enmienda en vigor.

En el caso de que, en la misma votación, se estén
considerando múltiples propuestas para cambiar el reglamento, una
versión deberá recibir más del 50% de los votos emitidos para que
se la considere ratificada. En este caso, una "abstención" es un
voto válido se lo considera un voto para no cambiar el reglamento
actual, en la medida en que aumenta la cantidad de votos
requeridos para ratificar el cambio propuesto.

8.7 Acusación de un Coordinador de Zona

8.7.1 Introducción

En casos extremos, un Coordinador de Zona puede ser
acusado mediante un referéndum.

La acusación de un Coordinador de Zona no requiere una
violación del Reglamento. El proceso de acusación es invocado
cuando la mayoría de los Coordinadores Regionales de una zona le
solicitan al Coordinador Internacional que lo instituya.

8.7.2 Procedimiento como en el Referéndum del Reglamento

Son de aplicación las previsiones de las secciones 8.2 y
8.3 para llevar a cabo un referéndum de acusación. Se aplica la
definición de "mayoría" de la sección 8.6.

Solamente los coordinadores regionales de la zona afectada
votan (aunque el coordinador de zona sea también el Coordinador
Internacional).

8.7.3 Mecanismo de Votación

Los procedimientos de votación son establecidos, los votos
son recopilados, y los resultados son anunciados por un
Coordinador Regional elegido por el Coordinador de Zona que es
acusado.

La remoción del Coordinador de Zona se efectiviza dos
semanas después del cierre de la votación, si la acusación es
procedente.

8.7.4 Limitación de "una vez al año"

Se pretende, en principio, que la remoción de un
Coordinador de Zona sea un mecanismo por medio del cuál la red
expresa, como un todo, su desagrado con la forma en que éste
interpreta el Reglamento.

De vez en cuando, cada uno encuentra motivos para estar
descontento con la forma en que el reglamento es interpretado.

En razón de permitirles a los Coordinadores de Zona la
interpretación del reglamento para hacer su propia defensa, al
menos un año calendario completo tiene que transcurrir entre la
acusación y el referéndum, independientemente de cuanta gente
sostenga la posición del Coordinador de Zona durante ese año.

El Coordinador de Zona podría dimitir durante un proceso
de acusación, entonces el proceso es considerado nulo y sin valor,
y no consume la cuota de "una vez por año".

bbsfidonet #015

bbsfidonet@gmail.com (Vicente Fons) — Wed, 27 Sep 2006 18:17:00 +0200

6 Procedimientos a seguir por el Coordinador de Zona

6.1 Generalidades

Un Coordinador de Zona de FidoNet tiene la tarea principal
de mantener el listado de nodos (NodeList) para la Zona,
compartirlo con los otros Coordinadores de Zona y asegurar la
distribución del listado de nodos (NodeList) maestro (o del
archivo diferencial o 'NodeDiff') a las Regiones de su Zona. El
Coordinador de Zona es también responsable de coordinar la distri
bución del Reglamento de la Red y la publicación FidoNews a los
Coordinadores Regionales de la zona.
El Coordinador de Zona es responsable del mantenimiento
del listado de nodos (NodeList) para la región administrativa. La
Región Administrativa tiene el mismo número que la zona, y
consiste en un conjunto de nodos asignados para cumplir propósitos
administrativos no relacionados con el envío y recepción de la
correspondencia normal de la red.
Un Coordinador de Zona está gravado con la tarea de
asegurar la operación pacífica de la Zona, lo que hace designando
y supervisando a los Coordinadores Regionales. Si un Coordinador
de Zona determina que un Coordinador Regional no está ejecutando,
adecuadamente, las tareas esbozadas en la sección 5, deberá
encontrarle un reemplazante.
El Coordinador de Zona define las fronteras geográficas de
las regiones dentro de la zona y establece el período de la Hora
de Correspondencia de la Zona (ZMH). El Coordinador de Zona es
responsable de revisar y aprobar cualesquiera exenciones
geográficas, tal como se describe en la sección 5.6.
El Coordinador de Zona es responsable de asegurar la
operación pacífica entre las puertas (gates) de su zona y todas
las demás, para la transferencia de correo interzonal.
Los Coordinadores de Zona son responsables de la selección,
entre sus pares, del Coordinador Internacional.

6.2 Selección

El Coordinador de Zona es seleccionado mediante una
votación en la que participan los Coordinadores Regionales de la
zona. El ganador debe obtener la mayoría absoluta de los votos.

7 Procedimientos a seguir por el Coordinador Internacional

7.1 Generalidades

El Coordinador Internacional es aquel Coordinador de Zona
"primero entre sus iguales".
El Coordinador Internacional tiene la tarea principal de
coordinar la creación del listado de nodos maestro (NodeList),
administrando la distribución entre las Zonas de los listados de
nodos (NodeLists) de la Zona.
El Coordinador Internacional es responsable de la
definición de nuevas zonas y para la negociación de acuerdos para
comunicarse con otras redes. ("Otra red" en este contexto
significa otras redes con las que FidoNet se comunica de igual a
igual, no "red" en el sentido del nivel organizacional de
FidoNet.).
El Coordinador Internacional es también responsable de
coordinar la distribución del Reglamento de la Red y FidoNews a
los Coordinadores de Zona.
El Coordinador Internacional es responsable de coordinar
las actividades del Consejo de Coordinadores de Zona.
El Coordinador Internacional actúa como vocero del Consejo
de Coordinadores de Zona.
En aquellos casos que no estén específicamente cubiertos
por este documento, el Coordinador Internacional puede emitir
interpretaciones o extensiones específicas a este reglamento. El
Consejo de Coordinadores de Zona puede revertir tales
reglamentaciones mediante un voto mayoritario.

7.2 Selección

El Coordinador Internacional se selecciona o remueve por
una votación en la que participan los Coordinadores de Zona. El
ganador debe obtener la mayoría absoluta de los votos.

bbsfidonet #014

bbsfidonet@gmail.com (Vicente Fons) — Tue, 26 Sep 2006 11:26:00 +0200

5 Procedimientos a seguir por el Coordinador Regional

5.1 Responsabilidades

Un Coordinador Regional tiene las siguientes
responsabilidades:

1) Asignar números de nodo a nodos independientes en la
región.

2) Alentar a los nodos independientes en la región a unirse a
las redes existentes, o a formar nuevas redes.

3) Asignar números de red y definir las fronteras de las
redes en la región.

4) Compilar un listado de nodos (NodeList) que contenga a
todas las redes y a todos los nodos independientes de la
región, y enviar una copia del mismo, toda vez que éste
cambie, al Coordinador de Zona.

5) Garantizar la operación pacífica de las redes dentro de la
región.

6) Garantizar que el archivo diferencial (NodeDiff) del
listado de nodos (NodeList), Reglamentos y números de
FidoNews se encuentren disponibles para los Coordinadores de
Red de la región tan pronto como le sea posible en la
práctica.

5.2 Asignación de Números de Nodo

Es su responsabilidad asignar números de nodo a los nodos
independientes en su región.
También puede cambiar los números de nodos existentes en
su región, aunque debería consultar con los nodos involucrados
antes de obrar de esta manera. Puede asignar cualquier número que
desee, en tanto y en cuanto cada nodo tenga un número único dentro
de su región.
No debe asignar un número de nodo a ningún sistema hasta
que haya recibido una solicitud formal de ese sistema a través del
correo de FidoNet. Esto garantizará que el sistema sea mínimamente
operacional. El mantenimiento estricto de esta política ha sido
uno de los puntos fuertes de FidoNet.
También se le recomienda, aunque no se le exige, que llame
a un tablero electrónico de boletines (BBS) que ha solicitado un
número de nodo, antes de asignárselo.
Deberá enviar un NetMail, ya que éste sirve para
asegurarse que el sistema es capaz de recibir correspondencia,
para informarle a un nuevo operador su número de nodo
Si un nodo en su región está actuando de una manera lo
suficientemente perturbadora, puede tomar cualquier acción que
estime necesaria, de acuerdo con las circunstancias del caso.
Si recibiera una solicitud de número de nodo desde fuera
de su región, debe remitirla al coordinador que sea más local para
el nodo solicitante.
Si recibiera una solicitud de número de nodo, de un nuevo
nodo, que está en un área cubierta por una red existente, entonces
debe remitir la solicitud al Coordinador de esa red en vez de
asignar un número usted mismo.
Si se formase una red, en un área en la que usted tiene
nodos independientes, aquellos nodos serán transferidos a la red
local tan pronto como sea posible en la práctica.

5.3 Alentar la Formación y Crecimiento de Redes

Una de sus tareas principales como Coordinador Regional es
promover el crecimiento de redes dentro de su región.
Deberá evitar tener nodos independientes en su región, que
estén dentro del área de cobertura de una red.
Hay sin embargo ciertos casos, donde un nodo no debería
ser un miembro de una red, tal como un sistema con una gran
tráfico de NetMails; vea la sección 4.2.
Si varios nodos independientes de su región están en un
área local, deberá alentarlos para que formen una red y, si es
necesario, les puede exigir que la formen. Refiérase a la sección
2.4.
Observe que no se pretende que aliente la formación de
redes triviales.
Obviamente, un nodo no hace una red. El número exacto de
nodos requeridos para formar una red efectiva tiene que ser
juzgado de acuerdo con las circunstancias de cada situación, y se
deja a su discreción.

5.4 Asignación de Números de Red

Es su responsabilidad asignar números de red a las nuevas
redes que se formen dentro de su región. Con este propósito, su
Coordinador de Zona le asignará un conjunto de números de red.
Como parte de esta función, es responsabilidad del Coordinador
Regional definir las fronteras de las redes de la región.

5.5 Mantenimiento del NodeList

Como Coordinador Regional, tiene un papel dual en el
mantenimiento del listado de nodos (NodeList) para su región.
En primer lugar: debe mantener el listado de nodos
independientes de su región. Deberá intentar instrumentar, lo más
pronto posible, los cambios de: nombre, de número telefónico, etc.
en este listado. Deberá enviar, ocasionalmente, un mensaje a cada
nodo independiente de su región, para garantizar que estos son
operacionales.
Si un nodo sale "del aire" sin avisarle previamente, puede
darle de baja o retirarlo del listado de nodos (NodeList). (Los
nodos son puestos DE BAJA por un período máximo de dos semanas,
después del cual deberá ser retirado del listado de nodos).
En segundo lugar, debe recibir los listados de nodos
(NodeLists) de los Coordinadores de Red de las distintas redes de
su región.
Necesitará mantener un conjunto de listados de nodos (NodeLists)
por cada red de su región, ya que no puede contar con obtener una
actualización semanal, de cada Coordinador de Red. Utilizando esas
actualizaciones, deberá armar, todas las semanas, un listado de
nodos (NodeList) maestro de su región y enviarlo al Coordinador de
su Zona en el día y hora establecidos. Se le sugiere que lo haga
tan tarde como le sea posible, para así poder acomodar cambios de
última hora, evitando el riesgo de perder la conexión con su
Coordinador Zonal, y por lo tanto perder la actualización semanal.

5.6 Exenciones Geográficas

Hay casos en donde las áreas geográficas de llamadas
telefónicas locales no coinciden con las regiones de FidoNet.
En casos excepcionales, se acuerdan exenciones a los
lineamientos generales geográficos, entre el Coordinador Regional
y el Coordinador de Zona de la zona involucrada. Tal exención no
es un derecho, y no es permanente. Cuando se forme una red en la
región adecuada, que le proveería al nodo exento un acceso
telefónico local, éste ya no lo será más.
Una exención puede ser revisada y revocada en cualquier
momento por cualquiera de los coordinadores involucrados.

5.7 Supervisión de las Operaciones de la Red

Es responsable de la designación de los coordinadores de
red de su región.
Si un Coordinador de Red saliente le sugiere a un sucesor,
no está obligado a aceptarlo, aunque normalmente lo hará. De forma
similar, no está obligado a aceptar los individuos seleccionados
por los miembros de la red en una elección, aunque normalmente lo
hará.
Es su responsabilidad como Coordinador Regional garantizar
que las redes dentro de su región están operando de una manera
aceptable.
Esto no significa que se le requiera para operar esas
redes; ya que esa es la responsabilidad de los Coordinadores de
Red. Significa que usted es debe asegurar que los Coordinadores de
Red de su región están actuando responsablemente.
Si encontrase que un Coordinador de Red de su región no
está ejecutando adecuadamente las tareas esbozadas en la Sección
4, deberá tomar cualquier acción que considere necesaria para
corregir esa situación.
Si una red crece tanto, que no puede acomodar
razonablemente el tráfico de correspondencia durante la Hora de
Correspondencia de la Zona (ZMH), el Coordinador Regional puede
decidir la creación de una o más redes nuevas. Estas nuevas redes,
aunque pueden estar dentro de un área única de llamadas telefóni
cas locales, deben tener una base geográfica para la determinación
de la membresía de futuros nodos.
Es su obligación como Coordinador Regional: mantener,
dirigir y contactarse con razonable frecuencia con las redes de su
región. El método exacto para lograr esto se deja librado a su
discreción.

5.8 Hacer Disponibles los Reglamentos, Listado de Nodos
(Nodelists) y FidoNews

Como Coordinador Regional, es su responsabilidad obtener
el último archivo diferencial (NodeDiff) del listado de nodos
(NodeList), el reglamento de la red y los últimos números de
FidoNews, tales como se publican, y ponerlos a disposición de los
Coordinadores de Red dentro de su región.
El listado de nodos (NodeList) es enviado por correo
semanalmente los sábados al Coordinador de Zona, y FidoNews es
publicada semanalmente los lunes en el nodo 1/1. Contáctese con
ellos para más detalles acerca de cómo obtener las últimas copias
cada semana.
Es su responsabilidad hacer que estén disponibles para
todos los Coordinadores de Red de su región, tan pronto como le
sea posible en la práctica. El método de distribución se deja
librado a su discreción. No se le exige que los distribuya a
alguno de los nodos independientes de su región, aunque puede
hacerlo si así lo deseara.
Se lo alienta para hacer que todos estos documentos estén
disponibles para transferencias para el público (usuarios) en
general.

bbsfidonet #013

bbsfidonet@gmail.com (Vicente Fons) — Mon, 25 Sep 2006 07:58:00 +0200

4 Procedimientos a seguir por el Coordinador de Red

4.1 Responsabilidades

Un Coordinador de Red tiene las siguientes
responsabilidades:

1) Recibir la correspondencia entrante para los nodos de su red, y
arreglar la entrega a sus receptores.

2) Asignar números de nodo a los nodos de su red.

3) Mantener el listado de nodos (NodeList) de su red, y enviar una
actualización del mismo al Coordinador Regional toda vez que éste
cambie.

4) Hacer disponibles, para los nodos de su red, de: los listados
de nodos diferenciales (NodeDiff), los nuevos números de FidoNews,
y nuevas revisiones del Reglamento de la Red, ni bien sean
recibidas y revisar, periódicamente, los listados de nodos para
asegurarse que estén actualizados.

4.2 Rutear la Correspondencia

Es su responsabilidad, como Coordinador de Red, coordinar
la recepción y envío de NetMails ruteados a través de anfitriones
(host) para los nodos en su red. El mejor método para lograrlo se
deja a su discreción.
Si un nodo de su red está recibiendo grandes volúmenes de
correspondencia, puede solicitar que el operador del mismo
contacte a los sistemas que le están enviando esta
correspondencia, y pedirles que no se la ruteen como anfitriones.
Si el problema persiste, puede solicitar a su Coordinador Regional
para que asigne al nodo un número como nodo independiente, y dar
de baja el sistema de su red.
Ocasionalmente, un nodo hará una "corrida de bombardeo"
(enviando un mensaje a muchos nodos a la vez). Si un nodo, de otra
red, está haciendo una "corrida de bombardeo" a los nodos de su
red, ruteándola a través de su anfitrión; entonces puede quejarse
al coordinador de la red del nodo ofensor (Si es un nodo
independiente, quéjese con el coordinador regional.) Las "corridas
de bombardeo" están consideradas como un comportamiento
perturbador.
Otra fuente de sobrecarga en los ruteos es el EchoMail. Al
EchoMail no se le puede permitir que degrade la habilidad de
FidoNet para manipular el tráfico normal de mensajes. Si un nodo
de su red está ruteando grandes volúmenes de EchoMail, puede
pedirle al operador del mismo ya sea: que limite el volumen de
EchoMail o bien que deje de rutearlo.
No se le exige que remita correspondencia encriptada,
comercial, o ilegal. Sin embargo, si usted no la remitiera, debe
seguir los procedimientos descriptos en la sección 2.1.7

4.3 Asignar Números de Nodo

Es su responsabilidad asignar números de nodo a nuevos
nodos de su red. También puede cambiar los números de nodos
existentes en la misma, aunque debería consultar con sus nodos
miembros antes de hacerlo.
Puede asignar cualquier número que desee, siempre y cuando
cada nodo tenga un número único dentro de su red.
No debe asignar un número de nodo a ningún sistema, hasta
que haya recibido una solicitud formal por parte del mismo a
través del correo de FidoNet. Esto garantizará que el sistema sea
mínimamente operacional.
En el mantenimiento estricto de esta política radica una
de las virtudes de FidoNet.
También se recomienda, aunque no se exige, que llame a un
tablero (BBS) que ha solicitado un número de nodo antes de
asignárselo.
Puede no asignar un número de nodo a un nodo situado en un
área cubierta por una red existente.
Además, si tuviera nodos en un área que será cubierta por
una red en formación, aquellos deberán ser transferidos a la nueva
red.
Deberá enviar un NetMail para informar el número de nodo a
un nuevo operador, ya que éste permite asegurarse que el sistema
es capaz de recibirlo.
Si un nodo de su red está actuando de una manera
suficientemente perturbadora, puede tomar cualquier acción que
estime necesaria, de acuerdo con las circunstancias del caso.

4.4 Mantenimiento del Listado de Nodos (NodeList)

Deberá instrumentar los cambios en su segmento del listado
de nodos (NodeList) los cambios: de nombre, de número telefónico,
etc., tan pronto como le sea posible, una vez que haya recibido la
información.
Deberá también, ocasionalmente, enviar un mensaje a cada
nodo de su red para garantizar que son operacionales.
Si un nodo sale "del aire" sin avisarle previamente, puede
darle de baja o retirarlo del listado de nodos (NodeList). (Los
nodos son puestos DE BAJA por un período máximo de dos semanas,
después del cual deberá ser retirado del listado de nodos).
Según su discreción, puede distribuir una parte de esta
carga de trabajo a nodos conectores (hubs). En este caso, deberá
recibir los listados de nodos (NodeLists) por parte del
Coordinador de Conectores (Hubs) de su red. Necesitará mantener un
conjunto del listado de nodos (NodeLists) por cada conector (hub)
dentro de su red, ya que usted no puede apoyarse en cada actuali
zación semanal de cada Coordinador de Conectores (Hub).
Deberá ensamblar un listado de nodos (NodeList) maestro de
su red todas las semanas y enviarlo al Coordinador Regional en el
día y hora acordados. Se le sugiere que lo haga tan tarde como le
sea posible, para así poder acomodar cambios de última hora,
evitando el riesgo de perder la conexión con su Coordinador
Regional y por lo tanto perder la actualización semanal.

4.5 Hacer Disponibles los Reglamentos, Listado de Nodos
(Nodelists) y FidoNews

Como Coordinador de Red deberá obtener, todas las semanas,
a través de su Coordinador Regional, el último número de la
publicación FidoNews y el archivo diferencial (NodeDiff) del
listado de nodos (NodeList). El archivo diferencial (NodeDiff) del
listado de nodos (NodeList) pone a disposición todos los sábados,
y FidoNews se publica cada lunes. Debe poner estos archivos a dis
posición de todos los nodos de la red, y se alienta a que lo deje
disponible para transferencias para el público (usuarios) en
general.
Deberá obtener la versión más reciente del reglamento que
sostiene a los miembros de su red, y ponerlo a disposición de los
nodos de la misma. Los Reglamentos son publicados con intervalos
esporádicos, de modo que también deberá informar a los nodos de su
red cuando tales eventos tengan lugar, y garantizar que los nodos
estén familiarizados, en general, con los cambios instrumentados.
El Reglamento, FidoNews, y el listado de nodos (NodeList)
son el pegamento que nos mantiene unidos. Sin ellos, dejaríamos de
ser una comunidad y nos volveríamos solamente otra colección
aleatoria de tableros de boletines (BBS).

bbsfidonet #012

bbsfidonet@gmail.com (Vicente Fons) — Sat, 23 Sep 2006 10:32:00 +0200

3 Procedimientos Generales para Todos los Coordinadores

3.1 Distribuir los Archivos de Actualización del NodeList
(NodeDiffs) y FidoNews

Todos los Coordinadores son responsables de la obtención y
distribución semanal de los archivos de actualización del listado
de nodos o NodeDiff y la publicación FidoNews.

3.2 Procesamiento de los Cambios en el Listado de Nodos y su
Intercambio

Cada coordinador es responsable de obtener información,
para el listado de nodos, del nivel inferior; procesarla, y pasar
los resultados a su nivel superior.
El período que demore en este proceso estará determinado
por las exigencias impuestas por el nivel superior.

3.3 Garantizar la Disponibilidad del último Reglamento (Policy)

Un Coordinador es responsable para hacer que la versión
actualizada de éste documento esté disponible para el nivel
inferior, y de alentar la familiaridad con él.
Además, se demanda de un coordinador, que fomente y revise
todos los reglamentos locales recibidas del nivel superior.
Aunque no se le exige, las reglas usuales de cortesía
indican que la participación del nivel superior debería ser
solicitada, cuando se aprueba un reglamento local.

3.4 Limitación del Número de Funciones (Hats Worn)

Se alienta a los coordinadores a limitar el número de
funciones que desempeñan para FidoNet.
Un coordinador que ocupa dos cargos diferentes, compromete
el proceso de apelación. Por ejemplo: si el Coordinador de una Red
es también el Coordinador Regional, a los nodos integrantes de esa
red se les niega un nivel de apelación.
Se desalienta a los coordinadores para que actúen como
conectores (hubs) para la distribución de EchoMail y software. Si
así lo deseasen hacerlo, deberán manipular el EchoMail (u otra
distribución) en un nodo diferente del administrativo. El nodo de
un coordinador deberá estar disponible para los niveles
inmediatamente superiores e inferiores.
Otra razón para desanimar múltiples funciones es la
dificultad de reemplazar los servicios desempeñados, si alguien
dejara la red. Por ejemplo: si un coordinador es el conector
(hub) del EchoMail y el conector de distribución de software
(FileEcho), aquellos servicios serán difíciles de restablecer cuan
do dimita esa persona.

3.5 Ser Miembro del área Administrada

Un coordinador debe ser miembro del área administrada. Eso
es, un Coordinador de Red tiene que ser un miembro de esa red en
virtud de la geografía. Un Coordinador Regional tiene que ser un
miembro de una red en la región o, de otra manera debe ser un nodo
independiente dentro de la misma.

3.6 Alentar a Nuevos Operadores de Sistema para Entrar a FidoNet

Se alienta a los coordinadores a que operen un sistema de
tablero de boletines (BBS) público, que sea de libre ingreso, con
el propósito de distribuir el Reglamento, FidoNews, y el listado
de nodos (NodeList) a potenciales nuevos nodos.
La difusión de esta información a personas que sean
potenciales operadores de FidoNet es importante para el
crecimiento de la misma. Los coordinadores deberían alentar el
surgimiento de nuevos nodos.

3.7 Tradición y Precedente

Un coordinador no está legalmente obligado, ya sea: a
husmear más allá del ámbito de aplicación de este documento o, por
las prácticas de su predecesor.
Además, un nuevo coordinador tiene el derecho de revisar
cualquier decisión tomada por sus predecesores para cumplir con el
Reglamento, y puede tomar cualquier acción sea necesaria para
rectificar cualquier situación que no haya sido consentida.

3.8 Administración Técnica

La responsabilidad principal de cualquier coordinador es
la administración técnica de las operaciones de la red.
Las decisiones deben tomarse en base a consideraciones
técnicas.

bbsfidonet #011

bbsfidonet@gmail.com (Vicente Fons) — Thu, 21 Sep 2006 12:02:00 +0200

2.2 Cómo obtener un número de nodo

Debe obtener, primero, un listado de nodos (NodeList)
actualizado, de modo que pueda enviar correspondencia. No necesita
un número de nodo para enviar correspondencia, pero debe tener uno
para que otros le envíen correspondencia a usted.
El primer paso para obtener un listado de nodos (NodeList)
actualizado es localizar un tablero de boletines (BBS) de FidoNet.
La mayoría de las listas de BBS incluyen al menos unos cuantos
sistemas de FidoNet, y generalmente los identifican como tales.
Utilice una fuente local para obtener documentación porque muchas
redes han detallado información disponible que explica el área de
cobertura de la red y cualesquiera otros requisitos o
procedimientos especiales.
Una vez que tiene un listado de nodos (NodeList), debe
determinar qué red o región cubre su área. Las regiones están
numeradas de 1 a 99; los números de red son mayores que 99.
Las redes están más bien restringidas en áreas que en
regiones, pero son preferidas ya que ellas mejoran el flujo de
correspondencia y proveen más servicios a sus miembros. Si no
pudiera encontrar una red que cubra su área, entonces elija la
región que sí lo hace.
Una vez que ha localizado la red o región en su área,
envíe un mensaje conteniendo una solicitud para un número de nodo
al nodo cero de esa red o región. La solicitud debe ser enviada
mediante un NetMail, ya que éste indica que su sistema tiene
capacidad para intercambiar correspondencia de FidoNet. Debe
adaptar su software de modo que la dirección del remitente de su
mensaje no provoque problemas para el coordinador que lo reciba.
Si escogiera la dirección de un sistema existente para su
nodo, esto provocará problemas obvios. Si su software fuera capaz,
debe utilizar la dirección -1/-1 esto es, la dirección
tradicionalmente utilizada por operadores potenciales. De otra
manera utilice [red]/9999 (por ej. si usted estuviera solicitando
ingresar a la red 123, configure su sistema como 123/9999). Muchas
redes tienen instrucciones específicas disponibles para nuevos
operadores, y estos procedimientos pueden contener alguna
preferencia para elegir la dirección del remitente. El mensaje que
usted envía tiene que incluir al menos la siguiente información:

1) Su nombre.

2) Su número de teléfono personal.

3) El nombre de su sistema.

4) La ciudad y provincia donde su sistema está localizado.

5) El número telefónico que será utilizado para llamar a su
sistema.

6) Sus horarios de operación para enviar y/o recibir correo
de NetMails y el de su BBS (en el caso de que su sistema
también sea utilizado para ello).

7) La velocidad de transmisión máxima, en baudios, que usted
puede sostener.

8) El tipo de software administrador de correspondencia
(mailer) y el módem que está utilizando.

Su coordinador puede contactarlo para requerirle
información adicional. Toda la información que presente será
considerada confidencial y no se le suministrará a nadie, excepto
a la persona que reemplace en el cargo al coordinador actual, al
dimitir éste.
Deberá informar que ha leído este documento y debe también
acordar apoyar todas las reglas vigentes en FidoNet actualmente.
Por favor, deje que transcurra un período de al menos dos
semanas para que su solicitud de número de nodo sea procesada.
Si enviara su solicitud a un Coordinador Regional, éste
puede a su vez reenviarla al Coordinador de Red apropiado.

2.3 Si Usted estuviera por Solicitar la Baja (Going Down)

Si su nodo será dado de baja por un período extenso de
tiempo (más de uno o dos días), deberá informar dicha situación a
su coordinador, cuanto antes. No es responsabilidad de su
coordinador perseguirlo para que le rinda un informe de su
situación y, si su sistema dejase de aceptar correspondencia será
retirado del listado de nodos.
Durante el período en que su nodo esté dado de baja, no
conecte en su línea telefónica un contestador telefónico
automático o cualquier otro dispositivo que responda el teléfono.
Si así lo hiciera, los nodos de FidoNet que llamen a su sistema se
conectarán con el contestador, con el subsiguiente perjuicio
económico, al aumentar sus facturas telefónicas sin que ningún
intercambio de correspondencia haya ocurrido, lo cual se considera
un comportamiento muy perturbador.
En resumen: la única cosa que debería siempre responder el
teléfono, durante los períodos de tiempo en que el listado de
nodos indica que su nodo aceptará correspondencia, debe ser
software compatible con FidoNet y que acepte la transferencia de
correspondencia.
Si va a permitir que su nodo funcione desatendido por un
período extenso de tiempo; por ejemplo: mientras usted está de
vacaciones, deberá notificar a su coordinador. Los sistemas
tienen, ocasionalmente, una tendencia a dejar de funcionar, de
modo que probablemente desee que su coordinador esté al tanto de
que se trata de una situación temporal.

2.4 Cómo Formar una Red

Si en su área hay varios nodos, pero ninguna red; una
nueva red puede ser formada. Esto tiene ventajas, tanto para usted
como para el resto de FidoNet.
Recibirá con mas facilidad el archivo diferencial del
listado de nodos (NodeDiff) y la publicación FidoNews, y todos los
demás pueden sacar ventaja del ruteo de la correspondencia de la
red (NetMail) a través de un anfitrión (Host) que lo distribuirá
dentro de la red formada.
El primer paso es contactar a los otros operadores de los
nodos en su área. Debe decidir qué nodos abarcará la red, y cuál
de estos le gustaría para que desempeñe el cargo de Coordinador de
Red. Luego deberá consultar con su Coordinador Regional, al cual
debe enviar la siguiente información:

1) El número(s) de región, o número(s) de red (en el caso de
que una red se esté dividiendo) que serán afectados por la
formación de su red.
El Coordinador Regional informará, a su vez, al
Coordinador de Zona y a los coordinadores de cualesquier
otras redes que sean afectadas por el cambio, que una nueva
red se encuentra en formación.

2) Una copia del segmento del listado de nodos de la nueva
red propuesta. Este archivo debería estar incluido en el
mensaje de solicitud del número de red, y debería utilizar el
formato del listado de nodos como se describe en la versión
actualizada de la publicación de FTSC apropiada. Por favor,
elija un nombre que relacione lo agrupado, por ejemplo
SoCalNet para nodos en el área del Sur de California
(SOuthern CALifornian NET) y MassNet West para el área de
Massachusetts Occidental (Western Massachusetts). Recuerde
que si usted se llama a sí mismo a su nodo o a su BBS:
DOGNET, ello no servirá para identificar su área.

La asignación automática de un número de red no se le
garantiza. Y, aunque la solicitud sea otorgada, la red podría no
ser estructurada exactamente como usted lo solicitó. Su
Coordinador Regional revisará su solicitud y le informará de su
decisión.
No envíe una solicitud de número de red al Coordinador
de Zona.
Todas las solicitudes de número de red deben ser
procesadas por el Coordinador Regional.

bbsfidonet #010

bbsfidonet@gmail.com (Vicente Fons) — Thu, 21 Sep 2006 09:17:00 +0200

2 Procedimientos a seguir por el Operador del Sistema (SysOp)

2.1 Generalidades

2.1.1 Las Bases

Como el operador del sistema de un nodo individual usted
puede hacer lo que desee, en tanto y en cuanto observe los eventos
de correspondencia, no sea excesivamente perturbador con otros
nodos de FidoNet, y no promueva o participe a través de FidoNet de
la distribución de software protegido por derechos de autor u otro
comportamiento ilegal.

2.1.2 Familiaridad con el Reglamento

Para entender el significado de "excesivamente
perturbador", es obligatorio, sobre todo para los operadores de
sistema, que relean ocasionalmente la política de FidoNet.
Los nuevos operadores de sistema deben familiarizarse
ellos mismos con el reglamento antes de solicitar un número de
nodo.

2.1.2 Responsabilidad del Tráfico Entrante a FidoNet a Través del
Nodo

El operador de sistema, cuya entrada figura en el listado
de nodos, es responsable de todo el tráfico de correspondencia
entrante a FidoNet a través de ese sistema. Esto incluye, pero no
está limitado, al tráfico ingresado por usuarios, puntos y
cualesquiera otras redes para las cuales el sistema podría actuar
como un puente.
Si un operador de sistema permite que mensajes del
"exterior" puedan entrar a FidoNet a través de su sistema, el
mismo debe estar claramente identificado por su número de nodo de
FidoNet como el punto de origen de ese mensaje, y debe actuar como
un puente en el sentido opuesto.
Si el resultado de ese tráfico fuese una violación del
reglamento, el operador del sistema debe rectificar la situación.

2.1.4 Encriptado y Revisión de la Correspondencia

FidoNet es un sistema amateur, nuestra tecnología es tal
que la privacidad de los mensajes no puede ser garantizada.
Como operador del sistema, usted tiene el derecho de
revisar el flujo de tráfico a través de su sistema, aunque más no
sea por otra razón que la de garantizar que el mimo no esté siendo
utilizado para propósitos ilegales o comerciales. El encriptado
como es obvio hace esta revisión imposible. Por lo tanto, el
tráfico encriptado y/o comercial, que es enviado sin el permiso ex
preso de todos los eslabones (links) del sistema de distribución,
constituye un comportamiento perturbador. Vea la sección 1.3.6
para una definición de tráfico comercial.

2.1.5 Inalterabilidad de la Correspondencia Enviada

Usted no debe modificar ningún mensaje, de cualquier tipo:
correo de red (NetMail) o de difusión (EchoMail); que esté pasando
a través de su sistema de un nodo de FidoNet a otro, excepto
aquello que sea necesario para su ruteo o por algún otro propósito
técnico.
Si es ofendido por el contenido de un mensaje, el
procedimiento que se describe en la sección 2.1.7 debe ser
utilizado.

2.1.6 Correspondencia de Red Privada (Private NetMail)

La palabra "privada" debería ser utilizada con gran
cuidado, especialmente con los usuarios de un BBS.
Algunos países tienen leyes que tratan sobre la
"correspondencia privada", y debería aclararse que la palabra
"privada" implica que ninguna otra persona que no sea el receptor
puede leer los mensajes.
Los operadores de sistema que no puedan proveer esta
distinción a sus usuarios, deberían considerarlo, no ofreciendo a
los mismos la opción de "correspondencia privada".
Si un usuario envía un "mensaje privado", el mismo no
tiene control sobre el número de sistemas intermediarios a través
de los cuales pasará ese mensaje hasta llegar a su destino.
Un operador de sistema que envíe un mensaje a otro
operador, puede controlar este aspecto enviando el mensaje
directamente al sistema del receptor, y así garantizar que
solamente el sistema receptor -u otro individuo a quien el
operador le haya dado autorización- pueda leer el mensaje.
Así, un operador de sistema puede tener expectativas
diferentes
a las de un usuario casual.

2.1.6.1 No revelar el contenido de la correspondencia en tránsito

Exponiendo, o de alguna manera, utilizando información
contenida en la correspondencia privada (NetMail) en tránsito de
un sistema a otro y que no esté dirigida a, o escrita por usted,
se considerará un comportamiento perturbador. A menos que el
mensaje haya sido puesto a su disposición por el autor o el
receptor como parte formal de una queja reglamentaria (formal
policy complaint).
Esto no se aplica para el correo de "difusión" (EchoMail),
que es por definición un medio de divulgación, y donde el concepto
de correo privado se usa con frecuencia para establecer un área
restringida, para uso exclusivo del operador del sistema.

2.1.6.2 Correspondencia Privada dirigida a usted

El tema de la correspondencia privada que le es remitida
directamente a su sistema, es más difícil aún que la cuestión
acerca de la correspondencia en tránsito (in-transit) tratada en
la sección previa.
La opinión jurídica comúnmente sostiene que, cuando usted
recibe un mensaje, éste se transforma en su propiedad, y usted
tiene el derecho legal de hacer con él lo que desee. Su derecho
legal no lo excusa de perturbar a otros.
En general, no debería enviarse información confidencial o
sensible, utilizando a FidoNet como medio. Este ideal está
frecuentemente comprometido ya que FidoNet es nuestro modo
principal de comunicación.
En general: si el remitente de un mensaje solicita
específicamente ,en el texto del mismo, que el contenido sea
mantenido confidencial; la liberación del mismo en una conferencia
pública puede considerarse como una actitud perturbadora.
Hay excepciones: si alguien estuviera afirmando una cosa
en público y diciendo lo contrario en su correspondencia privada;
el receptor de la misma no debería ser expuesto a "acosamiento",
simplemente porque el remitente solicita que el mensaje no sea
puesto a disposición del público.
El juicio y sentido común deberían ser utilizados en estas
cuestiones, tal como en todos los demás aspectos relativos al
comportamiento de las personas en FidoNet.

2.1.7 No Rutear Correspondencia

A usted no se le exigirá que rutee la correspondencia, a
menos que haya acordado realizar tal función. De igual manera, no
estará obligado a rutear correspondencia para todos los demás
nodos aunque lo haga para alguno en particular; esto es así a
menos que usted detente el cargo de Coordinador de Red o
Coordinador de Conectores (Hubs).
El ruteo de correspondencia a través de un nodo que no
está obligado a desempeñar tal función, y sin el permiso expreso
de ese nodo, puede considerarse un comportamiento perturbador.
Esto incluye al tráfico de EchoMail que no haya sido solicitado
por el nodo.
Sin embargo, si usted no remitiera un mensaje, cuando
previamente acordó desempeñar tal función, entonces debe regresar
el mensaje al operador del nodo a través del cual el mensaje
ingresó a FidoNet, con una explicación de las causas por las
cuales ese mensaje no fue remitido. No es necesario regresar
mensajes dirigidos nodos que no figuren en el último listado de
nodos (NodeList). La detención intencional de un mensaje en
tránsito sin seguir este procedimiento, constituye un
comportamiento perturbador.
En el caso de existir un problema técnico, que impida
remitir la correspondencia; este no será considerado un
comportamiento perturbador a menos que dicho problema persista
después de haberle sido señalado al operador del sistema.

2.1.8 Exclusividad de la Hora de Correspondencia de la Zona (ZMH)

La Hora de Correspondencia de la Zona es el corazón de
FidoNet, ya que es en esta hora cuando la correspondencia está
pasando entre los diferentes sistemas.
Cualquier sistema que desee formar parte de FidoNet debe
poder recibir correspondencia durante este período de tiempo,
utilizando el protocolo definido en la versión más actualizada que
publica el Comité de Normas Técnicas de FidoNet (FTS-0001 para la
época en que éste documento fue escrito).
Está permitido tener mayor capacidad (por ejemplo, utilizar
protocolos adicionales o extender las horas en que se intercambie
la correspondencia), pero el mínimo requisito es tener capacidad
FTS-0001 durante esa hora del día.
Este período de tiempo está reservado exclusivamente para
intercambiar la correspondencia de la red (NetMail).
Muchas empresas telefónicas, cobran basándose en la cantidad
de llamadas que se realicen (per-call basis), independientemente
de que se haya establecido una señal de: conectado (connect),
ninguna conexión (no connect) o de ocupado (busy). Por esta razón,
cualquier otra actividad, que no sea el procesamiento normal de la
correspondencia de red (NetMail), y que ocupe a un sistema durante
la ZMH, se considera un comportamiento perturbador.
El Echomail no deberá ser transferido durante la ZMH.
El acceso de usuarios (BBS) a un sistema deberá prohibirse
durante la ZMH.
Puede ocurrir que a un nodo miembro de una red local, se le
requiera para observar eventos adicionales de correspondencia,
definidos por el Coordinador de la Red.
Las restricciones de acceso, al sistema al que se le ha
requerido que tenga esos eventos adicionales, que pudiera haber
durante estos períodos de intercambio de correspondencia en la red
local, se dejan a discreción del Coordinador de la Red.

2.1.9 Nodos Privados

La única excepción al cumplimiento de la ZMH son los nodos
privados.
De ser posible, a las personas que soliciten nodos privados,
se les debería inscribir como puntos (Points).
Un nodo privado está justificado cuando el mismo debe
interactuar con muchos otros como un distribuidor de EchoMail. En
estos casos, la manera y tiempo exacto de intercambio de
correspondencia se acordará entre el nodo privado y los otros
sistemas. Tal acuerdo, entre un sistema privado y un conector
(Hub), no compromete el reemplazo de ese conector.
Un nodo privado debe formar parte de una red (no pueden ser
nodos independientes de la región.).
El hecho de mantener nodos que figuren como privados en los
listados, impacta sobre cada miembro de FidoNet, ya que ocupa
espacio en el listado de nodos (NodeList) de cada miembro de la
red.
Los nodos privados que sean exclusivamente para la
conveniencia de un operador (a expensas de cualquier otro nodo de
FidoNet) son un lujo que no es posible permitirse.
Las entradas redundantes en el listado de nodos (más de una
entrada en el listado con el mismo número de teléfono, exceptuando
lo estipulado por las normas de FTSC), que no sean esenciales,
también caen en esa categoría. Los operadores de los sistemas que
soliciten ser listados, como nodos privados o redundantes, deben
justificar cómo beneficiarán a su red local o a FidoNet como un
todo. El Coordinador de Red o Coordinador Regional puede revisar
esta declaración en cualquier momento y retirar a los nodos que no
hayan justificado su status de nodo privado.

2.1.10 Observación de los Eventos de Correspondencia

Las fallas en observar adecuadamente los eventos de
correspondencia son motivo suficiente para que un nodo sea
retirado de FidoNet sin notificación alguna, ya que la misma se
realiza, generalmente, mediante el correo de la red (NetMail).

2.1.11 Uso del Listado de Nodos (NodeList) Actualizado

Los sistemas o nodos que intercambian correspondencia,
operan ,generalmente, desatendidos y las llamadas tienen lugar en
horas de la madrugada. Si un sistema intentase llamar a un número
telefónico incorrecto o desactualizado, puede provocar que el
teléfono de alguna desgraciada persona suene a esas horas,
causándole molestias e inconvenientes. Por esta razón, un operador
del sistema que desee enviar correspondencia, está obligado a
obtener y utilizar, en la práctica, la edición más reciente del
listado de nodos.

2.1.12 Excomunicación (Excommunication)

Un sistema que haya sido removido de la red, se dice que
está excomunicado (la comunicación le es denegada).
Si su coordinador fue incapaz de contactarlo, usted puede
descubrir que ha sido excomunicado sin que medie aviso. Debería
rectificar el problema que origino esa situación y contactar a su
coordinador para obtener alguna explicación.
Los sistemas también pueden removerse del listado de nodos
por otras causas. Vea la sección 9, y las secciones 4.3 y 5.2.
Se considera un comportamiento perturbador el hecho de
ayudar a un sistema que fue excomunicado, a 'trampear' esa
remoción del listado de nodos. Por ejemplo, si decidiera rutear un
área de EchoMail a un amigo, que ha sido excomunicado, es probable
que usted también sea retirado del listado.

2.1.13 Distribución de la Hora de Correspondencia de la Zona (ZMH)

La distribución exacta de la Hora de Correspondencia de la
Zona (ZMH) es establecida por el Coordinador de Zona para cada una
de ellas. Vea la sección 10.2 para mas información.

2.1.14 Inobservancia del Período de Ahorro de Luz Solar (Daylight
Saving)

FidoNet no respeta el período de ahorro de luz solar. En
aquellas áreas geográficas que sí lo respeten, el esquema que
regula el tráfico de correspondencia de FidoNet debe ser ajustado
en la misma dirección que el cambio de reloj.
Alternativamente, usted puede optar por dejar su sistema
en tiempo estándar.

bbsfidonet #009

bbsfidonet@gmail.com (Vicente Fons) — Wed, 20 Sep 2006 21:48:00 +0200

1.3 Definiciones

1.3.1 FidoNews

FidoNews es un boletín de prensa distribuido semanalmente
en forma electrónica a través de la red. Es un medio importante a
través del cual los operadores del sistema de FidoNet se comunican
entre sí.
FidoNews provee la sensación de ser una comunidad de personas que
comparten intereses comunes.
De conformidad, los operadores del sistema y usuarios son
invitados para brindar su contribución a FidoNews. Las
contribuciones deben enviarse al nodo 1:1/1. Un archivo de texto
describiendo el formato a ser utilizado está disponible en el nodo
1:1/1 y en muchos otros sistemas.

1.3.2 Geografía

Cada nivel de FidoNet está contenido geográficamente por
el nivel inmediatamente superior a él. Una ubicación geográfica
dada está cubierta por una zona y una región dentro de esa zona, y
puede estar - o no - en una red.
Nunca hay dos zonas, dos regiones, o dos redes que cubran
la misma área geográfica.
Si un nodo está en el área geográfica de una red, debería
estar listado en esa red, y no de manera independiente en la
región. (La excepción principal a esta regla es la de un nodo que
reciba correspondencia en exceso la cual sea a su vez ruteada por
un nodo anfitrión o "host-routed"; vea la sección 4.2).
Las fronteras de red se basan en las áreas telefónicas de
llamadas tal como estén definidas por la compañía telefónica
local.
Aún en el caso de áreas donde la densidad de nodos es tan
grande que más de una red sea necesaria para servir a un área
telefónica de llamadas locales, un lineamiento general geográfico
se utilizará para decidir cuales nodos pertenecen a qué red.
La membresía de red se basa en razonamientos geográficos u
otra razón puramente técnica. No se basa en factores personales o
sociales.
Hay casos en que la primacía de áreas de llamada local
conduce a situaciones donde el dictamen lógico es que un nodo
físicamente ubicado en una Región de FidoNet debería ser asignado
a otra. En aquellos casos, con el acuerdo de los Coordinadores
Regionales y el Coordinador de la Zona involucrada, pueden
otorgarse exenciones. Tales exenciones están descritas en la
sección 5.6.

1.3.3 La Hora de Correspondencia de la Zona (ZMH)

La Hora de Correspondencia de la Zona (ZMH) es un período
de tiempo definido durante el cual a todos los nodos en una zona
se les exige que estén disponibles para aceptar el correo de la
red (NetMail). Cada zona de FidoNet define una ZMH y publica el
tiempo de su ZMH para todas las demás zonas de FidoNet. Véanse las
secciones 2.1.8 y 10.2.
La Hora de Correspondencia de la Zona (ZMH) ha sido
previamente referida a la Hora de Correspondencia Nacional y a la
hora de Correspondencia de Red. La Hora de Correspondencia de la
Zona (ZMH) es una terminología más exacta.

1.3.4 Listado de Nodos (NodeList)

El listado de nodos es un archivo, actualizado
semanalmente, que contiene las direcciones de todos los nodos
reconocidos de FidoNet. Este archivo es distribuido actualmente
por el Coordinador de Zona, a la Hora de Correspondencia de la
Zona (ZMH) a más tardar cada sábado; y está disponible para
transferencia electrónica (download) o para hacer una solicitud de
archivo (file request) sin ningún cargo.
Para ser incluido en el listado de nodos, un sistema debe
cumplir los requisitos definidos por este documento. Ningún otro
requisito puede imponérsele.
Listados de nodos parciales, de una única zona, por
ejemplo, pueden estar disponibles para los diferentes niveles en
FidoNet.
La lista completa, tal como ha sido publicada por el
Coordinador Internacional, es el listado de nodos oficial de
FidoNet, y será utilizado en circunstancias tales como la
determinación de elegibilidad para votar.
Todas las partes que componen el listado de nodos completo
se encuentran disponibles con cada Coordinador de Zona y en el
nodo de cada Coordinador Regional.

1.3.5 Comportamiento Excesivamente Perturbador (Annoying Behavior)

Hay referencias, a través de este reglamento, acerca del
"comportamiento excesivamente perturbador", especialmente en la
sección 9 (Resolución de Disputas). Definir este término es
difícil, ya que se basa en el sentido común del coordinador.
Generalizando: un comportamiento perturbador irrita,
incomoda, o causa daño a alguna otra persona. No es necesario
quebrantar una ley para ser perturbador.
Hay una distinción entre comportamiento excesivamente
perturbador y, simplemente, comportamiento perturbador. Por
ejemplo: hay una curva de aprendizaje que cada nuevo operador de
un nodo debe escalar; tanto en los temas técnicos, acerca de cómo
adaptar el software, como en los temas sociales, acerca de cómo
interactuar con otros miembros de FidoNet. Es un raro operador
aquél que, en algún punto de esa jornada, no ha llegado a molestar
a otros. Solamente cuando tal comportamiento persiste, después de
haberle sido señalado al operador causante, éste se transforma en
excesivamente perturbador.
El hecho de que no exista repetición de un comportamiento
perturbador, no implica que no es posible estar perturbando
excesivamente; por ejemplo: la falsificación deliberada de
correspondencia podría ser excesivamente perturbadora en su primer
intento, pero ilustra simplemente que debe extenderse una cierta
tolerancia. Remítase a la sección 9 y a los casos prácticos
estudiados (sección 10.3) para más información.

1.3.6 Uso Comercial

FidoNet es una red amateur. Los participantes invierten su
propio tiempo y dinero para hacerla funcionar en beneficio de
todos los usuarios.
No es apropiado que una empresa comercial saque ventaja de
estos esfuerzos voluntarios para sus propios intereses de negocio.
Por otra parte, FidoNet provee unos medios convenientes y
efectivos para que compañías y usuarios intercambien información
para mutuo beneficio.
Los Coordinadores de Red pueden verse forzados a subsidiar
operaciones comerciales al actuar como anfitriones (host) para la
transmisión de correspondencia de la red (NetMail), pudiendo hasta
encontrarse involucrados en un juicio, si alguna garantía fue
sugerida para una entrega por correo. Es por lo tanto política de
FidoNet que esa correspondencia comercial no sea distribuida.
"Correspondencia comercial", incluye a la correspondencia
que promueva intereses de negocios específicos, que no sean para
beneficiar a la red como un todo. Los ejemplos incluyen correo
interno de una compañía, correspondencia intercorporativa,
indagaciones específicas acerca de un producto (cotización, por
ejemplo), órdenes de compra, todas las diligencias para promover
un negocio y todos los demás temas específicamente relacionados
con los negocios.

bbsfidonet #008

bbsfidonet@gmail.com (Vicente Fons) — Tue, 19 Sep 2006 23:30:00 +0200

Hoy abordamos el capítulo de Organización de la Policy4

1.2 Organización

Los sistemas integrantes de FidoNet están agrupados en
varios niveles, y su administración es descentralizada en
correspondencia con estos agrupamientos. Este esbozo provee un
sumario de la estructura. Las tareas específicas del puesto de
coordinador se enumeran mas adelante.

1.2.1 Sistemas Individuales y Operadores Del Sistema (SysOps)

La menor subdivisión de FidoNet es el sistema individual o
nodo, en correspondencia con una única entrada en el archivo que
contiene el listado de nodos (NodeList).
El operador del sistema puede formular sus propias reglas
locales, atinentes al funcionamiento del tablero de boletines
(BBS), y para establecer su forma de relacionarse con sus
usuarios. El operador del sistema debe integrar una red con el
resto de los sistemas de FidoNet, con el fin de poder enviar y
recibir correspondencia; y las reglas locales deben ser
consistentes con los otros niveles de reglamentación de FidoNet.

1.2.1.1 Usuarios

El operador del sistema será responsable de las acciones
de cualquier usuario de su BBS cuando ellas afecten al resto de
FidoNet. (Si un usuario está perturbando, se considerará que el
SysOps está perturbando.). Cualquier ingreso de correspondencia a
FidoNet a través de un nodo dado, aunque no haya sido escrito por
el operador del sistema, se lo considerará de un usuario y es por
ende responsabilidad del operador. (Vea también la sección 2.1.3.)

1.2.1.2 Puntos (Points)

Un punto (Point) es un sistema FidoNet-compatible que no
está en el listado de nodos (NodeList), pero se comunica con
FidoNet a través de un nodo, al cuál se refiere como un nodo jefe
(BossNode). Un punto se considera, generalmente, de la misma
manera que un usuario; por ejemplo, el nodo jefe es responsable de
la correspondencia de sus puntos. (Vea la sección 2.1.3.). Las di
recciones de los puntos se determinan en base a las direcciones de
listado de nodos de sus respectivos nodos jefe; por ejemplo, la
dirección de un punto con un nodo jefe cuya dirección es
"1:114/15" podría ser "1:114/15.12". La correspondencia cuyo
destino es el punto es enviada a su nodo jefe, que luego la re
envía hacia el punto.
Al mantener puntos, el nodo jefe utilizara para los
mismos, una dirección privada que, en general, no debería ser
visible fuera de la relación nodo jefe-punto. Lamentablemente,
cuando el punto llame directamente a otro nodo que no sea su nodo
jefe (al hacer una solicitud de archivos o file-request, por
ejemplo), su dirección será registrada por dicho sistema.
De este modo, los puntos difieren de los usuarios, ya que
operan software que les permite administrar la correspondencia
(mailers) FidoNet-compatibles, y porque son capaces de contactar a
otros sistemas de FidoNet ademas de su nodo jefe.

1.2.3 Redes (Networks) y Coordinadores de Red

Una red es una colección de nodos en un área geográfica
local, usualmente definida por un área conveniente de llamadas
telefónicas.
Las redes coordinan su actividad de correspondencia para
disminuir el costo.
El Coordinador de Red es responsable de mantener la lista
de nodos para la red y de remitir el correo de la red (NetMail)
enviado a sus miembros por otros nodos de FidoNet. Aunque no se le
exige, el Coordinador de Red puede hacer arreglos para organizar
la salida del correo de la red. El Coordinador de Red es designado
por el Coordinador Regional.

1.2.3.1 Conectores (Hubs) de Distribución de la Red

Los Conectores (Hubs) de Distribución de la red son
sistemas que existen solamente en algunas redes. Pueden ser
designados para ayudar en le administración de una gran red por el
Coordinador de Red.
Las tareas que debe cumplir un conector y los procedimientos
exactos que debe seguir, son una cuestión que se establece entre
el Coordinador de la Red y los conectores de la misma, y no serán
discutidos aquí; con la salvedad de que un Coordinador de Red no
puede delegar en ellos la responsabilidad de mediar en las
disputas.

1.2.4 Regiones y Coordinadores Regionales

Una región es un área geográfica bien definida, que
contiene nodos, los cuales pueden estar agrupados (o no) en redes.
Una región típica contendrá muchos nodos en varias redes, y
algunos pocos nodos independientes que no forman parte de ninguna
red.
El Coordinador Regional mantiene la lista de nodos
independientes de la región y acepta los listados de nodos que le
hacen llegar los Coordinadores de Red en su región. Estos son
compilados para crear un listado de nodos regional, que es luego
enviado al Coordinador de Zona.
Un Coordinador Regional no desempeña servicios de remisión
de mensajes para ninguno de los nodos de la región. Los
Coordinadores Regionales son designados por el Coordinador de
Zona.

1.2.5 Zonas y Coordinadores de Zona

Una zona es una gran área geográfica, que a su vez
contiene a muchas regiones, cubriendo uno o más países y/o
continentes.
El Coordinador de Zona compila los listados de nodos de
todas las regiones en la zona, y crea el listado de nodos maestro
y el archivo diferencial de nodos (NodeDiff), que es entonces
distribuido en la zona.
Un Coordinador de Zona no desempeña servicios de remisión
de mensajes para ninguno de los nodos de su zona.
Los Coordinadores de Zona son seleccionados por los
Coordinadores Regionales de la zona correspondiente.

1.2.6 Consejo de Coordinadores de Zona

En ciertos casos, los Coordinadores de Zona trabajan
como un consejo para proveerle consejos al Coordinador
Internacional. El arreglo es similar al que existe entre un
presidente y sus consejeros. En particular, este consejo considera
temas interzonales.
Esto incluye, pero no está limitado a: el planeamiento de
los detalles en la generación del listado de nodos (NodeList), la
mediación en disputas interzonales, y temas tales que no estén
dirigidos a un bajo nivel de organización de FidoNet.

1.2.7 Coordinador Internacional

El Coordinador Internacional es aquel Coordinador de Zona
"primero entre sus iguales", que coordina la generación, en
conjunto, del listado de nodos maestro por los Coordinadores de
Zona.
El Coordinador Internacional actúa presidiendo el Consejo
de Coordinadores de Zona y como supervisor de las elecciones,
arreglando el anuncio del referéndum, la reunión y conteo de las
boletas y anunciando los resultados de aquellos temas que afecten
a FidoNet como un todo. El Coordinador Internacional es
seleccionado por los Coordinadores de Zona.

1.2.8 Organización descendente. Equilibrio y Controles.

Estos niveles de organización actúan para distribuir la
administración y control de FidoNet al más bajo nivel posible,
pero permitiendo aún una acción coordinada sobre el sistema de
correspondencia completo.
La administración se realiza operando de una manera
descendente (top-down). Esto es, que una persona a cualquier nivel
dado es responsable ante el nivel superior, y responsable de su
nivel inferior.
Por ejemplo, un Coordinador Regional es responsable ante
el Coordinador de Zona por cualquier cosa que ocurra en la región.
Desde el punto de vista del Coordinador de Zona, el Coordinador
Regional es completamente responsable del funcionamiento pacífico
de la región.
Asimismo, desde el punto de vista del Coordinador
Regional, el Coordinador de Red es completamente responsable de la
operación tranquila de la red.
Si una persona, en cualquier nivel superior al de operador
del sistema, es incapaz para desempeñar adecuadamente sus tareas,
la persona en el siguiente nivel puede reemplazarlo. Por ejemplo:
si un Coordinador Regional falla en el desempeño de sus funciones,
el Coordinador de Zona puede reemplazarlo.
Para proveer equilibrio y control al más alto nivel de
FidoNet, hay dos excepciones a esta organización descendente:

Los Coordinadores de Zona y el Coordinador Internacional
se seleccionan mediante el voto mayoritario de los coordinadores
en el nivel inferior. Igualmente, las decisiones tomadas por el
Coordinador Internacional pueden ser revertidas por el Consejo de
Coordinadores de Zona, y las decisiones tomadas por un Coordinador
de Zona pueden ser revertidas por los Coordinadores Regionales.
Vea las secciones 6 y 7 para más detalles. Las decisiones tomadas
por otros coordinadores no son tema para revertir por una votación
de bajo nivel, pero en cambio son tema para el proceso de
apelación descrito en la sección 9.5.

bbsfidonet #007

bbsfidonet@gmail.com (Vicente Fons) — Mon, 18 Sep 2006 19:43:00 +0200

En este episodio y en los siguientes, vamos a tratar sobre las normas por las que se rige FidoNet, en concreto la Policy4.

===================

La Plata, 7 de mayo de 1994.-

Prólogo de la segunda traducción

Transcurridos ya varios años de mi primer traducción del
reglamento de FidoNet, me ha parecido necesaria una revisión de la
original. En este período, han ocurridos muchos cambios en nuestra
red y yo he ganado alguna experiencia. Deseo que todo esto se vea
reflejado en la nueva traducción. Entre otras cosas, me he tomado
la libertad de traducir algunos términos de manera tal que sean
comprensibles para aquellas personas poco familiarizadas con
FidoNet. Así por ejemplo, el termino “POLICY” ha sido traducido
como “REGLAMENTO” y otros, como “EchoMail” no han sido traducidos
por no encontrar una palabra que lo reemplace de una forma - para
mi - satisfactoria. Esto me lleva a renovar la advertencia acerca
del sentido “informativo” de este documento, debiéndose remitir al
original en inglés para propósitos legales u oficiales dentro de
FidoNet.
Si descubriese algún error u omisión, envíe un NetMail
describiéndolo a Carlos Grane, nodo 4:902/2 de la red La Plata.

Carlos M. Fernández Grané.
——————————————————————

Prólogo de la primer traducción

La presente versión en español del POLICY4 es un intento
de acercar a aquellas personas que no dominan el inglés una
aproximación a la idea de las políticas que rigen la red. De
ninguna manera debe considerarse como el reemplazo del original.
Debo hacer notar que el documento original ha sido escrito
en Estados Unidos y la traducción de los giros idiomáticos es
difícil cuando no imposible. Existe sin embargo un sentido general
de la obra, que espero sea respetado por la presente traducción.
De no ser así los errores u omisiones se deben a la inexperiencia
de quién les escribe; y espero que las correcciones o sugerencias
me sean enviadas a la brevedad al nodo 4:902/2 de la Red Provincia
de Buenos Aires.
Las versiones actualizadas y corregidas serán puestas a
vuestra disposición lo antes posible.
Confío que esta traducción les sea de real utilidad.

Carlos M. Fernández Grané.

Agradecimientos

No sería justo negar la deuda de gratitud que mantengo con
César Ferri, operador de Cefex (4:902/1), quién me guió en mis
primeros pasos en el apasionante mundo de las telecomunicaciones.
A él pues, va mi agradecimiento.
——————————————————————

Documento de la Política, o Reglamento de FidoNet

Versión 4.06
Mayo 5, 1989

* * * PROPUESTA * * *

Este documento ha sido propuesto para votación por la
estructura de coordinadores, y no se encuentra
vigente. (N. del T.: el documento si se encuentra en vigor, ya que
la citada estructura lo ha aprobado. Se han propuesto nuevos
reglamentos: a nivel mundial; el WorldPolicy, que fue una
propuesta generada por Pablo Kleinman, fundador y primer
Coordinador Regional de la Argentina; y más recientemente, el
Policy5; pero ambas propuestas fueron desestimadas).

1 Esbozo

Este documento establece las reglas a seguir por
operadores de sistema (SysOps) que sean miembros de FidoNet: una
organización mundial de sistemas de tableros de boletines
electrónicos (electronic bulletin board systems o BBS).
FidoNet se define mediante un Listado de Nodos o NodeList,
actualizado semanalmente por el Coordinador Internacional.
Reglamentos adicionales pueden ser instaurados al nivel de
zona, región, o a nivel de red para proveer detalles adicionales
en procedimientos locales. Esos reglamentos de bajo nivel no
pueden contradecir este documento. Sin embargo, con la aprobación
del Coordinador Internacional, las reglas locales pueden ser
utilizadas para instrumentar diferencias, debido a condiciones
específicas locales.
Estas reglas locales no deben imponer restricciones
adicionales a los miembros de FidoNet, más allá de aquellas
incluidas en este documento; exceptuando la imposición de horarios
locales para intercambio de correspondencia.

1.0 Lenguaje

El lenguaje oficial de FidoNet es el idioma inglés. Todos
los documentos deberán existir en inglés. Se alienta la traducción
de los mismos a otros lenguajes.

1.1 Introducción

FidoNet es un sistema de correspondencia electrónica
amateur. Como tal, todos sus participantes y operadores son
voluntarios no pagos. Desde sus tempranos comienzos en 1984, como
una forma de intercambiar mensajes entre amigos, hoy día (1989)
incluye más de 5.000 sistemas en seis continentes.
FidoNet no es un medio de transporte común, o una red de
servicios de valor agregado; y es una red pública solamente y en
tanto los nodos constituyentes puedan proveer, individualmente,
acceso público a la red mediante su sistema. FidoNet es una red lo
suficientemente grande que podría caer por su propio peso
rápidamente, a menos que se le imponga alguna clase de estructura
y control. La operación de múltiples redes provee la estructura.
La administración descentralizada provee el control.
Este documento describe los procedimientos que han sido
desarrollados para administrar la red.

bbsfidonet #006

bbsfidonet@gmail.com (Vicente Fons) — Sat, 17 Jun 2006 15:16:00 +0200

En este número hablamos de los puntos, direcciones de bbs y punto, software especial para puntos y damos algunas direcciones interesantes que reproducimos a continuación:

Para saber mas del Blue Wave:

http://www.lacasadejara.org/paginaweb/jarabbs.html

Para saber mas sobre los puntos de fidonet:

http://www.ficbbs.org/puntos.html
http://www.txipinet.com/fido.php
http://www.terra.es/personal/jlgs2000/fido6.htm

bbsfidonet #005

bbsfidonet@gmail.com (Vicente Fons) — Wed, 24 May 2006 19:55:00 +0200

En este número tratamos de otros programas para acceder a BBS de forma un poco mas automatizada, y nos introduciremos en una BBS explicando paso a paso el proceso.

Los programas para acceso automatizado a las BBS son Blue Wave, QWK y Silver XPress.

Accedemos a PucelaBBS mediante telnet con los siguientes comandos:

En Windows telnet://pucelabbs.dyndns.org:3000
En Linux telnet pucelabbs.dyndns.org 3000

Para acceder a los programas antes mencionados, desde el menu principal tenemos que entrar por la opcion de mensajería y foros (M).

En la siguiente pantalla, entre otras opciones,al final tenemos la opción de correo offline en la opción (O).

Nos pedirá en otras pantallas que escojamos entre varios tipos de transferencia y compresores

Por fin llegamos a una pantalla en donde tenemos que indicar lo que queremos hacer y que está sin traducir, por lo que sólo está en inglés.

Básicamente las que mas utilizaremos serán:

Upload your replies para cuando queramos enviar nuestras respuestas.
Download your mail para recibir los mensajes y las respuestas a los nuestros.
Quit program y Goodbye que no hace falta explicar para que sirven

Además hay otras opciones, que normalmente sólo se utilizarán la primera vez para situar los diferentes indicadores, y algunas de forma excepcional para hacer un nuevo rescan de las áres, o bajarse de nuevo mensajes que por alguna razón se hayan perdido.

En realidad, es mucho mas fácil hacerlo que contarlo.

En el próximo número hablaremos de los puntos de fidonet.

bbsfidonet #004

bbsfidonet@gmail.com (Vicente Fons) — Sat, 20 May 2006 09:37:00 +0200

En este número ampliamos la lista de los programas para acceder a las BBS, tanto mediante llamada telefónica como por internet.

Programas de terminal para Windows:

Telix http://www.telix.com/delta/deltacom/tfw/index.html
NetTerm http://www.netterm.com/html/netterm.html
Procomm http://www.symantec.com/procomm/
QModem http://www.computerhope.com/software/qmodem.htm
Kermit http://www.columbia.edu/kermit/index-es.html
Zoc http://www.emtec.com/zoc/

Para Linux podemos utilizar Minicom

En los MAC se puede utilizar GLTerm http://www.pollet.net/GLterm/

Para DOS tenemos el Telix, Bananacom, Commo, Panther, Procomm, Qmodem, Telemate y Terminate.

Para MSX están Cacis, COMS6r9 y Erix

Para Commodore Amiga, el SkyTerminal, Gotcha, NComm, Term y TrapDoor

Para Commodore64 el SLKermit

Para Atari ST tenemos el StarCall

Programas para acceder por telnet vía internet:

Para Windows.

Syncterm http://syncterm.bbsdev.net/
mTELNET http://ozone.eesc.com/
Putty http://www.chiark.greenend.org.uk/~sgtatham/putty/
Netterm http://www.netterm.com/html/netterm.html
tn http://2f.ru/tn/
Zoc http://www.emtec.com/zoc/
Absolute Telnet http://www.celestialsoftware.net/

Para los diferentes sistema unix tenemos el Synmcterm

Para OS/2 el mTELNET, tn y Zoc

Para el Commodore Amiga, el AMTelnet

Para MAC

Nifty Telnet http://asg.web.cmu.edu/andrew2/dist/niftytelnet.html
Mac Telnet http://www.mactelnet.com/
NCSA Telnet http://www.macorchard.com/terminal.html
Data Comet http://www.databeast.com/

Tambien se puede acceder a algunas BBS con un programa de news, como por ejemplo:

news://news.rafastd.org

Y mediante un navegador web:

http://fido.beholderbbs.org

La dirección de este podcast es http://bbsfidonet.info y http://www.spnhome.com/spn1

bbsfidonet #003

bbsfidonet@gmail.com (Vicente Fons) — Wed, 17 May 2006 17:38:00 +0200

En este número explicamos como acceder a un BBS de la forma mas fácil, mediante llamada
telefónica con un programa de comunicaciones como el Hyper terminal de Windows o bien
vía internet mediante telnet.

Las direcciones que se han dado en el programa son las siguientes:

RafaSTD Madrid (España). Dirección telnet://bbs.rafastd.org Teléfono 915447282

Pucela BBS en Pucela (Valladolid) (España). Dirección telnet://pucelabbs.dyndns.org

Nervion BBS en Sevilla (España). Dirección telnet://nervionbbs.dyndns.org

Dock Sud BBS en Avellaneda (Argentina). Dirección telnet://bbs.docksud.com.ar

Ice BBS en Buenos Aires (Argentina). Dirección telnet://icebbs.com.ar

El Vicio BBS en Irapuato (México). Dirección telnet://elvicio.net

HidraSoft BBS en Aruja (Brasil). Dirección telnet://hidrasoft.dyndns.org

Fidotel BBS em Virginia (EE.UU.). Dirección telnet://telnet.fidotel.com

Este podcast se puede encontrar como ya es habitual en http://bbsfidonet.info y en http://www.spnhome.com/spn1

bbsfidonet #002

bbsfidonet@gmail.com (Vicente Fons) — Mon, 20 Mar 2006 23:11:00 +0100

En este número hablamos de Fidonet. Areas de FidoNet, generalidades, ventajas y desventajas respecto a otras formas de mensajería.

Para ver las áreas actuales acceder a la siguiente dirección: http://conecta2.thebbs.org/pucela_bbs/echolist.htm

La información de este podcast está basado en el FAQ sobre BBS e Internet recopilado por Komunero, Sysop de Pucela BBS.

bbsfidonet001

bbsfidonet@gmail.com (Vicente Fons) — Sat, 18 Mar 2006 14:26:00 +0100

En este primer número hablamos sobre que son las BBS, unas pinceladas sobre la red FidoNet, los sysops, los puntos, los programas mailer, QWK y Blue Wave para acceder a las BBS de forma automatizada. La información está basada en la FAQ sobre las BBS y FidoNet de Komunero, Sysop de Pucela BBS.

Promoción de bbsfidonet

bbsfidonet@gmail.com (Vicente Fons) — Wed, 15 Mar 2006 22:19:00 +0100

Promoción y bases de publicación del podcast.

La publicación no será periódica, si no que se hará cuando hayan noticias.

Para comenzar se realizarán varios podcast divulgativos sobre lo que es una BBS y la red FidoNet, y mas adelante se irán diciendo formas de acceso, direcciones y particularidades de diferentes BBS, así como programas de acceso, los diferentes estatus de usuario, los sysops y todo lo que se mueve en este mundo por muchas personas desconocido.

Todo el material para realizar este podcast será de procedencia mayoritaria de las propias BBS y Fidonet, siempre con el permiso de los autores o bien bajo CC o similar. Igualmente, la música, cuando se ponga será libre.

Sintonía: Mur de A truly inspiring piece of wax. Bajada de http://opsound.org