Subject: [hrpc] The Would Be Technocrats

From: farzaneh badii <[email-masked]>
Date: Thu, 15 Jul 2021 22:05:09 -0400

You might remember that we presented a draft paper at HRPC in Prague (in
2019) about how and why context and history  matter in assessing protocols'
impact on human rights.

 We managed to publish that paper after some excruciating rounds of
revisions ( which was well worth it) today at the journal of Information
policy. You can find it here:
https://www.jstor.org/stable/10.5325/jinfopoli.11.2021.0376?refreqid=excelsior%3A5f6e0042f4bc042a36aa87e2a4d0107c#metadata_info_tab_contents

Happy to discuss. I greatly enjoyed writing this piece. The history lessons
were very eye-opening.

<https://www.jstor.org/stable/10.5325/jinfopoli.11.2021.0376?refreqid=excelsior%3A5f6e0042f4bc042a36aa87e2a4d0107c#metadata_info_tab_contents>

<https://www.jstor.org/stable/10.5325/jinfopoli.11.2021.0376?refreqid=excelsior%3A5f6e0042f4bc042a36aa87e2a4d0107c#metadata_info_tab_contents>

Best

Farzaneh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Jul 2021 11:26:46 +0200

On Thu, Jul 15, 2021 at 10:05:09PM -0400,
 farzaneh badii <[email-masked]> wrote 
 a message of 80 lines which said:

> revisions ( which was well worth it) today at the journal of
> Information policy. You can find it here:

[HRPC people: there is a lively discussion on the internet-history
mailing list. A few emails at the beginning are a bit nasty (basically
denying that people who did not program network code in assembly
language in the 1970s could have to say anything) but skip them, the
rest of the thread is good. Note also that John Levine made some very
critical remarks about HRPC, along with some personal attacks but his
other messages are more useful.]

General summary on the paper: it is a criticism of HRPC work but I'm a
bit unease since it seems to me that the paper presents HRPC in a way
that I don't find realistic. The paper rightly criticizes the idea
that you can implement human rights in protocol networks, and have
therefore a technical object (the Internet) which would be
HR-preserving "automatically". But I don't think HRPC ever defended so
caricatural an opinion. I tend to think that the authors twisted HRPC
ideas in a way that make them easier to attack.

The conclusion of the paper that network protocols (or techniques in
general) cannot by themselves solve everything is, I think, widely
shared here. The paper accuses HRPC of "technocracy" ("The technocracy
is an approach that involves the HRPC RG studying protocols in
isolation") but fails to consider 1) the practical issues (HRPC goal
is to influence IETF, and IETF deals with protocol definition, not
deployment) 2) the simple lack of time, studying everything is a good
way to study nothing.

The paper seems to criticize the fact that HRPC changed in the course
of the group but it seems to me that it is to be expected from a
*research* group. From the beginning, I think the idea of HRPC was to
*explore* the complicated relationship between technique and politics
and to see what was possible.

On more specific points:

The description of "privacy by design" is unfair. PbD is not the idea
that you can design a technical system that will be so
privacy-preserving that politics and law would be unecessary. PbD is
the idea that technical people must take into account privacy from the
very start, because it would be harder to retrofit it later. For
instance, if you collect personal data, protecting it against
malicious access is hard. PbD would say "may be it is better not to
have personal data at all".

Regarding the EGPs, the paper says "EGP and BGP can be seen as a part
of the initial moves toward privatization of the Internet", clearly
showing in its analysis that technical decisions *do* have an impact
(good or bad). Also, one could say the the EGPs *enabled* (not
*created*) a multi-organization network, which is the definining
feature of the Internet (not technical details like the datagram).

Regarding the "protocol wars", the paper says "a far more open and
multiconstituency decision-making process at OSI". As they say on
Wikipedia, "reference necessary". "More open", an organisation where
the technical standards were not (and still are not) freely available?
When I was in an University working on FTAM (the OSI competitor of
FTP), I did not even have the right to distribute to the students the
copies of the standard I got (probably illegally).

Also on OSI, saying that "It was the expertise with which corporations
sent skilled representatives to derail negotiations and successfully
push their corporate interests that massively influenced OSI design
and that was in part responsible for OSI’s delays and the victory of
TCP/IP." is very questionable. OSI people managed to shoot themselves
in the foot without any help from the "corporations". When I reported
to ISO that two different FTAM implemtations could not exchange files,
I was told that this was normal, since there were so many FTAM options
and no common ground. ISO was uninterested in interoperability, since
they did not have in mind one bit internetwork but just a bunch of
corporate islands. This is what killed OSI.

About the DNS, the paper says "Despite the extensive historical
records (e.g., Listservs, interviews, and RFCs), it is unclear what
happened so that the root was created from the level of detail
required by the proposed framework. Although the USC-ISI team
solicited proposals from the broader Internet community, none of these
offered a distributed system that would have avoided some central
point of control." First, the paper (like, unfortunately, most
Internet governance papers) fail to make the difference between the
provisioning root (currently IANA) which has to be centralized
(otherwise, we could have two .com) and the resolution root (currently
the set of root name servers) which could be done differently. It is
true that a lot of design decisions were not clearly documented (and,
Andrew Sullivan explains nicely in the internet-history discussion,
"we cannot interview our former selves") but we have the complete
archive of namedroppers and you will note that the initial proposals
had no resolution root (instead, each TLD would have authoritative
name servers relaying requests to all other TLD, a bit like SS7).

About "Their decision might have just been because mathematicians and
engineers are drawn to hierarchical designs and it was more common.",
it is also because decisions are not taken on purely technical grounds
(because engineers are humans living in a society, with laws, money,
employments, prejudices, etc) but neither are they taken on purely
political grounds. For the provisioning root, there was no blockchain
at this time, so a centralized system was the only one which
worked. For the resolution root, the adopted system may not be "the
best" but it is certainly very efficient and was chosen partly for
that. The paper seems to err on the side of "technical arguments never
matter" (while some people on the internet-history thread erred on the
opposite side).

About the RDDS and specially the tiered access RDDS, the paper notes
about the failure of IRIS "may be a technical failure, we can also
attribute it to the potential political pressure by other stakeholders
not to implement it. Hence, IRIS became redundant." It is strange to
study the history of RDDS and to stop at IRIS. RDAP is widely deployed
but very few tiered accesses are available today because of a
non-technical issue: RDAP *enables* tiered access but to actually
deploy it, you need to decide who will be "priviledged" and this is a
tough political decision.

About the level of diversity in techniques in the various
interconnected networks, this was a hot topic at the beginning and the
result, the paper says, was "a fairly homogenous system of IP and
Ethernet". Indeed, using IP everywhere was a choice (a good one,
IMHO), but what is Ethernet doing here? Many networks used other
technologies (I managed IP networks running on token ring and
LocalTalk).

---

From: farzaneh badii <[email-masked]>
Date: Tue, 20 Jul 2021 09:31:48 -0400

Hi Stephane,

> ideas in a way that make them easier to attack.

Thanks a lot for the great criticisms. To be honest we wanted to warn the
HRPC and not to attack it and perhaps give it a revised direction (but a
new direction is another paper on its own that's why we didn't mention it). We
do believe there are political implications of Internet protocols. This is
why the engineers on the other mailing list actually are so riled up,
thinking we are arguing that protocols are inherently political. So one
positive thing that I think I took away from that discussion is that the
balance was just right (we praised the HRPC and its work but also
criticized it) . Which now you are refuting. :))) We didn't deny that
Internet protocols have political implications and said some positive
things about the potential of the group. So it angered the engineers
because well some mostly want to deny any political implications.

> deployment) 2) the simple lack of time, studying everything is a good

The deployment issue is a very good point. But I thought that this group is
really not an IETF group but an IRTF group that can focus on context as
well. also we argue that without contextualizing and measuring the impact
of the protocols we can't tell the engineers what to consider or what to
modify.

> have personal data at all".

This is correct but there are two strands: one that was advanced by Helen
Nissenbaum which is contextualizing privacy which is closer to what you are
describing and what we like - then there is another group that  argues that
privacy can be baked into the system which is what we are criticizing.

> feature of the Internet (not technical details like the datagram).

There is no denying that technical decisions can have an impact. What we
argue is that the impact might not be predictable at the time of designing
the protocol.

> copies of the standard I got (probably illegally).

I will look into this more, but I think multi-constituency and open differ
from free.

> corporate islands. This is what killed OSI.

The fun thing is that we had most of what you are saying about the OSI and
protocol war but were instructed not to cut it out them in this paper.

> name servers relaying requests to all other TLD, a bit like SS7).

Great point.

> matter" (while some people on the internet-history thread erred on the

But I am surprised why there is this impression that we argue technical
arguments never matter. We are arguing exactly the opposite. Perhaps we
need to revisit the style of writing.

> tough political decision.

:)) glad you are mentioning this. I went into the weeds of talking about
RDAP and going on and on about the EPDP at ICANN that it ended up looking
like a paper about ICANN. so we cut it out. But you are right at least
should have mentioned in a couple of sentences.

> technologies (I managed IP networks running on token ring and

I need to talk to you more about this.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Jul 2021 10:51:50 +0200

On Tue, Jul 20, 2021 at 09:31:48AM -0400,
 farzaneh badii <[email-masked]> wrote 
 a message of 449 lines which said:

> The deployment issue is a very good point. But I thought that this
> group is really not an IETF group but an IRTF group that can focus
> on context as well. also we argue that without contextualizing and
> measuring the impact of the protocols we can't tell the engineers
> what to consider or what to modify.

Let me try (carelessly!) an analogy with genetics. Some traits are
very clearly genetic and the responsible gene is well identified (eye
color, for instance). Other traits are more complicated. We don't know
"the" gene for cancer (and it is probably not just one gene but a
combination of many things) or for criminal behaviour (which is
probably not genetic at all).

In the same way, some traits of the Internet can be traced to just one
technical decision (sending data in clear helps surveillance) but
other are much more difficult to connect with a specific paragraph in
a RFC. For instance, you will probably not find the reasons for the
current concentration of email providers (Gmail, Outlook.com and a few
others) in RFC 5321 and 5322.

Conclusion? The IETF would certainly be helped by studies of protocol
deployments, of what actually happened in the wild (RFC 8980), but it
is not realistic to expect that these studies will always find
technical decisions to change. 

> there is another group that argues that privacy can be baked into
> the system which is what we are criticizing.

OK, but this is not what people who use the "privacy by design" slogan
mean.

> There is no denying that technical decisions can have an
> impact. What we argue is that the impact might not be predictable at
> the time of designing the protocol.

Some are. If you design a protocol today where user-displayed
character strings are always in ASCII, you will clearly have an impact
on internationalization. We agree that there are unexpected
consequences (specially in the long term) of protocols. But
nevertheless, sometimes, we can predict "danger ahead". This is where
guidance (from instance in RFC 8280) is useful.

> > Wikipedia, "reference necessary". "More open", an organisation
> > where the technical standards were not (and still are not) freely
> > available?  When I was in an University working on FTAM (the OSI
> > competitor of FTP), I did not even have the right to distribute to
> > the students the copies of the standard I got (probably
> > illegally).
> 
> I will look into this more, but I think multi-constituency and open
> differ from free.

Multi-consistuency, ISO? This is a joke. It is difficult to assert it
precisely (because it is a closed organisation and we don't really
know what happens inside) but I seriously doubt it is more diverse
than the IETF. (More marketing people, probably.)

And how could you claim to be open when your main output, the
documents, are not freely available?

> But I am surprised why there is this impression that we argue
> technical arguments never matter. We are arguing exactly the
> opposite. Perhaps we need to revisit the style of writing.

When, in your paper, you expose a decision, you mention several
possible reasons for this decision, but never technical reasons. So,
it can be deduced that you think technical arguments are not too
important in former choices.