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

[Mallory Knodel <[e-mail]>]

Right.

On 10/10/16 01:19 PM, Niels ten Oever wrote:
> 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
>
> PGP fingerprint    8D9F C567 BEE4 A431 56C4
>                    678B 08B5 A0F2 636D 68E9
>
> On 10/10/2016 12:17 PM, Mallory Knodel wrote:
>> 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
>>
>> On 10/10/16 12:24 PM, Niels ten Oever wrote:
>>> 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:
>>>
>>> https://tools.ietf.org/html/draft-irtf-hrpc-research-01
>>>
>>> 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
>>>
>>> On 10/10/2016 09:27 AM, Mallory Knodel wrote:
>>>> 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:
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hrpc mailing list
>>>>> [e-mail]
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> hrpc mailing list
>>>> [e-mail]
>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>>
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> [e-mail]
>>> 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
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
> _______________________________________________
> hrpc mailing list
> [e-mail]
> 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