New subject: Running for ARDC director position

18 Apr 2014

44net-request(a)hamradio.ucsd.edu wrote:
...
  Subject:
 Re: [44net] Running for ARDC director position
 From:
 Tom Hayward &lt;esarfl(a)gmail.com&gt;
 Date:
 04/17/2014 08:23 PM

 To:
 AMPRNet working group &lt;44net(a)hamradio.ucsd.edu&gt;

 I believe Bart got frustrated with the lack of change-management and
 specifications in AMPR. How your script is written depends on these
 things. 
What we see every time again when those issues are discussed is that there are people
who approach AMPRnet not as a hobby amateur packet radio network, what it is, but as an
extension of their network at work, usually they work in a professional datacenter or at
an ISP.
They want documentation and specifications because that is what they have at work.
But this is a hobby, and there are not going to be specifications and documentation until
someone who feels the need for them is going to write it.  And they do not volunteer!
The usual way to gather information has been to ask here, and possibly to dig in the
archives
of this list.  That may be a frustrating endeavour for a professional network admin, but
for the
average hobbyist it is a learning experience and a way to get things working by gradually
tweaking the configuration.

Please note that once you got everything working, it is pretty much useless.  So we
should
not take away the challenge of getting things working.  When there is a clear recipe to
get
everything working, or worse yet: automatic configuration, what reason would there be
left
to start the experiment to begin with?  A lot of AMPRnet is about learning, not about
achieving
the end result: a perfectly working network.  Because the fun ends once that goal is
reached.

Another thing I want to note is that Bart and some of his peers like to use a lot of
inside
terminology they speak with their colleagues at work.  They disregard the fact that the
people on this list are radio amateurs, people with a technical interest but not experts
in
internet technology as he is.  Every couple of months the same discussion springs alive
and
people start to pingpong technical terms between them and lose everyone else.  And worst,
they don't hesitate to slash the existing system, claiming all the time that it is
legacy
technology, that it is very unreliable, that it has to be replaced by the stuff they use
at work
because at work everything is so much better, etc.
But remember: that is at work.  And this is our hobby.  We may have different objectives,
like being able to comprehend things.  It may well be that the optimal solution for an
amateur
packet network is not the one that is optimal for the large internet with the professional
admins.
We also use NBFM to talk to our friends, a technology that is considered
"legacy" by the
professionals as well.  Some even use morse code.  They are not going to abandon that
because all the professionals have switched.

...

 It seems that to be allowed/compliant in AMPR, it just has to work
 with the existing system. But what is the existing system? There are a
 lot of existing systems and most of them are not documented. For
 example, we learned via the mailing list that many AMPR gateways have
 a static route to 44/8. This isn't documented in the encap file, it's
 just added by their scripts. Where is the specification for this? 
I don't think many gateways have a static route for 44/8.   I certainly don't have
one myself.
I could add such a route (as a null route), maybe that is a good idea.  I'll think
about it.
What I do have is a default route in table 44 that points to amprgw.   But the purpose of
that
is NOT to serve as a route for 44/8, its purpose is to route everything OUTSIDE 44/8 back
out via amprgw.   I require that because my ISP acts responsibly and has BCP38 in place.

In the past, before I installed ampr-ripd, I manually ran a script that downloaded the
encap
file and installed the routes.   I never put that in a cron job because the server for
that file
failed so often and I felt it was better to monitor the process and fall back to the
previous
encap file when things went wrong.
As a result, my routes were often not completely uptodate and it was a good idea to route
traffic for which I had no correct tunnel route back to amprgw.   In those days that still
worked,
amprgw (mirrorshades in those days) would forward that traffic to the actual gateway.
Nowadays amprgw does not perform that function anymore, so indeed it good be a good idea
to add a 44/8 null route.
But I don't think small issues like this warrant all the uproar, and I think it is
much more fun
to discuss pro's and con's of a certain configuration on the list than to throw
stones at the
existing system and demand everything to be overturned to look like an enterprise
network.

Rob