PG>> Никто ведь не предлагает создавать сеть из одного узла. PG>> Речь о расформировании или сохранении сети из одного узла.
VD> А пункта о "расформировании сети" в Уставе совсем нет (да, недоработка однако), так что придётся приметь тот в котором VD> описано что такое "сеть". И тут явно сказано - объединение НЕСКОЛЬКИХ узлов.
Нет. Про несколько узлов сказано в "2.4 How to Form a Network". А о том, что такое сеть, сказано в "1.2.3 Networks and Network Coordinators", и там сказано просто, что "A network is a collection of nodes in a local geographic area, usually defined by an area of convenient telephone calling". На мой взгляд, сеть из одного узла не противоречит определению из 1.2.3, хотя 2.4 говорит, что для создания сети одного узла мало.
PG>> Можно сделать так: PG>> один оставшийся узел автоматически становится NC своей сети, при этом PG>> он делегирует все функции, кроме разбора конфликтов, RC. То есть, PG>> причём почты на /0, ведение сетевого сегмента и пр. для этой сети PG>> осуществляет RC.
VD> Делегирование согласно 1.2.3.1 возможно только члену своей сети, так что проделегировать "на сторону" не получается.
Чтобы было проще, приведу тут названный тобой пункт полиси, он короткий:
===== 1.2.3.1 Network Routing Hubs
Network Routing Hubs exist only in some networks. They may be appointed by the Network Coordinator, in order to assist in the management of a large net- work. The exact duties and procedures are a matter for the Network Coordina- tor and the hubs to arrange, and will not be discussed here, except that a network coordinator cannot delegate responsibility to mediate disputes. =====
Где здесь сказано, что делегирование обязанностей координатора возможно только члену своей сети?
PG>> В этом случае всё хорошо с членством в управляемой структуре и PG>> географическим делением? ;-)
VD> Противоречие с 1.2.3.1 ...
1.2.3.1 говорит только о том, что можно и что нельзя делегировать хабам. Хабы, естественно, должны быть участниками этой же сети. Делегировать обязанности не хабам никто не запрещает. Например, R46C (и нынешний, и прошлый, и позапрошлый) делегировал мне сборку нодлистового сегмента R46. Вард в курсе (естественно - он ведь от меня этот сегмент принимает) и нарушением Устава это не считает.
PG>>>> === PG>>>> It is permissible to have greater capability (for example, to PG>>>> support additional protocols or extended mail hours), but the PG>>>> minimum requirement is FTS-0001 capability during this one hour PG>>>> of the day. PG>>>> === [...] VD>>> А серьёзно - в 2.1.8 сказано "FTS-0001 at this writing" VD>>> (предыдущая строчка от процитированной тобой), так что - заранее VD>>> заложено что FTS1 был нужен только в 84м году.
PG>> Как ты считаешь, в каком году поддержка FTS-1 перестала быть PG>> минимально необходимым требованием для узла?
VD> Судя по FTS-0006 - 30 nov 1991. Это первый (по моему списку) стандарт, расширяющий протокольную часть FTS-0001.
Ух. Я категорически не согласен с такой трактовкой. И мне очень удивительно, что такое говорит координатор крупнейшего в фидо региона. Уверен, члены FTSC, принимавшие стандарт FTS-0006, не имели ввиду, что с момента его принятия соблюдение FTS-1 стало необязательно. Как минимум, потому что это нарушало бы связность, перестала бы работать доставка почты в ZMH (один поддерживает только FTS-1, другой только FTS-6, и директная почта между ними не проходит). Сколь-нибудь весомых причин разрушать связность тогда не было (они появились гораздо позже, с распространением IP-only nodes).
В полиси чётко написано про поддержку FTS-1 как минимально необходимого, а остальные протоколы могут поддерживаться опционально. То есть, если два узла поддерживают, скажем, EMSI, они могут связаться через EMSI, но если общих расширений не нашлось, всегда должна быть возможность передать почту по FTS-1 в ZMH. Я не знаю, как можно было написать эту мысль ещё более чётко, чтобы она таки не допускала вольных трактовок типа твоей (что достаточно поддерживать один любой из протоколов, описанных в FTS).
PG>> И есть ли какой-то обязательный протокол, общий для всех узлов, сейчас? Если да, то какой?
VD> Нет и быть не может. Такого требования в Уставе нет.
"minimum requirement is FTS-0001 capability". Сейчас это требование устава не выполняется, да. Но долгое время оно таки соблюдалось.
[...] PG>> В полиси сказано чётко и однозначно: "Echomail should not be PG>> transferred during ZMH". Передавая echomail, мы нарушаем букву полиси. PG>> Но не считаем, что это плохо, потому что понимаем, что передача PG>> echomail в ZMH нынче никому не мешает.
VD> Не хочешь принимать эхи в ZMH - ставь флаг и не принимай, кто мешает? А вот если будет подана жалоба - будем VD> разбираться, кто чего собственно хотел...
О! Я именно об этом и толкую: можно нарушать устав в тех случаях, когда это никому не мешает. Как, например, с передачей echomail в ZMH или с сетью из одного узла. Правда, с сетью из одного узла - тут даже не очень понятно, является ли это нарушением полиси или нет.
[...] PG>> На Устав нужно опираться в спорных случаях. Когда какое-то действие PG>> может быть полезно для одних сисопов и неудобно для других - нужно PG>> делать так, как написано в Уставе (да и то, в разумных пределах: PG>> например, если IP-only nodes удобны тысяче, но вызывают некоторое PG>> неудобства у десяти, их нужно разрешать, даже при том, что формально PG>> они противоречат Уставу). Но если какое-то действие удобно некоторым PG>> сисопам, и не доставляет неудобств вообще никому, очень странно его PG>> отвергать на основании Устава. Это бюрократизм и буквоедство.
VD> Противоречия Уставу в IP-only нодах нет, как только появился стандарт на них - они стали разрешёнными. А до того - да, VD> были запрещены, вспомни "войну" за их авторизацию, даже регион 55 был под это дело открыт, как "площадка для VD> экспериментов"... И сколько времени они числились как PVT - именно из-за противоречия Уставу, пока оно не было решено.
Пока были сисопы, которые высказывали неудовольствие наличием IP-only узлов - да, была "война". Большинство хотело проигнорировать требование Устава, меньшинство противилось, поэтому искали всяческие компромиссные решения. Когда меньшинства не осталось - необходимость в компромиссах вроде R55 отпала, ION стали обычными узлами в своих сетях. И принятие стандарта FTS-1026 на это практически никак не повлияло.