- From: Cory Doctorow <doctorow@craphound.com>
- Date: Mon, 28 Feb 2022 10:42:44 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: hellekin <how@zoethical.com>, public-interop-remedies@w3.org
I don't think that's incompatible with the proposal, though? Remember there are three proposals here: 1. Recommend a requirements process; 2. Recommend compliance with requirements as an alternative to requirements with a standard; 3. Recommend a process for examining either a standards implementation or a requirements-satisfying API to determine whether it's sufficient. I'm seeking some consensus on 2. Your proposal for 1. sounds fine to me, and in no way incompatible with 2. Cory On 2/27/22 19:35, Mark Nottingham wrote: > My mental model for this is that the SDOs do the requirements process and document an interoperable solution, and then the regulators decide whether it's sufficiently pro-competitive, ex post. That removes the need for the regulator to do detailed requirement or specification work, and lets them rely on both legitimacy signals from the SDO and feedback from the affected market. > > Moving to a model where the regulators sets requirements puts considerable work on them, and they're not well-suited for it -- there are going to be non-obvious interactions between competition and other kinds of requirements which need to be balanced. > > In other words, I still think an open process informed by technical experts but with the involvement of civil society is the best path we have. We can improve it by injecting more clue / guidelines about what pro-competitive outcomes in standards look like.* > > I am very much less than thrilled about having big-tech funded Open Source as a get-out clause from standards conformance; it will very likely become de facto, and we've seen plenty of abuses of such OS projects (indeed, it's a major strategic tool for at least one of them, to my knowledge). > > Just my .02. > > Cheers, > > > * I'm noodling on this over here: <https://mnot.github.io/avoiding-internet-centralization/draft-nottingham-avoiding-internet-centralization.html>, but it's still a work-in-progress. > > > >> On 26 Feb 2022, at 4:34 am, Cory Doctorow <doctorow@craphound.com> wrote: >> >> Thanks, Hellekin! >> >> I guess I'm still trying to figure out why it's harder to police: >> >> a) A requirements process that produces a standard that addresses monopolization; and >> >> b) A standards process that honestly reflects those requirements; and >> >> c) An implementation that does not subvert the standard (say, through throttling, errors, IDS false positives, etc) >> >> Than all of the above and a requirements-satisfying implementation. >> >> In particular, it feels like all the real expense - the ongoing expense, that is - is in c), and that would be constant irrespective of whether it relates to a standards-defined API or a requirements-satisfying one. >> >> Cory >> >>> I still think that anything that will bring more work to compliance enforcers than to the institutions that need to be regulated will aggravate the situation, and plays in favor of the industry that must be regulated. It's simple energetic logic. You can't have n institutions to regulate and one enforcer to watch them all. It won't work. It does not work for finance, it won't work for tech giants. >>> == >>> hk >>> . >> > > -- > Mark Nottingham https://www.mnot.net/ >
Received on Monday, 28 February 2022 18:43:02 UTC