Tillbaka till svenska Fidonet
English   Information   Debug  
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33888
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24094
FIDONEWS_OLD1   27031/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4393
FN_SYSOP   41678
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13598
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16069
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/22090
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   924
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/4786
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   1121
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   3205
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/13258
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/2056
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/4288
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   32677
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/2053
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
Möte FIDONEWS_OLD1, 49742 texter
 lista första sista föregående nästa
Text 25812, 236 rader
Skriven 2006-02-22 10:58:00 av Michiel van der Vlist (2:280/5555)
  Kommentar till text 25784 av Dale Shipp (1:261/1466.0)
Ärende: Elist mergers
=====================
 >>   Needed or not, it is a useful tool.

 MVDV>> Your opinion and YOUR choice to use it.

 >   My choice and the choice of more than 400 other moderators
 > who choose to enter information about their echos there

We don't really know if they all made a free choice do we? After all you guys
have been telling us for years that unlisted echos would be taken off the Z1
backbone. There is a disticnt possibility that many moderators only listed
their echos because they felt they had no choice.

Luckily we have freed ourselves from the stranglehold of e-list/backbone
kartel, but many moderators may not be aware of that yet.

 >>   They would need to coordinate once per month, prior to
 >> issuing the updated monthly list.

 MVDV>> Once a month is unaceptable. If I wanted to know who the
 MVDV>> moderator of an echo is, I would want to know who it is

 >    If you are that much in need of instant gratification then
 > you can do a direct query of the Elist data base

That only works if there IS a central elist data base. Which would not be the
case with synchronised zonal lists.

 > out in most cases that it has not changed since the last monthly
 > publication of the Elist.

 >    Personally, I think that such a desire is overkill.

I don't. If I have to wait a minth to get to know who the moderator of an echo
is, I may as well wait for the monthly rules.

 MVDV>> NOW, not a month ago. An out of date list is totally
 MVDV>> useless. 48 hour is the maximum I would consider acceptable.

 >   You are posturing for effect, and your stated expectation is
 >   unreasonable.

Then let me tell you that the one and only instance where I thought I migh have
some use for the echolist, I was put on the wrong foor because the informatio
was out of date without me being aware of it.

 > Do you insist that the telephone company send you an
 >   updated phone book every week?

No, but I do require that they offer an alternative to get up to date
information. And they do, I can call the directory information service. And
since a decade or so I can consult the on-line telephone directory.

Peter Witschi offered the service of requesting an up to date list.

 > That is equally absurd.

Information that can be uo to a month out of date is useless. I don't think it
is absurd to make that observation.

 >> Same as the ZCs who need to coordinate once per
 >>   week prior to issuing the weekly nodelist update.

 MVDV>> A compromise which is on the brink of being acceptable. It
 MVDV>> does not work all that well IMNSHO. Most NC's btw, offer
 MVDV>> actual up to date nodelist segments by file request.

 >   And your point is?

That - although most of the information may be quit static - uo to date
information is essential when it comes to resolving issues. For example we have
seen disputes over who was eligible to vote or who had wrote access to sysop
echos due to dircrepancies between the nodelists ars distributed in different
zones.

 > That nodelist segment does not change more than once per week with
 > respect to the nodes not in their net.

Wrong. My NC f.e. updates the nodelist whenever a change is made and that
actual up to date segment is available by file request.

 > The fact that it is available to you via request is no different
 > from the fact that the Elist information is available to you via
 > request.

With lists for each zone that are only synchronised once a month the up tp date
informationis NOT available.

 MVDV>> I don't think so. Actually the longer I think about it, the
 MVDV>> more I tend to  the POV that this system with a merged list
 MVDV>> and a keeper for each zone would not have worked well anyway.
 MVDV>> A ship needs one and no more that one captain.

 >   The merged list

I think we have a sematics issue here. A merged list is ONE list that came into
being by merging two or more that existed as a separete entity before the
merger. This is what Andrian Walker and Peter Witschi had in mind when Adrian
handed over his part to Peter, so that in future there woukd be ONE list for Z1
and Z2, handled by Peter.

What you refer to, a list for each zone, each maintained by a zonal list keeper
and monthly synchronised, is not a merged list. That is a system of
*synchronised* lists.

 > would have required cooperation, not one captain.

Yes, synchronised lists require cooperation. Something which is not one of the
strong points of FidoNet escpecially when it is interzonal. So it should be no
big surprise that it failed.

You blame it all on Peter. I see it different. We will never agree.

 > But Peter abandoned the list being kept in Z2 instead of being a
 > part of that cooperation.

It is difficult to cooperate with "my way or the high way"type dictators like
Thom.

But you are forgetting something. Peter did not "abandon" the list. He
*resigned* from the position of Z2 e-list keeper. The Z2 community could have
appointed or elected a successor. Instaed they decided we no longer had use for
a list on the zone level. So if there was any "abandonning" it was by the Z2
community as a whole.

 >> Or the reverse. All either of us can really say for sure is who
 >> we deliver the netmail to.  After that, it is out of our control.

 MVDV>> No, one can make arrangements with whoever one routes the
 MVDV>> message to, to use only certain routes. Alternatively a

 >    How absurd an expectation.  I should tell my uplink's
 > uplink how they should route mail.  NOT!

You can ask him how he routes mail. But who says you have to throw yourself at
the mercy of thet particular mail router? Simplt select one that will cooperate
with you on an acceptable route.

 MVDV>> trusted person in Z1 could take the position of routing
 MVDV>> moderator updates. This person would set up a direct link
 MVDV>> with the e-list keeper in Z2 and forward messages for the
 MVDV>> Z1 moderators.

 >    DUH!  That trusted person in Z1 would have been the person
 > who maintains the portion of the Elist in Z1.

No. The trusetd person does not maintain the list. He mereley forwards messages
from moderators to the e-list keeper.

 > Since the Elist keeper in Z2 abandoned his portion of the Elist,

Wrong. The Z2 community abandonned.

 > that means that Thom is the only one left.

He is the one left, so much is true. Does not mean he all of a sudden gets
promoted from zonal to glaobal list keeper.

 MVDV>> The cost and security with this setup would be EXACTLy the
 MVDV>> same as with separate Z1 and Z2 e-list keepers and a merged
 MVDV>> list.

 >   The cost is the same because it is the same method.

No, it is not. See above.

 MVDV>> I did. There is no gebral ban on encryption.

 >   You are not making sense, and what ever you meant to type
 > you are wrong.

I meant to write "there is no general ban on encryption".

 > Encryption is prohibited unless restricted to special networks.

Wrong. Routing encrypted messages is allowed when the sysops involved agree.

No different than routing unencrypted mail (except fpor host routed)

 > I have not heard of such networks existing in fidonet for
 > a number of years now.  Educate me by showing how you would
 > encrypt a netmail and send it to me,

That may be a tad difficult because you technically are a point, getting mail
to you depends on you picking it up somewhere. No one can "push" mail to you,
so I am severely restricted in finding someone to take the last step.

But.. getting encrypted mail TO you is not the issue. The issue is can you send
routed encrypted mail to the e-list keeper without having to make an
intercontinental call?

You can send encrypted mail to me by dropping it off at 1:123/500. he will
forward it to me.

 >> At the moment, I do not know of any node who would accept an
 >> encrypted routed netmail.

 MVDV>> I know plenty.

 >   Prove it -- send me an encrypted netmail.  I want to see the evidence.

What is needed is that you can SEND encryoted mail. You can send encrypted mal
to me. See above.


Anyway, coming to think of it: to update the echolist in a secure way, it is
not needed to encrypt the entire message. All that is needed is to encrypt the
password. As the password already is a meaningless string, it would merely mean
that it would be replaced y another string just as meaningless with the
difference that the "password" that is now in the masssage is no longer
sufficient to get the update processed. It also requires the key, which is only
known to the moderator and the echolist keeper. If a router does not object to
a message containing a password of "XyZzy", why would he object if it was
replaced by "A4fJq5"?

My point is that there are many solutions for the cost problem, But you do not
want to hear it, you find excuses for rejection. All you want to hear about is
a solution where the list is NOT in the hands of a Z2 e-list keeper.

 >>  Never mind, telling me how you would encrypt it in a manner that
 >> would allow me to decrypt it.

 MVDV>> There are programmes for that. Not more difficuolt to set
 MVDV>> up than the stuff needed to maintain an e-list.

 >    So tell us all how you would set it up.  Don't duck the question.

I am not going to write a tutorial on PGP. That would be reinventing the wheel.
The information is freely available at various places. PGP is freeware. I can
make it requestable from my system too if you want.

Plus that there are alternatives for PGP. Some of them freeware too.

Cheers, Michiel

--- Buy Danish
 * Origin: http://www.vlist.org (2:280/5555)