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 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) .