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