Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00

From: Niels ten Oever <[email-masked]>
Date: Sun, 9 Oct 2016 18:31:28 +0200

Hi Stephen,

Thanks so much for this extremely thorough review. We've responded to
all your comments and offered some solutions or at least some arguments
why we did not think it was a problem. Responses inline, and a new
version can be found here:

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

On 09/22/2016 02:33 PM, Stephen Farrell wrote:
>
> Hiya,
>
> I spent a bit of time reviewing this finally.

We also spent a bit of time coming up with a reply, sorry if it took
longer than expected (and announced).

>
> Overall, I think this is a fine piece of work and I look
> forward to it becoming an RFC. I don't think it's nearly ready
> yet though, there's a lot to fix. (But see #1 below for a
> suggested short-cut.)
>
> Cheers,
> S.
>
> General, and, I think, important to handle...
>
> (1) What kind of consensus are we aiming for here?
>
> I'm not sure if this would be better off aiming to be a
> document that has RG consensus or not. There's a lot of fine
> text here, but there's also quite a few instances of text for
> which I think it may be quite hard to establish RG consensus,
> and where that may take some time and draft iterations.
> (You'll see some examples in my specific conments.) Clearly,
> processing the document aiming for RG consensus is an option,
> and maybe the default option, but I wondered if it'd also be an
> option to proceed more quickly with this documenting the
> author's research and opinions/conclusions (and not necessarily
> RG consensus) and to then later try to extract an updated
> version of the guidlines/questionnaire into a separate RFC
> aiming for RG consensus. I'm not arguing strongly for that
> latter plan but just wanted to ask in case it helps the RG (and
> Avri who I guess will have the fun of figuring this out:-).
>

Up to now we have been able to reach consensus on all points, so let's
not lower the bar!

> (2) Length and structure for protocol developers.
>
> I think this is too long to be very useful for protocol
> developers.  I doubt many of them will wade through 40+ pages
> to get to the bit that's really aimed at them. (And which
> pretty much needs a total re-write.) The plan mentioned in #1
> might help there I guess but another idea might be to move
> section 5.3.2 to the front and make a lot of the rest of the
> text into subsequent explanatory material and/or appendices.
>

I think this is actually quite an apt description of the research as it
has been done. After we managed to get this into a document I think it
would be great to come up with next steps for 5.3.2, such as bringing it
into the IETF.

> (3) What architecture do you mean?
>
> There are 25 lines that mention the term architecture in the
> draft and I'm not at all sure the term is used to mean the same
> thing throughout.  I'm also not sure that there is an accepted
> thing that is "the one true Internet architecture" that has
> IETF consensus but you seem to me to be assuming that there is
> such a beast. Is this just a language issue or a deep(er)
> problem?  I'm not sure, but eliminating references to the
> Internet architecture where possible would I think help.  See
> some of the specific comments below, but I'd recommend a pass
> over the document to check how this term is used as well.  (To
> try head off some lines of debate that might follow from this
> comment, I do think there are aspects of Internet architecture
> for which we do have IETF consensus, but I don't think the IETF
> has consensus on any one way in which to put all those together
> into something that'd be rightly termed the (or an) Internet
> architecture. I think RFC1958 section 2.1 supports that
> position btw.)
>
Thank you for pointing this out. By architecture, in this text, we are
referring to the technical functioning of the Internet – as it pertains
to the remit of the IETF. Would it be better if the first mention of the
word architecture came with the following clarification: ‘Internet
architecture is a catch-all phrase. In order to ensure it does not ring
hollow we want to clarify what we mean by this term. Our definition is
partly based on the consensus understanding of the term architecture as
laid out in RFC RFC1958 section 2.1, which states: ‘Many members of the
Internet community would argue that there is no architecture, but only a
tradition, which was not written down for  the first 25 years (or at
least not by the IAB).  However, in very general terms, the community
believes that the goal is connectivity, the tool is the Internet
Protocol, and the intelligence is end-to-end rather than hidden in the
network. The current exponential growth of the network seems to show
that connectivity is its own reward, and is more valuable than any
individual application such as mail or the World-Wide Web.  This
connectivity requires technical cooperation between service providers,
and flourishes in the increasingly liberal and competitive commercial
telecommunications environment. The key to global connectivity is the
inter-networking layer.  The key to exploiting this layer over diverse
hardware providing global connectivity is the "end to end argument’.
Building on RFC1958 we hold that the word architecture, in the context
of the IETF, refers to all the protocols, procedures, processes and
their accompanying people and politics that go into ensuring the
Internet remains a medium for unfettered global connectivity.’ Would
such a definition clarify our use of the word architecture sufficiently?

Additionally, we would like to push back a bit against the argument that
because there is no consensus in the IETF on what the term architecture
means, we cannot use it in the text. The IRTF should be the space where
we can push the boundaries on that discussion, bringing in definitions
from academia as we do in the text by referring to amongst others the
work of Prof. Denardis and Prof. Bowker on architecture.

> (4) What does "=" mean here?
>
> In section 2 and later (in 5.2.2) you have diagrams with
> bracketed terms on the left, then "=" and then another term on
> the right. I just don't get what you mean by that "=" sign. You
> say "combine" and "makes up" but frankly I don't get it, even
> though I was in some of the meetings where those pictures were
> presented.  E.g. in section 2, I don't get how to combine
> authenticity and anonymity in any useful sense, as those are
> mostly in conflict.

The easy answer, which will probably will not be enough for you, would
be: depends on the usecase. If we for instance take the example of TLS
for .onion websites, there the security model includes anonymity as well
as authenticity.

I think it can easily be argued than in many models of security, privacy
and anonymity play a role, in others anonymity may be less important.

To reflect this I changed the text to:

A combination of reliability, confidentiality, integrity, anonymity, and
authenticity is what makes up security on the Internet.

I also changed the '=' in to an '⇒'

> And the 2nd picture in section 2 has
> connectivity on the RHS, which you defined as being an "extent"
> and none of the things on the LHS seem to reflect that at all.
> While those pictures may well have been ok for use in
> presentations, I'm less happy that they're useful in an RFC.
> So, what does "=" mean? Can you actually define that relation?
> (Apologies if I'm being all "techie" and anal here, but I
> really don't get it, honest;-)

Where it come to the definition of rights in 5.2.2 the relation between
the LHS and the RHS should be 'contribute to an enabling environment
for', so I replaced the '=' with '⇒' and added an explanation.

>
> (5) The DDoS discussion is still wrong.
>
> I think the discussion of DDoS in section 5.2.11 (see below for
> specifics) is not good enough and that section needs to be
> re-written or mostly deleted. (Not all list discussions need to
> end up with a section in the document.) It may be the case that
> what is needed is some discussion of forms of protest using the
> Internet, but that I think would better be the topic for
> another document, if soeone has the energy/interest. (That
> could be interesting too!) For this document, if it is aimed at
> the IETF audience, the current text is not useful as it ends up
> as a (controversial) NOOP - "don't enable DoS" is already in
> RFC3552 since 2003.
>

The scope of this document is _very_ different from RFC3552. It analysis
a case of technology and it's impact human rights. So, it has a
completely different role from RFC3552, even though the conclusions are
largely the same.

> (6) The questionnaire is not good enough.
>
> 5.3.2.x.y: Please go through these questions yourself (for some
> protocol) and write down answers and see then what you think of
> the questions.  I think a number of these questions will not
> produce meaningful answers in any real attempt at using them.
> I also think that someone who is not an author and who is
> developing a new protocol needs to have gone through the
> exercise at least once before we should publish this document
> as any RFC. It is far too easy to ask unanswerable or
> non-useful questions otherwise.
>

We have had four people who did an exhaustive roadtest of the
questionnaire and used it on their draft in development. They presented
the outcomes at the session in Berlin and were also posted to the list.

> (7) Missing introductory text.
>
> I think there's a missing bit of explanatory text about rights
> in general that'd help some more IETF-oriented readers.  As I
> understand it, in HR all rights are contingent in the sense
> that governments are expected to balance competing rights in
> all cases. So e.g. even though we have a right to life,
> governments can legislate for capital punishment and still
> consider themselves signed up to the UDHR. I think this is
> worth noting, as for example, it means that we do not
> necessarily want to enshrine all the fine concepts on which the
> IETF has consensus as human rights, in particular, claiming
> that one had a right to encrypt could as a side-effect allow
> some governments to claim that they had a right to limit one's
> knowledge of mathematics, if that is claimed to compete with
> other rights (e.g. to safety). I'm not sure if this is the
> right HRPC document to capture that, but it was a surprise for
> me when I first found that out, so it may be worth adding a bit
> of text explaining basic rights concepts like that here or
> somewhere else.
>

The concept of balancing rights is not an easy one and there is also no
consensus in the law community about how this should be done. There are
many scholarly papers written about this, and I would large go with the
approach in the UN Guiding Principles for Business and Human Rights. So
I would offer the following text:

    Human rights can be in conflict with each other, such as the right
to freedom of expression and the right to privacy. In such as case the
different affected rights need to be balanced. In order to do this it is
crucial that the rights impacts are clearly documented in order to
mitigate the potential harm in a proportional way. Making that process
tangible and practical for protocol developers is what this research
aims to ultimately contribute to.

> Specific comments (without reference to importance:-)
>
> Note: I'm not quite sure why, but I read this through and
> commented as if it were a PhD thesis, which is a bit more
> stringent that e.g. IESG evaluation. Apologies if that seems
> like nitpicking, but I think given the possibly political
> (ab)uses to which this RFC could be put, and since we might
> effectively kill the impact of the RG if we do this first RFC
> badly, we might be better off to take that approach. I'm
> willing to believe that I'm being too nit-picky though:-)
>

Does this mean that if we answer all these questions to your
satisfaction we'll get a PhD ?

> abstract: These ought not have references and I think is too
> long.  I'd suggest keeping the 2nd para (minus the reference)
> and move the rest to the intro.

Proposal accepted

>
> intro, p3: How do you know that "open, secure and reliable" are
> necessary conditions here? I think you're likely correct, but
> I'm not sure that claim is justified in the document or in the
> references.

Reference added (to FOC Talinn agenda)

>
> intro, p3: "The Internet aims to be a global network of
> networks that provides unfettered connectivity to all users at
> all times and for any content [RFC1958]. " The "aims to be"
> there seems odd, and I don't see where 1958 says "at all times"
> which seems to me overstated.

Changed it into:
    The purpose of the Internet to be a global network of networks that
provides unfettered connectivity to all users and for any content
{{RFC1958}}

>
> intro, p3: "One could even argue that the Internet is not only
> an enabler of human rights, but that human rights lie at the
> basis of, and are ingrained in, the architecture of the
> network." Sure one could argue that but is that claimed as an
> RG consensus? And you're assuming that there is one true
> Internet architecture there I think, which is problematic.
>
Although there has been a lot of discussion on the extend to which human
rights were at the top of the minds of the people developing it, the
technical principles like end-to-end, decentralization etc which were
priorities for the initial developers overlap sufficiently with human
rights like freedom of speech and access to information to make this
argument stick. It might have been a happy accident, but few in the RG
have disputed that - when looking at it from this perspective - human
rights are not intrinsically weaved through the structure of the
network. We have specified our definition of Internet architecture to
mitigate your concerns there.

> intro, p3: "By doing so, the IETF enabled the manifestation of
> the right to privacy, through the Internet's architecture." I
> think this shows a misconception of the IETF's role, at least
> as I see it. I don't believe that the IETF controls the
> Internet's architecture in the sense implied here. If you'd
> said "through it's protocol design processes" at the end
> instead, then I think that'd be better. And saying "Enabled"
> makes it sound like a done-deal and we can all go home, which
> strikes me as pretty optimistic;-)

A little wish-fullthinking never hurt anyone I guess ;-) Incorporated
your suggestion at the end of the sentence  and changed 'enabled' to
'allowed' for.

>
> intro, p3, "Openness of communications of the technical design"
> what does that mean? And how does it "foster freedom of
> communication"?  I don't get the argument here.

We mean to say here that the nature of the Internet was fundamentally
open. People could just show up and hack away. Have changed the sentence
to read: The open nature of the initial technical design (open
standards, open source, etc) fostered freedom of communication as a core
value, everyone could join and everyone could submit code. Hope that
clarifies a bit. This was done to show that today's Internet is more
closed. Closed standards (and standards bodies) walled garden
applications etc.
>
> intro, p3, "galvanize" is overstated and the IETF doesn't
> "ensure" what happens in the network, but only in the protocols
> we define - what implementers and operators do with that is
> really up to them and not the IETF. That's an important
> distinction that's mixed up in a few places in the document,
> including in the next sentence - if the IRTF produces this RFC,
> that's great and will help to ensure better realisation of HR
> issues, but the existence of the RFC itself will not ensure
> anything.
>
Have changed the words ensuring and galvanizing for the word encourage.
And changed the word encourage in the second sentence to the word
facilitate. I understand that the IETF/IRTF does not ensure anything.
But to tone the language down all through the document would take away
from the fact that the IETF/IRTF does have a substantial role in setting
the standard (no pun intended) for what they think the network should
look like, irrespective of what implementers and operators end up doing.

> section 2: "unfettered" - while I myself do like that term, I
> think following the approach from RFC 4084 which you quote here
> would be a good general approach for this entire document.
> 4084 section 1.2 says that it intentionally avoide pejorative
> terms so as to increase the likelihood that operators will pay
> attention. I think following that guidance in this document
> would be good. Most of the text is actually fine in this
> respect, but an editing pass based on a review from some (as
> yet uninvolved) protocol developers would be a good thing.  For
> example, some of the references to companies and products later
> on might raise hackles in a way that'd be counter productive.
> Anyway, 4084 does not use the term unfettered at all so better
> to not say that here.
>

OK - removed 'unfettered'.

> section 2, and elsewhere: I think the use of the term anonymity
> is wrong in almost all cases in this document.

Interesting. Happy to fix, but would be great if you could give me a bit
more to work with.

> While it is the
> case that users (and non-technical folk in general, including
> law makers) may talk about anonymity, I think there are few to
> zero technical folks who think that anonymity is achievable at
> any scale today.

Anonymity has a very specific meaning in both legal and technical terms,
there I think it's important that we work on this. The UN Special
Rapporteur on Freedom of Expression has underlined the importance of
encryption and anonymity online (
http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/CallForSubmission.aspx
). And eventhough it is indeed a hard technical problem, I actually
think quite a lot of people are working on this. Tor is indeed probably
the best 'running code' example, but there is also Briar, I2P, Tribler,
etc. There is also an  increase in Operating Systems that are geared
towards anonymity (by integrating Tor and other measures) such as
Subgraph, Tails, and Qubes, so I think discussing it is relevant, and I
don't think we should take a step back an accept that it's not possible.

> Tor may be the closest we get, but it's not at
> all clear to me that anonymity is really a requirement or a
> goal for almost all protocol designers almost all of the time.

Maybe it's not and maybe it should be. Because there is a clear human
rights impact here. The aforementioned report by the UNSR recognizes the
essential role of encryption and anonymity in realizing human rights
protected under international law, as such technology “provide[s]
individuals and groups with a zone of privacy online to hold opinions
and exercise freedom of expression without arbitrary and unlawful
interference or attacks.”

> I do think we should consider "being hard to track" and similar
> as requirements/goals but that's different and I'm not sure we
> even have that good an idea about all the trade-offs that are
> involved here.

Isn't that something that should be documented?

> I'd recommend checking every time you use this
> tern, and getting rid of most of them.  (Will try to point out
> the ones I think are problematic below.) Note that the 4949
> definition is probably ok(ish:-) but once there are muliple
> protocols involved things become very unclear and in real
> networks, there's almost always someone somewhere who can
> identify (or re-identify) a person, host or bit of s/w and that
> context seems to be missing here when you use the term.
>

See above.

> 2, Defining connectivity as an "extent" is interesting. I'm not
> sure if it's precise enough though, e.g.,  what'd "twice better
> connectivity" mean? Not sure what to suggest but I do think
> you're right to not define it as binary. Maybe refer to RFC4084
> here again for some different types of connectivity?

Done - added reference to RFC4084

> 2, "content-agnosticism" - hmm, that seems a bit broken to me
> as a definition, it is ok to treat delay intolerant traffic
> differently and we do want that sometimes. "Identically" seems
> too strong, but I'm not sure what better definition to use
> without getting into an essay about net neutrality and similar
> things that I don't know much about;-)
>

I did not change this. Because although your statement on the delay of
intolerant traffic is true, common practice does not influence the
definition of content agnosticism perse.

> 2, "end-to-end" - I much prefer to refer to this as an argument
> and not a principle. You'll get different opinions on that
> though:-)

Could you elaborate? I think we documented the use and origins pretty
well in bodies of literature and academic discussion.
>
> 2, "Internet censorship" - I think this definition is too broad
> and could even be read to discourage data minimisation.  It
> seems to be missing the concept that the censor is acting
> without the agreement of the endpoints, but agreement/consent
> is such a slippy concept on the Internet maybe that'd be a bad
> idea. Anyway, this seems to broad to me fwiw.

Do you have any suggestions for new language to replace it with?
>
> 2, "Internet Standards as an Arena for Conflict"... eh...
> What? That's not a term to define, it's an argument for over
> beer! I think you need to delete that from this section. If you
> want to include the text somewhere then find a better way to do
> that I'd say. (But I'd still then ask: where is the principle
> of constant change defined for all time? :-)
>
Agreed. Moved the text to the literature and discussion section

> 2, "i18n" - I think you're wrong that "Many protocols..." don't
> support i18n. It's for sure true that a bunch don't do this
> well and ought, but "many" seems overstated. Did you count
> them?

We got this observation from the i18n WG in Yokohama.

 (Note that for many binary protocols i18n isn't very
> relevant at all, if one assume that i18n is mostly important
> for end-users and less so for developers or bigger operators.)
>

Here I would like to push back with the arguments Ramsey Nasser
introduced at his presentation at the hrpc session at IETF95. Based on
his programming language in Arabic he showed through 'engineering
performance art', that the Internet and its technical infrastructure is
inherently hostile to non latin characters, which send the message that
the Internet natively belongs to English speakers. This is true for
developers, operators and users alike imho.

> 2, "Open Standards Conform" - what? That's not a term to
> define. I think you also say this elsewhere so deleting this
> would be right. And what's RFC2606 got to do with it?
>

There should have been a hard return there. The text is lifted from
RFC2606. Should be fixed now.

> 2, "Openness" - I think this is just wrong and am not sure what
> you even want to define. You cannot for example have free
> access to hosts in my home network, no matter how openly you
> ask:-) If you want to define openness, then I think it'd have
> to be about processes and not access to hosts.
>

The definition doesn't say access to all hosts, right? I don't think I
agree with the critique.

> 2, "permissionless innovation" is not all about new protocols.
> It's also about using existing protocols in new ways without
> having to ask. Not all such uses are usefully described as new
> protocols.

added that to the text.

>
> 2, "Privacy" - I think adding some references to the HR and
> legal literature about privacy could help the more technical
> readers here.
>

Added:
The right to privacy is articulated  all of the major international and
regional human rights instruments, including:
{{UDHR}} Article 12: “No one shall be subjected to arbitrary
interference with his privacy, family, home or correspondence, nor to
attacks upon his honour and reputation. Everyone has the right to the
protection of the law against such interference or attacks.”
{{ICCPR}} Article 17: “1. No one shall be subjected to arbitrary or
unlawful interference with his privacy, family, home or correspondence,
nor to unlawful attacks on his honour or reputation. 2. Everyone has the
right to the protection of the law against such interference or attacks.”
The right to privacy is also included in:
Article 14 of the United Nations Convention on Migrant Workers;
Article 16 of the UN Convention on the Rights of the Child;
Article 10 of the African Charter on the Rights and Welfare of the Child;
Article 4 of the African Union Principles on Freedom of Expression (the
right of access to information);
Article 11 of the American Convention on Human Rights;
Article 5 of the American Declaration of the Rights and Duties of Man,
Articles 16 and 21 of the Arab Charter on Human Rights;
Article 21 of the ASEAN Human Rights Declaration; and
Article 8 of the European Convention on Human Rights.

> 2, reliable, resiliance and robustness - I'm surprised there're
> no references for the first two and puzzled by the references
> for the 3rd.

References added (my bad, thanks for spotting) and offered grammtical
improvements for robustness:

: The resistance of protocols and their implementations to errors, and
to involuntary, legal or malicious attempts to disrupt its mode of
operations. {{RFC0760}} {{RFC0791}} {{RFC0793}} {{RFC1122}}. Or framed
more positively, robustness is the quality of a system that can provide
functionality consistently and without errors despite  involuntary,
legal or malicious attempts to disrupt its mode of operations.

> There also seem to be very few reference to these
> later, which makes it odd to find them here. I wonder if the
> formalism you're using (introduced at the end of section 2) has
> caused you to shoe-horn in definitions of these?
>

Nopes - these were terms that kept returning in interviews and during
research. I also do not think they're hardly mention actually.

> 2, scalable - it's often a challenge in proocol design to
> ensure that a protocol scales down as well as up, in the sense
> of working well for smaller networks/deployments.  Might be
> worth pointing that out as it's relevant here when one
> considers designing new protocols potentially putting too much
> emphasis on the requirements of only bigger operators (who are
> in the room).

good point, added the following language to the text. In protocol design
ensuring for the capacity to both scale up and down can be a challenge.
Yet, it is important to consider the capability of the protocol to do
both, to ensure new protocols consider the requirements of both big and
small operators.

>
> 2, stateless - is used exactly once later, and stateful is not
> used at all later - do you really need this here? (Just define
> it when used, but I think protocol developers will get the
> meaning anyway.) You could also say that retaining state has
> potential privacy impact, which may not be so obvious. (That
> retaining state impacts on other protocol features such as
> hard-reboot is fairly well understood I think.)
>

Removed glossary entry

> 2, "Strong encryption / cryptography" I don't think this is
> needed or useful - why is it here? I think the IETF community
> know this already, is it useful for some other readership?  If
> so who? (Since I'm not sure it'd be that useful for any
> readership.)

It is an IRTF document, so I am hoping that it will be read by
researchers as well as protocol developers.

> 2, "transparent" - I don't like this definition which I think
> is not actually definining the term in the sense in which you
> use it in this document. As you actually use the term, it is
> mostly about processes, which is not what RFC2775 is about. In
> fact, I think you're actually using the term in it's normal
> English usage and don't really need a specific definition.
> (Though I didn't check all uses of the term.)
>

Fair point. Removed.

> 2, " The combination of reliability, confidentiality,
> integrity, anonymity, and authenticity is what makes up
> security on the Internet." No. That is just wrong. For example,
> that list omits DoS resilience, bugs (and protocol flaws) that
> cause problems like heartbleed, and I think, much else besides.
> I'm not sure how to fix this. (But see my general question wrt
> "=" as used here.)
>

I think this should be solved with the solution offered above.

> section 4: I don't accept that "protocols are politics by other
> means" - if I develop a way for two computers to interact in my
> (non-existent as it happens:-) basement, that is not politics.
> If I publish an academic paper on a faster way to do ECDH
> that's not politics.  I know it's a quote, but I don't think
> you ought present that quote in that way (reading IMO as if it
> were an RG consensus statement) without qualification.  The
> relevant qualification I think is tricky to formulate but has
> something to do with broad deployment or with deployment at
> some technical choke point that offers significant control to
> someone.
>

I want to push back a little on the fact that this is not RG consensus.
I think a lot of people have expressed the sentiment that their
technical protocols increasingly have an impact on the political realm
and vice-versa. As such protocols have become enveloped in politics,
whether we/the IETF/the technical community likes it or not. Not to
speak of the fact that many prominent academics, which include engineers
and computer scientists, underwrite this statement. I also do not think
it is without qualification, the text goes on to mention at least eight
different papers that carefully qualify these statements. If we however
write out there arguments we run the risk of making that bit of text
suffer from TL;DR.

> 4: I don't get the "values-by-design" point and how it's
> relevant to the IETF. I don't recall discussions about that on
> IETF/IRTF lists. Is this perhaps something that's really being
> discussed outside the IETF/IRTF context? If so, then the
> statement that these are a "new focal point" is not correct.
> (If you want to say this should or could be a discussion to
> have, that'd be fine but that's a different statement.)

These discussions have been had on the lists, in addition to the latest
session of hpc in Berlin when United Nations Special Rapporteur David
Kaye presented his latest report on the responsibility of SDOs vis-a-vis
human rights. The HRPC work has been focused specifically on the
question of how values get translated to design, and how they should or
should not. As such, I am surprised to hear you say that you have not
seen this happen on the list.

>
> 4: "tools of enforcement" - I'm not sure what you mean here. If
> you mean law enforcement then saying that would be better, but
> the sentence is vague, for me anyway so would be better
> rephrased.
>

The full quote in the paper reads:  "The “theory of the blunt
instrument” says that if  you  can  blunt  the  tools  of  your
antagonist  in  a  tussle,  you  may be able to disable him. Thus, if
all users of the Internet always  encrypted  everything  they  sent,
there  could  be  no wiretaps and no discrimination based on content.
The only tool left to the regulator (e.g., the state) would be the blunt
instrument  of  total  disconnect.  This  theory  is  appealing  to
those  who  see  the  Internet  as  a vehicle for contention with state
controls.  And indeed, this theory is appealing and has much  to
recommend  it.  But  (again)  in  the  extreme,  it
suffers from two problems. First, we have seen states, faced with  the
only  option  of  the  blunt  instrument,  use  it.  When Google
refused  to  continue  to  comply  with  the  law  of  the land  in
China,  China  threatened  to  revoke  their  license  to operate
there,  leaving  Chinese  users  with  the  even
- more regulated  alternative  of  Baidu.  Opinions  may  differ,  but
some  argue  that  a  little  Google  would  be  better for the Chinese
people than none.
Similarly,  Burma  took  the  step  of disconnecting all international
telecommunications links during    the    2007    “Saffron
Revolution”,    and    several
countries  have  blocked  Facebook  and  YouTube.  Are  those countries
and  their  citizens  better  off  with  that  outcome than    with
half    a    loaf?    Second,    when    law    trumps technology,
baking the “blunt instrument” outcome into the architecture   may
raise   large   complexities   for   actors required to comply with
regulations. When France required that  Yahoo  block  auctions  of  Nazi
 memorabilia  to  its citizens,  Yahoo  had  to  organize  a  table
that  identified (imperfectly)  IP  addresses  of  French  users.  Would
 it  have been better or worse if the Internet made it easy to tell from
what jurisdiction a connection came?"

See here:
http://conferences.sigcomm.org/co-next/2010/Workshops/REARCH/ReArch_papers/10-Brown.pdf

What they mean in this case is that if the IETF were to bake the UDHR
into its protocols, countries who do not agree with that might
completely withdraw from the standard setting process. I agree that
tools of enforcement is unclear so I changed that sentence to better
reflect that sentiment.

> 4: "This document sets out some preliminary steps and
> considerations for engineers to take into account when
> developing standards and protocols." I think that's a good and
> fair statement of where this document is at. But don't you
> elsewhere go further?

Not in this document methinks.

>
> section 5: It'd be great if you could add links or references
> to the source materials here. For example, who'd you interview?
> Are the videos avaiable? What's the list of RFCs you read and
> which were considered (most) relevant? Similarly for WG lists
> analysed etc. I'm sure you have all that stuff and making that
> available for later would be great.
>

Several people only wanted to be reviewed on the basis of anonymity,
releasing an incomplete list doesn't make a lot of sense methodologically.

There is a preliminary RFC reading list, but we let it go relatively
soon we we were able to do automated RFC analysis with this tool:
    https://github.com/nllz/rfc-analysis

The RFCs that were deemed most relevant are mentioned in the ID.

> 5.2.1.4 and 5.2.1.5: (See general point #4 above about "=") I
> don't think you actually have achieved this "the creation of a
> list of technical concepts that when combined create an
> enabling environment for human rights." It's a fine goal, but
> I'm not sure it's achievable in reality with the kind of
> precision claimed in this section.  I don't think the terms
> used in the figure in 5.2.1.5 are at all precise TBH, e.g.  the
> phrase "good enough" only occurs in this figure and nowehere
> else.
>

I hope this has been sufficiently addressed now with the fix offered above.

> 5.2.3: "These capabilities for network control and limitations
> of the freedom of expression by end hosts can be traced back to
> the IPv4 design..." I don't think you have justified this
> claim. My argument would be that there is no simlarly
> scaled/robust nework against which to compare IP and that does
> not have the feature that it allows deployments to limit
> freedom of expression. So it may be that this feature/bug is
> not IP specific but inherent in large networks. In any case,
> the claim seems too much to me. (That might be a useful topic
> for the RG to tackle, or maybe someone has already studied this
> issue?)
>

That thee is no scaled/robust network to compare against doesn't mean
that this cannot be true for the current one, right? Not sure if I
understand your point.

> 5.2.3.1: On what do you base the claim that source-routing
> could be better here? Source-routing seems to usually generate
> objections from transport folks. (You'd have to ask them for
> the history of that.) Spoofed source IP is a common mechaism
> for abuse.  While you do say these are not considered good
> practice, you don't say why (or provide a reference) so it
> looks to this reader as if you're saying that those "features"
> could have been better, but without evidence for that.  (Tor is
> lovely, but as currently defined, would not scale to the size
> of the Internet as it was quite some years ago.)
>

What we're doing here is 'know and show' the human rights impacts of a
specific protocol, that this is the only solution that exists and works
today, doesn't mean that it doesn't have a specific impact.  So it's
about documenting of impacts. I don't think we're claiming anywhere that
those features could have been better, the sentence only reads that it
_can_ be done differently, not that that solution would be better.

I've also added a reference on source routing.

> 5.2.3.2: are you referring to the protocol number here? (As
> listed at [1]) That has about 140 protocols many of which
> aren't in widespread use.  If so, then I question the claim
> that this is really the cause of DPI - I suspect that DPI
> devices mostly look deeper into the packet. That also seems to
> be indicated when you talk about transports and spdy. I think
> this section is confused about the differences between headers
> at various layers, and our history of sending cleartext.  That
> said, I could see that in future, as we encypt more Internet
> traffic, someone may find rights-invading ways to use layer 3
> headers but I'm not sure this is a significant issue today. (If
> there is evidence of this being done, I'd be interested in
> knowing about that. I guess there may be IPv6 options that are
> in use like that or have been suggested but you don't cover
> those at all that I can see.)
>
>    [1]
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
>

I removed this para for now, but am still researching it. Might offer
new text later on. Need some more thinking.

> 5.2.3.3: I don't think mobile IP could never have displaced NAT
> for IPv4.  We'd still have run out of addresses. So I'm not
> sure the point made here (that there was a "viable
> alternative") is correct at all.

With NAT deployed all over we're also running out of IP addresses, so
not sure your critique holds. Mobility could have been an alternative
for NAT, not for IPv6 (or its other alternatives).

>
> 5.2.4: "which enact ICANN's policy" Do you thnk that the ccTLDs
> would agree with that? I don't.

Altered the text to: "which function in line with ICANN's policy"

>
> 5.2.4: I think the fact that new gTLDs are hugely expensive is
> well worth a mention, as a deterrent to various freedoms.
>

You mean that it is expensive to become a registry (starting from
185.000 USD), or that gTLDs are expensive? If it's the first, we
probably need to address this discussion:
https://archive.icann.org/en/topics/new-gtlds/explanatory-memo-new-gtld-program-budget-22oct10-en.pdf
, for the latter I do not have any data that shows that gTLD overall are
more expensive.

> 5.2.4: I think you're missing some points here, maybe even an
> entire subsection. One of the ways around some of the issues
> listed is for clients to choose their resolver, e.g. so as to
> pick one that does check DNSSEC or that is not subject to the
> same regime as a default resolver. That can be blocked at the
> IP level, which is one issue. But even if I do that and use
> DPRIVE, then that creates a new threat of centralisation of
> lots of queries (e.g. at 8.8.8.8) which introduces yet another
> point at which control can be enforced or where traffic can be
> analysed. Passive DNS also has good and bad aspects. I'd say
> some or all of these points would be good to note. (But I'm not
> the right person to suggest good text sorry.)

Stephane has been so nice to provide text for this:

Users can switch to another resolver, for instance a public one such as
those operated by  Telecomix [http://dns.telecomix.org/]. The distorter
can then try to block or hijack the connection to this resolver. This
may start an arm's race, the user switching to secured connections to
this alternative resolver ({{RFC7858}}), the disruptor then trying to
find more sophisticated ways to block or hijack. In some cases, this
research to find an alternative, non-disrupting resolver, may lead to
more centralisation, many people going to a few big commercial public
resolvers.
>
> 5.2.5: The lack of a mandate for TLS was not the only reason
> why the web started out largely cleartext. There were also
> significant performance, UI, tooling and missing infrastructure
> issues, as well as the charging per certificate business model.
> Those were more important issues IMO, even though they do not
> nicely tie into the discussion of h2 and it's lack of a mandate
> for use of TLS. While I personally regret that, it was the
> result of a real and extended and open debate, which I think
> also ought be noted.
>
replaced 'caused' with 'was one of the reasons for'

> 5.2.5 and 5.2.5.x: While I'm fine with you calling the
> development of TLS MitM devices and similar "malicious," I am
> pretty sure plenty of folks might argue that. It'd be better to
> skip the pejorative language I think, but it is entirely
> correct to have the references to the attacks mounted using
> such technologies. I'd also tend to not mention specific
> companies and products in the body of the text, except where
> that is really necessary to make the point.
>

Done

> 5.2.5.1: How do you know it was Snowden's relevations that
> caused mail service providers (not ISPs!) to "follow Google's
> lead"? That may be correct, but I'm not sure there's the public
> evidence that they said that was why. (If there is, great, but
> please provide a reference, the one you do provide, [Peterson],
> is about gmail and not yahoo.) Also, Google use TLS, not SSL
> for gmail.

Done
>
> 5.2.5.1: "less democratic" - I think it's an error to say that,
> since many countries that are considered role models for
> democracy could do the same things, "some countries" and
> examples would be better. Same with "oppressive regimes" -
> there's no need to include that judgement here.  The reference
> here [RSF] wasn't accessible to me (no route to host) from a
> hotel network and eduroam. That could be nicely ironic, or a
> badly chosen reference. (But you need a reference.) The 2012
> Libya report also really needs a reference.
>
>    [RSF]
>
https://en.rsf.org/syria-syria-using-34-blue-coat-servers-23-05-2013,44664.html

Updated link, reference added and judgemental language removed.

>
> 5.2.5.2: wrt great-cannon, you might want to note that the IESG
> issued a related statement [2]. That's a bit tangential, but I
> think is relevant for this work.
>
>    [2]
> https://www.ietf.org/iesg/statement/maximizing-encrypted-access.html
>
> 5.2.5.2: "Companies like" is pejorative and the patent
> application seems irrelevant. "has been largely documented"
> calls for a reference. "Oppressive regimes" is also not needed
> here as is "little concern for bad human rights records." The
> right thing here I think is to note the documented record
> without pejoratives and to then let the reader draw their own
> conclusions.
>

Done and done

> 5.2.5.2: I don't think the text about h2 is fair. You're
> missing a) that there was a real and open debate on the topic,
> b) that some important implementations are exclusively h2/tls
> and c) that there is a spec for OS for HTTP being developed.
> Those are all as relevant as the fact that the outcome of the
> debate was to not mandate use of TLS all the time. (Which I do
> think is worth saying in this document, but needs more complete
> context.)

I am not sure what this would add to this. It is not stated that there
was no debate or that there are no exclusive h2/tls implementation. Am
happy to write something but am not completely sure what it would add to
the the analysis of the impact of this protocol on human rights.

>
> 5.2.6: I think this section is missing some things. First, the
> IETF/XSF relationship is relevant here and needs a mention. (As
> both good and bad!)

Do you have a reference / source where we can learn more about this?
Since you seem to hint at something I do not know about.

> Second, OTR is important, as is the
> community's failure to produce a better e2e standard for xmpp.

I am hesitant to do so, because then we would be analysing another
protocol, right?

> And lastly, I think the tendency of IM deployments to not
> deploy interoperable standarsd is missing, which also has good
> and bad aspects (good: they can do telegram etc, bad: no
> interop).  I'd suggest asking an XMPP expert to review/suggest
> text.  (Happy to help find you one if needed.)
>

Do we really want to get into the Facebook Messenger, Ello, Telegram,
Signal, Axolotl discussion with this? That would be a serious extension
to the discussion... in the security direction. I would like to hear
what other people think about this, because I think this document
already covers a lot of ground. On the other hand:

https://www.theguardian.com/technology/2016/aug/03/turkey-coup-gulen-movement-bylock-messaging-ap

Review by experts is always welcome. I asked Peter Saint Andre a while
ago but I did not hear back. Suggestions and reviewers are always very
welcome.

> 5.2.6: "The protocol also has facets that may stifle speech as
> users self-censor for fear of surveillance, or find themselves
> unable to express themselves freely." That's not an XMPP
> specific point - the same applies to email and the web and to
> any other protocol that supports interpersonal messaging or
> access to sensitive information. I think you ought up-level
> this point to a more generic section that calls out issues with
> multiple protocols. (Not sure where exactly, but having it here
> only isn't great.)

Agreed, have added this point to the Privacy Explanation in the
questionnaire.
>
> 5.2.7: Is this section about P2P in general (I'd consider P2P a
> design pattern) or about PPSPP or about BT? Each of those
> choices seems wrong. If the first, then that's not the same as
> other 5.2.x sections and doesn't mention other P2P protocols
> (e.g. RELOAD maybe). If the second, is the deployment of that
> sufficient to justify the text? If the 3rd - that's not an IETF
> protocol. So I'm not sure what to make of this.

It's the first. The reason for adding this case category to the research
was that peer-to-peer got mentioned a lot in the interviews and in
discussions on this, so we thought it would be useful for the document
to discuss it here.
>
> 5.2.7: Is it still true to say that P2P is an "increasingly
> becoming a popular architecture"? I thought usage stats were
> showing the opposite nowadays? The examples given are odd: as
> BTC doesn't do file sharing/interpersonal messaging, skype is
> no longer really P2P iiuc, and I don't know if spotify really
> is or not. Surely BT is the canonical real example?
>

Removed 'is becoming and added:

    "While its most common application has traditionally been
file-sharing (and other types of content delivery systems), P2P is a
popular architecture for networks and applications that require (or
encourage) decentralization. A prime example is Bitcoin (and similar
cryptocurrencies), as well as Bitcoin and proprietary multimedia
applications."

> 5.2.7: "mostly delegated" - I'm not sure this is correct.  I
> could argue that RELOAD is a counter example.

That's why it says 'mostly', right?

> I could further
> argue that the lack of deployment of RELOAD (iiuc) may be
> evidence that your implied argument that it'd be better for an
> organisation like the IETF to try produce complete specs in
> this space might be unwise in that it's less likely to result
> in deployment.

I think the 'conclusion' para is pretty clear on this:

These platforms are not perfect, and more research needs to be done.
If adopted at large, well-designed and resistant P2P networks might
represent a critical component of a future secure and distributed
Internet, enabling freedom of speech and freedom of information at scale.

I think that is not an implied argument for making everything P2P.

>
> 5.2.7.3: I think ledbat has some protocol features that would
> allow deployments (if they are nice) to reduce the scope for
> tracking. That's RFC 6817 but I'd have to reread it to check if
> there's something useful there, also not sure about ledbat
> deployment.
>

You mean this? https://tools.ietf.org/html/rfc6817#section-5.1 Doesn't
seem very conclusive.

> 5.2.7.4: Sybil attacks in this context (e.g. astroturfing) seem
> to be relevant to more than p2p protocols. In fact wouldn't
> they be more common on web based systems, at least as exploited
> by/for governments and commercial entities?
>

Added this suggestion

> 5.2.8: There are many kinds of VPN - I think it'd be better to
> rename this section to something like "personal VPNs" or
> similar, as you don't get into e.g. corporate VPNs.

I think the first para does cover the difference, and I don't think
there is anything in the rest of the analysis that is not true for other
kinds of VPNs?

>
> 5.2.8.1: "local illegitimate wiretapping" - that's another
> pejorative term for some, "monitoring" would be just as clear.
> (Again, not because what you say is wrong, but because there's
> no point in antagonising those who read this.)
>
updated

> 5.2.8.1: "are way less analyzed and understood" I think I
> recall some papers on these kinds of VPN that found some issues
> - be good to reference such work if possible, esp if there's a
> survey.

I've been searching a bit and did not find anything really good. Things
like:
    http://dx.doi.org/10.1016/S1742-6847(06)70438-4
    http://www.ijcse.com/docs/INDJCSE14-05-04-101.pdf

Theses ones are the best I could find:

https://www.insinuator.net/2013/08/vulnerabilities-attack-vectors-of-vpns-pt-1/#respond

http://ieeexplore.ieee.org.proxy.uba.uva.nl:2048/stamp/stamp.jsp?arnumber=7314859
So I referenced them in the text.

>
> 5.2.8.3: " VPN providers should at least be transparent on what
> information do they store and for how long is being kept" I
> fully agree with this, but what's it telling the IETF
> readership? Perhaps that RFCs ought identity potentially
> sensitive logged data or for how long that needs to be retained
> for technical reasons? That migth not belong here anyway but
> could be relevant somewhere in the document.
>

Changed 'shoud' into 'would' and added your suggestion to the privacy
question in the questionnaire.

> 5.2.9: This could be shorter and may better as a part of
> section 5.2.5 - why is this one status code so important?

reduced the text substantially.
>
> 5.2.10: I'm really not sure this (all) belongs here.  The
> middlebox debate is old and won't be resolved here, so I'm
> don't think it's worthwhile regurgitating the arguments in such
> detail. And I think you already said what you need to say when
> discussing NATs. I'd say deleting this section is maybe right.

deleted it.
>
> 5.2.10: (If you keep it) "IETF's role to prevent such
> censorship" again, the IETF is not the Internet police and does
> not "prevent" things like that. If you refer to the SPUD BoF,
> you should include references to the minutes etc.
>

deleted it.

> 5.2.10: "Middleboxes are becoming a proxy for the debate on the
> extent to which commercial interests are a valid reason to
> undermine the end- to-end principle." That seems like an
> opinion, and one I'd be surprised had consensus. Do you need to
> say that?

deleted it.

>
> 5.2.11: "Some people may say that DDoS attacks are the only
> mean to be heard, in the current Internet." Some people say
> that the moon landings were faked. Vague reportage like that is
> useless. I'd say this entire section needs to be redone with a
> strong statement that there is no valid use-case for DDos, and
> that DDoS is not a valid form of protest. I think such a
> statement is one that would have RG and indeed IETF consensus.
> I'm very sure that no concept of DDoS as a valid form of
> protest would garner consensus in either the RG or the IETF.

Done
>
> 5.2.11: "seem to suggest that the IETF should try to ensure
> that their protocols cannot be used for DDoS attacks" That's
> very understated and maybe even misleading. I would say that
> the IETF has long-standing consensus that DDoS is an attack
> that protocols should mitigate to the extent they can and that
> DDoS vectors in protocols are basically bugs.  RFC3552 (section
> 4.6) from 2003 covers this and says that standards MUST
> describe DoS issues.
>

Text added:

    All of these issues seem to suggest that the IETF should try to
ensure that their protocols cannot be used for DDoS attacks, which in
consistent with the long-standing IETF consensus that DDoS is an attack
that protocols should mitigate them to the extent they can {{RFC3552}}.

> 5.2.11: The linkage between private sector control of networks
> and DDoS is IMO entirely unconvincing. NRENs are generally
> private sector and have major issues with DDoS. (I'm sitting in
> a talk on that topic right now.) It is not at all clear that
> anyone who'd claim that they are using a DDoS attack to protest
> would actually be protesting about a network operator - it is
> much more likely they are protesting about some content owner,
> who may be public  or private sector.
>

Removed

> 5.2.11: I don't think we need or want the argument based on PM
> here at all. The argument about motivations for PM in RFC7258
> depends on there being some justifiable reasons for monitoring.
> (Otherwise we would not need to even point out that motivations
> don't matter.) There are no such close-to-good arguments at all
> for DDoS, so drawing that analogy is misleading.
>

Removed

> 5.2.11: If the RG feel there is a need to discuss a possibility
> for fully opted-in people to collectively protest, (I do not)
> then you should invent a new term for that and clearly say that
> even though such protest might appear to the network as beng
> the same as a DDoS (and hence be treated as an attack), that is
> not the same as a DDoS, where 100% of real cases involve
> compromised hosts or hosts being used as reflectors without
> permission. If the RG feel there is a need to discuss forms of
> protest on the Internet, then I think an entirely different
> section is needed, probably with a different structure.
>

Removed

> 5.3.1: I'm not sure the "HR threats" model is the right thing
> here. The same was true of rfc6973 as well, as you say, but in
> this case, I'm not sure you really even need the concept. 5.3.2
> just says stuff like "did you think about <foo>" so I don't see
> a need to say that "<foo> is a threat." I don't think you lose
> anything by losing that concept entirely. There is also a
> danger in including that risk analysis model here in that doing
> so might cause later disussion to be somewhat blinkered.

Not sure if I share your view. There are concrete threats, that we can
people to be cognizant of by thinking and documenting issues that could
arise, through the use of the questionnaire. I don't see how the use of
'threat' here is problematic.
>
> 5.3.1: "This is by no means an attempt to cherry picks rights,
> if other rights seem relevant, please contact the authors
> and/or the hrpc mailinglist." I'd delete that, it's not that
> appropriate for an RFC (it was for an I-D). But if you do want
> to say something about a contact point, the RG list would be
> better. (The phrasing "cherry pick" is also a bit odd.)

Rewrote: This is by no means an attempt to exclude specific rights or
proritize some rights over others, if other rights seem relevant, please
contact the research group mailinglist.

>
> 5.3.2: The title here is a bit inaccurate and misleading.
> You're presenting guidelines for protocol designers, and not
> for "HR considerations."
>

Seems in line with the dictionary definition here:

Simple Definition of consideration
: careful thought : the act of thinking carefully about something you
will make a decision about
: a desire to avoid doing something that will make another person sad,
upset, angry, etc.
: something that you think about when you make a choice or decision

from: http://www.merriam-webster.com/dictionary/consideration

> 5.3.2: I don't think that many IETFers follow or read RFC4101.
> (RFC4101 is a useful, good thing, but one that's not much used
> iiuc.)
>
>
It seem quite useful though, I do not necessarily see a reason to remove
it.

> 5.3.2.1.2: We're updating RFC3552 now, and the update will
> include some guidance on privacy considerations. I'm not sure
> if it'd be better to reference that draft now or not though, as
> it's early days. Probably best to refer to BCP72 though, as
> that'll remain the right reference when the 3552bis work is
> done.

Replaced everymention of RFC3552 with BCP72

>
> 5.3.2.1.2: "Could your protocol counter traffic analysis, or
> data minimization?" oops - I don't think you want to counter
> data minimisation. Better to split that into two questions
> probably.

Done.
>
> 5.3.2.1.3: This set of questions need work. All protocols "look
> at the packet content" or else do nothing at all. I think you
> want to ask people to think about which fields in the packet
> they need to access and to try to minimize those, and if
> possible, discourage others from looking at the rest (e.g. by
> enabling encryption of those).  I also have no clue what " Is
> the protocol transparent about its decisions?" means. And the
> last question is also pretty meaningless when looked at in
> isolation. (I think I already commented on the agnosticism
> phrase as used here before. The same issues apply to the
> explanatory text here.)

I've rewrote the section:

If your protocol impacts packet handling, does it look at the packet
payload? Does it look at Is it making decisions based on the payload of
the packet? Does your protocol prioritize certain content or services
over others in the routing process ? Is the protocol transparent about
the priotization that is made (if any)?

>
> 5.3.2.1.5: "readable by humans" is not the right criterion
> here. What you need to say is that "have to be understood by
> humans." For example, DNS names are mostly readable but IDNs
> are not, depending on which form one uses.

Accepted.

> For some protocols
> it is entirely fine still to use ascii for human-readable
> labels, if those are only seen by developers or more capable
> admins.

I would push back on this in relation to the presentation of and points
made by Ramsey Nasser that I already referenced above.

>
> 5.3.2.1.6: Re-using existing identifiers (e.g. MAC addresses)
> is the more common way that (re-)identification is enabled in
> protocols. You should point that out. I think the "make ...
> transparent" point is worth splitting from the identifier issue
> too - identifiers are very common, but making filtering
> apparent is much less so, and will be missed if you bundle
> these two things together. The last two questions aren't really
> useful though and are more explanatory text then real new
> questions.
>
Changed text, but I think last two questions are still useful for context.

> 5.3.2.1.7: These are not useful, as phrased for IETFers.  The
> only useful part here is the 2nd last question (use other
> things that are proprietary), the rest are not as they are
> already handled in IETF processes, and we do not want yet more
> bureaucracy. The explanatory material is way too long and also
> not useful for the IETF audience. The example given is an
> interesting thing, but far from a typical protocol, so
> therefore is not a good example.

Not sure about this. That this is picked up in other IETF processes
doesn't mean it shouldn't be discussed here from the human rights angle.
Else also wouldn't need to discuss security, etc. Plus I think there is
ample reference to the existing IETF procedures hear to ensure that
there is no duplication of efforts.
>
> 5.3.2.1.8: This entire section is useless for IETFers, except
> the last question about extensibility. The explanatory text and
> example however don't address that and are also not useful.
>

Pretty strong statement with not too much argumentation, could you
elaborate pls?

> 5.3.2.1.9: The question was asked already. Anonymity is not a
> useful goal in almost all IETF protocols, and if it were, it'd
> be a first order requirement (e.g. if we wrote an RFC for Tor)
> and would not be missed. Delete this section entirely.
>

I don't agree, especially since anonymity is such a concept that is both
legally and technically understood, but hard to achieve. And as you said
previously, the combination of protocols make anonymity harder, which is
actually a case to raise awareness about anonymity in all protocols.

> 5.3.2.1.10: The emphasis here is wrong. You should be asking
> about whether the protocol generates or processes anything that
> can be, or be tightly correlated with, PII. Many protocols have
> identifiers that are perfectly safe, until the host running the
> protocol is something that a person carries with them. The
> section needs a rewrite to take that approach.

Suggested text added.

>
> 5.3.2.1.11: Mixing accessibility and statefulness is wrong.
> Both are fine questions, but should not be bundled.

I think it helps if you look in the glossary for the different
definitions of accessibility, that might clarify things, or in the
explanation.

> The
> example is bad - HTML5 is the current spec and is not that RFC.

Reference changed.

>
> 5.3.2.1.12: I think this is arguably duplicative and the issue
> will (or should) be caught via other IETF processes apart from
> HR considerations. I'd delete this, though it's mostly harmless
> here.
>

I'm hesitant here (again) to remove this because this gets a different
meaning from the human rights perspective imho.

> 5.3.2.1.13: Again, this bundles things in a counterproductive
> manner. Split the topology/architecture points from the
> discriminaton/implication ones. (Even if you think those relate
> in terms of HR, that does not mean that they ought be bundled
> together in a questionnaire.)
>

Why not? I think the explanation and example tie it together nicely.

> 5.3.2.1.14: I don't think this belongs in the questionnaire
> either. It's covered alredy in other IETF processes, when most
> relevant, so is not useful to ask about here.
>

I'm hesitant here (again) to remove this because this gets a different
meaning from the human rights perspective imho.

> 5.3.2.1.15: This needs to be rewritten, there are 13 questions
> in the text which is entirely pointless. I would not bother to
> try answer those.

Hmmmmm. This is not a MUST, but it helps people structure their
thinking. Granularity can help with that, especially in an issue such
problematic and little understood such as Informed Consent, etc.

> You should just ask how confidentiality is
> supported and between what endpoints and how keying is done.
> (Or something like that, I didn't try the full re-write that is
> needed.) The re-write should also bundle this with most of the
> next two sections. (See below.)
>
> 5.3.2.1.15: The cryptographic parts of this should be merged
> into a rewritten 5.3.2.1.14. If there are non-crypto bits of
> this then those need better explanatory text as it'd not be
> relevant for most protocols. (I mean things like database
> consistency.) I'm not sure if anything would remain when this
> and the previous section were re-written.)

Having a hard time understanding this, because it are inherently
different issue from a rights perspective. Merging them would not be
helpful imho, but am happy to be convinced.

>
> 5.3.2.1.17: As per 5.3.2.1.16.

I assume you think these two should be merged? I could be convinced of
that, but would that make it easier to understand? Or just for the sake
of making it shorter? I do not think this Research Draft necessarily
needs to be short because it outlines the full research. If we take this
work further we can have a closer look at usability and streamlining it
with other relevant reviews that are ongoing in the IETF, IESG, etc.

>
> 5.3.2.1.18: This is entirely duplicative and should be deleted.

Agreed, removed.
>
> 5.3.2.1.19: I've no clue if this'd be useful to ask. Only
> testing would tell. (It might be, but I'm really not sure.)
>
> Nits/editorial...
>
> lots of places: there are too many over-long sentences that
> make this hard to read and less clear. I'd really recommend
> getting rid of as many of those as you can. The first non-quote
> paragraph of the intro is a good example.

During RG last call we'll do a full editorial review.
>
> intro, "the core of the Internet, its architectural design
> is..." Using "core" is a bad term there, mostly we mean
> something quite different when we talk about the Internet's
> core or similar.  (And that's another assumption that there's
> one true architecture.)
>

Hmmm, not sure. Compare:
http://www.wrr.nl/fileadmin/en/publicaties/PDF-Rapporten/The_public_core_of_the_internet_Web.pdf

> intro, "properly defined, described and protected as such" - I
> don't think "defined" is needed there, and it might not be
> correct either.
>

Why not? I think defining is always the first step to make something
tangible. Also inline with
https://business-humanrights.org/sites/default/files/media/documents/ruggie/ruggie-guiding-principles-21-mar-2011.pdf

> intro, "New protocols, particularly those that upgrade the core
> infrastructure of the Net, should be designed to continue to
> enable fundamental human rights." I'd drop the "core
> infrastructure" bit there, it's a distraction and liable to
> generate argument about what is or is not core, e.g. BGP is
> clearly core but is not otherwise mentioned in this document,
> and maybe correctly.
>

We have thought of BGP as one of the cases actually, and it is one that
I would love to to.

I do think it makes sense to put in some prioritization of human rights
impacts assessments in here though. I don't think core or non-core needs
to be binary as well. Some things are simply bound to be used more and
thus can have a bigger potential impact.

> intro, "The authors believe that the issues that have been
> raised by the reviewers have been addressed." Sorry to be
> raising more:-)

That should have been taken care of now ;)

>
> section 2: I think some better formatting is needed here to
> distinguish the terms defined from the text, which in some
> cases is fairly long. Just add bullets or quoting or something.

But this is the standard glossary approach, right? Will take this up (in
due time) with the RFC editor who probably has some good ideas about this.

>
> 2: "In the discussion of human rights and Internet architecture
> concepts developed in computer science, networking, law,
> policy-making and advocacy are coming together" Sorry, what is
> coming together in what discussion(s)? Too many commas there to
> be sure I think. (BTW, "architecture concepts" may well be an
> ok use of that word:-)
>

Concepts developed in different fields come together.

> 2, "censorship resistance" does not "prevent" censorship, I'd
> say mitigate is better than prevent.

Accepted

>
> 2, "confidentiality" - why not refer to 4949 there?
>

Done

> 2, "debugging" - the term debug is not used in the draft, why
> do you need the definition?

Tossed.

>
> 2, "decentralized" - why is "opportunity for" needed in this
> definition? I don't get that.

Tossed.
>
> 2, "technical this means..." needs fixing.
>

Fixed.

> 2, "Heterogenity" typo

Fixed

>
> 2, "autonomous organizations" do you mean ASes? If so, say so.
> If not, better to avoid the word autonomous here.
>

Changed autonomous with independent.

> 2, "integrity" - why not refer to 4949?

Added.

>
> 2, "Inter-operable" is normally not hyphenated in the IETF
>

Fixed

> 2, i18n - funny line breaks there make that hard to read

Fixed

>
> 2, l10n - you don't actually use that abbreviation so why
> define it?
>

Because many people use it, so it might provide some clarity. Don't
think it hurts.

> 2, "The combination of the end-to-end principle,
> interoperability, resilience, reliability and robustness are
> the enableing factors that result in on the Internet.  " That
> (non-)sentence needs fixing. I don't even know what you want to
> say tbh.
>

Fixed: The combination of the end-to-end principle, interoperability,
resilience, reliability and robustness are the enableing factors that
result in connectivity to and on the Internet.

> section 3: I think this short section is missing text to the
> effect that you think the answer to question 2 is yes.

But it would be weird to answer that question here, right? That is what
we're doing in the rest of the document.

>
> section 4: you say "five clear positions" but they are not
> clearly delineated in the document. I'd suggest using some
> headings or some other way to make these more distinct in the
> document.

Hmm, it's one position per para, and in it even mentioned which number
they are.

>
> 4: "embedded into the Internet's architecture" (top of p13) has
> another claim that there's one true Internet architecture.  You
> could change this one to be the set of protocols defined by the
> IETF or something similar.

The conception of Internet architecture of the authors is broader than that.

>
> 4: " As it stems from the issues as they arise in the field of
> technical engineering." That's not a sentence.

I also don't think it adds much, so it's removed.

>
> 5: "step taken by the research group" that's ambiguous - I
> think you mean the set of authors and their research groups at
> home and not the HRPC, which I don't think collectively read
> all the RFCs you mean. (I think it's fine to say that the
> authors were the one who did the work, if that's what you
> mean.)

I made it: authors and contributors

>
> 5.1: This section duplicates the intro to section 5. Is there a
> new point being made?

Yeah - methodology and datasources are inherently different parts that
both need to be justified afaik. Mixing them up would just be messy.

>
> 5.2: "(detailed under "2.vocabulary used")" do you mean section
> 2 there? Saying "Section 2" with the right xml2rfc incantation
> will cause the tools rendering to make that a link, which'd be
> nice.

I think that should also be working now.

>
> 5.2.1.1: "was assembly" typo.

Fixed.

>
> 5.2.1.5: figures are better numbered and with captions.

Done

>
> 5.2.2.1: I guess there's a heading level bug here in the
> document sounce?

Fixed.

>
> 5.2.3.1: "ability for those hosts to assemble or to
> consensually express themselves" huh? When/how do hosts
> assemble or do things consensually? Confusing people and hosts
> like that is odd.

Fixed.

>
> 5.2.3.2: Why refer to spdy and not h2? And is that even a good
> reference? The 4906 reference also puzzled me. (Even more:-)

That was removed, but we might introduce it in another for again later on.

>
> 5.2.5: Why "because of it's simple design"? I'd have thought it
> was more complicated than that and that a combination of HTTP,
> HTML, open-source browsers and web servers and cool content was
> involved.

Rewrote into: Its simple design strongly contributed to the fact that
HTTP......

>
> 5.2.5: TLS and SSL could do with references.

Added

>
> 5.2.5: Gen-ART? Huh? That's wrong. Gen-ART are fine people but
> they don't do what you say they do any more than any other set
> of IETFers. Are you confusing them with the IAB statement on
> encryption perhaps? Otherwise that is quite the puzzle for
> me:-)

Removed
>
> 5.2.5.1: What does "of the first" mean? "From the start"?
>

Dutchism - Fixed by changeing it into:

E-mail providers such as riseup.net were the first ones to enable SSL by
default.

> 5.2.5.1: "have been corrected in TLS1.3" is in the wrong tense
> - "are being corrected" is correct.

Fixed

>
> 5.2.5.1: TEMPORA, XKEYSCORE etc need references. Those can get
> hard to find later, at least good references can be hard to
> find.

Added.

>
> 5.2.6.1: I assume the URLs [1] and [2] don't need to be there
> and are xml2rfc artefacts to be fixed. Also, you should use
> example.com and example.net as per the usual way of handling
> examples in RFCs.

Will take this up with the RFC editor in due time.

>
> 5.2.7: "often seen" - by whom? I'm not sure that IETFers would
> share that opinion, so better to say who you do mean. "remains
> critical" is also overstated.

"regularly described" and "remains imporant"
>
> 5.2.7.1: "directed directly" typo

changed into: aimed directly

>
> 5.2.7.2: "throtteling" typo

Fixed

>
> 5.2.7.5: Why does only this section have a conclusions
> subsction? I'd say be consistent.

Heading tossed.

>
> 5.2.8.1: you could lose the heading here (consistency again:-)
>

Heading tossed.

> 5.2.8.1: some VPNs (but not the ones you care about) are not
> point-to-point.

Fixed with:
    The Virtual Private Networks (VPN) that are being discussed here are
point-to-point connections that enables two computers to communicate
over an encrypted tunnel.

>
> 5.2.8.1: "There are multiple implementations and protocols used
> in provisioning a VPN" do you really mean provisioning a VPN
> there? That'd mean something else for some IETFers. I think you
> mean setting up a personal VPN for a single user but not quite
> sure.

Fixed with: "There are multiple implementations and protocols used in
the deployment of VPNs,"

>
> 5.2.8.5: The URL for [PET2015VPN] didn't work for me. I found
> the paper elsewhere though.
>

Works fine for me.

> 5.2.8.7: This bit seems fairly repetitive, other than the
> timing/correlation issues. You could maybe say that more
> briefly.

Tossed the first two sentences.
>
> 5.2.10: The URL for [Walfish] doesn't point at the named paper
> - what's up there?

Fixed - but then we removed the whole section :)

>
> 5.2.11 (and elsewhere): "Many individuals, not excluding IETF
> engineers, have argued..." I hate constructs like that that
> assert that somebody somewhere (unnamed) thinks/says something.
> I don't see why any such assertions (of rumour basically) ought
> be in the RFC series. There are other examples of this
> construct in the draft.
>

It has been argued on the list. Would you prefer a link to the list
email? I think this a quite broadly shared opinion, so I don't really
think it's problematic.

> 5.2.11: Not all DoS attacks flood with traffic. Some might
> consume CPU cycles, in future some will consume limited power,
> and could be used in a DDoS. I don't think it's useful here
> (for the IETF audience) to define 3 types of DDoS attack.
>
Fixed:

    Technically DDoS attacks are when one or multiple host overload the
bandwidth or resources of another host by flooding it with traffic or
making resource intensive requests,

Re: Definition: why not?

> 5.3: "Having established how..." I don't think you established
> the "how." It'd be fair to do s/how/that/ though. (Twice.) That
> sentence is also overlong. Also "... by detailing how..." is
> similarly not correct.
>
In the previous steps we have established that human rights relate to
standards and protocols and offered a common vocabulary of technical
concepts that impact human rights and how these technical concept can be
combined to ensure that the Internet remains an enabling environment for
human rights. With this the contours of a model for developing human
rights protocol considerations has taken shape. This subsection provides
the last step by detailing how specific technical concepts identified
above relate to human rights, and what questions engineers should ask
themselves when developing or improving protocols. In short, it presents
a set of human rights protocol considerations.

> 5.3.1: 1st para is repetitive. Delete it.
>

I feel like some concrete cases here bring the focus back to the
questionnaire.

> 5.3.1: The term "ICTs" isn't common in the IETF community. I'd
> say rephrase stuff to not use that.

But it is used in the slides of Bless and Orwat, that's why it's there.

>
> 5.3.2.x.y: Having such deep levels of TOC makes life harder for
> readers and those commenting and later using this. Flatten it
> tall out. Or, do you even need the 5.3.2.x.y headings at all?
> (Some of the section titles don't map that well to the
> content.)

What doesn't map out? I think the numbers have been extremely handy in
reviewing. If people share this opinion I can remove them at the end of
Research Group Last Call
>
> 5.3.2.1.1: s/e2e principle/e2e argument/ again:-)
>

We cut the discussion up in the doc, but here it makes sense I'd say,
because it can concretely impact human rights.

> 5.3.2.1.1: the communication content would be concealed, not
> the act of communication

Fixed.

>
> 5.3.2.x.y: It'd be a very good idea to add an appendix that
> lists the questionnaire questions only (with those being
> numbered). That way, people who want to do this analysis can
> just use that part (at least the 2nd time).  If doing that,
> please ensure each question also has an unique number/label in
> the body of the document too, so that folks can find/correlate
> things.

I would prefer doing this in another document once this one is done.

>
> 5.3.2.1.4: The last para of explanatory material should not
> re-define COMSEC etc. Just point people at RFC3552/BCP72.  (But
> as BCP72.) The global adversary is also not purely passive, I'd
> lose that phrase.

Done.

>
> 5.3.2.1.5: "many protocols" is not usefully true I think.

Maybe you should take up that problem with
https://tools.ietf.org/html/rfc2277#section-2 ;)
> 10.2: delete this.

Done!

Thanks again!

Corinne & Niels

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 10 Oct 2016 10:27:11 +0300

Hi all

I have started to edit via git but perhaps that's no longer helpful at
this stage? I was focussed on the abstract and introductions as those,
at a minimum, should have strong logical arguments that draw the reader
into the longer paper.

I also fully agree with Stephen about the DDoS section and if nothing
else would be happy to proceed with working on this.

However, fully aware that work needs to progress and without having been
able to comment up to now I'd like feedback on where in the text my
edits could be most useful.

-Mallory

On 09/10/16 07:31 PM, Niels ten Oever wrote:
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc

-- 
Mallory Knodel
Association for Progressive Communications :: apc.org <https://apc.org>
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 10 Oct 2016 11:24:29 +0200

Hi Mallory,

Reviews and proposed edits (in the form of suggestions here on the list
and/or as pull request), are very welcome!

If you want to focus on the abstract and the introduction that would be
great, but of course feel free to look at other sections as well.

The latest version can always be found here:

https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md

Which is currently the same as:

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                   678B 08B5 A0F2 636D 68E9

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 10 Oct 2016 13:17:51 +0300

Great, Niels, I'll continue to send my edits via pull requests. At the
moment, I'm working on a fork via the apcorg Github user.

-Mallory

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 10 Oct 2016 12:19:49 +0200

Excellent, but just to make sure everything is going well: I haven't
received any pull request yet. Is that correct?

Cheers,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 10 Oct 2016 13:57:35 +0300

Right.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Oct 2016 14:17:14 +0100

Hi Niels,

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

Great thanks. I'll respond only to the more general points in
this mail. I'll send a response to the rest later.

> Up to now we have been able to reach consensus on all points, so let's

Well, the RG has yet to produce any RFCs so I'm not clear
that there's a bar we're lowering or raising. In any case
this was just a suggestion for Avri to consider so we need
say no more.

> would be great to come up with next steps for 5.3.2, such as bringing it

Sorry, that's non-responsive to the main point: this is too
long and the bit that's important for the claimed audience
(IETFers) is buried at the end. I still suggest making that
structural change. Why not?

> such a definition clarify our use of the word architecture sufficiently?

No, I think that's worse tbh, as will any attempt to define "the
Internet architecture" most likely. Others may disagree but I think
by far the best thing here is to remove as many uses of the term as
possible and to carefully say exactly what's meant in any remaining
cases (and I bet you'll find remaining cases mean different things).

> work of Prof. Denardis and Prof. Bowker on architecture.

Sorry, "pushing boundaries" is just fine, but one is not doing that
by using ill-defined terms in ill-defined ways. I also don't think
hrpc is a good venue for trying to define this particular term, nor
do I think such an activity is interesting or fruitful. Much better
to avoid use of the ill-defined term where it's not needed, which
is almost everywhere IMO.

> The easy answer, which will probably will not be enough for you,

Correct:-)

> would

No, the security model of TLS does not include anonymity. The security
model of Tor does. It's important to be precise like that I think in
this document. These uses of "=" or "===>" are nowhere near precise IMO.

> and anonymity play a role, in others anonymity may be less important.

It can be argued yes. That argument is wrong where it comes to
anonymity which is a very very hard goal to even approach.

> authenticity is what makes up security on the Internet.

I think that is still plain wrong in multiple ways, but certainly
wrt anonymity.

> I also changed the '=' in to an '⇒'

Not using "=" is a minor editorial improvement.

> for', so I replaced the '=' with '⇒' and added an explanation.

TBH, I think those diagrams have outlived their usefulness and
could just be deleted or moved to an appendix only about the
method used in this work that does not claim that these relations
are well defined. (See also my point (2) above about structure.)

> completely different role from RFC3552, even though the conclusions are

That is non-responsive to the main point here. The scope of
the DDoS discussion is still wrong. Can you respond to the
main point?

> the outcomes at the session in Berlin and were also posted to the list.

Can you send links to those please? I don't recall those as having
used the questions as listed but I may be mis-remembering. I still
find some of the questions non-useful for the intended audience
but of course I may be wrong or an outlier there.

> aims to ultimately contribute to.

I like that text, thanks. I'd suggest adding a bit of text to
cover what I think might be a misinterpretation that could be
common for the more literal-minded typical IETFer such as
myself:-) Something like:

"The fact that rights can always be in conflict with one another
means that all human rights are contingent and none are absolute.
So, for example, if one posited a "right to encrypt" as a human
right that inherently means accepting that there are times when
that "right" would lose out in balancing of conflicting rights.
That means that there are technical concepts (e.g. arithmetic,
the ability to write code), the free exercise of which may be
better protected if they are not specifically claimed as human
rights."

(As an aside, it's interesting that you are sensitive here to
the difficultly of establishing consensus on this topic, whereas
I am not. And then we reverse roles when it comes to "Internet
architecture." Not that surprising I guess:-)

>> Specific comments (without reference to importance:-)

Will get back to these later, when I get time.

Cheers,
S.

---

From: avri doria <[email-masked]>
Date: Sat, 15 Oct 2016 23:09:33 +0200

On 15-Oct-16 15:17, Stephen Farrell wrote:
>  Clearly,

Personally, given the importance I find in this bit of work, I think the
greater value is in finding rough consensus, not in getting something
out quickly.  I think there are lots of ways to get research published,
and the value of an IRTF RFC is partly in the rough consensus it involves.

The question, though may involve finding out where the rough lies.  I
think the work needs wider exposure and it is possible that a RGLC may a
good way to determine that with a wider audience.  One of the things I
have noticed with my own work in RGs in the past, is that sometimes it
takes more than 1 RGLC to get to the rough consensus point, so assuming
that enough people think that a RGLC is warranted, it may be worth
calling one.

Still looking for more opinions, more feedback and more discussion on
the points Stephen is making.

avri

avri

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 18 Oct 2016 06:48:33 -0400

+1 to starting RGLC soon

On Saturday, October 15, 2016, avri doria <[email-masked]> wrote:

> [email-masked] <javascript:;>

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

Tech Prom, CDT's Annual Dinner, is April 20, 2017!
https://cdt.org/annual-dinner

---

From: Corinne Cath <[email-masked]>
Date: Tue, 18 Oct 2016 16:05:39 +0100

+1 to Joe's +1

-- 
Corinne J.N. Cath
Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: [email-masked] & [email-masked]
Twitter: @C_Cath

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 18 Oct 2016 17:57:27 +0200

Hi Stephen,

Reply inline:

> structural change. Why not?

Because the authors intend to produce a seperate document geared
completely at providing considerations.

> cases (and I bet you'll find remaining cases mean different things).

Why is it worse?

> is almost everywhere IMO.

Well, we're providing references to infrastructure scholars, so am not
so sure about ill-defined. Could you be a bit more precise in your
objection?

> this document. These uses of "=" or "===>" are nowhere near precise IMO.

Because a function arrow doesn't seem in place here, or...?

> I think that is still plain wrong in multiple ways, but certainly

Why? Because anonymity is never part of any definition or concept of
security? That doesn't make sense to me.
> Not using "=" is a minor editorial improvement.

OK

> are well defined. (See also my point (2) above about structure.)

I think they have a clear role in the methodology as described, and
therefore fit in this research document.

> the DDoS discussion is still wrong. Can you respond to the

I thought I responded to your main point, could you else rephrase it? It
also rewrote it a bit, maybe that helps:

DDoS attacks can thus stifle freedom of expression, complicate the
ability of independent media and human rights organizations to exercise
their right to (online) freedom of association, while facilitating the
ability of governments to censor dissent.  When it comes to comparing
DDoS attacks to protests in offline life, it is important to remember
that only a limited number of DDoS attacks involved solely willing
participants. In most cases, the clients are hacked computers of
unrelated parties that have not consented to being part of a DDoS (for
exceptions see Operation Abibil {{Abibil}} or the Iranian Green Movement
DDoS {{GreenMovement}}). In addition, DDoS attacks are increasingly used
as an extortion tactic.

All of these issues seem to suggest that the IETF should try to ensure
that their protocols cannot be used for DDoS attacks, which is
consistent with the long-standing IETF consensus that DDoS is an attack
that protocols should mitigate them to the extent they can {{BCP72}}.
Decreasing the number of vulnerabilities in protocols and (outside of
IETF) the number of bugs in the network stacks of routers or computers
could address this issue. The IETF can clearly play a role in bringing
about some of these changes but the IETF cannot be expected to take a
positive stance on (specific) DDoS attacks, or create protocols to
enable some attacks and inhibit others. What the IETF can do is
critically reflect on its role in the development of the Internet, and
how this impacts the ability of people to excercise their human rights,
such as freedom of expression.

> but of course I may be wrong or an outlier there.

Presentation of Shane and Giovane at IETF:

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_HRPC&chapter=chapter_1

their earlier emails to the list:

https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi4

https://mailarchive.ietf.org/arch/msg/hrpc/OJKXq7Yq3AwX4j3Yv0Oi32MTzV8

https://mailarchive.ietf.org/arch/msg/hrpc/ZPvhLL0pj2vJxkVFKW3qM-stsoE

> means that all human rights are contingent and none are absolute.

This is not true. Torture is for instance always prohibited. We would
get here into concepts of proportionality and necessity (and perhaps
even legal accountability), which would imho only make the text more,
not less complex for literal-minded types (and the non-literal-minded
types alike).

> better protected if they are not specifically claimed as human

I see what you're trying to do here, but I think this is for another
document.

> architecture." Not that surprising I guess:-)

Well, there seems to be more consensus on Internet architecture than
this, at least as far as I could find, but am happy to be convinced (in
both cases).

Cheers,

Niels

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Oct 2016 17:38:07 +0100

Hiya,

(trimming bits....)

> completely at providing considerations.

Hmm. If that'd be an hrpc document then it'd fully
overlap with this. If not, then what kind of document
would that be? An IETF one? I think we're some way
from being ready for that tbh.

Anyway, doesn't that mean the comment stands for this
document? Producing another document doesn't answer
the point raised about the structure of this one.

>> cases (and I bet you'll find remaining cases mean different things).

Because I don't think it's likely an RG-consensus definition
of "Internet architecture" but even more important I think
this document doesn't have to depend on their being such a
consensus definition. (Just because there's a hole beside
us doesn't mean we need to dig it deeper:-)

> so sure about ill-defined. Could you be a bit more precise in your

More precise than "you don't need it, and you've not defined
it in a way that I think would garner consensus"? :-)

I'd again encourage you to try not use the term at all as it's
not needed.

> Because a function arrow doesn't seem in place here, or...?

I answered that above. Regardless of the symbol there's a
lack of precision in the concepts here but the presentation
implies that such precision exists. See the TLS/Tor text
just above.

> security? That doesn't make sense to me.

I think we'd agree TLS is currently the most important
security protocol widely used on the Internet. TLS has
no concept of anonymity. Saying that "a,b,c, anonymity, e
and f is what makes up security on the Internet" is IMO
therefore wrong, for all a,b,c, e and f.

Another issue with "anonymity" is that it's not at all
clear what you might mean by that. Is the use of a source
IP address allowed? What about a MAC address? What about
identifiers in client certificates? What about a TLS
session ticket? And all of those are just TLS examples.

Any the "is what makes up" just seems like arm-waving.
I really am not seeing how we benefit from making such
ostensibly definitive (mis)statements. (While at the
same time being fine that such constructs were found
useful when organising the work earlier on.)

> therefore fit in this research document.

Yes, those may have been helpful in doing the work. That
does not mean it is helpful to present them as if they
are defining precise relationships, as they are not. Hence
my suggestion to move them to an appendix and present
them there as a tool that was used in the research and
not as (seems to me to be the case) as some results of
the work that define precise relationships.

> such as freedom of expression.

Ok, fair enough, that is better.

I still think "limited number" and "in most cases" misrepresent
the reality though which is that maybe 99.999% of DDoS attacks
involve zombies.

I also don't think the linkage to freedom of expression survives
taking away the (bad) idea that some DDoS attacks are "ok."

Isn't the real problem with DDoS mitigation that it nearly forces
people to use commercial services, and not that DDoS mitigation
prevents people from saying what they want (e.g. protesting).

So I still think the above text could be improved but it's
no longer a show-stopper for me.

> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_HRPC&chapter=chapter_1

Didn't have time for that sorry.

> https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi4

Quoting from that:

"
Conclusion
==========
My own feeling is that while this checklist is helpful in the current
form, it should probably be shortened and clarified."

> https://mailarchive.ietf.org/arch/msg/hrpc/ZPvhLL0pj2vJxkVFKW3qM-stsoE

There Giovane said a bunch of the questions were not
relevant to him. (I'm not clear what the diference
between the two postings from his is btw, but that's
probably ok.)

Honestly, I'm not seeing "exhaustive," and I maintain my
position that a number of the questions won't have any good
answers for the intended audience.

> not less complex for literal-minded types (and the non-literal-minded

I'm more interested that the point below be included and don't
mind how that's introduced.

> I see what you're trying to do here, but I think this is for another

FWIW, I think it's important to include that point in this
document, given what I know of IETFers.

Cheers,
S.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 18 Oct 2016 15:04:11 -0400

> therefore fit in this research document.

This is probably old news but I agree that the diagrams have outlived
their usefulness... they draw the eyes, but then leave an interested
reader wondering what they are trying to depict. I like to be able to
describe the relationship described by a figure in words (even if
tortured!). Here, if I do that, I get:

Some combination of the concepts on the LHS support the concept on the RHS.

Can we just write that down in the draft for each figure? (If my
description above is right, I definitely think the figures can just be
removed in place of a table of concepts that interviewees listed as
relevant... no need for a mysterious figure).

best, Joe

Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Oct 2016 22:39:31 +0100

> Some combination of the concepts on the LHS support the concept on the RHS.

FWIW, that's almost the same conclusion I reached wrt the
relationship that the symbol is trying to represent. It's
not clear to me that such statements are useful, hence my
suggestion to keep the pictures in an appendix as a bit of
methodology that was found useful, but that does not really
represent a result of the research.

S.

---

From: Niels ten Oever <[email-masked]>
Date: Sun, 23 Oct 2016 18:16:42 -0400

Hiya,

> from being ready for that tbh.

IETF one, and I think we're indeed still some time away from that.

> the point raised about the structure of this one.

And I think my point also still stands. It is logical to put 
the conclusion of the research, after the research overview, at the 
bottom. At least in a Research Document (which is what we're 
developing here).

> us doesn't mean we need to dig it deeper:-)

I am not sure if this point is widely shared. Would love to 
hear from others. For me the way it is used does not seem 
problematic. Perhaps you could point out more specifically where you 
see problems (except in process)?

> I'd again encourage you to try not use the term at all as it's

Pls show me how it is ill-defined, cause I do not see it. But this 
might be me of course!

> the work that define precise relationships.

OK - created a table as suggested by Joe and removed the formulas. 
Hope that this will provide more clarity.

> > https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi4

OK - so let's get a bit deeper into this. We're saying that security 
is a human rights. We're not saying that encryption is a human 
rights, only that encryption can enable a specific human right. That 
is as far as we go here. I do not think that saying 'a specific 
technology is a human right' makes much sense, because it is context 
dependent. I do think privacy is a human rights and therefore we 
should use encryption.  And that is the point we're making imho. But 
maybe you see that differently?

I hope that with this we can now start the Research Group Last Call.

Cheers,

Niels

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 23 Oct 2016 23:44:06 +0100

> bottom. At least in a Research Document (which is what we're 

Many things are logical but unwise.

The length of this document and the target audience make
the current structure unwise.

I think in the above argument you also seem to be changing
the target audience a bit, moving from protocol developers
(IETFers) to those interested in reading about research.
Both are valid but very different target audiences.

> see problems (except in process)?

Didn't I do that in the detailed comments? Thought I had
anyway.

> Pls show me how it is ill-defined, cause I do not see it. But this 

Assuming there exists one true definition for the Internet
architecture is problematic. You already reference RFC1958
which says "The principle of constant change is perhaps the
only principle of the Internet that should survive indefinitely."
and which begins it's section 2.1 by saying "Many members of the
Internet community would argue that there is no architecture..."
While 1958 does go on to talk more about that (the that in
question being the topic of the RFC:-) I do not believe that
the core situation has changed over the last 20 years.

As to showing, I believe I did that in the original detailed
comments. (Would have to check though.)

> Hope that this will provide more clarity.

The tables are better than the formulae. I continue to
disagree with the "is what makes up" statement.

>> no longer a show-stopper for me.

Note that the above is still a comment on the draft. Just
because I don't think it a show-stopper doesn't mean that
it's good to ignore.

>>> https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi4

No response?

> is a human rights. 

I don't think that statement is in the draft. And while that
sentence may be one stated in various HR contexts, I don't
think that anyone has a good understanding of the mapping of
that to technical concepts that are meaningful to IETFers.
See the TLS/anonymity comments above.

> We're not saying that encryption is a human 
> is as far as we go here. 

Again. You don't currently say that in the draft. (And nor
should you I think.)

> I do not think that saying 'a specific 

I think you're missing my point so I'll try again.

There is a risk that IETFers take a very literal approach to
the topic of considering human rights and as a result argue
that anything they consider "good" is a human right. This
draft should, I think, help avoid that by describing at least
one major pitfall in such an approach. And I think the example
of encryption is a good one to use for this.

Cheers,
S.

---

From: Harry Halpin <[email-masked]>
Date: Mon, 24 Oct 2016 02:45:13 +0200 (CEST)

I would put something easy to read at the top (like I'm doing in this email), such as the conclusions and list of rights, and save justifications and examples for later in the document.

My two cents,
     harry

----- Mail original -----
> De: "Stephen Farrell" <[email-masked]>
> À: "Niels ten Oever" <[email-masked]>
> Cc: [email-masked]
> Envoyé: Lundi 24 Octobre 2016 00:44:06
> Objet: Re: [hrpc] review of draft-irtf-hrpc-research-00
> 
> 
>

---

From: Niels ten Oever <[email-masked]>
Date: Sun, 23 Oct 2016 22:05:27 -0400

Hiya,

> Both are valid but very different target audiences.

Since you and Harry feel strongly about this, I will reconsider moving
the 'Model for developing human rights protocol considerations' up.

Do you think we should put them after the 'Vocabulary Used' and before
the 'Research Questions'?

> Didn't I do that in the detailed comments? Thought I had

What we have now is: "all the protocols, procedures, processes and their
accompanying people and politics that go into ensuring the Internet
remains a medium for unfettered global connectivity."

I think it makes sense to define it because then we can make the direct
relation between human rights and the Internet architecture. Which I
think is an important point to make.

You think it's too broad to be meaningful?

> comments. (Would have to check though.)

I think with the definition offered above, we covered your criticisms.

> disagree with the "is what makes up" statement.

Does this solely apply to the security bit? Would you say that anonymity
is never a part of security?

Changed it into:

DDoS attacks can thus stifle freedom of expression, complicate the
ability of independent media and human rights organizations to exercise
their right to (online) freedom of association, while facilitating the
ability of governments to censor dissent.  When it comes to comparing
DDoS attacks to protests in offline life, it is important to remember
that only a limited number of DDoS attacks involved solely willing
participants. In the overwhelming majority of cases, the clients are
hacked hosts of unrelated parties that have not consented to being part
of a DDoS (for exceptions see Operation Abibil {{Abibil}} or the Iranian
Green Movement DDoS {{GreenMovement}}). In addition, DDoS attacks are
increasingly used as an extortion tactic.

>>> taking away the (bad) idea that some DDoS attacks are "ok."

That is the conclusion of these three paras.

>>> prevents people from saying what they want (e.g. protesting).

There are many issues with DDoS mitigation (cloudflare & tor, etc), but
do you think we should discuss them here? It is also a rapidly moving
topic (Dyn, etc).

> because I don't think it a show-stopper doesn't mean that

Sorry I did not react to this, was still thinking about it actually.
Hope this already helps a bit.

>>> answers for the intended audience.

Since the review of Shane and Giovane (and your comments) we cut a lot
of issues from the questionnaire, what else do you think we should cut?

> See the TLS/anonymity comments above.

That we do not fully understand it, does not mean we cannot say that
there is no relation, right? I think we are making a statement, just not
a conclusive one.

> Again. You don't currently say that in the draft. (And nor

We should not say that encryption enables the right to privacy?

> of encryption is a good one to use for this.

Are you saying that we should argue that there might be cases in which
encryption should not be used because of human rights considerations?

Cheers,

Niels