Text 1551, 263 rader
Skriven 2006-06-01 10:20:00 av Michiel van der Vlist (2:280/5555)
Kommentar till text 1523 av Peter Knapper (3:772/1.0)
Ärende: 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)
|