| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Vlist`s conjecture |
Hello Peter. 31 May 06 19:10, you wrote to me: MvdV>>> P4 was written with little or no concern for the situation MvdV>>> outside Z1 period. For one it tacitly assumes local calls are MvdV>>> free. PK>> Nope, nowhere does P4 say anything like that at all, that is PK>> simply YOUR interpretation. MvdV>> It is not my interpretation, it is my conclusion. PK> interpretation = conclusion.......;-) No. Here is what I glean from P4: 1) It prescribes geographical non overlappping nets based on "areas of conveniEnt calling" 2) Nodes that can not be fitted in such a scheme will be listed as RIN. 3) The host of a net is to receive incoming netmail destined for nodes in the net. The NC has to arrange for delivery of that mail to the nodes in the net. 4) P4 does *not* say who is to bear the cost of getting the mail from the host to the leaf nodes. ================================================================= Those are the facts as I glean them from P4. You may argue that what is above the double line is a result of my interpretation of P4, but that does not go for the *conclusion* drawn from the above: Vlist's conjecture: P4 was written from the tacit assumption that local calls are free. MvdV>> P4 is full of cost issues. There are penalties for unduly incurring MvdV>> cost on others, PK> Yes, THAT is a cost issue... Right. MvdV>> there are provisions for nodes routing extraordinary MvdV>> amounts of mail, etc, etc. PK> No, that is NOT just a cost issue, it is also a load issue. Yes, it PK> does have a cost component but it is not targeted at cost alone. True. And so it *also* is a cost issue. MvdV>> The NC has an obligation to see that mail delivered MvdV>> at the host gets to the nodes in the net. PK> Yes, the NC has an obligation to see that mail "gets to the Node", BUT PK> it does not say that the host HAS to hand deliver it. Exactly. It does not say how this has to be done and more to the point at hand: it does not say who bears the cost. PK> As long as the NC has correct mail ROUTING in his configuration, I PK> would be happy to say that the bulk of the job is done. Then the crunch is in the last mile. Setting up the correct routing is no good if the mail just sits there in the host's outbound waiting for someone to do something. No, I say the NC's obligation goes much furtjer than that; he has to see that it actually *gets* there. Some way... MvdV>> What is does *not* say is how it gets from the host to the MvdV>> leaf nodes. PK> Correct. Which is part one of the omission I noted. MvdV>> In particular it does not say who bears the *cost*. A glaring MvdV>> omission I say. PK> Omitted on purpose perhaps? I find that difficult to accept. P4 is full of details to the point of paternalism. And then they would be aware of this potential source of problems and just choose to not address it? Besides, if all is left to the net to sort out the cost issue for themselves, the geo restriction makes no sense. If a node is outside the "area of convennient calling" and its sysop is preparaired to pay for the (long distance) calls to pick up the mail, why deny him or her? Why force them to join the local net? The geonet restriction makes little or no sense *unless* one assumes they wanted to avoid debates over the cost by restricting nets to areas where calls between the members of the net are free. Free in the sense that there is no *extra* cost involved once one has the line set up. The geo restRictions caused a *lot* of problems here I might add. Such as forced cost recovery plans, dictatorial NCs, etc, etc. Problems that could have been avoided had the makers of P4 not ignored the problems associated with it. Such as cost of getting the mail form the host to the leaf nodes. MvdV>> The only explanation I can come up with is that the MvdV>> writers of P4 wrote it from the position that there MvdV>> *is* no cost. Which was true for most if not all of MvdV>> the US and Canada at the time of writing of P4. PK> How short sited on your part, I can see several reasons for this. All of them are either far fetched or denbunkable. PK> Perhaps the most obvious one is that they simply let the nodes work PK> this out for themselves. In that case the geo restrictions lose their justification. If the members of the net are allowed to arrange the cost recovery between them, there is no reason to deny out of area nodes into the net. PK> Shock... Horror... Michiel's clearly defined manual on how Fidonet PK> works is torn apart... Torn apart? Hardly. Yo have not disproven Vlist's conjecture. PK>> In addition, in many nets "local" was a cost call the same as in your PK>> part of the world. MvdV>> There may have been exceptions even in Z1 at the time MvdV>> of writing of P4. If that was the case, the writers MvdV>> of P4 were not aware of it or they choose to ignore it. PK> So its not conceivable to you that they DESIGNED it to work that way? Not really. I go for Ockham's razor. The explanation that requires the least additional assumprions is the one to be used: i.e. Vlist's conjecture. MvdV>> MvdV>> So it does not matter who calls who when it comes to the MvdV>> MvdV>> host's obligation of delivering incoming routed mail. PK>> Nope, there is no such obligation. A Host must agree to ROUTE INBOUND PK>> mail, but is not obliged to deliver it. He has an obligation to see that it reaches the desitnation. MvdV>> The intention obviously is to get the mail to its final destination PK> Not so obvious I am afraid... Not? How so? PK> To me, the intention is to define an arrival point for inbound mail PK> that then has a good chance of reaching the target system, and it can PK> reach that arrival point in pretty much the same fashion for ALL NETS PK> in Fidonet. That makes sense as a sub goal, but it loses all sense if the *ultimate* goal is not to get the mail to its final destination. MvdV>> and in order to do that *someone* has to make a call. The glaring MvdV>> ommission of not saying *who* has to make the call is the telltale MvdV>> evidence for the tacit assumption of free local calls. PK> I think you mean that by brilliant design that fact was left out, I would not label an omission that lead to a seven year cost sharing war in The Netherlands, to a several year schism in Germany and to severe net wars in The UK as "brilliant". If I am in a good mood, I would call it an oversight. In an bad mood I call it bloody stupid. MvdV>>> In Z2 local calls are *not* free and so it does matter MvdV>>> who calls who. PK>> And in many situations the same applies to other PK>> parts of the world, so don't worry, you are not alone......;-) MvdV>> We have adapted but not without some problems. MvdV>> Obviously it is unreasonable to demand that the host MvdV>> makes all the calls to deliver the mail. PK> But you can't say that, because you are just invalidating your PK> previous statement on the issue. Well I just said it didn't I? What previous statement did I invalidate? MvdV>> That would put *all* of the coast on one person. So we went by MvdV>> the rule: the leaf nodes have to call their host or hub at regular MvdV>> intervals to pick up mail. Prefereably every day, but once a week MvdV>> at minimum. PK> Exactly. Logic prevails... At the cost of violating P4. And even then, there is no logic in the geonet restriction if the leaf node carries all the cost of getting his mail from the host. MvdV>> There *have* been a few cases here in The Netherlands MvdV>> were sysops refused to comply. Nodes *have* been MvdV>> removed from the nodelist for not picking up mail for MvdV>> an extended period of time. (A couple of month). PK> And rightly so. Yoy think so? Apparently some *C's higher up in the chain disagreed with you as some of the smarter sysops had their excommunication overruled in an appeal. It would appear that striking a node from the nodelist because the sysop refuses to poll the host/hub at regular intervals is not 'rightly so'. MvdV>> Of course that is history. The few remaining POTS only nodes poll MvdV>> at regular intervals and for IP it does not matter as the calls MvdV>> *are* free. PK> No... not free... the cost is paid for access to the service, not the PK> use of it. Why do I have to write every word as if it is to be read by lawyers in a court of law. You know what I mean: there is no *extra* cost for the call once the system is set up. PK> The entire point of Fidonet is to operate as a co-opertive group of PK> people who work together following a common set of ideas. All very nice and in an ideal world we would not need rules. Rules are for when a conflict arises. PK> All of the points you "desire" Desire? What makes you think it is what I desire? I do not desire any of the above. If I had my desires P4 would never have been adopted. PK> above are trying to turn Fidonet into something much more rigid and PK> fixed, something that Fidonet is not. I am merely stating my conclusions based on P4. I did not say, nor did I intend to say that it is what I want. PK> As a document, overall I think P4 has been extremely well written, PK> even if it does have 1 or 2 rought edges. A few rough edges? I think it is very badly written. It is full of holes and inconsistencies. TJ had it right: P4 is a crock of smelly shit. PK> The beauty of P4 is that it does not tie things down too far, Seven year cost share war resulting form geonet restrictions..... PK> it gives Fidonet Members the chance to work things out themselves, Well they haven't been very successful at that, given that fidonet's alias is fight'onet... PK> IE it lets them work together in a co=operative spirit. Your approach PK> is to build walls and stop/go signs, *My* approach? He, I didn't write P4! I am merely sharing my ideas on what its implications are. PK> but sorry, that simply wont work in a co-operative environment. Indeed, it does not work very well. But do not blame it on me, blame it on the writers of P4. *They* wrote that crock of smelly shit. Cheers, Michiel --- GoldED+/W32-MSVC 1.1.5-b20060315* Origin: http://www.vlist.org (2:280/5555) SEEN-BY: 633/267 270 5030/786 @PATH: 280/5555 123/500 106/2000 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.