Text 31247, 140 rader
Skriven 2009-04-13 00:27:45 av FidoNews Robot (2:2/2.0)
Ärende: FidoNews 26:15 [02/05]: General Articles
================================================
=================================================================
                        GENERAL ARTICLES
=================================================================

            Trimming the FidoNet hierarchy
            By FTSC chairman, Michiel van der Vlist
            2:2/40

Summary
-------

This is a plea to reduce the FidoNet hierarchy by at least one level.
Fidonet has shrunk from some 36000 listed nodes in the second half of
the previous decade to some 4500 listed node per nodelist.100 of last
Friday. It is anyone's guess how much of these are dead wood, but
suspicion is that it is considerable. This is a plea to improve the
situation by reducing the number of hierarchical levels.

Why reduce the number of levels?
--------------------------------

Soon another region will disappear from the nodelist. Possibly even by
next Friday. Region 31, Austria. It has shrunk way below critical mass
and so the decision to not continue as a region of its own is a wise
decision. Keeping up appearances is not compatible with "ensuring the
smooth operation of the network", which is the job of the
coordinators.

This incident once again raises the question of whether FidoNet really
needs four levels of hierarchy. At ground level, there are the nodes.
Above that the net, then the regions and at the top the zones.
Technically there is a fifth level at the bottom: the points. Now that
FidoNet has shrunk to a fraction of what it ever was, do we need all
those levels? Did we ever need them? Soon after the creation of
FidoNet, nets were created for two reasons; One: it became too big for
one person to maintain the nodelist. Two: to create a default routing.
I think there is no question that nets are still useful. But do we
really need two levels of hierarchy above that? I doubt it. There is
no denying that the nodelist contains a lot of dead wood and that is a
sign that the coordination hierarchy is not functioning properly, it
seems to be unable to keep the nodelist clean from dead wood. It might
function better if the hierarchy were trimmed down. Too many cooks
spoil the broth.

What level to do away with?
---------------------------

Perhaps from a political point of view, it might be the best to do
away with the regions. Coming down from the top, it appears that It is
at the region level where things start to go wrong. RC's fall asleep
or just disappear and are not replaced with the result that the
segment is frozen and degrades into dead wood. However, this article
is not written from the political point of view, it is wrtten from a
technical point of view and from the technival point of view it would
be a good idea do to away with the zones.

Why do away with zones?
-----------------------

For starers: we never needed them in the first place and the technical
implementation is shaky at best. When FidoNet went from 1D to 2D, all
the software was upgraded. No 1D software survived after the
introduction of nets. But when zones were introduced, Fidonet took a
halfhearted turn. A system of zonegates was introduced so that nodes
could continue to use 2D only software. Also they could operate with a
nodelist of their own zone only. By now 2D only software (stone age
software) has faded out and disk space is no longer an issue, so that
"everyone" uses the full nodelist, but remnants of the 2D system still
remain. PATH and SEEN-BY in echomail are still 2D. And because nets
numbers are not unique across zones, systems acting as zonegates used
to strip SEEN+BYs in interzone echomail. This causes dupe prevention
not to work across zones. As long as only ONE zonegate is used to gate
echomail from one zone to another this is no problem, but that system
has long ago been abandoned. Pro posals to make PATH and SEEN-BY zone
aware were filed (FSC-0052 and others) but never implemented. As a
result Circular Path Protection does not work across zones and as it
is unlikely that FSC-0052 will ever be implemented, the only way to
ever make it work is to dispense with the zones or at lest with the
interzone duplicates.

From the non-technical POV, zones have brought us nothing but grief.
They have divided Fidonet into social islands for which their was
never a technical need. Add to that, that already one zone (zone 6)
was disbanded because there was no one left to administer it, and that
two other zones are unlikely to pass scrutiny for critical mass, there
is every reason to consider continuing the process of reducing the
number of zones with the ultimate goal of doing away with them
altogether.

How to go about it?
------------------

From the technical point of view there is one problem: Nets are not
unique across zones. So when doing away with zones, we first have to
deal with the rpoblem of duplicate nets.

For starters there is the recommendation that RC's when creating new
nets they DO NOT ASSIGN NET NUMBERS THAT ARE IN USE IN ANOTHER ZONE.
For ZC's the recommendation that when RC's go against this
recommendation, they do not approve it.

How about existing nets? although the majority of them has
disappeared, there are still a few duplicate nets. All in Z1 and Z2. I
counted seven. They are:

220
249
250
343
345
372
382
It seems that the problem has become manageable. Rc's may want to take
a closer look. Some of these nets could perhaps be easily dealt with.
Perhaps some of them do not even exist any more. Others consist of
only one or two sysops that could be transferred to a neighbour net.
To give just one example: net 2:220. As host it lists someone who is
already listed as host in another net. There is just one leaf node and
that is a private node. If that net isn't dead, it is in coma and
should have been disbanded and have the remaining node transferred to
a neighbouring net if it is still operational. I leave it to the
reader to find other examples examples of dead or near dead nets in
the duplicate list.


Conclusion
----------

I realise that doing away with the zones will be asking a lot. It will
demand lots of diplomacy from the ZCs to come to an arrangement, if
only about who will be the new top level coordinator. Nevertheless I
feel that reducing the coordinator overhead will benefit the network
in the long run and doing away with the zones will be a good start.



-----------------------------------------------------------------

--- Azure/NewsPrep 3.0
 * Origin: Home of the Fidonews (2:2/2.0)