“Before I went to IETF 126, I wrote that technical standards were never outside politics.”

I still believe that. More strongly now, unfortunately.

That earlier post was about the discomfort people feel when the word “political” gets anywhere near technical standards. Standards people often prefer to think of the work as cleanly technical: protocols, interfaces, formats, registries, security properties, deployment guidance. All very serious. All very precise. All safely outside the messier world of national interests, regulatory pressure, economic leverage, and institutional power. Except, of course, it never really was.

Technical standards encode assumptions about who can connect, who can speak, who can be trusted, who can be observed, who can be excluded, and who gets priority when values collide. That does not make standards work partisan. It does mean the work has political consequences.

I knew that before Vienna. What I came home with was something harder to sit with: recognizing that when nation-state politics enter the room, individual contributors have very little power.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

When the Room Gets Bigger Than the Room

That is not a comfortable realization for someone who believes in showing up, doing the work, reading the drafts, making careful comments, and helping improve the output.

Standards work depends on people believing that participation matters. You review. You object. You propose text. You listen. You compromise. You try again. You hope that good technical reasoning, persistence, and shared norms can keep the work pointed in a constructive direction. Most of the time, that still works well enough to be worth doing. But sometimes the forces shaping the conversation are much larger than the people in the room.

The Internet is not a quiet research network anymore; it hasn’t been for decades. Today, it is critical infrastructure, economic infrastructure, social infrastructure, surveillance infrastructure, public safety infrastructure, military-relevant infrastructure, and a major surface for both individual freedom and institutional control.

Every government has noticed. Every major platform has noticed. Every regulator has noticed. Every bad actor has noticed. Honestly, they would have to be asleep not to notice.

So when we talk about openness, neutrality, privacy, security, interoperability, resilience, and user agency, we are not talking about abstract architectural virtues. We are talking about live conflicts among governments, companies, communities, and individuals with very different ideas about what the Internet is for.

That changes the emotional texture of standards work.

Small Proposals, Larger Patterns

It is one thing to argue over a protocol mechanism because people disagree about deployment complexity or security properties. It is another thing to realize that a proposal may be part of a much larger pattern: more control at chokepoints, more regional divergence, more pressure for traceability, more assumptions that every interaction should be attributable to a legally recognized actor, more willingness to compromise global interoperability in the name of local policy goals.

Sometimes the proposal in front of you is perfectly reasonable on its own terms. That is the tricky part. Very few changes arrive wearing a sign that says, “Hello, I am here to help fragment the Internet.”

Instead, they arrive as practical accommodations. Local requirements. Compliance hooks. Deployment realities. Optional metadata. A small extension. A reasonable exception. A way to make the technology usable in one jurisdiction, one sector, one regulatory environment, one procurement context.

And sometimes those accommodations are necessary. That is what makes this hard.

The world has woken up to how powerful the Internet is. It has also woken up to how dangerous it can be. Fraud, exploitation, surveillance, abuse, disinformation, market concentration, child safety, national security, cyber conflict, platform accountability—these are not imaginary problems invented by people who hate packets. They are real.

A standards community that dismisses those concerns as someone else’s problem will become irrelevant. Possibly worse, it will deserve to become irrelevant.

But a standards community that simply absorbs every political demand into technical architecture without examining the consequences will also fail. It may produce specifications, but it will not preserve the properties that made the Internet worth standardizing in the first place.

That is the balance I am struggling with in my work with various standards communities.

The Bad Options

What can one person do to help maintain a decent balance between openness and neutrality on one side, and the demands of a world that now understands both the promise and the danger of the Internet on the other?

There are a few tempting answers.

One is to pick a single value and defend it vigorously. Privacy. Openness. End-to-end security. User agency. Global interoperability. Pick the hill and stand there.

There is dignity in that. Sometimes it is necessary. Standards work needs people who will say no, especially when everyone else is tired, and the room is trying to convince itself that the convenient compromise is harmless.

But there is a danger, too. If you defend only one shoreline while the tides are changing everywhere else, you may end up on a shrinking island. Still technically correct. Still morally satisfied. Still increasingly irrelevant to the systems people are actually building.

Another answer is to stay broadly aware and keep pointing out patterns. This is usually where I find myself. I watch different standards efforts, regulatory pressures, browser decisions, identity systems, security arguments, and governance conversations. I try to notice when the same assumption appears in multiple places, or when a small design choice in one area starts to rhyme with a larger shift somewhere else.

That can be useful. It can also make you sound like Chicken Little with a datatracker account.

Not every pattern is a plot. Not every proposal is a threat. Not every uncomfortable idea is evidence that the sky is falling. If you warn about everything, people eventually stop hearing you, even when the warning is justified.

A third option is to opt out entirely. Move off the grid. Build a bunker. Learn to grow potatoes. Possibly learn Chinese, depending on which geopolitical forecast is making the rounds that week. This has a certain emotional appeal after a long meeting. It is not, however, a strategy.

The Boring Answer

So I am left with the boring answer: Participate thoughtfully.

That sounds small. It may be small. But it’s not nothing. It’s not giving up on the process.

Participating thoughtfully means resisting the urge to sort proposals entirely by who submitted them. Provenance matters; incentives matter; geopolitical context matters. But a bad actor can make a technically valid observation, and a trusted actor can make a proposal with terrible implications.

If we only evaluate ideas by the badge in the room, we will miss both risks. So we have to read proposals for what they enable, not only what they claim to solve.

What assumptions does this design make about identity, authority, jurisdiction, consent, observability, or control? Who benefits if this becomes infrastructure? Who loses optionality? What becomes easier to mandate later? What becomes harder to protect? Is this mechanism that appears neutral in the abstract still neutral under predictable deployment pressure?

Optional features do not always stay optional. Metadata fields do not always remain harmless. Local accommodations do not always remain local. Compliance hooks have a way of becoming architectural expectations.

Turning Values into Review Comments

Participating thoughtfully also means distinguishing between legitimate policy needs and architectural overreach. Governments do have responsibilities; of course they do. Platforms have responsibilities, too. Users do experience real harms. But not every real problem should be solved by weakening the technical properties that protect everyone else.

Openness, neutrality, privacy, security, interoperability, and user agency are not vibes. They are design constraints. They need to be translated into specific technical questions, specific review comments, and specific proposed text. But not everyone will see the same pattern for when we drift from technical properties into overreach.

That is not the failure it might sound like. Sometimes the contribution is simply putting the pattern into the room so that others can test it, challenge it, refine it, or remember it later when the third “unrelated” proposal starts to look less unrelated. The whole point of having a diverse set of people in the room is to get those different perspectives.

No one can track everything. No one can defend every principle in every venue. The Internet is too large, the standards ecosystem is too distributed, and the meetings are too numerous. Pretending otherwise is a fast path to burnout and possibly unpleasant behavior on mailing lists.

So our work must become more disciplined. That means picking the areas to focus on. Staying connected to others so you have a community to work with. Building enough context to recognize when something is part of a larger shift. Perhaps most importantly, it means being willing to say, “I may be wrong, but I think this has implications beyond this document.” Then doing the more difficult thing: explain those implications in terms the working group can actually use.

Not Heroic, Still Useful

I wish there were a more heroic answer, but at the end of the day, most standards work is not heroic. It is cumulative. It is slow, procedural, and frequently irritating. It is a thousand small acts of review, clarification, objection, compromise, and memory. It is someone noticing that a term is overloaded, or someone asking who the relying party is. Someone pointing out that the privacy considerations assume away the most likely deployment model. Someone saying, again, that the user is a constituency, not a resource.

That work does not stop nation-state politics, but it can change what gets normalized.

It can make harmful assumptions visible before they harden into infrastructure. It can preserve room for better implementations. It can force tradeoffs to be named. It can keep global interoperability from being casually sacrificed. It can remind a room full of tired experts that technical elegance is not the only measure of success. And I think that’s what meaningful contribution looks like.

Still Showing Up

Meaningful contribution is not winning every argument. Nor is it pretending that a well-written issue comment can rebalance global power. It is showing up with enough context, enough humility, and enough stubbornness to keep asking what kind of Internet this proposal helps create.

That may not feel like much—goodness knows I had some serious conversations with myself about whether participation is still worth it—but giving up would concede the work to the people who are least troubled by the consequences.

And that’s something I’m not ready to do.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

Before I went to IETF 126, one of the bigger standards development meetings, I wrote that technical standards were never outside of politics.

I still believe that.

If anything, I believe it more strongly now.

That earlier discussion was about the discomfort people feel when the word political gets anywhere near technical standards.

Standards professionals often prefer to think of the work as cleanly technical.

It is about:

• Protocols
• Interfaces
• Formats
• Registries
• Security properties
• Deployment guidance

All of that is serious and precise.

And, conveniently, it can feel safely outside the messier world of:

• National interests
• Regulatory pressure
• Economic leverage
• Institutional power

Except, of course, it never really was.

Technical standards encode assumptions about:

• Who can connect
• Who can speak
• Who can be trusted
• Who can be observed
• Who can be excluded
• Who gets priority when values collide

That does not make standards work partisan.

It does mean the work has political consequences.

---

When Nation State Politics Enter the Room

What I came home from IETF 126 with was a less comfortable realization.

When nation state politics enter a standards-setting environment, individual contributors have very little power.

That is not an especially comfortable realization for someone who believes in showing up, doing the work, reading the drafts, making careful comments, and helping improve the output.

Standards work depends on people believing that participation matters.

You:

• Review
• Object
• Propose text
• Listen
• Compromise
• Try again

You hope that good technical reasoning, persistence, and shared norms can keep the work moving in a constructive direction.

Most of the time, that is true.

And that work still works well enough to be worth doing.

But sometimes the forces shaping the conversation are much larger than the people in the room.

---

The Internet Is No Longer a Quiet Research Network

The Internet has not been a quiet research network for decades.

Today, it is:

• Critical infrastructure
• Economic infrastructure
• Social infrastructure
• Surveillance infrastructure
• Public safety infrastructure
• Military-relevant infrastructure
• A major service for individual freedom
• A major mechanism for institutional control

Every government has noticed this.

Every major platform has noticed it.

Every regulator has noticed it.

Every bad actor has noticed it.

Honestly, they would have to be asleep not to.

So when we talk about:

• Openness
• Neutrality
• Privacy
• Security
• Interoperability

we are not talking about abstract architectural virtues.

We are talking about live conflicts among governments, companies, communities, and individuals with very different ideas about what the Internet is for.

---

The Emotional Texture of Standards Work Is Changing

It is one thing to argue over a protocol mechanism because people disagree about deployment complexity or security properties.

It is another thing to realize that a proposal may be part of a much larger pattern.

That pattern might involve:

• More control at choke points
• More regional divergence
• More pressure for traceability
• More assumptions that every interaction should be attributable to a legally recognized actor
• More willingness to compromise global interoperability in the name of local policy goals

Sometimes the proposal in front of you is perfectly reasonable on its own terms.

That is what makes this so tricky.

Very few changes arrive wearing a sign that says:

“Hello, I am here to help fragment the Internet.”

Instead, they arrive as practical accommodations.

There are local requirements to consider.

There are compliance hooks.

There is optional metadata.

There is a small extension.

There is a reasonable exception.

There is a way to make the technology usable in:

• One jurisdiction
• One sector
• One regulatory environment
• One procurement context

And sometimes those accommodations are necessary.

That is precisely what makes this difficult.

---

The World Has Woken Up to the Power of the Internet

The world has also woken up to how dangerous the Internet can be.

There are real problems involving:

• Fraud
• Exploitation
• Surveillance
• Abuse
• Disinformation
• Market concentration
• Child safety
• National security
• Cyber conflict
• Platform accountability

These are not imaginary problems invented by people who simply dislike technology.

They are real.

A standards community that dismisses these concerns as someone else’s problems will become irrelevant.

Possibly worse, it will deserve to become irrelevant.

But a standards community that simply absorbs every political demand into technical architecture without examining the consequences will also fail.

It may produce specifications.

But it will not necessarily preserve the properties that made the Internet worth standardizing in the first place.

---

The Balance Between Openness and Political Reality

This is the balance I’m personally struggling with in my work across standards communities.

What can one person do to help maintain a decent balance between:

• Openness and neutrality
• Privacy and security
• Global interoperability
• User agency

and the demands of a world that now understands both the promise and the danger of the Internet?

There are a few tempting answers.

---

Pick One Value and Defend It

One option is to pick a single value and defend it vigorously.

That value might be:

• Privacy
• Openness
• End-to-end security
• User agency
• Global interoperability

There is some dignity in that approach.

Sometimes it is necessary to stand.

Standards work needs people who will say no, especially when everyone else is tired and the room is trying to convince itself that a convenient compromise is harmless.

But there is a danger, too.

If you only defend one shoreline while the tides are changing everywhere else, you may end up on a shrinking island.

You can remain:

• Technically correct
• Morally satisfied

while becoming increasingly disconnected from the systems people are actually building.

---

Watch for Patterns

Another option is to stay broadly aware and keep pointing out patterns.

That is usually where I find myself.

I watch different:

• Standards efforts
• Regulatory pressures
• Browser decisions
• Identity systems
• Technical architectures

And I try to notice when the same assumption appears in multiple places.

I also watch for moments when a small design choice in one area begins to connect with a larger shift somewhere else.

That can be useful.

At least, I hope it is.

But it can also make you sound a little like Chicken Little with a data tracker account, crying panic left and right.

Not every pattern is a plot.

Not every proposal is a threat.

Not every uncomfortable idea is evidence that the sky is falling.

If you warn about everything, people will eventually stop hearing you, even when the warning is justified.

---

Opting Out Is Not a Strategy

The third option is, of course, to opt out entirely.

Move off the grid.

Build a bunker.

Learn to grow potatoes.

Possibly learn Chinese, depending on which geopolitical forecast is making the rounds that week.

There is a certain emotional appeal to that after a long standards meeting.

It is not, however, a strategy.

So I’m left with the boring answer:

Participate thoughtfully.

It sounds small.

Ultimately, it may be small.

But it is not nothing.

It means not giving up on the process.

---

Read Proposals for What They Enable

Participating thoughtfully means resisting the urge to sort proposals entirely by who submits them.

Provenance matters.

Incentives matter.

Geopolitical context matters.

But a bad actor can make a technically valid observation.

A trusted actor can also make a proposal with terrible implications.

If we only evaluate ideas by the badge in the room, we will miss both risks.

So we have to read proposals for what they enable, not only what they claim to solve.

That means asking:

• What assumptions does this design make about identity?
• What assumptions does it make about authority?
• What does it assume about jurisdiction?
• What does it assume about consent?
• What does it assume about observability?
• What does it assume about control?

Then ask:

• Who benefits if this becomes infrastructure?
• Who loses optionality?
• What becomes easier to mandate later?
• What becomes harder to protect?
• Does this mechanism remain neutral under predictable deployment pressure?

These questions matter because optional features do not always stay optional.

Metadata fields do not always remain harmless.

Local accommodations do not always remain local.

And compliance hooks have a way of becoming architectural expectations.

---

Distinguish Policy Needs From Architectural Overreach

Participating thoughtfully also means distinguishing legitimate policy needs from architectural overreach.

Governments have responsibilities.

Of course they do.

Platforms have responsibilities, too.

Users experience real harms.

Those harms deserve serious attention.

However, not every problem should be solved by weakening the technical properties that protect everyone else.

That distinction is essential.

The challenge is not to dismiss policy concerns.

It is to ask whether the proposed technical response is proportionate to the problem.

---

Treat Core Internet Values as Design Constraints

Openness, neutrality, privacy, security, interoperability, and user agency are not simply vibes.

They are design constraints.

They need to be translated into:

• Specific technical questions
• Specific review comments
• Specific proposed text

Not everyone will see the same patterns.

Not everyone will agree about when a proposal crosses from legitimate technical accommodation into overreach.

That is not necessarily a failure.

Sometimes the contribution is simply putting a pattern into the room so others can:

• Test it
• Challenge it
• Refine it
• Remember it later

That last part matters.

A third unrelated proposal may suddenly look less unrelated because someone noticed the pattern earlier.

---

No One Can Track Everything

The whole point of having a diverse set of people in the room is to get different perspectives.

No one can track everything.

No one can defend every principle in every venue.

The Internet is too large.

The standards ecosystem is too distributed.

The meetings are too numerous.

Pretending otherwise is a fast path to burnout and possibly unpleasant behavior on mailing lists.

We have all seen that happen.

So our work has to become more disciplined.

That means:

• Picking the areas where you can contribute
• Staying connected to others
• Building enough context to recognize larger shifts
• Creating a community to work with
• Knowing when to ask for help

Most importantly, it means being willing to say:

“I may be wrong, but I think this has implications beyond this document.”

Then comes the harder part.

Explain those implications in terms the working group can actually use.

---

Standards Work Is Cumulative

I wish there were a more heroic answer.

There isn’t.

Most standards work isn’t actually heroic.

It is:

• Cumulative
• Slow
• Procedural
• Frequently irritating

It is a thousand small acts of:

• Review
• Clarification
• Objection
• Compromise
• Memory

It is noticing that a term is overloaded.

It is someone asking who the relying party is.

It is someone pointing out that the privacy considerations assume away the most likely deployment model.

It is someone saying again that the user is a constituency, not a resource.

That work does not stop nation state politics.

But it can change what gets normalized.

It can make harmful assumptions visible before they harden into infrastructure.

It can preserve room for better implementations.

It can force tradeoffs to be named.

And it can keep global interoperability from being casually sacrificed.

---

Meaningful Contribution Is Not Winning Every Argument

Meaningful contribution is not winning every argument.

Nor is it pretending that a well-written issue comment can rebalance global power.

It is showing up with enough:

• Context
• Humility
• Stubbornness

to keep asking:

What kind of Internet does this proposal help create?

That question might not feel like much when you’re in the middle of a standards meeting.

And I have certainly had serious conversations with myself about whether participation is still worth it.

But giving up would concede the work to the people who are least troubled by the consequences.

That is not something I think we should be ready to do.

---

Final Thoughts

The Internet is becoming more geopolitical.

Standards work cannot escape that reality.

But that does not mean standards communities should abandon technical rigor, openness, or interoperability.

It means contributors need to become more attentive to the larger patterns surrounding the technical work.

That requires participation.

It requires context.

It requires disagreement without assuming bad faith.

And it requires enough humility to recognize that no individual can see the whole system.

The goal is not to win every fight.

It is to keep asking better questions about the infrastructure we are helping create.

---

Conclusion

Nation state politics may be larger than any individual standards contributor.

That does not make individual participation meaningless.

Standards work remains cumulative.

Every review comment, objection, clarification, compromise, and question can influence what becomes normalized.

The challenge is to recognize when apparently reasonable technical accommodations are part of a larger shift—and to make those implications visible while there is still time to discuss them.

We cannot control every force shaping the Internet.

But we can continue to show up, participate thoughtfully, and ask one deceptively important question:

What kind of Internet does this proposal help create?