<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 3/30/2014 5:42 PM, Dean Gibson AE7Q
wrote:<br>
</div>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Responses inline, bolded in blue:<br>
<br>
<div class="moz-cite-prefix">On 2014-03-30 12:38, Bart Kus wrote:<br>
</div>
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Dean,<br>
<br>
Thanks for outlining that approach. I have a few questions:<br>
<ol>
<li>Where is the protocol for zone updating documented? I see
RFC 2136, but I don't see where it uses authentication
anywhere. How does the authentication work here? <font
color="#3333ff"><b>DDNS uses "TSIG": <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://en.wikipedia.org/wiki/TSIG">http://en.wikipedia.org/wiki/TSIG</a></b></font><br>
</li>
<li>Is the authentication Part97 compatible? <font
color="#3333ff"><b>Not sure (see below); it's a signature
process using hashing.</b></font><br>
</li>
<li>Once an update session is authenticated, are there any
further provisions for integrity checking during the (I
assume) TCP? Are there HMACs sent along with it, or one
giant signature at the bottom? <font color="#3333ff"><b>I'm
sure the details are in the above link and its
references.</b></font><br>
</li>
</ol>
</blockquote>
</blockquote>
<br>
Thanks! It does indeed look like TSIG is P97-compatible. Good to
know, we may use it as some point.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<li> <br>
</li>
</ol>
I don't think we'll be able to use this approach for a few
reasons:<br>
<ol>
<li>It seems to rely on a shared secret. <font
color="#3333ff"><b>Yes.</b></font> We have a goal of
being fully autonomous with no degradation in network
services when all other means of communication are down. <b><font
color="#3333ff">Yes, that's the whole point of using
multiple 44.x.x.x DNS servers.</font></b> Passing
shared secrets around securely under Part 97 is impossible
as far as I can tell. <font color="#3333ff"><b>I'm not
sure I agree (see below).</b></font> They need to be
"encoded for the purposes of obscuring their meaning" -- the
exact thing the FCC forbids, in order for them to remain
secrets. <font color="#3333ff"><b>There is no "meaning"
other than "authenticate me" (see below).</b></font></li>
</ol>
</blockquote>
</blockquote>
<br>
If you're referring to the use of TSIG as a signature at the end of
a message, then yes, that hash is not encrypting any information,
it's simply signing something as being legitimate. But when you're
talking about getting a private key from point A to point B over the
network, and encrypting it during transmission so that it's not
visible to others, then I believe that's violating FCC regulations.
That's what I mean when I say we can't use PSKs: because their
dissemination is not compatible with P97, even though their
application is.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<li> Asymmetric cryptography is our only option, and only
when it's used as an integrity or identity mechanism. <font
color="#3333ff"><b>How does this apply to using SSH over
the air, which WamWAN enables by the distribution of SSH
keys on the Wiki? SSH not only authenticates, it
encrypts >>>all<<< the traffic. </b></font>Because
of all this, we actively avoid any pre-shared-key (PSK) or
password-based systems in our designs. <font
color="#3333ff"><b>From a legal perspective, I see that as
a distinction without a difference.</b></font><br>
</li>
</ol>
</blockquote>
</blockquote>
<br>
Yup, we're in a bad spot here. Presently trying to figure out how
to enable SSH with authentication and integrity, but not
encryption. There are other alternatives being considered such as
IPsec(AH)+telnet, but they're far more gross than fixing SSH to be
P97 compatible. The problem is there exists no protocol in the
world that provides remote control over ham radio in a secure way
that respects P97. Hams haven't yet done the work to invent one.
We're trying.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<li> <br>
</li>
<li>Even though you can update one server by talking to DNS
directly, how does that change get to all the others? <font
color="#3333ff"><b>That's a fundamental feature of BIND.
</b><b>Historically, the slaves query periodically (on the
interval specified in the SOA record). However, more
recent (like the last decade) versions of BIND have the
master push updates to the slaves. This is true when
changes are made, whether or not DDNS is used. The
updates happen pretty quickly (within a couple minutes).</b></font><br>
</li>
</ol>
</blockquote>
</blockquote>
<br>
It was a rhetorical question to setup the answers in the indented
list below. :)<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<li> <br>
</li>
<ol>
<li>People update every single server explicitly? <font
color="#3333ff"><b>No; see above.</b></font> That's a
PITA, and when servers are down, they'll miss updates. I
wouldn't expect people to keep a retry queue on their
own. When servers are decommissioned/brought up this
would mean pushing a list of servers to users constantly.
<font color="#3333ff"><b>Not with BIND. Somewhere in the
44.x.x.x world there needs to be a fixed IP (multiple)
source of DNS info, just like the (13? or so) DNS root
servers. I've replaced my "root servers" file once in
ten years. Hopefully, things are not going to be so
dynamic in HamWAN that hamwan.net DNS servers are
going to be constantly on the move.</b></font> More
PITA.</li>
</ol>
</ol>
</blockquote>
</blockquote>
<br>
No need to worry about changes here. HamWAN authoritative DNS
servers shall forever and always(*) be on 44.24.244.2 and
44.24.245.2. These are anycast IPs from 2 different anycast
ranges. They're documented on the <a
href="https://www.hamwan.org/t/tiki-index.php?page=Core+Routing&structure=HamWAN">Core
Routing</a> page. A similar pair (.1) are allocated to recursive
DNS service. These should also be global and present in other
people's HamWAN instances in other states. A roaming client
wouldn't need to change a thing when going from system to system.
As we spin up Memphis and Michigan, we're helping those teams ensure
seamless compatibility.<br>
<br>
* = OK, we might at some point use different IPs for unforeseeable
reasons. Forever is a long time. But as far as the present design
of this, there's no need to change those IPs in the face of any
presently possible network changes.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<ol>
<li>You rightly mentioned we could do a master server, but
this introduces a single point of failure. <font
color="#3333ff"><b>There has to be one authoritative
source in any system. </b></font></li>
</ol>
</ol>
</blockquote>
</blockquote>
<br>
Distributed peer systems do not have this property. It's time to
shed those shackles and embrace a better tomorrow! A change can be
submitted via any node in the peer cloud. There is no master or
authority, other than the peer cloud itself. The challenge in such
systems is how do you resolve conflicts. SymmetricDS provides a
rich set of conflict resolution solutions. Also note that this
means not all nodes will always agree on what the data should be at
all times, but they will eventually come to a consensus. This is
fine for DNS and many other systems, as it just introduces a delay
while maintaining consistency in the long run.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<ol>
<li><font color="#3333ff"><b>BIND slaves do not become
inoperative just because the master goes down. For
extended outages, it's pretty easy to swap masters.</b></font></li>
</ol>
</ol>
</blockquote>
</blockquote>
<br>
Regarding swapping masters, the less human involvement in the face
of failure, the better. I automatically raise an eye when someone
says "If X breaks, we'll login and do Y". That's a fragile design -
one that relies on a human timely response. Right now we have "if a
link breaks, OSPF will re-route the packets", which is a fine
solution. Need more of that.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<ol>
<li> Another design goal of HamWAN is to be as
fault-tolerant as possible. A single special server
contradicts that goal when that site goes offline. <font
color="#3333ff"><b>Again, BIND does ...</b></font> Yes,
you can anycast the special server's IP, but then you'd
have an impossible (read: unsupported) zone-update
topology between the DNS servers.</li>
</ol>
<li>This introduces yet-another piece of cryptographic
identity for people to keep secure. I'd like to avoid
adding complexity when it comes to identity. I'd like it
all to boil down to your private key for your PKI key pair.
<font color="#3333ff"><b>I don't understand the
distinction. </b><b>A private key isn't conceptually
different from other authentication schemes. You have
secret files. I do agree it would be nice to only have
one key.</b></font><br>
</li>
</ol>
</blockquote>
</blockquote>
<br>
I wasn't making a distinction. It's just yet-another file to worry
about keeping private. Added hassle. Bad.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<li> <br>
</li>
<li>DNS is not the only piece of configuration people will
need to send to HamWAN when they want changes. Edge
firewall rules are another good example. I'm sure tons of
others will follow. For simplicity's sake, I'd like to
unify it all under a single configuration management system.</li>
<li>We don't use BIND. I've run it professionally and at
scale for enough years to have learned to avoid it. <font
color="#3333ff"><b>Well, I have more networked devices (64
distinct IP addresses as of this morning; all but six
currently online) in my house than are presently on the
HamWan network.</b></font></li>
</ol>
</blockquote>
</blockquote>
<br>
Depends how you define "on the HamWAN network". :) We only keep
track of modems, not the systems behind them. I've got something
like 15 boxes here that are connected, not sure what others have.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<li><font color="#3333ff"><b> They are all using DHCP (two
servers using failover) for the assignment of both
static and dynamic IP addresses. The two DHCP servers
update five internal DNS (BIND) servers. I don't think
</b></font><font color="#3333ff"><b><font color="#3333ff"><b>HamWAN
</b></font> will have to worry about scalability in my
remaining lifetime.</b></font></li>
</ol>
</blockquote>
</blockquote>
<br>
The BIND choice isn't about scalability, it's about stability. I
can take you through some awesome BIND failures I've seen over the
years. Let's do that not-in-this-email though.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<blockquote cite="mid:53387299.4090206@bartk.us" type="cite">
<ol>
<li> We use PowerDNS for our authoritative DNS service, and
Unbound for our recursive DNS service. Even though PowerDNS
will likely have equivalent utilities/configuration options
as you mentioned for BIND above, the other problems remain.</li>
</ol>
<p>So, what ARE we doing here? We've chosen to keep the data
which feeds PowerDNS in a PostgreSQL database. This shifts
the problem of updates and replication into the database
realm. The presence of said database also provides us a
fairly universal and highly adaptable place to keep all other
configuration and state information. The problem is now
reduced to just allowing users secure and Part97 compatible
access to PostgreSQL. That problem is solved by PostgreSQL's
support for certificate-based authentication of users. We
have not yet verified if the sessions PostgreSQL provides also
provide HMAC support after the identity is established, while
avoiding encryption. If that's possible, then great, we're
done. If not, we can do some further work to make that
happen.<br>
</p>
This still leaves the problem of how to avoid a single-master
single point of failure scenario. Luckily, we've figured out
how to turn PostgreSQL into a true multi-master (that means
write-anywhere) database by the use of a piece of software
called SymmetricDS. <font color="#3333ff"><b>[Idle comment: I
use PostgreSQL 9.0 replication among four PostgreSQL
servers, using "hot standby".]</b></font> There's nothing
particularly magical about this software, I'm sure we could
implement an equivalent in-house, but why bother when someone
else has already done it! East PostgreSQL server listens on a
pair of anycast IPs, which are pointed to by a single DNS
record. No user configuration or re-routing required when
database servers or network links go down!<br>
<br>
So at the end of the day, we've got a fully redundant
multi-master database, that is modifiable by users using Part97
compatible protocols, using their single identity to keep things
simple, available via a single DNS name and pair of anycast IPs,
which happens to have authoritative DNS as one of the
configuration items it stores. This is absolutely foundational
to our future success in other services.<br>
<br>
Now for the big fat disclaimer. I've been extremely busy
lately, and the reality of what's actually up and running is: a
single instance of PowerDNS, a single instance of PostgreSQL,
and no instances of SymmetricDS. We haven't verified the user
access protocol. Right now we're at the stage of flipping some
triggers into stored procedures, since a design mistake was made
with the schema. We may or may not write some middleware to sit
in front of the database and terminate the user sessions, I just
don't know yet.<br>
<br>
While custom software that's Part97 compatible is do-able, and
we can release multi-platform solutions for simple command-line
configuration management, the web aspect of things is harder.
There is an open problem around how do we use existing web
browsers in such a way that's Part97 compatible and yet
authenticated and integrity enforced. HTTPS with null cipher
used to be an option, but all the browsers decided to "improve"
their software and removed null cipher support. The one thing
on the horizon that looks promising is WebCryptoAPI, which could
allow for JavaScript to HMAC all requests using the installed
private keys, without having direct access to the private keys.
The <a moz-do-not-send="true"
href="https://www.hamwan.org/t/tiki-index.php?page=Authentication&structure=HamWAN">Authentication</a>
page lists all the solutions we've brainstormed to date. Feel
free to address this problem space too.<br>
<br>
--Bart<br>
</blockquote>
<br>
<font color="#3333ff"><b>In conclusion ...,</b></font> the issues
here in my mind:<br>
<br>
<ol>
<li>Encryption: FCC Part 97.113 prohibits <i>"... </i><span><i>messages
encoded for the purpose of obscuring their meaning, except
as otherwise provided herein ..."</i>. The exceptions
have to do with <b>communication control</b> (model
aircraft and spacecraft) and not message content. I would
think the FCC would accept encryption as part of
authentication (that's part of securely <b>controlling the
communication</b>), but not message content.</span></li>
</ol>
</blockquote>
<br>
As far as HMAC and identity hashes go, I agree.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> In other words, what is the <b>intent of any
obscuration</b>?</span></li>
</ol>
</blockquote>
<br>
I'd also say that the output of a hash function when used as a
message or identity signature is not obscured in any way. The
signature is transmitted in plaintext over the air for anyone to
inspect. The signature is the message, and it obscures nothing. In
the case of HMAC, it signs the plaintext content preceding it right
on the air. Truly everything is out in the open.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> For example, SSH (commonly port 22) and HTTPS
(commonly port 443) would be out, as would the equivalent
secure eMail protocols (ports 993, 995, 465, etc...), as
clear meanings in the <b>content</b> are obscured.</span></li>
</ol>
</blockquote>
<br>
Yup, and hams need to get off their collective butts and fix this.
There is no protocol known to me which allows hams to have secure
control without also engaging encryption of the content.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> There is no "meaning" in a secure signature key
(other than "keep out"); the endpoints of the connection
are visible. It's the remaining/attached content that
matters.<br>
</span></li>
<li><span>Redundancy: I appreciate that goal. However, true
redundancy requires either simplicity, or a long industry
history that proves the complexity to be reliable. If
nothing else, <b>the computer world is littered with
complex solutions </b><b>that don't work (or work well).</b>
I see the HamWAN design heading down that road.</span></li>
</ol>
</blockquote>
<br>
Yeah, but I aspire to provide the best solutions I can. I've got no
interest in releasing half-assed designs. Anyone can do that and it
doesn't advance anything. Complexity does not equal failure or
unusability. It's all about wrapping all the complexity into a
simple user experience in the end. Cars are incredibly complicated
things, but they boil down to a wheel and some pedals for the end
user. Right now HamWAN is at the stage of assembling engines in the
factory. There's a lot of engineering work to go around. To help
users cope with all the changes and exposed complexity happening
right now, we're suggesting the shared administration model. Since
you chose not to participate in that, you need to keep up on your
own. I would also point out that you allow Comcast or whoever your
ISP is to manage your modem, since they don't even give you a
choice. Could you imagine what Comcast would have to deal with if
they had to call up every user to do something on their end every
time they changed DOCSIS channels on the network?<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> Meanwhile, we have some simple "wants" (not "needs")
that aren't being addressed, due to a future "perfect"
solution. I would much rather adopt a scheme that works,
and then improve it later as needed.<br>
</span></li>
</ol>
</blockquote>
<br>
What do you want/need right now? If it's DNS entries, we can do
that by hand. If it's a static IP, I wanted to use your modem as a
guinea pig for the BGP iteration of the design. Yes, I'm placing
design verification needs above your user satisfaction when I do
that. :) I've been working with WE7X on a non-BGP static IP setup,
but he's got an atypical situation going on there since he's a relay
site. Not a good test case for the typical static IP scenario.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> </span><br>
</li>
<li><span>How often are the DNS updates: Hopefully most people
will (other than when setting up) will have low-frequency
DNS updates, at least of nodes that they consider
"critical".<br>
</span></li>
</ol>
</blockquote>
<br>
Sounds like a reasonable description of the situation. No longer
sure how it fit into the larger picture of the email. :)<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> </span><br>
</li>
<li><span>People's time: I'd guess that most of the people on
this list have a full-time job. I'm probably the exception,
being retired. Nevertheless, I have only so much time to
give to <b>any</b> project as well. For that reason, I
think simplicity is important.</span></li>
</ol>
</blockquote>
<br>
Yup, as stated above, user experience being simple is important.
You're experiencing an unfinished network with all the complexity
out in the open. You've also made it harder on yourself by
disallowing remote access for network operator folks. That's a
personal choice you're of course free to make with your hardware,
but I think it's safe to say we're not gonna stop pushing for our
goals to keep the complexity you're chosen to take on low.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> Continuity (eg, among project member changes) also
suggests simplicity.</span></li>
</ol>
</blockquote>
<br>
Also, good documentation. We're documenting things as they get
finalized and publishing everything. Anyone not familiar with the
project but familiar with computers/networking, should be able to
surf that wiki and solve any problem.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<ol>
<li><span> Just one example:</span></li>
</ol>
<p><br>
I asked about a hostname automatically tied to my IP address. I
don't <b>need</b> a fixed IP address. It would just be nice
(not to mention simple) for some things (like running a DNS
server!). And it doesn't even have to happen in the next two
months (or more). But when I asked, the response was to offer
to set me up with BGP, so that I can roam. A complex solution
(?) proposed by someone who has very little time (and I don't
want to take any more of that time than is necessary).<br>
</p>
</blockquote>
<br>
BGP isn't solely about roaming. It's also about security. The
protocol stack I need to verify is to ensure noone else clones your
MAC and steals your IP address and your traffic. The simple
solution in this case (static DHCP) is really vulnerable and not
suitable for wide deployment. See the <a
href="https://www.hamwan.org/t/tiki-index.php?page=Point+to+Multipoint+Authentication&structure=HamWAN">Point
to Multipoint Authentication</a> page for a (slightly outdated)
authentication sequence and main communication mode between cell
sites and clients.<br>
<br>
If this weren't part 97, things would be really simple. We'd throw
WPA2 up on the APs and everyone would get a login. Sadly that
encrypts things, so we can't use these industry standards on ham
radio. We're forced to go to great lengths to remain both secure
and compliant. You're experiencing the outcome of collective ham
laziness not having yet invented the digital future.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<p> </p>
<p>For the radio I have, <b>I don't want to roam; it took too
much effort to aim and mount the antenna !!!</b> (I presently
have a pulled muscle in my lower back from climbing around on
the roof.) If I want to roam, I will buy another radio and
antenna (they're inexpensive enough), and when I roam, I either
expect to have a varying DHCP address, <b>OR</b>, I will use my
first radio to keep track of the second radio's whereabouts,
just like I do now with my fixed IP-address DNS server in Boston
keeping track of my ISP's DHCP-assigned IP address here at home,
and updating DNS as needed.<br>
</p>
</blockquote>
<br>
I can confirm that when you roam, you'll indeed be able to pull
DHCP. Another option you'll have when you roam is that after you've
pulled DHCP, you can also engage BGP to announce a subset of your
allocation. For example, if your home has a /29 allocated, you can
announce just a /32 from that to your roaming client. The network
will re-route that /32 away from your home and to your roaming
client. Flexible!<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<p> </p>
<p>Remember, I don't <b>n</b><b>eed</b> a fixed IP address or a
hostname tied to it, all within the 44.x.x.x network. It'd just
be nice. I have assigned "hamwan.ae7q.net" to my (first) radio,
since it appears that the assigned DHCP address doesn't change
across disconnects of more than a day. Yes, it won't be useful
if only the 44.x.x.x network is available, but what have I lost?<br>
</p>
<p>Here are my interests in the HamWAN network, in decreasing
order of "importance" (I have no plans to save the world in a
catastrophe):<br>
</p>
<ol>
<li>Network access to the Internet via HamWAN, that reasonably
survives a low-grade catastrophe. I presumably have that now
(but no guarantees).</li>
<li>Network access to the Snohomish County DEM site. That's
more guaranteed than #1 above, considering generators at both
sites.</li>
<li>Network access to the full 44.x.x.x network. I have no idea
how meaningful this is. It's an area for tinkering.</li>
</ol>
<p>Remember, I bought the HamWAN radio/antenna (that was my reason
for coming to Puyallup this month), because of delays in the
Universal Digital Radio project. I wanted something that works
now, and Scott Honaker put me on to your project. I've now got
something that works now, and am grateful for the effort (past,
present, and future) that's gone into the HamWAN project by all
that have been involved. I would just like to tinker (the
amateur equivalent of "experiment") with some simple things
without waiting for the grand solution.<br>
</p>
</blockquote>
<br>
What are we blocking in your tinkering? The two examples you
mentioned (DNS and static IP) we can address right now. DNS we can
do by hand, and static IP is fairly static for you even with just
DHCP. I could do a temporary static DHCP assignment there but be
aware of the hijacking issue I mentioned. The temporary period will
expire when the Point to Multipoint Authentication protocol stack is
verified and deployed.<br>
<br>
What kind of tinkering are you thinking of doing? Perhaps some of
that information might drive some inputs to our design plans. I'd
like to know how people use the network in general.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<p> </p>
<p>Now, what do others want? I have no idea. I would have
thought that, in the past year, you would have more than a dozen
or so participants.</p>
</blockquote>
<br>
Me too! I think hams are really into the theory of being on a
microwave digital network, but not so motivated to go out and buy
the hardware, configure it, install it, align it, and integrate it
into their home network. I know of at least 2 examples where folks
have actually bought the hardware and have been in a coverage zone
for months, but just haven't deployed it. This may very well be a
ham culture issue. Ham radio has been very focused on analog voice
systems. Learning how to do digital network comms does take time
and effort. Time changes all things though, and I'm encouraged by
the new hams we've minted through this project. I'd like for us to
focus on ham-recruitment of digital-savvy folks in the future. They
may have an easier time of adopting HamWAN type technologies. And
of course, we eventually need to get down to an appliance solution.
There's a whole bunch of UI work involved with that. We need
programmers!<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<p> How did your last two weekend presentations go?</p>
</blockquote>
<br>
As well as could be expected, I suppose. I'm pretty sure I lost
both audiences, except for 1-2 guys in each one who had previous
network experience. These deep-dive talks that focus on a specific
subject are not appropriate for general audiences, so I'm calling my
experiment a failure and will be using other methods going forward.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<p> Granted that "location, location, location" is a big deal
here, I can understand some hesitancy, but hey, the investment
to try it out is minimal, especially with your "try it" offer.</p>
</blockquote>
<br>
Yeah, the trial offer needs more promotion. It's difficult to
structure it though from an accounting and tax standpoint. That's
why it's not on the front page. We need some financial people to
bring this to a wider audience. Or just some other entity we can
link to that can handle the trial hardware program. Perhaps some
clubs can step up or something, I dunno.<br>
<br>
<blockquote cite="mid:5338BA10.8040105@ae7q.net" type="cite">
<p> Of course, we're all in a "fringe" area of interest in
amateur radio ... too many think their handheld is what it's all
about. I'm reminded of a huge multi-agency EmComm exercise a
few years ago that I participated in. I was assigned as a radio
liaison to a fire chief, and when he saw I had a nice camera, he
told me to stow the radio and take pictures ...<br>
</p>
</blockquote>
<br>
BTW, I believe this is the longest email I've written in over a
year. Gotta knock that off. :)<br>
<br>
--Bart<br>
<br>
</body>
</html>