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

[Niels ten Oever <[e-mail]>]

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
>