Articles

• North American Backbone Echo Changes [Sep-Oct]
• Feed Cuts vs. Message Filtering
• Fidonet over IP, Part 4 of 4

North American Backbone
Echo Changes [Sep-Oct]
by Lisa Gronke, 1:105/9
lisa@psg.com

Summary of backbone echo changes during Sep Oct.

Brought to you courtesy of (unix) diff.

Note: The North American Backbone has changed the format of its areafix compatible lists. Backbone.na now lists all NAB backbone echos. The backbone.no list has been discontinued. Echos that are in jeopardy because of low traffic or an expired Elist entry are listed in Section 3 of the weekly backstat.na.

diff (backbone.na + .no) 05-Jul-98 backbone.na 06-Sep-98 [edited].

Added to the backbone

> BAD_COPS            What ya gonna do when they come for you
> ENGLISH_TUTOR       English Tutoring for the English Language
> FEED_CUT            Inform users sysops and *EC's of echo feed cuts
> INET_NODELIST       FidoNet Nodelisting of Internet Sites
> INJOY               The InJoy Internet Dialer
> LE/SECURITY         Law Enforcement/Security Issues  Concerns
> LINUX_BBS           Linux BBSing
> MOTOR_SPORTS_RESULTS Various Motor Sports Results
> NT4_UK              Discussion of Microsoft's NT4 Workstation/Server
> OKLAHOMA            GENERAL CHAT FOR OKLAHOMA
> PENNSYLVANIA        GENERAL CHAT FOR PENNSYLVANIA
> TORNADO.SUPPORT     Tornado BBS Software Support Echo

Removed from the backbone or quasi-backbone

< ANEWS               (not in EchoList since  5/1/98)
< ANIME               (not in EchoList since  6/1/98)
< ER                  (low traffic since  4/1/98)
< FIPS                (low traffic since  4/1/98)
< IRS_HELP            (low traffic since  4/1/98)
< PCBPPL              (low traffic since  4/1/98)
< RAILFANS            (not in EchoList since  6/1/98)
< RECOVERY            (not in EchoList since  5/1/98)

• There are 720 echos in backbone.na [01-Nov-98] (up 111)
• There are 0 echos in backbone.no (down 107)
• for a total of 720 backbone echos (up 4)

Feed Cuts vs. Message Filtering
by Jerry Schwartz, 1:142/928

In last week's FidoNews, Gordon Lewicky made an impassioned statement against feed cuts and in favor of "culling" offensive posters' messages from echos. Unfortunately, I think he's heading down a wrong and very dangerous path.

If a nuisance poster is denied the ability to post in an echo by a sysop, his or her messages simply don't exist -- anywhere. However, the proposed culling action would by definition happen when the sysop does not agree to restrict access to the echo; so the culling would have to occur at one or more other systems.

At the very least, this presumes that suitable software is universally available; but there is a worse problem. Once specific messages are being filtered out on certain systems (and possibly not on other systems), it will quickly become obvious because there will be replies and side comments which won't be filtered out. We have enough problems tracking down broken links without introducing the appearance of broken links deliberately.

A more insidious problem is that the widespread, sanctioned use of such techniques would provide cover for unsanctioned use. "My, oh my, did I accidentally put your name in my filter? I'll fix that first thing a week from Tuesday."

I don't think any of us want to see that.

Fidonet over IP,
Part 4 of 4:

Policy aspects about IP-Nodes

Copyright 1998 by Lothar Behet

Part 1 and 2 in FidoNews issue contained a definition of Fidonet-over-IP and the available software. Part 3 was dedicated to possibilities of and actual proposals for integration of ip-nodes

1. Basics (again :)

Let us take a look on requirements for conventional nodes at first (excerpts from the Fidonet policy 4.07):

1.3.2 Geography

Each level of FidoNet is geographically contained by the level immediately above it. A given geographic location is covered by one zone and one region within that zone, and is either in one network or not in a network. There are never two zones, two regions, or two networks which cover the same geographic area.

1.3.3 Zone Mail Hour

Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are required to be able to accept netmail. Each Fidonet zone defines a ZMH and publishes the time of its ZMH to all other Fidonet zones. See sections 2.1.8 and 10.2.

2.1.8 Exclusivity of Zone Mail Hour

mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at this writing). It is permissible to have greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTS-0001 capability during this one hour of the day.

2.1.9 Private Nodes

The rare exception to ZMH compliance is private nodes. Persons requesting private nodes should be supported as points if possible. A private listing is justified when the system must interface with many others, such as an echomail distributor. In these cases, the exact manner and timing of mail delivery is arranged between the private node and other systems. Such an agreement between a private system and a hub is not binding on any replacement for that hub. A private node must be a part of a network (they cannot be independents in the region.)

Private listings impact each member of FidoNet, since they take up space in everyone's nodelist. Private listings which are for the convenience of one sysop (at the expense of every other sysop in FidoNet) are a luxury which is no longer possible. Non-essential redundant listings (more than one listing for the same telephone number, except as mandated by FTSC standards) also fall into this category. Sysops requesting private or redundant listings must justify them with a statement explaining how they benefit the local net or FidoNet as a whole. The Network Coordinator or Regional Coordinator may review this statement at any time and listings which are not justified will be removed.

10.2 Timing of Zone Mail Hour

Zone Mail Hour is observed each day, including weekends and holidays. The time is based upon Universal Coordinated Time (UTC), also known as Greenwich Mean time (GMT). In areas which observe Daylight Savings Time during part of the year, the local time of zone mail hour will change because FidoNet does not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set for each zone by the Zone Coordinator.

In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC. In each of the time zones, this is:

Eastern Standard Time    4 AM to 5 AM
Central Standard Time    3 AM to 4 AM
Mountain Standard Time   2 AM to 3 AM
Pacific Standard Time    1 AM to 2 AM
Hawaii Standard Time    11 PM to Midnight

In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC.

In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC. In each of the time Zones involved this is:

GMT +12 Zone        6:00 AM to 7:00 AM
(New Zealand)
GMT +10 Zone        4:00 AM to 5:00 AM
(East Australia)
(Papua New Guinea)
(Micronesia)
GMT +9.5 Zone       3:30 AM to 4:30 AM
(Central Australia)
GMT +9 Zone         3:00 AM to 4:00 AM
(Japan)
(Korea)
(Eastern Indonesia)
GMT +8 Zone         2:00 AM to 3:00 AM
(Hong Kong)
(Taiwan)
(Central Indonesia)
(Philippines)
(Western Australia)
GMT +7 Zone         1:00 AM to 2:00 AM
(Malaysia)
(Singapore)
(Thailand)
(Western Indonesia)

Each Coordinator (i.e. RC, ZC) is responsible for his part the nodelist data, which at last is the "phonebook" of Fidonet. It contains the required data for a possible direct session between any two nodes, as long as they use the same technology (certain analog modems, ISDN, IP in the future).

The requirement of FTS-0001 handshake protocol may be relativated, as FTS-0001, Chapter H leaves room for future development over non-dial nets, which might include a modified handshaking procedure.

Availability for direct calls from any other node

Internet connections have one thing in common with ISDN-nodes: They can only be accessed with the same type of technology, while both are incompatible to each other and to conventional PSTN-nodes.

Since 1993 ISDN-nodes are included in the nodelist with their special flags and most of them run at least one additional analog line or use specialized terminal adpaters, which support conventional calls via ISDN as transport layer as a combined node.

In fact, there are 3 major points for assigning a node number: ZMH (Zone Mail Hour), geography and FTS-0001.

2. Effects for IP-Nodes?

The internet acting as additional carrier for FTN-compatible sessions is in fact a non-dial-net, mostly formed of a huge mass of permanent communication paths. Only the individual session between any two nodes requires both systems availability for that duration, so that even dial-in users may run Fidonet over ip.

The timeslice may be ZMH or any other clearly stated online-time (i.e. published via T-flags in the nodelist), as long as ZMH is included in it. So there is no need for an in most countries quite expensive permanent connection to the internet to maintain CM-capability (Continues Mail), as this may be realized using callback capabilities for the internet connection.

There is no easy resolution for geography within the internet, as neither the ip number nor the FQDN (Fully Qualified Domain Name) are bound directly to geographical definitions. Even a system with a certain FQDN (i.e. www.fidonet.org, fido.nrh.de) might be hosted in the USA or any other country.
This concludes, that the geographical position is bound to the sysop home site and this assigns his membership to a certain net in the sense of Fidonet.

FTS-0001 defines all aspects of a certain handshake procedure between two nodes, focused on a conventional dial-net via telephone lines.
While Chapter H leaves room for future developments, the strict accordance to the FTS-0001 procedure should be thought over again. The internet as a carrier medium can not guarantee for a minimum bandwidth for a certain session neither for calculatable response times.

This makes a strict FTS-0001 sessions under certain circumstances unreliable or even impossible, as its definition of timeouts is insufficient for slow connections via certain parts of the internet, especially when satellite links are included on some parts of the routing path.

This uncalculatable response behaviour is considered in some modern protocols especially designed for transfer of data via the internet (i.e. BinkP), while it still allows the authentification based on the fidonet nodelist data. There might be developed other variants for fidonet-over-ip in the future, which should be taken into consideration, as long as they are publicly available.

3. Some practical experiences
As I was one of the early ip-nodes in fidonet, i use strict fidonet-over-ip since more than one year. Therefore i especially included the chapter about FTS-0001 relativity in this article, as BinkP does not fulfill it, but certain connections are really impossible with FTS-0001 via telnet or Vmodem.

Within this year, i saw many nodes announcing ip-capabilities for fidonet use, but some them disappeared without any further notice. So many lists of ip-nodes (in the future even my own one) are unreliable, as long as they are not maintained regularly.

Other transport protocols:
FTP does not require the nodelist for authenfication of a sessions, is it is a completely closed definition of its own as one of the standard functions in the internet. Email-based methods generally do not require any direct, authentificated session between the recipants.

4. Conclusion

An IP-node may be a "legal" part of Fidonet, as long as his system is available at least at ZMH.
His system must support a direct handshaking session over ip,
while nodelist data is used for calling and authentification.
He belongs to a certain geographical net, based on his home site and his NC handles his nodelist entry in a responsible manner.

Additional protocols should be considered as announcable, as some interested people might use it without installation of a complete node-system software package for easy participation within fidonet below the node-status.

In my proposal (see part 3) I considered all of the above aspects, including the possible future developments, which might not be calculated completely at this time.

The the nomenclature of the flags with an leading "I" just shows any node directly the participation of a special class (comparable to Vxxx for ISDN nodes, Hxx for Hst, Zxx for Zyxel), the official definition of ip-flags is more important than their optical design.

Sources and availability:
For an actual compilation of sources, download and other information, just take a look on http://home.nrh.de/~lbehet/fido/ (The site is tri-lingual (english/german/partly esperanto) at this moment, but volunteer translators are already busy :)

Testing FIP all around the world:
Beside connections to the authors system (fido.nrh.de at 194.231.142.17) with BinkP:24554, Telnet:23 and Vmodem:3141, the above mentioned website offers an ip nodelist, which is continuously growing :)

Legal information:
Copyright 1998 by Lothar Behet
This series of articles may be distributed freely within the fidonet community.
The distribution (partially or complete) on digital or printed media without explicit authorization of the author is prohibited.