IETF Draft: Centralization, Decentralization, and Internet Standards
ietf.org
ietf.org
As well as providing some carefully worded definitions that are really useful in discussions, it sets out a stance of the IETF against massive commercial centralisation.
> Despite being designed and operated as a decentralized network-of-networks, the Internet is continuously subjected to forces that encourage centralization.
Practically the first words in any network course I teach these days are to explain to students who think "The Internet" is Facebook and Google what a catastrophe "Mainframe 2.0" really is.
> call into question what role architectural regulation -- in particular, that performed by open standards bodies such as the IETF -- should play in preventing, mitigating, and controlling Internet centralization.
IETF rightfully challenges (a decade too late) what this deviation from design principles really means, including the threat to its own relevance.
> The primary audience for this document is the engineers who design and standardize Internet protocols.
A problem here is that without a civics/ethics foundation contemporary engineers may not understand the deeper nature of a protocol versus a black-box platform. IETF may be moving into a new educational role to explain why a protocol is more desirable.
I am still reading but so far I have not seen the key issue of resilience (availability is mentioned) including the impact on national infrastructure resilience.
There is the Evolvability, Deployability, & Maintainability [0] working group that has some good documents that relate to that.
I guess the art in protocol design is to have as few as possible mandatory-to-implement parts, which are itself minimized in complexity, so that a minimal implementation is doable with a reasonable amount of effort while already achieving a good result (and UX). Then the optional parts can be added piece-by-piece, after the implementation was already published/released.
Noncommercial internet user here. I will gladly trade "functionality" for simplicity and implementation diversity, i.e., choice. Often "functionality" is not something internet users ask for, but something standards authors want, where either the authors are commercial entities purporting^1 to act on behalf of internet users or they are under pressure from commercial interests wanting to exploit internet users, i.e., internet traffic.
1. In truth they act on their own behalf and to satisfy their paying customers, e.g., advertisers or other "tech" companies, not internet users.
This cuts to the heart of it. In my book "The Big Bucks" the characters live through this, and in the 80s it was very often assumed that "multi-stakeholderism" meant a government-chartered body like the CCITT. In fact, in 1990, the federal government actually mandated OSI via GOSIP (there was no commercial Internet then). The consensus on the internet-history mailing list is that by then the war was already over, and TCP had won.
After all, governments MUST be the proper place to balance all the competing interests, mustn't they? So why didn't it work?
Well, TCP was "simple" enough that anyone could implement it, whereas OSI had a whole bunch of "profiles" to accommodate what everyone wanted. As a result, interoperability was impossible as a practical matter.
Network operators didn't even try, since TCP had Interop conferences where vendors came and proved themselves TCP citizens. OSI had nothing remotely comparable. With IETF, things didn't become standards until you had multiple interoperating implementations.
It's a different world now, though. The stakeholders are not all grad students and defense company network administrators. However, a government-sponsored "standards" organization won't work any better now than it did then.
Is it even possible for the IETF (or a similar standardization body) to mitigate it?
I disagree. Humans are successful because we exhibit rather few immutable "inherent conditions", and there's volumes of literature from the anthropologists on that flexibility.
Maybe what you mean is that systems (which complex societies and networks are) exhibit, amongst other things, an inherent possibility of agglomeration. Sometimes we call that a "network effect" - power to the powerful, riches to the rich, and so on.
Yes that's true of inanimate systems, like star formation. Human beings, and indeed other life forms, offer the precise counter to that force in being agents that choose an optimal level of proximity and connectivity. I like to use the analogy of matter, balanced between strong and weak forces of repulsion and attraction. People have a Goldilocks point for connection complexity, as seen in Robin Dunbar's number or George Miller's magic "seven plus or minus two", and this replicate at various levels of organisational scale as people like Thomas Schelling and Fred Brooks have indicated.
Unfortunately the way "network effects" are talked about today in tech creates a distortion around such dynamic equilibriums, painting them as necessarily "winner takes all".
> Is it even possible for the IETF (or a similar standardization body) to mitigate it?
That's a really good question. And several questions inside it to unpack. Their remit? Their capability? Their moral role?
I think the answer is broadly "Yes" (to all), but for small values of "it". What requires and deserves protection (morally), and can be protected (practically via regulation), is the substrate on which other things are built. In the IETF document, protocols like IP, TCP and DNS are mentioned frequently, but obviously there's a much larger suite. That, in concert with anti-trust, competition and interoperability laws will allow choice around as much or little centralisation as people want. The idea that new protocols should continue to adhere to the same standards and values as the foundation is the thrust (insofar as I read it).
IETF say there cannot be an "Internet Police" but in many ways that's exactly what is needed, and maybe what they wish they are - in a benevolent sense. Because ultimately the corporations are their own worst enemy. They will destroy the foundation on which they're built. Like a child that needs guidance, organisations like IETF act as a parent to stop cannibalism. Or, as verbal-judo proponent George Thompson said... "to help you make the best decisions for yourself now, that you would make if you were thinking clearly in some future frame of regret."
Ummm, what? If something is decentralized, then that's kind of the point that you can't hold "someone accountable for how the function is performed". If you could hold someone accountable, then you would be able to censor the function at that point of control. This just seems like a criticism of decentralization as a whole.
Also, at the beginning of the Decentralization Techniques section they said...
> "Choosing the appropriate techniques for decentralization requires balancing the specific goals of the function against centralization risk, because completely precluding all forms of centralization through technical means is rarely achievable."
So is it that decentralization is impossible to achieve or that it's achievable, but undesirable? I feel like I'm being gaslighted by the IETF.
Merely knowing who controls the nodes doesn’t mean you actually can trivially censor them: if you have thousands of nodes controlled by different organisations globally you’ll have a much harder time censoring them than a distributed system where a single organisation has a significant share.
Agreed, you want the nodes to be controlled by many different entities globally, but that should be a function of the technical implementation of the distributed system rather than having to identify a responsible party that is accountable for this objective. Privacy is crucial to ensure a distributed system continues to function; otherwise, orgs or individuals running nodes could be censored in mass by authorities or participants may stop using the system due to security concerns.
While reading this, I tried to apply what they mention at the beginning of the Centralization and Decentralization sections, that is that both are continuums.
They try to quantify this using "centralization risk". For some functions, greater decentralization might be not worth the effort, is actually undesirable, or even impossible due to technical reasons. For others, these are in greater number, everything should be done to prevent centralization.
> An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.
A lot of people associate "RFC" with standards track RFCs so I felt this could cause some confusion.
The stages of "standardness" have been there since the 1980s. Many important RFCs have never gone beyond Draft.
As an example of an equivilant informational draft I was involved in https://www.ietf.org/archive/id/draft-lapuh-spb-deployment-0... I can say it reached this stage with basically no review.
If you wanted to have an equivalently published document on centralisation stating the exact opposite of everything this one does you could have it up by the end of the month without worrying about review.
That said, they say right at the top that this is Informational, don't they?
Also, if you did try "an equivalently published document on centralisation stating the exact opposite" of the IETF position, I have a suspicion you'd run into some problems. Wouldn't you? At least some public statements that "that's just his opinion, man."
That said there is nothing wrong with conflicting informational RFCs, they are meant to share information with the community not to convey consensus so it's fine to have conflicting views as long as it sources from differing information. That said it's generally considered better for you and the other person try to come to a common understanding and share that information as one informational document.
Also, RFCs are certainly not only standards track. There is a mix of types including Informational, Experimental and Standards track RFCs.
There was no claim that RFCs must be standards track, this is actually a false relation the last line explicitly calls out people for having. Maybe it should have been made even clearer this is a false assumption without relying on context.
I wonder if RFC 2026 is worthy of its own HN post. Just submitted :).
But NAT seems to have gotten a lot more practical use, with IPv6 very gradually getting adopted over the decades.
Centralization of various forms is natural and useful and shouldn't be viewed as some ideological enemy.
Emergence of monopolies, nepotism and corruption are also very natural and usefull, but not to me as a consumer for sure.