Text 10098, 195 rader
Skriven 2013-08-29 15:21:16 av Ulrich Schroeter (2:244/1120)
Kommentar till text 10094 av Michiel van der Vlist (2:280/5555)
Ärende: Internet access - Fidonet Policy thoughts ....
======================================================
Hi Michiel,
Thursday August 29 2013 13:17, you wrote to me:
MV> Hello Ulrich,
MV> On Thursday August 29 2013 05:42, you wrote to me:
MV>>> Apart from the impossibility of changing P4,
US>> p407, 8.1 isn't a blocker as all ZC's accepts the proposal to
US>> move forward with the voting mechanism
MV> The last time it was tried it already failed at the first step:
MV> getting a majority of the RC's to say "yes".
at the first step ?
you're building your house from the roof tops ?-)
and then you probably didn't had a masterplan to move this project
to success ... ?!? ?-)
MV> Six month work for some
MV> two dozen people - me included - to come to consensus about some very
MV> simple changes and it failed right at the first hurdle.
MV> And now that there is no IC, it will be even more difficult. You
MV> assume that a unanimous decision by the ZC's take the place of a
MV> decision by the IC, but I am sure not everyone will agree on that.
preparation, that starts before starting with main work
the planning period is still to use seriosly, to identify blockers,
eg missing IC ... you have to put in extra steps, but this also is a chance to
get the required people involved, before the main project part starts
eg. start with interviews with the ZC's to get their viewpoints, what is
possible, what is a NO GO ... at this step you also can request their
anticipates, how difficult it is nowadays to get response from the RC's and
NC's of the included regions and nets. Furthermore, how deep an antipathy exist
to update an essential document
Another essential topic in project planning of Policy Update is PR - public
relations ... communicate the changes, how Fidonet will win if a specific
update will be incorporated. How each member receives an advantage if a
specific paragraph will be updated and what it does mean for the future of
Fidonet ...
MV> Sorry Uli, I know when I have lost. I know the theory of changing P4,
MV> and I also know that in practise it is impossible.
you didn't yet show up the real show stoppers or blocking factors
The missing IC can be a show stopper, but this needs some investigation
before it can be concluded, that it is a blocker
there were rumours all around over the years to update P407 as it is outdated
since about 15 (?) years ... there is enough potencial support, the question
is, does it count for a majority ...
The best way to get an overview is to ask around first, then start with the
work ...
MV> It has been tried
MV> many times and it has always failed. If you want to try again, go
MV> ahead, but count me out. I have better things to do than to waste my
MV> precious time on a mission impossible.
US>> 51% of all votes will bring the proposal POLICY to effect
MV> You conveniently skip a number of steps....
the two potential show stoppers known from current Policy revision
is the proposal before IC (solution: bring all ZC's to accept proposal)
and the 2nd one, to receive 51% of all votes
from the casted votes out of the group of *C structure at and above NC
This is less a problem, if its well communicated down to all nodes.
If there is concensus over a topic before the project starts, its
unlikely, that later the referendum will vote against.
The challenge is, to bring all controverse topics upto a point, where a
majority can accept it.
When last try to update Policy did happen? Was it in the 90's ?
Today many sysops try to find workarounds around the P407 restrictions
discovered. All attempts in updating software with new features, that
is based on bending the Policy as possible, is a strong signal, that something
needs to be changed and brought in sync to todays knowledge about
communications.
About 15 years after the last referendum there is a good chance to move forward
with a new referendum, with all the experience we've collected over the
past 24 years P407 has been voted to effect.
MV>>> a complete (physical) restructure of Fidonet is suicide.
MV>>> In Dutch we have a saying: "je moet
MV>>> oude bomen niet verplanten". I think that applies to Fidonet.
US>> old fidonet still works together with the last big change -> FoIP
MV> It barely survived that change.
What are the topics that leads you to this conclusion ?
I come to the opposite conclusion ... why approx 90% of
all Fidonet traffic is handled today via FoIP ?!?
MV> And we are down to less than 5% of what we ever were.
yes, we all do know this very well ... that by end of 90's
the majority of online users moved to internet services
MV> We are hovering near critical mass. Fidonet will
MV> not survive another radical change.
So why did Fidonet survive so a long time ?
with introducing FoIP, we're nearby internet services, but this
is only half of the truth.
Facebook, Twitter, Google and many other internet "services"
are centralized systems ...
Fidonet still continues to work decentralized.
The physical layer that is used doesn't matter .. as long there are
enough systems (nodes), who can exchange partly the overall traffic.
If one system dies, another system recovers operation.
There is a similar idea with filesharing in the internet -> torrents
that builds up a decentralized filebase. Thats why fidonet today has a minor
role on frequests, but still continues to distribute mails
Why Fidonet'ers don't using forums and mailing lists? 'cause forums and mailing
lists are centralized systems. If the central server goes down, the mailing
lists and forum stops working. Fidonet still continues.
Look to the lavabit example ... email service provider has been shut down (for
whatever reason) .. the service died.
Fidonet's content is a balanced restriction and openess. If one node dies, the
rest of fidonet still continues to operate.
Probably you've also have heard about messages that in Egypt's spring fidonet
tooks a role ? ... one can belief it or not ... but looking deeper it makes
sense, to have a decentralized "organisation" running so that in case half of
the network has been shut down, the 2nd half still is operational alive ...
This is todays message, that realy makes Fidonet
in Tom Jennings ideas to have a universial, decentralized communications
network, where each one may connect another without having a dictatorship that
allows one to cut down the whole net.
Why do we block down possible alternate transport media with restrictions
written into policy, why we aren't able, to correct these clauses, so Fidonet
becomes future minded and open to systems that makes the heart of Fidonet -
decentralized operations over well defined FTN standards that doesn't limit
communication down to one transport media only
My vision:
to give up the exclusivity of one transport layer only
from -o-o--o---o-o-----o---o-o-o---o-o---oo-o--o--o--o-----o--o-
by break down the barriers that prevents us today to move
forward with an elevator concept
to support multiple transport layers
to -o-o--o---o-o-----o---o-o-o---o-o---oo-o--o--o--o-----o--o-
| | | | | | | | | |
-o--o-o---o-o---o-o-----o---o-o-o--o-o--o--o----o-o-o----o-
| | | | | | | | | | |
-o-o--o--o--o-----o-o-o-o-o---o-o---oo-o---o-o--o-----o--o-
| | | | | | |
---o---o-o-----o----o--oo---o-o---oo----o--o--o-----o-o-o--
One potential candidate has been named in the meanwhile:
"HAM" packet radio maybe such an addtl. transport layer
Others may follow ...
A subliminal anxiety of publishing content in the internet is not
that is intended by this concept. Its an open looking forward by the
question, what may happen tommorow, if one switches off the
centralized internet routers, than probably from one day to another
all internet and mostly all phone traffic (in the western world)
will be shut down.
Today we're using POTS and by bending Policy also IP ...
to add more physical layers we have to bend Policy again.
Is this what we want? or do we want the Policy updated
to make it possible to extend the Fidonet capabilities
to switch easily the media to continue with communication ?
MV> Cheers, Michiel
MV> -$- GoldED+/W32-MINGW 1.1.5-b20110320
MV> $ Origin: http://www.vlist.org (2:280/5555)
regards, uli ;-)
---
* Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)
|