In light of this statement, it is necessary to reiterate that FidoNet is NOT a democractic organization. Indeed, it isn't an organization at all, but a loose association of independent nets. If what you are doing works in your net, and does not violate Policy, then it is right. If it interferes with other nets, then it becomes the RC's job to solve the problem.

An NC actually has two jobs at the same time. The NC is the official "head" of a network and is also the Net Coordinator of a net within FidoNet. The first job has nothing to do with FidoNet in any way. The second job is entirely to do with FidoNet. Of course, the two jobs are inextricably intertwined, but we must all do our best to keep them separate.

As network head, if you want to rule your net with an iron hand, that's your choice. If you want to hold elections over every decision, that's fine too. But the NC's job is to do what is listed in Policy 4 under NC's responsibility and to react appropriately to directives received from their RC. That's it.

If you're having problems in your net and want advice, the RC is there to provide that advice. It will almost always consist (in broad terms) of something along the lines of "follow Policy 4 -- don't put up with any horse's appendages, and don't let anyone upset the smooth running of your network." If you want to play safe (and I recommend this approach), ask the RC what to do about a specific situation. If you want advice, however, give enough details to work with. Most RCs don't like surprises, so if you have a policy complaint that you think may bounce, ask for assistance from the RC.

If you're an NC because you like power, you're in the wrong job and should seriously consider leaving before you're thrown out. If you think that having the biggest net or the noisest net, or the furthest South net is important, you're mistaken. In recent history, a number of NCs have been replaced in FidoNet for failing to perform their assigned duties. The cases were reviewed by the ZC at the time, and all decisions were confirmed.

This is not an issue for NC debate. NCs who insist on being disruptive will be replaced whenever the RC considers it necessary. This will be true no matter who is occupying the RC slot at any given time, if they are doing their RC job properly.

RC's who are not performing their duties should and will be replaced by their ZC in the same fashion.

These are the facts of FidoNet life. They are immutable. You can either accept them or quit. The NC position is a volunteer job and these are the ground rules -- nobody is forcing you to be an NC.

These are the simple rules for NC operation in Region 17 at this time:

1. Operate an FTS-0001 compliant mailer;
2. Observe ZMH;
3. Do nothing illegal through FidoNet;
4. Administer your Net as defined in P4;
5. Poll the RC's system at least once a week;
6. Deliver an up-to-date node stub to the RC as often as required.

That's all there is to it. Any NC who fails to live up to these responsibilities will be replaced. Remember, however, that these are the MINIMUM requirements. An NC who only follows the minimum may not be the best choice for the position.

What does the RC do for NCs? As Policy says, the RC is responsible for the smooth operation of the Region. That means that if your net is disrupting other in FidoNet, the RC is charged with doing something about it. Additionally, the RC supplies you with the nodediff and FidoNews.

The RC should give you a ready ear, and should support you and your decisions (even if I don't like them, I'll support them if they follow policy!). I'm going to try and keep you posted on anything important that's coming down. I'm going to answer questions -- and if I don't know the answer, I'll do my best to find it out. If I think you're screwing up as NC, I'll tell you. I'll also ask you to let me help you unscrew it (it's usually easier than finding a new NC! <g>).

Additional duties, are as specified in Policy, and include hearing, arbitrating, and if necessary, ruling on FidoNet problems within your net. You can delegate any aspect of the NC's job with the exception of hearing and ruling on Policy Complaints. Regardless of who has been assigned to do what job, the NC is responsible.

Here are some specific guidelines -- if you already know this stuff, or have a workable alternative, just skip to the next part!

Node Stubs:

The list of nodes in YOUR net is called the Node Segment before you process it, the Node Stub after your process it, and becomes part of the Region Stub after I process it. It becomes part of the Zone stub after the ZC processes it, and eventually becomes part of the Node Diff which is distributed to all FidoNet nodes. Every node in FidoNet is required to run with an up-to-date nodelist -- that means not just getting the diff, but applying it each week.

Using MakeNL:

The easiest way to generate your segment of the nodelist is to use the (DOS) program MAKENL. It's requestable from me as MKNL251.ZIP and the current version is 2.51. Some detailed and simplified instructions for using it are in MAKENL.HOW (a copy is also in the zipped file MAKENL.NCS) available from my system).

Sending Node Stubs:

You need to send me a node stub each week, regardless of whether your net membership has changed or not. This procedure allows me to ensure that your system is up and running with a minimum of fuss for either of us. The easiest way for you to do this is to set your batch files to run Makenl every night, but on Tuesday night move the outfile to a backup directory (thus giving you a backup and a history of your net) before you call Makenl -- Makenl will check, find no file, generate and send a new one to me. Be careful not to erase your master node segment!

Your node stub should be in to me no later than early AM Wednesday. If you're in need, you can send to me on Thursday early morning as well, and if you're really desperate you can try later in the day as well. The region stub goes to the Z1C as soon as you send it to me; the Z1C compiles his list at 7 PM (Pacific Standard Time) on Thursday. If there is a fatal error in your stub, you'll get a crash message back from my system; otherwise, a confirmation will be on hold for you. You should also see your net listed in my weekly posting of stubs received (in the RGN17 echo). You can send as many node stubs to me as often as you like -- my system will process them all in order!

Absence:

If you're going away please let me know, along with the name and voice phone number of whoever will be sitting in for you. Most NCs find that they can put off all Net business (other than node segment changes) until they return. We can discuss this and develop solutions for you on an "as-needed" basis.

Routed Netmail:

Incoming:

There are several ways of getting netmail in and out of your net. First let's discuss incoming mail: it is the NC's responsiblity:

"1) To receive incoming mail for nodes in the network, and arrange delivery to its recipients".

This means that you must either delivery the mail to the node in your net, or find a way to advise him/her that there is mail waiting. You do not have to make long distance calls at your expense. If you can't deliver the mail, you must return it or notify the sender that it was underliverable.

Outgoing:

You do not have to deal with outgoing netmail from your net. You may do so if you choose.

The easiest (but most expensive) to send netmail is to call the destination node directly. Most NCs are not enthusiastic about doing this for their nodes.

The second way of sending netmail is via the *C chain. This is known as Low Priority Routed Netmail (LPRN). This routing is paid for by the NCs (who deliver to their RC when they poll), the RCs (who pick up and deliver from the ZC), and the ZC (who picks up and delivers from the other ZCs). It's not a fast route, but it's quite reliable. Of course some netmail may not travel the entire path--so the outbound routing from a node looks something like this, while the inbound is just the reverse:

 Node ===> NC ***> RC ***> ZC ***> ZCs in other Zones
            º      º        º
            º      º        ÈÍ ***> Other RCs in the same Zone
            º      ÈÍ ***> Other NCs in the same Region
            È ===> Other Nodes in the same Net

The third way of sending netmail is via the *EC chain. This is known as Echomail Routed Netmail (ERN) or sometimes Low Priority Echomail Routed Netmail (LPERN). This method is usually faster than LPRN but tends to be less reliable. In the past, we've had problems with the satellite companies not wanting to route netmail. Whether that problem is solved I don't know. Once again, a given piece of netmail may not travel the entire path, but here's what it looks like:

User ===> Node ===> Echo Hub ===> NEC ***> REC ***> Star +++> other Stars
                      ³                             ³                  ³
                      ³                             ³  The "Backbone"  ³
                      À***>Echo Hub in another Net  ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
                           or Zone (Long distance)

In addition, any node in this chain may be connected to any other node, and the echoes agreed upon by those two will be exchanged that way.

Finally, some sysops are beginning to use the InterNet for both routing netmail and echomail. This topic is currently beyond the scope of this document.

1.2.1 Individual Systems and System Operators

The sysop runs his/her system as they see fit, as long as they mesh with the rest of FidoNet in accordance with Policy. That means that you can't tell anyone what to do with their systems as long as they observe Policy.

1.2.1.1 Users and 1.2.1.2 Points

No user is responsible to FidoNet; only nodelisted operators are. If a problem develops with the user, approach the sysop about it. Under no circumstances can a complaint be filed against or by a user, so the sysop is completely responsible for his/her users' actions.

NOTE: Points are users as far as Policy is concerned.

1.2.3 Networks and Network Coordinators

NCs are appointed. If an election is held in a network, the elected candidate is generally appointed by the RC. The RC is not required to do so, however; s/he may appoint someone else (this is *very* rare, btw). The reason things are done this way is because Policy requires that each level of the coordinator structure be responsible for everything happening within their jurisdiction; if I'm going to be responsible for everything in a region, appointing someone I believe may be a problem for me invites trouble.

1.2.4 Regions and Regional Coordinators

The RC is not required to forward *any* messages. S/he is appointed by the ZC, under the same general guidelines outlined in 1.2.3 for NCs.

1.2.5 Zones and Zone Coordinators

ZCs are also not required to forward any messages. They are selected by the RCs in the region, as opposed to being appointed by the IC. This is the lowest level of FidoNet in which an election is not only sanctioned but required.

1.2.6 Zone Coordinator Council

The ZCC is intended to address issues affecting FidoNet as a whole. It is a governing body, and concentrates on inter-zonal issues.

1.2.7 International Coordinator

The IC is (normally) a ZC who is selected by the ZCs to be a "first among equals." That means that the IC is the chair of the ZCC. S/he can issue decisions and specific interpretations of Policy when necessary, or extend Policy if needs dictate.

1.2.8 Top-down Organization/Checks and Balances

Generally speaking, FidoNet is structured in such a way as to allow the lowest levels of the Coordinator structure to act as appropriate to any local conditions in their area. That means that as long as your network is operating in a manner consistent with Policy, you can do just about anything you like. You are completely responsible for your network, and you are completely responsible to the RC for any problems which may arise within your network, just as the RC is completely responsible to the ZC. If anyone in the Coordinator structure isn't properly doing their job in accordance with Policy, they may be replaced by the person at the next higher level in the structure; i.e. NCs can be replaced by RCs, who can be replaced by ZCs. The ZCs and the IC are (s)elected rather than appointed to provide for part of the balance process, and another part is provided by the RC's ability to reverse a ZC decision, and the ZCC to reverse a IC decision. RC's and NC's decisions are not subject to reversal, but are subject to the appeals process outlined in section 9.5 of Policy.

1.3.2 Geography

Networks are expected to be clearly defined using geographic criteria, which may include local calling areas as part of the definition. There must, however, be a clear geographic definition to each and every network. Where there are many nodes in a given area, and local calling allows them to reach each other but the network is so large it is unmanageable (a judgement call by the *C chain), it must be split using strictly geographic criteria and any node in the area must be listed in the proper network. Policy does not allow for exceptions to this unless they are based on technical merit, and must be approved by the RC and ZC. Generally speaking, in practice, only the RC need give explicit approval. You, as NC, are expected to abide the border definitions. Listing a node which is not within the geographic boundaries of your network is an explicit violation of Policy unless it is approved. Personal and social factors are *NOT* to be considered in where someone is listed. Policy does not recognize anyone's right to determine what network they are listed as a member of; nodes are to be listed as a member of the network whose geographic definition they are located within.

1.3.3 Zone Mail Hour

ZMH is a case of tradition and precedent. It goes back to the days when CM systems were not commonplace in FidoNet. Enforcing ZMH is one of your responsibilities as a NC. I personally don't require that you "enforce" ZMH, but remember that Policy does so require; if a complaint is filed, you will be required to act on it appropriately.

1.3.4 Nodelist

Remember that as long as a node is operating within the requirements of Policy they are qualified to be listed. You cannot impose any additional restrictions of any kind. Doing so is an explicit violation of Policy. Included in this is the issue of applications; you can request that potential nodes use a particular format, but you must accept any form of netmail that contains the information required by Policy. Note that while there is no requirement for a sysop to use his/her real name in the nodelist, I expect that you will know the real name and will make a judgement call on whether to allow a node to use a false name or not. My guideline would be that of "why does the sysop want to use a fake name?" -- some well-known public figures may have just cause to want to use a pseudonym, but I can't see it for us ordinary folk!

1.3.5 Excessively Annoying Behavior (EAB)

Here's a really sticky wicket. As NC, you are the first-line arbiter of complaints, and you are expected to define "EAB". A few things to keep in mind when attempting to define it:

A) EAB is almost always *repeated and persistent* annoying behavior on the part of a member of FidoNet who has been apprised of the nature of his/her behavior and why it is annoying.

B)be annoying because of their inexperience. They should not be castigated or penalized for their lack of experience, but should instead be educated and guided to knowledge of their infraction.

C) Someone exhibiting EAB may be doing so for a reason; try to find a way to see the reason and understand it. Remember that everyone in FidoNet has an equal right to participate, and that there are at least two sides to every story.

D) Rude and obnoxious behaviour, obscene language, threats against individual's person or property etc. will all be considered excessively annoying on the first occasion. Membership in FidoNet is a privilege not a right. Membership can be suspended or revoked if the member does not behave in an appropriate manner.

If you have to decide a complaint in which EAB is alleged, then the best advide I can offer is to leave no stone unturned. Search for the truth as both of the principals see it, and then read the appropriate sections of Policy before drawing any conclusions. Then re-read everything a second time before issuing a decision. Remember that you must always issue a decision that is based on Policy not on your feelings.

You're welcome to consult with me before making a decision, but don't expect me to a) solve your problem for you or b) decide an abstract or hypothetical case.

1.3.6 Commercial Use

Another point of contention. The general guideline here is that no business should take advantage of FidoNet to further their business interests at the expense of the members of FidoNet. A software company providing support for its products would not be an example of this, because the members of FidoNet would benefit from that. Think of the potential benefits to members of FidoNet when you think of commercial use and you will arrive at a fair interpretation in most cases. This section also addresses mail which is forwarded via NCs to employees of companies or which is business-related. The rule is that this type of mail is not forwarded, and no guarantees of delivery are expressed or implied.

Section 2: Sysop Procedures

2.1.1 The Basics

In general, sysops are free to do as they please. As long as they abide by Policy, you cannot impose any additional restrictions on them or tell them how to operate their systems. If they operate a commercial system, it's none of your business unless they violate Policy. If they operate a system which has pirated software or any other illegal materials, you must show that they are using FidoNet to move those files or materials if you are to take action against them. A complaint filed against a sysop who has illegal software on their system is invalid unless it demonstrates that FidoNet technology was used; i.e., a log segment which shows a mail session in which a file was transferred. This is the way that Policy is written; I question whether or not it's reasonable in this regard, but I have to interpret it as written. A complaint filed against someone who is *promoting* the piracy of software need only show the attempt to promote the activity, not the actual piracy or transfer of a file.

2.1.2 Familiarity with Policy

Now you know why I'm doing this. Everyone is expected to be familiar with Policy, but you as a NC are requred to understand it. You decide what EAB is, so you have to understand Policy to do so.

2.1.3 Responsible for All Traffic Entering FidoNet Via the Node

Any message which is transferred by FidoNet is considered to be the responsibility of the originating system for the purposes of complaints. Remember that points are really users, and that the bossnode would be the sysop responsible in this case.
2.1.4 Encryption and Review of Mail

This section can be both confusing and dangerous. Be aware that several opinions concerning the legality of reviewing mail have been put forth, and the consensus has been that if you do not review mail, you are not responsible for its content. This seems to be the most prudent course of action to take, since it absolves you of any blame for the activities of others.

If you *do* review mail, and you find that your system is being used to route commercial mail or illegal information (be careful about defining it!) then you must bounce that mail as provided for in section 2.1.7.

2.1.5 No Alteration of Routed Mail

This is straightforward. Don't touch any message routed through your system and you won't have a problem.

2.1.6 Private Netmail

This can be summed up as follows:

1) There is no such thing as routed private mail. Anyone along the way can read it.

2) If it's really private, send it direct.

3) This section seems to say that a sysop cannot share private netmail with anyone else without the permission of the sender. This section appears to contradict 2.1.6.2 "Private mail addressed to you".

2.1.6.1 No Disclosure of in-transit mail

This section is pretty clear: if a message isn't addressed to you, and you weren't given the message by the writer or the recipient, then you have no business reading it. If you do, and you make use of what you saw, you have violated this section of Policy. It is important to understand the implications here:

1) You don't have to tell anyone what you saw to make use of it; you can violate this provision of Policy by simply making use of information.

2) This only applies to netmail, and strictly speaking, only when the private flag is set (this is an interpretation that I have made; it is not specifically mentioned in Policy.) If the private flag is not set, then it is questionable whether or not the message was intended to be private, and you shouldn't attempt to make a judgement call on it. The exception would be when it states in the body of the message that it is confidential.

2.1.6.2 Private mail addressed to you

Mail written by or to you is yours to do with as you please, unless it is specifically requested by the sender that it be kept confidential. If the sender does request confidentiality, and uses that as a "tool" to harass or otherwise annoy someone (including you), then this specific rule may not apply. Judgement and common sense should be used in determining intent, and if there was no intent to annoy, it should not be considered annoying unless it persists.

2.1.7 Not Routing Mail

If you agree to route mail, you must either do so or return messages you do not route. The only exceptions to this rule are:

1) Messages which cannot be returned because the origin address is not nodelisted, and

2) Echomail, which is a broadcast medium and returning the message would serve little purpose.

If you bounce a message, you must include an explanation as to why it was bounced. Do not simply return the message without explanation; this will cause confusion, and will likely result in further messages to you asking for the reasons.

Failure to properly bounce a message that was stopped at your system is annoying behavior. If it's a technical problem, then a reasonable amount of time should be allowed for technical compliance to occur before it's considered annoying. Reasonable? That's up to you to define, but consider how much time you'd need to fix such a problem and then double it to allow for those who may be less technically competent; this should provide a pretty good yardstick.

2.1.8 Exclusivity of Zone Mail Hour

ZMH was intended as a window during which any system in FidoNet could directly call and drop off or pick up netmail. With the advent of CM software capable of receiving and sending mail 24 hours a day, it's not as important as it used to be.

It is, however, still important and required. There's a fine line here.

Stress the importance of this to your nodes, but I don't want to see you going out of your way on an enforcement kick. Unless you receive a complaint about someone not being able to drop off mail during ZMH, I don't want you acting against any node because of this provision.

Remember: educate them and assist them to comply. Don't dictate.

Last item on this section: you, as NC, can require that your nodes observe an additional mail event. This is provided for in Policy primarily so that you can drop mail off to any node in your network at a time convenient to you. Be reasonable if you intend on invoking this provision, because I don't want to hear people complaining that they have to take their BBSes offline during their peak calling times.

2.1.9 Private Nodes

Private listings are easily abused, and there's a lot of talk about iliminating them in the next version of Policy. There's good reason for this: most of these nodes can be supported properly as points of another system.

Avoid private listings whenever possible. If a node can't be supported as a point and can't arrange to be online for ZMH, then a private listing *may* be justified. Check this one out carefully as private listing impact on us all.

2.1.10 Observing Mail Events

Removing a system from FidoNet because you couldn't drop off mail during ZMH is allowed, but very often what happens is that the person who was dropped suddenly reappears complaining that s/he wasn't notified. Again, educating the node is the key. Be sure that they understand that they must be able to receive netmail during ZMH (or a network mail event.)

2.1.11 Use of Current Nodelist

Here's another area that has sometimes been abused by NCs. You must properly interpret this section along with section 4.1; what that means, in a nutshell, is that you should *periodically* check to ensure that nodes are using up-to-date nodelists, not that you should require them to pick up from you weekly.

Once a month is more than sufficient to check systems for current nodelists. If you excommunicate someone simply because they haven't picked up two nodediffs, I'll overturn you on any appeal made to me.

I've said it before, but it bears repeating: BE REASONABLE.


2.1.12 Excommunication

This is one of the most misunderstood things about FidoNet.

Excommunication is the act of removing someone's primary node number from the Nodelist. It can occur for failure to observe ZMH, as the result of a PC, or by the invocation of section 4.3 by a NC.

1) Failure to observe ZMH: be sure that you've tried everything before doing this. I guarantee the node will come back to you asking why s/he is no longer listed, and will be very angry. Save yourself the aggravation whenever possible.

2) Ruling on a PC: if a node has been so annoying to someone that a complaint is filed, and you find in favor of the complainant, do your best to find an alternative to excommunication. Let this be the path of last resort, when nothing you can do will resolve the problem.

3) Invoking 4.3: be *very* certain that you're doing the right thing here. Invoking 4.3 is a unilateral decision that only a NC can make, and if an appeal is filed, you will come under a microscope for it. If I find that you have wrongfully excommunicated someone, I will first overturn your decision and will then decide whether or not you should remain on as a NC. I will not tolerate abuses of this section; document everything and be prepared to prove that you were acting reasonably in making the decision you made.

If you're getting the idea that I dislike excommunication, you're right -- please avoid it whenever possible.

On the other hand, if you *have* excommunicated someone and on appeal I find in your favour (or if there is no appeal), I will back you 100%.
Note that excommunication doesn't have to (and probably shouldn't be) for life; shorter terms are possible!

When deciding to excommunicate, you should ask yourself whether you are punishing someone or protecting FidoNet. If the former, they should be give a chance to demonstrate that they have learnt their lesson. If the latter, then a life-time suspension might be appropriate.

2.1.13 Timing of ZMH

The ZC sets the timing of ZMH, which is currently 01:00-02:00 PST. There is no reason to expect this to change.

2.1.14 Non-observance of Daylight Savings Time

Simply put: when PDT kicks in, adjust your mail schedules accordingly. ZMH does not actually change, so when clocks move ahead one hour, the timing of ZMH moves up one hour along with your clock.

Here it is, so there's no confusion:

Time Zone : Zone 1 Mail Hour

Pacific Standard Time: 01:00 to 02:00
Pacific Daylight Time: 02:00 to 03:00

Of course, you could always do what I do, and just stay on Standard time all year long. Then you never have to worry about it. <grin>

2.2 How to obtain a node number

Under *NO* circumstances are you to require the use of a specific format for the application for a node number. That means:
1) You must accept any *netmail* message arriving at your system requesting a node assignment, as long as it contains the necessary information (which does not include addresses)

2) You cannot *require* the use of a program which generates such a message although you can certainly request that it be used.

3) You cannot require that an application be filled out

Further:

1) You cannot assign a node number to someone outside of your geographic boundaries under any circumstances without approval from the RC

2) If an application is incomplete, request the additional information and do not leave the applicant hanging waiting for a response

3) Get node applications processed in a reasonable time frame (i.e., two weeks)

4) If an application comes in from someone who should be listed in a different network, quickly forward the application to the NC of that network

5) You cannot require additional information not mentioned in Policy; you may request it, but you cannot deny someone's application because they didn't supply you with it

You are not required to grant nodelistings to anyone who applies, but have a good reason not to if you don't. Explain it to the person applying.

In general, it seems better to let someone join FidoNet and then educate them until you can't stand it, rather than barring them to begin with. You'll find you get a surprising number of nodes who learn to behave after they're allowed to join.

2.3 If You are Going Down

Encourage your nodes to notify you of problems whenever they anticipate them, then they can comply with this provision easily. As in most other cases, it's up to you to educate them on proper FidoNet etiquette.

2.4 How to Form a Network

I'm not anxious to split the region into a zillion micro-nets. For that reason, I'm going to be reluctant to grant any network applications which will result in splitting a network unless there's agreement between all concerned and it will prove beneficial.

If a network is to be formed, then I require that boundaries be set that are clear, agreed upon by all concerned, and observed strictly. I also require that the person who will serve as NC be approved by the majority of those in the new network.

Any network application coming to me which does not meet these requirements will be turned down immediately. I'm especially watchful for personality conflicts masked as network applications, and will deny those as well.

3 General Procedures for All Coordinators

3.1 Make Available Difference Files and FidoNews

Self-explanatory. Note that you don't have to deliver them, particularly not at long distance.

3.2 Processing Nodelist Changes and Passing Them Upstream

Already discussed in the preamble.

3.3 Ensure the Latest Policy is Available

Basically self-explanatory, but I suggest you let me see any local network policies that you may want to implement so I can help you ensure that they are not in conflict with FidoNet Policy. This will protect you in the event of a complaint.

3.4 Minimize the Number of Hats Worn

Don't try to do everything. Most of us can do one thing well, but do many things poorly. If you move mail in addition to coordinating a network, be sure that people can get through to you when they need to. If you will be stepping down as either a coordinator or a hub, please allow plenty of time for your services to be replaced.

3.5 Be a member of the Area Administered

Self-explanatory.

3.6 Encourage New Sysops to Enter FidoNet

Self-explanatory. I have a file which explains a lot about FidoNet on my BBS, and which gives instructions on applying for a node assignment. It tells people what files to get (Policy, etc.) and what software is needed. Please consider doing the same thing. You're welcome to a copy of mine if you want it.

3.7 Tradition and Precedent

While it's nice to observe tradition and precedent, you don't have to do what your predecessor did. You are only bound to act within the guidelines in Policy. If someone else decides a certain case a certain way, you don't have to do the same thing.

3.8 Technical Management

Decisions on network management must be made on technical grounds. There is some grousing from a few people about NCs making decisions on other factors. Well, the fact of the matter is that you can; as long as a decision is *not* related to the management of a network, you are not bound to decide it on technical grounds. Never, however, use personal or social factors for making a decision if at all possible. Convenience, as opposed to preference, is a good basis for a decision.

4 Network Coordinator Procedures

4.1 Responsibilities

As NC, you really don't have as much to do as you might think. Ideally, your network will pretty much run itself. We all know that's a pretty optimistic view, but it is in fact achievable.

You are responsible for routing inbound netmail for members of your network to them. This does not mean you have to spend money to deliver mail to a long distance node. I suggest you arrange for such nodes to poll you once or twice a week.

As NC, you are also responsible for assigning node numbers to members of your network, and for assigning new node numbers to applicants. I have several points to make here:

1) Any application which comes in to you which includes all of the required information (as per 2.2 of Policy) is to be honored as a valid application. No additional information can be required in order to assign a node address.

2) The use of "network applications" is optional, but not required. Failure to act on an otherwise valid request because you didn't receive "your application" from the applicant is a violation of Policy, and any appeals to me will be ruled upon accordingly.

3) You are *not required* to approve of each and every application you receive. You *ARE*, however, required to be reasonable in considering them. Several examples are provided in Policy; someone who is known to be a twit and cause trouble for others is not someone you'd welcome into FidoNet. If there's *any* doubt, however, I want you to approve an application. The one thing we must not do is to start forming an "exclusive club" by rejecting applications. Use your best judgement--I won't second-guess you as long as you've done your homework. Appeals to me because applications were denied will be investigated (remembering that they are not policy complaints), and if you tell me that the individual in question is a problem, I'll always side with you.

Key in this point is the fact that an applicant is *not* a member of FidoNet, and is not protected by Policy. I can't overturn your decision without setting an awful precedent, so I'm not about to. All I'm asking you to do is BE REASONABLE.

As NC, you are responsible for maintaining the nodelist segment for your net. Some NCs in the region delegate some of that task to hub coordinators, who maintain subsegments for their hubs and submit them to the NC each week. This is fine, but remember that you and you alone are responsible. If problems occur, don't point fingers at anyone else. I'll be very disappointed if you do. <g>

You should keep your nodelist segment in numerical order, at least within each hub's portion of the list.

Please note that modem and user flags do change from time to time. Encourage (require?) your nodes to keep you informed of new hardware, changes of operating hours, etc., and keep your segment up-to-date.

You also have to "make available" NodeDIFFs, FidoNews and Policy Documents. Note the words "make available"; there's good reason for that. You are *NOT REQUIRED* to *DELIVER* them. You are simply required to make them available. It's up to the nodes to get them. If you distribute them through your hubs, as most do, then that's a benefit to those members of your network. They are responsible for getting them and making use of them, which brings me to my final point here.

Policy says that you are responsible for ensuring that nodes in your network use "up to date" nodelists. I'm confused as to how you would accomplish that, because you can't audit everyone's systems. Even if they receive the DIFFs every week, they don't have to apply them, just have a current nodelist.

Basically, I'm telling you that you should stress the importance of using up-to-date nodelists, but you can't reasonably enforce it because you can't go to everyone's homes and look at their systems. If someone uses an out-of-date nodelist, and wakes someone in the middle of the night with a modem call, the authorities will deal with them. You will hear about it, and then you can deal with that situation. If you have good reason to believe that someone is not using an up-to-date nodelist, you could test them. When I was an NC I had to do that on several occasions, though I never had to remove anyone over it; after I notified them that they needed to stay current or they might face problems with the authorities, they got with the program.

, Once again, please use your best judgement.

4.2 Routing Inbound Mail

I basically covered this in part 7, but a couple of additional points are added here.

Policy tells you that if a node is receiving large volumes of host-routed netmail, you can request that node to ask the senders of that mail to stop routing it. Note that you don't ask the senders, you get the sysop to do it. If the sysop can't or won't solve the problem, you can ask the RC to assign the node regional-independent listing and drop them from your network.

The thing about that last bit that strikes me is that the request to the RC to assign the independent status does not need to be approved for you to drop the system from your network. I have a problem with this, but I'm not sure how it can be clarified in accordance with Policy. For the time being, I'm hoping that we won't have this situation occur.

Bombing runs: annoying behavior, period. Recently, someone posted a message about "luck" to a great many people, who in ignorance of Policy did the same in return until at least 1000 of these puppies were floating around at any time. This is an abysmal way to behave; that costs each of us money! If someone complains to you about a bombing run, take it *very* seriously. If it's true, then deal with it appropriately.

Echomail: this is an interesting topic, and one which can be treated as a study in and of itself. Bottom line: if echomail traffic causes netmail traffic to be seriously delayed or lost, then the echomail traffic should be moved or rerouted so as not to interfere with netmail. Netmail is *more important* than echomail, folks. Don't let anyone tell you different.

In addition, don't get involved in a network's cost recovery plan as an adminstrator. Don't accept financial support from a CRP, don't help administer it. Hands off!

You are not required to route mail which you can't read (encrypted), commercial mail (advertisements, etc.) or illegal mail. If you don't route such mail, bounce it in accordance with section 2.1.7.

Please note that you are not the "mail police". You do not have to review mail, and if you do not then common opinion holds that you are probably protected from action against you. I do not review mail passing through my system for this very reason; ever hear of AT&T being sued or prosecuted for allowing drug runners to do business using their phones? <grin>

4.3 Assigning Node Numbers

More on this subject: most of this section is straightforward. The first part describes your responsibility for maintaining the integrity of the network by only assigning numbers not in use to nodes qualified to have them. It also says that you can reassign new addresses to existing nodes, but you should check with the members before doing so.

You should return the node assignment to the applicant in netmail, to be sure that they can read it as well as send it.

Now the section I have a real problem with:

"If a node in your network is acting in a sufficiently annoying manner, then you can take whatever action you deem fit, according to the circumstances of the case."

The words "according to the circumstances of the case" are important, and are too often ignored. If the problem is related to participation in an echomail area, then cut the link to the echo. If the problem is related to someone dropping obscene or inflammatory netmail on someone's system, then password the link.

NCs have been know to use this section to summarily excommunicate members of their networks. I *WILL NOT TOLERATE* abuses of this section of Policy in any way.

In other words, find the least restrictive means of dealing with a problem. Excommunicating someone based on an invocation of 4.3 is a *SERIOUS MATTER.*

Appeals to me will be investigated thoroughly and if I find that a bad decision was made, I will direct it to be corrected. If it's clear that an abuse occured, the NC will be replaced. If you had any doubts as to my feelings on this section, I hope that this clears them up.

4.4 Maintaining the Nodelist

You should implement name changes, phone number changes, and so forth in your segment of the nodelist as soon as possible after the information is received from the affected node. If you're on holiday (and of course you'll have told me that) then either have someone else do the node stub update or get me to do it for you.

If a node turns out to be "off the air" with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to be marked DOWN for a maximum of two weeks, after which the line should be removed from the node- list.)

I would suggest that if a node has advised you of a long-term but non-permanent down time (perhaps a move, or a major hardware failure) you might remove the number from the nodelist but reserve it and re-issue it without formality later.

You may distribute a portion of your workload to what Policy calls "routing hubs". Some nets call these "District Coordinators". You can get your DCs to do anything you would do *except* to hear policy complaints.

4.5 Making Available Policies, Nodelists and FidoNews

Policy states that you should obtain a new issue of FidoNews and a new nodelist difference file every week from your Regional Coordinator. Satellite feeds were unknown when Policy 4 was written, of course, but I still recommend that you get your nodediff from the RC. It provides a guarantee that no-one can tamper with or block our nodediffs.

Note that by Policy the nodediff is not required to be available until Saturday; occasionally things do go wrong but I assure you I'll be the first to know -- I don't want to hear complaints from you at noon on Friday!

Please get (from me or elsewhere) and make available the most recent version of Policy and make it available to the nodes in your network. You might also hold the previous 6 nodediffs so that nodes with a problem don't necessarily need to download the whole nodelist to repair a missed diff.

5 to 8.7.4

The next sections of Policy deal with RCs, ZCs, and so on. I won't waste your time discussing them.

9 Resolution of Disputes

9.1 General

(This is worth quoting in its entirety):


******
The FidoNet judicial philosophy can be summed up in two rules:

1) Thou shalt not excessively annoy others.

2) Thou shalt not be too easily annoyed.

In other words, there are no hard and fast rules of conduct, but reasonably polite behavior is expected. Also, in any dispute both sides are examined, and action could be taken against either or both parties. ("Judge not, lest ye be judged")
********

Policy makes it quite clear that it is YOUR job as NC to define "excessively annoying" in your network. Don't abuse your responsibility but don't shirk it either. That's the fine line you must tread.

9.2 Problems with Another Sysop

Any complaint that comes to you must demonstrate that the sysops have attempted to solve their problem directly. If the complainant can't show you that, reject the complaint.

NEVER, NEVER, NEVER answer a complaint in less than 1 week, and preferably take two or three. You'll find that amazing things happen if you do nothing, and you'll often find complaints being withdrawn.

Regardless of your personal feelings, remember that the person complaining really believes s/he has been wronged; listen sympathetically and rule kindly even if you are rejecting the complaint.

9.3 Problems with your Network Coordinator

If a node complains to me about your behaviour, my first response will be to forward you the message (usually with the name removed) and ask for your comments. This doesn't mean that I'm taking sides; I merely want to hear both sides. As above, often a node simply needs to hear the same message from the next level of *C, or needs some education that you haven't been able to convey.

Section 9.4 through 9.8

I think you can handle these without my interpretations! I would draw your attention to section 9.7, however.

9.9 Echomail

There is NO echomail policy. There is a Backbone Operating Procedures, but this is strictly a matter internal to the (three or four) backbone hubs. Give the problem to your NEC and stay out of it (see below).

A *EC is appointed by the *C at the same level, so an NEC is appointed by an NC, an REC by an RC, etc. The *EC is responsible to the *C as (once again) the *C is totally responsible for the smooth operation of his/her net/region/zone. Once you have appointed an NEC, get out of the way. If there is a problem with echomail such that the smooth operation isn't, find another NEC -- don't start fixing it or interfering with it. The intention is that 99% of us can't separate an NC response from an NEC response, and even if you're that 1% no-one else will be able to tell that you've done it!

The *C structure should not be involved in echomail (other than as a reader/writer). That means you, as NC, should not be part of the process that controls the distribution of echomail. There is nothing wrong with hubbing it (as long as it doesn't interfere with your NC duties), just don't get into the coordination side. You should particularly not get into the financial side of anything to do with echomail.

The rationale here is that we want to emphasize the amateur aspect of FidoNet, and if the coordinators are involved in the financial side it's really hard to claim that we have no monetary interest.

Additionally, you are *NOT* to use excommunication as a means of control concerning echomail. If a node has a problem with a cost recovery plan (CRP) or with an echomail distribution coordinator deal with inside those situations, don't start yanking node numbers.

It would seem to me that a wise NC arranges for an NEC (by appointment, election, divine inspiration, divination of internal organs, or whatever) and then gets out of the way. There are some situations where the size of the net or the particular situation may dictate that the NC and NEC be the same person -- if that's you, be very, very careful! I will not support an NC who mixes FidoNet and echomail matters. Very few echomail matters involve Policy complaints -- those that do must, of course, be dealt with by the NC but except for those, let your NEC handle it.

Please note: If your net owns equipment, be very clear that it is NOT FidoNet that owns it -- a FidoNet network cannot own equipment. Your local group of sysops may choose to do so -- that's not FidoNet's problem. As above, I don't want any of the equipment matters confused with FidoNet.

The remainder of Policy is case histories. Please read them carefully, as they form the basis of our interpretations.

I hope this rather long-winded interpretation has given you some idea of where I'm coming from -- feel free to ask questions, and be prepared for things to change. I'm not rigid about most of this and if someone can offer me a good reason to change my thinking I'm willing to do so.

In the end, it's the *C structure that interprets Policy -- you, as NC, make your own best interpretation. If a node doesn't like that, they can appeal to the RC, the ZC, and the IC, in that order. If you've done your best, you've done your job and no-one will be unhappy.

FidoNet's strength is in the diversity and well-meaning of its people. You won't hear it said very often (I'm sorry to say) but we appreciate the work the NC's do!

Cheers, Dallas
RC 17