PG>>>> 1. Вместо поддержки FTS-1 и ZMH достаточно поддерживать любой PG>>>> описанный в FTS протокол в заявленное время.
VD>>> Да. VD>>> Не хочешь заодно и роутинг нетмайла узаконить? Хотя бы в виде VD>>> требования наличия связи со своим НЦ?
PG>> Требование аплинка это покрывает. PG>> Связь со своим NC необязательна - может не быть общих протоколов. А по PG>> роутингу через аплинка дойдёт.
VD> Тут уже написали про проверку живости... Либо вменяй это в обязанность НЦ (с возможностью назначать "обзвонщика"), либо VD> - общий протокол.
Узнать, работает ли узел, можно (поддерживаемый протокол в нодлисте должен быть заявлен). Соответственно, механизм удаления из нодлиста дохляков есть. А на регулярной основе обзванивать все узлы - сейчас такй обязанности нет. Если есть желающий (NC или кто другой) - обзванивает. Если нет - узлы удаляются при появлении проблемы, если кто-то жалуется. Так можно и оставить, тут что-то менять, как мне кажется, незачем.
PG>>>> 2. У каждого узла (за PG>>>> исключением узлов, находящихся на вершине иерархии или в PG>>>> полносвязке)
VD>>> А зачем исключения?
PG>> Чтобы в результате получился связный граф (дерево). PG>> Для этого каждый линк должен быть направлен, чтобы было понятно, кто PG>> аплинк, а кто даунлинк. Могут быть, конечно, "паритетные" PG>> (горизонтальные) линки, но они к структуре дерева не относятся. Важно, PG>> чтобы был хотя бы один линк, направленный вверх. Иначе соберутся два PG>> узла в локалке, объявят друг друга аплинками и будут роутить друг PG>> другу почту - фидошники? ;-) А если такое запрещать, тогда нужно PG>> делать исключение для узлов, стоящих на вершине иерархии роутинга (по PG>> аналогии с Интернетом - Tier1).
VD> Зачем запрещать? У нас такие есть до сих пор, оторванные после падения аплинка...
При падении аплинка связность нужно восстанавливать. И это должна быть забота оторванного, а не остальных.
VD> Вот и нужно иметь гарантированную связь с узлом даже после исчезновения его аплинка. VD> Представь что есть целые регионы без связи с внешним миром (не уверен что на самом деле такие есть, но представить VD> регион который ни с кем кроме своих собственных сетей не общается - запросто)...
В таком случае это левонет, а не часть глобальной сети Fidonet. Почта по роутингу должна проходить. Если не проходит - нужно чинить.
VD>>> Аплинк для РЦ - хаб сети, к котрой он принадлежит (если VD>>> независимый - то тоже есть аплинк), для НЦ - очевидно, для узла VD>>> полносвязки - он же член какой-то сети, значит и там есть аплинк, VD>>> минимум НЦ этой сети...
PG>> Для RC - хаб сети, для хаба - NC, для NC - RC? PG>> Так почта будет кругами ходить. :)
VD> Не-а, для НЦ - не РЦ, а лонглинк их сети! РЦ не нанимался доставлять почту сетям! :-)
PG>>>> Можно ещё добавить ссылку на региональное эхополиси.
VD>>> Оно и так упомянуто в Уставе, зачем дублировать?
PG>> Эхополиси? Вроде, не упомянуто. PG>> А уж тем более, эхополиси R50. :) PG>> Ссылка на эхопол сделает его более легитимным. Сейчас при нарушении PG>> эхопола можно фактически лишь отключить от эх, координатор не может PG>> предпринимать какие-либо действия на основании нарушения эхопола, т.к. PG>> сисоп не обязан его соблюдать, хотя фактически предпринимал. Когда-то PG>> на эту тему жаркие дискуссии были.
VD> И опять же тебе уже указали на регионы 45 и 46. Нет уж, Эхополиси пусть будет на основании 9.9 Устава!
Тут момент скользкий в том, что регионы 45 и 46 являются потребителями эхобона R50 (и даже его участниками). А нынешний эхопол - это фактически правила существования эхобона, права и обязанности его участников и тех, кто им пользуется. В данный момент получается, что регионы 45 и 46 эхобоном пользуются, но его правила соблюдать не обязаны, модератор или эхокоординатор или сисоп эхохаба не может потребовать от сисопа R46 выполнения каких-то правил этого эхопола. Неувязочка.
Впрочем, это действительно можно решать отдельно, без привязки к local policy.