Articles

• Continuing the Elist thoughts
• Echolist, And How It's Done in Zone 2 Region 24

Continuing the Elist thoughts
By Frank Vest
1:124/6308

Last week I wrote a small article about thoughts on the Elist in Zone1. It seems that Zone1 isn't the only Zone where an Elist is in place. I'm going to continue these thoughts in hopes of merging them and see what happens.

Zone1 has two echomail distributors. The Z1B (Zone 1 Backbone) and the NAB (North American Backbone). The main difference I see between the two backbones is that one purges echos based on traffic and the Elisting and the other uses the Elist only. I'm not going to argue the pros and cons of purging by traffic. The common factor here is that both use the Elist in some way.

1. The Elist is the basis for what echos are carried in Zone1.
   1. The Elist shows what Network distributes a particular echo.
      1. If the echo is listed for Fidonet distribution, it's a Fidonet echo?
      2. If an echo is listed as being from another Network, it is an "OtherNet" echo?
   2. If an echo is listed in one Network and another Network wishes to distribute that echo, an agreement for gating the echo between the Networks must be worked out?

So, it seems that the Elist is a tool to determine what echos are available and from what Network. If an echo is Elisted as an "Othernet" echo, it can not be distributed in Fidonet Zone1 and visa versa??

Let's look at this.

Example: I start an echo with a tag of BACK_TO_BASICS. I Elist it as a Fidonet echo for distribution. An "Othernet" decides to start an echo with the same tag. Does the fact that I have it Elisted as a Fidonet echo stop them? I doubt it. Would it stop me from distributing the echo if it was Elisted as an "Othernet" echo. Not if I wanted to distribute it. Of course, the echo wouldn't be Elisted as my echo.

The thought here is multi-part.

1. Is the Elist a tool or a rule?
   1. If a tool, then all Echo Tags must be listed or listable?
      1. The fact that one Network has an echo tag listed could not because for refusing to list the same tag from another network?
         1. There could be 2+ listings for each echo tag. Each listing from a different Network?
   2. If a rule, then only Fidonet tags are allowed?
      1. If other tags are allowed, Fidonet tags take priority?
         1. If a tag is listed from an "Othernet", Fidonet could list the same tag and "bump" the "Othernet" tag off the Elist?

Just some thoughts.

Regards,

Frank

Echolist, And How It's Done
in Zone 2 Region 24
By Dennis Alexis Valin Dittrich

As Frank Vest wrote his thoughts about the Zone 1 elist and because there is some dispute about its sense and use I felt the urge to comment on his article by explaining how we in Region 24 of Zone 2 coordinate our echomail conferences.

First of all, there is some kind of elist. And, there is a collection of nodes who act as regional backbone. These nodes are obliged to carry all echomail conferences listed in our 'elist'. Most of these nodes exchange mail nearly instantaneously using binkd, i.e. fido over IP. But this is not what I want to write about.

How is an echomail conference listed in the Region 24 elist?

The Grandfather mechanism.
Per definition all backbone conferences are listed in the Region 24 elist. In order to be a backbone conference there has to be a rules file for this echo conference sent to the REC which means most times that there is a moderator, too. Some times the participants of a conference voted against moderatorship thus there are unmoderated conferences on the backbone as well. In the corresponding rules file the status unmoderated is then recorded. The REC protects these conferences from hijacking. Only a majority vote of the participants can install a new moderator and thus change the status of this conference.

The New Born mechanism.
Even now in times of declining participation in fidonet there is some times need for a new conference. There are essentially two ways to get a new conference into the elist. Get it distributed by your own and as soon as it has traffic and is available in a larger area, i.e. several nets, it is listed in the elist. For infomation purposes you can ask the REC to list this conference in a list for 'additional echo conferences which are available in the region but not neccessarily on the backbone'. The second way to get your conference into the region elist and thus onto the backbone is to just find some nodes (or even only points) who want this new conference. If there are at least 6 nodes from at least 3 different nets your conference gets listed in the region elist and thus immediately on the backbone.

What purpose does the region echo conference list have?
The Region 24 echo conference list acts as centrally coordinated forward list for the whole region. If a conference is listed in this list you can be sure to get it at your local uplink. Second, there is an indicator for the read/write permission showing whether there are restrictions or not. Third, name and AKA of the moderator or the status unmoderated are recorded. Forth, there will be (at least some) traffic since the REC and the backbone coordinator monitor the traffic and drop conferences from the region elist if they lack traffic for a specific amount of time. Thus, you always know what topics are covered by existing, active conferences in our region.

When and how is a conferences droped from the region elist?
If a conference lacks traffic for more than 40 days the moderator will be notified that her conference is soon due for deletion. This fact will be announced in a special conference as well. Thus, everyone can veto the deletion process. Either (s)he just writes a message in the conference and thus produces traffic or asks for special protection because this conference is known for sporadic traffic due to some seasonal effects. Up to now this special treatment was always granted if asked for. If a conference lacks traffic for more than 70 days it will be droped from the region elist and listed in the region 'kill list' instead. Conferences listed in this kill list are automatically deleted from all backbone systems.

The abovementioned lists are weekly generated by the REC using a perl script, the rules file archive, the traffic data base which consists of the latest traffic statistics of all backbone nodes and some control files to cover special cases. These lists are then hatched to a region wide distributed file echo. Changes in these lists are announced to the abovementioned special echo conference.

As a last remark, the world wide backbone (WWB) forward list for region 24 is derived from the region elist and there are several forward lists from other regions of Zone 2, too. Michiel, there are elists in Zone 2...