This election is important for the future of MICE. Please consider your choices carefully, and please make sure to vote. If you cannot attend the meeting, I encourage you to designate a proxy, which must be done in advance. According to the bylaws, you can do this by email to the Chief Manager. I believe that is Shaun, but if you want to be safe and nobody confirms who holds that role, send your proxy to Shaun, Jay, and Reid. Obviously, you should inform the proxy, too.

If you wish to vote for me, but cannot attend the meeting, you can designate Mike Johnston as your proxy. I assume Owen will also provide proxy instructions.

At the time of the MICE UG, I will be in San Francisco at the OpenZFS Developer Summit. I may be able to attend the MICE UG remotely, but I cannot commit to that. I definitely will not be able to attend in person. At the last UG when we were scheduling this one, it seemed like there were not a lot of dates that worked for the board, especially Reid. I felt it was better to optimize for the current board, so I did not ask for a date change.

I am a long-time MICE supporter. I have attended, in person, most of the UG meetings since I learned of MICE, despite the distance and sometimes the weather. I have also made a point of involving my co-workers. I contribute in other ways, including mailing list discussions, handling the routine website updates, and talking up MICE both privately and publicly (e.g. NANOG 65 Peering Personals). I secured a donation from my employer for MICE's Juniper service contract.

Overall, I think MICE is headed in the right direction. My top priority is, of course, that we complete the non-profit filing in a timely fashion. Immediately after that, we need to address financial sustainability.

Along the way, there are a couple items related to the participant versus member distinction:

• I would like to formalize the procedure for new connections. I am not envisioning big changes. We simply need to document the procedure and be explicit about the various states and steps. Specifically, we need to implement (as the board previously agreed) a process of participants requesting membership.

• In looking at the bylaws, we may need to make a small fix to address non-member participants (e.g. University of Wisconsin System). The current bylaws specify in 1.16(a) that a membership resignation results in a port disconnection. One might be able to play games by suggesting that they never accepted membership and thus did not resign, but this is hole that needs to be fixed anyway.

> PVLAN service.  What are your opinions on if MICE should offer it or not.

I do not think we should add features speculatively. If two or more participants have concrete plans to actually use a PVLAN in short order, I have no problem with it. As a volunteer-run exchange, the participants involved bear the responsibility to engineer and implement the solution, or convince someone to do it for them.

If implemented on the main switches, remote switch operators should not be compelled to (nor prohibited from) participating in PVLAN service.

> Do you see any major conflicts between your other affiliations/obligations and MICE?  I am interested both from the standpoint of availability, as well as from the professional interest point of view.

I am a board member (immediate past president) of the Thief River Falls Rotary Club. I am a board member of Instant Messaging Freedom, the non-profit foundation which assists Adium and Pidgin. I am a developer of Pidgin. I am a member of the ZFS on Linux team. I maintain a couple quasi-abandoned open source projects: docsis & pks. I maintain gbonds's Debian packaging. I expect no professional conflicts with any of these.

Time conflicts are always a concern. None of these roles are huge time commitments; the amount of time I spend on them is flexible. I have the full support of my employer for participating in MICE, so that comes out of work time.

The biggest potential for conflict is obviously my employment at Wikstrom Telephone Company, a MICE member and participant. (I also vote at ARIN on their behalf.) This is the same situation as the other board members and candidates. I see no problem navigating this through disclosure and, if necessary, recusal.

> Do you see the finical current model as sustainable for MICE?

I am skeptical that MICE can function indefinitely on ad-hoc donations.

> What changes would you suggest on the business side?

Long-time members may recall I was involved in previous planning for this.

Here is my current plan:

Expenses

First, we need to define what we need on the expense side. I believe everyone agrees we need operating funds to pay the year's bills (ARIN fees, etc.). My position is that we can accept the discounted Cologix rates as a given. That is subject to change at the expiration of our contract, of course, but that would be similar with a non-discounted contract.

Opinions on the capital expenses are more varied, but I think we have a broad consensus that we will need new switches over time. My position is that, moving forward, MICE needs to be proactive, not reactive, in planning for capital expenditures.

There are three reasons we need new switches:

1) Hardware failures

2) Bandwidth growth

3) New members

All of these rely on estimates. Reasonable people can disagree, so we can adjust based on member consensus. The important thing is that we not lose the budget forest for the trees. We need to get started with something, and we can adjust over time.

For #1, let's assume a switch needs to be replaced, on average, every 10 years.

For #2, let's assume 50% annualized growth. This is the "Nielsen's Law" number. That rate is higher than what I am seeing in reports of actual national averages, but lower than my employers' actual bandwidth growth. A 50% annualized growth rate means an order of magnitude port speed increase occurs every 5 to 6 years. When it comes to planning for new switches, the particular port speed is something which will be determined at the time of purchase. That is, last year's 10G might be next year's 40G or 100G.

For #3, it is very hard to predict. We cannot extrapolate from the bootstrapping days of MICE, as it is unlikely we will continue to add members at the same rate. As a starting point, I would suggest we round #2's timeframe down to 5 years and then keep a close eye on what is actually happening. Adding this all together looks like this:

1) We estimate the current replacement cost of each switches. We subtract the amount we currently have budgeted. (At the start, that's zero.) We calculate the years remaining (10 years minus how long we have owned the switch). We divide those two numbers to determine how much we need to budget per year for hardware replacement.

2) Of our fastest port type, we currently have two switches. So we need to plan to replace those with two switches of the future port speed, at some point. We take the cost of the Juniper 10G switch when we purchased it. For each 10G switch, we take that cost, subtract what we currently have budgeted (zero), and divide that by the remaining time in the upgrade cycle (5 years minus the length of time we had the switch). This gives the amount we need to budget per year for port speed growth.

Adding operating costs plus the capital costs defines our annual need. This is independent of how we recover these costs.

Income

On the income side, there are many possible models. I start by defining goals. Note that here I am talking about various types of fees which are possible.

• We recover our budgeted costs.

• Members are treated equally.

• If there is a member fee, all members pay it equally.

• Participants are treated equally.

• If there is a participant fee, all participants pay it equally.

• Remote switch operators are treated equally.

• If there is a remote switch operator fee, all remote switch operators pay it equally.

• Port users are treated neutrally.

• If there are port fees, port users pay based on their port types/counts.

• I oppose giving free ports to eyeball networks.

• I oppose giving free ports to content providers.

• I oppose differentiating non-profit versus for-profit.

• PCH is an interesting edge case, because they are providing services for the Internet itself. I could accept them as a special case, if there was broad member consensus. A better answer, though, might be for the subset of interested members to donate to PCH to cover their fees.

• We should not create perverse incentives on port speeds.

• For example, if a 10G port costs ten times as much as a 1G port, we could see 4x1G or even 8x1G LAGs used rather than the preferred 10G.

• Likewise, but less so (as port users' equipment costs act as disincentives), setting the prices the same may result in smaller port users utilizing 10G ports when 1G ports would be more than sufficient.

• To address these concerns, the previous proposal put the "relative value" at 2x.

Finally, here is my proposal of which possible fees to actually charge:

• There should be a member fee, which is mandatory.

• This formalizes whether or not you have voting rights within MICE.

• The extra step weeds out participants who have no interest in governance, which helps with quorum issues. (This may allow us to raise the quorum requirement, which was desired by some members.)

• This fee should be a token amount.

• Failure to pay the member fee results in a termination of membership (and thus voting rights), but not other statuses (e.g. participant status).

• There should be a participant fee.

• This fee should be a small amount.

• We might set the amount based on the ARIN costs.

• For the initial implementation, participant fees should be "optional". We would invoice for them, but not enforce disconnections for failure to pay.

• We can revisit this item once we see how things go.

• There should not be a remote switch operator fee.

• I do not see any costs to recover here.

• There should be port fees.

• This fee should be a large amount, relative to other fees. This is how we recover the capital costs. This is also how we recover the service contract costs.

• For the initial implementation, port fees should be "optional". We would invoice for them, but not enforce disconnections for failure to pay.

• We can revisit this item once we see how things go.

Determining the actual fees is a math exercise given the inputs above.