Subj : linked
To : Frank Vest
From : Peter Knapper
Date : Mon Dec 16 2002 08:24 pm
Hi Frank,
FV> No reason to re-invent the wheel. The wheel (Nodelist) is fine. The
FV> wheel (DNS) is fine. The other wheels are fine too. The problem is
FV> that there are too many wheels? How the heck do we steer this thing?!?:-)
So you are a unicycle expert then?......;-) My view is that the nodelist (the
Captain) steer's the ship, however I also do not see the captain doing all the
work, when appropropriate, he uses the right man for the job.
FV> Fidonet still needs the Nodelist. IMHO, it always will. When Fidonet
FV> doesn't need its own Nodelist, Fidonet will not be Fidonet.
I don't think the NEED for the Nodelist is in dispute, its just what tasks are
best left to the Nodelist, as opposed to what tasks are passed elsewhere...
FV> There's the key. Routed. If the Node is not listed in the Nodelist or
FV> the DNS, the message is routed.
Thats not quite how I view it. My scenario runs like this -
1. If the Node is NOT Nodelisted, then it is bounced back to the sender.
2. If pre-existing arrangements are in place, then they will be used.
3. If the Node is Nodelisted, AND uses BinkP (IBN), then I will attempt to
deliver direct using BinkP.
4. If the node is Nodelisted, PSTN and local, then I will either place it on
HOLD (by arrangement), attempt to deliver direct, otherwise I Route that
traffic.
5. In all cases if DIRECT connection fails, I will Route the mail.
This is how its worked for me for many years.
FV> If the default DNS is fidonet.net, then all Nodes that wish to be
FV> contactable would need to be listed in the fidonet.net DNS?
IP Contactable?... then yes. It is up to the destiniation node to decide if
they wish to be listed (and therefore contactable) or not.
FV> Ok. The majority rules... no matter what?
No, not majority, and certainly not "no matter what"... Its simply a case of
those that have something that works well, will continue to use it until they
see good reason to not use it.
If Fidonet implements something that ends up competing with existing setups,
then Fidonet will be the loser, because regardless of "standards", Sysops will
continue to use something that works better for them, than the supposed
"standard" they are asked to implement, UNLESS there is some clear reason why
the "something new" is better...
PK> Are we going to
PK> totally ignore the way a vast majority of Fidonet IP users appear to
PK> wish to work? Surely this should tell us something?
FV> How many NODES of the 9000+ in Fidonet use fidonet.net?
No idea sorry, that would need quite a bit more work than what I have done, as
I said above, it was only a quick analysis.
PK> However, if you are NOT suggesting to put <some.domain> into the
PK> Nodelist, then the MOST practical place left is the DNS, which is
PK> fine with me.
FV> DNS is fine as a fallback default. I just think that there needs to be
FV> some indication in the Nodelist that the Node is IP capable.
Agreed...
FV> For POTs or IP, Fidonet must have a Nodelist and entries for the
FV> Nodes in the Nodelist telling where to "call" to contact that Node.
Agreed for PSTN (I prefer calling POTS nodes PSTN nodes because PSTN works for
both POTS and ISDN nodes, whereas POTS is not strictly valid for ISDN nodes
because they use an enhaced "POTS" type service that is not always compatible
with ISDN).
However for IP nodes, this is part of the problem. The REAL issue seems to be
over HOW this could be done without breaking anything. Using the DNS means
those issues are almost non-existant (IMHO).
FV> I hope we never get to the point of not needing a Nodelist.
I can't see Fidonet existing without something like the Nodelist, either in its
current form, or something completely different, however yes, I think "the
Nodelist" will always (see next paragraph) be part of Fidonet.
As a small diversion here, if you can see a bit into the future, say when
nothing but IP is used for transport within Fidonet, do you think you can see
where things might end up? My own thoughts in this area are... interesting...
to say the least. I am not sure a lot of people have given it much thought
though (some of them might have a heart attack.......;-)).
Now back to our regular program...
PK> No, Fidonet needs to settle on an IP transmission standard fairly
PK> quickly (probably based on the existing BinkP protocol), similar to
FV> How? There are too many already. binkp, ftp, telnet. Of which, telnet
FV> seems to handle the old POTS protocols.
How? Easy, Fidonet MUST set down an IP standard, the same as it did with the
PSTN. All the other "flavours" of IP can fit around that standard, but defining
an IP standard would actually help Fidonet get things IP going better than they
are now. Its the variations in IP connectivity that are causing the issues over
how to document what it being done...
PK> the PSTN standard. We currently use several flags to help the PSTN
PK> side of things (V24,V32,V42b, etc), a few similar ones for IP should
FV> The flags you mention are not protocol flags. They are connection
FV> ability flags.
No, the PSTN flags above really are protocol flags, its those protocols that
define HOW 2 nodes will be able to use the telephone line between them. Thats
why we currently have several IP flags, they match the PSTN protocol flags at
the basic connection level. With PSTN, the FLAG's are used down at ISO layer 2
for Dial-up connections. With IP (which is ISO layer 3), the FLAG's define the
ISO layer 4 standard for the connection. Its the same functionality, just at
different layers of the protocol stack...
FV> Flags for DSL, cable modem, dial-up isp and such would fit better
FV> in your above statement.
Nope, because all those define is the MEDIA that is used by the Node for
connection to the Internet. With PSTN the phone line was the begining of the
transport layer, however with the Internet, IP fills that same role. Once the
IP layer is established, the Media doesn't matter in the slightest.
Cheers................pk.
--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)
