Articles

A silly & unrealistic look at geographical exemptions.. or not?
By Frank Vest
1:124/6308

There was a Node in a Net in a Region in a Zone. The Node number was his very own.

Good grief! That sounds like something Dr. Seuss would write. :-))

Anyway;

The Node wanted, for some reason, a Node number in another Region in the Zone while keeping the Node number in the current Region.

While this would not be a problem to do, a simple matter of the RC adding the Node to the Nodelist, it is against Policy to have the same Person in two different geographical Regions, or Zones or Nets for that matter. At least on a permanent basis.

Geography as put forth in Fidonet Policy was the problem. Let's look at geography. What is it?

In relation to the dictionary, it is "The science that describes the surface of the Earth." It is also "The natural aspect, features, etc., of a place or area."

In Fidonet, a Zone, Region or Net is/could be the natural aspect or feature of Fidonet. Maybe this is unrealistic, but humor me. :-)

It is said that an Internet address is a location and has nothing to do with geography. A Fidonet address, then, should have nothing to do with geography. In reality, an Internet address is more than an address. It is a "phone number" of sorts. One can "dial" an Internet address and connect to the machine at that address. To "dial" a Fidonet address will connect you to nothing.... well, it might connect you to something, but what? Probably not what or who you wanted. :-))

The Fidonet address is a location. It is geographical in the sense that it gives a location of where that node resides within that land of Fidonet. The Internet address does this as well for the Internet. The Fidonet address, however, can not be dialed with success unless it is translated via some means to a number that can be used to connect. That is what the Nodelist does. Without the Nodelist to translate, xx:yyyy/zzzz means little as far as "dialing" or making a connection goes. On the other hand, 192.168.0.1 is a valid connection number. Yes, I know that 192.168.0.1 is not used as an address on the Internet. It's just an example, ok.

What do we have so far?

Internet address = connectivity
Fidonet address + Nodelist = connectivity

What's the problem? Why can't a Fidonet Node have more than one address? The Internet allows this, right?

This, in reality, would not be such a problem if it were only one Node. It would be little or no problem if the Node wanted to be removed from the current Net in that Region and moved to another Region as a Regional Independent or to another Net. As it happened, the Node wanted a Node number in one Region's Net while having an Regional Independent number in another Region.

The question is, `why not allow this?' After all, geography is not an issue as far as connection is concerned in today's Internet world. An Internet address has no value in geography, why should a Fidonet address?

Technically, I see no problem with this. Let's throw some (non)reality in this formula that has been so long in building. Reality, or non-reality, can really mess up a world. :)

The reality is that in the Internet world, one is allowed as many addresses as desired if one is willing to pay for them. Technically, there is no reason not to allow this.

Pay and desire are key here.

The reality is that in Fidonet, one should be allowed to have as many addresses as desired. Technically, with the Nodelist to translate Fidonet addresses into "dialable numbers", there is no reason not to. They don't even have to be paid for.

Pay and desire again are key here.

Let's add one more little thing to this. Human nature. If you removed "pay" as a factor, most people would ask the Internet for as many addresses as they could dream up. "Pay" protects the Internet from this to some degree. Yes, I know that there are other factors. Let's deal with what we have here, shall we?

Ok. Let's do a little unrealistic and silly math.

One Sysop wants a Node number in each Net, Region and Zone in Fidonet. Why not?? There's no technical reason not to... Well, let's see how that adds up;

There are 6 Zones, 70 Regions and hundreds of Nets. Let's use a small number for the Nets of, say, 300 minus 1 for the Node asking for the numbers.

1 Sysop x 6 zones = 6 Node numbers
1 Sysop x 70 Regions = 70 Node Numbers
1 Sysop x 300 Nets - 1 = 299 Node Numbers

So; 6 + 70 + 299 = 375 Nodes in the Nodelist plus what is currently there.

That's not too bad, right??

Let's go one more step.

300 Nets = an average of, say, 10 Nodes per net.

300 x 10 = 3000 Nodes

I'll let you do the formula here. The grand total would be around 828000 Nodes numbers.

Now, add to this formula that each Node could start his/her own Net up to the limit that Fidonet addressing allows. Better yet, figure the maximum number of addresses available in the "xx:yyyy/zzzz" addressing of Fidonet. Oh yes.. don't forget the .9999 for Point addresses. I don't even want to try that math. :-)

Oh... alright... Somewhere around 9,898,020,099 assuming 99 Zones with 9999 Nets and 9999 Nodes and 0 Points, If I haven't missed in the math. If I have, well... that's life.

Ok... You're going to argue that "common sense" would win out, Sysops voting on allowing addresses would prevent this, we would never reach this many Node numbers, the *Cs would prevent it and other things.

Well... Common sense in many cases isn't common, the *C are claimed to be only "Clerks" under the Nodes and, adding apathy in to the formula, if someone wanted to add a Net or Region with his/her friends in it and a vote was taken, most likely, the only voters would be the person and his/her friends. Guaranteed addition of Net or Region... maybe both or more... and isn't the reason for having an address pool in the Internet because the Internet is running out of addresses?

Oh heck! Let's do it! I want to see a Pentium bog down processing a 20 gig Nodelist. :-))

Wanna turn your Cray into a XT? Join Fidonet. :-)))

The Rogue Region
Philip Lozier 1:267/169

As I watch the debates go on concerning the removal of the RC12, I can't help but be amazed at the reactions to this by many, and the complete blindness of those who fail to see the simplicity of the issue.

What I see from the folks who are against this removal are a bunch of personal opinions not related to policy at all. There is no place for those "opinions" when viewing an action of this nature, as it is clearly defined within the policy itself.

Many have said that policy needs to be modified, and I would agree with this, however, policy should not be changed to the drastic degree that many would like IMO. I have many views on this, but it is a whole different issue.

Let me, before I go any further, state that I am not opposed to the allowance of out of net, or region, listings if there is a good technical reason for it, and if proper procedure is followed in having the listing agreed to by all involved, and approval is made by the ZC. This is absolutely NOT the case here.

R12 has a long history of defying Policy4 and trying to do whatever it damn well pleases. Recently, as is evident by the issue at hand, they have simply taken one step to far, and got their toes stepped on for it... It was felt that it would be just fine and dandy to go ahead and list another node that was listed elsewhere without consulting anybody at all. The ZC got wind of this, and cried foul, and told R12 that they could not do this any longer. From what I understand, the response of the RC12 was to mark the node on hold (which still in no way solved an illegitimate listing), send a response to the ZC of the effect that R12 has their own interpretation of P4, and to immediately list EVEN MORE nodes in a similar fashion.

To top it off even further, the RC12, to my understanding, further issued a defiant public statement in which the offer was made to list ANY node, from anywhere, within R12, wether they were listed elsewhere or not.

How can an RC take actions like these, and NOT expect to be removed?

The question has been issued as to if the ZC had a right to do this... YUP. Policy supports it. ANY RC is "responsible" to the ZC:

1.2.8 Top-down Organization. Checks and Balances.

For example, a Regional Coordinator is responsible to the Zone Coordinator for anything that happens in the region. From the point of view of the Zone Coordinator, the Regional Coordinator is completely responsible for the smooth operation of the region.

</policy>

The above clearly states that the RC is answerable to the ZC. For those who claim otherwise, they probably think the sky is red, and need a new prescription for their eyeglasses as well.

Many say the geographical clauses need to be changed... why? If a node, be it ION or not, lives in say Chicago, if the net in Chicago is able to provide them a proper feed, then what good reason would they have to list elsewhere? Just to be different? If there is no local net, why can't they still lit within their "proper" region. It makes no sense.

The fact is that this is a geographical issue, and geography is well defined in P4, and until changed, stands as is. Without spelling it all out, we know what it says... wether you like it or not is irrelevant. The most relevant part here clearly says that network membership is based on geographical or other purely technical rationale. It is not based on personal or social factors.

The exemptions portion clearly state that an exemption is NOT a right, and is not permanent. It further states that in the "exceptional" case where an exemption is allowed, it MUST be agreed upon between the ZC and the RC's (note the plural) involved. Again, this is not the case here.

The RC12 clearly defied these portions of policy as if they had never existed, and never even consulted the ZC, or any other RC involved. In doing so, it would appear to me that R12 was acting as a rogue region that lives outside of policy, and with no consideration for the rest of FidoNet whatsoever.

This lack of consideration for Fidonet as a whole is a continuous thing. While some may say "well their attracting new nodes, why shouldn't they reap the rewards", I would say, that if they are attracting new nodes, then they are doing what they are supposed to. They are also supposed to refer these nodes to the proper network or region that they belong in. If they were truly acting on the best interest of Fidonet, they would be more than happy and willing to do it the right way, and help other portions of FidoNet grow, but it appears that they are only self serving, and that there actions of node snatching are no more reputable or proper than the actions of those who would hijack an echo to serve their own purposes.

Getting right down to if the ZC had the right to remove RC12, I submit my final portion of policy quote:

6 Zone Coordinator Procedures

6.1 General

If a Zone Coordinator determines that a Regional Coordinator is not properly performing the duties outlined in section 5, a replacement should be found.

The Zone Coordinator is responsible for reviewing and approving any geographic exemptions as described in section 5.6.

</policy>

Sky still red? Clearly the ZC has the right to remove the RC. Clearly the RC12 should have consulted the ZC about any geographic exemptions. Clearly the RC12 defied the ZC publicly, and CLEARLY the RC12, while capable of doing so, REFUSED to perform her duties as described by policy, and even more clearly, was fully justified in being removed.

I am pretty confident on my position here, as a vote has been being taken around here as wether to back or condemn the removal. So far, though it may change, the flow seems towards backing the removal.

Why would it be any other way? If rogues are allowed to run around FidoNet and do anything they please, and get away with it without any level of accountability, then only chaos can follow. It will be then that all levels of even the loosest form of organization will be lost, and the true demise of FidoNet starts to unfold.

Introduction to Following the Z1C
Dale Ross
1:379/1

There are several issues that surround our Current Z1C that I will be writing about in coming editions of FidoNews as time permits. Some of my writings will be articles that will attempt to explain problems from my point of view. There will also be comic relief skits that have been put together for tension relief. They also represent some of the events that my articles will cover. Most of the comic relief skits are based on Monty Python skits and Python type humor. So to fully understand them you might want to check out the echo MONTE and ask questions :-). MONTE is an echo for the discussion of the funniest troupe to ever grace this planet.

Scene 1: The Z1C and Z1EC Seenby stuffing event

Some of you reading this article are already aware of Seenby-gate. However, I realize that many sysops do not read the Zone 1 echoes because of the bad blood they contain. Those sysops get their information here in FidoNews or from debates that spill over into the echoes that they are be reading.

The key players:

FidoNet Z1EC: Foxy Ferguson
FidoNet Z1C: Janis Kracht

The Z1EC is the editor and primary distributor of the "Official" Zone 1 Echomail routing chart, ROUTELST.nnn. At least that is what the Z1C and Z1EC call it, the "Official" list.

I am not going to go into every detail of every battle that led up to Seenby-gate. After earlier conflicts between Foxy and several Tier 1 Hubs from the Z1B over her handling of ROUTELST.nnn, it was suggested that an alternate routing list might be produced. Janet Kracht warned John Souvestre against the production of an alternate routing list. Her statement was perceived as a threat and she was advised of that fact. She was asked multiple times to clarify her statement and she refused to do so. Here is her statement:

+++ MESSAGE HEADER+++
From: JANIS KRACHT
To: JOHN SOUVESTRE
Date: 2/11/2001 11:14 PM
Subject: Open Letter
Echo: Z1_Routing
+++MESSAGE HEADER+++

Quote from Janis:

"And now you are threatening to create another routelist? I'll tell you what. If you don't drop this problem you have with Foxy and truly try to work with her, and if you don't stop threatening to create another routelist, you may find your Z1B left in the dust."

Later she made the following comment:

+++ MESSAGE HEADER+++
From: JANIS KRACHT
To: JOHN SOUVESTRE
Date: 2/12/2001 3:41 PM
Subject: Open Letter
Echo: Z1_Routing
+++ MESSAGE HEADER+++

Quote from Janis:

"I think that creating another ERN Routelist will cause the Z1B more problems than you can imagine."

After these messages many of us were left with the feeling that the Z1C would try to take some kind of action against the Z1B and anyone friendly towards the Z1B.

Because of the issues with the Z1EC and the Z1C, ultimately several sysops approached me about an alternate routing list. They were interested in forming a volunteer group, aka ERN Charting Committee to address routing issues. Up until that point none of these sysops had discussed with me or any other member of the Z1B the possibility of creating an alternate list. The mission of this group was to look into the possibility of producing an alternate routing chart for Zone 1. Eventually an alternate routing list was produced and it was hatched into Z1_REC, the same file distribution echo that ROUTELST.nnn is hatched.

The very next week the Z1EC hatched ROUTELST.112. Only this time several FidoNet Zone 1 node numbers were added to the Seenby lines of the tic file. This prevented these systems, and any peer connection links of these systems from receiving ROUTELST.112. Not a single system that was added to the Seenby line connected directly to the Z1EC for any kind of traffic. That very same week the weekly posting or ROUTELST.nnn to the message echo Z1_ROUTING stopped. Obviously both of these events were attempts to keep routing information out of the hands of people that were considered to be "not friendly" to the Z1C and Z1EC.

I learned that ROUTELST.112 had been hatched but did not arrive at my system. I contacted my upstream link for files, Bob Juge @1:106/2000 about the problem. He acknowledged that the problem was upstream of him but did not elaborate on what the problem might be. After checking with another Z1B hub, Todd Cochrane (1:10/345) it was confirmed that my node number, 1:379/1 and several other node numbers were in the tic file that he received. Node numbers 4-5 hops away from the Z1EC where also in the tic file. There were even systems that did not normally receive that file echo that were also listed in the tic file.

The following nodes were added:

Seenby 1:229/438 Darrell Salter
Seenby 1:229/604 Stewart Honsberger
Seenby 1:229/731 Phil Simpson
Seenby 1:249/116 Carl Austin Bennett
Seenby 1:250/525 Lesley-Dee Dylan
Seenby 1:379/1 Dale Ross
Seenby 1:2404/201 Ruth Argust
Seenby 1:2624/306 David Calafrancesco

The result of this stuffing of node numbers was that the Z1C did little more than slap the Z1EC on the wrist. The Z1C continues to support the Z1EC. The Z1EC AND Z1C have never explained what happen nor have they apologized for these actions against fellow FidoNet sysops. The Z1EC has attempted to blame this problem on an error in processing and some multi-computer configuration that she has setup. Third hand information suggests that she entered the node numbers into a new software package to test that package and meant to remove the numbers before the real file was hatched.

The question we have about that explanation:

Why were these specific node numbers used for the test? Everyone one of the nodes listed was unfriendly to the Z1C or Z1EC for one reason or another.

It is very obvious that this was a deliberate act by the Z1EC and possibly the Z1C based on her previous threats. Some of us believe that this was simply the Z1C carrying out the threats that she had issued a few months earlier.

The Z1EC has several people running interference for her, most notably Ross Cassell (1:18/500) and of course our esteemed Z1C. There are several other people helping but their roles to date have been of a much lower profile and do not warrant mentioning at this time. I mention the players because you will read about them in the comedy skit that I have submitted with this article. As new players are introduced in future skits I will detail that person's role so that you can get a better understanding of the players.

There are two people that are publicly known to be associated with the group producing the alternate routing list. Bobby Queen 1:379/5 is the public spokesperson for the group. I provide a point address for the group to send NetMail queries about routing information and I provide technical "support" concerning routing issues.

I may write another article about other events surrounding this routing chart in the future. The purpose of that article will be to give you a better understanding of what they do. However, the intention of this article is to focus on the Seenby stuffing.

These events have generated several compilations of Monty Python skits to fit the situation(s). This is the first of those skits. They were all written as a method of releasing tension over the situation. We went through several names before we hit on these. We figure they are more acceptable to all readers than some of the other proposed names. As I was touching this skit up months after originally writing it, a new name has come to the surface and I have added it in here.