Text 329, 265 rader
Skriven 2005-05-20 17:26:00 av Michiel van der Vlist (2:280/5555)
Kommentar till text 293 av Carol Shenkenberger (6:757/1)
Ärende: Changing FTS-0001.
==========================
Hello Carol,
>> No. Please, LISTEN to me. You are dreaming. I do not have
>> the resources in this smaller zone that is more IP intense
>> percentage than any other zone out there,
MvdV>> Is that so? When I discard the garbage from the zone 6 segment I count
MvdV>> 5 POTS and 3 IP systems in zone 6. POTS is still in the majority. That
MvdV>> is assuming the information /you/ provide is correct.
> Smile, I appreciate the ideas! One factor is known and i've not
> been hiding it. Z6 segment is not accurate one POTS listings.
I realise you are saddled with an inheritance that is a bit messy...
> Hence, your data solutions(no fault of your own) do not work.
Despite that I still say it can work. Read on...
MvdV>> It is not what I desire, it is what policy says: assignment of node nu
MvdV>> shpuld be based on technical reasons only. If you follow that guide li
> Yes, and this has already changed in some zones, and changed
> in Z6 before i even got there.
And some of these others have seen the error of their ways and corrected it. My
own region is a good example.
You may want to read Jan Vermeulen's article Fidonews again. IIRC it was in the
1999 Volume.
> Z6 allows and has for some time, IP only nodes and NC's and *RC's*.
And the fact that they have allowed that is one of the causes of the mess it is
in...
> I do not want to arge the validity of this as it is
> not arguable. Facts are facts. Z6 has IP Only RC's.
I am not arguing the fact that presently there are two IP on;u RC's. what I am
arguing is that there is a need for them.
MvdV>> there is no need for ION hosts in Z6.
>> When you and some others in Z2 speak on this, they think with
>> the mindset of at least 4 of 5 nodes have a POTS line.
MvdV>> Carol, you /have/ five nodes with a POTS line. And you only need one..
> Umm, no, I have 3 POTS nodes. 1 of them has a ring-down setup
> that is not reachable from outside his country as far as I can
> determine. The rest are lingering bad listings I have not yet
> fixed.
That still leaves two, which is enough to avoid the need for ION *C's.
MvdV>> I never said or meant to say that whatever is left of zone 6 should
MvdV>> be "demised". Of course not, we should do our utmost to see that
MvdV>> the nodes remain connected.
MvdV>> And this time I am not talking about having the remaining nodes move
MvdV>> to a neighbouring zone either. (Although I still say that would be
MvdV>> the logical thing to do).
> In the long term, if Z6 can not function, this is what will happen.
Then why postpone the inevitable?
> Due to commonality of several things, they would shift to Z3 more
> naturally than any other place.
The only commonality I see, is that Z3's ZMH would fit in better. Although The
importance of that is not as great as it once was.
> Next most likely would be following actual path of connection
> which is Z1.
Connection with what? Echomail links don't count.
MvdV>> Your job is not impossible. But you have to think out of the box
MvdV>> to untie the mess.
> Grin, have ben thinking out of the box.
You have indeed. But... what you fail to realize is that there is more that one
box. There are boxes within boxes and you have only stepped out of the inner
box...
MvdV>> Your job is to find the best achievable connectivity for the nodes
MvdV>> in your zone. Indeed without causing conflict with others.
> Hence i really *really* want to get away from the 000- listings.
Getting away from the bogus numbers is good thing, but replacing it by
"-Unpublished-" only solves the problem of people not aware of the trap
attempting to dial those numbers and getting into problems.
What it does not solve is the problem of poor connectivity.
> Unfortunately I have no other option just now for
> some of those you see as 'POTS' but to shift them to
> 000-0-0-0-0. Li for example simply does not have a valid POTS
> number nor do any sites in China as far as I can tell.
Bin Li? Hmmm Janis told us he had left FidoNet...
Anyway, the hard reality is that if Bin Li is still present in FidoNet he
simply does not qualify to perform a host function:
Host,654,Shanghai_Net,Shanghai,Bin_Li,000-0-0-0-0,300,CM,XA,V32B,V42B,V34
This one is not an ION host, it is an *unreachable* host. There is no valid
contact information whatsoever. Not POTS and not IP. replacing the bogus number
by "-Unpublished-" does not solve the problem that he can not perform the main
function of a host and that is to receive mail for the nodes in the net.
If Bin Li is still there, he should not be host and be listed as a private node
at most. That sounds harsh, but it IS the reality of FidoNet.
>> What i need is an answer that unties Pvt and -Unpublished-.
>> The software is there. It's just getting people to implement
>> it that may be the problem.
It won't solve the problem mentioned above.
MvdV>> No, that is not the problem. Think out of the box Carol. Walk
MvdV>> around the problem and have a look at it from the other side.
MvdV>> Ask yourself if what you perceive to be the problem really is
MvdV>> the problem.
> Yes, that is the problem. I've looked. Nor can I take a
> person who is a valid node and just shift their nodenumber in
> a1 weeks notice out here in the boonies of Fidonet.
Of course not. I am not suggesting that you should do it in a week. Although
the two years Jan Vermeulen planned for the reorganisation of R28 (then 200
nodes) is much more than you should need. Onec again: Read Jan's article.
>> In the meantime, with extreme unhappiness, I have to shift
>> nodes to 000-0-0-0-0 for the phone line shortly or risk yet
>> more bogus numbers. At least that one is known and folks
>> should be aware to block it.
Do I understand it that this is a temporary measure and you are contemplating a
better solution? Something that /does/ involve changing node numbers? In that
case I withdraw most of my objections...
MvdV>> Inadvertent dialling of bogus numbers that can cause problems
MvdV>> to the caller is just one issue and I think it is not the main one.
MvdV>> The main issue is connectivity.
> It is an issue out here of main concern. I cant force the
> folks out here to post in echos you travel,
There is no need for that. Some would argue that echomail is not even part of
FidoNet.
> but I can prevent dialing problems due to bogus phone numbers.
When I say connectivity I mean connectivity for *netmail*.
MvdV>> Decoupling "Pvt" and "-Unpublished-" will indeed allow you to
MvdV>> list Joe Sysop, who's system is ION, as host. But if you go
MvdV>> for that approach I The question should not be "how can I
MvdV>> list Joe as host?". The question should be "how can I arrange
MvdV>> for the best connectivity for the nodes in my zone?"
> Smile, I can dream! Path of connection here is nothing like
> you have experience in.
What makes you think I have no experience with odd oath of conection?
> It is no fault of yours that this is not like the model you
> have been trained in for the past several years. Took me a
> bit to catch on too.
It appears to me that when we mention "connectivity" we are not talking the
same thing.
What I have learned is that the only
> Just keep in mind no 2 zones are the same and a pattern that
> matches your own experience as 'works well' need not be the one
> another zone has grown up with that also 'works well'.
FidoNet is a global netwok. Zone specific "solutions" are detrimental to
connectivity. A sysop in zone X should be able to send netmail to a node in
zone Y /without/ having to know about any zone specific issues.
The only official way of routing in FidoNet is to drop it at the host of the
destination. That should /always/ work.
> Z3 is a classic there that is radically different from Z2 yet
> 'works well'.
I don't see any radical differences between Z3 and Z2.
MvdV>> Forget about the existing situation. Forget about silly notions
MvdV>> like regions should equate countries etc. ect. That make no
MvdV>> sense anymore in your s
> Smioe again! Z6 long went away from that. Hasnt been 1
> country per region for a very long time. China is the only
> one that lists only China nodes, all the others are mixed
> based on connectivity.
MvdV>>> the only logical answer to that question is: One.
> Nope. 2, with China abouyt to demise as I said being next in line.
That is not what I was referring to.
MvdV>> Forget about the past. Forget about silly notions like "demising"
MvdV>> a region. A region is nothing but an administrative thing. They
MvdV>> were introduced to reduce the administrative load on the
MvdV>> coordinators. Totally unneeded in your situation. Forget the
MvdV>> whole concept of Regions.
> Did you track that we demised 5 regions in the past 18 months?
> I am looking close at China but not ready just yet.
We still are not talking the same language. What I see it that regions have
been "demised" because their was not a single node left. India comes to mind.
The only one weher it was done right was your own regio. 63 IIRC.
Look at it this way:
You need:
1) Someone to maintain the nodelist. How big a team do you need to maintai a
nodelist segment with less than 10 nodes? One is all you need and If you can't
find *one* willing an able to do it, you'd better close shop.
2) Someone to run the system that accepts inbound mail for the rest and
forwards it. That system should preferably offer POTS and IP capabilities. How
many of those do yo need to care for less than 10 downlinks. One is al you need
and If you can't find *one*, you better close shop.
3) Complaint handling. If with just ten nodes you need a hierarchy to resolve
complaints.....
MvdV>> Here is one possible answer: (Just an example mind you.)
> Smile, gives me a few ideas. Not what I want to do just yet
> though. I DO appreciate it however. Humm, comes to mind you
> seg doesnt quite match mine yet. You still list Thailand for
> example. I took them out I think it was 2 segments ago.
> Might be a processing problem I was unaware of?
Hmmm....
It seems something went wrong last week and we missed one or two steps. Now we
are in sync again and ward has used your segment #140.
But Thailand is still there, albeit with an unreachable host. :-(
N.B. Please don't take all this personal. As far as I am concerned we are not
fighting. Just exchanging unorthodox ideas.
Cheers, Michiel
---
* Origin: http://www.vlist.fidosoft.de (2:280/5555)
|