18 Apr
2014
18 Apr
'14
2:12 a.m.
Hi all,
I've read each of your replies, but to reply to each one in depth
individually would really flood the list, so let me address the main
points here in one email. First though:
Brian and Board, can you share the details of how board members become
board members? There is widespread confusion about this as the bylaws
don't really seem to address new director election / appointment procedures.
Can you also state for the record how many directors ARDC has right
now? Some sources I saw show only 1 (Brian), other sources show 3 (is
this current data?). Are there minutes or other records of how these
directors became directors? That might shed further light on the
process. Surprisingly, the state of California does not seem to require
that directors be registered. In Washington we have to list our
directors as part of public record.
Now, onto the replies...
Many of you made good points that I agree with. Improved transparency,
better statements, continued free access, etc. There seems to be
universal desire being expressed for such changes in ARDC. I also like
the idea of treating ARDC as a RIR, but at the same time, the ARDC is a
really *handy* place to define some optional interfacing standards, so I
wouldn't want to do away with that side of things. In short, where
there is agreement, I don't think there's much for me to say, so let me
move on to some of the contentious issues.
Hi lleachii / KB3VWG! I've spent hours (both in public and private
threads) trying to foster your understanding of a one-line router change:
ip rule add from <your 44net> table ampr
I've given you explicit packet flow explanations for every permutation,
but ultimately you're still insisting on more and saying you're taking
the change for review by your engineers. This indicates to me you don't
actually understand the change and/or how Linux does routing. I can't
be responsible for everyone's education. I've given you the time I
consider proper but at some point I need to stop.
The other thing I realized during our discussions is that even if I do
manage to convince you that it's a wonderful change full of unicorns and
rainbows, what does that mean for the outcome? Will AMPR adopt it as
part of some official standard? Will Brian immediately sign off? No!
It's me simply convincing one man that if he wants to talk to my
particular 44net, he can do it by using the mentioned technique. The
return on investment here is particularly poor.
The real root of the problem here is the lack of an official ARDC / AMPR
decision making process. Do I have to convince everybody? Do I have to
convince Brian? Do I have to convince a majority of the 44net members,
or board? Do I not have to convince anyone and just log the suggested
process on the wiki?
Until these questions are answered, anyone trying to do development is
fighting an uphill battle and investing more hours than are needed to
accomplish any given thing.
In the interest of progress, after I broke off the thread with you, I
started a new thread with Brian to enact my simple IP gateway request,
fully accepting the fact that other people may not be able to talk to my
network after the change went through. This got referred to Chris,
whose ultimate reply to me was that the gateway change was "not
permitted". It's not clear to me who is in charge of such decisions and
such permissions to this day.
Having exhausted the normal methods, here I am running for board, to fix
and eliminate such gridlock for anyone else who would like to push AMPR
forward. The present organizational environment is not conducive to
innovation.
Now, as to your other points:
I do not wish to "tear down and rebuild the infrastructure from the
ground up, all other nodes be damned, as long as HamWAN works". You've
worked with me on 1 change, and in that case I gave you a compatibility
solution. JNOS' lack of policy routing may require a different solution
which can come later (eg: extra routes, eg: different gateway list,
etc). If that means JNOS nodes can't reach my network in the interim,
that's OK by me. At least progress has been made.
Regarding "I've asked Bart to contribute the changes he wishes me to
implement on our nodes": I've never actually asked you to implement
anything. You can if you'd like to participate in testing and
development, but you're not required to maintain communication with my
network. It's your network, do with it as you please! Many AMPR
networks don't even have gateways listed. There are plenty of other
folks who are willing to help me test IPIP anycasting, with much less fuss.
The following is just blatant disinformation: "I was shocked when I
realized thier lead guy was the one wanting to tear current
infrastructure apart simply to make HamWAN work with AMPRNet as he
envisioned it, leaving connectivity gaps, not providing a routing 44GW,
etc." Nothing is being torn apart or destroyed. I'm experimenting with
my own 44net allocation and it has no impact on how other people talk
amongst themselves or to UCSD's gateway. At worst, people may not be
able to talk to my network in all cases, and that's a choice that's OK
for me for the time being. Perfection can come after version 1.
Next: "I understand he has his own ASN and therefore probably a pretty
good infrastructure; but it is a commercial outfit." HamWAN is a
non-profit organization, and we do take donations of money or other
resources such as, in this case, an ASN donation. This does not mean
that the name on the ASN is the owner of HamWAN.
Next: "UCSD has been very gracious to HamRadio over the years, and
anyone wanting to make such drastic moves will probably also want to
move the AMPRNet NOC." There is no "NOC", it's a simple peering point
where 44/8 is announced. You don't have to speculate here. As part of
my listed agenda, I stated my desire to create more peering points like
this to eliminate the single point of failure we now have with UCSD.
This does not mean removing UCSD from the equation. Other regional
peering points like this already exist, we just need broader coverage.
Regarding the ARIN comments, I agree ARDC should not sign the ARIN
Legacy Agreement. I still want to see the legal heritage of 44/8 to see
exactly how ARDC can resist any take-over threats. These documents
should be on the website somewhere. How did ARDC come to own 44/8?
What is the documented chain of ownership? What's stopping AnyCorp from
saying the IANA table entry is wrong and AnyCorp owns 44/8 instead?
RFC790 shows ownership of 44/8 falling to Hank in 1981 (which may be
contestable for lack of an NSF letter or something). Where's the chain
of ownership up to 2011's incorporation of ARDC? It's important to get
your ducks in a row as the IPv4 crunch intensifies.
Finally, I don't even know how to respond to this fantastic bout of
paranoia: "Now he reappears lobbying for a board position in lieu of
working to fix his perceived "issues" with ARDC - citing old technology
and old ideas; all one can be left to assume is he want's to disamble
AMPRNet for the 190 other states on the planet, control 44/8 and ARDC -
still not offering anything to the software, processes or services
within AMPR until he has control; basically, a HSMM Radio coup." You
seriously think I'm spending all this time developing HamWAN and dealing
with issues here so I can execute some evil plan? I see an organization
with gridlock and poor governance here, and I'm offering my services at
solving those problems. We don't have problems like this in the HamWAN
org. The doers are empowered with clear processes and red tape has been
removed. The board is elected based on merit, not legacy. Time spent
campaigning is limited to keep everyone focused on what matters - NOT
politics. Voting is transparent. Anyway...
Hi John / K7VE!
From your email: "A lot of people contribute time, we need more that
contribute money." Can you share what ARDC uses the money for? Having
looked over the financials, I'm not seeing any spending details.
Next: "Should the ARDC evolve into a club with members and dues". I'm
generally in favor of this model, but the dues should be optional and
should only entitle you to voting rights. That forces you to have some
skin in the game before affecting the org with your vote. Some other
"skin" techniques were also suggested, like having an allocation or
running a gateway. These are probably appropriate. I also like the
staggering of directorships.
Next: "where it could be formally voted into existence". Voted by who?
Next: "I have advocated a model of using BGP and the Internet to sew
together regional networks into a complete fabric and that those
regional networks could then address "last mile" issues with IPIP or VPN
tunnels as appropriate. I'd like to see this formalized and adopted
sooner rather than later." You're just describing "using the Internet"
here, aren't you? Do you have more details on this proposal? This
sounds really similar to the "more Internet gateways" line item of my
agenda. Are we talking about the same thing?
Next: "As to Bart's "candidacy" for a Director's position. That is
premature, based on the current governance and structure of ARDC." ARDC
is what exists right now. There's no need to wait for a re-birth to fix
some of the problems. We can work with what we have. I don't want
Brian replaced by a new org. His service over the last 20+ years shows
a tremendous dedication to this network. His continued contributions
will no doubt be beneficial. I simply want ARDC to become more open,
better governed, and positioned in such a way that it fosters innovation
and experimentation. You know, the stuff in the charter! :)
Next: "Frankly, I think Bart has accomplished a lot in the last couple
of years from a technical point of view. I happen to live in the area
where HamWan is being developed and the progress seems to be constant.
The problem is, Bart, like many driven technology experts, can come off
as dismissive and narrow-minded, and that isn't productive." This quote
claims that I've both managed to accomplish a lot, and then concludes
that I'm not a productive leader. You're gonna have to pick one. I sit
in a room day in day out with 35 other people and guide decisions, set
goals, and push people beyond their existing limits. All for the shared
end goal of providing the best network we can. I've brokered many deals
to get us the resources we need to operate, some of them requiring
incredible tact. You're not exposed to any of this though, since you
don't develop HamWAN. Those who have actually worked with me have
voiced their support on this mailing list. I didn't ask any of them to
say a thing on my behalf.
I can only speculate you're probably thinking of the HamWAN / HSMM lack
of interoperability that was strongly requested during our initial
phase. As much as people wish for this, there are several reasons a
smooth interop cannot be done. (1) HSMM is Part 15 and we can't carry
that traffic on Part 97 frequencies, (2) The use of 10/8 address space
makes HSMM non-interoperable -- not just with HamWAN, I mean with almost
every other network, and (3) the design of the HSMM organization is
decentralized on purpose, so even if we were to offer some interop
standard, there's noone there to reach an agreement with. The present
situation is this: HSMM folks are free to use HamWAN however they wish.
They simply connect to the network using our documented procedures. If
they wanna run VPNs over the microwave, that's fine. They're hams and
they have a right to do whatever they want on the airwaves as long as
it's legal. There are no special provisions on the HamWAN side to
provide for end-to-end traffic between HSMM nodes. That's all up to the
user.
If you're thinking of some other situations, I don't know what to say.
If you're gonna be a man that accomplishes substantial goals, you're
gonna invariably piss some people off about something. That's the cost
of getting things done.
I wonder if this email has exceeded 32kB yet. If I failed to address a
burning point in an email you sent on this subject, please follow up and
let me know.
--Bart