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

[Mallory Knodel <[e-mail]>]

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