- Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #461 [785] From : Ward Dossche 2:292/854 21 Aug 97 12:13:04 To : All 22 Aug 97 06:09:06 Subj : IP-access ------------------------------------------------------------------------------- Colleagues, This is a genuine attempt at suicide! More and more nodes are offering IP-access yet cannot be listed as such short of starting another flame-war in selected sysop-conferences. I can see the "debate" about flags and how to structure the IP-number etc... We can shortcircuit this by putting IP somewhere of it's own yet not interfering with regular fido-operations. What if we create a zone-7 f.e. and stuff all IP in-there while updating a zone7-segment parallel with (or in) the nodelist? If the other zones don't care we can still run like that overhere in zone-2. Right, Rome wasn't built on 1 day, and maybe we'll need an IP-code-of-conduct etc... but we should start moving. several people have advocated it already, this is a new technology we cannot embrace while observing policy so what do we think about this proposal? Please mark the word "proposal"! OK? \x/ard --- DB 1.58/001877 * Origin: Ladies and gentlemen, Elvis has left the theater (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #467 [785] From : Mario Mure' 2:335/533 22 Aug 97 18:59:04 To : Ward Dossche 23 Aug 97 18:19:04 Subj : Re: IP-access ------------------------------------------------------------------------------- In a message dated < 21 Aug 97 12:13:04 >, addressed to All about < IP-access >, Ward Dossche wrote: WD> What if we create a zone-7 f.e. and stuff all IP in-there while updating WD> a zone7-segment parallel with (or in) the nodelist? If the other zones WD> don't care we can still run like that overhere in zone-2. I *fully* agree with your proposal and suggest to adopt the scheme used in regions 50 and 46 for IP flags. WD> Right, Rome wasn't built on 1 day, and maybe we'll need an WD> IP-code-of-conduct etc... but we should start moving. several people WD> have advocated it already, this is a new technology we cannot embrace WD> while observing policy so what do we think about this proposal? IMHO, IP-technology is the future of our network. Please, don't be shortsighted in this matter or there won't be *any* future for Fidonet... WD> Please mark the word "proposal"! OK? :-) Ciao ! /mario/ mure@sistemia.it --- DMreply v2.0 * Origin: Djemaa El Fna (2:335/533@fidonet) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #468 [785] From : Jan Ceuleers 2:292/857 22 Aug 97 17:56:10 To : Ward Dossche 24 Aug 97 18:40:22 Subj : IP-access ------------------------------------------------------------------------------- --> Note: Forwarded (from: ENET.SYSOP) by Jan Ceuleers using timEd. Originally from Jan Ceuleers (2:292/857.0) to Ward Dossche. Original dated: Aug 22 '97, 17:19 I quote Ward Dossche: WD> What if we create a zone-7 f.e. and stuff all IP in-there WD> while updating a zone7-segment parallel with (or in) the WD> nodelist? If the other zones don't care we can still run WD> like that overhere in zone-2. While this is basically a good idea, it creates a number of problems (most of which are silly, but please bear with me). - Who will the *Cs of this zone be? - What policies will this zone be administrated under? The geographical clauses are hard to apply. - Who will the *ECs be? - Will nodes exist that only have a zone 7 node number? - Since zone 7 will geographically overlap all other zones, there will be a very large number of gateways between zone 7 and each of the other zones. This may create serious problems with the exchange of echomail (SEEN-BY stripping etc.). A few thoughts of my own on this: - In order to minimize echomail gatewaying problems, I'd suggest that zone 7 addresses should not be used in echomail by nodes other than leaf nodes. This obviously means that nodes that have echomail downlinks must also have an address in one of the other zones (and hence be reachable by modem or ISDN). - In order to avoid all of the above problems completely, here's an alternative proposal: create an additional net in each region which isn't included in the 'main' nodelist. A separate nodelist is compiled in parallel containing only those nets. Except for the ZCs and RCs, the main nodelist is completely disjoint from this other nodelist. The advantage of this approach over the other obvious possibility (1 such extra region per zone) is that administration and routing are more straightforward. The fourth option is the Russian-one (I think): the creation of nodes in existing nets. This has the disadvantage that potentially each *C has one or more IP nodes in his shadow segment, whereas he isn't necessarily IP-capable himself, so that he can't verify the reachability of those nodes. Granted: that same problem already exists today due to the mutual incompatibility of a lot of ISDN and modem gear. All options other than your proposal (i.e. zone 7) pose the problem of trying to decide in which region or net a given IP-only node should be listed: trying to apply the geographical rule is difficult to defend. I guess the gist of my reaction is that I feel that we should ask ourselves at which level the IP shadow nodes should be introduced: in a shadow zone, in a shadow region in each zone, in a shadow net in each region, or just as shadow nodes in each net? Each option has pros and cons. Jan ___ timEd-A10a - Origin: Experimenter Board, Antwerp, Belgium (2:292/857) --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #470 [785] From : Jan Vermeulen 2:280/100 24 Aug 97 17:15:02 To : Jan Ceuleers 25 Aug 97 18:42:04 Subj : IP-access ------------------------------------------------------------------------------- Quoting Jan Ceuleers on Fri 22 Aug 97 17:56 to Ward Dossche: jc> While this is basically a good idea, it creates a number of jc> problems (most of which are silly, but please bear with me). I have no IP-access right now, so what I am going to propose here may not be the ideal solution. Nevertheless I think that this may work. Can't we have an IP-List per net, with entries roughly in the form of the St Louis nodelist: key,site,town,sysop,phone,baud,flags where: key = a key as in the nodelist, except Hub or Pvt node = the node number as in the nodelist site = the site name as in the nodelist town = the town as in the nodelist sysop = the sysop as in the nodelist phone = either nnn-nnn-nnn-nnn for the IP number or (in case of a ZC, RC or Host having no IP-number): -Unpublished- baud = 300 to keep MakeNl happy; or anything else than 1200, 2400, 9600 and add that rate to the MakeNl control file flags = whatever is needed The network lists would be compiled into region lists, region lists into zone lists and zone lists into the global list by the same software that is already in use. Most nodelist compilers will accept such a list to be compiled in some way or other into the same database as the 'standard' nodelist and show the complete set of connection possibilities of any given site to the mailer software and the sysop. Also, future integration into the FidoNet nodelist would still remain a possibility. -=<[ JV ]>=- * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #471 [785] From : Pedro Lima 2:362/21 24 Aug 97 06:57:56 To : Jan Ceuleers 25 Aug 97 18:42:04 Subj : IP-access ------------------------------------------------------------------------------- JC> I guess the gist of my reaction is that I feel that we should ask JC> ourselves at which level the IP shadow nodes should be introduced: in JC> a shadow zone, in a shadow region in each zone, in a shadow net in JC> each region, or just as shadow nodes in each net? Each option has pros JC> and cons. First of all, I thank you for your message, since it corresponds pretty much to my own thoughts on the matter. From the several solutions you suggested, I think that creating specific nets to contain the IP nodes would be generally adequate. This may not be a practical solution, however, if the number of IP nodes in a region doesn't justify the formation of a network... On the other hand, and that's the main reason for this reply, I'm horrified with the perspective of having "second rate nodes", and that would happen if we admitted them as shadow nodes, or nodes in a shadow something, because they simply wouldn't belong to FidoNet. The Z7's proposal also has this problem. I apologise for being political, but when the rules of a community stop serving the community and the community begins to serve the rules, then there's something *very* wrong. The best solution is to change the rules, but if this isn't possible, then the community has to break the rules if it wants to progress. This specifically means that is not the individual who should break the rules. I think this is the FidoNet situation. P4.07, for all the merits it may have, it also has dramatic flaws in what concerns adequacy for the community it regulates, and I think this is a common idea throughout FidoNet sysops (I'm not saying everyone agrees with it, though). Since we seem unable to change a comma in Policy, then we have to break it if we want to go ahead. But this can only be done if there's a general consensus on the action to be taken. I think network or regional dimensions aren't really enough for such an attempt to succeed, but I'm convinced that something at Z2's dimension could manage to do it. So, I'd propose that Z2 nodes are consulted on if they think IP nodes can be part of FidoNet, although that would breach some of FidoNet regulations. I apologise to Ward for taking the liberty, but I'd suggest he initiates this consultation throughout the zone. I'd also suggest the same mechanism to be used in the other zones as well, but I think Z2 is the real key for it. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #473 [785] From : Mats Wallin 2:201/329.11 25 Aug 97 12:33:42 To : Jan Ceuleers 26 Aug 97 08:58:48 Subj : IP-access ------------------------------------------------------------------------------- JC> - In order to avoid all of the above problems completely, here's an JC> alternative proposal: create an additional net in each region which JC> isn't included in the 'main' nodelist. I have given this some thought also, and it would IMHO be better to include TCP/IP nodes in their own net in each region, then to have a special zone for them. However, I do not agree that this net should be left out of the main nodelist. It has to be included in the main nodelist if these nodes should be considered FidoNet members, and much more important, if any other system should be able to route netmail messages to them. Remember, many systems are running netmail trackers that would bounce a message to a node in an unlisted net. IMHO, the host of a "TCP/IP-net" should be required to support atleast analog modem calls, as well as TCP/IP sessions, to make it possible for any system in FidoNet to crash a mail for any node in that net via the host. One other thing I've considered is that a TCP/IP system that would be allowed in this net should be required to, just as any other nodes in FidoNet, answer mail sessions during atleast ZMH. Since I don't really see why a TCP/IP node would be able to answer only during ZMH, they should probably be required to answer any time during the day. Another question is what type of mail sessions these nodes should be required to support? Since this is FidoNet after all, I guess that the minimum requirement probably should be a FTS-1 session via Telnet/Vmodem. But I'm not sure about this. Some type of standard FidoNet mail-session should probably be required though. Mats mw@defsol.se --- * Origin: Definite APXw (2:201/329.11) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #479 [785] From : Jan Ceuleers 2:292/857 26 Aug 97 17:49:58 To : Pedro Lima 27 Aug 97 07:35:48 Subj : IP-access ------------------------------------------------------------------------------- I quote Pedro Lima: PL> On the other hand, and that's the main reason for this PL> reply, I'm horrified with the perspective of having "second PL> rate nodes", and that would happen if we admitted them as PL> shadow nodes, or nodes in a shadow something, because they PL> simply wouldn't belong to FidoNet. The Z7's proposal also PL> has this problem. I quite agree with your reasoning. However, for IP nodes to be able to co-exist with modem and ISDN nodes in the same nodelist, I feel it must be possible for existing nodelist compilers (or other software that reads the distribution nodelist) to be configured to prevent calls being made by modem or ISDN nodes to IP-connected nodes (and possibly vice-versa as well, but there I'm not so sure that we need to require that it be possible with _existing_ software). I must say that I haven't looked at the Russian initiative for some time and that I don't know how the address of the node is listed, but if the phone number field is used for that purpose, and if it contains an IP address (as opposed to an fqdn; this could save $100 per year in DNS charges) then it's conceivable that there is a collision between this IP address when interpreted as a telephone number or vice versa. Obviously, since the introduction of ISDN-only nodes in the nodelist some years ago now, it's been bad practice to allow calls to be made to a node whose "modem" capability flags in the nodelist don't explicitly indicate compatibility with one's own equipment. But at least the ISDN and modems (the PSTN) share the same addressing domain: the global E.164 numbering plan. If, on the other hand, the phone number field is left unused on IP-connected nodes, and a User flag or some other method is used to convey addressing information, then I submit that it may be a good idea to flag such nodes as Pvt, since correctly-written software will then divert telephony-style calls to the net host. To return to the point on DNS address resolution. I've heard suggestions for the DNS to be relied on to provide the IP address of a node, based on the node being listed in the fidonet.org domain. This would mean that no addressing information (other than the node number) needs to be included in the nodelist. But then I feel that a way must be devised to automate the administration of the required DNS configuration files at the authoritative name server for that zone (or net or whatever). Otherwise the sysadmins of those name servers will be expected to scan each week's nodelist for changes in the list of IP-connected nodes, then try and obtain IP addresses for the new IP nodes and modify the necessary files. The alternative is that the DNS service be decentralised so that net hosts of nets containing IP-connected nodes are able to administrate their own net's DNS entries. This requires them to run a name server though, which may heighten the threshold for wide-scale introduction of IP-connected nets. For the reasons explained in the above paragraph, I submit that at least in an interim period, IP or fqdn information be included in the nodelist instead of it being implicit. Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #480 [785] From : Jan Ceuleers 2:292/857 26 Aug 97 18:17:24 To : Wim Van Sebroeck 27 Aug 97 07:35:50 Subj : IP-access ------------------------------------------------------------------------------- Wim, In your capacity of postmaster@z2.fidonet.org I'm looking forward with great interest to your contributions to this thread. Pretty please?... Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #482 [785] From : Jan Vermeulen 2:280/100 26 Aug 97 12:00:58 To : Mats Wallin 27 Aug 97 07:35:50 Subj : IP-access ------------------------------------------------------------------------------- As I said in REGCON and probably also will be compelled to say in ENET.SYSOP: --- here goes --- Quoting Mats Wallin on Mon 25 Aug 97 12:31 to Jan Ceuleers: mw> IMHO, the host of a "TCP/IP-net" should be required to support mw> atleast analog modem calls, as well as TCP/IP sessions, to make it mw> possible for any system in FidoNet to crash a mail for any node in mw> that net via the host. Considering that access over telephone lines is one of the few conditions for a node to be a member of FidoNet, IP-Access should be considered as an additional feature just as FTS-6 and EMSI are additional features. This will avoid placing additional burdens on host systems and limiting the number of possible candidates where NC elections are concerned. It also avoids placing a burden on nodes that have IP-Access to have FTS-1 capabilities over Telnet for the sake of compliance. If you would wish to reply that this excludes nodes that have no telco access, then you will have exactly understood what I mean: FidoNet is basically a point-to-point network whereas in the internet all traffic is routed, whether it is tunneled or not. We should not change that difference as it would be tantamount to dissolving FidoNet. -=<[ JV ]>=- * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #483 [785] From : Mats Wallin 2:201/329.11 26 Aug 97 10:35:12 To : Pedro Lima 27 Aug 97 07:35:50 Subj : IP-access ------------------------------------------------------------------------------- PL> So, I'd propose that Z2 nodes are consulted on if they think PL> IP nodes can be part of FidoNet, although that would breach PL> some of FidoNet regulations. IMHO, adding IP nodes to the nodelist is only a technical change, and there shouldn't be a need to consult all nodes in FidoNet (or the zone) in that matter. If it is done this time, it should already have been done when ISDN nodes were added to the nodelist, and probably at a number of other times also. Mats mw@defsol.se --- * Origin: Definite APXw (2:201/329.11) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #484 [785] From : Mats Wallin 2:201/329.11 27 Aug 97 09:43:00 To : Jan Vermeulen 28 Aug 97 06:20:32 Subj : IP-access ------------------------------------------------------------------------------- JV> Considering that access over telephone lines is one of JV> the few conditions for a node to be a member of FidoNet, JV> IP-Access should be considered as an additional feature just JV> as FTS-6 and EMSI are additional features. Does it actually say that anywhere? I must admit that I can't recall that part of the policy. I really don't see any reasons why access over thelephone lines should be something that is required for a node. If that had been the case, ISDN nodes should not have been allowed in the first place either. Sure, ISDN is also one type of telephone lines, but most TCP/IP systems are also connected to other systems via some type of telephone lines, even if they often are leased telephone lines. The reason ISDN is used by many nodes is that FidoNet needs to change overtime, and to use the newer technologies when they become available (and affordable). TCP/IP connects are just the next step, and should be allowed IMHO. JV> This will avoid placing additional burdens on host JV> systems and limiting the number of possible candidates where JV> NC elections are concerned. Why is that? If each region have one single net that is used for nodes that have TCP/IP access (and probably only TCP/IP access), it is rather natural that these nodes also wants a Host that have TCP/IP access. I do not suggest that every Host should have TCP/IP access, atleast not today. Who knows what will happen in the future. But we have to start somewhere. JV> FidoNet is basically a point-to-point network whereas in the JV> internet all traffic is routed, whether it is tunneled or JV> not. We should not change that difference as it would be JV> tantamount to dissolving FidoNet. Almost all traffic in FidoNet is routed, the number of direct connections (i.e. crash mail messages) are much less than the number of routed netmail messages. And then we haven't started to talk about echomail. It might be true that the actual TCP/IP packets are routed on the Internet, but in most cases, the actual e-mail messages are not. Looking at the 'Received by' and 'Received from' lines messages in the e-mail messages I receive, it's very clear that almost all messages are sent directly from the origin to my ISP's system. So the actual information that is sent via FidoNet is much more routed than the information that is sent via the Internet. Mats mw@defsol.se --- * Origin: Definite APXw (2:201/329.11) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #485 [785] From : Pedro Lima 2:362/21 28 Aug 97 01:53:00 To : Jan Ceuleers 28 Aug 97 18:09:16 Subj : IP-access ------------------------------------------------------------------------------- Hi, JC> However, for IP nodes to be able to co-exist with modem and ISDN nodes JC> in the same nodelist, I feel it must be possible for existing nodelist JC> compilers (or other software that reads the distribution nodelist) to JC> be configured to prevent calls being made by modem or ISDN nodes to JC> IP-connected nodes Yes, but this may be possible if a specific (user?) flag is assigned to IP nodes, such as 'IP' . I don't know every implementation of nodelist compilers (or similar), but I think it should be an acceptable approach, like with ISDN nodes. JC> I must say that I haven't looked at the Russian initiative for some JC> time and that I don't know how the address of the node is listed, but JC> if the phone number field is used for that purpose, and if it contains JC> an IP address (as opposed to an fqdn; this could save $100 per year in JC> DNS charges) then it's conceivable that there is a collision between JC> this IP address when interpreted as a telephone number or vice versa. I think that the phone number field is indeed used to that purpose, and I agree that it's the IP address which should be listed, not the fqdn. If I recall correctly, the russian proposal accepts both. JC> Obviously, since the introduction of ISDN-only nodes in the nodelist JC> some years ago now, it's been bad practice to allow calls to be made JC> to a node whose "modem" capability flags in the nodelist don't JC> explicitly indicate compatibility with one's own equipment. But at JC> least the ISDN and modems (the PSTN) share the same addressing domain: JC> the global E.164 numbering plan. Yes, but unless a review is made to the nodelist standards, this will always be a problem or at least, a potential problem. I don't know if a phone number field is acceptable in the form "aaa.bbb.ccc.ddd" with most software, but perhaps "aaa-bbb-ccc-ddd" is? The possible problem with the last form (perhaps easily corrected, but I really don't know) is that to my knowledge the software used with the russian approach doesn't accept the second form. JC> If, on the other hand, the phone number field is left unused on JC> IP-connected nodes, and a User flag or some other method is used to JC> convey addressing information, then I submit that it may be a good JC> idea to flag such nodes as Pvt, since correctly-written software will JC> then divert telephony-style calls to the net host. Yes, I agree, although I don't like the idea of having a lot of Pvt nodes. It's even probably the more compatible solution, but if the first option is possible (and the russian experience seems to indicate that it is), I'd really prefer it. JC> To return to the point on DNS address resolution. (...) JC> For the reasons explained in the above paragraph, I submit that at JC> least in an interim period, IP or fqdn information be included in the JC> nodelist instead of it being implicit. I fully agree. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #486 [785] From : Pedro Lima 2:362/21 28 Aug 97 01:54:44 To : Mats Wallin 28 Aug 97 18:09:16 Subj : IP-access ------------------------------------------------------------------------------- MW> IMHO, adding IP nodes to the nodelist is only a technical change, and MW> there shouldn't be a need to consult all nodes in FidoNet (or the MW> zone) in that matter. If it is done this time, it should already have MW> been done when ISDN nodes were added to the nodelist, and probably at MW> a number of other times also. I see both your points, and my opinion is this. Technical changes may or may not require a change to the standards. Placing IP addresses in the phone field, to be properly done and if I recall correctly, would require a change of the FTS which defines the nodelist (unlike what happened with ISDN nodes). However, changing an FTS seems to be something like hitting Mars with a sling, and that's why I suggested that the nodes are consulted on this one, because if we are going to violate standards, then we need all the support for it. But, if changing the FTS is indeed possible(*), I'm all for it. Also, there may be other options, like listing them as Pvt nodes, as Jan so well considered. Naturally, all this works on the presumption that IP nodes should be just like any other node. (*) actually, it reminds me of the story of the snake eating its own tail, because the FTSC theoretically documents the practice, and the practice doesn't advance because the FTSs would be breached. ;-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #487 [785] From : Pedro Lima 2:362/21 28 Aug 97 01:55:40 To : Jan Vermeulen 28 Aug 97 18:09:16 Subj : IP-access ------------------------------------------------------------------------------- Hi, JV> If you would wish to reply that this excludes nodes that have no JV> telco access, then you will have exactly understood what I mean: JV> FidoNet is basically a point-to-point network whereas in the internet JV> all traffic is routed, whether it is tunneled or not. We should not JV> change that difference as it would be tantamount to dissolving FidoNet. Hmm. As far as my opinions are concerned, you scored a major point here, so I must change them. Damn! :-) I'm kidding, I thank you for the observation. However, I'd like to point out that it could be convenient to accept IP-only nodes in special circumstances, like if there's no other possibility of having an IP echomail hub or others that I'm not thinking of at the moment. These could eventually be listed as Pvt nodes, an attribution that is controlled by the competent *C, so the burden on the hosts can be managed, and by being Pvt, they aren't eligible for coordination jobs, so the inner nature of Fidonet isn't disturbed. Now, a Pvt number, as per specs, always has the phone number listed as "-Unpublished-". Is it possible to replace the phone number in a Pvt entry with an IP address? Do we need a "parallel" nodelist specifying the IP addresses of such cases? Or is this completely out of line with reality? :-) Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #491 [785] From : Jan Vermeulen 2:280/100 28 Aug 97 10:53:48 To : Mats Wallin 29 Aug 97 18:23:46 Subj : IP-access ------------------------------------------------------------------------------- Quoting Mats Wallin on Wed 27 Aug 97 9:43 to Jan Vermeulen: JV>> Considering that access over telephone lines is one of JV>> the few conditions for a node to be a member of FidoNet, JV>> IP-Access should be considered as an additional feature just JV>> as FTS-6 and EMSI are additional features. mw> Does it actually say that anywhere? I must admit that I can't mw> recall that part of the policy. FYI: P4, 1.2.3 1.3.2 (2) 2.1.8 (2) 2.1.9 (2) 2.1.11 (2) 2.2 (6) 2.3 (2) 4.4 (1) 5.5 (2) mw> I really don't see any reasons why access over thelephone lines mw> should be something that is required for a node. If that had been mw> the case, ISDN nodes should not have been allowed in the first mw> place either. mw> Sure, ISDN is also one type of telephone lines,... ISDN is trunk line technology brought to the local loop. Sysops that are ISDN-only are exceptions (IMANSHO they should not be allowed anymore as the technology has become affordable -- however, having analogue and digital technology available on the same telephone number can not always be achieved). So, basically, ISDN is an additional feature, just as EMSI and V34plus are additional features. They're nice to have, but one can dispense with them and still be policy compatible. mw> ... but most TCP/IP systems are also connected to other systems via mw> some type of telephone lines, even if they often are leased telephone mw> lines. Those 'other systems' are hubs and routers, there is hardly any direct point to point connection between two systems unless they happen to be next to each other in a route. mw> The reason ISDN is used by many nodes is that FidoNet needs to mw> change overtime, and to use the newer technologies when they become mw> available (and affordable). I do not dispute that, Mats, but it is only half the issue; the main issue of FidoNet is point to point connectivity, and with the internet there is none. mw> TCP/IP connects are just the next step, and should be allowed IMHO. In addition to the basic telephony connections, okay. Using the internet can be a true cost saver for international and very long distance national mail transfers; whether this must be real 24 hours IP access or just dial-up-and-ftp remains to be seen. The monthly cost for IP where I live will be easily twice that of FTP, dial-up cost for 60 mins/day included. JV>> This will avoid placing additional burdens on host JV>> systems and limiting the number of possible candidates where JV>> NC elections are concerned. mw> Why is that? If each region have one single net that is used for mw> nodes that have TCP/IP access (and probably only TCP/IP access), it mw> is rather natural that these nodes also wants a Host that have mw> TCP/IP access. I my view, IP being _additional_ to the basic requirements for FidoNet connectivity, the nodes should be in their 'own' net and not be grouped into one separate net per region. mw> I do not suggest that every Host should have TCP/IP access, atleast mw> not today. Who knows what will happen in the future. But we have to mw> start somewhere. Sure, but in doing so we_should_not_break_FidoNet. JV>> FidoNet is basically a point-to-point network whereas in the JV>> internet all traffic is routed, whether it is tunneled or JV>> not. We should not change that difference as it would be JV>> tantamount to dissolving FidoNet. mw> Almost all traffic in FidoNet is routed, the number of direct mw> connections (i.e. crash mail messages) are much less than the mw> number of routed netmail messages. But point-to-point mail is _possible_ and it is being used; I'm getting an average of 10 crash mails per day and that you can only do using telephone lines. mw> And then we haven't started to talk about echomail. Any additional method of file transfer is fine with me, as long as the basic point-to-point option remains available. mw> It might be true that the actual TCP/IP packets are routed on the mw> Internet, but in most cases, the actual e-mail messages are not. In reality, it is routed, only they're hiding it from you... mw> Looking at the 'Received by' and 'Received from' lines messages in mw> the e-mail messages I receive, it's very clear that almost all mw> messages are sent directly from the origin to my ISP's system. ... like routed netmail would look to you if there would be no via kludges (mailers like Dutchie 3.0 and above can be set to not add via's). mw> So the actual information that is sent via FidoNet is much more mw> routed than the information that is sent via the Internet. You can not send mail point-to-point using the internet; if you think it is, it has been simulated. -=<[ JV ]>=- * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #494 [785] From : Pedro Lima 2:362/21 28 Aug 97 05:32:32 To : Mats Wallin 29 Aug 97 18:23:48 Subj : IP-access ------------------------------------------------------------------------------- Hi, JV> Considering that access over telephone lines is one of JV> the few conditions for a node to be a member of FidoNet, MW> Does it actually say that anywhere? I must admit that I can't recall MW> that part of the policy. No, it doesn't. Not by those many words. However, it's pretty clear that P4.07 is built around the conception that FidoNet works via "normal" telephonic calls. You can see this in the reasoning behind geonets (1.2.3, 1.3.2), ZMH (2.1.8), non-redundancy of nodelist entries (2.1.9), use of current nodelist (2.1.11), the required information to apply for a node (2.2), procedures to follow when a node goes down (2.3), and nodelist maintenance (4.4 and 5.5). This could eventually be circumvented if an agreement is made as to make the necessary equivalences between a phone number and an IP address, i.e., if we want to go by the book, an ammendment to Policy *and* a FTS to define the technical requirements of such nodes. MW> I really don't see any reasons why access over thelephone lines should MW> be something that is required for a node. If that had been the case, MW> ISDN nodes should not have been allowed in the first place either. MW> Sure, ISDN is also one type of telephone lines, but most TCP/IP MW> systems are also connected to other systems via some type of telephone MW> lines, even if they often are leased telephone lines. Leased telephone lines don't have an address (i.e. a phone number), they simply aren't addressable by definition, being point-to-point links. With IP, you address the interface to the line (the terminal equipment, if you prefer). With ISDN, you have a mixture of both, since you have to address the line (by its telephone number) and the interface you want to reach (by its service indicator). Ideally, I also think that telephone line access shouldn't be something required for a FidoNet node, but given the present day FidoNet, I think it's very difficult to change that requirement (it's there, I'm afraid) in the near future unless we start to defy FidoNet's present immobility one step at a time and literally force things to change. This "slowness" (not immobility!) also allows us to timely consider the several impacts (at least, the major, obvious ones) that it may have and build things consistently. MW> The reason ISDN is used by many nodes is that FidoNet needs to change MW> overtime, and to use the newer technologies when they become available MW> (and affordable). I'm afraid that the main reason why ISDN is used by so many nodes resumes to being faster than analog lines with an attractive price (I know, not everywhere). :-) But, the reason why ISDN managed to be in FidoNet are mainly two. First, little change to the current FidoNet organizational structures was actually required, and second, because the sysops actively showed their interest in it. MW> TCP/IP connects are just the next step, and should be allowed IMHO. I agree, but IP would challenge the current FidoNet organizational structures in a much deeper way than ISDN did. I don't think we're ready yet for it, and that was how I understood what Jan was talking about, and why I changed my mind on the appropriate action to take at this moment. MW> Why is that? If each region have one single net that is used for nodes MW> that have TCP/IP access (and probably only TCP/IP access), it is MW> rather natural that these nodes also wants a Host that have TCP/IP MW> access. If a network is built with nodes that have IP access, it's mandatory that its host has IP access too, since it has to belong to the network in the first place. :-) Care should be taken however, because it will be only natural to expect that such networks mostly contain commercial-based systems (IP nodes aren't cheap) and that commercial attitudes come to play. Let me be very clear on this to avoid misinterpretations. I have *nothing* against commercial-based, as long as the amateur nature of FidoNet isn't disturbed. MW> It might be true that the actual TCP/IP packets are routed on the MW> Internet, but in most cases, the actual e-mail messages are not. MW> Looking at the 'Received by' and 'Received from' lines messages in the MW> e-mail messages I receive, it's very clear that almost all messages MW> are sent directly from the origin to my ISP's system. e-mail messages are (usually) transmitted via TCP/IP packets, so I fail to understand your reasoning on this one. In most cases, the data which constitutes the actual e-mail message has to be routed via several machines before reaching its destination. MW> So the actual information that is sent via FidoNet is much more routed MW> than the information that is sent via the Internet. I really can't tell, but I don't think that the raw problem lies in how many 'hops' the information has to go until it reaches its destination, but in the fact that the net is built with voluntary, amateur effort (there may be some exceptions, but let's leave it at that for the moment), and that no FidoNet sysop would indulge in having his system invaded with tons of information which he has to route to somewhere, even if he has a permanent IP-connection. Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #496 [785] From : Ward Dossche 2:292/854 29 Aug 97 22:31:20 To : All 30 Aug 97 06:42:54 Subj : IP-connectivity ------------------------------------------------------------------------------- Dear all, I must say I am a bit desilusioned by some people argumenting against IP-connectivity in Fidonet and trying to keep it PSTN-only as that is what the Fido-spirit is about or that it is against specific documented or undocumented practice etc... It seems to me that it would be completely wrong to not embrace IP-connectivity nor any of the new transmission-technologies that may/will be coming at us. Therefor I will yet launch another proposal of which in any case Denis McMahon is the spiritual father. Life can be much simpler than creating a separate zone/region/net. What Denis proposes is to put the IP-number in the phone-number-field but have it preceded by a fictitious non-existant country-code. IP-capable nodes then just translate this ficticious country-code into whatever is needed to achieve an IP-session and off they go. Those who aren't IP-capable don't translate and aren't bothered by it. It is then up to via some flags or several ficticious country-codes or a combination of both to define virtual modem transfers, ftp transfers and other types which can present themselves. No need for "pvt"-nodes either ... and the beauty of this proposal is that it can be used for other future technologies as well and, why not, ISDN too to avoid analog nodes calling digital-ones ... Personally I think Denis' idea was a very good-one, and if implemented I guess will be called "The McMahon annotation". ;-) Comments please? \x/ard --- DB 1.58/001877 * Origin: The pianoplayer (2:292/854) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #497 [785] From : Jan Ceuleers 2:292/857 30 Aug 97 10:30:38 To : Ward Dossche 01 Sep 97 02:23:12 Subj : IP-connectivity ------------------------------------------------------------------------------- I quote Ward Dossche: WD> What Denis proposes is to put the IP-number in the WD> phone-number-field but have it preceded by a fictitious WD> non-existant country-code. WD> WD> IP-capable nodes then just translate this ficticious WD> country-code into whatever is needed to achieve an WD> IP-session and off they go. Those who aren't IP-capable WD> don't translate and aren't bothered by it. Yes, this has been talked about quite some time ago already. The proposal at the time was to use an unused country code as a prefix for identifying the address space of the address that was to follow. This method can be used to identify a large number of address spaces. At the time, I proposed at least the following address spaces: IPv4 (the current 32-bit IP addressing system), IPv6 (the next-generation IP addressing system), X.121 (the addressing system used by X.25) and perhaps others. (I've been searching through my archives but couldn't find the earlier correspondence I had about this). We should check with the ITU which fake country code to use. It should be a country code that does not now and will never in the future exist. One way to ensure that would perhaps be to just use a 0 as the first digit in order to avoid collisions. The only thing that is likely to be used for is as the prefix for interplanetary telephone calls ;-) The numbering scheme could then become: 0 1 IPv4-address 0 2 IPv6-address 0 3 X.121-address In order to keep the door open for more than 10 such address spaces, the digit 9 should be used as an indication that the next digit will also be part of the address space identifier: 0 91 another-address-type 0 92 yet-another-address-type ... 0 991 the-address-types-just-keep-on-coming ... Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #499 [785] From : Jan Vermeulen 2:280/100 30 Aug 97 19:01:04 To : Ward Dossche 01 Sep 97 03:05:36 Subj : IP-connectivity ------------------------------------------------------------------------------- Quoting Ward Dossche on Fri 29 Aug 97 22:31 to All: wd> I must say I am a bit desilusioned by some people argumenting wd> against IP-connectivity in Fidonet and trying to keep it PSTN-only wd> as that is what the Fido-spirit is about or that it is against wd> specific documented or undocumented practice etc... FidoNet technology being a point to point network our prime concern should be with maximum connectivity, unless we would find a way to change policy in order to make long distance, international and intercontinental routing compulsory and instantaneous. Having said this I wish to stress that I am in favour of any technology that would enhance FidoNet's capabilities, provided that the following principles are respected: 1. maximum connectivity for any sysop in the net: I stress the term sysop, not node, as we may have to allow for more than one node number for the same sysop in cases where incompatibility between technologies, when used at the same node number, might exist. In the foreseeable future, this will probably include having at minimum an inexpensive modem on line during ZMH. 2. technical feasability I have no examples to show right now, but if we'd assume they do not exist right now we'd be sure to find out in due course. 3. absence of legal obstructions One example: HAM radio. It's relatively easy to install and there is no cost attached to it's use. Yet certain countries (among them the Nether- lands) prohibit its use for other purposes than communicating between HAM radio operators. wd> It seems to me that it would be completely wrong to not embrace wd> IP-connectivity nor any of the new transmission-technologies that wd> may/will be coming at us. Agreed. [...] wd> What Denis proposes is to put the IP-number in the phone-number-field wd> but have it preceded by a fictitious non-existant country-code. Clever thinking, it really is, but will it work? Now do not say that I'm a pessimist, because that is what I am by nature, but it would not be fun when one day the whole of FidoNet would be caught with its virtual pants down because the ITU decided to use our non-existent country code for some newly born nation (e.g. Sjeverna Srpska or whatever). wd> IP-capable nodes then just translate this ficticious country-code wd> into whatever is needed to achieve an IP-session and off they go. wd> Those who aren't IP-capable don't translate and aren't bothered by wd> it. Wouldn't the same apply to nodes using a U,IP:255.255.255.255 kind of flag? This would be easier on makenl settings (maxphone!) and no conversion of the IP numbers would be needed. It would also allow to have the same node number for telco and IP access where possible. In case of IP access only, "-Unpublished-" must be accompanied by "Pvt" for MakeNl to accept the entry wd> It is then up to via some flags or several ficticious country-codes wd> or a combination of both to define virtual modem transfers, ftp wd> transfers and other types which can present themselves. I've explained the danger of fictitious country codes... wd> No need for "pvt"-nodes either ... "Pvt" would be a perfectly legal flag, if needed at all, as this type of access would be to the future benefit off all Fidonet (P4, 2.1.9). wd> ... and the beauty of this proposal is that it can be used for other wd> future technologies as well... ITU permitting! wd> ... and, why not, ISDN too to avoid analog nodes calling digital-ones ... It is relatively easy to prevent isdn nodes to call analogue ones and vice versa; in most countries not making the effort to have correct mailer would be quite harmless as there would be no charge if you'd try. wd> Personally I think Denis' idea was a very good-one, and if wd> implemented I guess will be called "The McMahon annotation". ;-) Sorry to kill your joy, but it's really a bit more complicated. Why don't we take some time to toss around ideas and objections in order to find out what really will work for the net? -=<[ JV ]>=- * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #500 [785] From : Wim Van Sebroeck 2:292/862 31 Aug 97 12:40:16 To : All 01 Sep 97 18:20:28 Subj : Re: IP-access ------------------------------------------------------------------------------- From: wim@infomag.iguana.be (Wim Van Sebroeck) Hello Jan, Jan Ceuleers (Jan.Ceuleers@f857.n292.z2.fidonet.org) wrote: > In your capacity of postmaster@z2.fidonet.org I'm looking forward with great > interest to your contributions to this thread. Pretty please?... I missed the original proposal, but here are my comments: Fidonet doesn't need an extra Zone 7 for TCP/IP nodes. My opinion is that these nodes belong in the nodelist of their proper region/net. I would include these nodes in the nodelist. How we included these nodes is an other problem. 1) Why don't we need a Zone 7: * Because it is geographically incorrect. It is (in my opinion) more interesting to divide Fidonet in geographic instances. It gives people a clue to where people are writing to/from. * Because their is the ZC7 and ZEC7 problem. * Because the DNS tables of fidonet.org are based on the fact that fidonet is divided into geographical items. Zone 1 corresponds with the z1.fidonet.org subdomain, zone 2 corresponds with the z2.fidonet.org subdomain. Each subdomain is being supervised and managed by someone off that perticular zone. Who should be managing z7.fidonet.org ? Isn't it the same as placing nodes in fidonet.org itself? * Because DNS is an extra aid to solving the problem: Why create a special zone 7 nodelist when we have DNS-tables with extra information? Here is an example: f30.n5000.z2.fidonet.org. IN A 193.124.216.12 IN TXT "CM,MO,TCP,VMP,TEL,U,fidomail.ssc.nsu.nsk.su" *.f30.n5000.z2.fidonet.org. IN MX 1 f30.n5000.z2.fidonet.org. This means that 2:5000/30 is reachable via TCP/IP at IP-address 193.124.216.12 . In the TXT field we have some flags like they are defined in the nodelist. (CrashMail, Mail-Only, TCP/IP connected with VMODEM and Telnet capabilities.) So All necessary information (The nodelist flags and the IP address) are allready available in a list that contains all systems (= the DNS tables) for that specific zone. 2) Nodelist: I suggest to add these nodes into the net and/or region they belong to. People use this nodelist to check wether or not a node exist (in trackers and other software). Nodes that are only accessible through TCP/IP are reachable by means of routing through other systems. They could be included as being Pvt nodes with an -Unpublished- telephonenumber. 3) Nodelist-Flags/Compatibility-Flags. Their are many different protocols to connect two fido-nodes over a TCP/IP connection. Since the carrier is different (yes, its TCP/IP but no, it's actually TCP/IP with a certain service; just as ISDN has V110, V120, X75, SYNC-PPP) and the basic protocols are normally those of FTS-0001, we have no guarantees that each TCP/IP node is capable of connecting to another TCP/IP node. We need to Define NODELIST-FLAGS for this, just like we did for ISDN lines. (VMODEM could be VMP , TELNET could be TEL , IFCICO could be IFC , BINKD could be BNK , ... ). So no new Zone 7 but the implementation of another carrier (just like ISDN was) in the nodelist(-flags). greetings, Wim. PS: the DNS-tables of z2.fidonet.org are publicaly available at: ftp://ftp.z2.fidonet.org/pub/fidonet/dns/fidoz2.dns --- ifmail v.2.10-tx8.3 * Origin: InfoMag - Software Development System (2:292/862@fidonet) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #501 [785] From : Mats Wallin 2:201/329.11 01 Sep 97 11:06:58 To : Jan Vermeulen 02 Sep 97 06:38:04 Subj : IP-access ------------------------------------------------------------------------------- JV> So, basically, ISDN is an additional feature, just as JV> EMSI and V34plus are additional features. They're nice to JV> have, but one can dispense with them and still be policy JV> compatible. It is an additional feature only if the node in question also have an analogue modem. If they only have ISDN, you can't compare it with EMSI or V.34. JV> I do not dispute that, Mats, but it is only half the JV> issue; the main issue of FidoNet is point to point JV> connectivity, and with the internet there is none. Point to point connectivity is something we never had to 100%. For instance, there have always been modems that have been unable to connect with each other, there have always been Pvt nodes. FidoNet has become what it is today because it did NOT require point to point connectivity. I don't say that point to point connectivity isn't something that is useful, but it is more important to use the new technologies that become available and affordable than to force everyone to use the current technologies. JV> The monthly cost for IP where I live will be easily twice JV> that of FTP, dial-up cost for 60 mins/day included. I guess you with 'monthly cost for IP' are thinking about a 24h connection? In that case, I actually think that was very cheap (or that your dial-up access is very expensive, compared to our costs here in Sweden). But prices will not stay the same for ever, and new technologies for 24h connections to the Internet will become available that will lower the costs. Preventing the use of a new technology because it is to expensive, or not available, in some places of the world is not a good idea. JV> But point-to-point mail is _possible_ and it is being JV> used; I'm getting an average of 10 crash mails per day and JV> that you can only do using telephone lines. Sure it is used. In some cases it might be because of privacy, but I would say that in atleast many cases, if not all, the reason for the crash mails is speed. And that would not be a concern anyway, if you have to crash a netmail message via the host of a net, who then can forward it immediately to the destination. And if it is a question of privacy, well, IMHO, that is something the IP-node would have to consider before deciding that he only should have IP-access. mw>> It might be true that the actual TCP/IP packets are routed mw>> on the Internet, but in most cases, the actual e-mail mw>> messages are not. JV> In reality, it is routed, only they're hiding it from you... Sure, and your "direct" phone call to someone is also routed. It has to be, since you do not have a direct connection with every single phone/modem in the world. The only difference is the type of equipment that is used to route the data, and they way the data is routed (in the IP world, each packet can be routed via different systems, while the phone call is routed once when it is being setup). JV> You can not send mail point-to-point using the internet; JV> if you think it is, it has been simulated. The IP packets might be routed via other systems, but the actual message is not processed by each system it is routed via. Just as your "direct" FidoNet message is sent via a number of phone exchanges, but they don't process the message. Mats mw@defsol.se --- * Origin: Stockholm, Sweden (2:201/329.11) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #502 [785] From : Anton Kuznetsov 2:465/50 01 Sep 97 22:36:06 To : All 02 Sep 97 06:38:04 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- Buenas dias, amigos ! Quoting a message of Jan Ceuleers to Ward Dossche [30 Aug 97, 10:30]: [ ... ] JC> We should check with the ITU which fake country code to use. It should JC> be a country code that does not now and will never in the future exist. JC> One way to ensure that would perhaps be to just use a 0 as the first JC> digit in order to avoid collisions. AFAIK "0" is used for "Country Direct" service: 011 USA, AT&T 012 USA, AT&T 013 USA, MCI 014 USA, MCI 015 USA, Sprint 016 USA, Sprint 017 CANADA, Teleglobe 018 CANADA, Teleglobe 031 NL, Dutch PTT Telecm 032 BELGIUM, Belgacom 033 FRANCE, Telecom 048 POLAND, Polish Telecom 049 GERMANY, DBT Telecom 081 JAPAN, KDD [ ... ] Anthony. Donetsk, Ukraine --- E-mail: tony@tony.donetsk.ua * Origin: Everything you say may be used against you. (2:465/50) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #503 [785] From : Wim Van Sebroeck 2:292/862 01 Sep 97 21:51:58 To : All 03 Sep 97 19:20:42 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- From: wim@infomag.iguana.be (Wim Van Sebroeck) Jan Ceuleers (Jan.Ceuleers@f857.n292.z2.fidonet.org) wrote: > At the time, I proposed at least the following address spaces: IPv4 (the > current 32-bit IP addressing system), IPv6 (the next-generation IP addressing > system), X.121 (the addressing system used by X.25) and perhaps others. (I've > been searching through my archives but couldn't find the earlier > correspondence I had about this). ... Nice idea. But what whit nodes that have a pstn or isdn number and TCP/IP connectivity? greetings, Wim. --- ifmail v.2.10-tx8.3 * Origin: InfoMag - Software Development System (2:292/862@fidonet) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #504 [785] From : Jan Ceuleers 2:292/857 03 Sep 97 18:34:22 To : Anton Kuznetsov 05 Sep 97 18:30:36 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- I quote Anton Kuznetsov: AK> AFAIK "0" is used for "Country Direct" service: Then that's a local quirk of your national dialing plan. Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #505 [785] From : Jan Ceuleers 2:292/857 04 Sep 97 18:00:08 To : Wim Van Sebroeck 05 Sep 97 18:30:36 Subj : Re: IP-connectivity ------------------------------------------------------------------------------- I quote Wim Van Sebroeck: > At the time, I proposed at least the following address spaces: IPv4 (the > current 32-bit IP addressing system), IPv6 (the next-generation IP addressing > system), X.121 (the addressing system used by X.25) and perhaps others. (I've > been searching through my archives but couldn't find the earlier > correspondence > I had about this). WVS> Nice idea. But what whit nodes that have a pstn or isdn WVS> number and TCP/IP connectivity? Those nodes will need extra node numbers. Unfortunately, the current nodelist format does not realistically permit a node to advertise all of its capabilities if it has a multitude of them. Not even in the case modem/ISDN. It may be that a node has a modem on-line at phone number x, and an ISDN device (which does not have a modem) at phone number y. Even if these two devices can be reached at the same phone number, and hence only one node number is listed, then there may be uncertainties as to whether a particular capability flag refers to the modem, to the ISDN device or to both (V42B comes to mind). The most elegant solution would indeed be something like what Steve Woodmore proposed, but that requires a change in all software that generates or uses the nodelist. Steve proposed the addition of "Extra," lines which would indicate additional capabilities or co-ordinates of the last non-Extra line preceding them. The main merit of this solution is that only one node number is needed, so that a node is unequivocally identified by the single node number, regardless of the connectivity method used to reach him. The (in my view) most important disadvantage is that it will no longer be possible to select a technology through which to connect to a multi-technology node by selecting the corresponding AKA of that node. Also, there would not be much difference in the resulting size of the nodelist between Steve's proposal and simply handing out extra node numbers. Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #508 [785] From : Jan Vermeulen 2:280/100 07 Sep 97 00:00:00 To : Rune Johansen 09 Sep 97 07:50:04 Subj : IP-access ------------------------------------------------------------------------------- * Crossposted from ENET.SYSOP Quoting Rune Johansen on Fri 5 Sep 97 22:32 to Lothar Behet: rj> As I have said in another message here earlier, a SysOp could tell rj> his PSTN node to NOT call nodes with ,IP in the flag list, because rj> the "phone number" is an IP or DNS address. Unless I'm very wrong, it has now been made clear that DNS addresses can be used in all cases; they can be placed in the BBS name field of a nodelist entry, leaving the telephone number field free for its original purpose: listing a telephone number; and non IP-aware software will not be troubled by funny numbers. This not only introduces the possibility to list nodes that are allocated on the fly a different IP number each time they connect to their ISP but also eliminates the problem of lack of room in the flags field for flagging non standard IP ports at the destination node as presumably this would be solved by the destination's uplink. The time open problem can easily be addressed by using FSC-0062 and change the flag from Txy to ITxy. Is there anything else that needs to be solved before we can integrate IP-nodes into the nodelist via standard network lists? -=<[ JV ]>=- * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #509 [785] From : Jan Ceuleers 2:292/857 09 Sep 97 07:09:12 To : Jan Vermeulen 10 Sep 97 19:28:48 Subj : IP-access ------------------------------------------------------------------------------- I quote Jan Vermeulen: [Listing host@fqdn in BBS name entry] JV> This not only introduces the possibility to list nodes JV> that are allocated on the fly a different IP number each JV> time they connect to their ISP but also eliminates the JV> problem of lack of room in the flags field for flagging non JV> standard IP ports at the destination node as presumably this JV> would be solved by the destination's uplink. Please tell me how this bit about dynamic IP addresses works. Is it possible for an ISP to allocate a DNS entry to a dialup customer who has a dynamically-assigned IP address? Where does that DNS entry point to while that customer isn't on-line? How does the ISP avoid this DNS entry being cached by name servers across the world, thus avoiding outdated and therefore incorrect data to be served to people querying a non-authoritative name server (which is the normal thing to do)? Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #511 [785] From : Jan Vermeulen 2:280/100 10 Sep 97 00:00:00 To : Jan Ceuleers 11 Sep 97 21:44:56 Subj : IP-access ------------------------------------------------------------------------------- Quoting Jan Ceuleers on Tue 9 Sep 97 7:09 to Jan Vermeulen: JV>> ... nodes that are allocated on the fly a different IP number each JV>> time they connect to their ISP jc> Please tell me how this bit about dynamic IP addresses works. I do not know HOW it works, I do know THAT it works. -=<[ JV ]>=- * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #514 [785] From : Jan Ceuleers 2:292/857 12 Sep 97 07:09:04 To : Jan Vermeulen 13 Sep 97 16:13:16 Subj : IP-access ------------------------------------------------------------------------------- I quote Jan Vermeulen: JV>> ... nodes that are allocated on the fly a different IP number each JV>> time they connect to their ISP jc> Please tell me how this bit about dynamic IP addresses works. JV> I do not know HOW it works, I do know THAT it works. You haven't addressed the question at the center of my argument. Yes, I know that dynamic IP addresses themselves do indeed work. My ISP assigns me one each time I log on. What's more important is that it's not possible for dynamic IP addresses to be assigned DNS entries. This is why the IP address _must_ be included in the nodelist, at least for nodes that have dynamic IP addresses. Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #515 [785] From : Jan Vermeulen 2:280/100 13 Sep 97 00:00:00 To : Jan Ceuleers 14 Sep 97 18:14:50 Subj : IP-access ------------------------------------------------------------------------------- Quoting Jan Ceuleers on Fri 12 Sep 97 7:09 to Jan Vermeulen: jc>> Please tell me how this bit about dynamic IP addresses works. JV>> I do not know HOW it works, I do know THAT it works. jc> You haven't addressed the question at the center of my argument. Well... jc> Yes, I know that dynamic IP addresses themselves do indeed work. My jc> ISP assigns me one each time I log on. What's more important is jc> that... jc> ...it's not possible for dynamic IP addresses to be assigned DNS entries. jc> This is why the IP address _must_ be included in the nodelist, at least jc> for nodes that have dynamic IP addresses. Jan, isn't this a circular statement or did you want to say something different from what you actually wrote? Dynamic IP addresses are assigned on the fly and will differ at each connect. This would mean that they would be valid for the duration of one connection only and may get outdated again by the time their entry has been updated in the next nodelist. -=<[ JV ]>=- * Origin: The Poor Man's Workstation -- Wormerveer NL (2:280/100) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #516 [785] From : Pedro Lima 2:362/21 13 Sep 97 05:56:12 To : Jan Ceuleers 15 Sep 97 06:12:46 Subj : IP-access ------------------------------------------------------------------------------- Hi, JC> What's more important is that it's JC> not possible for dynamic IP addresses to be assigned DNS entries. Actually, it looks like it's possible. FWIW, and if you have Internet access, take a look at http://www.dyndns.com. JC> This JC> is why the IP address _must_ be included in the nodelist, at least for JC> nodes that have dynamic IP addresses. ?!! Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #520 [785] From : Jan Ceuleers 2:292/857 14 Sep 97 09:57:20 To : Jan Ceuleers 15 Sep 97 06:12:48 Subj : IP-access ------------------------------------------------------------------------------- I quote Jan Ceuleers: JC> You haven't addressed the question at the center of my JC> argument. Yes, I know that dynamic IP addresses themselves JC> do indeed work. My ISP assigns me one each time I log on. JC> What's more important is that it's not possible for dynamic JC> IP addresses to be assigned DNS entries. This is why the IP JC> address _must_ be included in the nodelist, at least for JC> nodes that have dynamic IP addresses. Wow, what a dumb conclusion to draw. Dynamic IP addresses can't be listed, by virtue of their being dynamic... Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #521 [785] From : Pedro Lima 2:362/21 13 Sep 97 05:56:12 To : Jan Ceuleers 15 Sep 97 07:11:48 Subj : IP-access ------------------------------------------------------------------------------- Hi, JC> What's more important is that it's JC> not possible for dynamic IP addresses to be assigned DNS entries. Actually, it looks like it's possible. FWIW, and if you have Internet access, take a look at http://www.dyndns.com. JC> This JC> is why the IP address _must_ be included in the nodelist, at least for JC> nodes that have dynamic IP addresses. ?!! Regards, Pedro --- * Origin: Kaos BBS * +351-1-8862878 * 24h (2:362/21) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #522 [785] From : Jan Ceuleers 2:292/857 14 Sep 97 09:57:20 To : Jan Ceuleers 15 Sep 97 07:11:48 Subj : IP-access ------------------------------------------------------------------------------- I quote Jan Ceuleers: JC> You haven't addressed the question at the center of my JC> argument. Yes, I know that dynamic IP addresses themselves JC> do indeed work. My ISP assigns me one each time I log on. JC> What's more important is that it's not possible for dynamic JC> IP addresses to be assigned DNS entries. This is why the IP JC> address _must_ be included in the nodelist, at least for JC> nodes that have dynamic IP addresses. Wow, what a dumb conclusion to draw. Dynamic IP addresses can't be listed, by virtue of their being dynamic... Jan --- timEd-A10a * Origin: Experimenter Board, Antwerp, Belgium (2:292/857) - Fido Intern (2:2446/301) --------------------------------------- REGCON.EUR - Msg : #540 [785] From : Ask Bjoern Hansen 2:235/224 28 Aug 97 03:42:52 To : Jan Ceuleers 06 Oct 97 07:05:28 Subj : IP-access ------------------------------------------------------------------------------- Hello Jan! Tuesday August 26 1997 17:49, Jan Ceuleers wrote to Pedro Lima: JC> I quite agree with your reasoning. JC> However, for IP nodes to be able to co-exist with modem and ISDN nodes JC> in the same nodelist, I feel it must be possible for existing nodelist JC> compilers (or other software that reads the distribution nodelist) to JC> be configured to prevent calls being made by modem or ISDN nodes to JC> IP-connected nodes Modem flags? :-) Kind Regards, Ask --- GoldED/2 3.00.Alpha4+ * Origin: Windows: A View to be Killed. (2:235/224)