PG> Хм, а ведь можно закрепить это правило: "У каждого узла (за PG> исключением "корневых" узлов для определённого уровня иерархии или PG> входящих в netmail-полносвязку) должен быть как минимум один аплинк, с PG> которым есть договорённость о доставке почты любому другому узлу PG> fidonet, и связь с которым защищена паролем. Таким образом, почта при PG> отправке по роутингу идёт сначала по пути от даунлинков к аплинкам, а PG> потом, напротив, от аплинков к даунлинкам, пока не достингет PG> получателя". Это, с одной стороны, будет описывать реальное положение PG> вещей, а с другой - логичным образом уберёт требование общего PG> протокола для всех узлов - просто каждый узел должен найти себе PG> аплинка. В роли аплинка не обязательно должен быть координатор PG> следующего уровня, как я предлагал раньше. Согласен, достаточно описать что проблемы роутинга - это проблемы узла (даунлинка). Поиск аплинка- проблема каждого. Только, может быть, надо как-то более определенно написать кто считается аплинком, может быть даже со ссылкой на другой документ. Схема роутинга Node<->[Hub<->]<->NC<->RC<->ZC с различными оптимизациями хождения (в т.ч. и не известными на данный момент) - устраивает. Роутинг на региональные pvt - ручками на аплинка, с которыми договорятся эти pvt, в т.ч. через RC (RC не обязан в этой редакции. В другой пусть будет обязан. Если будет напрягать трафик - пусть позаботится об его оптимизации хождения, чтобы, например, он бегал NC<->NC/NC<->Uplink) Любители исключительно экзотических технологий пусть кучкуются под хабами, у которых есть такая же технология. Если у хаба и хоста нет такой технологии - то проблема отправки от узла писем - его проблема, пусть представит что в его сети/регионе никого нет ( всех запретили :-) ) и "звонит" хоть в другую страну, даже с переходом в другой регион. Его положение от запрета других технологий однозначно не ухудшается. Получение почты - по роутингу, или, если позволяют технологии отправляющего - директом. При этом технологии в полиси можно спокойно не описывать.
Мое мнение по сетям из одного узла: однозначно оставлять. Выдать оставшемуся узлу AKA из другой сети этого же региона для сохранения кол-ва уровней аппеляции, может быть даже новую сеть создать :-) с назначением ее NC кого-либо из NC существущих других нормальных сетей этого же региона. Комплейны на узлы из вырожденных сетей подавать нормальному NC, в чьей сети первым былы выданы AKA. По результатам рассмотрений комплейнов NC, присматривающие за вырожденными сетями из одного узла - информируют RC о рассмотрении - для выноса и вырожденной сети из нодлиста в случае, если NC примет решение об экскомуникации. Почему оставлять - потому что переезда узлы могут просто не пережить. Плюс чем черт не шутит, если появится еще узел - назад переезжать? Если нет, то если появится второй, третий, десятый... - всех в чужую сеть?
ZHM отменить (требования обязательной поддержки FTS-0001-совсем, время ответа - по флагам), процедуру изменения полиси упростить, pvt - склонять к eon-ам :-)
И что-то я запутался, о чем еще речь шла? Было бы неплохо вести какой-нибудь список вопросов, с разбивкой по содержимому темы. Путеводитель, так сказать...
Alexey --- GoldED+/W32 1.1.5-021109 * Origin: Путь наверх (2:455/19.1)
