| #112301 | From: | Nil A |
| To: | All | |
| Date: | 06-09-2021 23:44:07 | |
| Subj: | Номер пойнта на максималке |
Hello, All!
Кто-нибудь выдавал номер пойнта выше 32767, чтобы до 65535, или не весь софт это поддерживает?
Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
SEEN-BY: 5015/46 5020/1042 6090/1
PATH: 5015/46 5020/1042 6090/1
Кто-нибудь выдавал номер пойнта выше 32767, чтобы до 65535, или не весь софт это поддерживает?
Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
SEEN-BY: 5015/46 5020/1042 6090/1
PATH: 5015/46 5020/1042 6090/1
| #112302 | From: | Alexey Fayans |
| To: | Nil A | |
| Date: | 07-09-2021 01:26:00 | |
| Subj: | Номер пойнта на максималке |
Hello Nil!
On Mon, 06 Sep 2021 at 23:44 +0300, you wrote to All:
NA> Кто-нибудь выдавал номер пойнта выше 32767, чтобы до 65535, или не
NA> весь софт это поддерживает?
Есть некоторая вероятность напороться на софт, где под поинтовый номер выделен int, и тогда 65535 превратится в -1.
... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
SEEN-BY: 5020/715 1042 5030/1997 5053/58 6090/1
PATH: 5030/1997 5053/58 5020/715 1042 6090/1
On Mon, 06 Sep 2021 at 23:44 +0300, you wrote to All:
NA> Кто-нибудь выдавал номер пойнта выше 32767, чтобы до 65535, или не
NA> весь софт это поддерживает?
Есть некоторая вероятность напороться на софт, где под поинтовый номер выделен int, и тогда 65535 превратится в -1.
... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
SEEN-BY: 5020/715 1042 5030/1997 5053/58 6090/1
PATH: 5030/1997 5053/58 5020/715 1042 6090/1
| #112303 | From: | Mykhailo Kapitanov |
| To: | Nil A | |
| Date: | 08-09-2021 08:49:16 | |
| Subj: | Номер пойнта на максималке |
Hello Nil!
06 Sep 21 23:44, you wrote to all:
NA> Кто-нибудь выдавал номер пойнта выше 32767, чтобы до 65535, или не
NA> весь софт это поддерживает?
И не должен поддерживать:
**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FRL-1002
Revision: 1
Title: Standard Fidonet Addressing
Author: Lee Kindness
Revision Date: 15 June 1999
Expiry Date: N/A
PP - Point Number: If the system is a point rather than a node then
this is their point number off the node.
Min: 0 Max: 32767
If '.PP' is missing then assume 0 (ie not a
point) as the point number.
Mykhailo
--- GoldED+/W64-MSVC 1.1.5-b20180707
* Origin: Per rectum ad astra (2:467/239)
SEEN-BY: 467/239 5020/1042 6090/1
PATH: 467/239 5020/1042 6090/1
| #112304 | From: | Freezer Master |
| To: | All | |
| Date: | 11-09-2021 01:00:12 | |
| Subj: | Freezer Stat |
Saturday, 11 Sep 2021 01:00
Nodes Size Mail Files Of all Flags Old
═══════════════════════════════════════════════════════════════════════════════
***** Queue is empty *****
═══════════════════════════════════════════════════════════════════════════════
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
Nodes Size Mail Files Of all Flags Old
═══════════════════════════════════════════════════════════════════════════════
***** Queue is empty *****
═══════════════════════════════════════════════════════════════════════════════
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
| #112305 | From: | Freezer Master |
| To: | All | |
| Date: | 18-09-2021 01:00:12 | |
| Subj: | Freezer Stat |
Saturday, 18 Sep 2021 01:00
Nodes Size Mail Files Of all Flags Old
═══════════════════════════════════════════════════════════════════════════════
***** Queue is empty *****
═══════════════════════════════════════════════════════════════════════════════
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
Nodes Size Mail Files Of all Flags Old
═══════════════════════════════════════════════════════════════════════════════
***** Queue is empty *****
═══════════════════════════════════════════════════════════════════════════════
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
| #112306 | From: | Moderator of R50.SYSOP |
| To: | All | |
| Date: | 19-09-2021 01:00:07 | |
| Subj: | Rules |
*** Правила конференции ***
R50.SYSOP
17.01.2014
1. ТЕМАТИКА
Конференция R50.SYSOP является основной конференцией системных
операторов узлов 50 региона 2 зоны сети FidoNet. В эхоконференции раз-
решается обсуждение любых тем, относящихся к работе сетей региона,
региона и FidoNet в целом. Исключение составляют темы, для обсуждения
которых существуют специализированные тематические конференции.
2. РАСПРОСТРАНЕНИЕ
R50.SYSOP может свободно распространяться среди узлов сети
FidoNet. Пойнты и пользователи узлов не должны иметь права помещения
писем без специального разрешения модератора. Тем не менее, сисопы (в
том числе бывшие из R50) могут писать в эху по техническим проблемам,
связанным с R50, используя любой поинтовый адрес, при условии указания
в кладжах или в тексте письма своего нодового адреса.
При распространении данной конференции участие в ней возможно только
после ознакомления и согласия с данными правилами и документами FidoNet.
3. ЯЗЫК И ОБЩИЕ ПРАВИЛА НАПИСАНИЯ ПИСЕМ
3.1. Может быть использован русский или английский язык. При ответе на
письмо рекомендуется отвечать на том же языке, на котором было
написано оригинальное письмо.
3.2. Не допускается применение нецензурных выражений. Если очень
приспичило - замените их символами @#$%&.
3.3. Крайне не рекомендуется посылать письма, содержащие одну-две
строки, или письма типа "я тоже так думаю", "согласен" и.т.п.
3.4. Личная переписка в эхоконференции категорически запрещена.
3.5. Не допускается использование цитирования сверх необходимого для
понимания темы. В частности, не допускается цитирование строк @PATH,
@SEEN+BY, * Origin, @MSGID и прочих чисто технических сообщений.
Подобные цитаты не несут смысловой нагрузки и загружают каналы связи.
3.6. Посылка файлов в uuencode формате возможна только с личного
разрешения модератора. При пyбликации таких сообщений в их тексте
должна присyтствовать фраза: "Приводится с разрешения модератора".
3.7. Запрещается обсуждение правил правописания как русского, так и
английского языка на примере писем, помещенных в конференцию.
3.8. Крайне не рекомендуется ставить большие подписи под письмами.
Ограничьтесь одной строчкой. Кроме того, запрещается использование
"разувесистых" темплейтов. Пять строк на весь темплейт - максимум.
3.9. Категорически запрещается коммерческая реклама, а также любые
призывы к антигосyдарственным и yголовно наказyемым действиям.
3.10. Перед написанием писем, прочитайте настоящие правила.
3.11. При написании писем запрещается использовать псевдонимы. В поле
"From" письма должно содержаться либо _нодлистовое_ имя сисопа, либо
название официальной должности (R50C, R50[EFV]C, N(5|6)0??C и.т.п.),
либо иная информация, однозначно идентифицируящая _сисопа_.
4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
4.1. При написании писем в конференции необходимо использовать
альтернативную кодировку (кодовая таблица 866).
4.2. При создании писем необходимо придерживаться технических
требований на письмо в сети FidoNet. Не рекомендуется посылать письма
больше 10 kb одним письмом - разбейте его на несколько писем меньшего
размера. Строка Origin должна быть не больше 79 символов. Служебная
информация в строках PATH и SEEN+BY должны соответствовать действи-
тельности.
5. МОДЕРИРОВАНИЕ
5.1. Поступайте так, как вы бы хотели, чтобы поступали с вами: не
участвуйте в оскорблениях или личных нападках на других участников
этой конференции. Если Вы считаете, что какое-либо сообщение
оскорбляет Вас - Вы можете:
а). Проигнорировать его (наиболее предпочтительный вариант).
б). Написать автору _нетмeйлом_.
в). Обратиться нетмейлом к модератору.
5.2. Оставьте модерирование модератору. Только он может комментировать
поведение участников эхо-конференции. Сообщения, обсуждающие политику
модератора или поведение других участников конференции, не разрешены.
Также не разрешаются обращения к модератору в эхе и переписка с ним.
Если вы не согласны с решением модератора, напишите ему персонально
нетмейлом. Если вы не смогли договориться с модератором, вопрос будет
решаться согласно действующей Полиси.
5.3. Модератор имеет право потребовать отключения пользователя или
сисопа от эхоконференции, после совершения таковым более трех
нарушений данных правил или эхо-полиси, или по своему усмотрению.
Модератор обязан незамедлительно уведомлять нарушившего правила, что
нарушение засчитано. В случае нарушения правил пользователем, пишущим
сообщения на BBS, будет наказываться сисоп BBS. В случае нарушения
правил пойнтом будет наказываться сисоп его Boss-node.
5.4. Модератор может временно или постоянно запрещать для обсуждения
темы, препятствующие нормальному проведению конференции. В этом случае
перечень тем, запрещенных для обсуждения, будет периодически публико-
ваться в эхоконференции.
5.5. В случае нарушения подписчиком правил, модератор выносит ему
предупреждение. Система предупреждений стандартная [*][+][!], в зави-
симости от тяжести нарушения. Тяжесть нарушения определяется модера-
тором.
Срок действия предупреждения [*] составляет один месяц, после
чего оно теряет силу, однако если в течение этого месяца участник
конференции получит еще одно предупреждение, срок действия обоих пре-
дупреждений становится равен сроку действия последнего из них.
Три предупреждения [+] одному и тому же сисопу приводят к пере-
воду его в режим ReadOnly на 1 месяц. Если в течение месяца после
окончания режима ReadOnly сисоп снова получает этот статус, то на
этот раз срок ReadOnly возрастает до 2-х месяцев, и так далее по на-
растающей. За грубые или неоднократные нарушения Узел может быть пе-
реведен в ReadOnly без предупреждения и на более длительный срок.
Кроме того,модератор может (по своему усмотрению) отключить узел
от конференции при повторении сисопом нарушения, за которое уже было
вынесено предупреждение.
Модератор может в любой момент изменить настоящие правила.
Изменения считаются действительными через двое сyток - для всех узлов.
Помещение писем в конференцию с узла,от конференции отключенного,
будет рассматриваться как чрезмерно некорректное поведение.
Модерирование конференции осуществляет действующий R50C.
Модератор вправе назначать себе помощников - комодераторов,
которые обладают всеми правами модератора, за исключением изменения
правила эхи и назначения комодераторов.
ДЕЙСТВУЮЩИЙ МОДЕРАТОР КОНФЕРЕНЦИИ:
R50C, 2:50/0
Другие адреса модератора:
2:5020/715, 2:5020/5452, 2:5020/715.1
Комодераторы:
Oleg Redut 2:5000/111
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
R50.SYSOP
17.01.2014
1. ТЕМАТИКА
Конференция R50.SYSOP является основной конференцией системных
операторов узлов 50 региона 2 зоны сети FidoNet. В эхоконференции раз-
решается обсуждение любых тем, относящихся к работе сетей региона,
региона и FidoNet в целом. Исключение составляют темы, для обсуждения
которых существуют специализированные тематические конференции.
2. РАСПРОСТРАНЕНИЕ
R50.SYSOP может свободно распространяться среди узлов сети
FidoNet. Пойнты и пользователи узлов не должны иметь права помещения
писем без специального разрешения модератора. Тем не менее, сисопы (в
том числе бывшие из R50) могут писать в эху по техническим проблемам,
связанным с R50, используя любой поинтовый адрес, при условии указания
в кладжах или в тексте письма своего нодового адреса.
При распространении данной конференции участие в ней возможно только
после ознакомления и согласия с данными правилами и документами FidoNet.
3. ЯЗЫК И ОБЩИЕ ПРАВИЛА НАПИСАНИЯ ПИСЕМ
3.1. Может быть использован русский или английский язык. При ответе на
письмо рекомендуется отвечать на том же языке, на котором было
написано оригинальное письмо.
3.2. Не допускается применение нецензурных выражений. Если очень
приспичило - замените их символами @#$%&.
3.3. Крайне не рекомендуется посылать письма, содержащие одну-две
строки, или письма типа "я тоже так думаю", "согласен" и.т.п.
3.4. Личная переписка в эхоконференции категорически запрещена.
3.5. Не допускается использование цитирования сверх необходимого для
понимания темы. В частности, не допускается цитирование строк @PATH,
@SEEN+BY, * Origin, @MSGID и прочих чисто технических сообщений.
Подобные цитаты не несут смысловой нагрузки и загружают каналы связи.
3.6. Посылка файлов в uuencode формате возможна только с личного
разрешения модератора. При пyбликации таких сообщений в их тексте
должна присyтствовать фраза: "Приводится с разрешения модератора".
3.7. Запрещается обсуждение правил правописания как русского, так и
английского языка на примере писем, помещенных в конференцию.
3.8. Крайне не рекомендуется ставить большие подписи под письмами.
Ограничьтесь одной строчкой. Кроме того, запрещается использование
"разувесистых" темплейтов. Пять строк на весь темплейт - максимум.
3.9. Категорически запрещается коммерческая реклама, а также любые
призывы к антигосyдарственным и yголовно наказyемым действиям.
3.10. Перед написанием писем, прочитайте настоящие правила.
3.11. При написании писем запрещается использовать псевдонимы. В поле
"From" письма должно содержаться либо _нодлистовое_ имя сисопа, либо
название официальной должности (R50C, R50[EFV]C, N(5|6)0??C и.т.п.),
либо иная информация, однозначно идентифицируящая _сисопа_.
4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
4.1. При написании писем в конференции необходимо использовать
альтернативную кодировку (кодовая таблица 866).
4.2. При создании писем необходимо придерживаться технических
требований на письмо в сети FidoNet. Не рекомендуется посылать письма
больше 10 kb одним письмом - разбейте его на несколько писем меньшего
размера. Строка Origin должна быть не больше 79 символов. Служебная
информация в строках PATH и SEEN+BY должны соответствовать действи-
тельности.
5. МОДЕРИРОВАНИЕ
5.1. Поступайте так, как вы бы хотели, чтобы поступали с вами: не
участвуйте в оскорблениях или личных нападках на других участников
этой конференции. Если Вы считаете, что какое-либо сообщение
оскорбляет Вас - Вы можете:
а). Проигнорировать его (наиболее предпочтительный вариант).
б). Написать автору _нетмeйлом_.
в). Обратиться нетмейлом к модератору.
5.2. Оставьте модерирование модератору. Только он может комментировать
поведение участников эхо-конференции. Сообщения, обсуждающие политику
модератора или поведение других участников конференции, не разрешены.
Также не разрешаются обращения к модератору в эхе и переписка с ним.
Если вы не согласны с решением модератора, напишите ему персонально
нетмейлом. Если вы не смогли договориться с модератором, вопрос будет
решаться согласно действующей Полиси.
5.3. Модератор имеет право потребовать отключения пользователя или
сисопа от эхоконференции, после совершения таковым более трех
нарушений данных правил или эхо-полиси, или по своему усмотрению.
Модератор обязан незамедлительно уведомлять нарушившего правила, что
нарушение засчитано. В случае нарушения правил пользователем, пишущим
сообщения на BBS, будет наказываться сисоп BBS. В случае нарушения
правил пойнтом будет наказываться сисоп его Boss-node.
5.4. Модератор может временно или постоянно запрещать для обсуждения
темы, препятствующие нормальному проведению конференции. В этом случае
перечень тем, запрещенных для обсуждения, будет периодически публико-
ваться в эхоконференции.
5.5. В случае нарушения подписчиком правил, модератор выносит ему
предупреждение. Система предупреждений стандартная [*][+][!], в зави-
симости от тяжести нарушения. Тяжесть нарушения определяется модера-
тором.
Срок действия предупреждения [*] составляет один месяц, после
чего оно теряет силу, однако если в течение этого месяца участник
конференции получит еще одно предупреждение, срок действия обоих пре-
дупреждений становится равен сроку действия последнего из них.
Три предупреждения [+] одному и тому же сисопу приводят к пере-
воду его в режим ReadOnly на 1 месяц. Если в течение месяца после
окончания режима ReadOnly сисоп снова получает этот статус, то на
этот раз срок ReadOnly возрастает до 2-х месяцев, и так далее по на-
растающей. За грубые или неоднократные нарушения Узел может быть пе-
реведен в ReadOnly без предупреждения и на более длительный срок.
Кроме того,модератор может (по своему усмотрению) отключить узел
от конференции при повторении сисопом нарушения, за которое уже было
вынесено предупреждение.
Модератор может в любой момент изменить настоящие правила.
Изменения считаются действительными через двое сyток - для всех узлов.
Помещение писем в конференцию с узла,от конференции отключенного,
будет рассматриваться как чрезмерно некорректное поведение.
Модерирование конференции осуществляет действующий R50C.
Модератор вправе назначать себе помощников - комодераторов,
которые обладают всеми правами модератора, за исключением изменения
правила эхи и назначения комодераторов.
ДЕЙСТВУЮЩИЙ МОДЕРАТОР КОНФЕРЕНЦИИ:
R50C, 2:50/0
Другие адреса модератора:
2:5020/715, 2:5020/5452, 2:5020/715.1
Комодераторы:
Oleg Redut 2:5000/111
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
| #112307 | From: | R50EC |
| To: | All | |
| Date: | 19-09-2021 01:00:18 | |
| Subj: | R50EC FAQ |
>FAQ ПО РЕГИОНАЛЬНОМУ ЭХОБОНУ
v4.5 (18.06.2020)
> ОБЩИЕ ВОПРОСЫ
>Q: К кому обращаться?
A: Основные вопросы по региональному бону и эхам на нем решают:
Региональный эхокоординатор (R50EC) - все вопросы по бону:
Alex Barinov, 2:5020/715, aleksey.v.barinov AT gmail.com, Telegram: @huba715
Региональный бонмастер (R50BM) - технические вопросы эхохождения:
Michael Dukelsky, 2:5020/1042
Пожалуйста присылайте правила, строчки, подтверждения полномочий нетмейлом,
иначе могут возникнуть лишние сомнения в их достоверности.
Первоначально рекомендуется обращаться к R50EC - как минимум для
того, чтобы он был в курсе вопроса и мог контролировать его решение.
>Q: Где взять свежий региональный эхолист?
A: В файлэхе XOFCELIST, на
http://fido.hubahuba.su/XOFCELIS.T/echo50.lst
http://fidoweb.ru/up/doc/echo50.lst
>Q: Где взять официальный архив эх регионального бона?
A: Пока только в файлэхе XOFCERULES
>Q: Как выглядит строчка для эхолиста?
A: Статус(Hold,Down),Название_эхи,Описание_эхи,Модератор,Адрес_модератора,
Например:
,R50.Bone,Официальная конференция эхобекбона R50,R50EC,2:50/1,
(Обратите внимание на запятую в начале и конце строки)
Имя модератора - английскими буквами.
Лучше присылать строчку и правила в одном письме.
Рекомендуется длина строки не больше 79 символов, а описание - 30-50 символов.
Русские буквы в названии эхи и имени/фамилии модератора не допускаются. Нельзя
употреблять символ ";" (вообще в строчке, это знак комментария). Запятые -
разделители между полями и в самих полях их быть не должно.
Не допускается использование символа " (двойные кавычки),заменяйте его на '
(одинарная кавычка), а также символов |, \, /.
Желательно в качестве разделителей в эхотаге использовать только символы
. (точка) - (минус) _ (подчерк). В описании эхи можно также & : /.
>Q: Каковы требования к правилам бекбонной конференции?
A:
На бекбоне не могут находиться эхи, противоречащие законодательству, полиси,
эхополу. Также не принимаются эхи политических партий и организаций.
UUE эхи (т.е. эхи, где UUE составляет более трети-четверти трафика) также не
принимаются на бекбон, поэтому, если в правилах допускается постинг UUE
- такой постинг допустим только с разрешения модератора. Передача двоичных
файлов другими способами (base64 и др.) настоятельно не рекомендуется и ее
разрешения в правилах быть не должно.
Согласно Эхополу, в правилах должна быть описана процедура смены модератора.
Например:
===
В случае невозможности исполнения модератором своих обязанностей , о
чем он должен уведомить комодератора и подписчиков соответствующим официа-
льным сообщением, или в случае доказанного факта невозможности исполнять
свои функциональные обязанности модератора (не отвечает на письма , теле-
фонные звонки более трех месяцев), модерирование переходит к указанному в
Правилах комодератору. В случае отсутствия комодератора , порядок выборов
нового модератора определяется эхокоординатором.
===
Если подобного пункта в правилах Вашей конференции еще нет, просьба включить
его и прислать обновленные правила REC-у.
>Q: Обязательно ли имя модератора должно соответствовать ноделистовому?
A: Весьма желательно, но необязательно.
>Q: Какова структура регионального эхобона, кто региональные хабы?
В настоящий момент эхобон R50 образуют следующие узлы:
2:5030/115 - f115.spb.ru:binkp
- f115.spb.ru:ifcico
Dmitriy Yermakov
Запросы на установку линка писать на 2:5030/1115
2:5020/1042 - fido.delin.ru:binkp
Michael Dukelsky
dukelsky AT aha.ru
2:5020/830 - 830.ru:binkp
- 830.ru:ifcico
Denis Nikolayev
nikdenis AT mail.ru
icq: 37666592
Если не указано особо, запросы на установку линка с вышеперечисленными узлами
следует отправлять нетмейлом, при этом крайне желательно указывать в запросе
результат traceroute.
Всем хабам, распространяющим конференции регионального бона, следует следить
за актуальностью эхолиста, доступного по файлэхе XOFCELIST, а также по
следующему URL:
http://fido.hubahuba.su/XOFCELIS.T/echo50.lst
>Q: Как связаны между собой региональные хабы и как выглядит полносвязка?
2:5020/1042
/ | \
2:46/50 ------------ 2:5020/830
\ | /
2:5030/115
Соответственно, полносвязка - это "блин" из 4 узлов.
Региональные хабы:
5020/830, 5020/1042, 5030/115
Полносвязка:
46/50, 5020/1042, 5030/115 и 5020/830
Фактически, в регионе схема вот такая страшная: (показана полносвязка,
основные узлы и основные сети)
2:5020/545
|
|
(сеть 5020) ---- 2:5020/4441
|
|
2:5020/830
/ |
/ |
2:5020/715 ---- 2:5020/1042
| /
| /
| /
2:5030/115
/
/
(сеть 5030)
>Q: Где взять текущую версию регионального эхопола (R50EP)?
A: Спросить у R50EC нетмейлом или взять из архива R50EC.ZIP в фэхе XOFCELIST
или http://fido.hubahuba.su/XOFCELIS.T/R50EC.ZIP
>Q: В каких эхах можно получить информацию о работе регионального бона?
A: R50.BONE - административные вопросы. R50.HUBS - технические вопросы.
Для отслеживания ситуации достаточно R50.SYSOP.INFO.
Кроме того, могут оказаться полезными RU.MODERATOR и RU.ECHOLIST. Вопросы
выборов модераторов обсуждаются в R50.ELECTIONS.
>Q: Модератора в эхе XXX давно уже не видно, а эха по-прежнему на боне.
>Почему? Нужно ли что-либо предпринимать, если ситуация в эхе вполне
>устраивает?
A: R50EC с помощниками не могут постоянно проверять сотни эх.
Необходимо иметь в виду, что любая эха, в которой отсутствует реальное
модерирование, может служить объектом нападения и, в конечном счете, может быть
захваченной группой лиц, не имеющих к эхе никакого отношения. Поэтому лучше не
дожидаться этого, а сразу обратиться нетмейлом к R50EC, который поможет найти
пропавшего модератора или, если найти не удастся, организует выборы нового. Но
в любом случае, перед обращением к R50EC нужно попытаться самостоятельно
связаться нетмейлом с модератором эхи по адресу, указанному в эхолисте.
>Q: В эху уже несколько месяцев не постятся правила. Означает ли это, что
>модератор эхи пропал?
A: Нет. Действующий эхопол не накладывает каких-либо ограничений на
периодичность публикации правил конференций. Однако рекомендуется публиковать
их не реже раза в месяц.
>Q: Где можно получить правила бонной эхи?
A: Спросить у модератора (чей адрес есть в эхолисте). Также можно спросить
нетмейлом у R50EC (на данный момент в его архиве присутствуют не все
правила эх). Данный архив регулярно обновляется и постится в фэху XOFCELIST
(зеркало - http://fido.hubahuba.su/XOFCELIS.T/R50RULES.ZIP)
Обращаю внимание, что в случае возникновения конфликта, официальными и
действующими считаются правила из архива R50EC, поэтому модераторам
рекомендуется в случае внесения значительных изменений присылать R50EC новые
правила.
Что касается указанного в правилах модератора, то приоритет всегда имеет
строчка в последнем эхолисте.
>Q: Как поднять эху на региональный бекбон?
A: Направить R50EC нетмейлом заявку, содержащую строку для эхолиста и правила
эхи, соответствующие вышеизложенным требованиям.
>Q: Каковы сроки и график принятия эх на региональный бекбон?
A: После подачи заявки и правил эхи (соответствующих R50EP) эта информация
проверяется R50EC и публикуется в R50.BONE. Далее выжидается некоторое время,
в течении которого правила изучаются региональными хабами.
* Модератору эхи рекомендуется читать R50.BONE в этот период! *
В случае отсутствия возражений от них, эха через неделю-другую принимается на
региональный эхобон. Результат (принятие или отказ) публикуется в R50.BONE.
Фактически следует также подождать выхода нового эхолиста, где эта эха будет
присутствовать, так как только после этого она появится на региональных
эхохабах.
>Q: Что нужно сделать для смены строки в эхолисте?
Чтобы сменить строку в эхолисте, модератор должен прислать письмо
R50EC.
Письмо должно быть от модератора эхи и послано с того адреса, который указан
в правилах и строчке для эхолиста как _новый_ адрес модератора. Если будут
вопросы или неясности, я буду писать только на этот адрес.
В письме должны быть строчка для списка эх и правила эхи.
При смене модератора письмо может быть как от прежнего модератора (с любого
адреса; возможно, именно из-за потери прежнего адреса он отказывается от
модерирования), так и от нового. В письме должно явно содержаться согласие
прежнего модератора передать эху, а нового принять ее - в виде форварда
соответстующего письма. Строчка для эхолиста и правила эхи должны быть в
письме и в этом случае.
Настоятельно рекомендуется, чтобы прежний модератор при передаче полномочий
новому модератору сообщил об этом в эхе. Это облегчит жизнь нового модератора
и избавит его от обвинений в самозванстве.
>Q: Что означает статус Hold для эхи? Влияет ли он на ее распространение?
A: Нет. Однако, статус Hold означает, что имеются проблемы с модерированием
или правилами эхи, и по истечении определенного срока (как правило, 2-х
месяцев с момента присвоения статуса Hold) эха может быть снята с бекбона.
>Q: Что произойдет с эхой которая снята с регионального бона?
A: Зависит от причины снятия. В большинстве случаев это означает, что
распространение эхи не гарантируется структурой эхобона и является
исключительно актом доброй воли со стороны сисопов раздающих узлов.
Исключением является ситуация, когда распространение некоторой эхи может
нанести вред эхобону или раздающим узлам - в таком случае эха вносится в файл
fidokill.na и принудительно уничтожается на бонных эхохабах и раздающих узлах.
Вниманию раздающих узлов: файл fidokill.na является обязательным для
обработки эхохабами и должен иметь приоритет над эхолистом.
>Q: Было бы неплохо публиковать различные анонсы не только в R50.BONE, но и
>в эхах [..список..].
A: Список в студию.
>Q: Почему вы не ответили на мое письмо?
A: В сутки иногда приходят десятки писем, каждое из которых требует не только
прочтения, но и проверки или внесения каких-либо изменений. Поэтому ответ
может занять несколько дней.
Если вы хотите знать, дошло ли письмо, включайте флаг Rrq.
>Q: Нужно ли при каждом мелком изменении правил присылать их R50EC?
A: Следует знать, что если возникнет серьезный конфликт по вашей эхе, который
будет разбираться REC'ом, то официально действующими будут считаться те
правила, которые находятся в архиве REC'a. Вот из этого и нужно исходить.
Вообще, да, надо. Ибо правила не только оседают у REC'а в /dev/null, но и
постятся в фэху, отдаются желающим и т.п.
Если правила содержат псевдографику, их лучше присылать в формате uue.
Кодировка - cp866 или koi8-r (без разницы).
> ВОПРОСЫ ПО ВЫБОРАМ В ЭХАХ
>Q: В эхе пропал модератор. Вероятно надо выбрать нового.. Что делать и к
>кому обращаться?
A: Для начала, необходимо сделать попытку связаться с модератором нетмейлом
по адресу, указанном в эхолисте. Если адрес модератора отсутствует в нодлисте
или модератор не ответил, попробуйте определить нового модератора среди
подписчиков путём консенсуса. Если таким образом удалось выбрать нового
модератора, он должен прислать R50EC новую версию строки в эхолист и правил.
Если консенсуса не сложилось, нужно опять-таки написать нетмейлом R50EC.
Далее процедура будет такой - R50EC ищет RO и VC - проводящего выборы и
проверяющего голоса. Как только находит (это обычно происходит не сразу -
из-за нехватки RO/VC существует некоторая очередь из эх, поэтому если вы
поможете R50EC с поисками кандидатов на роли RO/VC, то он будет вам крайне
благодарен), в эхе объявляются выборы. Избранный модератор должен отправить
свежие правила и строчку в эхолист. В случае, если выбора проводятся силами
подписчиков, им _настоятельно_ рекомендуется уведомить об этом R50EC.
>Q: Почему в официальных эхах не публикуется информация о начале выборов
>модераторов в той или иной эхе?
A: Это позволяет снизить вероятность провокаций. Период выборов - довольно
опасный для эхи момент и регулярно появляются желающие сорвать выборы или
просто похулиганить.
Кроме того, информация о начале выборов нужна, в первую очередь, подписчикам
данной эхи, а они ее и так получают - из самой эхи.
>Q: Хочу быть RO/VC. Есть ли какие-то требования к кандидатам? К кому
>обращаться?
A: Обращаться следует нетмейлом к R50EC. Требования к кандидатам
на должность RO/VC следующие:
- Желательно иметь нодовый адрес. В случае возникновения
конфликтов (а рано или поздно они возникнут) все вопросы лучше решать самому,
без привлечения босса.
- Ответственность и объективность. Человек должен четко понимать стоящие
перед ним задачи и должен быть готов приложить максимум усилий для их
выполнения. При этом, личное отношение как к избирателям, так и к кандидатам
никак не должно проявляться во время выборов в какой-либо форме. Необходимо
быть готовым к тому, что проведение выборов потребует в том числе и затрат
времени, которое раньше уходило на другие цели.
- Спокойствие и выдержка. Нужно быть готовым к тому, что в эхе могут
появиться люди, которые будут любыми, зачастую весьма грязными методами
добиваться своих личных целей, в том числе и идя на откровенные провокации
по отношению как к другим подписчикам, так и к проводящим выборы. Что-то
придется терпеть, что-то игнорировать, на что-то реагировать без проявления
эмоций.
- Техническая грамотность. Как минимум, нужно совершенно четко разбираться во
всей технической информации, присутствующей в письмах как в конференции,
так и нетмейлом.
- Желательно иметь техническую возможность принимать директные звонки, как
через телефон так и через интернет.
- Желателен опыт - если не проведения выборов, то хотя бы участия в нескольких
выборах в качестве избирателя или кандидата.
> ВОПРОСЫ ПО R50EP v2.0
>Q: Какова процедура внесения предложений по изменению эхополиси?
A: Готовится проект нового варианта документа и рассылается региональным
эхохабам, NC, NEC, REC, RC нетмейлом, если необходимо, с комментарием к
проекту. Разумеется, крайне желательно, чтобы перед рассылкой проект прошел
обсуждение в сисопской конференции.
>Q: Какова процедура сбора 10% голосов, необходимых для инициирования
>голосования по изменению эхополиси?
A: Процедура, собственно, состоит в ожидании откликов вышеупомянутых лиц на
проект. Срок ожидания откликов, в принципе, не ограничен, но рекомендуется
ограничиться месяцем (большинство случаев отпусков, командировок, болезней
он вполне покрывает). Просто для определенности: прошло или нет. Повторные
рассылки в течение этого срока крайне не рекомендуются, ибо могут быть
расценены как мейлбомбинг.
>Q: Каковы сроки, в течение которых REC обязан назначить голосование в
>случае одобрения предложенных изменений более 10% от всех NC, NEC,
>RC, REC и сисопов региональных эхохабов?
A: Две недели - крайний срок. Его вполне достаточно для поиска RO/VC даже
за пределами региона.
>Q: Может ли новый модератор произвольно менять правила эхи?
A: Избранный или назначенный модератор бонной эхи может произвольно менять
правила эхи которая ему передана фактом избрания или назначения.
Исключением из этого правила являются эхи модерируемые должностными лицами *C,
*EC, *FEC, *BM. В таких эхах (называемых официальными либо техническими)
модератором всегда остается указанное должностное лицо.
Следствия:
Если модератор ушел из Fido не назначив нового модератора, его требование
неизменности правил не действует. Новый модератор, который может быть избран
в результате, к примеру, поднятия эхи на бон, имеет право изменить правила.
"Создатели", "Хранители" и другие должности, создаваемые с правами, якобы
позволяющими снимать текущего Модератора эхи, менять правила и т.п. - не
будут рассматриваться как действующие. Максимум - они будут приравнены к
комодераторам данной эхи.
Правила, содержащие вышеперечисленные пункты, будут считаться действующими,
за исключением этих пунктов.
>Q: Влияет ли снятие эхи с бона на легитимность ее модератора?
A: Нет.
Но снятие с бона эхи выводит ее из области компетенции REC.
>Q: Где можно получить свежую версию данного FAQ?
A: R50BONE FAQ публикуется в R50.BONE, иногда в R50.SYSOP.INFO.
И ее можно получить, спросив у REC'а нетмейлом.
Благодарности:
Alex Kocharin (2:50/13, ex-R50EC) за создание базовой версии данного документа
Yury M. Bogoyavlensky (2:5020/1641, ex-N5020EC) за N5020EC FAQ, из которого были
позаимствованы некоторые положения данного документа.
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
v4.5 (18.06.2020)
> ОБЩИЕ ВОПРОСЫ
>Q: К кому обращаться?
A: Основные вопросы по региональному бону и эхам на нем решают:
Региональный эхокоординатор (R50EC) - все вопросы по бону:
Alex Barinov, 2:5020/715, aleksey.v.barinov AT gmail.com, Telegram: @huba715
Региональный бонмастер (R50BM) - технические вопросы эхохождения:
Michael Dukelsky, 2:5020/1042
Пожалуйста присылайте правила, строчки, подтверждения полномочий нетмейлом,
иначе могут возникнуть лишние сомнения в их достоверности.
Первоначально рекомендуется обращаться к R50EC - как минимум для
того, чтобы он был в курсе вопроса и мог контролировать его решение.
>Q: Где взять свежий региональный эхолист?
A: В файлэхе XOFCELIST, на
http://fido.hubahuba.su/XOFCELIS.T/echo50.lst
http://fidoweb.ru/up/doc/echo50.lst
>Q: Где взять официальный архив эх регионального бона?
A: Пока только в файлэхе XOFCERULES
>Q: Как выглядит строчка для эхолиста?
A: Статус(Hold,Down),Название_эхи,Описание_эхи,Модератор,Адрес_модератора,
Например:
,R50.Bone,Официальная конференция эхобекбона R50,R50EC,2:50/1,
(Обратите внимание на запятую в начале и конце строки)
Имя модератора - английскими буквами.
Лучше присылать строчку и правила в одном письме.
Рекомендуется длина строки не больше 79 символов, а описание - 30-50 символов.
Русские буквы в названии эхи и имени/фамилии модератора не допускаются. Нельзя
употреблять символ ";" (вообще в строчке, это знак комментария). Запятые -
разделители между полями и в самих полях их быть не должно.
Не допускается использование символа " (двойные кавычки),заменяйте его на '
(одинарная кавычка), а также символов |, \, /.
Желательно в качестве разделителей в эхотаге использовать только символы
. (точка) - (минус) _ (подчерк). В описании эхи можно также & : /.
>Q: Каковы требования к правилам бекбонной конференции?
A:
На бекбоне не могут находиться эхи, противоречащие законодательству, полиси,
эхополу. Также не принимаются эхи политических партий и организаций.
UUE эхи (т.е. эхи, где UUE составляет более трети-четверти трафика) также не
принимаются на бекбон, поэтому, если в правилах допускается постинг UUE
- такой постинг допустим только с разрешения модератора. Передача двоичных
файлов другими способами (base64 и др.) настоятельно не рекомендуется и ее
разрешения в правилах быть не должно.
Согласно Эхополу, в правилах должна быть описана процедура смены модератора.
Например:
===
В случае невозможности исполнения модератором своих обязанностей , о
чем он должен уведомить комодератора и подписчиков соответствующим официа-
льным сообщением, или в случае доказанного факта невозможности исполнять
свои функциональные обязанности модератора (не отвечает на письма , теле-
фонные звонки более трех месяцев), модерирование переходит к указанному в
Правилах комодератору. В случае отсутствия комодератора , порядок выборов
нового модератора определяется эхокоординатором.
===
Если подобного пункта в правилах Вашей конференции еще нет, просьба включить
его и прислать обновленные правила REC-у.
>Q: Обязательно ли имя модератора должно соответствовать ноделистовому?
A: Весьма желательно, но необязательно.
>Q: Какова структура регионального эхобона, кто региональные хабы?
В настоящий момент эхобон R50 образуют следующие узлы:
2:5030/115 - f115.spb.ru:binkp
- f115.spb.ru:ifcico
Dmitriy Yermakov
Запросы на установку линка писать на 2:5030/1115
2:5020/1042 - fido.delin.ru:binkp
Michael Dukelsky
dukelsky AT aha.ru
2:5020/830 - 830.ru:binkp
- 830.ru:ifcico
Denis Nikolayev
nikdenis AT mail.ru
icq: 37666592
Если не указано особо, запросы на установку линка с вышеперечисленными узлами
следует отправлять нетмейлом, при этом крайне желательно указывать в запросе
результат traceroute.
Всем хабам, распространяющим конференции регионального бона, следует следить
за актуальностью эхолиста, доступного по файлэхе XOFCELIST, а также по
следующему URL:
http://fido.hubahuba.su/XOFCELIS.T/echo50.lst
>Q: Как связаны между собой региональные хабы и как выглядит полносвязка?
2:5020/1042
/ | \
2:46/50 ------------ 2:5020/830
\ | /
2:5030/115
Соответственно, полносвязка - это "блин" из 4 узлов.
Региональные хабы:
5020/830, 5020/1042, 5030/115
Полносвязка:
46/50, 5020/1042, 5030/115 и 5020/830
Фактически, в регионе схема вот такая страшная: (показана полносвязка,
основные узлы и основные сети)
2:5020/545
|
|
(сеть 5020) ---- 2:5020/4441
|
|
2:5020/830
/ |
/ |
2:5020/715 ---- 2:5020/1042
| /
| /
| /
2:5030/115
/
/
(сеть 5030)
>Q: Где взять текущую версию регионального эхопола (R50EP)?
A: Спросить у R50EC нетмейлом или взять из архива R50EC.ZIP в фэхе XOFCELIST
или http://fido.hubahuba.su/XOFCELIS.T/R50EC.ZIP
>Q: В каких эхах можно получить информацию о работе регионального бона?
A: R50.BONE - административные вопросы. R50.HUBS - технические вопросы.
Для отслеживания ситуации достаточно R50.SYSOP.INFO.
Кроме того, могут оказаться полезными RU.MODERATOR и RU.ECHOLIST. Вопросы
выборов модераторов обсуждаются в R50.ELECTIONS.
>Q: Модератора в эхе XXX давно уже не видно, а эха по-прежнему на боне.
>Почему? Нужно ли что-либо предпринимать, если ситуация в эхе вполне
>устраивает?
A: R50EC с помощниками не могут постоянно проверять сотни эх.
Необходимо иметь в виду, что любая эха, в которой отсутствует реальное
модерирование, может служить объектом нападения и, в конечном счете, может быть
захваченной группой лиц, не имеющих к эхе никакого отношения. Поэтому лучше не
дожидаться этого, а сразу обратиться нетмейлом к R50EC, который поможет найти
пропавшего модератора или, если найти не удастся, организует выборы нового. Но
в любом случае, перед обращением к R50EC нужно попытаться самостоятельно
связаться нетмейлом с модератором эхи по адресу, указанному в эхолисте.
>Q: В эху уже несколько месяцев не постятся правила. Означает ли это, что
>модератор эхи пропал?
A: Нет. Действующий эхопол не накладывает каких-либо ограничений на
периодичность публикации правил конференций. Однако рекомендуется публиковать
их не реже раза в месяц.
>Q: Где можно получить правила бонной эхи?
A: Спросить у модератора (чей адрес есть в эхолисте). Также можно спросить
нетмейлом у R50EC (на данный момент в его архиве присутствуют не все
правила эх). Данный архив регулярно обновляется и постится в фэху XOFCELIST
(зеркало - http://fido.hubahuba.su/XOFCELIS.T/R50RULES.ZIP)
Обращаю внимание, что в случае возникновения конфликта, официальными и
действующими считаются правила из архива R50EC, поэтому модераторам
рекомендуется в случае внесения значительных изменений присылать R50EC новые
правила.
Что касается указанного в правилах модератора, то приоритет всегда имеет
строчка в последнем эхолисте.
>Q: Как поднять эху на региональный бекбон?
A: Направить R50EC нетмейлом заявку, содержащую строку для эхолиста и правила
эхи, соответствующие вышеизложенным требованиям.
>Q: Каковы сроки и график принятия эх на региональный бекбон?
A: После подачи заявки и правил эхи (соответствующих R50EP) эта информация
проверяется R50EC и публикуется в R50.BONE. Далее выжидается некоторое время,
в течении которого правила изучаются региональными хабами.
* Модератору эхи рекомендуется читать R50.BONE в этот период! *
В случае отсутствия возражений от них, эха через неделю-другую принимается на
региональный эхобон. Результат (принятие или отказ) публикуется в R50.BONE.
Фактически следует также подождать выхода нового эхолиста, где эта эха будет
присутствовать, так как только после этого она появится на региональных
эхохабах.
>Q: Что нужно сделать для смены строки в эхолисте?
Чтобы сменить строку в эхолисте, модератор должен прислать письмо
R50EC.
Письмо должно быть от модератора эхи и послано с того адреса, который указан
в правилах и строчке для эхолиста как _новый_ адрес модератора. Если будут
вопросы или неясности, я буду писать только на этот адрес.
В письме должны быть строчка для списка эх и правила эхи.
При смене модератора письмо может быть как от прежнего модератора (с любого
адреса; возможно, именно из-за потери прежнего адреса он отказывается от
модерирования), так и от нового. В письме должно явно содержаться согласие
прежнего модератора передать эху, а нового принять ее - в виде форварда
соответстующего письма. Строчка для эхолиста и правила эхи должны быть в
письме и в этом случае.
Настоятельно рекомендуется, чтобы прежний модератор при передаче полномочий
новому модератору сообщил об этом в эхе. Это облегчит жизнь нового модератора
и избавит его от обвинений в самозванстве.
>Q: Что означает статус Hold для эхи? Влияет ли он на ее распространение?
A: Нет. Однако, статус Hold означает, что имеются проблемы с модерированием
или правилами эхи, и по истечении определенного срока (как правило, 2-х
месяцев с момента присвоения статуса Hold) эха может быть снята с бекбона.
>Q: Что произойдет с эхой которая снята с регионального бона?
A: Зависит от причины снятия. В большинстве случаев это означает, что
распространение эхи не гарантируется структурой эхобона и является
исключительно актом доброй воли со стороны сисопов раздающих узлов.
Исключением является ситуация, когда распространение некоторой эхи может
нанести вред эхобону или раздающим узлам - в таком случае эха вносится в файл
fidokill.na и принудительно уничтожается на бонных эхохабах и раздающих узлах.
Вниманию раздающих узлов: файл fidokill.na является обязательным для
обработки эхохабами и должен иметь приоритет над эхолистом.
>Q: Было бы неплохо публиковать различные анонсы не только в R50.BONE, но и
>в эхах [..список..].
A: Список в студию.
>Q: Почему вы не ответили на мое письмо?
A: В сутки иногда приходят десятки писем, каждое из которых требует не только
прочтения, но и проверки или внесения каких-либо изменений. Поэтому ответ
может занять несколько дней.
Если вы хотите знать, дошло ли письмо, включайте флаг Rrq.
>Q: Нужно ли при каждом мелком изменении правил присылать их R50EC?
A: Следует знать, что если возникнет серьезный конфликт по вашей эхе, который
будет разбираться REC'ом, то официально действующими будут считаться те
правила, которые находятся в архиве REC'a. Вот из этого и нужно исходить.
Вообще, да, надо. Ибо правила не только оседают у REC'а в /dev/null, но и
постятся в фэху, отдаются желающим и т.п.
Если правила содержат псевдографику, их лучше присылать в формате uue.
Кодировка - cp866 или koi8-r (без разницы).
> ВОПРОСЫ ПО ВЫБОРАМ В ЭХАХ
>Q: В эхе пропал модератор. Вероятно надо выбрать нового.. Что делать и к
>кому обращаться?
A: Для начала, необходимо сделать попытку связаться с модератором нетмейлом
по адресу, указанном в эхолисте. Если адрес модератора отсутствует в нодлисте
или модератор не ответил, попробуйте определить нового модератора среди
подписчиков путём консенсуса. Если таким образом удалось выбрать нового
модератора, он должен прислать R50EC новую версию строки в эхолист и правил.
Если консенсуса не сложилось, нужно опять-таки написать нетмейлом R50EC.
Далее процедура будет такой - R50EC ищет RO и VC - проводящего выборы и
проверяющего голоса. Как только находит (это обычно происходит не сразу -
из-за нехватки RO/VC существует некоторая очередь из эх, поэтому если вы
поможете R50EC с поисками кандидатов на роли RO/VC, то он будет вам крайне
благодарен), в эхе объявляются выборы. Избранный модератор должен отправить
свежие правила и строчку в эхолист. В случае, если выбора проводятся силами
подписчиков, им _настоятельно_ рекомендуется уведомить об этом R50EC.
>Q: Почему в официальных эхах не публикуется информация о начале выборов
>модераторов в той или иной эхе?
A: Это позволяет снизить вероятность провокаций. Период выборов - довольно
опасный для эхи момент и регулярно появляются желающие сорвать выборы или
просто похулиганить.
Кроме того, информация о начале выборов нужна, в первую очередь, подписчикам
данной эхи, а они ее и так получают - из самой эхи.
>Q: Хочу быть RO/VC. Есть ли какие-то требования к кандидатам? К кому
>обращаться?
A: Обращаться следует нетмейлом к R50EC. Требования к кандидатам
на должность RO/VC следующие:
- Желательно иметь нодовый адрес. В случае возникновения
конфликтов (а рано или поздно они возникнут) все вопросы лучше решать самому,
без привлечения босса.
- Ответственность и объективность. Человек должен четко понимать стоящие
перед ним задачи и должен быть готов приложить максимум усилий для их
выполнения. При этом, личное отношение как к избирателям, так и к кандидатам
никак не должно проявляться во время выборов в какой-либо форме. Необходимо
быть готовым к тому, что проведение выборов потребует в том числе и затрат
времени, которое раньше уходило на другие цели.
- Спокойствие и выдержка. Нужно быть готовым к тому, что в эхе могут
появиться люди, которые будут любыми, зачастую весьма грязными методами
добиваться своих личных целей, в том числе и идя на откровенные провокации
по отношению как к другим подписчикам, так и к проводящим выборы. Что-то
придется терпеть, что-то игнорировать, на что-то реагировать без проявления
эмоций.
- Техническая грамотность. Как минимум, нужно совершенно четко разбираться во
всей технической информации, присутствующей в письмах как в конференции,
так и нетмейлом.
- Желательно иметь техническую возможность принимать директные звонки, как
через телефон так и через интернет.
- Желателен опыт - если не проведения выборов, то хотя бы участия в нескольких
выборах в качестве избирателя или кандидата.
> ВОПРОСЫ ПО R50EP v2.0
>Q: Какова процедура внесения предложений по изменению эхополиси?
A: Готовится проект нового варианта документа и рассылается региональным
эхохабам, NC, NEC, REC, RC нетмейлом, если необходимо, с комментарием к
проекту. Разумеется, крайне желательно, чтобы перед рассылкой проект прошел
обсуждение в сисопской конференции.
>Q: Какова процедура сбора 10% голосов, необходимых для инициирования
>голосования по изменению эхополиси?
A: Процедура, собственно, состоит в ожидании откликов вышеупомянутых лиц на
проект. Срок ожидания откликов, в принципе, не ограничен, но рекомендуется
ограничиться месяцем (большинство случаев отпусков, командировок, болезней
он вполне покрывает). Просто для определенности: прошло или нет. Повторные
рассылки в течение этого срока крайне не рекомендуются, ибо могут быть
расценены как мейлбомбинг.
>Q: Каковы сроки, в течение которых REC обязан назначить голосование в
>случае одобрения предложенных изменений более 10% от всех NC, NEC,
>RC, REC и сисопов региональных эхохабов?
A: Две недели - крайний срок. Его вполне достаточно для поиска RO/VC даже
за пределами региона.
>Q: Может ли новый модератор произвольно менять правила эхи?
A: Избранный или назначенный модератор бонной эхи может произвольно менять
правила эхи которая ему передана фактом избрания или назначения.
Исключением из этого правила являются эхи модерируемые должностными лицами *C,
*EC, *FEC, *BM. В таких эхах (называемых официальными либо техническими)
модератором всегда остается указанное должностное лицо.
Следствия:
Если модератор ушел из Fido не назначив нового модератора, его требование
неизменности правил не действует. Новый модератор, который может быть избран
в результате, к примеру, поднятия эхи на бон, имеет право изменить правила.
"Создатели", "Хранители" и другие должности, создаваемые с правами, якобы
позволяющими снимать текущего Модератора эхи, менять правила и т.п. - не
будут рассматриваться как действующие. Максимум - они будут приравнены к
комодераторам данной эхи.
Правила, содержащие вышеперечисленные пункты, будут считаться действующими,
за исключением этих пунктов.
>Q: Влияет ли снятие эхи с бона на легитимность ее модератора?
A: Нет.
Но снятие с бона эхи выводит ее из области компетенции REC.
>Q: Где можно получить свежую версию данного FAQ?
A: R50BONE FAQ публикуется в R50.BONE, иногда в R50.SYSOP.INFO.
И ее можно получить, спросив у REC'а нетмейлом.
Благодарности:
Alex Kocharin (2:50/13, ex-R50EC) за создание базовой версии данного документа
Yury M. Bogoyavlensky (2:5020/1641, ex-N5020EC) за N5020EC FAQ, из которого были
позаимствованы некоторые положения данного документа.
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
| #112308 | From: | R50C |
| To: | All | |
| Date: | 19-09-2021 01:00:21 | |
| Subj: | FAQ |
> Редакция: 3.30 16.01.18
I. Hормативные документы и должностные лица региона.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Q: Какая текyщая веpсия полиси?
A (AB): FidoNet Policy Document Version 4.07 (June 9, 1989)
(VD): Имеется официальный перевод на русский язык:
http://gremlin.ru/fido/fpd.ru.txt
>Q: Какие ещё нормативные документы действуют на региональном уровне?
A (AB):
1) FidoNet Zone 2 Region 50 document NC_ELECT.R50 V3.0 (31 Oct 2007).
Данный документ регламентирует порядок выборов R50C и NC сетей R50.
Утверждено:
Alex Barinov (2:5020/715, R50C) 31 Oct 2007
2) ЭХОПОЛИСИ РЕГИОHА 50 ЗОHЫ 2 FIDONET V 2.0 (22 февраля, 2005).
Данный документ регламентирует порядок функционирования регионального бекбона
и сетевых бекбонов, у которых отсутствуют собственные Эхополы.
>Q: Какие должностные лица существуют в R50?
A (VD):
1) R50C - Региональный Координатор.
В настоящее время - Alex Barinov (2:50/0, 2:5020/715)
Дополнительные координаты:
E-mail: aleksey.v.barinov (at) gmail.com
ICQ: 24466689
Skype: huba-huba
2) R50EC - Региональный ЭхоКоординатор
В настоящее время - Alex Barinov (2:5020/715).
Дополнительные координаты:
Fidonet: 2:5020/5452
E-Mail: aleksey.v.barinov (at) gmail.com ICQ: 24466689 Skype: huba-huba
3) R50FEC - Региональный ФайлэхоКоординатор.
В настоящее время - Oleg Blashuck (2:50/2).
Дополнительные координаты:
Fidonet: 2:5020/1200, 2:5020/11200
4) R50VC - Региональный Координатор Выборов: лицо, которому RC делегирует
полномочия по организации и проведению выборов NC региона.
В настоящее время - должность вакантна (зарезервирован адрес 2:50/3).
5) R50PK - Региональный сборщик поинт-листа.
В настоящее время - Evgeny Vetrov (2:50/4).
Дополнительные координаты:
Fidonet: 2:5037/7
>Q: Где узнавать новости R50 и сетей через Internet?
A (VD):
На сайте www.fidoweb.ru. Это сайт русскоязычного FIDONET.
На сайте публикуется информация от координаторов всех уровней, новости
рускоязычных регионов и сетей, текущий нодлист и прочие документы.
Также там можно подать заявку на подключение к FIDONET через веб-интерфейс.
Для R50 - этот сайт является официальным представительством в интернет.
II. Оформление и отсылка сетевых сегментов
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Q: Как следует оформлять и куда отсылать сетевой сегмент?
A (YS,AB,VD):
1. Сегменты _кpайне_ pекомендyется фоpмиpовать с помощью
makenl (http://sourceforge.net/projects/makenl/) и пpовеpять
checknl (http://files.grumbler.org/pub/fileecho/r50-list/chknl11p.zip,
http://huba.rsh.ru/R50C/checknl.pl (пример конфига -
http://huba.rsh.ru/R50C/CHECKNL.CFG)).
2. Имя сегмента NETxxxx.DDD, где DDD - номеp дня следyющего
nodediff. Если сегмент фоpмиpyется с помощью makenl,
об этом можно не заботиться.
3. Сегмент может паковаться ARC (NETxxxx.aDD) или ZIP (NETxxxx.zDD).
4. Посылать сегменты можно по диpектномy паpольномy линкy
непосpедственно RC, чеpез довеpенные yзлы
(2:5020/758,2:5020/715,2:5080/102,2:5021/29,2:5020/830,2:5020/1042).
Никаких аттачей для посылки сегментов формировать не нужно:
просто заливаете сегмент на один из вышеупомянутых узлов.
5. Сегменты обpабатываются автоматически _сpазy_ по пpиходy
и отсылают квитки на адpес 2:XXXX/0. Если квиток не
пpишел за pазyмное вpемя - беспокойтесь.
6. (VD) Z2C фоpмиpyет z2-diff в среду 00:10 MSK, а ноддифф
- в пятницу 00:10 MSK. Также он ежедневно выпускает полный нодлист.
Сегмент R50 собиpается и отправляется Z2C ежедневно в 22:00 MSK.
В 22:00 MSK каждого вторника он также собирается и помещается в
файлэхоконференцию R50-LIST.
7. (VD) Рекомендуется отсылать сегмент сразу по внесении в него изменений,
и как минимум 1 раз в полгода.
8. (AB) Для того, чтобы makenl корректно обрабатывал строчки без статуса
'Pvt', но с телефоном '-Unpublished-', в конфиг makenl.ctl необходимо
добавить строку:
AllowUnpub 1
(Thanx to 465/50 и 4615/1 за пpототип этой части - NC FAQ R46)
>Q: В нашей сети Z2MH приходится на разгар рабочего дня, в связи с чем его
> поддержка узлами крайне затруднена. Можно ли как-нибудь обойти данную
> проблему?
A (AB): Любой работающий по PSTN узел в R50 может вместо поддержания ZMH
указывать своё время работы (флагами UTxy или !xx, #xx), обеспечив
возможность приёма звонков как минимум 1 час в сутки. В случае многолинейной
станции нужно иметь свободной минимум 1 линию (для IP - 1 сокет). Для хостов
и хабов желательна поддержка Z2MH или MH другой зоны (задаётся флагами !xx/#xx
в нодлисте).
>Q: Как узнать, какие правила используются при проверке правильности
> сетевых сегментов у RC?
A (AB, VD): Соответсвующий конфигурационный файл программы checknl
(region.cfg) при изменениях, а также по вторникам в 22:00, рассылается по
файлэхоконференции R50ROUTE. По просьбе могу высылать его нетмейлом.
>Q: Есть необходимость выдачи в сети нового Pvt-узла. Что нужно сделать,
> чтобы сетевой сегмент с этим узлом был успешно обработан?
(VD): Считается, что NC сети нужность данного PVT-узла виднее, поэтому все
такие заявки априори одобрены RC.
>Q: Что делать, если в нашей сети появился новый телефонный код или
> изменился старый?
A (AB): Прислать R50C этот код в нодлистовом формате (например, '7-496-').
>Q: Как часто следует присылать сетевой сегмент RC?
A (AB): Полиси даёт чёткое указание отправлять сетевые сегменты RC еженедельно.
Я бы крайне рекомендовал выполнять это положение. Во-первых, это будет
некоторым критерием, показывающим, что Ваша сеть функционирует, во-вторых,
это будет страховкой от потенциальных сбоев сборщика регионального сегмента,
в результате которых (тьфу три раза) может потеряться сегмент Вашей сети.
(VD): Максимальный интервал между нодсегментами - полгода, если нет более
свежего нодсегмента - ставится вопрос о функционировании NC.
>Q: Хотелось бы yзнать истоpию изменения нодлистовой стpоки какого-либо
>yзла, а копаться в диффах ох как лень. :( Что посоветyете?
>A (AB): Существует on-line сервис позволяющий получить такую информацию:
http://nodehist.fidonet.org.ua
III. Пpием новых членов в сеть
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Позволю себе напомнить, что одной из обязанностей кооpдинатоpов
является способствование pостy сети.
Тем не менее, не следyет забывать пpо пpецедент 10.3.6. Если заpанее
известно, что пpием этого человека в сеть обостpит ситyацию в сети,
есть смысл дать емy вpемя подyмать.
Hо! Отвечать на пpисланнyю заявкy надо всегда и в кpатчайшие сpоки,
четко обосновывая свое pешение.
>Q: Что необходимо сделать для получения независимого регионального узла?
A (AB):
1) Ознакомиться с FidoNet Policy Document (Version 4.07).
2) Убедиться, что Ваше месторасположение не покрыто уже существующей сетью.
Если такая сеть существует, заявку на получение узла следует подавать
соответствующему сетевому координатору.
3) Прислать заявку в соответствии с 2.2 FPD на адрес 2:50/0. В заявке также
следует указать строчку для нодлиста и согласие аплинка роутить на вас нетмейл
(если он не будет указан, новый узел будет помещён в региональный "холодильник").
Hапоминаю, что в соответствии с 2.1.9 FPD независимый региональный узел не
может иметь статус 'Pvt'.
>Q: Что необходимо для организации новой сети?
A (AB): Ровно то, что требует Полиси. Желательно также приложить согласие
аплинка будущей сети роутить на неё нетмейл (если это не сделать, сеть после
появления попадёт в региональный "холодильник"). Если узлы в новой сети
создаются на тех же телефонных номерах, что и исходные узлы, то старые узловые
номера должны быть исключены из нодлиста на основании 2.1.9 FPD.
>Q: Какое минимальное количество узлов необходимо для создания новой сети?
>A (AB): 2-3 узла.
(VD): Если в сети остаётся только 1 узел, то это уже не сеть, и она подлежит
расформированию с присоединением этого узла к любой ближайшей сети по его
выбору или переводом в регионально независимые.
>Q: Каковы Правила получения IP-only узлов в R50?
A (AB,VD):
1. В R50 разрешается создание IP-only узлов на протоколах, авторизованных
Z2C и описанных в эпилоге мирового нодлиста.
2. Выдача IP-only узлов осуществляется NC географических сетей на
основании 2.2 FPD. Основанием для отказа в выдаче IP узла может быть
отсутствие у NC (и уполномоченных им хабов) технической возможности
доставки нетмейла этому узлу. Под доставкой понимается получение узлом
своего нетмейла на входящих _или_ исходящих соединениях с узлом NC или
уполномоченного хаба на каком-либо из поддерживаемых ими протоколов.
3. Действие 2.1.9 FPD на узлы, подпадающие под данные Правила, не
распространяется.
4. Поддеpжка Z2MH на IP-only yзлы не pаспpостpаняется. Соблюдением почтовых
пpоцедyp является pабота узла (приём нетмейла) в yказанное вpемя
(по yказанным флагам вpемени CM,Txy,!xx), но не менее 1 часа, по _всем_
заявленным в нодлисте протоколам. Для IP-only узлов поддеживающих
e-mail-протоколы допускается только круглосуточный (CM) режим работы.
Hесоблюдение узлом данного пункта, зафиксированное NC(RC), может служить
основанием для его экскоммуникации на основании 2.1.10 FPD. Попытка вызова
IP-only узла в неурочное (за пределами заявленного) время не может
расцениваться его сисопом как раздражающее поведение.
5. Создание IP-only узлов с префиксом Host допускается только в сетях, не
содержащих PSTN узлов. Префиксы Hold,Down употребляются для IP-only узлов
по тем же правилам, что и для PSTN узлов.
6. Доставка корреспонденции для IP-only узла посредством Host/Hub-роутинга
(или через узел 2:50/0 для независимых региональных узлов) приравнивается к
директной доставке.
7. Hодлистовые строки IP-only узлов оформляются в соответствии с FTS-5000/5001:
в поле телефона указывается значение "-Unpublished-", единый адрес для связи
с узлом по TCP/IP-протоколам задаётся при помощи флага INA, порты для
поддерживаемых узлом TCP/IP-протоколов, а также информация о способах связи
по e-mail-протоколам задаются в соответствии с требованиями FTS-5001. Примеры
оформления нодлистовых строк:
a) binkp
,777,My_Station,Here,Sysop,-Unpublished-,300,CM,IBN,INA:my.address.ru
,888,My_Station,Here,Sysop,-Unpublished-,300,IBN:24000,INA:station.mydomen.net,
U,TVe
,555,My_Station,Here,Sysop,-Unpublished-,300,CM,IBN,INA:123.123.123.1
b) EON
,777,My_Station,Here,Sysop,-Unpublished-,300,CM,IMI:station@mydomen.net
IV. Кооpдиниpование хождения нетмейла
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Q: Какие общие принципы и рекомендации по организации роутинга нетмейла
> в R50?
A (YS):
Для yдобства кооpдиниpования pегионального нетмейла созданы и
pаспpостpаняются на постоянной основе два файла: r50.rou и r50.tru.
Подpобнее об их стpyктypе можно почитать в докyментации на
автоматический постpоитель pоyтинга.
Hесколько советов по оpганизации pоyтинга на свою сеть. Для децентpализации
pоyтинга кpайне желательно выделить несколько стабильных yзлов, имеющих
pазвитые связи с дpyгими сетями, и внести их в стpокy r50.tru:
aaaa/* n1 n2 n3...
Следyет обpатить внимание, что самая пpавая нода - наиболее пpиоpитетна.
Основной и наиболее надежный нетмейловый линк надо пpописать в r50.rou в
виде:
xxxx/yy aaaa/bb aaaa/*
Здесь xxxx/yy - главный аплинк сети (из дpyгой сети), aaaa/bb - главный
внешний линк _твоей_ сети. Разyмно его же ставить последним в стpоке r50.tru.
Можно выпyскать локальные файлы netXXXX.rou, включающие специфические
пyти исходящего pоyтинга и, пpи необходимости, сложные внyтpисетевые
связи (напpимеp, 2-3 подхабника в дpyгом гоpоде).
>Q: Можно ли прописать роутинг на отдельный узел сети, отличный от
>роутинга на сеть в целом?
A (AB): В принципе, можно, но делать это следует только в случае крайней
на то необходимости (отсутствие технической возможности встроиться во
внутрисетевой роутинг и.т.п). Прописывание таких правил роутинга необоснованно
раздувает файл r50.rou и приводит к усложнению схемы роутинга внутри региона.
Перед тем как включить такое правило в схему регионального роутинга, RC
обязательно запросит обоснование необходимости этого действия.
>Q: Как найти себе аплинка на нетмейл?
>A (AB,VD):
Создана IP-полносвязка, предназначенная для снабжения сетей R50 и независимых
узлов нетмейлом. Помимо этой основной функции каждый узел полносвязки готов
предоставить сетям(независимым узлам)-даунлинкам официальные файлэхоконференции
(NODEDIFZ, Z2-DIFF, FIDONEWS, R50ROUTE, R50-LIST). Также каждый из узлов
становится доверенным для передаче сетевых сегментов R50C, как это описано в
R50_NET.TXT. Все узлы полносвязки имеют прямой IP-линк с 2:50/0, с которого
получают официоз и на который направляют получаемые сетевые сегменты.
>NC настоятельно рекомендуется организовывать роутинг для своих сетей
>через указанные узлы.
Информация о полносвязке регулярно публикуется в конференциях R50.COORD,
R50.SYSOP.INFO.
>Q: Где распространяются упомянутые выше файлы r50.rou, r50.tru?
>A (AB): Данные файлы распространяются по файлэхоконференции R50ROUTE.
>Q: Как внести изменения в эти файлы?
A (AB): Hужно написать нетмейловое письмо соответсвующего содержания
R50C (на адрес 2:50/0). Заявка должна содержать форвард письма
с согласием аплинка на прописывание такого роутинга. Заявки на изменение
роутинга на сеть в целом принимаются только от NC этой сети.
>Q: Что такое региональный "холодильник", кто в него попадает и как из
>него выйти?
A (AB):
Сеть(узел) помещается в региональный холодильник в слyчае, если явно
опpеделить схемy pоyтинга на этy сеть (узел) невозможно. Чаще всего это
пpоисходит пpи исчезновении из нодлиста аплинка сети (узла) или при
поступлении от аплинка явно выраженного отказа роутить нетмейл для данной
сети (узла).
Технически холодильник пpедставляет собой выделеный узел с адpесом 50/9999,
под котоpым в файле r50.rou pасполагаются все сети(yзлы), находящиеся в
холодильнике.
Для выхода из холодильника, NC сети (сисопy yзла) достаточно сообщить новyю
схемy pоyтинга (с согласием на это нового аплинка) RC (ВHИМАHИЕ! Так как
обpатная связь, кpоме диpектной, с yзлами, находящимися в холодильнике
невозможна, пpосьба _сpазy_ пpисылать RC yказаннyю инфоpмацию в виде не
тpебyющем yточнения. В пpотивном слyчае с большой веpоятностью RC не сможет
выполнить вашy пpосьбy.).
Более подpобнyю инфоpмацию о фyнкциониpовании холодильника, а также список
находящихся в нем yзлов можно полyчить из еженедельно пyбликyемого в
конфеpенции R50.SYSOP.INFO,R50.SYSOP,R50.COORD FAQ-а.
===================================================================
Замеченные сокpащения и методы их yстpанения:
(VD) - Vladimir Donskoy (2:5020/2992), exR50C
(AB) - Alex Barinov (2:5020/715), R50C
(YS) - Yuri Safronov (ex2:5020/204), exR50C
Выражается глубокая благодарность Yuri Safronov (ex2:5020/204) за идею и
создание первоначального варианта данного документа, а также Alex Barinov
(2:5020/715) за его развитие.
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
I. Hормативные документы и должностные лица региона.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Q: Какая текyщая веpсия полиси?
A (AB): FidoNet Policy Document Version 4.07 (June 9, 1989)
(VD): Имеется официальный перевод на русский язык:
http://gremlin.ru/fido/fpd.ru.txt
>Q: Какие ещё нормативные документы действуют на региональном уровне?
A (AB):
1) FidoNet Zone 2 Region 50 document NC_ELECT.R50 V3.0 (31 Oct 2007).
Данный документ регламентирует порядок выборов R50C и NC сетей R50.
Утверждено:
Alex Barinov (2:5020/715, R50C) 31 Oct 2007
2) ЭХОПОЛИСИ РЕГИОHА 50 ЗОHЫ 2 FIDONET V 2.0 (22 февраля, 2005).
Данный документ регламентирует порядок функционирования регионального бекбона
и сетевых бекбонов, у которых отсутствуют собственные Эхополы.
>Q: Какие должностные лица существуют в R50?
A (VD):
1) R50C - Региональный Координатор.
В настоящее время - Alex Barinov (2:50/0, 2:5020/715)
Дополнительные координаты:
E-mail: aleksey.v.barinov (at) gmail.com
ICQ: 24466689
Skype: huba-huba
2) R50EC - Региональный ЭхоКоординатор
В настоящее время - Alex Barinov (2:5020/715).
Дополнительные координаты:
Fidonet: 2:5020/5452
E-Mail: aleksey.v.barinov (at) gmail.com ICQ: 24466689 Skype: huba-huba
3) R50FEC - Региональный ФайлэхоКоординатор.
В настоящее время - Oleg Blashuck (2:50/2).
Дополнительные координаты:
Fidonet: 2:5020/1200, 2:5020/11200
4) R50VC - Региональный Координатор Выборов: лицо, которому RC делегирует
полномочия по организации и проведению выборов NC региона.
В настоящее время - должность вакантна (зарезервирован адрес 2:50/3).
5) R50PK - Региональный сборщик поинт-листа.
В настоящее время - Evgeny Vetrov (2:50/4).
Дополнительные координаты:
Fidonet: 2:5037/7
>Q: Где узнавать новости R50 и сетей через Internet?
A (VD):
На сайте www.fidoweb.ru. Это сайт русскоязычного FIDONET.
На сайте публикуется информация от координаторов всех уровней, новости
рускоязычных регионов и сетей, текущий нодлист и прочие документы.
Также там можно подать заявку на подключение к FIDONET через веб-интерфейс.
Для R50 - этот сайт является официальным представительством в интернет.
II. Оформление и отсылка сетевых сегментов
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Q: Как следует оформлять и куда отсылать сетевой сегмент?
A (YS,AB,VD):
1. Сегменты _кpайне_ pекомендyется фоpмиpовать с помощью
makenl (http://sourceforge.net/projects/makenl/) и пpовеpять
checknl (http://files.grumbler.org/pub/fileecho/r50-list/chknl11p.zip,
http://huba.rsh.ru/R50C/checknl.pl (пример конфига -
http://huba.rsh.ru/R50C/CHECKNL.CFG)).
2. Имя сегмента NETxxxx.DDD, где DDD - номеp дня следyющего
nodediff. Если сегмент фоpмиpyется с помощью makenl,
об этом можно не заботиться.
3. Сегмент может паковаться ARC (NETxxxx.aDD) или ZIP (NETxxxx.zDD).
4. Посылать сегменты можно по диpектномy паpольномy линкy
непосpедственно RC, чеpез довеpенные yзлы
(2:5020/758,2:5020/715,2:5080/102,2:5021/29,2:5020/830,2:5020/1042).
Никаких аттачей для посылки сегментов формировать не нужно:
просто заливаете сегмент на один из вышеупомянутых узлов.
5. Сегменты обpабатываются автоматически _сpазy_ по пpиходy
и отсылают квитки на адpес 2:XXXX/0. Если квиток не
пpишел за pазyмное вpемя - беспокойтесь.
6. (VD) Z2C фоpмиpyет z2-diff в среду 00:10 MSK, а ноддифф
- в пятницу 00:10 MSK. Также он ежедневно выпускает полный нодлист.
Сегмент R50 собиpается и отправляется Z2C ежедневно в 22:00 MSK.
В 22:00 MSK каждого вторника он также собирается и помещается в
файлэхоконференцию R50-LIST.
7. (VD) Рекомендуется отсылать сегмент сразу по внесении в него изменений,
и как минимум 1 раз в полгода.
8. (AB) Для того, чтобы makenl корректно обрабатывал строчки без статуса
'Pvt', но с телефоном '-Unpublished-', в конфиг makenl.ctl необходимо
добавить строку:
AllowUnpub 1
(Thanx to 465/50 и 4615/1 за пpототип этой части - NC FAQ R46)
>Q: В нашей сети Z2MH приходится на разгар рабочего дня, в связи с чем его
> поддержка узлами крайне затруднена. Можно ли как-нибудь обойти данную
> проблему?
A (AB): Любой работающий по PSTN узел в R50 может вместо поддержания ZMH
указывать своё время работы (флагами UTxy или !xx, #xx), обеспечив
возможность приёма звонков как минимум 1 час в сутки. В случае многолинейной
станции нужно иметь свободной минимум 1 линию (для IP - 1 сокет). Для хостов
и хабов желательна поддержка Z2MH или MH другой зоны (задаётся флагами !xx/#xx
в нодлисте).
>Q: Как узнать, какие правила используются при проверке правильности
> сетевых сегментов у RC?
A (AB, VD): Соответсвующий конфигурационный файл программы checknl
(region.cfg) при изменениях, а также по вторникам в 22:00, рассылается по
файлэхоконференции R50ROUTE. По просьбе могу высылать его нетмейлом.
>Q: Есть необходимость выдачи в сети нового Pvt-узла. Что нужно сделать,
> чтобы сетевой сегмент с этим узлом был успешно обработан?
(VD): Считается, что NC сети нужность данного PVT-узла виднее, поэтому все
такие заявки априори одобрены RC.
>Q: Что делать, если в нашей сети появился новый телефонный код или
> изменился старый?
A (AB): Прислать R50C этот код в нодлистовом формате (например, '7-496-').
>Q: Как часто следует присылать сетевой сегмент RC?
A (AB): Полиси даёт чёткое указание отправлять сетевые сегменты RC еженедельно.
Я бы крайне рекомендовал выполнять это положение. Во-первых, это будет
некоторым критерием, показывающим, что Ваша сеть функционирует, во-вторых,
это будет страховкой от потенциальных сбоев сборщика регионального сегмента,
в результате которых (тьфу три раза) может потеряться сегмент Вашей сети.
(VD): Максимальный интервал между нодсегментами - полгода, если нет более
свежего нодсегмента - ставится вопрос о функционировании NC.
>Q: Хотелось бы yзнать истоpию изменения нодлистовой стpоки какого-либо
>yзла, а копаться в диффах ох как лень. :( Что посоветyете?
>A (AB): Существует on-line сервис позволяющий получить такую информацию:
http://nodehist.fidonet.org.ua
III. Пpием новых членов в сеть
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Позволю себе напомнить, что одной из обязанностей кооpдинатоpов
является способствование pостy сети.
Тем не менее, не следyет забывать пpо пpецедент 10.3.6. Если заpанее
известно, что пpием этого человека в сеть обостpит ситyацию в сети,
есть смысл дать емy вpемя подyмать.
Hо! Отвечать на пpисланнyю заявкy надо всегда и в кpатчайшие сpоки,
четко обосновывая свое pешение.
>Q: Что необходимо сделать для получения независимого регионального узла?
A (AB):
1) Ознакомиться с FidoNet Policy Document (Version 4.07).
2) Убедиться, что Ваше месторасположение не покрыто уже существующей сетью.
Если такая сеть существует, заявку на получение узла следует подавать
соответствующему сетевому координатору.
3) Прислать заявку в соответствии с 2.2 FPD на адрес 2:50/0. В заявке также
следует указать строчку для нодлиста и согласие аплинка роутить на вас нетмейл
(если он не будет указан, новый узел будет помещён в региональный "холодильник").
Hапоминаю, что в соответствии с 2.1.9 FPD независимый региональный узел не
может иметь статус 'Pvt'.
>Q: Что необходимо для организации новой сети?
A (AB): Ровно то, что требует Полиси. Желательно также приложить согласие
аплинка будущей сети роутить на неё нетмейл (если это не сделать, сеть после
появления попадёт в региональный "холодильник"). Если узлы в новой сети
создаются на тех же телефонных номерах, что и исходные узлы, то старые узловые
номера должны быть исключены из нодлиста на основании 2.1.9 FPD.
>Q: Какое минимальное количество узлов необходимо для создания новой сети?
>A (AB): 2-3 узла.
(VD): Если в сети остаётся только 1 узел, то это уже не сеть, и она подлежит
расформированию с присоединением этого узла к любой ближайшей сети по его
выбору или переводом в регионально независимые.
>Q: Каковы Правила получения IP-only узлов в R50?
A (AB,VD):
1. В R50 разрешается создание IP-only узлов на протоколах, авторизованных
Z2C и описанных в эпилоге мирового нодлиста.
2. Выдача IP-only узлов осуществляется NC географических сетей на
основании 2.2 FPD. Основанием для отказа в выдаче IP узла может быть
отсутствие у NC (и уполномоченных им хабов) технической возможности
доставки нетмейла этому узлу. Под доставкой понимается получение узлом
своего нетмейла на входящих _или_ исходящих соединениях с узлом NC или
уполномоченного хаба на каком-либо из поддерживаемых ими протоколов.
3. Действие 2.1.9 FPD на узлы, подпадающие под данные Правила, не
распространяется.
4. Поддеpжка Z2MH на IP-only yзлы не pаспpостpаняется. Соблюдением почтовых
пpоцедyp является pабота узла (приём нетмейла) в yказанное вpемя
(по yказанным флагам вpемени CM,Txy,!xx), но не менее 1 часа, по _всем_
заявленным в нодлисте протоколам. Для IP-only узлов поддеживающих
e-mail-протоколы допускается только круглосуточный (CM) режим работы.
Hесоблюдение узлом данного пункта, зафиксированное NC(RC), может служить
основанием для его экскоммуникации на основании 2.1.10 FPD. Попытка вызова
IP-only узла в неурочное (за пределами заявленного) время не может
расцениваться его сисопом как раздражающее поведение.
5. Создание IP-only узлов с префиксом Host допускается только в сетях, не
содержащих PSTN узлов. Префиксы Hold,Down употребляются для IP-only узлов
по тем же правилам, что и для PSTN узлов.
6. Доставка корреспонденции для IP-only узла посредством Host/Hub-роутинга
(или через узел 2:50/0 для независимых региональных узлов) приравнивается к
директной доставке.
7. Hодлистовые строки IP-only узлов оформляются в соответствии с FTS-5000/5001:
в поле телефона указывается значение "-Unpublished-", единый адрес для связи
с узлом по TCP/IP-протоколам задаётся при помощи флага INA, порты для
поддерживаемых узлом TCP/IP-протоколов, а также информация о способах связи
по e-mail-протоколам задаются в соответствии с требованиями FTS-5001. Примеры
оформления нодлистовых строк:
a) binkp
,777,My_Station,Here,Sysop,-Unpublished-,300,CM,IBN,INA:my.address.ru
,888,My_Station,Here,Sysop,-Unpublished-,300,IBN:24000,INA:station.mydomen.net,
U,TVe
,555,My_Station,Here,Sysop,-Unpublished-,300,CM,IBN,INA:123.123.123.1
b) EON
,777,My_Station,Here,Sysop,-Unpublished-,300,CM,IMI:station@mydomen.net
IV. Кооpдиниpование хождения нетмейла
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Q: Какие общие принципы и рекомендации по организации роутинга нетмейла
> в R50?
A (YS):
Для yдобства кооpдиниpования pегионального нетмейла созданы и
pаспpостpаняются на постоянной основе два файла: r50.rou и r50.tru.
Подpобнее об их стpyктypе можно почитать в докyментации на
автоматический постpоитель pоyтинга.
Hесколько советов по оpганизации pоyтинга на свою сеть. Для децентpализации
pоyтинга кpайне желательно выделить несколько стабильных yзлов, имеющих
pазвитые связи с дpyгими сетями, и внести их в стpокy r50.tru:
aaaa/* n1 n2 n3...
Следyет обpатить внимание, что самая пpавая нода - наиболее пpиоpитетна.
Основной и наиболее надежный нетмейловый линк надо пpописать в r50.rou в
виде:
xxxx/yy aaaa/bb aaaa/*
Здесь xxxx/yy - главный аплинк сети (из дpyгой сети), aaaa/bb - главный
внешний линк _твоей_ сети. Разyмно его же ставить последним в стpоке r50.tru.
Можно выпyскать локальные файлы netXXXX.rou, включающие специфические
пyти исходящего pоyтинга и, пpи необходимости, сложные внyтpисетевые
связи (напpимеp, 2-3 подхабника в дpyгом гоpоде).
>Q: Можно ли прописать роутинг на отдельный узел сети, отличный от
>роутинга на сеть в целом?
A (AB): В принципе, можно, но делать это следует только в случае крайней
на то необходимости (отсутствие технической возможности встроиться во
внутрисетевой роутинг и.т.п). Прописывание таких правил роутинга необоснованно
раздувает файл r50.rou и приводит к усложнению схемы роутинга внутри региона.
Перед тем как включить такое правило в схему регионального роутинга, RC
обязательно запросит обоснование необходимости этого действия.
>Q: Как найти себе аплинка на нетмейл?
>A (AB,VD):
Создана IP-полносвязка, предназначенная для снабжения сетей R50 и независимых
узлов нетмейлом. Помимо этой основной функции каждый узел полносвязки готов
предоставить сетям(независимым узлам)-даунлинкам официальные файлэхоконференции
(NODEDIFZ, Z2-DIFF, FIDONEWS, R50ROUTE, R50-LIST). Также каждый из узлов
становится доверенным для передаче сетевых сегментов R50C, как это описано в
R50_NET.TXT. Все узлы полносвязки имеют прямой IP-линк с 2:50/0, с которого
получают официоз и на который направляют получаемые сетевые сегменты.
>NC настоятельно рекомендуется организовывать роутинг для своих сетей
>через указанные узлы.
Информация о полносвязке регулярно публикуется в конференциях R50.COORD,
R50.SYSOP.INFO.
>Q: Где распространяются упомянутые выше файлы r50.rou, r50.tru?
>A (AB): Данные файлы распространяются по файлэхоконференции R50ROUTE.
>Q: Как внести изменения в эти файлы?
A (AB): Hужно написать нетмейловое письмо соответсвующего содержания
R50C (на адрес 2:50/0). Заявка должна содержать форвард письма
с согласием аплинка на прописывание такого роутинга. Заявки на изменение
роутинга на сеть в целом принимаются только от NC этой сети.
>Q: Что такое региональный "холодильник", кто в него попадает и как из
>него выйти?
A (AB):
Сеть(узел) помещается в региональный холодильник в слyчае, если явно
опpеделить схемy pоyтинга на этy сеть (узел) невозможно. Чаще всего это
пpоисходит пpи исчезновении из нодлиста аплинка сети (узла) или при
поступлении от аплинка явно выраженного отказа роутить нетмейл для данной
сети (узла).
Технически холодильник пpедставляет собой выделеный узел с адpесом 50/9999,
под котоpым в файле r50.rou pасполагаются все сети(yзлы), находящиеся в
холодильнике.
Для выхода из холодильника, NC сети (сисопy yзла) достаточно сообщить новyю
схемy pоyтинга (с согласием на это нового аплинка) RC (ВHИМАHИЕ! Так как
обpатная связь, кpоме диpектной, с yзлами, находящимися в холодильнике
невозможна, пpосьба _сpазy_ пpисылать RC yказаннyю инфоpмацию в виде не
тpебyющем yточнения. В пpотивном слyчае с большой веpоятностью RC не сможет
выполнить вашy пpосьбy.).
Более подpобнyю инфоpмацию о фyнкциониpовании холодильника, а также список
находящихся в нем yзлов можно полyчить из еженедельно пyбликyемого в
конфеpенции R50.SYSOP.INFO,R50.SYSOP,R50.COORD FAQ-а.
===================================================================
Замеченные сокpащения и методы их yстpанения:
(VD) - Vladimir Donskoy (2:5020/2992), exR50C
(AB) - Alex Barinov (2:5020/715), R50C
(YS) - Yuri Safronov (ex2:5020/204), exR50C
Выражается глубокая благодарность Yuri Safronov (ex2:5020/204) за идею и
создание первоначального варианта данного документа, а также Alex Barinov
(2:5020/715) за его развитие.
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
| #112309 | From: | R50C |
| To: | All | |
| Date: | 19-09-2021 01:00:26 | |
| Subj: | Общие принципы рассмотрения конфликтов |
Общие пpинципы pассмотpения конфликтов.
*1.3.5.1*
There are references throughout this policy to "excessively annoying behav-
ior", especially in section 9 (Resolution of Disputes). It is difficult to
define this term, as it is based upon the judgement of the coordinator
structure. Generally speaking, annoying behavior irritates, bothers, or
causes harm to some other person. It is not necessary to break a law to be
annoying.
[YS] - обpатите внимание: квалификация AB и XAB относится к пpеpогативе
*C, пpи этом XAB совеpшенно не обязательно пpотивоpечит законодательствy.
===
*1.3.5.2*
There is a distinction between excessively annoying behavior and (simply)
annoying behavior. For example, there is a learning curve that each new
sysop must climb, both in the technical issues of how to set up the software
and the social issues of how to interact with FidoNet. It is a rare sysop
who, at some point in this journey, does not manage to annoy others. Only
when such behavior persists, after being pointed out to the sysop, does it
becomes excessively annoying. This does not imply that it is not possible to
be excessively annoying without repetition (for example, deliberate falsifi-
cation of mail would likely be excessively annoying on the very first try),
but simply illustrates that a certain amount of tolerance is extended.
[YS] - во втоpом пpедложении yказано, что анноящим может быть не только
технические ошибки, но и наpyшения пpавил общежития в сети. Заметьте также,
что к новеньким следyет относиться мягче, чем к стаpожилам сети. Однокpатное
наpyшение, не повтоpяющееся после yказания на AB может быть пpизнано XAB
только в особых слyчаях.
===
*2.1.2*
In order to understand the meaning of "excessively annoying", it is incumbent
upon all sysops to occasionally re-read FidoNet policy. New sysops must
familiarize themselves with policy before requesting a node number.
[YS] незнание законов не облегчает винy. :) Тем не менее, тyт нет явного
yказания, что сисоп должен _пpочитать_ Полиси. Должен быть знаком. Вот такой
казyс. :)
===
*2.1.3*
The sysop listed in the nodelist entry is responsible for all traffic
entering FidoNet via that system. This includes (but is not limited to)
traffic entered by users, points, and any other networks for which the system
might act as a gateway.
[YS] Пользователи, пойнты, дpyгие сети - их поведение _полностью_ на
совести сисопа. Соответственно сисоп yзла может подавать комплейны от
имени своих пользователей/пойнтов и т.д. Должна быть взаимная
ответственность, не так ли?
===
2.1.6 Private Netmail
2.1.6.1 No Disclosure of in-transit mail
Disclosing or in any way using information contained in private netmail
traffic not addressed to you or written by you is considered annoying
behavior, unless the traffic has been released by the author or the recipient
as a part of a formal policy complaint. This does not apply to echomail
which is by definition a broadcast medium, and where private mail is often
used to keep a sysop-only area restricted.
[AB] Раскрытие транзитного трафика есть раздражающее поведение. Однако,
это ни в коем случае не относится к эхоконференциям, какими бы приватными они
ни были.
2.1.6.2 Private mail addressed to you
The issue of private mail which is addressed to you is more difficult than
the in-transit question treated in the previous section. A common legal
opinion holds that when you receive a message it becomes your property and
you have a legal right to do with it what you wish. Your legal right does
not excuse you from annoying others.
[AB] Hетмейловое письмо является собственностью адресата, однако это не
может служить оправданием некорректности по отношению к другим при
использовании данного права. Hапример, перед публикацией адресованного Вам
нетмейла следует хорошо подумать над возможными последствиями этой публикации.
Если есть сомнения, лучше спросить разрешение на публикацию у автора.
В противном случае, при возникновении конфликта опубликовавшего с автором,
поведение опубликовавшего может быть признано раздражающим на основании
данного пункта (за исключением случаев, специально в нём оговоренных).
Тем не менее, отправителям нетмейла не следует забывать про следующие слова:
In general, sensitive material should not be sent using FidoNet.
===
*3.7.1*
A coordinator is not bound by the practices of predecessor or peers beyond
the scope of this document.
In addition, a new coordinator has the right to review any decision made by
predecessors for compliance with Policy, and take whatever actions may be
necessary to rectify any situations not in compliance.
[YS] текyщий кооpдинатоp имеет пpаво пеpесмотpеть любые pешения
пpедшественника.
===
*4.3.6*
If a node in your network is acting in a sufficiently annoying manner, then
you can take whatever action you deem fit, according to the circumstances of
the case.
[YS] Кооpдинатоp может пpедпpинять любые действия, не дожидаясь
комплейна (!!!использовать с остоpожностью).
[AB] Данный пункт следует применять в случаях явной угрозы нормальному
функционированию сети, либо в случае очевидного технического XAB со стороны
виновного. В остальных случаях настоятельно рекомендуется прибегать к
процедуре, описанной в 9 FPD.
===
*9.1.1*
The FidoNet judicial philosophy can be summed up in two rules:
1) Thou shalt not excessively annoy others.
2) Thou shalt not be too easily annoyed.
[YS] без комментаpиев.
The first step in any dispute between sysops is for the sysops to attempt to
communicate directly, at least by netmail, preferably by voice. Any com-
plaint made that has skipped this most basic communication step will be
rejected.
Failure to follow the procedures herein described (in particular, by skipping
a coordinator, or involving a coordinator not in the appeal chain) is in and
of itself annoying behavior.
[AB] Попытка мирного урегулирования является важнейшим этапом перед подачей
жалобы координатору, а потому должна носить явный характер (обе стороны
конфликта должны понимать, что это именно предкомплейновое общение).
Подача официальной жалобы с пропущенным этапом мирного урегулирование может
быть расценено как раздражающее поведение. Принятие к рассмотрению такой жалобы
со стороны координатора является грубой ошибкой.
Filing a formal complaint is not an action which should be taken lightly.
Investigation and response to complaints requires time which coordinators
would prefer to spend doing more constructive activities. Persons who
persist in filing trivial policy complaints may find themselves on the wrong
side of an excessively-annoying complaint. Complaints must be accompanied
with verifiable evidence, generally copies of messages; a simple word-of-
mouth complaint will be dismissed out of hand.
[AB] Подача официальной жалобы - крайняя мера, когда любые другие способы
урегулирования конфликта не увенчались успехом. Посему к данной процедуре
следует подходить с максимальной серьёзностью. Для подачи официальной жалобы
должны, во-первых, иметься веские основания, во-вторых, должны быть строго
соблюдены все формальности, описанные в 9.1. В противном случае жалоба
может быть развёрнута против её подателя.
===
9.7 Right to a Speedy Decision
A coordinator is required to render a final decision and notify the parties
involved within 30 days of the receipt of the complaint or appeal.
[AB] NC обязан принять решение по официальной жалобе в течение 30 дней с
момента её получения. Данное время должно быть употреблено NC на попытку
уже со своей стороны урегулировать конфликт мирным путём. Срыв данного срока
без уважительных причин есть признак неисполнения обязаностей со стороны NC.
Податель официальной жалобы, сроки рассмотрения которой были сорваны, может
передать её на рассмотрение RC, обязательно указав на факт срыва сроков
рассмотрения на сетевом уровне.
===
2.1.12 Excommunication
Systems may also be dropped from the nodelist for cause. See section 9, and
sections 4.3 and 5.2.
[AB] Экскоммуникация - высшая мера воздействия на сисопа, в случае, когда
другие меры не способны привести к разрешению конфликта. В свою очередь,
бессрочная экскоммуникация должна применяться в наиболее вопиющих случаях,
либо при повторяющемся XAB. В остальных случаях в решении координатора
должен быть оговорен срок экскоммуникации.
Восстановление экскоммуницированного узла по истечению срока экскоммуникации
производится только на основании соответствующего заявления его сисопа на имя
координатора. Автоматическое восстановление узла не допускается. В случае,
если экскоммуникация была произведена по мотивам технического нарушения,
координатор перед восстановлением узла вправе убедиться в том, что данное
нарушение было корректным образом устранено.
===
*9.9*
Echomail is an important and powerful force in FidoNet. For the purposes of
Policy Disputes, echomail is simply a different flavor of netmail, and is
therefore covered by Policy.
[YS] Пpи pазбоpе комплейнов эхомейл пpиpавнен к нетмейлy. Hикаких делений
на бэкбонные/технические/флеймовые не пpедyсмотpено. Hадо помнить о
9.1.1, 1.3.5.1 и 1.3.5.2, пpинимая pешения, но общий пpинцип в этом пyнкте
сфоpмyлиpован абсолютно однозначно.
===
Замеченные сокpащения и методы их yстpанения:
(AB) - Alex Barinov (2:5020/715), R50C
(YS) - Yuri Safronov (ex-2:5020/204), exR50C
Выражается глубокая благодарность Yuri Safronov (ex-2:5020/204) за идею и
создание первоначального варианта данного документа.
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
*1.3.5.1*
There are references throughout this policy to "excessively annoying behav-
ior", especially in section 9 (Resolution of Disputes). It is difficult to
define this term, as it is based upon the judgement of the coordinator
structure. Generally speaking, annoying behavior irritates, bothers, or
causes harm to some other person. It is not necessary to break a law to be
annoying.
[YS] - обpатите внимание: квалификация AB и XAB относится к пpеpогативе
*C, пpи этом XAB совеpшенно не обязательно пpотивоpечит законодательствy.
===
*1.3.5.2*
There is a distinction between excessively annoying behavior and (simply)
annoying behavior. For example, there is a learning curve that each new
sysop must climb, both in the technical issues of how to set up the software
and the social issues of how to interact with FidoNet. It is a rare sysop
who, at some point in this journey, does not manage to annoy others. Only
when such behavior persists, after being pointed out to the sysop, does it
becomes excessively annoying. This does not imply that it is not possible to
be excessively annoying without repetition (for example, deliberate falsifi-
cation of mail would likely be excessively annoying on the very first try),
but simply illustrates that a certain amount of tolerance is extended.
[YS] - во втоpом пpедложении yказано, что анноящим может быть не только
технические ошибки, но и наpyшения пpавил общежития в сети. Заметьте также,
что к новеньким следyет относиться мягче, чем к стаpожилам сети. Однокpатное
наpyшение, не повтоpяющееся после yказания на AB может быть пpизнано XAB
только в особых слyчаях.
===
*2.1.2*
In order to understand the meaning of "excessively annoying", it is incumbent
upon all sysops to occasionally re-read FidoNet policy. New sysops must
familiarize themselves with policy before requesting a node number.
[YS] незнание законов не облегчает винy. :) Тем не менее, тyт нет явного
yказания, что сисоп должен _пpочитать_ Полиси. Должен быть знаком. Вот такой
казyс. :)
===
*2.1.3*
The sysop listed in the nodelist entry is responsible for all traffic
entering FidoNet via that system. This includes (but is not limited to)
traffic entered by users, points, and any other networks for which the system
might act as a gateway.
[YS] Пользователи, пойнты, дpyгие сети - их поведение _полностью_ на
совести сисопа. Соответственно сисоп yзла может подавать комплейны от
имени своих пользователей/пойнтов и т.д. Должна быть взаимная
ответственность, не так ли?
===
2.1.6 Private Netmail
2.1.6.1 No Disclosure of in-transit mail
Disclosing or in any way using information contained in private netmail
traffic not addressed to you or written by you is considered annoying
behavior, unless the traffic has been released by the author or the recipient
as a part of a formal policy complaint. This does not apply to echomail
which is by definition a broadcast medium, and where private mail is often
used to keep a sysop-only area restricted.
[AB] Раскрытие транзитного трафика есть раздражающее поведение. Однако,
это ни в коем случае не относится к эхоконференциям, какими бы приватными они
ни были.
2.1.6.2 Private mail addressed to you
The issue of private mail which is addressed to you is more difficult than
the in-transit question treated in the previous section. A common legal
opinion holds that when you receive a message it becomes your property and
you have a legal right to do with it what you wish. Your legal right does
not excuse you from annoying others.
[AB] Hетмейловое письмо является собственностью адресата, однако это не
может служить оправданием некорректности по отношению к другим при
использовании данного права. Hапример, перед публикацией адресованного Вам
нетмейла следует хорошо подумать над возможными последствиями этой публикации.
Если есть сомнения, лучше спросить разрешение на публикацию у автора.
В противном случае, при возникновении конфликта опубликовавшего с автором,
поведение опубликовавшего может быть признано раздражающим на основании
данного пункта (за исключением случаев, специально в нём оговоренных).
Тем не менее, отправителям нетмейла не следует забывать про следующие слова:
In general, sensitive material should not be sent using FidoNet.
===
*3.7.1*
A coordinator is not bound by the practices of predecessor or peers beyond
the scope of this document.
In addition, a new coordinator has the right to review any decision made by
predecessors for compliance with Policy, and take whatever actions may be
necessary to rectify any situations not in compliance.
[YS] текyщий кооpдинатоp имеет пpаво пеpесмотpеть любые pешения
пpедшественника.
===
*4.3.6*
If a node in your network is acting in a sufficiently annoying manner, then
you can take whatever action you deem fit, according to the circumstances of
the case.
[YS] Кооpдинатоp может пpедпpинять любые действия, не дожидаясь
комплейна (!!!использовать с остоpожностью).
[AB] Данный пункт следует применять в случаях явной угрозы нормальному
функционированию сети, либо в случае очевидного технического XAB со стороны
виновного. В остальных случаях настоятельно рекомендуется прибегать к
процедуре, описанной в 9 FPD.
===
*9.1.1*
The FidoNet judicial philosophy can be summed up in two rules:
1) Thou shalt not excessively annoy others.
2) Thou shalt not be too easily annoyed.
[YS] без комментаpиев.
The first step in any dispute between sysops is for the sysops to attempt to
communicate directly, at least by netmail, preferably by voice. Any com-
plaint made that has skipped this most basic communication step will be
rejected.
Failure to follow the procedures herein described (in particular, by skipping
a coordinator, or involving a coordinator not in the appeal chain) is in and
of itself annoying behavior.
[AB] Попытка мирного урегулирования является важнейшим этапом перед подачей
жалобы координатору, а потому должна носить явный характер (обе стороны
конфликта должны понимать, что это именно предкомплейновое общение).
Подача официальной жалобы с пропущенным этапом мирного урегулирование может
быть расценено как раздражающее поведение. Принятие к рассмотрению такой жалобы
со стороны координатора является грубой ошибкой.
Filing a formal complaint is not an action which should be taken lightly.
Investigation and response to complaints requires time which coordinators
would prefer to spend doing more constructive activities. Persons who
persist in filing trivial policy complaints may find themselves on the wrong
side of an excessively-annoying complaint. Complaints must be accompanied
with verifiable evidence, generally copies of messages; a simple word-of-
mouth complaint will be dismissed out of hand.
[AB] Подача официальной жалобы - крайняя мера, когда любые другие способы
урегулирования конфликта не увенчались успехом. Посему к данной процедуре
следует подходить с максимальной серьёзностью. Для подачи официальной жалобы
должны, во-первых, иметься веские основания, во-вторых, должны быть строго
соблюдены все формальности, описанные в 9.1. В противном случае жалоба
может быть развёрнута против её подателя.
===
9.7 Right to a Speedy Decision
A coordinator is required to render a final decision and notify the parties
involved within 30 days of the receipt of the complaint or appeal.
[AB] NC обязан принять решение по официальной жалобе в течение 30 дней с
момента её получения. Данное время должно быть употреблено NC на попытку
уже со своей стороны урегулировать конфликт мирным путём. Срыв данного срока
без уважительных причин есть признак неисполнения обязаностей со стороны NC.
Податель официальной жалобы, сроки рассмотрения которой были сорваны, может
передать её на рассмотрение RC, обязательно указав на факт срыва сроков
рассмотрения на сетевом уровне.
===
2.1.12 Excommunication
Systems may also be dropped from the nodelist for cause. See section 9, and
sections 4.3 and 5.2.
[AB] Экскоммуникация - высшая мера воздействия на сисопа, в случае, когда
другие меры не способны привести к разрешению конфликта. В свою очередь,
бессрочная экскоммуникация должна применяться в наиболее вопиющих случаях,
либо при повторяющемся XAB. В остальных случаях в решении координатора
должен быть оговорен срок экскоммуникации.
Восстановление экскоммуницированного узла по истечению срока экскоммуникации
производится только на основании соответствующего заявления его сисопа на имя
координатора. Автоматическое восстановление узла не допускается. В случае,
если экскоммуникация была произведена по мотивам технического нарушения,
координатор перед восстановлением узла вправе убедиться в том, что данное
нарушение было корректным образом устранено.
===
*9.9*
Echomail is an important and powerful force in FidoNet. For the purposes of
Policy Disputes, echomail is simply a different flavor of netmail, and is
therefore covered by Policy.
[YS] Пpи pазбоpе комплейнов эхомейл пpиpавнен к нетмейлy. Hикаких делений
на бэкбонные/технические/флеймовые не пpедyсмотpено. Hадо помнить о
9.1.1, 1.3.5.1 и 1.3.5.2, пpинимая pешения, но общий пpинцип в этом пyнкте
сфоpмyлиpован абсолютно однозначно.
===
Замеченные сокpащения и методы их yстpанения:
(AB) - Alex Barinov (2:5020/715), R50C
(YS) - Yuri Safronov (ex-2:5020/204), exR50C
Выражается глубокая благодарность Yuri Safronov (ex-2:5020/204) за идею и
создание первоначального варианта данного документа.
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
| #112310 | From: | R50C |
| To: | All | |
| Date: | 19-09-2021 01:01:00 | |
| Subj: | Hетмейл-полносвязка |
Создана IP-полносвязка, предназначенная для снабжения сетей R50 и независимых
узлов нетмейлом. Помимо этой основной функции каждый узел полносвязки готов
предоставить сетям(независимым узлам)-даунлинкам официальные файлэхоконференции
(NODEDIFZ, Z2-DIFF, FIDONEWS, R50ROUTE, R50-LIST). Также каждый из узлов
становится доверенным для передачи сетевых сегментов R50C, как это описано в
R50NC.FAQ. Все узлы полносвязки имеют прямой IP-линк с 2:5020/715, с которого
получают официоз и на который направляют получаемые сетевые сегменты.
>NC настоятельно рекомендуется организовывать роутинг для своих сетей
>через указанные узлы.
>Узлы, помеченные в списке знаком "-" либо перегружены и не берут новых линков,
>или находятся в процессе вывода из полносвязки. Запрашивать у них новые линки
>не нужно.
2:5020/715 - binkp - fido.hubahuba.su
- E-mail - aleksey.v.barinov@gmail.com
- Telegram - @huba715
- Предоставляется нетмейл, официальные файлэхи.
2:5030/731 - binkp - f731.s0t.ru
- E-mail - s0t@s0t.ru
- Предоставляется нетмейл, официальные файлэхи.
2:5080/102 - протокол binkp порт 24554
- протокол binkp порт 443
- (тестируется) протокол ifcico raw
- хост binkd.node.grumbler.org
- E-Mail: stas.grumbler@gmail.com
- E-Mail: g_nospam@grumbler.org
- Jabber: grumbler@grumbler.org
- WWW для заявки, репорта и пр.: http://node.grumbler.org
- принимаю всех желающих
- нетмейл, файлэхи, форвардная подписка на эхи бона R50
- желательно использовать пароль в пакетах .PKT
- отправка к RC сетевого сегмента нодлиста:
- файлы NET*.??? пересылаются, отправителю - отчёт
- "диодная" файлэха R50.NETSEGMENT
- файл-аттачи к RC маршрутизируются
2:6090/1 - binkp, ifcico - fido.mic6090.pp.ru или по binkp.net (2M)
- E-Mail: n6090c@mail.ru
- ICQ:321628167
- Hовые линки: добро пожаловать
(нетмейл, эхи, имеющиеся фэхи).
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
узлов нетмейлом. Помимо этой основной функции каждый узел полносвязки готов
предоставить сетям(независимым узлам)-даунлинкам официальные файлэхоконференции
(NODEDIFZ, Z2-DIFF, FIDONEWS, R50ROUTE, R50-LIST). Также каждый из узлов
становится доверенным для передачи сетевых сегментов R50C, как это описано в
R50NC.FAQ. Все узлы полносвязки имеют прямой IP-линк с 2:5020/715, с которого
получают официоз и на который направляют получаемые сетевые сегменты.
>NC настоятельно рекомендуется организовывать роутинг для своих сетей
>через указанные узлы.
>Узлы, помеченные в списке знаком "-" либо перегружены и не берут новых линков,
>или находятся в процессе вывода из полносвязки. Запрашивать у них новые линки
>не нужно.
2:5020/715 - binkp - fido.hubahuba.su
- E-mail - aleksey.v.barinov@gmail.com
- Telegram - @huba715
- Предоставляется нетмейл, официальные файлэхи.
2:5030/731 - binkp - f731.s0t.ru
- E-mail - s0t@s0t.ru
- Предоставляется нетмейл, официальные файлэхи.
2:5080/102 - протокол binkp порт 24554
- протокол binkp порт 443
- (тестируется) протокол ifcico raw
- хост binkd.node.grumbler.org
- E-Mail: stas.grumbler@gmail.com
- E-Mail: g_nospam@grumbler.org
- Jabber: grumbler@grumbler.org
- WWW для заявки, репорта и пр.: http://node.grumbler.org
- принимаю всех желающих
- нетмейл, файлэхи, форвардная подписка на эхи бона R50
- желательно использовать пароль в пакетах .PKT
- отправка к RC сетевого сегмента нодлиста:
- файлы NET*.??? пересылаются, отправителю - отчёт
- "диодная" файлэха R50.NETSEGMENT
- файл-аттачи к RC маршрутизируются
2:6090/1 - binkp, ifcico - fido.mic6090.pp.ru или по binkp.net (2M)
- E-Mail: n6090c@mail.ru
- ICQ:321628167
- Hовые линки: добро пожаловать
(нетмейл, эхи, имеющиеся фэхи).
---
* Origin: New World BBS (2:5020/715)
SEEN-BY: 5020/715 1042 6090/1
PATH: 5020/715 1042 6090/1
