Устав FidoNet
Версия 4.07 9 июня, 1989

               
(продолжение)
4 Процедуры Координатора Сети

4.1 Обязанности

Координатор Сети выполняет следующие обязанности:

   1) Принимает входящую корреспонденцию  для  узлов  сети,  и
      устраивает ее пересылку получателям.

   2) Присваивает узловые номера узлам сети.

   3) Ведет NodeList сети,  и посылает его копию Региональному
      Координатору, когда он меняется.

   4) Обеспечивает доступ узлов сети к новым файлам различий в
      NodeList'e,  новым выпускам FidoNews,  и новым редакциям
      Уставных Документов Сети по мере их получения,  и перио-
      дически  проверяет,  чтобы  узлы пользовались последними
      доступными NodeList'ами.


4.2 Пересылка неограниченного объема корреспонденции

В вашей  власти  как  Координатора Сети координировать прием и
пересылку неограниченного объема Host-направленной Netmail уз-
лам  вашей  сети.  Hа ваше усмотрение остаются все связанные с
этим вопросы.

Если какой-либо узел вашей сети получает  большой  объем  кор-
респонденции, вы можете запросить SysOp'a, чтобы он связался с
системой,  посылающей эту корреспонденцию,  и запросил  ее  не
направлять  корреспонденцию  Host'у.  Если проблему не удалось
решить, вы можете запросить своего Регионального Координатора,
чтобы  он присвоил узлу номер,  как независимому в регионе,  и
исключил систему из сети.

Иногда какой нибудь узел  начинает  "бомбардировку"  (посылает
одно  сообщение многим узлам).  Если узел другой сети осущест-
вляет бомбардировки ваших узлов и  направляет  корреспонденцию
через ваш Host, вы можете подать жалобу Координатору Сети это-
го узла.  (Если этот узел независим,  вы подаете жалобу Регио-
нальному Координатору.) Бомбардировки считаются некорректными.

Другая причина маршрутной перегрузки - Еchomail.  Hедопустимо,
чтобы Еchomail уменьшала возможности FidoNet по обработке тра-
фика  нормальных сообщений.  Если узел в вашей сети пересылает
большой объем Еchomail, вы можете попросить SysOp'a либо огра-
ничить объем Еchomail, либо прекратить пересылку Еchomail.

От вас не требуется пересылать кодированную,  коммерческую или
незаконную корреспонденцию.  Однако,  если вы  не  пересылаете
корреспонденцию,  вы  должны выполнить процедуры,  описанные в
разделе 2.1.7.


4.3 Присвоение узловых номеров

В ваши обязанности входит присваивать узловые номера новым уз-
лам вашей сети.  Вы можете также поменять номера  существующих
узлов,  хотя перед этим необходимо предупредить остальные узлы
сети.  Вы можете присваивать любые номера, следя за тем, чтобы
каждый узел имел в сети свой уникальный номер.

Вы не  должны  присваивать  узловой номер любой системе до тех
пор,  пока не получите формальный запрос от  этой  системы  по
"почте" FidoNet. Это гарантирует, что система минимально рабо-
тоспособна. Строгое соблюдение этого правила является одной из
основ FidoNet.

Также рекомендуется, хотя и не обязательно, связаться с систе-
мой,  которая запрашивает узловой номер, до того как присвоить
ей номер.

Вы не  можете  присваивать узловой номер узлу,  находящемуся в
местности,  покрывающейся существующей сетью. Кроме того, если
некоторые из ваших узлов находятся в местности,  покрывающейся
создаваемой сетью, эти узлы должны быть переданы новой сети.

Вы должны пользоваться Netmail,  чтобы сообщить новому SysOp'у
его  узловой номер,  т.к.  это поможет убедиться в возможности
системы принимать Netmail.

Если один из узлов вашей сети действует некорректно, вы можете
предпринять любые меры, которые вам кажутся соответствующими в
данных обстоятельствах.


4.4 Ведение NodeList'a

Вы должны вносить изменения имен, телефонных номеров, и т.д. в
ваш отрывок NodeList'a как можно быстрее после  получения  ин-
формации от заинтересованных узлов. Вы должны также при случае
посылать сообщения каждому узлу сети, чтобы убедиться в их ра-
ботоспособности.  Если  узел  не отвечает без предварительного
предупреждения,  вы должны либо отметить это,  либо  исключить
узел из NodeList'a. (Узлы могут находиться в списке не отвеча-
ющих максимум две недели, после чего линия должна быть удалена
из NodeList'a.)

По вашему усмотрению, вы можете распределять часть своей рабо-
чей нагрузки на почтовые буферы.  В этом случае, вы должны по-
лучать  NodeList'ы  от  Координаторов Буферов вашей сети.  Вам
потребуется вести NodeList'ы для каждого  буфера  вашей  сети,
т.к.  вы  не можете расчитывать на еженедельное получение исп-
равлений от каждого Координатора Буфера. Вы должны еженедельно
собирать общий NodeList вашей сети и посылать его Регионально-
му Координатору к установленному дню и времени. Предпочтитель-
но делать это как можно позднее,  чтобы внести последние изме-
нения,  но принимая во внимание возможность потери связи с Ре-
гиональным Координатором и таким образом пропуска недели.


4.5 Распространение Уставов, NodeList'ов и FidoNews

Как Координатор Сети, вы должны еженедельно получать от своего
Регионального  Координатора новый выпуск FidoNews и новый файл
различий с предыдущим NodeList'ом.  Файл различий с предыдущим
NodeList'ом в настоящее время распространяется по субботам,  а
FidoNews выходит по понедельникам.  Вы  должны  распространять
эти файлы среди всех узлов сети, и поощряется их распростране-
ние по линиям связи.

Вы должны также получать последние версии Уставов и других до-
кументов  сети,  и  распространять  их среди узлов вашей сети.
Уставы выходят непериодично,  поэтому вы должны сообщить узлам
своей сети,  когда это происходит, и убедиться, что узлы в об-
щем знакомы с изменениями.

Устав, FidoNews и NodeList - это  основа,  которая  объединяет
нас.  Без  них  мы  перестали бы быть сообществом,  и стали бы
просто еще одной разрозненой группой BBS.



5 Процедуры Регионального Координатора

5.1 Обязанности

Региональный Координатор выполняет следующие обязанности:

   1) Присваивает узловые номера независимым узлам региона.

   2) Поощряет присоединение независимых узлов региона  к  су-
      ществующим сетям, или создание ими новых сетей.

   3) Присваивает сетевые номера сетям в своем регионе и опре-
      деляет их границы.

   4) Создает общий NodeList всех сетей  и  независимых  узлов
      региона и посылает его копию Координатору Зоны, когда он
      изменяется.

   5) Обеспечивает бесперебойную работу сетей в регионе.

   6) Расространяет  новые  файлы  различий   от   предыдущего
      NodeList'a,  Уставы и выпуски FidoNews среди Координато-
      ров Сетей региона настолько быстро,  насколько это  воз-
      можно.


5.2 Присваивание узловых номеров

Вы обязаны присваивать узловые номера независимым узлам регио-
на.  Вы  также  можете  менять номера существующих узлов сети,
предварительно сообщив об этом соответствующим узлам. Вы може-
те присваивать любые номера,  следя за тем,  чтобы каждый узел
имел в сети свой уникальный номер.

Вы не должны присваивать узловой номер любой  системе  до  тех
пор,  пока  не  получите  формальный запрос от этой системы по
"почте" FidoNet. Это гарантирует, что система минимально рабо-
тоспособна. Строгое соблюдение этого правила является одной из
основ FidoNet.

Также рекомендуется, хотя и не обязательно, связаться с систе-
мой,  которая запрашивает узловой номер, до того как присвоить
ей номер.

Вы должны пользоваться Netmail,  чтобы сообщить новому SysOp'у
его  узловой номер,  т.к.  это поможет убедиться в возможности
системы принимать Netmail.

Если один из узлов вашей сети действует некорректно, вы можете
предпринять любые меры, которые вам кажутся соответствующими в
данных обстоятельствах.

Если вы получаете запрос узлового номера не из своего региона,
вы должны переслать запрос соответствующему координатору само-
го низкого возможного уровня,  который вы сможете  определить.
Если вы получаете запрос узлового номера от нового узла, нахо-
дящегося в местности, покрываемой существующей сетью, вы долж-
ны переслать запрос соответствующему Координатору Сети, вместо
того, чтобы присваивать номер самому.

Если в местности,  где находятся ваши независимые узлы, созда-
ется новая сеть, эти узлы должны быть переданы в эту сеть, как
только это будет возможно.


5.3 Поощрение создания и роста сетей

Одной из ваших основных обязанностей как Регионального Коорди-
натора является стимулирование роста сетей вашего региона.

Вы должны избегать наличия в регионе независимых узлов,  нахо-
дящихся в местности,  покрываемой сетью. Однако существуют оп-
ределенные случаи,  когда узел не должен быть членом сети, как
например система с неограниченным объемом Netmail;  см. раздел
4.2.

Если несколько независимых узлов вашего  региона  находятся  в
одной местности, вы должны поощрять их к созданию сети, а если
это необходимо, вы можете потребовать от них создать сеть. См.
раздел 2.4.  Имейте в виду,  что это не значит,  что вы должны
поощрять создание мелких сетей. Очевидно, что один узел не яв-
ляется сетью. Точное число узлов, которое требуется для созда-
ния эффективной сети,  должно определяться по обстоятельствам,
и остается на ваше усмотрение.

5.4 Присвоение сетевых номеров

В ваши обязанности входит присвоение сетевых номеров новым се-
тям, создающимся в вашем регионе. Координатор Зоны присваивает
вам определенный диапазон сетевых номеров для этих целей.  Как
часть этой функции, в ваши обязанности как Регионального Коор-
динатора входит определение границ сетей вашего региона.


5.5 Ведение NodeList'a

Как Региональный Координатор, вы выполняете двоякую роль в ве-
дении NodeList'a региона.

Во-первых, вы  должны  вести список независимых узлов региона.
Вы должны по возможности быстро вносить в  NodeList  изменения
имен,  телефонных  номеров и т.д..  Вы должны также при случае
посылать сообщения каждому узлу сети, чтобы убедиться в их ра-
ботоспособности.  Если  узел  не отвечает без предварительного
предупреждения,  вы должны либо отметить это,  либо  исключить
узел из NodeList'a. (Узлы могут находиться в списке не отвеча-
ющих максимум две недели, после чего линия должна быть удалена
из NodeList'a.)

Во-вторых, вы  должны получать NodeList'ы от Координаторов Се-
тей вашего региона.  Вам потребуется вести NodeList'ы для каж-
дой сети вашего региона, т.к. вы не можете расчитывать на еже-
недельное получение исправлений от каждого Координатора  Сети.
Вы должны еженедельно собирать общий NodeList вашего региона и
посылать его Координатору Зоны к установленному дню и времени.
Предпочтительно  делать  это  как можно позднее,  чтобы внести
последние изменения, но принимая во внимание возможность поте-
ри связи с Координатором Зоны и таким образом пропуска недели.

5.6 Географические освобождения

Встречаются случаи,  когда  география местных телефонных сетей
не совпадает с регионами FidoNet.  В исключительных случаях по
соглашению  с заинтересованными Региональными Координаторами и
Координаторами Зон допускаются  освобождения  от  действующего
обычно географического принципа.  Такие исключения не являются
правом, и не постоянны. Когда в соответствующем регионе созда-
ется  сеть,  обеспечивающая  доступ  к  освобожденному узлу по
местным телефонным линиям,  такой узел перестает быть освобож-
денным.  Освобождение может быть пересмотрено и отозвано в лю-
бое время любым заинтересованным координатором.


5.7 Hадзор за работой сетей

В ваши обязанности входит назначение Координаторов Сетей в ва-
шем регионе.  Если уходящий Координатор Сети предлагает своего
преемника, вы не обязаны принимать эту кандидатуру, хотя обыч-
но вы ее принимаете.

Вы, как Региональный Координатор,  отвечаете за то, чтобы сети
в  вашем регионе работали в допустимой манере.  Это не значит,
что от вас требуется управлять деятельностью этих  сетей;  это
входит в обязанности Координаторов Сетей.  Hо это значит,  что
вы должны следить за тем, чтобы Координаторы Сетей в вашем ре-
гионе выполняли свои обязанности.

Если вы  пришли к выводу,  что Координатор Сети вашего региона
плохо выполняет свои обязанности,  описанные в Разделе  4,  вы
можете предпринять любые меры,  которые, по вашему мнению, не-
обходимы для того, чтобы исправить ситуацию.

Если сеть становится настолько большой,  что  не  может  спра-
виться с прохождением трафика за время ZMH, Региональный Коор-
динатор может создать из этой сети еще одну  или  более  новых
сетей.  Эти  новые сети,  хотя они могут находиться в пределах
одной местной телефонной сети, при определении членства должны
все же руководствоваться географическим принципом.

Ваша обязанность,  как Регионального Координатора, - поддержа-
ние с разумной периодичностью прямого контакта с сетями вашего
региона.  Выбор  способа выполнения этих обязанностей остается
на ваше усмотрение.


5.8 Распространение Уставов, NodeList'ов и FidoNews

Как Региональный  Координатор,  вы  должны получать новый файл
различий с предыдущим NodeList'ом,  уставы сетей и  новые  вы-
пуски FidoNews по мере их выхода и распространять их среди Ко-
ординаторов Сетей вашего  региона.  NodeList  распространяется
еженедельно  по субботам Координатором Зоны,  а FidoNews изда-
ется по понедельникам узлом 1/1.  Свяжитесь с ними для выясне-
ния деталей о том, как получать еженедельно последние копии.

В ваши обязанности входит распространение этого материала сре-
ди всех Координатов Сетей вашего  региона  как  можно  быстрее
после  его  получения.  Как вы это сделаете,  остается на ваше
усмотрение.  От вас не требуется распространять их среди неза-
висимых узлов региона,  хотя если вы хотите, вы можете это де-
лать.  Поощряется распространение этих  документов  по  линиям
связи для ознакомления с ними широкой публики.



6 Процедуры Координатора Зоны

6.1 Общие

Первоочередной задачей  каждого  из  Координаторов Зон FidoNet
является ведение NodeList'a Зоны  и  распространение  главного
NodeList'a  (или файла различий) в Регионах Зоны.  Координатор
Зоны также отвечает за координацию распространения  документов
Устава Сети и FidoNews среди Региональных Координаторов Зоны.

В обязанности Координатора Зоны входит обеспечение бесперебой-
ной деятельности сети в Зоне,  которое осуществляется назначе-
нием и надзором за Региональными Координаторами.

Если Координатор Зоны определяет, что Региональный Координатор
плохо выполняет свои обязанности,  перечисленные в разделе  5,
должна быть найдена замена.

Координатор Зоны устанавливает географические границы регионов
Зоны и назначает время Zone Mail Hour.

Координатор Зоны отвечает за пересмотр и утверждение любых ге-
ографических освобождений, описанных в разделе 5.6.

Координатор Зоны  отвечает за обеспечение бесперебойной работы
шлюзов между зоной и другими зонами,  передающих корреспонден-
цию между зонами.

Координаторы Зон  выбирают из своей среды Международного Коор-
динатора.


6.2 Выборы

Координатор Зоны  выбирается  абсолютным  большинством голосов
Региональных Координаторов зоны.


7 Процедуры Международного Координатора

7.1 Общие

Международный Координатор  - это "первый среди равных" Коорди-
натор Зоны.

Первоочередной задачей  Международного  Координатора  является
создание главного NodeList'a,  которая осуществляется управле-
нием распределения NodeList'ов Зон между Зонами. Международный
Координатор отвечает за определние новых зон, а также за веде-
ние переговоров и заключение соглашений о коммуникации с  дру-
гими сетями.  ("Другие сети" в этом контексте означают сети, с
которыми Fidonet взаимодействует на равных, а не "сети" в зна-
чении организационного уровня FidoNet.)

Международный Координатор  также отвечает за координацию расп-
ределения Уставов Сети и FidoNews среди Координаторов Зон.

Международный Координатор отвечает за координацию деятельности
Совета  Координаторов Зон.  Международный Координатор является
представителем Совета Координаторов Зон.

По вопросам,  не рассмотренным подробно в этом документе, Меж-
дународный  Координатор  может  издавать конкретные толкования
или дополнения к этому Уставу.  Совет Координаторов Зоны может
отменить эти документы большинством голосов.


7.2 Выборы

Международный Координатор  избирается (или смещается со своего
поста) абсолютным большинством голосов Координаторов Зон.


8 Референдумы

Процедуры, описанные в этом разделе,  используются при ратифи-
кации новой версии устава FidoNet и представляют  собой  меха-
низм  изменения  устава.  Эта процедура также используется при
вынесении вотума недоверия Координатору Зоны.


8.1 Проведение референдума

Референдум по вопросу изменения устава проводится, когда боль-
шинство Региональных Координаторов FidoNet  сообщают  Междуна-
родному  Координатору,  что они хотят рассмотреть предлагаемую
новую версию Устава.


8.2 Объявление и результаты

Предполагаемые изменения Устава распространяются с использова-
нием той же структуры,  которая используется для распределения
файлов  различий NodeList'a и FidoNews.  Результаты и объявле-
ния, связанные с референдумом, распространяются структурой ко-
ординаторов как часть еженедельного файла различий NodeList'a.
Международный  Координатор   предоставляет   копии   редактору
FidoNews для включения в выпуск, хотя официальное объявление и
даты голосования привязываются к распределению NodeList'a.

В случае  принятия  нового  устава  Международный  Координатор
устанавливает дату его вступления в силу и объявляет ее в еже-
недельном файле различий NodeList'a.  Документ вступает в силу
не позднее одного месяца после завершения голосования.


8.3 Право голоса

Каждый член структуры координаторов FidoNet на уровне  и  выше
Координатора Сети имеет один голос. (Координаторы почтовых бу-
феров не имеют права голоса.) В случае,  если во время голосо-
вания в должность вступает новый координатор, голосовать может
либо он сам, либо его предшественник, но не оба. Если один че-
ловек совмещает более одной должности координатора,  он тем не
менее имеет только один голос.

Предполагается, что Координаторы Сетей оценивают мнение членов
своей  сети,  и голосуют соответственно.  Проводить формальное
голосование не требуется, но Координатор Сети должен проинфор-
мировать сеть о вопросах и договориться о позиции сети.  Коор-
динатор  Сети  действует  как  представитель  рядовых   членов
FidoNet.


8.4 Механизм голосования

Фактический механизм голосования,  включая вопрос о том, будет
ли  голосование  тайным,  как будут собираться,  проверяться и
подсчитываться голоса,  устанавливается по усмотрению Междуна-
родного Координатора.  В идеале,  сбор голосов должен осущест-
вляться с помощью надежно защищенной системы связи,  обеспечи-
ваемой самой FidoNet.

Для обеспечения достаточного времени обсуждения, любое голосо-
вание должно быть объявлено не позднее чем за  две  недели  до
его начала.  Время сбора голосов не должно быть менее двух не-
дель.


8.5 Голосование по Уставу в целом

Поскольку этот  Устав  взаимно переплетается и содержит ссылки
на себя,  то  сравнительно  простое  изменение  может  повлечь
несколько  изменений  в документе.  Для упрощения процесса при
голосовании делается выбор между целыми документами, а не меж-
ду отдельными изменениями.  В простейшем случае,  это означает
голосование "за" и "против" по новому документу. Если рассмат-
риваются  несколько альтернатив,  они должны быть представлены
целыми документами, из которых выбирается один.


8.6 Принятие решения

Изменение Устава считается вступившим в силу если, после окон-
чания сбора голосов,  оно получило  большинство  поданных  го-
лосов.  апример,  если 350 человек имело право голоса, из них
100 подали голоса, то для объявления вступления в силу измене-
ния требуется как минимум 51 голос "за".

В случае  рассмотрения нескольких изменений устава в одном го-
лосовании,  версия должна получить более 50% поданных голосов,
чтобы  быть ратифицированной.  В этом случае голоса воздержав-
шихся от голосования влияют на результат,  будучи по  существу
голосами против изменения текущего устава, т.к. они увеличива-
ют количество голосов,  требуемых для ратификации предлагаемых
изменений.


8.7 Вотум недоверия Координатору Зоны

8.7.1 Проведение

В исключительных случаях, Координатору Зоны может быть вынесе-
но недоверие в результате референдума. Вотум недоверия Коорди-
натору Зоны не обязательно проводится в  результате  нарушения
Устава.  Вотум недоверия объявляется, когда большинство Регио-
нальных Координаторов зоны требуют его проведения от  Междуна-
родного Координатора.

8.7.2 Процедура, аналогичная референдуму по уставу

Положения разделов 8.2 и 8.3 применимы к проведению вотума не-
доверия.

Применимо определение понятия  "большинство"  в  разделе  8.6.
Право  голоса имеют только координаторы данной зоны (даже если
Координатор Зоны является также Международным Координатором).

8.7.3 Механизм голосования

Региональный Координатор,  назначенный Координатором Зоны, ко-
торому выносится вотум недоверия,  устанавливает процедуры го-
лосования,  проводит сбор голосов и объявляет результаты. Сме-
щение  Координатора  Зоны  производится  в течение двух недель
после окончания голосования, если вотум вынесен.

8.7.4 Ограничение проведения вотума одним в год

Смещение Координатора Зоны в первую очередь является  механиз-
мом,  с  помощью которого сеть в целом выражает неудовольствие
толкованием Устава Координатором Зоны.  В том или ином случае,
все бывают недовольны тем, как толкуется Устав. Для того, что-
бы Координаторы Зон все же толковали Устав, а не занимались бы
только тем, что защищали себя, между вотумами должен проходить
как минимум один календарный год (независимо от того, как мно-
го человек занимает пост Координатора Зоны в течение этого го-
да.)

Если Координатор Зоны уходит в отставку  во  время  проведения
вотума,  вотум считается не имеющим силы и недействительным, и
не входит в квоту "один в год".


9 Урегулирование конфликтов

9.1 Общие процедуры

Юридическая философия FidoNet может быть выражена двумя прави-
лами:

     1) Ты  не должен быть чрезмерно некорректным по отношению
к другим.

     2) Ты не должен слишком легко раздражаться  из-за  некор-
        ректного поведения по отношению к себе.

Другими словами, каких-нибудь строгих правил не существует, но
ожидается вежливое поведение.  Также, в любом конфликте обсуж-
дается  вина каждой стороны,  и меры могут быть приняты против
любой из них или их обеих. ("Hе суди, да не судим будешь!")

Ответственность за определение "чрезмерно некорректного  пове-
дения"  лежит  на структуре координаторов.  Как и общепринятое
определение порнографии ("Я не могу определить это,  но  знаю,
что это,  когда я это вижу."),  точное определение допустимого
поведения в FidoNet  невозможно.  Основные  направления  этого
устава  намеренно  оставлены  недостаточно конкретными,  чтобы
обеспечить структуре координаторов ту свободу,  которая им не-
обходима для соответствия нуждам растущего и меняющегося сооб-
щества.

Первый шаг в любом конфликте между  SysOp'ами  -  это  попытка
SysOp'ов   связаться  напрямую,  по  крайней  мере  с  помощью
Netmail,  но лучше по обычному телефону. Если, подавая жалобу,
вы  пропустили  этот  основной  этап,  ваша  жалоба  не  будет
рассматриваться.

Рассмотрение формальной жалобы - это действие,  к которому  не
следует легкомысленно относиться. Расследование и принятие мер
по жалобе требует времени,  которое координаторы предпочли  бы
потратить  на  более  конструктивную  деятельность.  Тот,  кто
настаивает на рассмотрении мелких жалоб по  нарушению  устава,
может оказаться виновным в "чрезмерно некорректной" подаче жа-
лобы. Жалобы должны сопровождаться убедительными доказательст-
вами,  обычно копиями сообщений;  просто голословные жалобы не
рассматриваются.

Hесоблюдение описанных здесь процедур (в частности,  обращение
через  голову координатора,  или обращение к координатору,  не
входящему в цепочку аппеляции) само по  себе  является  некор-
ректным поведением.


9.2 Проблемы с другим SysOp'ом

Если у вас возникли проблемы с другим SysOp'ом, вы должны пер-
вым делом попробовать урегулировать их через Netmail или в те-
лефонном разговоре с этим SysOp'ом.

Если при этом не удалось решить проблему, вы должны подать жа-
лобу  вашему  Координатору  Сети  и  Координатору Сети другого
SysOp'a.  Если вы, или вы оба не входите в сеть, вы должны по-
дать жалобу соответствующему Региональному Координатору.  Если
при этом вы не будете удовлетворены,  вы имеете право на аппе-
ляцию, процесс которой описан в разделе 9.5.


9.3 Проблемы с вашим Координатором Сети

Если у вас возникли проблемы с вашим Координатором Сети и  вам
кажется,  что с вами поступают неправильно, вы имеете право на
рассмотрение данной ситуации. Как и во всех конфликтах, первым
шагом является попытка решить проблему, связавшись напрямую.

Следующим шагом  вы связываетесь со своим Региональным Коорди-
натором. Если ваш случай заслуживает рассмотрения по существу,
возможны разные варианты предпринятых мер, включая смену Коор-
динатора Сети или даже расформирование вашей  сети.  Если  вам
было отказано в общении вашим Координатором Сети,  это решение
может быть отменено, и вы будете восстановлены в сети.

Если вы останетесь недовольны решением Регионального Координа-
тора,  вы имеете право на аппеляцию,  процесс которой описан в
разделе 9.5.


9.4 Проблемы с другими координаторами

Жалобы на  некорректное поведение любых координаторов рассмат-
риваются, как описано в разделе 9.2, и должны подаваться коор-
динатору следующего уровня.  Hапример,  если вам кажется,  что
ваш Региональный Координатор виновен в некорректном  поведении
(в противоположность неспособности исполнять обязанности коор-
динатора), вы должны подать свою жалобу Координатору Зоны.

Жалобы, касающиеся деятельности координатора по выполнению  им
обязанностей,  предусмотренных уставом,  принимаются только от
уровня,  непосредственно под ним. апример, жалобы, касающиеся
деятельности Регионального Координатора,  принимаются от Коор-
динаторов Сетей и  независимых  узлов  региона.  Такие  жалобы
должны  направляться  Координатору  Зоны после соответствующих
попыток решить проблемы с помощью непосредственного общения.


9.5 Процесс аппеляции

Hа решение,  принятое координатором, может быть подана аппеля-
ция следующему уровню.  Аппеляция должна быть подана в течение
двух недель после принятия решения,  на которое подается аппе-
ляция.  Все аппеляции должны следовать по цепочке  управления;
если пропущены уровни, аппеляция немедленно отклоняется.

Результатом аппеляции не будет полное расследование, а решение
будет принято на основе документов,  предоставленных сторонами
на нижнем уровне.  Hапример, при рассмотрении аппеляции на ре-
шение Координатора Сети Региональный Координатор будет пользо-
ваться  информацией,  предоставленной этим координатором и по-
давшим жалобу SysOp'ом;  Региональный  Координатор  не  обязан
предпринимать попытки независимого сбора информации.

Аппеляция имеет следующую структуру:

   Аппеляции на  решения  Координатора  Сети могут быть поданы
   соответствующему Региональному Координатору.

   Аппеляции на решения Регионального Координатора могут  быть
   поданы соответствующему Координатору Зоны. Координатор Зоны
   принимает решение и доводит его до Региональных Координато-
   ров этой зоны. Это решение может быть отменено большинством
   голосов Региональных Координаторов.

   Аппеляции на решения Координатора Зоны  могут  быть  поданы
   Международному Координатору. Международный Координатор при-
   нимает решение и доводит его до Совета  Координаторов  Зон,
   который может отменить его большинством голосов.

Если у вас возникла проблема с самим Координатором Зоны, т.е.,
Координатор Зоны нарушил устав по отношению к вам, ваша жалоба
должна быть подана Международному Координатору, который примет
решение и сообщит о нем Совету Координаторов Зон для возможной
отмены, как описано выше.


9.6 Ограничения срока рассмотрения жалобы

Жалоба не может рассматриваться более 60 дней,  начиная с даты
обнаружения источника нарушения,  либо по признанию, либо тех-
нической уликой.  Жалобы не могут  рассматриваться  более  120
дней с момента происшествия,  если это не определенно незакон-
ное поведение.


9.7 Право на быстрое решение

От координатора  требуется вынести окончательное решение и из-
вестить заинтересованные стороны в течение 30 дней  с  момента
получения жалобы или аппеляции.


9.8 Возвращение в первоначальную сеть

Если конфликт по уставу решен,  любые узлы,  восстановленные в
результате аппеляции,  возвращаются в локальную сеть или реги-
он, к которым они географически или технически принадлежат.


9.9 Echomail

Echomail является  важным  и  мощным  средством  FidoNet.  При
рассмотрении конфликтов по уставу,  Echomail - это просто раз-
новидность Netmail,  и, таким образом, покрывается Уставом. По
своей природе,  Echomail налагает уникальные технические и со-
циальные  требования  к сети,  кроме тех,  которые покрываются
данной версией Устава. Таким образом, устав Echomail, расширя-
ющий общий Устав (и не противоречащий ему), поддерживаемый Ко-
ординаторами Echomail,  и ратифицированный в процессе,  анало-
гичном  этому  документу,  признается  Координаторами  FidoNet
действительной структурой для решения конфликтов по  вопросам,
относящимся  к  Echomail.  В будущем устав Echomail может быть
объединен с данным документом.


9.10 История прецедентов

Большая часть Устава Fidonet по своей природе такова,  что мо-
жет быть истолкована различным образом.  Hикто не  может  ска-
зать,  что нас ждет в этом постоянно изменяющемся мире.  Устав
сам по себе является лишь частью того,  что используется в ка-
честве основных правил при посредничестве в конфликтах - такой
же или даже более важной частью являются прецеденты.

Для согласования этого процесса истории прецедентов могут быть
добавлены или удалены из данного документа Международным Коор-
динатором,  решение которого может быть отменено Советом Коор-
динаторов  Зон.  Если  Устав изменен в сторону отмены действия
прецедента,  Устав перекрывает этот прецедент. (Тщательно под-
готовленное  изменение  предотвращает  такую ситуацию,  удаляя
ссылку на прецедент, как часть изменения.

Хотя описание прецедента может быть удалено, история прецеден-
та  не может быть изменена никоим образом.  История прецедента
написана примерно во время решения по нему, теми, кто вовлечен
в него. Изменение текста истории прецедента - это то же самое,
что переписывание истории, нечто совершенно неприемлемое в ор-
ганизации, занимающейся пересылкой информации.



10 Приложения

10.1 Общие

Приложения к  этому документу являются исключениями в нормаль-
ном процессе ратификации. Раздел 10.2 может быть изменен соот-
ветствующим Координатором Зоны, а раздел 10.3 может быть изме-
нен Международным Координатором (см. Раздел 9.10.


10.2 Время Zone Mail Hour

Zone Mail  Hour  соблюдается  ежедневно,  включая  выходные  и
праздники.  Его время основано Международном  Координированном
Времени  (UTC  - Universal Coordinated Time),  также известном
как Время Гринвичского Меридиана (GMT - Greenwich Mean  time).
В  тех  местах,  где на некоторое время в году вводится летнее
время,  местное время ZMH меняется,  т.к. FidoNet не соблюдает
летнее время. Точное время ZMH устанавливается для каждой зоны
Координатором Зоны.

В Зоне 1 FidoNet,  Zone Mail Hour установлен с 09.00 до  10.00
по Гринвичу. В каждой из часовых поясов, это соответствует:

     Eastern Standard Time 04.00 - 05.00 Central Standard Time
     03.00 -  04.00  Mountain  Standard  Time  02.00  -  03.00
     Pacific  Standard Time 01.00 - 02.00 Hawaii Standard Time
     23.00 - 00.00

В Зоне 2 FidoNet,  Zone Mail Hour установлен с 02.30 до  03.30
по Гринвичу.

В Зоне  3 FidoNet,  Zone Mail Hour установлен с 18.00 до 19.00
по Гринвичу. В каждом из часовых поясов, это соответствует:


  Пояс +12 GMT 06.00 - 07.00 (овая Зеландия)

  Пояс +10  GMT  04.00  - 05.00 (Восточная Австралия) (Папуа -
  овая Гвинея) (Микронезия)

  Пояс +9,5 GMT 03.30 - 04.30 (Центральная Австралия)

  Пояс +9 GMT 03.00 - 04.00 (Япония) (Корея) (Восточная  Индо-
  незия)

  Пояс +8  GMT  02.00 - 03.00 (Гонконг) (Тайвань) (Центральная
  Индонезия) (Филиппины)

  Пояс +7 GMT 01.00 - 02.00  (Малайзия)  (Сингапур)  (Таиланд)
  (Западная Австралия) (Западная Индонезия)


10.3 Истории прецедентов

Истории, описывающие прошлые конфликты, показательны, т.к. по-
казывают  общие  процедуры и методы.  Любое решение может быть
включено в этот документ большинством голосов либо Совета  Ко-
ординаторов Зоны, либо Региональных Координаторов.

Устав4 вносит  значительные  изменения в функции Координаторов
Зон и Международного Координатора.  В следующих случаях, реше-
ния  по  которым принимались на основании Устава3,  подставьте
"Координатор Зоны" везде, где встречается "Международный Коор-
динатор(*)".


10.3.1 Случай нечестного SysOp'a

SysOp одного из локальных узлов использовал  Netmail  в  своей
неэтичной деловой практике.  Координатор Сети посчитал это не-
корректным поведением и исключил этот узел из NodeList'a.

SysOp этого узла обратился к Региональному Координатору, чтобы
зарегистрироваться в качестве независимого узла.  Региональный
Координатор,  проконсультировавшись с Координатором Сети,  ре-
шил, что Координатор Сети принял правильное решение. Узлу было
отказано в статусе независимого.

Международный Координатор(*) не вмешивался.


10.3.2 Случай Mailer'a - хакера

A sysop  of  a  local node made use of file attaches for extra
users to mail himself the USER.BBS  file  from  several  local
boards.  Sysop'ы этих BBS посчитали его поведение некорректным
и обратились к Координатору Сети,  который согласился и исклю-
чил некорректный узел из NodeList'a.

Консультации с Региональным Координаторм не проводились.

Международный Координатор(*) не вмешивался.


10.3.3 Случай беспокойного крикуна

Локальный узел был недоволен Координатором Сети,  который,  по
его мнению. не предоставлял достаточно услуг. Постоянные жало-
бы Координатору сети не удовлетворили его,  поэтому  он  обра-
тился к Международному Координатору(*).

Международный Координатор(*)  не  стал  рассматривать  жалобу,
т.к. жалоба не подавалась Региональному Координатору.

Локальный узел подал жалобу Региональному Координатору,  кото-
рый  расследовал  этот случай и пришел к выводу,  что какая-то
доля истины в жалобе была.  Он дал совет и помог  Координатору
Сети  конфигурировать  его  систему  таким образом,  чтобы она
обеспечивала более высокий уровень услуг локальным узлам.

Региональный Координатор также решил,  что локальный узел  был
недоволен,  ожидая услуг,  не требуемых обычно от Координатора
Сети.  Локальный узел был проинформирован об истинных  обязан-
ностях  Координатора  Сети,  и  ему также посоветовали снизить
уровень своих ожиданий.


10.3.4 Случай очень занятого узла

Локальный узел,  на котором работал розничный торговец,  зани-
мался "бомбардировками",  посылая свою рекламу через  FidoNet.
Координатор Сети был недоволен тем,  что ему приходилось обра-
батывать выходящий трафик в коммерческих целях, и попросил ло-
кальный узел выйти из сети.

Локальный узел обратился к Региональному Координатору, и полу-
чил статус независимого узла в регионе.


10.3.5 Метка дьявола

Местный SysOp,  чей  "почтовый  ящик"  использовался в связи с
колдовскими ритуалами,  хакерством,  phreaking, и неприличными
материалами, обратился к Координатору Сети, чтобы получить уз-
ловой номер.  Координатор Сети,  полагая,  что этот  "почтовый
ящик" чрезвычайно некорректен, отклонил запрос.

Консультации с Региональным Координаторм не проводились.

Международный Координатор(*), узнав, что консультации с Регио-
нальным Координаторм не проводились,  отменил это  решение.  В
дальнейшем аппеляции не подавались.


10.3.6 Случай SysOp'a - идиота

Клиент различных локальных узлов был повсеместно известен сре-
ди SysOp'ов как идиот.  Пользователь приобрел свою собственную
систему,  стал SysOp'ом,  и подал запрос на получение узлового
номера.  Координатор  Сети отклонил запрос.  Аппеляция не была
подана.


10.3.7 Случай пристрастия к Echomail

Локальный узел  пристрастился  к  Echomail  и принял участие в
нескольких конференциях, направлявших Mail через его сеть. За-
тем  он начал свое собственную Echomail-конференцию и трансли-
ровал Echomail между несколькими системами, снова пересылая ее
через сеть.

Координатор Сети заметил,  что работа сети заметно ухудшилась.
Он  потребовал   от   узла-нарушителя   уменьшить   количество
Echomail,  проходящей через сеть.  Компромисс был достигнут на
том,  что большинство трафика Echomail больше не  пересылалось
через сеть,  а пересылаемый объем Echomail ограничен двадцатью
сообщениями за ночь. Аппеляция не была подана.


10.3.8 Случай непостоянной работы "почтового ящика"

Локальный пользователь решил установить узел в благотворитель-
ных целях.  Используемая машина в  дневное  время  применялась
также и в других целях,  а SysOp часто отлучался.  Его коллеги
часто забывали устанавливать систему  в  конце  рабочего  дня,
когда его не было на месте,  поэтому узел часто в течение про-
должительного времени не отвечал. Координатор Сети, обнаружив,
что узел не способен принимать корреспонденцию,  отметил,  что
он не отвечает.  SysOp возвращался, снова устанавливал "почто-
вый ящик", и просил восстановить его.

В конце концов,  Координатор Сети решил, что SysOp не способен
обслуживать надежную систему,  и окончательно  удалил  его  из
NodeList'a.  Последующие  запросы  узлового  номера от того же
SysOp'a были отклонены. Аппеляция не была подана.


10.5 Официальные заявления и т.п.

Fido и  FidoNet являются зарегистрированными торговыми марками
Fido Software, Inc.


                          Алфавитный указатель

-1/-1,  2.3
Автоответчик  2.3
Административный регион  6.1
Адрес в сообщении с запросом узлового номера  2.2
Адрес для напраления материалов для FidoNews  1.3.1
Большинство  8.6, 8.7.2
Бомбардировка  4.2
BossNode  1.2.1.2
Быстрое решение  9.7
Внесение изменений в NodeList  3.2
Время обсуждения  8.2
Время сбора голосов  8.4
Время Zone Mail Hour  2.1.13, 2.1.14, 10.2
Вопросы взаимоотношений между зонами  1.2.6
Вотум недоверия  8.7
Входящая корреспонденция  2.1.6.1
Выборы координаторов  1.2.5, 6.2, 7.2
Гарантия доставки корреспонденции  1.3.6
География  1.3.2, 5.6
Голос  8
     право 8.3, 8.7.2
Границы  1.3.2
Дата вступления в силу изменений в уставе  8.2
Должности  3.4
Дополнительные "почтовые" процедуры в локальных сетях  2.1.8
Доступность NodeList'а  1.3.4
Доступ пользователя во время ZMH  2.1.8
EchoMail  4.2, 9.9
Жалоба (по уставу)  2.1.6.1, 9
Загрузка пользователями  3.6, 4.5, 5.8
Заказы (коммерческие)  1.3.6
Замена координаторов  1.2.8
Замена служб  3.4
Замена узлового номера  4.3, 5.2
ZMH см. Zone Mail Hour
Знакомство с уставом  2.1.2, 2.2
Zone Mail Hour  1.3.3, 2.1.8
     время 2.1.13, 2.1.14, 10.2
Зоны  1.2.5, 1.3.2
Изменение корреспонденции  2.1.5
Исключения  5.6
Исключительность Zone Mail Hour  2.1.8
Использование FidoNet в деловых целях  1.3.6
Истории прецедентов  9.10, 10.3
Как получить узловой номер  2.2
Кодирование  2.1.4, 4.2
Коммерческие сообщения  1.3.6, 2.1.4, 4.2
Контроль и равновесие  1.2.8
Конфликты  9
Координатор Сети  1.2.3
     процедуры 4
     замена 5.7, 9.3
Координатор Зоны  1.2.5, 6
     выборы 6.2
     вотум недоверия 8.7
     процедуры 6
     смещение 6.2
     отставка во время вотума недоверия 8.7.4
Корреспонденция (Mail)  1.2.3, 4.2
Летнее время  2.1.14
Mailer  2.2
Маленькие сети  5.3
Международный Координатор  1.4.1, 1.4.9, 7
Местные телефонные сети  1.3.2
Местные уставы  1.2, 3.3
Модем  2.2
азначение координаторов  1.2.3, 1.2.4, 5.7, 6.1
National Mail Hour  см. Zone Mail Hour
езависимый узел  4.2, 5.2
езаконная корреспонденция  4.2
езаконное поведение  2.1.1, 9.6
екорректное поведение  1.3.5,  1.4.8,  2.1.1,  2.1.2,  2.1.4,
     2.1.6, 2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
елегальное распространение программного обеспечения  2.1.1
еоправданные списки узлов  2.1.9
еотвечающая система  2.3, 4.4, 5.5
есоблюдение тайны переписки  2.1.6
Network Mail Hour  см. Zone Mail Hour
овые SysOp'ы  2.1.2, 3.6
NodeList  1.3.4, 2.2, 4.4, 5.5
     доступность 3.1, 4.5, 5.8
     изменения 4.4, 5.2
     текущий 2.1.11
     определение 1.3.4
     формат 10.3
     официальный 1.3.4
омер обычного телефона  2.2
Обзор пересылаемого трафика  2.1.4
Общественный BBS  3.6
Объявление результатов голосования  8.2
Ограничение времени принятия решения  9.7
Ограничение срока рассмотрения жалобы  9.6
Оператор системы (SysOp)  1.2.1
Оправдание частного узла  2.1.9
Освобождения, расположение узла  1.3.2, 5.6
Оскорбительные сообщения  2.1.5
Основа  4.5
Отказ в общении  2.1.12, 4.3, 5.2, 9
Отпуск (каникулы)  2.3
Отставка Координатора Зоны  8.7.4
Пересмотр решений  3.7
Пересылка  2.1.4 - 2.1.7, 4.2
Подготовка материалов для FidoNews  1.3.1
Подчинение сверху вниз  1.4.9
Point'ы  1.2.1.2, 2.1.3
Получение узлового номера  2.2
Пользователь  1.2.1.1
Почтовый буфер  1.2.3.1, 4.4
Правила  9.1
Право голоса  8.3
Преимущества членства в сети  2.2
Прецедент  3.7, 9.10, 10.3
Протокол  2.1.8
Процедуры SysOp'а  2
Разрешение конфликтов  9
Распределение голосов  8.2
Ратификация  7.1
Региональный Координатор  1.2.4
     процедуры 5
     замена 6.1, 9.4
Регионы  1.2.4
Референдум  1.2.7, 8
Решение проблем  9
Сети с тремя уровнями  1.2.3.1
Сеть
     преимущества 2.2
     границы 1.3.2, 5.4
     определение 1.2.3
     создание 2.4, 5.3
     почтовый буфер 1.2.3.1, 4.4
     количество 2.2, 5.4
Системы, оставляемые без оператора  2.3
Соблюдение "почтовых" процедур  2.1.8, 2.1.10
Совет Координаторов Зон  1.2.6, 7.1
Стандарты (FTSC)  2.1.8, 2.4
Текущий NodeList  2.1.11
Телефонные сети  1.3.2, 5.6, 5.7
Точка происхождения  2.1.3
Традиция  3.7
Требование быть в NodeList'e  1.3.4, 2.1.2, 2.2
Узловые номера  4.3, 5.2
     получение  2.2
Узлы
     определение 1.2.1
     не отвечающий 2.3
Уровни FidoNet  1.2, 1.4
Устав  3.1, 3.3, 4.5, 5.8
Файл различий  4.5, 5.8, 8.2
FidoNews  1.3.1
     доступность 3.1, 4.5, 5.8
FTSC  2.1.8, 2.1.9, 2.4
Host-направленная корреспонденция  4.2
Цепочка аппеляции  9.5
Цепочка управления  1.2.8
Частичный NodeList  1.3.4
     изменение 8
     жалоба 2.1.6.1, 9
     знакомство с 2.1.2, 2.2
     местный 1.2, 3.3
Частная сеть  1.2.1.2
Частные сообщения  2.1.6
Частные узлы  2.1.9
Членство в управляемой структуре  3.5
Чрезмерно некорректное поведение 1.2.1.1, 1.3.5, 2.1.1, 2.1.2,
     2.1.4,  2.1.6, 2.1.7, 2.1.8,  2.1.11, 2.3, 4.2, 4.3, 5.2,
     9, 10
Шлюз  2.1.3
Язык  1.0