Tillbaka till svenska Fidonet
English   Information   Debug  
GET_INFO   105
GOLDED   0/408
HAM   0/16052
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22010
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   898
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4784
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1117
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   2756
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13055
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2055
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4276
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   28277
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2008
DOS_INTERNET   0/196
duplikat   6000
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33803
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   23518
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12841
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4186
FN_SYSOP   41525
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13570
FUNNY   0/4886
GENEALOGY.EUR   0/71
Möte IC, 2851 texter
 lista första sista föregående nästa
Text 1506, 185 rader
Skriven 2006-05-30 08:31:00 av Michiel van der Vlist (2:280/5555)
   Kommentar till text 1499 av Philip Lozier (1:267/169)
Ärende: Situation on R2:50
==========================
Hello Philip.

29 May 06 11:56, you wrote to me:

 MvdV>> The NC has an obligation to see that mail delivered at the host
 MvdV>> gets to the nodes in the net.

 PL> No... the NC has the obligation to make "arangements" for delivery.

... and see that these arrangements are carried out and have the desired
effect. As I see it, this amounts to "seeing" that the mail is delivered.

Note that "seeing" it is delivered does not necesariky imply he hast to deliver
it himself.

 MvdV>> What is does *not* say is how it gets from the host to the leaf
 MvdV>> nodes. In particular it does not say who bears the *cost*.  A
 MvdV>> glaring omission I say.

 PL> That was handled in my net years ago in the POTS only days... (see
 PL> below).

Same here. It was "handled". That does not nullify the omision.

 MvdV>> The only explanation I can come up with is that the writers of
 MvdV>> P4 wrote it from the position that there *is* no cost. Which
 MvdV>> was true for most if not all of the US and Canada at the time
 MvdV>> of writing of P4.

 PL> I can't speak for the writers of P4, but taking into account that a
 PL> net was basicly an area code,

Not so. Nets are based on "areas of convienent calling". Such areas may or may
not coincide with the areas defined by area codes.

 PL>  even today it doesn;t ring true that a call within an area code has
 PL> no cost, and it definately DID have a cost out of your "exchange" area
 PL> with an area code at the time,

So in that case the "areas of convenenient calling" do not coincide with the
areas difined by the area codes.

 PL> I don;t think that was the position they wrote it from.  It depends on
 PL> the plan a person has.

Fact remains that the writes of P4 neglected to address the matter of cost of
transport within the net.

 PL> Even today, unless on the "unlimited regional" plan (calls within an
 PL> area code but outside you "local" calling area) some calls can cost
 PL> more in your own area code than calling overseas.

So obviously such calls are not within an "area of convenient calling" and
therfore a net should not be so large as to cover an entire area code where
such a situation exists.

 PL> CRP was only for echomail and files, and if you weren't involved in
 PL> the CRP you were OBLIGATED to call the host system once a day for your
 PL> HRN if you were outside the then NC's calling area.

Makes sense, but it *isn't covered by policy.

 PL> Back then too, remember, almost NONE of the FidoNet software was even
 PL> free.  While a hobby, it cost money to participate.

True but beside the poibt. Which was: P4 does not address the cost of
transporting mail within the net. While there is an obligation to get HRN to
its desitination.

 PL> The obligation for cost is on those who wish to participate, then
 PL> -and- now.

Again: sounds reasonable, but it is not what policy says in regard to HRN.

 MvdV>>>> So it does not matter who calls who when it comes to the
 MvdV>>>> host's obligation of delivering incoming routed mail.

 PL> Yes it does.

Under the assumption of free local calls it does not.

 PL> I'm a host.  If in the event I ever again have a POTS node, and that
 PL> node is somewhere that would cost me money to send anything to them,

My theory is that the writers of P4 went from the tacit assumption that it does
*not* cost money.

 PL> it will be their obligation to poll ME within a preset timeframe every
 PL> day.

Such a dictatorial edict has no basis in policy. Nodes have to be available to
recive mailk, at least during ZMH, there is no requirement for nodes to poll
their host or designated hub at regular intervals.

Which is the heart of my argument: policy *fails* to address this issue.

 PL>   I will provide the HRN, but you will poll for it regularly, lest you
 PL> get billed monthly for any calls out to you.

And if he refuses to pay you will strike him from the nodelist? I don't think
that will hold in an appeal.

 MvdV>> The intention obviously is to get the mail to its final
 MvdV>> destination and in order to do that *someone* has to make a
 MvdV>> call.

 PL> Ever hear the old term "sneaker mail"... for all of what P4 says,
 PL> netmail can be copied to a floppy and "delivered".

Yes, I know of that method, I have used it myself in the past. ;-)

Whatever, there is still cost involved...

 MvdV>> The glaring ommission of not saying *who* has to make the call is
 MvdV>> the telltale evidence for the tacit assumption of free local calls.

 PL> I don't think so... the ommision of that, and the inclusion of "make
 PL> arangements" seems to leave it up to the individual sittuations of the
 PL> individual nets.

Which is ok when it involves just a "free" local call, but it has caused
serious problems in situations where local calls are not free. (Such as in most
parts of Europe)

 MvdV>> We have adapted but not without some problems. Obviously it is
 MvdV>> unreasonable to demand that the host makes all the calls to
 MvdV>> deliver the mail. That would put *all* of the coast on one
 MvdV>> person. So we went by the rule: the leaf nodes have to call
 MvdV>> their host or hub at regular intervals to pick up mail.
 MvdV>> Prefereably every day, but once a week at minimum.

 PL> Absolutely, but considering how slow mail movement used to be, once a
 PL> week was insufficient in the views of the powers to be locally.

And again here lies a source of problems. The "powers that be" may consider it
insufficient, but what if the node says "once a week is good enough for me abd
if *you* think it is not, you call me.". There is no obligation in policy that
nodes should make regular calls. In fact there is no obligation for a leaf node
to make any outgoing calls whatsoever except for the initial call to apply for
the node number. There is ony the obligation to be available to *receive*
calls.

 MvdV>> There *have* been a few cases here in The Netherlands were
 MvdV>> sysops refused to comply. Nodes *have* been removed from the
 MvdV>> nodelist for not picking up mail for an extended period of
 MvdV>> time. (A couple of month).

 PL> Here, after "a couple of days" of not polling, a node was in question
 PL> of being down.

Definitely wrong. As long as a mailer answers incoming calls, there is no
ground to mark a node as down.

 PL>   Contact was attempted to be made.  If contact was made, the
 PL> sittuation was dealt with on an individual case by case basis.

Sure it was delat with. Outside policy and in many instances in vio;lation of
policy.

 PL> If contact couldn't be made, the node was DOWN in the next
 PL> nodelist... two weeks later removed if the node didn't restore contact
 PL> of their own accord.  It is, after all, a duty of the node to let the
 PL> host know if they'll be down for more than a few days.

True, but beside the point. The node has to be available for receiving mail,
but ther is no obligation to give "life signs".

 MvdV>> Of course that is history. The few remaining POTS only nodes
 MvdV>> poll at regular intervals and for IP it does not matter as the
 MvdV>> calls *are* free.

 PL> Yup... so all a moot point really.

It is now but it sure was not in the past. As I said we had a seven year cost
sharing war related to this issue. It might have been avoided had the makers of
P4 paid more attention to the situation outside Z1. In particular the fact that
local calls are not free.

 PL> Just thought I'd share how it was done here, based on local
 PL> interpretation of policy, in the old days.

Michiel

--- GoldED+/W32-MSVC 1.1.5-b20060315
 * Origin: http://www.vlist.org (2:280/5555)