@MSGID: 2:5075/21@fidonet 7a40db61
@REPLY: 2:5001/100@fidonet 6a94733d
@CHRS: CP850 2
@TZUTC: 0200
@PID: SeenBy macOS MVP
@TID: SeenBy Tosser 0.1

Hello Dmitry Protasoff!

Hello Dmitry!

Thank you - and actually, I mostly agree with your diagnosis.

 If these statistics are representative, then yes: stale and
completely dead entries in the nodelist are a much bigger operational problem
than DNS failures.

But I think we`ve just changed the subject. :)

What we were discussing was a very small and rather deterministic change:

    hostname
    optional static IP

with equally boring semantics:

    try hostname
    if it fails -> try static IP, if present

 That`s a small feature, cheap to implement, backward-compatible, and
it addresses one specific failure mode.

 What you are proposing now is much more interesting - but also a
completely different class of problem.

DP> What I see as a potential project - is to create a nodelist and if
DP> someone wants - a DNS service which will contain real, proven
DP> information. Only nodes which could be reached! Even potentially.

Now *this* makes my architect alarm start making noises. :)

 Because "real, proven information" and "could be reached" sound
simple until we try to specify them.

What exactly constitutes proof that a node is dead?

One failed TCP connection?
Ten?
For an hour?
A day?
A month?

From one probe?
From several networks?
Several countries/ASes?

What about a node which is reachable only at certain times?

What about:

    DNS fails, IP works
    DNS works, TCP fails
    IPv4 works, IPv6 fails
    IPv6 works, IPv4 fails
    one probe reaches it, another doesn`t
    connection succeeds but there is no valid BinkP response
  what about sysops not involved in mail tranfer? For example, I
just returned, so Fido was working without me somehow, I don`t have
intetion on giving a point to anyone (and I don`t see a queue for the
either), so I will not respond. How about that? 

 And most importantly: who is allowed to turn an observation made by
an automated monitoring system into authoritative information about
FidoNet topology?

 That`s not an argument against the idea. Quite the opposite - I
think it`s a much more interesting and probably much more useful project.

 But compared to adding one optional field, this has considerably
more architectural uncertainty. We have suddenly gone from:

    "store another endpoint"

to:

    "design a distributed node health/validation system and define
     how its observations affect authoritative network state."

Those are rather different-sized jobs. :)

And curiously, the first proposal doesn`t interfere with the second one at all.

It actually gives the second one a useful tool.

Suppose the nodelist says:

    hostname = node.example.org
    static_ip = 192.0.2.42

Your validator tries the hostname and fails.

Without the second endpoint, all it knows is:

    node unreachable through hostname

With the optional static IP it can independently try:

    192.0.2.42

and now it can distinguish at least two very different conditions:

    hostname fails + IP fails
        -> probably an endpoint/node/connectivity problem

    hostname fails + IP works
        -> node is alive, DNS path is broken

That`s rather valuable information for exactly the project you`re proposing.

DP> So the proposed solution (IP + hostname) could potentially save only
DP> one SysOp.

Yes. Based on your ten-month sample, apparently one SysOp.

 That`s useful information and it certainly changes the *priority* I
would assign to the feature.

But it doesn`t really change its cost or architecture.

 We are talking about an optional field in a format where a line
may be up to 1024 characters, plus a trivial fallback rule. Nodes
without static addresses don`t use it. Existing software can ignore it.
Nothing needs a new central service.

So I wouldn`t stop fixing the Titanic`s hull in order to tune the piano. :)

 But if the piano tuner needs thirty seconds and his work doesn`t
interfere with the people fixing the hull, I`m not sure we need to throw
his wrench overboard either.

And your proposal about cleaning the nodelist is definitely the hull problem.

 I`d be much more interested now in discussing how to define "dead
node" reliably enough that the resulting information can be trusted.

Because I think that is where the genuinely difficult architecture begins.

 And, conveniently, having more than one independently testable
endpoint in the authoritative nodelist would make that job easier, not
harder.


--- SeenBy 0.1
 * Origin: SeenBy macOS MVP (2:5075/21@fidonet)
SEEN-BY: 221/0 280/464 5003 5555 301/1 310/31
335/364 341/66 5001/100 5015/46
SEEN-BY: 5019/40 5020/715 1042 1146 4441 5030/1081
5051/44 5053/58 5075/21 35
@PATH: 5075/21 35 280/5555 5053/58 5020/715