Subject: [hrpc] I-D Action: draft-irtf-hrpc-political-04.txt

From: [email-masked]
Date: Mon, 16 Sep 2019 02:11:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Human Rights Protocol Considerations RG of the IRTF.

        Title           : Notes on networking standards and politics
        Author          : Niels ten Oever
	Filename        : draft-irtf-hrpc-political-04.txt
	Pages           : 15
	Date            : 2019-09-16

Abstract:
   The IETF cannot ordain what standards or protocols are to be used on
   networks, but the standards development process in the IETF does have
   an impact on society through its normative standards setting process.
   This document aims to bring about a better understanding on the
   political nature of standards and protocols.  Among other things, the
   IETF's work affects what is perceived as technologically possible and
   useful where networking technologies are being deployed, and its
   standards reflect what is considered by the technical community to be
   feasible and good practice.  Whereas there might not be agreement
   among the Internet protocol community on the specific political
   nature of the technological development process and its outputs, it
   is undisputed that standards and protocols are both products of a
   political process, and they can also be used for political means.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-hrpc-political/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-hrpc-political-04
https://datatracker.ietf.org/doc/html/draft-irtf-hrpc-political-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-political-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 16 Sep 2019 17:00:57 +0200

Hi all,

As promised, after ironing out some bugs with xml2rfc (thanks Henrik), here is an updated version of draft-political which addresses the comments from SM and Eliot.

Best,

Niels

On 9/16/19 11:11 AM, [email-masked] wrote:
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
DATACTIVE Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: [email-masked]
Date: Mon, 16 Sep 2019 17:16:11 -0400

Hi,

Thanks Niels.

SM & Eliot, are you satisfied with the way your comments were addressed?

Any other reviews in the wind?

thanks

avri

---

From: avri doria <[email-masked]>
Date: Mon, 16 Sep 2019 17:23:19 -0400

Hi,

On a personal note:

I am still somewhat insecure about the statement:

"it is undisputed that standards and protocols are both products of a
political process, and they can also be used for political means."

I wont dispute the the idea of process and some use being political, but
is the statement really undisputed?

Will read the rest of the new draft in the next day or so.

thanks

avri

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Sep 2019 07:47:50 +0200

Hi Avri,

I ask for guidance from the chair and from the RG as to what qualifies as ready for publication.  What are the criteria?  What are we aiming for?  Academic quality?

My view?   There are some real problems in the document.  This is not an exhaustive list:

The thesis statement conflicts with the introduction, and conflates protocols and standards.
As both protocols and standards are central to the document, you would think that they would be defined early on, like in the definitions section.
The difference between protocols and standards is not made, nor is equivalence.
There is no statement of import in the form of what real contribution the work is making and why that contribution matters.
The general and the specific are conflated.  Are protocols and standards at issue here or are we talking about IETF protocols and standards?
The lack of examples is really quite frustrating.

There are a great many other problems with the draft, not the least of which is that the author makes unsupported claims, either by reference or proof, one example being the discussion in Section 5 about the WTO.

Are these show stoppers?  Please before we continue, let’s understand our own standard for publication.

Eliot

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 17 Sep 2019 11:09:05 +0200

Hi Eliot,

> My view?   There are some real problems in the document.  This is not an exhaustive list:

I am a bit surprised by this, since these are not points you brought up in your past email. But I am happy to address them of course.

>   * The thesis statement conflicts with the introduction, and conflates protocols and standards.

Could you be so kind to point out the conflict?

>   * As both protocols and standards are central to the document, you would think that they would be defined early on, like in the definitions section.

These definitions were there in the -01 version of the document:

https://tools.ietf.org/html/draft-irtf-hrpc-political-01

Then the RG asked me to remove them, am happy to put them back in if people think that is the right way to go. 

>   * The difference between protocols and standards is not made, nor is equivalence.

See above. I also explained in my previous mail that I use standards where the argument supersedes protocols, especially for section 5 where lessions are brought in from other standard setting fields. 

Not all standards are protocols, but all protocols are standards. 

>   * There is no statement of import in the form of what real contribution the work is making and why that contribution matters.

What about these sentences?

From abstract:

This document aims to bring about a better understanding on the
   political nature of standards and protocols.

From intro:

  In this document we aim to outline different
   views on the relation between standards and politics, and seek to
   answer the question of whether standards are political, and if so,
   how.

>   * The general and the specific are conflated.  Are protocols and standards at issue here or are we talking about IETF protocols and standards?

We are talking about the political nature of networking protocols, specifically those in the IETF.

>   * The lack of examples is really quite frustrating.
> 

Why are examples, or cases, needed to proof the point? In an earlier comment you said that the thesis was extremely obvious? Am a bit at a loss.

> There are a great many other problems with the draft, not the least of which is that the author makes unsupported claims, either by reference or proof, one example being the discussion in Section 5…

Which claim do you mean specifically?

Best,

Niels

---

From: [email-masked]
Date: Tue, 17 Sep 2019 08:22:22 -0400

Hi,

I too am looking for RG guidance.

While I am not personally convinced of its readiness I believe my
co--chair does think it ready, so I am looking for RG evidence.  Eliot,
I really appreciate your reviews. Unfortunately I am having trouble
gauging the views of the rest of the RG. I have gotten 2 messages off
list telling me of issues, and ask that those that have a view on its
readiness, positive or not, speak up.

As for judging by academic quality, yes, I do look for some academic
quality.  Not perhaps full academic rigor but sufficient academic rigor,
; i.e no obvious defects in the argumentation, adequate references to
counter arguments &c. I am also looking for clarity, which academic
rigor does not necessary measure.

Also since this is no longer a personal doc but a RG doc, I am looking
for a positive evidence that the group finds it acceptable.  Yes, the LC
is meant to verify that, but I feel I need to have the impression that
is is ready and acceptable to most before I am willing to start a LC to
verify the degree of rough consensus. Since I can neither assume silence
means consent nor means dissent, in the absence of more comment, I keep
asking.  I would hate to call a LC, have few to none respond and take to
the IRSG review on scant evidence.  I will keep asking.

Some people have offered to review, so I live in hope we will get those
reviews soon.

Thanks again for your comments.

avri

On 17-Sep-19 01:47, Eliot Lear wrote:
> Hi Avri,
>
> I ask for guidance from the chair and from the RG as to what qualifies
> as ready for publication.  What are the criteria?  What are we aiming
> for?  Academic quality?
>
>   * As both protocols and standards are central to the document, you
>     would think that they would be defined early on, like in the
>     definitions section.
>   * There is no statement of import in the form of what real
>     contribution the work is making and why that contribution matters.
>   * The general and the specific are conflated.  Are protocols and
>     standards at issue here or are we talking about IETF protocols and
>     standards?
> There are a great many other problems with the draft, not the least of
> which is that the author makes unsupported claims, either by reference
> or proof, one example being the discussion in Section 5 about the WTO.
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Sep 2019 08:50:30 -0400

> I too am looking for RG guidance.

FWIW, the objections I raised probably a year ago haven’t been addressed yet.  An RG document should make a clear case for whatever point it’s making, but this document doesn’t do that.  The introduction is not really doing the job of an introduction—it starts with several quotes, and never really says what the document is about nor why we should read it.   Section 3 should be the introduction, and could start with the question stated there, and then give an overview of what the document talks about and what research methodology was used.  The quotations in the introduction could either be chucked, or woven in appropriately, but as they are, they just prevent the reader from proceeding further.

The text from the abstract could be useful in the introduction; the abstract itself is meant to be a sales pitch for why you should read further and what the document is about, and so this one is way too long.

The methodology that produced the subsections of 4 is unclear; it seems to be the author summarizing these viewpoints, but the author clearly has opinions about these viewpoints, and the summaries are difficult to follow and full of detail that is really part of the author’s conclusion, and not part of the explanation of the position. So they aren’t really doing the job of helping us to understand the issues.  Furthermore, we don’t know how the author decided to represent just these viewpoints, and no others, nor is there any discussion of the relationships between these views, which I think clearly exist: they are presented as orthogonal.

As an example of the difficulty of following these subsections, consider subsection 4.4.  We have an initial paragraph that explains the topic decently well, followed by a long quotation from Heidegger that explains it better, followed by a paragraph that introduces a new analogy, finally followed by a paragraph that tries to relate these analogies to the Internet and to protocols, but thoroughly fails to do so.  I think part of the reason it fails is that the author is really trying to express his view of how the Internet is analogous to the two examples he has given, and that distorts the analogy enough to make it quite difficult to follow.

There are two major issues with this document as an RG document.  First, I don’t think it is an RG document.  I think it’s the author’s document.  Secondly, it desperately needs a developmental edit.  I think the ideas being expressed here are probably worth expressing, but if it’s going to be Niels’ document, then Niels needs to get some outside feedback to turn it into a good document that says what Niels wants to say in a way is useful to other readers.  And if it’s to be an RG document, then it needs to have more participation from the RG.  In order for that to happen, it probably needs Neils to be a contributing author rather than the editor, and for someone else to take over the editorial role.

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 17 Sep 2019 15:12:52 +0200

Dear Ted,

Thanks for this.

On 9/17/19 2:50 PM, Ted Lemon wrote:
> On Sep 17, 2019, at 8:22 AM, [email-masked] <mailto:[email-masked]> wrote:
> FWIW, the objections I raised probably a year ago haven’t been addressed yet.  An RG document should make a clear case for whatever point it’s making, but this document doesn’t do that.  The introduction is not really doing the job of an introduction—it starts with several quotes, and never really says what the document is about nor why we should read it.  

When the I-D started without references (not quotes), people said it should be based on existing literature and opinions within the IETF, and not on intuitions. Then I added these references to anchor the introduction documents. 

If Ted and the RG would prefer, I could also change around para 1 and para 2, but the academic way would be to start with embedding it in literature. I leave it to you all to let me know your preferences.

 Section 3 should be the introduction, and could start with the question stated there, and then give an overview of what the document talks about and what research methodology was used. 

It is highly unusual to start a paper with the research question (section 3.) and the methods (section 4). 

 The quotations in the introduction could either be chucked, or woven in appropriately, but as they are, they just prevent the reader from proceeding further.

Have you tried reading the sentences without looking at the references? Am also happy to remove them and connect the two paragraphs. As said, it are not quotes, but references to show that we are not making this up.

> The text from the abstract could be useful in the introduction; the abstract itself is meant to be a sales pitch for why you should read further and what the document is about, and so this one is w…

The abstract is 137 words, generally an abstract is 250 words in Science and Technology Studies, so am curious where this standards comes from. 

> 
> The methodology that produced the subsections of 4 is unclear; it seems to be the author summarizing these viewpoints, but the author clearly has opinions about these viewpoints, and the summaries are difficult to follow and full of detail that is really part of the author’s conclusion,
The titles of these positions are taken literally from this mailinglist and discussions in the session, and then built up further by embedding them with existing literature. 

Where do you see a bad representation?

> and not part of the explanation of the position. So they aren’t really doing the job of helping us to understand the issues. 

It would be great if you could point out where so we can improve.

 Furthermore, we don’t know how the author decided to represent just these viewpoints, and no others, 

Because these were the viewpoints of 'positions that have been observed in the IETF and IRTF community, and have been observed during interviews, mailinglist exchanges, and during research group sessions.  These positions were observed during participatory observation, through 39 interviews'

nor is there any discussion of the relationships between these views, which I think clearly exist: they are presented as orthogonal.

Where? Happy to correct that.

> As an example of the difficulty of following these subsections, consider subsection 4.4.  We have an initial paragraph that explains the topic decently well, followed by a long quotation from Heide…

This was provided by Andrew Sullivan, not by me. But happy to correct.

> 
> There are two major issues with this document as an RG document.  First, I don’t think it /is/ an RG document.  I think it’s the author’s document.  

Why, it has been adopted by the RG.

Secondly, it desperately needs a developmental edit.  I think the ideas being expressed here are probably worth expressing, but if it’s going to be Niels’ document, then Niels needs to get some outside feedback to turn it into a good document that says what Niels wants to say in a way is useful to other readers.  

I take issue with this description. There have been a lot of people who have contributed a lot of text to this document, among which Andrew Sullivan, Michael Rogers, and Amelia Andersdotter.

And if it’s to be an RG document, then it needs to have more participation from the RG.  In order for that to happen, it probably needs Neils to be a contributing author rather than the editor, and for someone else to take over the editorial role.

Where does this rule stem from? This was not how we progressed with RFC8280.

Best,

Niels

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Sep 2019 09:33:16 -0400

This is an IRTF document, which will show up in the RFC series, and not a standard academic document.   If the goal is for this to be useful to the community of users for which the IRTF and IETF are the core, then it should look like an RFC, not like an academic paper.

This means that the abstract should be just long enough to tell the reader what is inside the package and why they should read it, and no longer.  It should not say anything about the structure of the RFC.

Similarly, it may be that an academic research paper can’t start with the research question because that’s the custom in academic research papers; if this RG has as its goal to speak only to the academic community, perhaps that is okay.  But then why publish it here and not in an academic journal?  Isn’t the point of doing academic work in the IRTF that it is part of the greater IETF community, and that its work is the production of useful RFCs?  Furthermore, if academic papers generally suffer usability issues (and IMHO they do), should we replicate those usability issues here, or should we do better?

Anyway, as I read through the rest of the response, it appears that you are simply disagreeing with my viewpoint.  That’s fine—I’m responding to Avri’s request for feedback with my opinion, not trying to speak authoritatively to you as the author.  I have made similar comments in the past, and not seen the document change as a result, nor seen my comments addressed.   Perhaps this document represents more views than just yours, but it certainly hasn’t captured my feedback.

As for the thicket of citations in the introduction, you have, at minimum, a usability problem here.  Don’t ask me to read past the thicket of citations.  Figure out a way to present these citations so that they are usable.   Your job as an editor is to produce a useful document; when you get feedback that makes the document less useful, you have to figure out a way to act on that feedback that is beneficial: it’s not enough to take the feedback in its original form and apply it, knowing that it’s making the document worse.

> On Sep 17, 2019, at 9:12 AM, Niels ten Oever <[email-masked]> wrote:
> 
> Dear Ted,
> 
> Thanks for this.
>

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 17 Sep 2019 15:45:20 +0200

Hi Ted,

> Similarly, it may be that an academic research paper can’t start with the research question because that’s the custom in academic research papers; if this RG has as its goal to speak only to the ac…

I have tried in my work in this RG to build a bridge between the IETF and academia. When I write things in IETF/RFC format, people say it is not academic enough, when things are more academic, it is not IETF/RFC enough. I am really at a loss here.

If you want to be a co-author, I am happy to have you on as one. I am also happy to take pull requests, as you have seen in the past there is an almost 100% acceptance rate for them, as with text suggestions.

> 
> Anyway, as I read through the rest of the response, it appears that you are simply disagreeing with my viewpoint.

I am happy to address your viewpoints, but it is hard to navigate suggestions from the RG that are simply going in different directions. 

  That’s fine—I’m responding to Avri’s request for feedback with my opinion, not trying to speak authoritatively to you as the author.  I have made similar comments in the past, and not seen the document change as a result, nor seen my comments addressed.   

I am very sorry about that, since I really do try to respond to all comments and take them into account. It saddens me that you feel I don't.

Perhaps this document represents more views than just yours, but it certainly hasn’t captured my feedback.
> As for the thicket of citations in the introduction, you have, at minimum, a usability problem here.  Don’t ask me to read past the thicket of citations.  Figure out a way to present these citation…

Maybe I could add a footnote to the introduction, or to the document in general, where I would place these references? 

Any suggestions on how this is done within the RFC context would be very welcome.

Best,

Niels

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Sep 2019 10:11:46 -0400

> I have tried in my work in this RG to build a bridge between the IETF and academia. When I write things in IETF/RFC format, people say it is not academic enough, when things are more academic, it i…

It may be that you have taken on an impossible task.  But let’s assume for a moment that you have not.  If not, then when you are faced with a choice between readability and conformity, which do you think is the right choice to make?

> If you want to be a co-author, I am happy to have you on as one. I am also happy to take pull requests, as you have seen in the past there is an almost 100% acceptance rate for them, as with text s…

I hate to continue to give you a hard time, but this may be part of the problem… :]

> I am happy to address your viewpoints, but it is hard to navigate suggestions from the RG that are simply going in different directions. 

When we get into situations like this, it might help to step back and ask the question: what is it that we want out of this document?  Why are we doing this?

What I generally want out of documents is that they provide a clear picture of something that we need to understand, but do not all collectively understand well.  They should be written in such a way that with as little effort as possible, I can read them and come away understanding the problem or solution being discussed more clearly.  I can know what the authors opinions are, and where what they said was opinion, and where what they said was intended to be objective.  I can reason about whether it was objective.

Writing documents like this is really hard.  There is nothing to be ashamed of when you don’t succeed at first attempt.

Speaking of academic publishing, it is frequently the case that the goal of the document is not what I stated above.  Because of the “publish or perish” problem, and also the “I need to look smart” problem, and the “I need to signal that I am an academic” problem, much is typically said in the document that has nothing to do with communicating about the ostensible subject of the document.

While we can’t pretend that these pressures don’t exist for authors of IRTF documents, I think it’s worth actually aspiring to produce useful stuff, and to notice when the various pressures of academia distort the writing and make it less useful.

Of course, this is just my opinion.  It may be that there isn’t consensus on this.  There are valid reasons to try to conform to academic forms: if we don’t, there’s a risk that academics won’t take us seriously.  But if we are to compromise in service of that goal, let’s at least understand why it is that we want to be taken seriously, and what our options are for achieving that goal.

At present it feels like it’s a bit contemptuous of academics to suggest that they will not read a useful, clear document because it’s not in the right form.  If there are academics for whom this conjecture is true, are they the ones we want to reach?

What is the good outcome here?   Is it being heard, or is it being influential?   Do we actually have something valuable to say?  Who needs to hear what we have to say?   Why will it be beneficial for them to do so?

---

From: Gurshabad Grover <[email-masked]>
Date: Tue, 17 Sep 2019 19:50:00 +0530

> I too am looking for RG guidance.

Hello.

Some thoughts on the research question and the conclusion in the draft:

Andrew Sullivan's comments from a while ago [fn0] ring true to me. I
actually think there are three questions the draft is trying to comment on:

(1) Do networking standards have political use and/or impact?
(2) Is there politics in the development of networking standards?
(3) "Are protocols political?"

The conclusion (and abstract) say that (1) and (2) are undisputed: "it
is undisputed that standards and protocols are both products of a
political process, and they can also be used for political means." I
think it would be useful to clarify how this is arrived at: is this
statement relying on the views summarised in Section 4, i.e. through
participant observation, discussions and interviews? Because to me, all
subsections of Section 4 do not seem to be answering all the three
questions. (See [fn1] for how I'm reading each subsection in Section 4,
please correct me if I'm wrong).

While the draft says that it does not aim to check participants' views
for consistency, I still think the addition of text to this effect is
important because this claim is relied upon in the conclusion to answer
(3), i.e. the research question, in the affirmative. This seems to be
suggesting that if (1) and (2) are true, then (3) is true. Is this a
correct interpretation?

Quick summary of my suggestions:
* explicitly add what specific question out of the three was
discussed/asked in Section 4;
* clarify whether Section 4 is being used to arrive at the conclusion;
* clarify the link between the three questions

Thank you.
-Gurshabad

[fn0] https://mailarchive.ietf.org/arch/msg/hrpc/FjPucFoWPCaVzNbYOycp3TH1Z4I

[fn1] For each claim, I interpret the answers in sub-sections of Section
4 to be:
* 4.1: (1) True; 	(2) Unclear; 	(3) False
* 4.2: (1) Unclear; 	(2) Unclear; 	(3) Sometimes true
* 4.3: (1) True; 	(2) Unclear; 	(3) Unclear
* 4.4: (1) True; 	(2) Unclear;	(3) Maybe true?
* 4.5: (1) True; 	(2) True; 	(3) True

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Sep 2019 16:23:24 +0200

Hi Ted,

> On 17 Sep 2019, at 16:11, Ted Lemon <[email-masked]> wrote:
> 

Indeed.  Niels is in a hard spot because there are a variety of expectations about what this document should contain. Just between you and me there are differences.  And this boils down a bit to “Whose document is it anyway?”  RGs have some latitude on this, by the way: this document does not need to be a consensus view.  But if it is, then our differences should be explored.

To your point, and to the point Avri made, the document must be clear as to its purpose, and that is where I think some of the trouble lies now.  The “why” is a very important question because it provides some scoping as to audience and focus.  The way I put this is that there has to be some import to the work that is clear to the reader.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Sep 2019 11:02:53 -0400

Hi,

Speaking as usual only for myself (but I am employed by the Internet
Society).

On Tue, Sep 17, 2019 at 04:23:24PM +0200, Eliot Lear wrote:
>   And this boils down a bit to “Whose document is it anyway?”  RGs have some latitude on this, by the way: this document does not need to be a consensus view.  But if it is, then our differences should be explored.
>

I simply don't understand why that self-imposed rule is being followed
in this case anyway.  It has been long clear, in my opinion, that the
authors of this document have a strong view they wish to press, and
that they will do so.  Several of us have extremely serious
reservations about that view (for my part, I have given up on making
those arguments, because I was unsatisfied with the way they were
addressed and I just don't have the time to invest to continue to
press the point).  In such an environment, a consensus document will
either be too watery to be interesting or else will not really
represent consensus.  The solution to such a dilemma is surely to
refuse the conditions that make it possible.  No?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 17 Sep 2019 17:16:53 +0200

> (3) "Are protocols political?"

Thanks a lot for this Gurshabad, I think this is very insightful, since it brings back the original framing. 

I am happy to integrate the changes proposed by Gurshabad, which I think make a lot of sense, but then I would like to hear from Eliot and Ted whether this would also help answer their questions.

As said earlier, this document is not aimed to provide recommendations to the IETF, but to be a platform for further discussion. And to prevent the RG of going in circles sometimes also about things that seem 'trivially true' [0].

Best,

Niels

[0] https://mailarchive.ietf.org/arch/msg/hrpc/rwa2nQfNKodd8ZYQ3DqRD5kg3sU

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 17 Sep 2019 17:26:13 +0200

On 9/17/19 5:02 PM, Andrew Sullivan wrote:
> the
> that they will do so

There is no normative view expressed in this document whatsoever. So I am having a hard time following this argument (that btw seems borderline ad hominem). 

> Several of us have extremely serious
> press the point). 

Happy to review archival emails, as I did with previous versions, and integrate comments. Links and comments are very welcome.

Best,

Niels

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Sep 2019 11:45:51 -0400 (EDT)

On Tue, 17 Sep 2019, Ted Lemon wrote:

> It may be that you have taken on an impossible task.  But let’s assume for a moment that you have not.  If not, then when you
> are faced with a choice between readability and conformity, which do you think is the right choice to make?

I think the document is small enough that this can be handled on a case
to case basis. And that comments should be given regarding specific
sections of text that you think are not in the expected IETF style.

> While we can’t pretend that these pressures don’t exist for authors of IRTF documents, I think it’s worth actually aspiring to
> produce useful stuff, and to notice when the various pressures of academia distort the writing and make it less useful.

And I would say this applies to commenting or suggested change as well.
Your argument of "Let's step back and see" is rather vague and questions
the whole process. I think there are already enough people who agree
with the process outcome of having a useful document, and we are at a
point where we are looking for concrete input in improving the document.

Do you have any concrete OLD / NEW text suggestions?

> What is the good outcome here?

"This document aims to bring about a better understanding on the political nature of standards and protocols."

> Is it being heard, or is it being influential?

It is a bit early to say that, as the document is still in the draft
stage. The question to ask is more "can this document in the current
form, positvely influence or shape future IETF developments". I think
the answer is yes. If you have suggestions of making this document
even better, I'd love to hear those specific suggestions.

> Do we actually have something valuable to say?

I would love to have this document as a reference for document authors
to think about their specific IETF work impacts the global internet, and
via the internet, society. That is, this document would be a great
starting point for a document author to consider if their document needs
a Human Rights Consideration section. Writing such a section has as goal
to confirm (or perhaps improve) the protocol described causes no
unintentional harm to society.

In other words, the old IETF mantra of "making the internet work better"
is falling short of what we should be thinking of. Engineers like to
live in the ideology that "better" can be a purely technological issue,
but it is not.

For example, by making encryption with TLS ubiquitous, engineers feel
they have only made the internet better. Yet, some remote communities
that relied on proxy/caching servers to be able to have affordable
internet are now seeing a prohibitively expensive internet bill since
nothing can be cached anymore. Worse, some hacked up solutions now to
run the browser remotely in the cloud and only show a graphical output,
which can be strongly compressed and sometimes even largely cached,
to the client. This is resulting in a significantly reduced security
for those users, the equivalent of giving companies or nation states
administrative access to your personal laptop or mobile phone which
full surveilance powers. The opposite of what TLS was supposed to
accomplish.

With documents as RFC 1984 and RFC 7258 we have done some specific work in
the areas of non-technical awareness inside the IETF. This document does
a good job in providing an update to that old mantra. What I am mostly
afraid of, is that the "rough concensus" that works great for technical
protocol issues, is working quite poorly for IETF as an organisation
because it enforces the Status Quo. This can be painfully seen in recent
discussions where discussing how to be nicer to each other ends up in
fanatical censorship and organisational distrust arguments.

>  Who needs to hear what we have to say?   Why will it be beneficial for them to do so?

I think the answer to that is clear and obvious.

I understand and agree with the IETF's goal of reducing the political
aspects of internet engineering as much as possible. But a line must
be drawn somewhere. Just like we are seeing employees walk out of some
Silican Valley companies in protest of certain technologies they are
told ti develop that are used to suppress civil liberties and human
rights, so does the IETF need to take on some responsibility that it
is not aiding in turning internet technologies against human rights.
That requires people to sometimes step out of their engineering room,
and look at the world at large. And this document precisely tries to
do that. Make a document that engineers will read that is slightly
outside their area of expertise and comfort zone, and educate them
about things they might otherwise not think about.

In fact, I wonder if we should not have an item about this topic for
our newcomer sessions on Sunday, where we remind the engineers that
their work on internet protocols does not happen in a vacuum. Hopefully,
we can soon point those newcomers (and the old guard) at the very least
to this document.

Paul

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Sep 2019 17:53:01 +0200

Hi Paul,

> On 17 Sep 2019, at 17:45, Paul Wouters <[email-masked]> wrote:
> 

I think it would help the rest of us if you could explain what actions you would or would not have taken on any document you have written, based on what you read in this document.  By the way, if you could do that, it would be a very good example for Niels to include.

It would also help address a key concern of mine, which is that Niels could then more clearly express the import of the work.

This is not the only issue to be addressed, but it’s a big one.

Eliot

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Sep 2019 12:02:25 -0400 (EDT)

> As for the thicket of citations in the introduction, you have, at minimum, a usability problem here.  Don’t ask me to read past the thicket of citations.  Figure out a way to present these citation…

I agree this section is (too) hard to read and could be improved. Note
that this issue came up seperately recently in the discussion regarding
the draft-klensin-idna-rfc5891bis document, and there might be (or soon
will be) a way to cite xref's without the explicit [blue link block]. So
this is a minor issue that can be resolved to satisfy all parties.

Paul

---

From: [email-masked]
Date: Tue, 17 Sep 2019 12:38:25 -0400

Hi,

To explain why I am looking for rough consensus.

As far as I am concerned we can publish work in the IRTF stream or
outside as papers, books, conference presentations &c.  In trying to run
this group on grounds that are similarto IETF WGs, I have always taken
this hybrid approach.  But when doing the work in the IRTF stream, I try
to adhere to the IETF type of procedures within the constraints defined
in the IRTF track.  While we could have decided to do a closed group of
distinguished scholars, engineers and activists with an authoritative
chair, or some other approach, at the beginning we decided on this
approach for the group.

This is also why I can be such a stubborn pain when I ask whether
someone really wants to turn their document over to the RG.  If this
were a personal draft, I would look at it differently.  I think we could
support personal RFCs that present an individual argument. I would still
look for it to well formed and cover all the issues before sending it
on, but would not look for rough consensus.

I think we can reach rough consensus, even when we disagree, without
watering the content down to pabulum.  It is harder and, at least to my
mind, is part of the exercise we are engaged in. In a RG document, we
should be able to discuss all relevant sides of the issue, especially if
our purpose is to inform.

thanks

avri

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Sep 2019 12:52:03 -0400

On Sep 17, 2019, at 11:45 AM, Paul Wouters <[email-masked]> wrote:
> "This document aims to bring about a better understanding on the political nature of standards and protocols.”

To whom?

> even better, I'd love to hear those specific suggestions.

That’s the question I was asking.  Sorry for being unclear.

> unintentional harm to society.

This was my understanding as well.  I think it’s currently not going to succeed at meeting that need.

> Yet, some remote communities

These are great examples.  I wonder if this document as it is at present could have helped to avoid this problem.  I think the answer is no.  It would be fantastic if this document could be written in such a way that it could help to avoid problems of this type.

The bottom line is that I agree completely with all the aspirations that you have stated.  I just don’t see how this document helps to bring us closer to achieving them.

The canonical answer to that is “send text.”  However, when I have commented in the past, my comments have seemed not to be heard.  If I were to send text, it would almost be a complete rewrite.  I’m certainly not willing to undertake that sort of effort without some notion that it would be useful.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Sep 2019 09:04:41 -0800

> our purpose is to inform.

I suppose this is another opportunity to remind people to
distinguish between disagreements that they can live with and
disagreements they cannot.  Also, sometimes (often, actually, I
think) it's necessary to document points of view we disagree
with, and presenting those points of view is not the same as
arguing for them.  However, I think it's worth noting that if
this is published as an RFC it's likely to be widely misconstrued
as representing the IETF view and it's probably a good idea to be
sensitive to that.

Also, as noted elsewhere, IRTF documents do not need to represent
RG consensus but I think it's a good idea if there's at least RG
agreement that the contents are correct.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Mark Perkins <[email-masked]>
Date: Tue, 17 Sep 2019 19:41:46 +0000 (UTC)

I disagree that these are real problems - more like things that need correction rather than 'show stoppers'.

The difference between standards and protocols is implicit in section 4.5, but I agree this needs to be made explicit in the vocabulary section (which is far too short). To note, this is not specific to this document, but is unfortunately widespread leading to the conflation of the two - as mentioned by Eliot.

So, vocabulary entries for protocol; standard; internet protocol; internet standard; ietf protocol; ietf standard.

The lack of WTO citation is not critical, just something that needs to be recitified (I have no argument with the WTO paragraph, it is fairly anodine). Lack of citations need to be indicated, and provided to the author(s) when aware.

The draft is full of examples - where precisely do people think they are missing?

This question of citations and examples is also linked to the question of 'readability', by which people here seem to mean creating the wish to read further - rather than legibility. BUT, given the subject matter, I think the supporting citations and examples are essential 'somewhere' in the document, even if in a section of their own (to increase the documents overall 'readability')

I agree that the importance of the research question needs explaining, although Neils states it clearly outside the document: 'And to prevent the RG of going in circles sometimes also about things that seem 'trivially true' '

Personally, I think that many 'techies' try to pretend that their work is 'not political', whereas it is clear from the document that this is not the case. Why is this important? Human rights ARE political, and internet protocol & standard processes, especially where they impact on human rights (especially 'fundamental' human rights) ARE political. This means that aside from 'Security considerations' for protocols, there are other, 'political', 'human rights' considerations that should be made clear, and not avoided. Paul Wouters puts this more diplomatically than I do.
Mark Perkins

    On Wednesday, September 18, 2019, 4:04:57 AM GMT+11, Melinda Shore <[email-masked]> wrote:  

Melinda

---

From: Juliana Guerra <[email-masked]>
Date: Tue, 17 Sep 2019 17:06:05 -0500

Hi,

I think this draft is complete in terms of content, recognizing its
purpose as a platform for further discussion.

For me, it's still difficult to get all the rules and acceptable manners
in IETF/IRTF but I suppose (correct me if I'm wrong, please) that RGs
need an interdisciplinary discussion, which also implies other
methodologies and problem statements, different from -and in dialog
with- engineering.

I totally think this document is useful and valuable, and I second
Paul's idea of including it in the newcomers introduction conference.

I also think that making some text changes will help to clarify the
problem. Reading the draft I feel there are a lot of implicit ideas that
can be explicitly stated. I propose some changes, different from those
proposed by Gurshabad. Hope it can help.

- For me it's a little weird to find only one sentence in Section 3.
Although the question is suggestive, its not a research question because
there are only two possible answers: yes or not. It would be interesting
to find a problem statement, for example one referring terms like open,
formal, voluntary, competition and collaboration, which appear as
problematic in relation to standardization processes throughout the
draft. Articulating these terms in one sentence may help to explicitly
tie Sections 4 and 5.

- I haven't followed in detail earlier discussions about this draft, and
I don't know why the definition of "protocols" and "standards"
were removed from Section 2 (Vocabulary Used). Beyond that, for me -an
external reader or an already new participant- in Section 5 it is not
clear what exactly is referred to as "standard setting processes" in
general, and in particular in IETF. This discussion about 'de facto' vs.
'de jure' and normative vs. voluntary in IETF particular case, can be
stated in one paragraph, may be in the Conclusions.

- For me it's not clear where exactly emerges the conclusion, mentioned
in a previous discussion, about "that standards are in effect normative,
even if we claim them to be voluntary". Reading and reading again the
draft I'm not sure if it emerges from the general review or from the
interviews, mailinglist and meetings exchanges, and participatory
observation. I don't think this part needs more content but to be
presented in a clearer form.

best,

Juliana Guerra

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Sep 2019 18:12:36 -0400

On Sep 17, 2019, at 1:04 PM, Melinda Shore <[email-masked]> wrote:
> disagreements they cannot.

FWIW, I responded because Avri asked for feedback, not because I need for my complaints to be addressed.   If the WG generally feels that the document is useful as is, I don’t want to stand in the way.

---

From: Mark Perkins <[email-masked]>
Date: Wed, 18 Sep 2019 01:15:17 +0000 (UTC)

Hi all
Personally, I agree with the argument of the document and its importance, which is why I believe that it should be both be readable (people should want to read it), legible, well documented and supported by examples & citations.
Those who have pointed out lacking (or incorrect) citations &/or places where examples are missing, PLEASE be precise in pointing these out & providing citations, examples or corrections.
I agree that the vocabulary section needs to be filled out, and the text concord with definitions given (standards vs protocols, etc).
As for readability, I am not sure how this can be improved, unless many citations & examples are moved to a 'reference' section. Given the subject matter of the document, I do not think we can avoid providing many of the citations/examples...
As for the research question, as given it is clearly a binary yes/no.  Perhaps within the conclusion, a sub-section of 'resulting research questions' could be useful.
My 2 pacific francs
Mark Perkins
    On Wednesday, September 18, 2019, 9:06:18 AM GMT+11, Juliana Guerra <[email-masked]> wrote:  
 
 Hi,

best,

Juliana Guerra

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Sep 2019 21:39:32 -0400

Hi,

Speaking only for myself.

On Tue, Sep 17, 2019 at 07:41:46PM +0000, Mark Perkins wrote:
> 
> Personally, I think that many 'techies' try to pretend that their work is 'not political', whereas it is clear from the document that this is not the case.

Whether it is clear from this document is precisely what I find
contentious about the document, and asserting that it is so clear does
not make that true.

Despite not having the time for a complete review, I feel some
affection for this document because I made some early contributions to
it, so I had another look.  The assertion that the document "shows"
that protocols are in fact political is still not, in my reading,
borne out.

Section 4 attempts to outline various positions about the claim that
protocols are inherently political.  I think it mostly succeeds in
this, although I think some of the descriptions are more complete,
more charitable, or both than others.  I continue to suspect that §4.5
makes the conflation I asked about once before, but I can't really
focus on this such that I could make the case properly.

I really don't understand section 5.  I guess I understand that it is
an attempt to hook up the discussion of protocols and politics to the
function of standards.  Ironically, however, this undermines any
argument about protocols being necessarily political based on §4,
because not every protocol is a standard.  It would seem that a Venn
diagram would show this pretty clearly, but they're hard to make in
ASCII art.

But the real problem comes in §6, where claims are made that are
poorly supported by the text, and not obviously true.  For instance,

   Economics, competition, collaboration, openness, and political impact
   have been an inherent part of the work of the IETF since its early
   beginnings.

strikes me as a claim that may or may not be empirically true, but it
would need rather a lot of argument to support it.

	… but [the IETF] does set
   open standards for interoperability on the Internet, and has done so
   since the inception of the Internet.  

is at least possibly false, since many of the early standards for
Internet interoperability were set by the IAB, of which the IETF was a
subsidiary (see https://tools.ietf.org/html/rfc1120).

	Because a standard is the blue-
   print for how to accomplish a particular task, the adopted standards
   have a normative effect.  

This claim is belied by the number of IETF standards that are widely
ignored or have not been implemented, and it suggests that the IETF
has a kind of control that it does not actually have (as acknowledged
only in the previous sentence).  The best we can get is that adopted
standards _may_ have a normative effect, sometimes.  That seems hardly
surprising, but it's also a pretty weak claim on which to build a
universally-quantified claim about protocols and politics.

I'll number some propositions in the next passage for ease of
reference:

   [0] Whereas there might not be agreement among the Internet protocol
   community on the specific political nature of the technological
   development process and its outputs, [1] it is undisputed that standards
   and protocols are both products of a political process, [2] and they can
   also be used for political means.  [3] Therefore protocols and standards
   are not 'value-neutral, [4] and neither is the IETF' [RFC3935].  [5] Thus we
   can answer the research question 'are protocols political' in
   affirmative fashion.

In the above, [0] is simply an acknowledgemwnt of the differences in
§4.  [1] appears to be a claim that each of these propositions is true:

	[A] all standards are always a product of a political process
	[B] all protocols are always a product of a political process

It is entirely unclear to me that [B] is in fact true, much less that
it has been demonstrated anywhere in this draft.  And it seems trivial
to come up with an example where this is false -- for instance, the
process where some lone programmer writes v0 of some protocol for his
or her software such that others can use it (this is sometimes called
"an API", but it's often just as easily described as an immature
protocol).  At the very least, to call such a process "political" is
to render the meaning of "political" empty.  So, the truth of [1],
which depends on both [A] and [B] being true, seems suspect to me.

It seems to me that [2] is trivially true, since it is merely a claim
about both protocols and standards being possibly used for political
means, and as long as we can think of one example this proposition is
then true.

[3] is a very fast conclusion that, with liberal application of the
principle of charity, can be rendered thus

	[a] If a thing is both the product of a political process and
	possibly used for political means, then it is not value-neutral.

	[b.1] ARGUMENT FROM [1] GOES HERE
	therefore
	[b] protocols and standards are not value-neutral

	therefore

	[c] Protocols and standards are not value-neutral

(As you can see, [c] is the same as [3].)  The problem here starts
with the difficulty in accepting [1], as I outline above.  If we do
not believe that [1] is demonstrated, then the antecedent of the
conditional in [a] is not shown as [b], so the syllogism that gets us
to [c] can't proceed.  That's the first problem.  But the second
problem is in the premise [a] itself.  For the truth is that [a] is
just an _assertion_ that a political process and use for political
means entails that the result is somehow political.  That is not
actually demonstrated, however, and as a refutation of "the politics
lies entirely in the human use, not in the object itself" described in
§4.1 it is simply begging the question.  The number of seats in the
Canadian House of Commons is the product of a political process and it
is certainly used for political means.  That does not make the number
of seats "political" in itself: it might be just a contingent fact
about the current composition of the House of Commons.  In other
words, this depends very much on how one interprets "φ is political",
which was of course the very question that was open in the first
place, so the text has reasoned in a circle.

[4] does not follow from [3] at all, and I don't see how it follows
from any of the other premises either.  I don't know that it matters,
because it isn't obvious to me that the draft ever wanted to make the
claim that the IETF is or is not political.  One suspects that the
goal is to make an approving appeal to authority of RFC 3935, but it's
hard to tell.  [5] is false in case [3] does not hold, and since [3]
is in trouble [5] is too.

In case anyone wanted my recommendation, it would be for the RG to
change the focus of the document:

	In this document we aim to outline different views on the relation
   between standards and politics.

This would be enough and would be a contribution to the RFC Series
because it would document some positions (in §4).  In this case §6
could simply be removed.  I don't know what to do with §5 because I
don't understand it.  Alternatively, the author could publish this
document without it being an RG document, thereby avoiding the need to
come to consensus on a position that I believe unlikely to yield such
consensus (mostly because I believe the position to be manifestly
false).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Perkins <[email-masked]>
Date: Wed, 18 Sep 2019 03:32:17 +0000 (UTC)

Thanks Andrew
I think that you are reiterating, in a more detailed form, why it is essential that the vocabulary section distinguises between protocols & standards, and that the following text clearly applies that distinction.
I would argue that standards are inherently political, and that protocols that become standards thus also become political.
Protocols can be developed in a myriad of ways; while it COULD be argued that since an individual is a product of a social/political process, his protocols, for the purposes of this document, I think that would be unecessary sociology. However, some protocols are developed by groups of people (commercial, academic, non-profit, etc), which are clearly embedded in a political context which constrains/directs their development of protocols; in this case, the protocols can clearly be seen as 'political' as well as 'technical', some more so than others.
While standards come in a variety of flavors, with a variety of coercive mechanisms (market, legal, technical, etc), their very development as standards is political. Whether they are used or not can change over time, as can be the extent of their use (individual, local, international, etc.) and is a reflection not only of their technical nature, but also of their political nature - which can also change over time.
For me, the document does show that protocol and, especially, standard development / work is political, BUT I come from a political rather than techie background ;) I am glad that Andrew (& others) are pointing out weaknesses that need to be addressed in the argumentation, and hopefully (along with clear citations & examples) we can address those weaknesses so that he (& others) agree that document has shown its assertions to be true
Mark Perkins

    On Wednesday, September 18, 2019, 12:40:20 PM GMT+11, Andrew Sullivan <[email-masked]> wrote:  
 
 Hi,

    therefore

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Sep 2019 09:59:18 -0400

Hi,

On Wed, Sep 18, 2019 at 03:32:17AM +0000, Mark Perkins wrote:

>  some protocols are developed by groups of people (commercial, academic, non-profit, etc), which are clearly embedded in a political context which constrains/directs their development of protocols; in this case, the protocols can clearly be seen as 'political' as well as 'technical', some more so than others.

That formulation repeats the equivocation between "_x_ is developed
through a process that includes politics" and "_x_ is political".  I
guess it is no longer clear to me what "_x_ is political" means.  But
it seems pretty clear to me that such a conclusion could be used for
all sorts of mischief.

Look, the US state of Indiana once considered a bill that was supposed
to have a method to square the circle and that imputed a value of
π≈3.2.  Does this mean that the value of π is political?  Well, yes,
in some trivial sense: it has been the subject of a process that was
itself entirely political.  But that does not mean that the value of π
is political in the ordinary sense of "_x_ is political" or that it
would be in any way appropriate to try to use the legislature to
settle once and for all the correct way to calculate diameter.

I think the manifold sense of "_x_ is political" is obscured rather
than clarified at least in §6 of the draft.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]