Text 2683, 290 rader
Skriven 2004-12-03 13:05:57 av Roy Witt (1:10/22)
Kommentar till text 2656 av Michiel van der Vlist (2:280/5555)
Ärende: Z1B <> EP1
==================
02 Dec 04 16:42, Michiel van der Vlist wrote to Matt Bedynek:
>> however, I guess it would be pointless in this zone since feed cuts
>> are subject to the agreement of he who moves the traffic and what some
>> entry on some sysop's echolist has on it;
MvdV> So someone who is cut off just moves to another link that does not
MvdV> recognise the e-list as final authority.
>> again, at least that is how things are run are here.
MvdV> I am starting to have my doubts. I keep hearing that the backbone
MvdV> systems will not carry echo that are not in the list and that they
MvdV> will use the list as the ultimate authority as to who is moderator,
MvdV> but no one will tell me who these backbone systems are. Where is
MvdV> the list of systems that actually operate in such a rigid way?
You're conversing with one individual (Matt) who was part of that scheme,
when it was being used. It was used by the Z1Backbone, a long, long time
ago. There were two sysops who first implemented the scheme, Bruce Bodger
and John Sylvester. You might recognize node 1:396/1 as a major echomail
mover during that time.
That practice was continued up until Bodger and Sylvester left Fidonet.
I believe it was Ross Cassell and Jeff Smith who took over the reins of
the Z1B when they left (Matty boy joining in later under someone else's
node number (1:106/1 wasn't always his node)). The Z1B grew to bigger
porportions and lived a while longer until a political battle ensued about
two years ago and the members of the Z1B split, Cassell deserting his
fellow mail movers and joining with the NAB (which it looks like he's
also abandoned most recently). The battle continued until the Z1B
organization was desolved, even though all remaining Z1B members continue
to move mail to this day.
You can also see the works of both sysops, Bodger and Sylvester in your
own EP1, as they were the people who wrote the original. Their version was
rejected by the *Cs of this zone and thus, they implemented a 'Service
Level Agreement'. (you can find a partial quote from it at the end of
this message)
I can't speak for the NAB, but I don't recall them ever having such a
scheme in place. In fact, they carry echoes that are not in the echolist
and they even carry echoes with no traffic in them. Which was the reason
why the Z1B issued echolist warnings to those echoes either not in the
list or were about to expire. Why I don't know because carrying a dead
echo has no traffic and therefore, doesn't put any burden on your mail
tosser, accept to take up room in the configs. When tossing, that tag
will pass through the tosser in a matter of nano-seconds when there's no
traffic to toss.
>> would similar behavior by a Z2 sysop be permitted by a Z1 mail
>> mover in Mr. Ceppa's echo? I wonder?
MvdV> I can't answer that. Dan said that he would not tolerate the way he
MvdV> behaved himself in his own echo though.
Ceppa has been a hypocrite in his own echo, not to mention others. Perhaps
he didn't read or even know about the responisbilities of a moderator as
outlined in the following document. At least on one occasion I recall that
he went for the throat of a sysop instead of the offending user. A lot of
what follows was changed when Sylvester exited Fidonet, but the moderator
section remained pretty much intact, c2002.
Ä Z1BACKBONE (1:10/22) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Z1BACKBONE Ä
Msg : #727 [727] Uns
From : John Souvestre 1:396/1 01 Mar 01 04:52:10
To : All 02 Mar 01 06:41:46
Subj : SLA_0103.Z1B
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
=====================================
== Zone 1 Backbone ==
== Service Level Agreement ==
=====================================
SLA_0103.Z1B - Mar 2001
===========================
___________ Snip! ____________O/___________________________________
O\
All Z1B Hubs agree to the terms of this document.
1.4 Z1B Relationship to FidoNet
___________ Snip! ____________O/___________________________________
O\
3.0 Moderators
=================
3.1 Moderator Identification
-------------------------------
The Z1B refers to the current EchoList in order to identify an echo's
moderator. As far as the Z1B is concerned, all individuals listed as
moderators or co-moderators of a particular echo are equal. In case of
disagreement, however, the moderator listed first has priority.
Moderators are encouraged to appoint co-moderators to assist them in
their duties and to stand in for them in their absence. This will ensure
that the echo is properly maintained, especially in the case of a
moderator who is frequently absent for long periods of time.
3.2 Moderator Responsibilities
---------------------------------
The responsibilities of a moderator of an echo which the Z1B distributes
are:
1) Seeing that messages in their echo correspond to the echo's
theme.
2) Updating their echo's listing in the Echolist at least every six
months.
3) Preventing the distribution of their echo from interfering with
the operation of the Z1B.
4) Must be accessible via netmail through known channels.
5) Seeing that messages in their echo do not violate the standards
set in Section 4.
When moderators place their echoes on the Z1B they must realize that Z1B
Hubs distribute publicly available echoes and that the job of enforcing
any kind of access restrictions remains with the moderator. These
restrictions, as well as the echo's rules, are usually available in the
EchoList so that any Sysop interested in the echo may review them prior
to actually carrying the echo on his or her system.
3.3 Moderator Tools
----------------------
The Z1B provides some "tools" to a moderator in order to help him/her
carry out their responsibilities.
If a moderator believes that a node is violating an echo rule, he/she may
request the feed to that node be severed. This request is made in
written form (netmail), to the Z1B Hub feeding the offending node, with a
copy to the offending node. It is recommended that a copy also be sent
to the node's NEC so that he or she is aware of such problems in the net
and can provide information and assistance.
Some important points to remember regarding feed cut requests:
1) Feed cuts should be initiated with an effort to cause the least
amount of disruption to the echo.
2) In most cases, the main goal of a feed cut is to remove a REPEAT
offender who is likely to cause future echo disruption.
3) Echo rule offenders are, in most cases, PEOPLE - not systems.
4) SYSTEMS should not be cut until efforts to remove the PERSON have
failed. Moderators should attempt to resolve problems as close to
the root of the problem as possible, i.e., user first, SysOp
second, hub third, etc.
5) Feed cuts at the zone level are taken very seriously. Only use
them as a last resort after all other means have failed. Have
proper documentation ready to support a link cut request at the
zone level showing that all other efforts have failed.
6) Feed cut requests are just that - requests. Communications should
be polite and not demanding as you are REQUESTING help from
another system.
3.4 Echo Addition
--------------------
The Z1BC adds an echo to Z1B distribution when all of these requirements
are met:
1) The moderator lists the echo in the EchoList. See the EchoList
FAQ for information about how to do this.
2) The moderator requests that the echo be distributed by the Z1B.
The request should be sent from one of the moderator addresses
listed in the EchoList, via one of the following methods,
preferably "A".
A) Echomail: To "Z1B", in the Z1BACKBONE echo
B) Netmail: To "Z1B", at the Z1BC's FidoNet address
C) Email: To the Z1BC's Internet address, subject "Z1B"
The body of the request should consist of a current copy of the
EchoList listing for the echo. This could be taken from a recent
message from the EchoList (netmail, email or echomail) or be an
excerpt from the current EchoList itself.
The echo is then listed in BACKSTAT.Z1B as requesting addition.
3) Within one month of being initially being listed in BACKSTAT.Z1B,
two Tier 1 or 2 Z1B Hubs and/or RECs request that the Z1B
distribute the echo. The requests should be sent via one of the
following methods, preferably "A".
A) Echomail: To "Z1B", in the Z1BACKBONE echo
B) Netmail: To "Z1B", at the Z1BC's FidoNet address
C) Email: To the Z1BC's Internet address, subject "Z1B"
The requests are noted in BACKSTAT.Z1B.
If two requests are not forthcoming, prior to the one month
expiring the moderator may request a one month extension from the
Z1BC.
The echo is then added to BACKBONE.Z1B and this is noted in BACKSTAT.Z1B.
A welcome message is sent in the echo to help establish links. At this
time any private links to the echo should be switched to the Z1B.
3.5 Echo Removal
-------------------
The Z1BC removes an echo from Z1B distribution when any of these
situations occur:
1) The echo is not listed in the EchoList. The echo is first listed
as "not in EchoList" in BACKSTAT.Z1B for up to 3 months, then it
is dropped entirely. During these 3 months, bi-monthly warning
messages are posted in the echo alerting the moderator and the
users as to the echo's status. If at any time during these 3
months it is re-listed in the EchoList then it's status is
restored.
2) Unconditionally when the moderator sends a direct request to the
Z1BC that the echo be removed. The request should be sent from
one of the moderator addresses listed in the EchoList, to one of
the following:
A) Echomail: To "Z1B", in the Z1BACKBONE echo
B) Netmail: To "Z1B", at the Z1BC's FidoNet address
C) Email: To the Z1BC's Internet address, subject "Z1B"
3) The moderator fails to properly carry out his responsibilities
(see Section 3.2).
4) The traffic level in the echo falls below 2 messages for any
month. The echo is first listed as "low traffic" in BACKSTAT.Z1B
for up to 6 months, then it is dropped entirely. If at any time
during these 6 months the traffic level rises to or above 5
messages for any month then it's status is restored.
The Z1B drops echoes when the traffic level falls below a
minimum:
A) To encourage the formation of new echoes, like pruning
dead branches off a tree.
B) To save the SysOps and users from the frustration of
setting up areas only to find that they are dead.
5) When it is decided by a two-thirds vote that the distribution of
an echo is not in the best interest of the Z1B.
All changes in status of echoes are noted in BACKSTAT.Z1B.
___________ Snip! ____________O/___________________________________
O\
================================== End ==================================
-+-
+ Origin: Southern Star - sstar.com - V.32b/V.34+ - 504-885-5928 -
(1:396/1)
--- Twit(t)-Filter Tossed v2.3 (2000)
* Origin: Flying \A/ Ranch, Santa Ysabel, CA (1:10/22)
|