octubre 01, 2006
bbsfidonet #018
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.
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.
# posted by Vicente Fons @ 10:54 a. m. 
