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