Subj : proposed new nodelist                                    [2]
To   : Peter Knapper
From : Jasen Betts
Date : Tue Jul 16 2002 02:16 pm

Hi Peter.

15-Jul-02 21:17:38, Peter Knapper wrote to Jasen Betts


PK> Hi Jasen,

PK>> A new format YES, but as an addition to the current nodelist, NOT
PK>> a replacement

JB>> Why not duplicate the nodelist information in the new file, it
JB>> would make its use easier ...

PK> Because its not needed.

true.... I see that now. there's no need to improve the nodelist for
internet nodes, but a tool to "downgrade" the nodelist so that POTS
mailers that have problems with some current conventions can make sensible
choices when given crashmail for IONs.

JB>>> Leave them broken? why?

PK>> The current Nodelist is NOT broken to me.

JB>> you are not all of fidonet...

PK> I never said I was, however I am a member who has no problems with
PK> the current Nodelist data, I just understand that it will not
PK> always work for some.

And that's valid not motivation to fix it?

JB>> (do you really want me to list my gripes with what is again?)

PK> Well never having seen your previous comments I have no idea what
PK> you are talking about. If you are talking about the way people
PK> have mangled Nodelist entries to do something they wanted and
PK> "broke" the way the Nodelist works for others, then I am not
PK> surprised.

yeah, basically that.

JB>> but I see no way that this plan of yours can benefit users of
JB>> existing software.

PK> Its not designed to, it is only for IP nodes, the PSTN segment
PK> always has the nodelist to satisfy their needs

It won't benefit users of existing ip fido software either.
but it does seem to be a good addition to fidonet.

JB>> like the nodelist?  like echomail routing? you're relying on
JB>> others every day when you use fidonet.

PK> So minimise the amount you have to repy on them.

I favour maximising the reliability of the rest of fidonet...
same goal different strategy.

PK> One thing a lot of people forget is that just about the entire
PK> Fidonet Backbone is moved using IP these days. All these IP nodes
PK> work using something other than Nodelist info. Amazing how they
PK> manage to do this without using the Nodelist.......;-)

true, the nodelist sn't used for moving echomail (except in some
errorchecks)

JB>> And this is not somethoing than cold be implemented overnight.

PK> Exactly the reason why it needs to be worked out properly and
PK> agreed with as many Fidonet people as possible, before something
PK> is started

what I mean is that intiallly most IP nodes won't support this...
it'll be a gradual change-over not a sudden one, and there's no way that I
can for existing IP mailers to send crashmail without using a nodelist
unless they are modified in some way...

JB>> The nodelist is already in the control for the *C structure, it's
JB>> their main reason for existing (as i read P4), if they kick you
JB>> out of the nodelist a server on ypur PC will do you not good
JB>> whatsoever.

PK> Something somewhere has to define what makes up Fidonet so others
PK> can get a feel for what Fidonet really is. The Nodelist is the
PK> current master list. The Nodelist and the DNS records could be the
PK> furture master list..

yeah, that would work.

PK> If you get kicked out of the Nodelist, then you have exactly the
PK> same procedures available to rectify that (via a Policy complaint
PK> to the *C structure)

PK>> The end node then has the ability to manage THEIR membership as
PK>> they wish, OR use a "shared" server

JB>> Is this about some *Cs disallowing certain nodelist entries
JB>> (mainly those notconforming to FTS0005) they claim to do this
JB>> because those "bad" entries cause problems with some systems.

PK> Nothing like that at all, its just another option for distributing
PK> responsibility

ok... I was wondering what you were trying to achieve with this scheme
I think I understand it now.

JB>> don't worry about that, it's alreadly lost.

PK> No it isn't. It just needs putting back on the rails by giving
PK> those that made the "invalid" changes the option to correct the
PK> mistakes

Good luck with trying.

PK>> No. The Mailer uses the Nodelist to perform the action defined by
PK>> the Operator. The decision to Host Route, Network Route, Crash or
PK>> Hold mail, is all with the Sysop. It is up to the Sysops(s) to
PK>> ensure their system has the best chance possible of succeeding

each time I read that it makes more sense.

JB>>> however the present nodelist doesn't evem provide a way fr a

PK> If I wish to crash a Netmail to someone, and a crash poll fails
PK> for a reason I can't determine remotely, I then Host Route that
PK> Netmail. The most likely reason for Crash failing that I have
PK> found, is because the Nodelist entry is not strictly telling the
PK> truth for some reason. This is becoming more and more of the real
PK> situation these days, which is why I usually Route all my Netmail,
PK> I don't usually bother to even try Crashing it

ah.....

JB>> There are HUBS (and NCs and atleast one RC) with no published
JB>> POTS connection.

PK> Then (IMHO) strictly speaking, it sounds like the *C above them is
PK> not doing their job, an *C should ALWAYS be PSTN contactable
PK> somehow to be compliant with P4.

it does make some sense,
the argument against it is that it's anacronistic, which also makes sense
but so is the whole concept of zones nets for IP nodes,

Requiring Hosts to be POTS capable is unlikely to be a permanent solution
unless IP nodes can exist without a host.

PK> I believe this is most important
PK> for NC's, and also why it can be a huge bone of contention with
PK> some people. I also understand that some Zones may view this
PK> differently

JB>>> how's a mailer supposed to know that it's the same destination
JB>>> with just a different "name"

PK>> But its not the same destination, its a different node number.

PK> < text deleted >

JB>> some of them _may_ be one sysop running multiple fido systems but
JB>> most of them appear to me to be the same BBS but with too many
JB>> connections to list on a single nodleist line (either line
JB>> length, flags conflict, or some other cruft is forcing them to
JB>> list multiple times)

PK> Initial appearances can be very deceptive. A different type of
PK> modem may require different flags to be shown, or hours of service
PK> for different reasons.

yes I understand many of the reasons. In my opinion it would be good if
they could put all that in a single nodelist entry... obviously doing that
without losing functionality would require major changes to the nodelist
format.

JB>> I'm aware of 1900 others.

PK> Have you considered that you may be too picky over other peoples
PK> reasons for doing this?

I'm not saying they shouldn do it, I'm saying to could be done better.
with a bnew nodelist format.

PK> As I described above, and they are being used like that.

The main problem I see with multi-listed systems is the mailer being able to
recognise it as multi-listed and pick the most appropriate node so send the
mail to.

-=> Bye <=-
---
# Origin: Sturgeon's Law:  90% of everything is crud. (3:640/531.42)
* Origin: Baddog BBS (1:218/903)