10 Apéndices10.1 Generalidades Los Apéndices de éste documento son excepciones al procesonormal de ratificación. La sección 10.2 puede ser modificada porel Coordinador de Zona apropiado, y la sección 10.3 puede sermodificada 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 observatodos los días, inclusive durante los fines de semana y díasfestivos y feriados. La hora se establece en base al Tiempo UniversalCoordinado (UTC en inglés), también conocido como tiempo delMeridiano 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 localcorrespondiente a la Hora de Correspondencia de la Zona (ZMH)cambiará, porque FidoNet no observa dichos períodos. El momentoexacto de la Hora de Correspondencia de Zona es dispuesto, paracada zona, por el Coordinador de Zona. En la Zona 1 de FidoNet, la Hora de Correspondencia de laZona es observada desde las 0900 hasta las 1000 UTC. En cada unade 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 laZona es observada desde las 0230 hasta las 0330 UTC. En la Zona 3 de FidoNet, la Hora de Correspondencia de laZona 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 soninstructivas para mostrar la aplicación de los procedimientos ymétodos generales. Cualquier decisión puede ser incluida en éste documentopor un voto mayoritario; ya sea del Consejo de Coordinadores deZona o bien por los Coordinadores Regionales. El Reglamento 4 cambia significativamente las funcionesdel Coordinador de Zona y de los Coordinadores Internacionales. En los siguientes casos, que fueron decididos utilizandoel 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 paradedicarse a prácticas comerciales faltas de ética. El Coordinador de la Red se sintió muy perturbado por estaactitud, y dio de baja del NodeList al nodo local. El nodo local apeló al Coordinador Regional para que se leasignara el status de nodo independiente. El Coordinador Regional, después de consultar con elCoordinador de la Red, decidió que el mismo tuvo razón al estarperturbado. 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 adosadoso "file attaches" para conseguir enviarse a sí mismo el archivoUSER.BBS (N. del T.: en este archivo, algunos programas, almacenanla información sobre los usuarios del BBS: datos personales,contraseña, etc.). de varios tableros locales (BBS). Losoperadores de estos tableros (BBS) se sintieron perturbados poréste comportamiento, y llamaron la atención a su Coordinador deRed, 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 Coordinadorde Red por fallar en proveerle servicios. Las respuestas delCoordinador de Red a sus quejas reiteradas no le satisficieron, demodo que llamó la atención al Coordinador Internacional (*). El Coordinador Internacional (*) desestimó la quejadebido 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 laqueja. Aconsejó y ayudó al Coordinador de Red a configurar susistema para proveer un mejor nivel de servicios a sus nodoslocales. El Coordinador Regional también decidió que el nodo localestaba sintiédose perturbado muy fácilmente, ya que estuvoreclamando servicios que normalmente no son requeridos de unCoordinador de Red. El nodo local fue informado en cuanto a las tareasespecíficas de un Coordinador de Red, y se le aconsejó quedisminuyera sus expectativas al respecto.10.3.4 El Caso "Busy Beaver" Un nodo local,, que era operado por un establecimientocomercial minorista, fue acusado de la realización de "corridas debombardeo" para enviar su propaganda a través de FidoNet. El Coordinador de la Red se sintió perturbado al tener quemanejar el tráfico de salida de correspondencia para una operacióncomercial, y le pidió al nodo local que abandonara la red. El nodo local apeló al Coordinador Regional, y le fuegarantizado 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 deritos vudú, "hacking", "phreaking", y distribución de materialobsceno apeló a un Coordinador de Red para obtener un número denodo. El Coordinador de Red consideró que el comportamiento deese tablero (BBS) era excesivamente perturbador, y le denegó susolicitud. El Coordinador Regional no fue consultado. El Coordinador Internacional (*), al ver que elCoordinador Regional no había sido consultado, desestimó el casoinmediatamente. Ninguna otra apelación fue hecha.10.3.6 El Caso del SysOps Inútil (Twit) Un usuario de diversos nodos locales, que funcionaban comoBBS, había sido rotundamente reconocido por todos los de losmismos como un inútil. El usuario obtuvo su propio sistema, se transformó enoperador 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 variasconferencias, ruteando su correspondencia a través de su red.Luego creó una conferencia de EchoMail propia y comenzó a rutearEchoMail entre varios sistemas, ruteando todo el tráfico decorrespondencia nuevamente a través de su red. Su Coordinador de la red observó que el desempeño de lamisma se estaba viendo seriamente afectado. Al nodo ofensor se leordenó detener sus actividades. Se llegó a un compromiso, donde gran parte del tráfico delEchoMail no fue enviado más a través de la red y el EchoMailruteado 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 promoveruna obra de caridad. La computadora fue también utilizada paraotras actividades diversas durante el día, y el operador delsistema era, con frecuencia, requerido lejos de su lugar deresidencia. Sus colaboradores frecuentemente olvidaban poner enmarcha 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 derecibir correspondencia, lo marcaba como "de baja". Cuando eloperador del nodo regresaba, ponía en marcha el tablero, y pedíaser restablecido. Con el tiempo, el Coordinador de la Red decidió que eloperador del nodo no había sido capaz de mantener su sistemafuncionando confiablemente, y lo retiró del NodeListdefinitivamente. Fueron rechazadas posteriores solicitudes delmismo operador para un número de nodo. No se hicieron apelaciones.

Ver todos los episodios