Hello Alexey,

On Tuesday October 07 2014 12:00, you wrote to me:

 AV> The "*" as the hostname and root-domain parameter are primarily
 AV> intended for single connections (like sending direct netmail when
 AV> routing doesn't work).

I prefer the other way around. I send direct when possible and route when
direct is not possible.

 AV> Permanent links should (in the meaning from
 AV> FTA-1006: do that, unless you have really strong reasons for not
 AV> doing) be explicitly configured

That is how I have done it. My permanent links - the one I have a secure
connection with - are in nodes.cfg, an include file for binkd.cfg.

 AV> to use all known information: all hostnames from nodelist and,
 AV> possibly,  literal IP addresses (just in case of DNS failure or domain
 AV> expiration).

I prefer to not use literal IP addresses and use only host names instead. DNS
failures are rare and many IP adresses are dynamic anyway. A much more frequent
event is that a node is temporary off-line.  If one enters both the host name
and the IP address, binkd will just needlessly try both if the node is
off-line.

 AV> For example, your node is listed in my binkd.links as:

 AV> node 2:280/5555 fido.vlist.eu;2001:7b8:2ff:3a9::2;83.82.233.201
 AV> [password]

 AV> That means, my node will try to resolve fido.vlist.eu first (as this
 AV> hostname appears in the nodelist), but if that fails, it will try both
 AV> IPv6 and IPv4 addresses

If fido.vlist.eu fails, ninetynine times out of hundred the IP address will
fail as well. The DNS service for vlist.eu is much more reliable then my own
system. Tha added value is small.

 AV>  (once known to be static).

Not really. It s a dynamic address, but it only changes when the MAC address of
my router changes.

 MvdV>>>> The nodelist is the primary source of Fdionet connection
 MvdV>>>> information. All the information to make a connection MUST
 MvdV>>>> be present in the nodelist. DNS distributed nodelists as
 MvdV>>>> documenetd in FTS-5004 are an /additional/ service, not a
 MvdV>>>> replacement for the nodelist.
 ml>>> agreed on both accounts...
 MV>> So a protocol flag without an associated host name or IP number
 MV>> in the nodelist is an error.

 AV> As FTSC, we should point ZCs at this error...

Yes, we should. Unfortunately not all *Cs are equally responsive...

 MV>> You know, you don't HAVE to list all your connections in the
 MV>> nodelist. It is not a MUST. All that is required is that you list
 MV>> /a/ connection method that will let others connect to you. This
 MV>> is an amateur network. No one will hold it against you if you can
 MV>> not offer 100% connectivity.

 AV> Hmmm... I'm about to reach 99.995% - less than 2 months left. And
 AV> reaching 99.999 is on my agenda :-) Well, as a HL/HA system architect
 AV> I have both knowledge and ability for that (main server is rented,
 AV> backup server is at my home).

Good for you. ;-)

 MV>> It is OK to only publish the more obscure connectiom methods to a
 MV>> limited number of selected parties.

 AV> Once I tried FTN connection over binkp over tcp over AX.25 over UHF
 AV> radio. However, that's not the connection method I'd like to publish
 AV> in the nodelist.

I have experimented with transfering data over HAM radio. They were interesting
experiments. It is not suitable for Fidonet though. There are legal problems.
Plus that there is no place for the frequency in the nodelist. ;-)

 MV>> In fact here this was not unusual in the POTS age. Several
 MV>> nodes/BBSs here in The Netherlands had two telephone lines. But
 MV>> only one of the numbers was published in the nodelist. The other
 MV>> number was only given to preferred users/points. The second line
 MV>> did not need to observe ZMH of course. So users could continuue
 MV>> to be served all night.

 AV> Another option was to use these hidden lines for outgoing connections.

Especially if you can get your boss to pay the bill. ;-)


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20130111