From nobody Sun Oct 9 09:27:48 2016 Return-Path: X-Original-To: hrpc@irtf.org Delivered-To: hrpc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EB5129427; Sun, 9 Oct 2016 09:27:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147603046639.30603.1999554475476570569.idtracker@ietfa.amsl.com> Date: Sun, 09 Oct 2016 09:27:46 -0700 Archived-At: Cc: hrpc@irtf.org Subject: [hrpc] I-D Action: draft-irtf-hrpc-research-01.txt X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 16:27:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Human Rights Protocol Considerations of the IETF. Title : Research into Human Rights Protocol Considerations Authors : Niels ten Oever Corinne Cath Filename : draft-irtf-hrpc-research-01.txt Pages : 68 Date : 2016-10-09 Abstract: This document provides a proposal for a vocabulary to discuss the relation between human rights and Internet protocols, an overview of the discussion in technical and academic literature and communities, a proposal for the mapping of the relation between human rights and technical concepts, and a proposal for guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations [RFC6973]. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. This documents aims to be a consensus document of the Human Rights Protocol Consideration Research Group of the Internet Research Task Force (IRTF). Discussion of this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/listinfo/hrpc The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-irtf-hrpc-research-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-research-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 9 09:31:41 2016 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39489129577 for ; Sun, 9 Oct 2016 09:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.33 X-Spam-Level: X-Spam-Status: No, score=0.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_BRBL_LASTEXT=1.449, SPF_NEUTRAL=0.779, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v5BFst-A-cA for ; Sun, 9 Oct 2016 09:31:33 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7586129573 for ; Sun, 9 Oct 2016 09:31:32 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 63C867D3A3B for ; Sun, 9 Oct 2016 16:31:31 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 522DCDC40E9 for ; Sun, 9 Oct 2016 16:31:31 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id AA2307D3A3B for ; Sun, 9 Oct 2016 16:31:30 +0000 (UTC) To: hrpc@irtf.org References: From: Niels ten Oever Message-ID: Date: Sun, 9 Oct 2016 18:31:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oGPKCBiPFJUaGF0SCmWXriaimmi8Jov74" Archived-At: Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 16:31:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oGPKCBiPFJUaGF0SCmWXriaimmi8Jov74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=93 as it pe= rtains to the remit of the IETF. Would it be better if the first mention of the word architecture came with the following clarification: =E2=80=98Interne= t 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: =E2=80=98Many 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=E2=80=99= =2E 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.=E2=80=99 Wo= uld 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 "=3D" mean here? > > In section 2 and later (in 5.2.2) you have diagrams with > bracketed terms on the left, then "=3D" and then another term on > the right. I just don't get what you mean by that "=3D" 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 '=3D' in to an '=E2=87=92' > 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 "=3D" 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 '=3D' with '=E2=87=92' 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.asp= x ). 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 =E2=80=9Cprovide[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.=E2=80=9D > 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: =E2=80=9CNo 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.=E2=80=9D {{ICCPR}} Article 17: =E2=80=9C1. 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.=E2= =80=9D 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 > "=3D" 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 =E2=80=9Ctheory of the blunt instrument=E2=80=9D 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 =E2=80=9CSaffron Revolution=E2=80=9D, 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 =E2=80=9Cblunt instrument=E2=80=9D outcome into the architectu= re 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_paper= s/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= =2E 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 "=3D") 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 abov= e. > 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.xhtm= l > 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-p= rogram-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,4466= 4.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-move= ment-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= =3D7314859 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 " so I don't see > a need to say that " 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= =2E > 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/rugg= ie/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= =2E > > 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 th= at. > > 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= =2E > > 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 --oGPKCBiPFJUaGF0SCmWXriaimmi8Jov74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX+nDhAAoJEAi1oPJjbWjpGKQIAICQ0ETlawrs/c0XduiTOfFZ ln9lxpX8Csgshpbw54uiRzdeDcu5OMgFoJ3aPO/V83tKM/nChFOyKDpVES/JUbg4 GmFIt2jpHDui5LoWc7LyaM0ko8BilM/VsYThoMquVJK1J2Bg65LcuOeVypLFmV3i RVbwc28+oU10i3D4ofuo/O8jNeyDIHiG6uWGcBL9srBvyaSvw44x5wolkoWH1X7O 16OJph9ug2b4oYNqFxabEG05ovQIz5YvHUTUi3+DUQ3ZE82PRMasyE5j+OUZamPd A0vaeUVsFeVZXLCJtUqA2yjXMJl1iHpeDIJleut47APjFRYbcpkqfaxaGnI7/14= =j51O -----END PGP SIGNATURE----- --oGPKCBiPFJUaGF0SCmWXriaimmi8Jov74-- From nobody Sun Oct 9 12:58:15 2016 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003A0129550 for ; Sun, 9 Oct 2016 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.328 X-Spam-Level: X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdKTSM0g3vY6 for ; Sun, 9 Oct 2016 12:58:11 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B5B128B44 for ; Sun, 9 Oct 2016 12:58:11 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id CC1AA7D3A3B for ; Sun, 9 Oct 2016 19:58:09 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id BA45FA0BBEB for ; Sun, 9 Oct 2016 19:58:09 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id A0DB57D3A3B for ; Sun, 9 Oct 2016 19:58:09 +0000 (UTC) To: "hrpc@irtf.org" From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <64cb2185-0c1e-d7dd-824d-e797e1d5db31@article19.org> Date: Sun, 9 Oct 2016 21:58:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kGQjTQDRhUbb6I5GOc6nsMfPr9hx6FeT9" Archived-At: Subject: [hrpc] Proposed Agenda HRPC @ IETF X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 19:58:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kGQjTQDRhUbb6I5GOc6nsMfPr9hx6FeT9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Please find underneath a first draft of the proposed agenda for our session in Seoul. All suggestions for speakers, drafts, ideas and discussions are very welcome. Human Rights Protocols Considerations (hrpc) research group sessions at #IETF96 [time] UTC [timezone], November [day] 2016 - Beginning (5 min) Jabber scribe, note takers Agenda Bashing Notewell Introduction - Status of research group & documents (2 min) - Context of research (5 mins) - Presentation + Q&A - Francesca Musiani on Infrastructure and Human Rights (20 mins) - Presentation + Q&A - Sarah Spiekerman on Value Based Design (20 mins) - Discussion of draft-irtf-hrpc-research (20 mins) https://tools.ietf.org/html/draft-irtf-hrpc-research - process update by document sherpherd (Avri Doria) - content update by document authors (Niels ten Oever, Corinne Cath) - next steps - Open discussion other drafts, papers, ideas (15 min) - Next steps (5 min) - AOB Best, Niels --=20 Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 --kGQjTQDRhUbb6I5GOc6nsMfPr9hx6FeT9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX+qFRAAoJEAi1oPJjbWjp2B0H/iwXWuWu1182TFc2P+cJx28v w3MWFFbng4papP59pTT/qhQGQoomKLt1aJYmcSVcdgZ4a8u/3ydR97Z1TMmG+cdG +lvdJZQlr8SgmJ9zc30x06UxmtIYdQ6ITObcHpWw02k4/bI+fwhVlUq62xtO4wFH vkp/EpXEc1PX6A+nkL6LtQjIP8pH7vN3Tfobwfwsg/tOrtVmhdWv/bzZphVEOasL 6ggLzupsxEouVrfS5B83Ku3AIz+TjLdd0QJc4VrQfdg+3lx8bqNyWPXTicuNHDH+ u6lWLn5AcXoqE+sFrZXXmTJmY43qeFide9WGPyDZwUGLY5qBPKG5hXtaJcuAU4g= =b6v/ -----END PGP SIGNATURE----- --kGQjTQDRhUbb6I5GOc6nsMfPr9hx6FeT9-- From nobody Mon Oct 10 00:27:32 2016 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8601295D0 for ; Mon, 10 Oct 2016 00:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.194 X-Spam-Level: X-Spam-Status: No, score=-7.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyJfiYzXaFRu for ; Mon, 10 Oct 2016 00:27:21 -0700 (PDT) Received: from mail.gn.apc.org (mail.gn.apc.org [37.220.108.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC121294A6 for ; Mon, 10 Oct 2016 00:27:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id 0EA912011733 for ; Mon, 10 Oct 2016 08:27:18 +0100 (BST) X-Virus-Scanned: by amavisd-new at mail.gn.apc.org Received: from mail.gn.apc.org ([127.0.0.1]) by localhost (mail.gn.apc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IB-awEVAAETH for ; Mon, 10 Oct 2016 08:27:14 +0100 (BST) Received: from anonymous ([10.254.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mallory) by mail.gn.apc.org (Postfix) with ESMTPSA id 98238201170F for ; Mon, 10 Oct 2016 08:27:12 +0100 (BST) To: hrpc@irtf.org References: From: Mallory Knodel Message-ID: <57FB42CF.5010008@apc.org> Date: Mon, 10 Oct 2016 10:27:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SlRw0kS1bRgHmA5ANpWq8l5VJKM7NNwBG" Archived-At: Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 07:27:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SlRw0kS1bRgHmA5ANpWq8l5VJKM7NNwBG Content-Type: multipart/alternative; boundary="------------020103010003020609050503" This is a multi-part message in MIME format. --------------020103010003020609050503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 i= t > 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 =E2=80=93 as it = pertains > to the remit of the IETF. Would it be better if the first mention of th= e > word architecture came with the following clarification: =E2=80=98Inter= net > 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: =E2=80=98Many member= s 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=E2=80= =99. > 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.=E2=80=99 = Would > such a definition clarify our use of the word architecture sufficiently= ? > > Additionally, we would like to push back a bit against the argument tha= t > 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 "=3D" mean here? >> >> In section 2 and later (in 5.2.2) you have diagrams with >> bracketed terms on the left, then "=3D" and then another term on >> the right. I just don't get what you mean by that "=3D" 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 wel= l > as authenticity. > > I think it can easily be argued than in many models of security, privac= y > 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, an= d > authenticity is what makes up security on the Internet. > > I also changed the '=3D' in to an '=E2=87=92' > > >> 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 "=3D" 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 '=3D' with '=E2=87=92' and added an explanation= =2E > > > >> (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 analysi= s > 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 i= s > 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 huma= n > 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 sentenc= e > to read: The open nature of the initial technical design (open > standards, open source, etc) fostered freedom of communication as a cor= e > 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 settin= g > the standard (no pun intended) for what they think the network should > look like, irrespective of what implementers and operators end up doing= =2E > >> 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 bi= t > 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.a= spx > ). 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= =2E > > > >> 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 th= e > essential role of encryption and anonymity in realizing human rights > protected under international law, as such technology =E2=80=9Cprovide[= 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.=E2=80=9D > >> 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: =E2=80=9CNo 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.=E2=80=9D > {{ICCPR}} Article 17: =E2=80=9C1. No one shall be subjected to arbitrar= y or > unlawful interference with his privacy, family, home or correspondence,= > nor to unlawful attacks on his honour or reputation. 2. Everyone has th= e > right to the protection of the law against such interference or attacks= =2E=E2=80=9D > 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 Chil= d; > 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 desig= n > 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 >> "=3D" 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 engineer= s > 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-vi= s > 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 =E2=80=9Ctheory of the blunt > instrument=E2=80=9D 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 blun= t > 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 =E2=80=9CSaffron > Revolution=E2=80=9D, 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 =E2=80=9Cblunt instrument=E2=80=9D outcome into the architec= ture may > raise large complexities for actors required to comply with > regulations. When France required that Yahoo block auctions of Naz= i > memorabilia to its citizens, Yahoo had to organize a table > that identified (imperfectly) IP addresses of French users. Woul= d > it have been better or worse if the Internet made it easy to tell fro= m > what jurisdiction a connection came?" > > See here: > http://conferences.sigcomm.org/co-next/2010/Workshops/REARCH/ReArch_pap= ers/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 methodological= ly. > > 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 "=3D") 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 ab= ove. > > >> 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 tha= t > 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.xht= ml >> > 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 ar= e > 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,44= 664.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 t= o > 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-mo= vement-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 researc= h > 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 scal= e. > > 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 othe= r > 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-vp= ns-pt-1/#respond > > http://ieeexplore.ieee.org.proxy.uba.uva.nl:2048/stamp/stamp.jsp?arnumb= er=3D7314859 > 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 " so I don't see >> a need to say that " 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, pleas= e > 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 remov= e > 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 conte= xt. > > >> 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= =2E > 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 bot= h > legally and technically understood, but hard to achieve. And as you sai= d > previously, the combination of protocols make anonymity harder, which i= s > 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 thi= s > 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_cor= e_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/ru= ggie/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 need= s > 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 (i= n > due time) with the RFC editor who probably has some good ideas about th= is. > >> 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 b= y > 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 ar= e > 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 b= e > combined to ensure that the Internet remains an enabling environment fo= r > human rights. With this the contours of a model for developing human > rights protocol considerations has taken shape. This subsection provide= s > 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 present= s > 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 > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --=20 Mallory Knodel Association for Progressive Communications :: apc.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------020103010003020609050503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-re=
search-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 =E2=80=93 as it pe=
rtains
to the remit of the IETF. Would it be better if the first mention of the
word architecture came with the following clarification: =E2=80=98Interne=
t
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: =E2=80=98Many 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=E2=80=99=
=2E
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.=E2=80=99 Wo=
uld
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 "=3D" mean here?

In section 2 and later (in 5.2.2) you have diagrams with
bracketed terms on the left, then "=3D" and then another term on
the right. I just don't get what you mean by that "=3D" 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 '=3D' in to an '=E2=87=92'



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 "=3D" 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 '=3D' with '=E2=87=92' 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 th=
ink 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 e=
xtend 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 mani=
festation 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 t=
hat 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 t=
erm 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/Iss=
ues/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 =E2=80=9Cprovide[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.=E2=80=9D


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 interes=
ting. 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 b=
roken 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 a=
s 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 discuss=
ion section


2, "i18n" - I think you're wrong that "Many protoc=
ols..." 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 t=
erm 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 ne=
w 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: =E2=80=9CNo 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.=E2=80=9D
{{ICCPR}} Article 17: =E2=80=9C1. 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.=E2=
=80=9D
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 surpr=
ised 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 de=
sign 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 thin=
k 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 wh=
ich 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, confidentiali=
ty,
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
"=3D" as used here.)


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


section 4: I don't accept that "protocols are poli=
tics 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 ho=
w 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 =E2=80=9Ctheory of the blunt
instrument=E2=80=9D 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    =E2=80=9CSaffron
Revolution=E2=80=9D,    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 =E2=80=9Cblunt instrument=E2=80=9D outcome into the architectu=
re   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://confere=
nces.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=
=2E

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 a=
bout "=3D") 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 abov=
e.



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/assignme=
nts/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-p=
rogram-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, ma=
ybe 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 relevati=
ons 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]


h=
ttps://en.rsf.org/syria-syria-using-34-blue-coat-servers-23-05-2013,44664=
=2Ehtml

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/stateme=
nt/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:


http=
s://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 stif=
le 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 c=
orrect.  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#sec=
tion-5.1 Doesn't
seem very conclusive.



5.2.7.4: Sybil attacks in this context (e.g. astro=
turfing) 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.pd=
f

Theses ones are the best I could find:

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


http://ieeexplore.=
ieee.org.proxy.uba.uva.nl:2048/stamp/stamp.jsp?arnumber=3D7314859
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 p=
art 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/dictionar=
y/consideration


5.3.2: I don't think that many IETFers follow or r=
ead RFC4101.
(RFC4101 is a useful, good thing, but one that's not much used
iiuc.)



It seem quite useful though, I do not necessarily se=
e a reason to remove
it.


5.3.2.1.2: We're updating RFC3552 now, and the upd=
ate 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 sti=
ll useful for context.



5.3.2.1.7: These are not useful, as phrased for IE=
TFers.  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. Anonymi=
ty 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 counte=
rproductive
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 ques=
tionnaire
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_th=
e_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/medi=
a/documents/ruggie/ruggie-guiding-principles-21-mar-2011.pdf


intro, "New protocols, particularly those that upg=
rade 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 h=
ave 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=
=2E


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" cens=
orship, 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 t=
o 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 t=
ext 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 th=
at.


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=
=2E


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 abou=
t) 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 t=
han 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. So=
me 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 co=
mmunity. 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 conc=
ealed, 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
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc

--
Mallory Knodel
Association for Progressive Communications :: apc.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
--------------020103010003020609050503-- --SlRw0kS1bRgHmA5ANpWq8l5VJKM7NNwBG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX+0LPAAoJEAwyonG9PMeAhVcH/iXfTLagb0IwT9G8pB2g6HSJ WHLNwc7TbXc2TJX1D0uGTGT8W9r6EQzbZK7MBoHQ4DK0Y0oxJ3xW2bcva4VVuiDJ u27p8WxicucA3zokKRg4dH3IRuMKr8RZ69D8fxX4WxHsCqChxzYnw3MpByLO3fAT mmsTDe63bUdKhXvFW/ZGA/NxFGRPUnQdEaecXEursIwN3pu5+GzyJqx+LlZnrbDT ksfb+4pOmcbhAleiNEjsjG0oDAmeH7B4Ss/foubQx/RhHrW64cr2CRK2Ga0FdfjS JfhEweaEuPFEJZQDd5yOj4nTJxXvqIxNGGbAnjXOsZykSlDMD2aC2FrxsuMtjMs= =32GS -----END PGP SIGNATURE----- --SlRw0kS1bRgHmA5ANpWq8l5VJKM7NNwBG-- From nobody Mon Oct 10 02:24:47 2016 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581C81294BE for ; Mon, 10 Oct 2016 02:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.33 X-Spam-Level: X-Spam-Status: No, score=0.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_BRBL_LASTEXT=1.449, SPF_NEUTRAL=0.779, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWKk6Y_nOuIb for ; Mon, 10 Oct 2016 02:24:37 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D86A129453 for ; Mon, 10 Oct 2016 02:24:35 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 2A16020E0508 for ; Mon, 10 Oct 2016 09:24:34 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 12F5320E0506 for ; Mon, 10 Oct 2016 09:24:34 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id DEEBD20E0508 for ; Mon, 10 Oct 2016 09:24:33 +0000 (UTC) To: hrpc@irtf.org References: <57FB42CF.5010008@apc.org> From: Niels ten Oever Message-ID: <626501bd-3ce5-fd9a-e6f9-3a911584b953@article19.org> Date: Mon, 10 Oct 2016 11:24:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.3.0 MIME-Version: 1.0 In-Reply-To: <57FB42CF.5010008@apc.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FaRSemqBiU4cUC9oiLEt5CoJMTbRHJNCS" Archived-At: Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 09:24:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FaRSemqBiU4cUC9oiLEt5CoJMTbRHJNCS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 >=20 > 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. >=20 > I also fully agree with Stephen about the DDoS section and if nothing > else would be happy to proceed with working on this. >=20 > However, fully aware that work needs to progress and without having bee= n > able to comment up to now I'd like feedback on where in the text my > edits could be most useful. >=20 > -Mallory >=20 > 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 argument= s >> 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 i= t >> 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 =E2=80=93 as it= pertains >> to the remit of the IETF. Would it be better if the first mention of t= he >> word architecture came with the following clarification: =E2=80=98Inte= rnet >> architecture is a catch-all phrase. In order to ensure it does not rin= g >> hollow we want to clarify what we mean by this term. Our definition is= >> partly based on the consensus understanding of the term architecture a= s >> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many membe= rs 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=E2=80= =99. >> 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.=E2=80=99= Would >> such a definition clarify our use of the word architecture sufficientl= y? >> >> Additionally, we would like to push back a bit against the argument th= at >> because there is no consensus in the IETF on what the term architectur= e >> means, we cannot use it in the text. The IRTF should be the space wher= e >> 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 "=3D" mean here? >>> >>> In section 2 and later (in 5.2.2) you have diagrams with >>> bracketed terms on the left, then "=3D" and then another term on >>> the right. I just don't get what you mean by that "=3D" 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 we= ll >> as authenticity. >> >> I think it can easily be argued than in many models of security, priva= cy >> 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, a= nd >> authenticity is what makes up security on the Internet. >> >> I also changed the '=3D' in to an '=E2=87=92' >> >> >>> 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 "=3D" 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 betwee= n >> the LHS and the RHS should be 'contribute to an enabling environment >> for', so I replaced the '=3D' with '=E2=87=92' and added an explanatio= n. >> >> >> >>> (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 analys= is >> a case of technology and it's impact human rights. So, it has a >> completely different role from RFC3552, even though the conclusions ar= e >> 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 presente= d >> the outcomes at the session in Berlin and were also posted to the list= =2E >> >>> (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 n= o >> consensus in the law community about how this should be done. There ar= e >> many scholarly papers written about this, and I would large go with th= e >> approach in the UN Guiding Principles for Business and Human Rights. S= o >> 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 tha= t >> 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 hum= an >> 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 senten= ce >> to read: The open nature of the initial technical design (open >> standards, open source, etc) fostered freedom of communication as a co= re >> 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= =2E >> 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 setti= ng >> the standard (no pun intended) for what they think the network should >> look like, irrespective of what implementers and operators end up doin= g. >> >>> 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 b= it >> 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 term= s, >> 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 probabl= y >> 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 possibl= e. >> >> >> >>> 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 t= he >> essential role of encryption and anonymity in realizing human rights >> protected under international law, as such technology =E2=80=9Cprovide= [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.=E2=80=9D >> >>> 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 i= s >> inherently hostile to non latin characters, which send the message tha= t >> 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 an= d >> regional human rights instruments, including: >> {{UDHR}} Article 12: =E2=80=9CNo 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.=E2=80=9D >> {{ICCPR}} Article 17: =E2=80=9C1. No one shall be subjected to arbitra= ry or >> unlawful interference with his privacy, family, home or correspondence= , >> nor to unlawful attacks on his honour or reputation. 2. Everyone has t= he >> right to the protection of the law against such interference or attack= s.=E2=80=9D >> 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 Chi= ld; >> Article 4 of the African Union Principles on Freedom of Expression (th= e >> 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 provid= e >> 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 desi= gn >> ensuring for the capacity to both scale up and down can be a challenge= =2E >> Yet, it is important to consider the capability of the protocol to do >> both, to ensure new protocols consider the requirements of both big an= d >> 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 >>> "=3D" 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= =2E >> 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 enginee= rs >> and computer scientists, underwrite this statement. I also do not thin= k >> it is without qualification, the text goes on to mention at least eigh= t >> different papers that carefully qualify these statements. If we howeve= r >> 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 lates= t >> session of hpc in Berlin when United Nations Special Rapporteur David >> Kaye presented his latest report on the responsibility of SDOs vis-a-v= is >> human rights. The HRPC work has been focused specifically on the >> question of how values get translated to design, and how they should o= r >> 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 =E2=80=9Ctheory of the blunt >> instrument=E2=80=9D says that if you can blunt the tools of you= r >> 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 blu= nt >> instrument of total disconnect. This theory is appealing to >> those who see the Internet as a vehicle for contention with stat= e >> 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 Chines= e >> people than none. >> Similarly, Burma took the step of disconnecting all international= >> telecommunications links during the 2007 =E2=80=9CSaffron >> Revolution=E2=80=9D, and several >> countries have blocked Facebook and YouTube. Are those countrie= s >> and their citizens better off with that outcome than with >> half a loaf? Second, when law trumps technology, >> baking the =E2=80=9Cblunt instrument=E2=80=9D outcome into the archite= cture may >> raise large complexities for actors required to comply with >> regulations. When France required that Yahoo block auctions of Na= zi >> memorabilia to its citizens, Yahoo had to organize a table >> that identified (imperfectly) IP addresses of French users. Wou= ld >> it have been better or worse if the Internet made it easy to tell fr= om >> what jurisdiction a connection came?" >> >> See here: >> http://conferences.sigcomm.org/co-next/2010/Workshops/REARCH/ReArch_pa= pers/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 methodologica= lly. >> >> 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 "=3D") 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 a= bove. >> >> >>> 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 work= s >> 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 th= at >> 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.xh= tml >>> >> 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-gtl= d-program-budget-22oct10-en.pdf >> , for the latter I do not have any data that shows that gTLD overall a= re >> 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 a= s >> those operated by Telecomix [http://dns.telecomix.org/]. The distorte= r >> 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,4= 4664.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 extensio= n >> 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-m= ovement-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 resear= ch >> 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 sca= le. >> >> 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 oth= er >> 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. Thing= s >> 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-v= pns-pt-1/#respond >> >> http://ieeexplore.ieee.org.proxy.uba.uva.nl:2048/stamp/stamp.jsp?arnum= ber=3D7314859 >> 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 attac= k >> that protocols should mitigate them to the extent they can {{RFC3552}}= =2E >> >>> 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 " so I don't see >>> a need to say that " 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 coul= d >> arise, through the use of the questionnaire. I don't see how the use o= f >> '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, plea= se >> 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 remo= ve >> 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 o= f >> 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 point= s >> 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 cont= ext. >> >> >>> 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 angl= e. >> Else also wouldn't need to discuss security, etc. Plus I think there i= s >> 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 bo= th >> legally and technically understood, but hard to achieve. And as you sa= id >> 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 sak= e >> 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 th= is >> work further we can have a closer look at usability and streamlining i= t >> 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_co= re_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/r= uggie/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 tha= t >> I would love to to. >> >> I do think it makes sense to put in some prioritization of human right= s >> impacts assessments in here though. I don't think core or non-core nee= ds >> 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 t= his. >> >>> 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 wha= t >> 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 a= re >> 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 th= e >> 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 f= or >> human rights. With this the contours of a model for developing human >> rights protocol considerations has taken shape. This subsection provid= es >> 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 presen= ts >> 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= =2E >> >>> 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 o= f >> 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 >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >=20 > --=20 > Mallory Knodel > Association for Progressive Communications :: apc.org = > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --FaRSemqBiU4cUC9oiLEt5CoJMTbRHJNCS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX+15NAAoJEAi1oPJjbWjpb2AIAIKwQDMv1OgilkBJ6DHR94Hf WDzBVi7FxKWbJUYlwDRkC2sYuy82Y8k+wrfYLAqsy6Eddzynx85da/WasbbNS40j QmMdhLHpopSKpcT/JhhqUNMmkeZRLKG4w9dWFNOtBIfo6dpsKaYq1FUVmPimnfcD UJDfiMt/iRzoArrML1488GGKnEx+vOSSU1YNElszMfMK6nHGCp/kCc+wsVy56hQm yxWPohlh2gU1pFUHVDekWB/mUuFN+15Yj6EbNhxGNurfB43pgA1EcIjQzjoEt64J qrXQm2jhFA6BMixZ5y/fXhQuHtSfkCDAVHaUgQTd0kfFei6WxETO/nImE1MkpIY= =H52j -----END PGP SIGNATURE----- --FaRSemqBiU4cUC9oiLEt5CoJMTbRHJNCS-- From nobody Mon Oct 10 03:18:14 2016 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E241294DF for ; Mon, 10 Oct 2016 03:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.194 X-Spam-Level: X-Spam-Status: No, score=-7.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltzCROO8fPEA for ; Mon, 10 Oct 2016 03:18:01 -0700 (PDT) Received: from mail.gn.apc.org (mail.gn.apc.org [37.220.108.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58B7129483 for ; Mon, 10 Oct 2016 03:18:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id 74ECB201926D for ; Mon, 10 Oct 2016 11:17:59 +0100 (BST) X-Virus-Scanned: by amavisd-new at mail.gn.apc.org Received: from mail.gn.apc.org ([127.0.0.1]) by localhost (mail.gn.apc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkQpQ0nA1w6r for ; Mon, 10 Oct 2016 11:17:54 +0100 (BST) Received: from anonymous ([10.254.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mallory) by mail.gn.apc.org (Postfix) with ESMTPSA id 78D45201877B for ; Mon, 10 Oct 2016 11:17:52 +0100 (BST) To: hrpc@irtf.org References: <57FB42CF.5010008@apc.org> <626501bd-3ce5-fd9a-e6f9-3a911584b953@article19.org> From: Mallory Knodel Message-ID: <57FB6ACF.6010902@apc.org> Date: Mon, 10 Oct 2016 13:17:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <626501bd-3ce5-fd9a-e6f9-3a911584b953@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qgKIL27dJuhghaUre4utD8HlobPk0pJik" Archived-At: Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "niels@article19.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 10:18:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qgKIL27dJuhghaUre4utD8HlobPk0pJik Content-Type: multipart/alternative; boundary="------------000709060706000300070801" This is a multi-part message in MIME format. --------------000709060706000300070801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 reade= r >> 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 be= en >> 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 argumen= ts >>> 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 i= t >>> 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 ar= e >>> referring to the technical functioning of the Internet =E2=80=93 as i= t pertains >>> to the remit of the IETF. Would it be better if the first mention of = the >>> word architecture came with the following clarification: =E2=80=98Int= ernet >>> architecture is a catch-all phrase. In order to ensure it does not ri= ng >>> hollow we want to clarify what we mean by this term. Our definition i= s >>> partly based on the consensus understanding of the term architecture = as >>> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many memb= ers of the >>> Internet community would argue that there is no architecture, but onl= y 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 th= e >>> 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 divers= e >>> hardware providing global connectivity is the "end to end argument=E2= =80=99. >>> Building on RFC1958 we hold that the word architecture, in the contex= t >>> 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.=E2=80=99= Would >>> such a definition clarify our use of the word architecture sufficient= ly? >>> >>> Additionally, we would like to push back a bit against the argument t= hat >>> because there is no consensus in the IETF on what the term architectu= re >>> means, we cannot use it in the text. The IRTF should be the space whe= re >>> we can push the boundaries on that discussion, bringing in definition= s >>> 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 "=3D" mean here? >>>> >>>> In section 2 and later (in 5.2.2) you have diagrams with >>>> bracketed terms on the left, then "=3D" and then another term on >>>> the right. I just don't get what you mean by that "=3D" 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, woul= d >>> be: depends on the usecase. If we for instance take the example of TL= S >>> for .onion websites, there the security model includes anonymity as w= ell >>> as authenticity. >>> >>> I think it can easily be argued than in many models of security, priv= acy >>> 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 '=3D' in to an '=E2=87=92' >>> >>> >>>> 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 "=3D" 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 betwe= en >>> the LHS and the RHS should be 'contribute to an enabling environment >>> for', so I replaced the '=3D' with '=E2=87=92' and added an explanati= on. >>> >>> >>> >>>> (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 analy= sis >>> a case of technology and it's impact human rights. So, it has a >>> completely different role from RFC3552, even though the conclusions a= re >>> 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 present= ed >>> the outcomes at the session in Berlin and were also posted to the lis= t. >>> >>>> (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 a= re >>> many scholarly papers written about this, and I would large go with t= he >>> 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 righ= t >>> to freedom of expression and the right to privacy. In such as case th= e >>> 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 proces= s >>> 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 th= at >>> 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 hu= man >>> 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 R= G >>> 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 sente= nce >>> to read: The open nature of the initial technical design (open >>> standards, open source, etc) fostered freedom of communication as a c= ore >>> 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 encourag= e. >>> 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 awa= y >>> from the fact that the IETF/IRTF does have a substantial role in sett= ing >>> the standard (no pun intended) for what they think the network should= >>> look like, irrespective of what implementers and operators end up doi= ng. >>> >>>> 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 ter= ms, >>> 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= =2Easpx >>> ). And eventhough it is indeed a hard technical problem, I actually >>> think quite a lot of people are working on this. Tor is indeed probab= ly >>> the best 'running code' example, but there is also Briar, I2P, Trible= r, >>> 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 possib= le. >>> >>> >>> >>>> 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 =E2=80=9Cprovid= e[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.=E2=80=9D >>> >>>> 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 o= f >>> 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 o= n >>> 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 th= at >>> 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 a= nd >>> regional human rights instruments, including: >>> {{UDHR}} Article 12: =E2=80=9CNo 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.=E2=80=9D >>> {{ICCPR}} Article 17: =E2=80=9C1. No one shall be subjected to arbitr= ary or >>> unlawful interference with his privacy, family, home or correspondenc= e, >>> nor to unlawful attacks on his honour or reputation. 2. Everyone has = the >>> right to the protection of the law against such interference or attac= ks.=E2=80=9D >>> 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 Ch= ild; >>> Article 4 of the African Union Principles on Freedom of Expression (t= he >>> 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, an= d >>> to involuntary, legal or malicious attempts to disrupt its mode of >>> operations. {{RFC0760}} {{RFC0791}} {{RFC0793}} {{RFC1122}}. Or frame= d >>> more positively, robustness is the quality of a system that can provi= de >>> 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 des= ign >>> ensuring for the capacity to both scale up and down can be a challeng= e. >>> Yet, it is important to consider the capability of the protocol to do= >>> both, to ensure new protocols consider the requirements of both big a= nd >>> 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 >>>> "=3D" 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 consensu= s. >>> I think a lot of people have expressed the sentiment that their >>> technical protocols increasingly have an impact on the political real= m >>> 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 engine= ers >>> and computer scientists, underwrite this statement. I also do not thi= nk >>> it is without qualification, the text goes on to mention at least eig= ht >>> different papers that carefully qualify these statements. If we howev= er >>> 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 late= st >>> 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 =E2=80=9Ctheory of the blunt= >>> instrument=E2=80=9D says that if you can blunt the tools of yo= ur >>> 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 bl= unt >>> instrument of total disconnect. This theory is appealing to >>> those who see the Internet as a vehicle for contention with sta= te >>> 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 th= e >>> 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, bu= t >>> some argue that a little Google would be better for the Chine= se >>> people than none. >>> Similarly, Burma took the step of disconnecting all internationa= l >>> telecommunications links during the 2007 =E2=80=9CSaffron >>> Revolution=E2=80=9D, and several >>> countries have blocked Facebook and YouTube. Are those countri= es >>> and their citizens better off with that outcome than with >>> half a loaf? Second, when law trumps technology, >>> baking the =E2=80=9Cblunt instrument=E2=80=9D outcome into the archit= ecture may >>> raise large complexities for actors required to comply with >>> regulations. When France required that Yahoo block auctions of N= azi >>> memorabilia to its citizens, Yahoo had to organize a table >>> that identified (imperfectly) IP addresses of French users. Wo= uld >>> it have been better or worse if the Internet made it easy to tell f= rom >>> what jurisdiction a connection came?" >>> >>> See here: >>> http://conferences.sigcomm.org/co-next/2010/Workshops/REARCH/ReArch_p= apers/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 methodologic= ally. >>> >>> 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 "=3D") 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 wor= ks >>> 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 t= hat >>> those features could have been better, the sentence only reads that i= t >>> _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.x= html >>>> >>> 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-gt= ld-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 distort= er >>> 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 ther= e >>> was no debate or that there are no exclusive h2/tls implementation. A= m >>> 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 extensi= on >>> 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 whil= e >>> ago but I did not hear back. Suggestions and reviewers are always ver= y >>> 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 resea= rch >>> 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 documen= t >>> 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 sc= ale. >>> >>> 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 ot= her >>> 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. Thin= gs >>> 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?arnu= mber=3D7314859 >>> 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 atta= ck >>> 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 " so I don't see >>>> a need to say that " 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 ca= n >>> people to be cognizant of by thinking and documenting issues that cou= ld >>> 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, ple= ase >>> 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 rem= ove >>> 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 abou= t >>> 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 poin= ts >>> 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 con= text. >>> >>> >>>> 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 ang= le. >>> 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 b= oth >>> legally and technically understood, but hard to achieve. And as you s= aid >>> 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 differen= t >>> 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 differen= t >>> 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 o= f >>> that, but would that make it easier to understand? Or just for the sa= ke >>> 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 t= his >>> 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_c= ore_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 th= at >>> I would love to to. >>> >>> I do think it makes sense to put in some prioritization of human righ= ts >>> impacts assessments in here though. I don't think core or non-core ne= eds >>> to be binary as well. Some things are simply bound to be used more an= d >>> 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 wh= at >>> 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 numbe= r >>> 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 tha= n 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 tha= t >>> 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 late= r 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 t= he >>> 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 provi= des >>> 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 prese= nts >>> 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 ther= e. >>> >>>> 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 i= n >>> 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 >>> hrpc@irtf.org >>> https://www.irtf.org/mailman/listinfo/hrpc >> --=20 >> Mallory Knodel >> Association for Progressive Communications :: apc.org >> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 >> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >> > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --=20 Mallory Knodel Association for Progressive Communications :: apc.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------000709060706000300070801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-re=
search-01

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
w=
ww.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-re=
search-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 rep=
ly, 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 o=
n all points, so let's
not lower the bar!


(2) Length and structure for protocol develope=
rs.

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 descriptio=
n 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 =E2=80=93 as it pe=
rtains
to the remit of the IETF. Would it be better if the first mention of the
word architecture came with the following clarification: =E2=80=98Interne=
t
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: =E2=80=98Many 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=E2=80=99=
=2E
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.=E2=80=99 Wo=
uld
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 "=3D" mean here?

In section 2 and later (in 5.2.2) you have diagrams with
bracketed terms on the left, then "=3D" and then another term on
the right. I just don't get what you mean by that "=3D" 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 '=3D' in to an '=E2=87=92'



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 "=3D" 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 '=3D' with '=E2=87=92' 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 f=
rom 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 ro=
adtest 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 o=
ne 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 import=
ance:-)

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 quest=
ions 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 n=
etwork 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 Inte=
rnet 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 t=
he 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 g=
uess ;-) 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 Inter=
net 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 I=
ETF 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 li=
ke 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 t=
he 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 le=
gal 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/Iss=
ues/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 t=
here 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 =E2=80=9Cprovide[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.=E2=80=9D


I do think we should consider "being hard to t=
rack" 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 int=
eresting. 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 b=
it 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 sta=
tement 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 th=
is as an argument
and not a principle. You'll get different opinions on that
though:-)

Could you elaborate? I think we documented the u=
se and origins pretty
well in bodies of literature and academic discussion.

2, "Internet censorship" - I think this defini=
tion 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 Conflic=
t"... 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 dis=
cussion section


2, "i18n" - I think you're wrong that "Many pr=
otocols..." 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 Yoko=
hama.

 (Note that for many binary protocols i18n isn't very

relevant at all, if one assume that i18n is mo=
stly important
for end-users and less so for developers or bigger operators.)


Here I would like to push back with the argument=
s 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 abou=
t 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: =E2=80=9CNo 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.=E2=80=9D
{{ICCPR}} Article 17: =E2=80=9C1. 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.=E2=
=80=9D
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 s=
urprised there're
no references for the first two and puzzled by the references
for the 3rd.

References added (my bad, thanks for spotting) a=
nd 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 th=
ese
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 prooco=
l 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 w=
ill be read by
researchers as well as protocol developers.


2, "transparent" - I don't like this definitio=
n 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, confident=
iality,
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
"=3D" 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 th=
is 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 an=
d 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 =E2=80=9C=
theory of the blunt
instrument=E2=80=9D 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    =E2=80=9CSaffron
Revolution=E2=80=9D,    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 =E2=80=9Cblunt instrument=E2=80=9D outcome into the architectu=
re   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://confere=
nces.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 st=
eps 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 link=
s 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=
=2E

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 abo=
ve about "=3D") 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 so=
urce-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 hum=
an 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 num=
ber 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/assignme=
nts/protocol-numbers/protocol-numbers.xhtml


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


5.2.3.3: I don't think mobile IP could never h=
ave 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 ou=
t 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 thn=
k that the ccTLDs
would agree with that? I don't.

Altered the text to: "which function in line wit=
h ICANN's policy"


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


You mean that it is expensive to become a regist=
ry (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-p=
rogram-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 th=
is:

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 t=
he 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 f=
or'



5.2.5 and 5.2.5.x: While I'm fine with you cal=
ling 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 rele=
vations 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 e=
rror 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,4=
4664.html

Updated link, reference added and judgemental language removed.


5.2.5.2: wrt great-cannon, you might want to n=
ote 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/stateme=
nt/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 fa=
ir. 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 th=
ings. 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 le=
arn 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 deploym=
ents 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 Messe=
nger, 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:


http=
s://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 Exp=
lanation 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 feat=
ures 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. a=
stroturfing) 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 i=
t'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" - th=
at'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 anyth=
ing really good. Things
like:
    http://dx.doi.org/10.1016/S1742-6847(06)70438-4
    http://www.ijcse.com/docs/INDJCSE14-05-04-101.pd=
f

Theses ones are the best I could find:

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


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



5.2.8.3: " VPN providers should at least be tr=
ansparent 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 sugg=
estion 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 preve=
nt 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 con=
trol 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 argu=
ment 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 disc=
uss 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 concret=
e 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 cher=
ry 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 exclu=
de 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 her=
e:

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/dictionar=
y/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 necessaril=
y 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 traffi=
c 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. Al=
l 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 rig=
ht 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 pre=
sentation 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 fo=
r 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 o=
ther 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 argume=
ntation, could you
elaborate pls?



5.3.2.1.9: The question was asked already. Ano=
nymity 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 suc=
h 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 sh=
ould 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 statefuln=
ess 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 duplicati=
ve 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 co=
unterproductive
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 i=
t 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 s=
hould be deleted.

Agreed, removed.

5.3.2.1.19: I've no clue if this'd be useful t=
o 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 re=
view.

intro, "the core of the Internet, its architec=
tural 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_th=
e_internet_Web.pdf


intro, "properly defined, described and protec=
ted 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 st=
ep to make something
tangible. Also inline with
https://business-humanrights.org/sites/default/files/medi=
a/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 actua=
lly, 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 th=
at 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 n=
eeded 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, righ=
t? Will take this up (in
due time) with the RFC editor who probably has some good ideas about this=
=2E


2: "In the discussion of human rights and Inte=
rnet 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 toge=
ther.


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

Accepted


2, "confidentiality" - why not refer to 4949 t=
here?


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 ha=
rd to read

Fixed


2, l10n - you don't actually use that abbrevia=
tion 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 principl=
e,
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 princip=
le, 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 missi=
ng text to the
effect that you think the answer to question 2 is yes.

But it would be weird to answer that question he=
re, 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 a=
uthors 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=
=2E


5: "step taken by the research group" that's a=
mbiguous - 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 sect=
ion 5. Is there a
new point being made?

Yeah - methodology and datasources are inherentl=
y 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 h=
ere 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 a=
nother 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 contrib=
uted 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 reference=
s. 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 n=
eed 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 tim=
e.


5.2.7: "often seen" - by whom? I'm not sure th=
at 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 con=
clusions
subsction? I'd say be consistent.

Heading tossed.


5.2.8.1: you could lose the heading here (cons=
istency 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 a=
nd 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, oth=
er 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=
=2E 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 h=
uman 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 f=
ocus back to the
questionnaire.


5.3.1: The term "ICTs" isn't common in the IET=
F 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 make=
s 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 b=
een 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 on=
ce this one is done.


5.3.2.1.4: The last para of explanatory materi=
al 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 tr=
ue 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
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


        

        
--=20
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
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc



      

      

      

      

      

      
_______________________________________________
hrpc mailing list
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


    

    

    
-- 

      Mallory Knodel

      Association for Progressive Communications :: apc.org

      gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C
      C780

  


--------------000709060706000300070801--

--qgKIL27dJuhghaUre4utD8HlobPk0pJik
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX+2rPAAoJEAwyonG9PMeAYLMH/irJGdSsFq5O3+cUQ7PW5cvh
zERwiqqXc5oqsOGY9abXtKeM9UBfKqvleXEu8RX5Hahk/XfD0A3DB8WMQbnzgbBt
1UiF9JTV5Sigr6PiNEKy+PINa+eonG1mZzrvQjF6UWb7I82F4icwhqWzuemWZ4xW
38TPZm0wl9Ll4uJhRfe93HmQ+Ef4HuJd9wJdQBsTunTX9vbE+geLfkQeh1IkBse1
bfErt7l0+46vJnQximP96p8dn/Gd99uYY7z0KxZrt3JtFx/9dca39I/a9Djwhxpz
1FgMCYDkjZrmsYGafojPQCL+5SCu264YJw7B7Bq/qVpT/ZhoMxLR/0yps6yRiOU=
=TA5d
-----END PGP SIGNATURE-----

--qgKIL27dJuhghaUre4utD8HlobPk0pJik--



From nobody Mon Oct 10 03:19:59 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50671294DF for ; Mon, 10 Oct 2016 03:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.33
X-Spam-Level: 
X-Spam-Status: No, score=0.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_BRBL_LASTEXT=1.449, SPF_NEUTRAL=0.779, WEIRD_PORT=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXmif7yv0GU9 for ; Mon, 10 Oct 2016 03:19:51 -0700 (PDT)
Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B75129483 for ; Mon, 10 Oct 2016 03:19:51 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 22BA720E0506 for ; Mon, 10 Oct 2016 10:19:50 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 104EB220C378 for ; Mon, 10 Oct 2016 10:19:50 +0000 (UTC)
Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id D6AEB20E0506 for ; Mon, 10 Oct 2016 10:19:49 +0000 (UTC)
To: hrpc@irtf.org
References:   <57FB42CF.5010008@apc.org> <626501bd-3ce5-fd9a-e6f9-3a911584b953@article19.org> <57FB6ACF.6010902@apc.org>
From: Niels ten Oever 
Message-ID: 
Date: Mon, 10 Oct 2016 12:19:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.3.0
MIME-Version: 1.0
In-Reply-To: <57FB6ACF.6010902@apc.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UtpTnrVRuTox8FdXOqGk6qsAmc919KCh8"
Archived-At: 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Oct 2016 10:19:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UtpTnrVRuTox8FdXOqGk6qsAmc919KCh8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
>=20
> -Mallory
>=20
> 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 lis=
t
>> and/or as pull request), are very welcome!
>>
>> If you want to focus on the abstract and the introduction that would b=
e
>> 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 a=
t
>>> this stage? I was focussed on the abstract and introductions as those=
,
>>> at a minimum, should have strong logical arguments that draw the read=
er
>>> 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 b=
een
>>> 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 t=
o
>>>> all your comments and offered some solutions or at least some argume=
nts
>>>> 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 bringin=
g 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 a=
re
>>>> referring to the technical functioning of the Internet =E2=80=93 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: =E2=80=98In=
ternet
>>>> architecture is a catch-all phrase. In order to ensure it does not r=
ing
>>>> 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: =E2=80=98Many mem=
bers of the
>>>> Internet community would argue that there is no architecture, but on=
ly 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 communit=
y
>>>> believes that the goal is connectivity, the tool is the Internet
>>>> Protocol, and the intelligence is end-to-end rather than hidden in t=
he
>>>> 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 provider=
s,
>>>> and flourishes in the increasingly liberal and competitive commercia=
l
>>>> telecommunications environment. The key to global connectivity is th=
e
>>>> inter-networking layer.  The key to exploiting this layer over diver=
se
>>>> hardware providing global connectivity is the "end to end argument=E2=
=80=99.
>>>> Building on RFC1958 we hold that the word architecture, in the conte=
xt
>>>> 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.=E2=80=99=
 Would
>>>> such a definition clarify our use of the word architecture sufficien=
tly?
>>>>
>>>> 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 architect=
ure
>>>> means, we cannot use it in the text. The IRTF should be the space wh=
ere
>>>> we can push the boundaries on that discussion, bringing in definitio=
ns
>>>> from academia as we do in the text by referring to amongst others th=
e
>>>> work of Prof. Denardis and Prof. Bowker on architecture.
>>>>
>>>>
>>>>> (4) What does "=3D" mean here?
>>>>>
>>>>> In section 2 and later (in 5.2.2) you have diagrams with
>>>>> bracketed terms on the left, then "=3D" and then another term on
>>>>> the right. I just don't get what you mean by that "=3D" 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, wou=
ld
>>>> be: depends on the usecase. If we for instance take the example of T=
LS
>>>> 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, pri=
vacy
>>>> and anonymity play a role, in others anonymity may be less important=
=2E
>>>>
>>>> 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 '=3D' in to an '=E2=87=92'
>>>>
>>>>
>>>>> 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 "=3D" 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 betw=
een
>>>> the LHS and the RHS should be 'contribute to an enabling environment=

>>>> for', so I replaced the '=3D' with '=E2=87=92' and added an explanat=
ion.
>>>>
>>>>
>>>>
>>>>> (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 anal=
ysis
>>>> 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 presen=
ted
>>>> the outcomes at the session in Berlin and were also posted to the li=
st.
>>>>
>>>>> (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 rig=
ht
>>>> to freedom of expression and the right to privacy. In such as case t=
he
>>>> different affected rights need to be balanced. In order to do this i=
t is
>>>> crucial that the rights impacts are clearly documented in order to
>>>> mitigate the potential harm in a proportional way. Making that proce=
ss
>>>> 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 t=
hat
>>>> 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 h=
uman
>>>> rights were at the top of the minds of the people developing it, the=

>>>> technical principles like end-to-end, decentralization etc which wer=
e
>>>> priorities for the initial developers overlap sufficiently with huma=
n
>>>> 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 - huma=
n
>>>> rights are not intrinsically weaved through the structure of the
>>>> network. We have specified our definition of Internet architecture t=
o
>>>> 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 ;-) Incorporate=
d
>>>> 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 fundamentall=
y
>>>> open. People could just show up and hack away. Have changed the sent=
ence
>>>> 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 encoura=
ge.
>>>> And changed the word encourage in the second sentence to the word
>>>> facilitate. I understand that the IETF/IRTF does not ensure anything=
=2E
>>>> But to tone the language down all through the document would take aw=
ay
>>>> from the fact that the IETF/IRTF does have a substantial role in set=
ting
>>>> the standard (no pun intended) for what they think the network shoul=
d
>>>> look like, irrespective of what implementers and operators end up do=
ing.
>>>>
>>>>> 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 te=
rms,
>>>> 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/CallForSubmissio=
n.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 proba=
bly
>>>> the best 'running code' example, but there is also Briar, I2P, Tribl=
er,
>>>> 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, an=
d I
>>>> don't think we should take a step back an accept that it's not possi=
ble.
>>>>
>>>>
>>>>
>>>>> 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 huma=
n
>>>> 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 =E2=80=9Cprovi=
de[s]
>>>> individuals and groups with a zone of privacy online to hold opinion=
s
>>>> and exercise freedom of expression without arbitrary and unlawful
>>>> interference or attacks.=E2=80=9D
>>>>
>>>>> 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 prett=
y
>>>> 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 t=
hat
>>>> 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: =E2=80=9CNo one shall be subjected to arbitrary=

>>>> interference with his privacy, family, home or correspondence, nor t=
o
>>>> attacks upon his honour and reputation. Everyone has the right to th=
e
>>>> protection of the law against such interference or attacks.=E2=80=9D=

>>>> {{ICCPR}} Article 17: =E2=80=9C1. No one shall be subjected to arbit=
rary or
>>>> unlawful interference with his privacy, family, home or corresponden=
ce,
>>>> nor to unlawful attacks on his honour or reputation. 2. Everyone has=
 the
>>>> right to the protection of the law against such interference or atta=
cks.=E2=80=9D
>>>> 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 C=
hild;
>>>> 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 Ma=
n,
>>>> 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 grammtica=
l
>>>> improvements for robustness:
>>>>
>>>> : The resistance of protocols and their implementations to errors, a=
nd
>>>> to involuntary, legal or malicious attempts to disrupt its mode of
>>>> operations. {{RFC0760}} {{RFC0791}} {{RFC0793}} {{RFC1122}}. Or fram=
ed
>>>> more positively, robustness is the quality of a system that can prov=
ide
>>>> 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 durin=
g
>>>> 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 de=
sign
>>>> ensuring for the capacity to both scale up and down can be a challen=
ge.
>>>> Yet, it is important to consider the capability of the protocol to d=
o
>>>> 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
>>>>> "=3D" 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 consens=
us.
>>>> I think a lot of people have expressed the sentiment that their
>>>> technical protocols increasingly have an impact on the political rea=
lm
>>>> 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 engin=
eers
>>>> and computer scientists, underwrite this statement. I also do not th=
ink
>>>> it is without qualification, the text goes on to mention at least ei=
ght
>>>> different papers that carefully qualify these statements. If we howe=
ver
>>>> 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 lat=
est
>>>> session of hpc in Berlin when United Nations Special Rapporteur Davi=
d
>>>> 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 no=
t
>>>> 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 =E2=80=9Ctheory of the blun=
t
>>>> instrument=E2=80=9D says that if  you  can  blunt  the  tools  of  y=
our
>>>> antagonist  in  a  tussle,  you  may be able to disable him. Thus, i=
f
>>>> all users of the Internet always  encrypted  everything  they  sent,=

>>>> there  could  be  no wiretaps and no discrimination based on content=
=2E
>>>> The only tool left to the regulator (e.g., the state) would be the b=
lunt
>>>> instrument  of  total  disconnect.  This  theory  is  appealing  to
>>>> those  who  see  the  Internet  as  a vehicle for contention with st=
ate
>>>> 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  t=
he
>>>> 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,  b=
ut
>>>> some  argue  that  a  little  Google  would  be  better for the Chin=
ese
>>>> people than none.
>>>> Similarly,  Burma  took  the  step  of disconnecting all internation=
al
>>>> telecommunications links during    the    2007    =E2=80=9CSaffron
>>>> Revolution=E2=80=9D,    and    several
>>>> countries  have  blocked  Facebook  and  YouTube.  Are  those countr=
ies
>>>> and  their  citizens  better  off  with  that  outcome than    with
>>>> half    a    loaf?    Second,    when    law    trumps technology,
>>>> baking the =E2=80=9Cblunt instrument=E2=80=9D outcome into the archi=
tecture   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.  W=
ould
>>>>  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 UDH=
R
>>>> 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 methodologi=
cally.
>>>>
>>>> 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 "=3D") 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 mea=
n
>>>> 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 wo=
rks
>>>> 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 offe=
r
>>>> 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, s=
o
>>>> not sure your critique holds. Mobility could have been an alternativ=
e
>>>> 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-g=
tld-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 distor=
ter
>>>> can then try to block or hijack the connection to this resolver. Thi=
s
>>>> may start an arm's race, the user switching to secured connections t=
o
>>>> this alternative resolver ({{RFC7858}}), the disruptor then trying t=
o
>>>> find more sophisticated ways to block or hijack. In some cases, this=

>>>> research to find an alternative, non-disrupting resolver, may lead t=
o
>>>> more centralisation, many people going to a few big commercial publi=
c
>>>> 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.htm=
l
>>>>>
>>>>> 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 the=
re
>>>> 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 ad=
d 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 extens=
ion
>>>> 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 whi=
le
>>>> ago but I did not hear back. Suggestions and reviewers are always ve=
ry
>>>> 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 rese=
arch
>>>> 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 docume=
nt
>>>> 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 s=
cale.
>>>>
>>>> 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 o=
ther
>>>> 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. Thi=
ngs
>>>> 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?arn=
umber=3D7314859
>>>> 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 privac=
y
>>>> 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 i=
n
>>>> consistent with the long-standing IETF consensus that DDoS is an att=
ack
>>>> 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 " so I don't see
>>>>> a need to say that " 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 c=
an
>>>> people to be cognizant of by thinking and documenting issues that co=
uld
>>>> 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 o=
r
>>>> proritize some rights over others, if other rights seem relevant, pl=
ease
>>>> 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 yo=
u
>>>> will make a decision about
>>>> : a desire to avoid doing something that will make another person sa=
d,
>>>> 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 re=
move
>>>> 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 service=
s
>>>> over others in the routing process ? Is the protocol transparent abo=
ut
>>>> 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 poi=
nts
>>>> 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 co=
ntext.
>>>>
>>>>
>>>>> 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 an=
gle.
>>>> 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, whic=
h 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 differe=
nt
>>>> 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 differe=
nt
>>>> 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 suc=
h
>>>> 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 s=
ake
>>>> 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 t=
hat
>>>> I would love to to.
>>>>
>>>> I do think it makes sense to put in some prioritization of human rig=
hts
>>>> impacts assessments in here though. I don't think core or non-core n=
eeds
>>>> to be binary as well. Some things are simply bound to be used more a=
nd
>>>> 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 tha=
t
>>>> 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 w=
hat
>>>> 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 numb=
er
>>>> 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 th=
an 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 th=
at
>>>> 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 lat=
er 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 tha=
t
>>>> 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 SS=
L 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 i=
n
>>>> 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 reall=
y
>>>> 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 o=
r
>>>> 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 t=
o
>>>> standards and protocols and offered a common vocabulary of technical=

>>>> concepts that impact human rights and how these technical concept ca=
n 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 prov=
ides
>>>> the last step by detailing how specific technical concepts identifie=
d
>>>> above relate to human rights, and what questions engineers should as=
k
>>>> themselves when developing or improving protocols. In short, it pres=
ents
>>>> 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 the=
re.
>>>>
>>>>> 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
>>>> hrpc@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>> --=20
>>> Mallory Knodel
>>> Association for Progressive Communications :: apc.org 
>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>>
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>=20
> --=20
> Mallory Knodel
> Association for Progressive Communications :: apc.org =

> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>=20
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


--UtpTnrVRuTox8FdXOqGk6qsAmc919KCh8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX+2tFAAoJEAi1oPJjbWjpEbAH/3v3/zBMYwfdOY2XkuOp2Pe8
Wxr+6yysq7OuvQoMOkH+KoAp5N0NCHzBIOTE3bNh1liO6Cxov6SrsdzUUUTByjxV
g/etw2yUGil+RB0liHs0cJgcEylgRdEtz5ZgCUhF7BvL4MzbymZYwtAkhdDEDPwx
Oe+ins9pXRvaq3pOTdzyvMr/iW+X+TB5luMPqpVzk2fsDm4uANYik65lXj/yrCUq
nFZO0MgtqJyoC+Xt9slhHA9V0yFdPd2H0q/W91IpG6w8Y7nhJmPBoNIZDEJj/ZDw
fCw933+lsi/7r2UYP8WmtradqOYQrAeV9/V9YoMcOTPxWIlJawCtwa5g2f2ka0U=
=72sa
-----END PGP SIGNATURE-----

--UtpTnrVRuTox8FdXOqGk6qsAmc919KCh8--


From nobody Mon Oct 10 03:57:59 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030F01294FC for ; Mon, 10 Oct 2016 03:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.194
X-Spam-Level: 
X-Spam-Status: No, score=-7.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTkKe8L-5-Qk for ; Mon, 10 Oct 2016 03:57:46 -0700 (PDT)
Received: from mail.gn.apc.org (mail.gn.apc.org [37.220.108.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2563C129507 for ; Mon, 10 Oct 2016 03:57:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id EFC312017F1B for ; Mon, 10 Oct 2016 11:57:43 +0100 (BST)
X-Virus-Scanned: by amavisd-new at mail.gn.apc.org
Received: from mail.gn.apc.org ([127.0.0.1]) by localhost (mail.gn.apc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdvSY26cpyKD for ; Mon, 10 Oct 2016 11:57:39 +0100 (BST)
Received: from anonymous ([10.254.254.3])  (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mallory) by mail.gn.apc.org (Postfix) with ESMTPSA id EA7B52017EFD for ; Mon, 10 Oct 2016 11:57:37 +0100 (BST)
To: hrpc@irtf.org
References:   <57FB42CF.5010008@apc.org> <626501bd-3ce5-fd9a-e6f9-3a911584b953@article19.org> <57FB6ACF.6010902@apc.org> 
From: Mallory Knodel 
Message-ID: <57FB741F.3010803@apc.org>
Date: Mon, 10 Oct 2016 13:57:35 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NbhvbKNuw9KDW9J29C6LSRijxR9G6H731"
Archived-At: 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Oct 2016 10:57:57 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--NbhvbKNuw9KDW9J29C6LSRijxR9G6H731
Content-Type: multipart/alternative;
 boundary="------------050001050802080001060107"

This is a multi-part message in MIME format.
--------------050001050802080001060107
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Right.

On 10/10/16 01:19 PM, Niels ten Oever wrote:
> Excellent, but just to make sure everything is going well: I haven't
> received any pull request yet. Is that correct?
>
> Cheers,
>
> Niels
>
> Niels ten Oever
> Head of Digital
>
> Article 19
> www.article19.org
>
> PGP fingerprint    8D9F C567 BEE4 A431 56C4
>                    678B 08B5 A0F2 636D 68E9
>
> On 10/10/2016 12:17 PM, Mallory Knodel wrote:
>> Great, Niels, I'll continue to send my edits via pull requests. At the=

>> moment, I'm working on a fork via the apcorg Github user.
>>
>> -Mallory
>>
>> On 10/10/16 12:24 PM, Niels ten Oever wrote:
>>> Hi Mallory,
>>>
>>> Reviews and proposed edits (in the form of suggestions here on the li=
st
>>> 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 thos=
e,
>>>> at a minimum, should have strong logical arguments that draw the rea=
der
>>>> into the longer paper.
>>>>
>>>> I also fully agree with Stephen about the DDoS section and if nothin=
g
>>>> 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 argum=
ents
>>>>> 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 too=
k
>>>>> 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 le=
t'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 a=
s 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 bringi=
ng 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 =E2=80=93 as=
 it pertains
>>>>> to the remit of the IETF. Would it be better if the first mention o=
f the
>>>>> word architecture came with the following clarification: =E2=80=98I=
nternet
>>>>> 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 architectur=
e as
>>>>> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many me=
mbers of the
>>>>> Internet community would argue that there is no architecture, but o=
nly a
>>>>> tradition, which was not written down for  the first 25 years (or a=
t
>>>>> least not by the IAB).  However, in very general terms, the communi=
ty
>>>>> 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 sho=
w
>>>>> 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 provide=
rs,
>>>>> and flourishes in the increasingly liberal and competitive commerci=
al
>>>>> telecommunications environment. The key to global connectivity is t=
he
>>>>> inter-networking layer.  The key to exploiting this layer over dive=
rse
>>>>> hardware providing global connectivity is the "end to end argument=E2=
=80=99.
>>>>> Building on RFC1958 we hold that the word architecture, in the cont=
ext
>>>>> 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.=E2=80=
=99 Would
>>>>> such a definition clarify our use of the word architecture sufficie=
ntly?
>>>>>
>>>>> 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 architec=
ture
>>>>> means, we cannot use it in the text. The IRTF should be the space w=
here
>>>>> we can push the boundaries on that discussion, bringing in definiti=
ons
>>>>> from academia as we do in the text by referring to amongst others t=
he
>>>>> work of Prof. Denardis and Prof. Bowker on architecture.
>>>>>
>>>>>
>>>>>> (4) What does "=3D" mean here?
>>>>>>
>>>>>> In section 2 and later (in 5.2.2) you have diagrams with
>>>>>> bracketed terms on the left, then "=3D" and then another term on
>>>>>> the right. I just don't get what you mean by that "=3D" 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, wo=
uld
>>>>> 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, pr=
ivacy
>>>>> and anonymity play a role, in others anonymity may be less importan=
t.
>>>>>
>>>>> 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 '=3D' in to an '=E2=87=92'
>>>>>
>>>>>
>>>>>> 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 "=3D" 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 bet=
ween
>>>>> the LHS and the RHS should be 'contribute to an enabling environmen=
t
>>>>> for', so I replaced the '=3D' with '=E2=87=92' and added an explana=
tion.
>>>>>
>>>>>
>>>>>
>>>>>> (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 ana=
lysis
>>>>> 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 prese=
nted
>>>>> the outcomes at the session in Berlin and were also posted to the l=
ist.
>>>>>
>>>>>> (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 als=
o 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=
=2E So
>>>>> I would offer the following text:
>>>>>
>>>>>     Human rights can be in conflict with each other, such as the ri=
ght
>>>>> 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 proc=
ess
>>>>> tangible and practical for protocol developers is what this researc=
h
>>>>> 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, th=
e
>>>>> technical principles like end-to-end, decentralization etc which we=
re
>>>>> priorities for the initial developers overlap sufficiently with hum=
an
>>>>> rights like freedom of speech and access to information to make thi=
s
>>>>> argument stick. It might have been a happy accident, but few in the=
 RG
>>>>> have disputed that - when looking at it from this perspective - hum=
an
>>>>> 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 ;-) Incorporat=
ed
>>>>> your suggestion at the end of the sentence  and changed 'enabled' t=
o
>>>>> '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 fundamental=
ly
>>>>> open. People could just show up and hack away. Have changed the sen=
tence
>>>>> 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 tha=
t
>>>>> clarifies a bit. This was done to show that today's Internet is mor=
e
>>>>> 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 encour=
age.
>>>>> And changed the word encourage in the second sentence to the word
>>>>> facilitate. I understand that the IETF/IRTF does not ensure anythin=
g.
>>>>> But to tone the language down all through the document would take a=
way
>>>>> from the fact that the IETF/IRTF does have a substantial role in se=
tting
>>>>> the standard (no pun intended) for what they think the network shou=
ld
>>>>> look like, irrespective of what implementers and operators end up d=
oing.
>>>>>
>>>>>> 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 t=
erms,
>>>>> there I think it's important that we work on this. The UN Special
>>>>> Rapporteur on Freedom of Expression has underlined the importance o=
f
>>>>> encryption and anonymity online (
>>>>> http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/CallForSubmissi=
on.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 prob=
ably
>>>>> the best 'running code' example, but there is also Briar, I2P, Trib=
ler,
>>>>> etc. There is also an  increase in Operating Systems that are geare=
d
>>>>> towards anonymity (by integrating Tor and other measures) such as
>>>>> Subgraph, Tails, and Qubes, so I think discussing it is relevant, a=
nd I
>>>>> don't think we should take a step back an accept that it's not poss=
ible.
>>>>>
>>>>>
>>>>>
>>>>>> 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 hum=
an
>>>>> rights impact here. The aforementioned report by the UNSR recognize=
s the
>>>>> essential role of encryption and anonymity in realizing human right=
s
>>>>> protected under international law, as such technology =E2=80=9Cprov=
ide[s]
>>>>> individuals and groups with a zone of privacy online to hold opinio=
ns
>>>>> and exercise freedom of expression without arbitrary and unlawful
>>>>> interference or attacks.=E2=80=9D
>>>>>
>>>>>> 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 pret=
ty
>>>>> 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 infrastructur=
e 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 thin=
k 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: =E2=80=9CNo one shall be subjected to arbitrar=
y
>>>>> interference with his privacy, family, home or correspondence, nor =
to
>>>>> attacks upon his honour and reputation. Everyone has the right to t=
he
>>>>> protection of the law against such interference or attacks.=E2=80=9D=

>>>>> {{ICCPR}} Article 17: =E2=80=9C1. No one shall be subjected to arbi=
trary or
>>>>> unlawful interference with his privacy, family, home or corresponde=
nce,
>>>>> nor to unlawful attacks on his honour or reputation. 2. Everyone ha=
s the
>>>>> right to the protection of the law against such interference or att=
acks.=E2=80=9D
>>>>> 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 M=
an,
>>>>> 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 grammtic=
al
>>>>> 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 fra=
med
>>>>> more positively, robustness is the quality of a system that can pro=
vide
>>>>> 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 duri=
ng
>>>>> 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 d=
esign
>>>>> ensuring for the capacity to both scale up and down can be a challe=
nge.
>>>>> 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
>>>>>> "=3D" 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 consen=
sus.
>>>>> I think a lot of people have expressed the sentiment that their
>>>>> technical protocols increasingly have an impact on the political re=
alm
>>>>> 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 engi=
neers
>>>>> and computer scientists, underwrite this statement. I also do not t=
hink
>>>>> it is without qualification, the text goes on to mention at least e=
ight
>>>>> different papers that carefully qualify these statements. If we how=
ever
>>>>> write out there arguments we run the risk of making that bit of tex=
t
>>>>> 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 la=
test
>>>>> session of hpc in Berlin when United Nations Special Rapporteur Dav=
id
>>>>> 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 shoul=
d or
>>>>> should not. As such, I am surprised to hear you say that you have n=
ot
>>>>> 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 =E2=80=9Ctheory of the blu=
nt
>>>>> instrument=E2=80=9D 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 conten=
t.
>>>>> 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 s=
tate
>>>>> 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 Chi=
nese
>>>>> people than none.
>>>>> Similarly,  Burma  took  the  step  of disconnecting all internatio=
nal
>>>>> telecommunications links during    the    2007    =E2=80=9CSaffron
>>>>> Revolution=E2=80=9D,    and    several
>>>>> countries  have  blocked  Facebook  and  YouTube.  Are  those count=
ries
>>>>> and  their  citizens  better  off  with  that  outcome than    with=

>>>>> half    a    loaf?    Second,    when    law    trumps technology,
>>>>> baking the =E2=80=9Cblunt instrument=E2=80=9D outcome into the arch=
itecture   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 UD=
HR
>>>>> 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 bette=
r
>>>>> 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 methodolog=
ically.
>>>>>
>>>>> There is a preliminary RFC reading list, but we let it go relativel=
y
>>>>> 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 "=3D") 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 offere=
d 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 me=
an
>>>>> 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 o=
f a
>>>>> specific protocol, that this is the only solution that exists and w=
orks
>>>>> 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=
=2Exhtml
>>>>>>
>>>>> I removed this para for now, but am still researching it. Might off=
er
>>>>> 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 alternati=
ve
>>>>> 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 overal=
l 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 suc=
h as
>>>>> those operated by  Telecomix [http://dns.telecomix.org/]. The disto=
rter
>>>>> can then try to block or hijack the connection to this resolver. Th=
is
>>>>> 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, thi=
s
>>>>> research to find an alternative, non-disrupting resolver, may lead =
to
>>>>> more centralisation, many people going to a few big commercial publ=
ic
>>>>> 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-201=
3,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.ht=
ml
>>>>>>
>>>>>> 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 th=
ere
>>>>> 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 a=
dd 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, Telegra=
m,
>>>>> Signal, Axolotl discussion with this? That would be a serious exten=
sion
>>>>> to the discussion... in the security direction. I would like to hea=
r
>>>>> 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-gule=
n-movement-bylock-messaging-ap
>>>>>
>>>>> Review by experts is always welcome. I asked Peter Saint Andre a wh=
ile
>>>>> ago but I did not hear back. Suggestions and reviewers are always v=
ery
>>>>> 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 res=
earch
>>>>> 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 docum=
ent
>>>>> 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 simila=
r
>>>>> 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=
=2E
>>>>> 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 Does=
n'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. Th=
ings
>>>>> 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-o=
f-vpns-pt-1/#respond
>>>>>
>>>>> http://ieeexplore.ieee.org.proxy.uba.uva.nl:2048/stamp/stamp.jsp?ar=
number=3D7314859
>>>>> 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 priva=
cy
>>>>> 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 at=
tack
>>>>> that protocols should mitigate them to the extent they can {{RFC355=
2}}.
>>>>>
>>>>>> 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 " so I don't see
>>>>>> a need to say that " 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 c=
ould
>>>>> arise, through the use of the questionnaire. I don't see how the us=
e 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, p=
lease
>>>>> 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 y=
ou
>>>>> will make a decision about
>>>>> : a desire to avoid doing something that will make another person s=
ad,
>>>>> 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 r=
emove
>>>>> 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 packe=
t
>>>>> payload? Does it look at Is it making decisions based on the payloa=
d of
>>>>> the packet? Does your protocol prioritize certain content or servic=
es
>>>>> over others in the routing process ? Is the protocol transparent ab=
out
>>>>> 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 po=
ints
>>>>> 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 c=
ontext.
>>>>>
>>>>>
>>>>>> 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 a=
ngle.
>>>>> Else also wouldn't need to discuss security, etc. Plus I think ther=
e 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, whi=
ch is
>>>>> actually a case to raise awareness about anonymity in all protocols=
=2E
>>>>>
>>>>>> 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 differ=
ent
>>>>> 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=
=2E
>>>>>
>>>>>> 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 differ=
ent
>>>>> 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 su=
ch
>>>>> 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 b=
e
>>>>> 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 necessaril=
y
>>>>> 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 streamlinin=
g it
>>>>> with other relevant reviews that are ongoing in the IETF, IESG, etc=
=2E
>>>>>
>>>>>> 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 somethin=
g
>>>>> tangible. Also inline with
>>>>> https://business-humanrights.org/sites/default/files/media/document=
s/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 ri=
ghts
>>>>> 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 u=
p (in
>>>>> due time) with the RFC editor who probably has some good ideas abou=
t 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, interoperabilit=
y,
>>>>> resilience, reliability and robustness are the enableing factors th=
at
>>>>> 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 num=
ber
>>>>> 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 t=
han 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 t=
hat
>>>>> both need to be justified afaik. Mixing them up would just be messy=
=2E
>>>>>
>>>>>> 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 la=
ter 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 th=
at
>>>>> 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 S=
SL 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 her=
e are
>>>>> point-to-point connections that enables two computers to communicat=
e
>>>>> 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 real=
ly
>>>>> 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 technica=
l
>>>>> concepts that impact human rights and how these technical concept c=
an be
>>>>> combined to ensure that the Internet remains an enabling environmen=
t for
>>>>> human rights. With this the contours of a model for developing huma=
n
>>>>> rights protocol considerations has taken shape. This subsection pro=
vides
>>>>> the last step by detailing how specific technical concepts identifi=
ed
>>>>> above relate to human rights, and what questions engineers should a=
sk
>>>>> themselves when developing or improving protocols. In short, it pre=
sents
>>>>> 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 th=
ere.
>>>>>
>>>>>> 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 en=
d 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 sa=
y,
>>>>> 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=
=2E
>>>>>
>>>>>> 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
>>>>> hrpc@irtf.org
>>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>> --=20
>>>> Mallory Knodel
>>>> Association for Progressive Communications :: apc.org 
>>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780=

>>>>
>>>>
>>>> _______________________________________________
>>>> hrpc mailing list
>>>> hrpc@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>>
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>> --=20
>> Mallory Knodel
>> Association for Progressive Communications :: apc.org 
>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc

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

--------------050001050802080001060107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Right.

    

    
On 10/10/16 01:19 PM, Niels ten Oever
      wrote:

    

    

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

Cheers,

Niels

Niels ten Oever
Head of Digital

Article 19
w=
ww.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 p=
ull 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-re=
search-01

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
w=
ww.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-re=
search-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 w=
ork 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 consens=
us on all points, so let's
not lower the bar!



              

                
(2) Length and structure for protocol deve=
lopers.

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 descri=
ption 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 architec=
ture, in this text, we are
referring to the technical functioning of the Internet =E2=80=93 as it pe=
rtains
to the remit of the IETF. Would it be better if the first mention of the
word architecture came with the following clarification: =E2=80=98Interne=
t
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: =E2=80=98Many 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=E2=80=99=
=2E
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.=E2=80=99 Wo=
uld
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 "=3D" mean here?

In section 2 and later (in 5.2.2) you have diagrams with
bracketed terms on the left, then "=3D" and then another term on
the right. I just don't get what you mean by that "=3D" 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 no=
t 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 '=3D' in to an '=E2=87=92'




              

                
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 "=3D" 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 '=3D' with '=E2=87=92' 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_ differe=
nt 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 exhaustiv=
e 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 ea=
sy 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 im=
portance:-)

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 q=
uestions 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, sec=
ure 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 glob=
al 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 I=
nternet 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 t=
he 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 galvaniz=
ing 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 d=
o 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 grea=
t 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 bot=
h 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/Iss=
ues/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 no=
t 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. Becau=
se 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 =E2=80=9Cprovide[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.=E2=80=9D



              

                
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 document=
ed?



              

                
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 t=
o this as an argument
and not a principle. You'll get different opinions on that
though:-)


              

              
Could you elaborate? I think we documented t=
he use and origins pretty
well in bodies of literature and academic discussion.


              

                
2, "Internet censorship" - I think this de=
finition 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 Con=
flict"... 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 "Man=
y 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 i=
s mostly important
for end-users and less so for developers or bigger operators.)



              

              
Here I would like to push back with the argu=
ments 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 hos=
ts, 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 referen=
ces 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: =E2=80=9CNo 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.=E2=80=9D
{{ICCPR}} Article 17: =E2=80=9C1. 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.=E2=
=80=9D
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 spottin=
g) 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 t=
o 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 pr=
oocol 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 do=
n'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 defin=
ition 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, confi=
dentiality,
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
"=3D" as used here.)



              

              
I think this should be solved with the solut=
ion 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 tha=
t 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" poin=
t 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 w=
hat 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 =E2=
=80=9Ctheory of the blunt
instrument=E2=80=9D 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    =E2=80=9CSaffron
Revolution=E2=80=9D,    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 =E2=80=9Cblunt instrument=E2=80=9D outcome into the architectu=
re   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://confere=
nces.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 preliminar=
y 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=
=2E

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 "=3D") 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 con=
trol 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 com=
pare 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 tha=
t 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/assignme=
nts/protocol-numbers/protocol-numbers.xhtml



              

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



              

                
5.2.3.3: I don't think mobile IP could nev=
er 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 runnin=
g 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 re=
gistry (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-p=
rogram-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 fo=
r 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 n=
ot 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 reaso=
ns 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/stateme=
nt/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 i=
s 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. I=
t 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 som=
e 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 ca=
n 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 woul=
d be analysing another
protocol, right?



              

                
And lastly, I think the tendency of IM dep=
loyments 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 M=
essenger, 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:


http=
s://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 genera=
l (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 c=
ase 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 t=
his 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 clea=
r 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://to=
ols.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 thi=
nk 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 differ=
ence, 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 unders=
tood" 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 a=
nything really good. Things
like:
    http://dx.doi.org/10.1016/S1742-6847(06)70438-4
    http://www.ijcse.com/docs/INDJCSE14-05-04-101.pd=
f

Theses ones are the best I could find:

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


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




              

                
5.2.8.3: " VPN providers should at least b=
e 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 bette=
r 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) bel=
ongs 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 p=
revent 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 att=
acks 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 sho=
uld 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 con=
crete 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 e=
xclude 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/dictionar=
y/consideration



              

                
5.3.2: I don't think that many IETFers fol=
low 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 necess=
arily 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 tr=
affic 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=
=2E 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 phrase=
d 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 ar=
gumentation, 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. Yo=
u 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 state=
fulness 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 dupli=
cative 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 bec=
ause 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 bec=
ause this gets a different
meaning from the human rights perspective imho.



              

                
5.3.2.1.15: This needs to be rewritten, th=
ere 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 peo=
ple 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, becau=
se 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 merge=
d? 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 a=
nd should be deleted.


              

              
Agreed, removed.


              

                
5.3.2.1.19: I've no clue if this'd be usef=
ul 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 editoria=
l review.


              

                
intro, "the core of the Internet, its arch=
itectural 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_th=
e_internet_Web.pdf



              

                
intro, "properly defined, described and pr=
otected 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 firs=
t step to make something
tangible. Also inline with
https://business-humanrights.org/sites/default/files/medi=
a/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 a=
ctually, 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 issue=
s 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=
=2E



              

                
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 "preve=
nt" censorship, I'd
say mitigate is better than prevent.


              

              
Accepted



              

                
2, "confidentiality" - why not refer to 49=
49 there?



              

              
Done



              

                
2, "debugging" - the term debug is not use=
d in the draft, why
do you need the definition?


              

              
Tossed.



              

                
2, "decentralized" - why is "opportunity f=
or" 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 hyphen=
ated in the IETF



              

              
Fixed



              

                
2, i18n - funny line breaks there make tha=
t hard to read


              

              
Fixed



              

                
2, l10n - you don't actually use that abbr=
eviation so why
define it?



              

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



              

                
2, "The combination of the end-to-end prin=
ciple,
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 pri=
nciple, 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 m=
issing text to the
effect that you think the answer to question 2 is yes.


              

              
But it would be weird to answer that questio=
n 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 e=
ven mentioned which number
they are.



              

                
4: "embedded into the Internet's architect=
ure" (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 t=
he authors is broader than that.



              

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


              

              
I also don't think it adds much, so it's rem=
oved.



              

                
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 inher=
ently 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 w=
ith captions.


              

              
Done



              

                
5.2.2.1: I guess there's a heading level b=
ug here in the
document sounce?


              

              
Fixed.



              

                
5.2.3.1: "ability for those hosts to assem=
ble 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 con=
tributed to the fact that
HTTP......



              

                
5.2.5: TLS and SSL could do with reference=
s.


              

              
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? "F=
rom 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" i=
s in the wrong tense
- "are being corrected" is correct.


              

              
Fixed



              

                
5.2.5.1: TEMPORA, XKEYSCORE etc need refer=
ences. 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 sur=
e 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 c=
are 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 implementatio=
ns 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 implementati=
ons and protocols used in
the deployment of VPNs,"



              

                
5.2.8.5: The URL for [PET2015VPN] didn't w=
ork 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 poin=
t at the named paper
- what's up there?


              

              
Fixed - but then we removed the whole sectio=
n :)



              

                
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 pr=
efer 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 tra=
ffic. 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 t=
hink 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 th=
at 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 t=
he 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 Or=
wat, 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 ha=
ve 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/ a=
gain:-)



              

              
We cut the discussion up in the doc, but her=
e 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 documen=
t once this one is done.



              

                
5.3.2.1.4: The last para of explanatory ma=
terial 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 usefull=
y 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
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


            

            
--=20
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
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc



          

          

_______________________________________________
hrpc mailing list
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


        

        
--=20
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
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc



      

      

      

      

      

      
_______________________________________________
hrpc mailing list
hrpc@=
irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


    

    

    
-- 

      Mallory Knodel

      Association for Progressive Communications :: apc.org

      gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C
      C780

  


--------------050001050802080001060107--

--NbhvbKNuw9KDW9J29C6LSRijxR9G6H731
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX+3QfAAoJEAwyonG9PMeAyyQH/0PBJS8ky1qA6vJrbmKGHQOK
IUqW2szA01eY77yRPotNraFEmcci55jHa1clC37O9FvousZPl84qfcF+5TcxeQvq
rXjwGkmqJLoY/ge/7XhBmQnErG27ZIfO09uF6u2dgdXK6dEuVNlcAsY2cEdFKHNH
u6tUDj5RqW5Mjihcyc9t1kfBFki1+dn35Dtk6hDdUjOv5RFVR079XUlYzs1unEep
xswpuFqFdkO9lgJoac/ibgAJv+WG+kMxaTSUHRTbKk/5kBiyduHpe+vxcBMBmEGW
CabvbWMiMApaCM1z4o/hDPzRqyZyVC4hnvxYJ5QPEfXeJ8VwBjTo3OL2XcCDkKo=
=F6U5
-----END PGP SIGNATURE-----

--NbhvbKNuw9KDW9J29C6LSRijxR9G6H731--


From nobody Fri Oct 14 08:14:05 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413F3129523 for ; Fri, 14 Oct 2016 08:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Level: 
X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q6ETJajCs46 for ; Fri, 14 Oct 2016 08:14:00 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045171294B9 for ; Fri, 14 Oct 2016 08:14:00 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5CBE32806B8 for ; Fri, 14 Oct 2016 17:13:58 +0200 (CEST)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 586232803B4 for ; Fri, 14 Oct 2016 17:13:58 +0200 (CEST)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 5640AB38004 for ; Fri, 14 Oct 2016 17:13:28 +0200 (CEST)
Received: by b12.nic.fr (Postfix, from userid 1000) id 513E03FD53; Fri, 14 Oct 2016 17:13:28 +0200 (CEST)
Date: Fri, 14 Oct 2016 17:13:28 +0200
From: Stephane Bortzmeyer 
To: hrpc@irtf.org
Message-ID: <20161014151328.aofaigf5byraghzf@nic.fr>
References: <147603046639.30603.1999554475476570569.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <147603046639.30603.1999554475476570569.idtracker@ietfa.amsl.com>
X-Operating-System: Debian GNU/Linux stretch/sid
X-Kernel: Linux 4.7.0-1-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20160916 (1.7.0)
Archived-At: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-01.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Oct 2016 15:14:04 -0000

On Sun, Oct 09, 2016 at 09:27:46AM -0700,
 internet-drafts@ietf.org  wrote 
 a message of 53 lines which said:

>         Title           : Research into Human Rights Protocol Considerations
>         Authors         : Niels ten Oever
>                           Corinne Cath
> 	Filename        : draft-irtf-hrpc-research-01.txt

IMHO, it is more or less ready for a Last Call in this group. We do
not try to have an important protocol on the Standards Track, which
would require a perfect document. We are trying to document something
which was never explicit before, the fact that apparently technical
decisions have consequences for human rights. IMHO, this is more
important than trying to have a perfect RFC. I suggest we worked on it
long enough. Stephen Farrell's remarks

were good and interesting but I do not think they are a pre-requisite
for the Last Call.

However, I would be glad if some issues were really addressed. For
instance, I still do not find a clear definition of "public space"
(this is related to the dDoS discussion), despite
,
the text about script encoding is still unclear despite
...


From nobody Sat Oct 15 03:10:10 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAC212949C for ; Sat, 15 Oct 2016 03:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.255
X-Spam-Level: 
X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mx17bc219R5 for ; Sat, 15 Oct 2016 03:10:07 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A761296F6 for ; Sat, 15 Oct 2016 03:10:07 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id D59176AFED for ; Sat, 15 Oct 2016 10:10:05 +0000 (UTC)
X-Session-Marker: 6176726940646F7269612E6F7267
X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:355:379:599:800:854:960:967:973:982:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1513:1515:1516:1518:1521:1534:1542:1593:1594:1683:1711:1730:1747:1777:1792:1801:1963:2198:2199:2393:2525:2553:2567:2682:2685:2691:2736:2741:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:4362:4425:4605:4860:5007:6117:6119:7652:7903:8660:8957:8985:9010:9025:10004:10400:10559:10848:11232:11658:11914:12043:12050:12109:12114:12291:12379:12438:12663:12683:12740:13019:13071:13095:13148:13230:13846:14096:14097:14180:14181:14721:21060:21080:21324:21366:21433:21451:30022:30054:30060:30070:30090:30091, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none
X-HE-Tag: chalk83_1dd1b880ab332
X-Filterd-Recvd-Size: 3315
Received: from [127.0.0.1] (unknown [41.162.95.186]) (Authenticated sender: avri@doria.org) by omf06.hostedemail.com (Postfix) with ESMTPA for ; Sat, 15 Oct 2016 10:10:04 +0000 (UTC)
References: <147603046639.30603.1999554475476570569.idtracker@ietfa.amsl.com> <20161014151328.aofaigf5byraghzf@nic.fr>
To: hrpc@irtf.org
From: avri doria 
Message-ID: 
Date: Sat, 15 Oct 2016 12:09:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161014151328.aofaigf5byraghzf@nic.fr>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Antivirus: avast! (VPS 161014-3, 10/14/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-01.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: avri@acm.org
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Oct 2016 10:10:09 -0000

Hi,

Thanks to Niels & Corinne for the edited version.  I am still in the
process of reading the revision.

I too am inclined to start the RGLC real soon now, but wanted to give
people a chance to read and comment first.  Plan to take some sort of
action next week on this. I tend to believe that this is not something
we need to rush on, but also not something we should dally with.  And
while Stephen review is not a gating factor, it does seem appropriate
that his comments were responded to before moving on.

As for the issue you bring up, I assume you are not asking that the RG
deal with this before the RGLC.

thanks
avri

On 14-Oct-16 17:13, Stephane Bortzmeyer wrote:
> On Sun, Oct 09, 2016 at 09:27:46AM -0700,
>  internet-drafts@ietf.org  wrote 
>  a message of 53 lines which said:
>
>>         Title           : Research into Human Rights Protocol Considerat=
ions
>>         Authors         : Niels ten Oever
>>                           Corinne Cath
>> 	Filename        : draft-irtf-hrpc-research-01.txt
> IMHO, it is more or less ready for a Last Call in this group. We do
> not try to have an important protocol on the Standards Track, which
> would require a perfect document. We are trying to document something
> which was never explicit before, the fact that apparently technical
> decisions have consequences for human rights. IMHO, this is more
> important than trying to have a perfect RFC. I suggest we worked on it
> long enough. Stephen Farrell's remarks
> 
> were good and interesting but I do not think they are a pre-requisite
> for the Last Call.
>
> However, I would be glad if some issues were really addressed. For
> instance, I still do not find a clear definition of "public space"
> (this is related to the dDoS discussion), despite
> ,=

> the text about script encoding is still unclear despite
> .=
=2E.
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>



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


From nobody Sat Oct 15 06:17:25 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057241296F7 for ; Sat, 15 Oct 2016 06:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.297
X-Spam-Level: 
X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBv1j7Aizz9l for ; Sat, 15 Oct 2016 06:17:22 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6194D1296EF for ; Sat, 15 Oct 2016 06:17:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 197BFBDF9; Sat, 15 Oct 2016 14:17:20 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15L1wjvmiihF; Sat, 15 Oct 2016 14:17:15 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A67D3BDCC; Sat, 15 Oct 2016 14:17:14 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476537435; bh=O2eeRngb8SHqP1NLRi+QgrAKra5g7HRjfdaum5aKnAc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=4iNGeKyqBVW1Barc82UnhNwgq0uF32B87oA8u3Zh9aGicGrqoMKz5CmajWkkvUBQi tTlo4aVxAelBNug13ewQPCpVxy+rnEs9ZKgtJXOo4EosUsa4Xii9eVYEQbwXWgE1yD ClyEDbxEemzyyArebdKMicbYcdbGPZTuqiV5NHWs=
To: Niels ten Oever , hrpc@irtf.org
References:  
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
Date: Sat, 15 Oct 2016 14:17:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OgORdO1W9jhUWqqcvBGFhFwnkbwHrwAX5"
Archived-At: 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Oct 2016 13:17:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--OgORdO1W9jhUWqqcvBGFhFwnkbwHrwAX5
Content-Type: multipart/mixed; boundary="E1E8Kl5C1LSKS74ieD82dOGExuvD3CS8g";
 protected-headers="v1"
From: Stephen Farrell 
To: Niels ten Oever , hrpc@irtf.org
Message-ID: <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
References: 
 
In-Reply-To: 

--E1E8Kl5C1LSKS74ieD82dOGExuvD3CS8g
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Niels,

On 09/10/16 17:31, Niels ten Oever wrote:
> Hi Stephen,
>=20
> 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:
>=20
> https://tools.ietf.org/html/draft-irtf-hrpc-research-01

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

>=20
> On 09/22/2016 02:33 PM, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> I spent a bit of time reviewing this finally.
>=20
> We also spent a bit of time coming up with a reply, sorry if it took
> longer than expected (and announced).
>=20
>>
>> 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:-).
>>
>=20
> Up to now we have been able to reach consensus on all points, so let's
> not lower the bar!

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

>=20
>> (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.
>>
>=20
> 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 i=
t
> into the IETF.

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

>=20
>=20
>> (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 =E2=80=93 as it =
pertains
> to the remit of the IETF. Would it be better if the first mention of th=
e
> word architecture came with the following clarification: =E2=80=98Inter=
net
> 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: =E2=80=98Many member=
s 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=E2=80=
=99.
> 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.=E2=80=99 =
Would
> such a definition clarify our use of the word architecture sufficiently=
?

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

>=20
> Additionally, we would like to push back a bit against the argument tha=
t
> 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.

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

>=20
>=20
>> (4) What does "=3D" mean here?
>>
>> In section 2 and later (in 5.2.2) you have diagrams with
>> bracketed terms on the left, then "=3D" and then another term on
>> the right. I just don't get what you mean by that "=3D" 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.
>=20
>=20
> The easy answer, which will probably will not be enough for you,

Correct:-)

> 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 wel=
l
> as authenticity.

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

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

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

>=20
> To reflect this I changed the text to:
>=20
> A combination of reliability, confidentiality, integrity, anonymity, an=
d
> authenticity is what makes up security on the Internet.

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

>=20
> I also changed the '=3D' in to an '=E2=87=92'
>=20

Not using "=3D" is a minor editorial improvement.

>=20
>> 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 "=3D" 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;-)
>=20
>=20
> 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 '=3D' with '=E2=87=92' and added an explanation=
=2E

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

>>
>> (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.
>>
>=20
> The scope of this document is _very_ different from RFC3552. It analysi=
s
> 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.

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

>=20
>=20
>> (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.
>>
>=20
> 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.=


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

>=20
>> (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.
>>
>=20
> 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:
>=20
>     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 i=
s
> 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.

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

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

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

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

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

Cheers,
S.




--E1E8Kl5C1LSKS74ieD82dOGExuvD3CS8g--

--OgORdO1W9jhUWqqcvBGFhFwnkbwHrwAX5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYAixaAAoJEC88hzaAX42iyAQIAKNJnTkaoR4BWCTsEVtXmNHj
mpxFWR9REWkt/nVrRzHIwMFVHAn9tZ0Yu/f2vxJVLilgsNI/r6Uf4S6mbGsrS7yN
GVOA9Yb1jRWhSY+OHMj1DBtholNoh3tuYjnFSCW0a2YHnXF4OPYwb2xt0dLwyQK1
6rQEC3rYcn1q3qFo0YFDQih4/ZVBsuVdt86yZd/4hYuVr+WPloMUidCGIakzgdMD
6zNU+m4J7uDgJWN4I9+QVJ4sUM69KsfhE3CkjFt0tNAD+ts0pdzdgix51cc906M+
QcjzQy+d2RhOdzVKFK9hlcM8X6cko3bsBeQ9QluNpvDKdiosrKq/F72zeutg+W4=
=7J6M
-----END PGP SIGNATURE-----

--OgORdO1W9jhUWqqcvBGFhFwnkbwHrwAX5--


From nobody Sat Oct 15 14:09:42 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE39D129590 for ; Sat, 15 Oct 2016 14:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.445
X-Spam-Level: *
X-Spam-Status: No, score=1.445 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwO5f_hdLd-K for ; Sat, 15 Oct 2016 14:09:39 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E32F129563 for ; Sat, 15 Oct 2016 14:09:39 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 3C60A12BA14 for ; Sat, 15 Oct 2016 21:09:38 +0000 (UTC)
X-Session-Marker: 6176726940646F7269612E6F7267
X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:355:379:599:854:967:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1513:1515:1516:1518:1521:1534:1541:1593:1594:1683:1711:1730:1747:1777:1792:2393:2525:2553:2560:2563:2682:2685:2693:2859:2895:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:5007:6117:6119:7652:7903:8985:9025:10004:10400:10450:10455:10848:11232:11658:11914:12043:12109:12114:12663:12740:13069:13073:13161:13229:13311:13357:14096:14097:14181:14721:14764:14777:19904:19999:21067:21080:21324:21326:21366:21433:30022:30041:30054:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none
X-HE-Tag: fact42_7121fa20f6958
X-Filterd-Recvd-Size: 2619
Received: from [127.0.0.1] (unknown [196.208.108.61]) (Authenticated sender: avri@doria.org) by omf03.hostedemail.com (Postfix) with ESMTPA for ; Sat, 15 Oct 2016 21:09:37 +0000 (UTC)
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
To: hrpc@irtf.org
From: avri doria 
Message-ID: <93327a79-ca3e-3980-9753-98e9fedee4f4@acm.org>
Date: Sat, 15 Oct 2016 23:09:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Antivirus: avast! (VPS 161015-0, 10/15/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: avri@acm.org
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Oct 2016 21:09:41 -0000

On 15-Oct-16 15:17, Stephen Farrell wrote:
>  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:-).
> >>

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

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

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

avri


avri


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


From nobody Tue Oct 18 03:48:37 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2119A1295A9 for ; Tue, 18 Oct 2016 03:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ShomFmG_wl4 for ; Tue, 18 Oct 2016 03:48:35 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F20012956D for ; Tue, 18 Oct 2016 03:48:35 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id t193so134782114ywc.2 for ; Tue, 18 Oct 2016 03:48:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0KcNpYelIPOSyOm1S8LKkyg/CSeUF7NLrcaduXv+IpI=; b=asuVjnmxMWk+Zc1y4zSz7Bnl3JAfHpeuFQ1SX7pvGgyxBI8gF1AA+1lnAEeBY58HAi FcKYatay7H6hIdHcCRVb4i/Ts8UJ/4LjLRhhiMPEE8khU8aRiAIT4DtCv24Uh1ihLod9 EFs2saDzhtd0Y056/2u9aLE/XVHs/FW+miy7s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0KcNpYelIPOSyOm1S8LKkyg/CSeUF7NLrcaduXv+IpI=; b=NotEphrIOMaBnWsguI9Mig9HyZGNPP9kaC0uf1jInkaVJtOUn+FdpXCdsr5V2Q5f4w /L0uwHrN6zU5bRqnOUjozB9jMaYVZMdjhJ6s8LAVHbaHVyo812NJYZa38O3BUAMkECUK gwqzzvpaon+rFv72k+EGYrmZ+0s+4jnVZ4u7yehK51jJvI0cgDekEugejkr3dHhByGqs 9e8RnLnzLor+XtahNMa5SGu6XfycIu9ucl5K7Rhp9sk5d5XS/Q+HJ0pExP2YhZUaXjwh im3RPtynutjPU62oxgf17tnoS82023aemR/JPiYCByrUCgztgbkU8UI9Xi2n8ptlmF7w OuOw==
X-Gm-Message-State: AA6/9RnRgPKqQ3Rrv4sHGkWcnCE3XGY3J6+fNbxqLn/jgA3cP2MMyXXC+3iwCMVpinp3MCjGhGCSpXMSALcW4Pzy
X-Received: by 10.129.105.196 with SMTP id e187mr1991112ywc.291.1476787714665;  Tue, 18 Oct 2016 03:48:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.13.21 with HTTP; Tue, 18 Oct 2016 03:48:33 -0700 (PDT)
In-Reply-To: <93327a79-ca3e-3980-9753-98e9fedee4f4@acm.org>
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <93327a79-ca3e-3980-9753-98e9fedee4f4@acm.org>
From: Joseph Lorenzo Hall 
Date: Tue, 18 Oct 2016 06:48:33 -0400
Message-ID: 
To: "avri@acm.org" 
Content-Type: multipart/alternative; boundary=001a1147121e2488f0053f216f5e
Archived-At: 
Cc: "hrpc@irtf.org" 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 10:48:37 -0000

--001a1147121e2488f0053f216f5e
Content-Type: text/plain; charset=UTF-8

+1 to starting RGLC soon

On Saturday, October 15, 2016, avri doria  wrote:

>
>
> On 15-Oct-16 15:17, Stephen Farrell wrote:
> >  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:-).
> > >>
>
> Personally, given the importance I find in this bit of work, I think the
> greater value is in finding rough consensus, not in getting something
> out quickly.  I think there are lots of ways to get research published,
> and the value of an IRTF RFC is partly in the rough consensus it involves.
>
> The question, though may involve finding out where the rough lies.  I
> think the work needs wider exposure and it is possible that a RGLC may a
> good way to determine that with a wider audience.  One of the things I
> have noticed with my own work in RGs in the past, is that sometimes it
> takes more than 1 RGLC to get to the rough consensus point, so assuming
> that enough people think that a RGLC is warranted, it may be worth
> calling one.
>
> Still looking for more opinions, more feedback and more discussion on
> the points Stephen is making.
>
> avri
>
>
> avri
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org 
> https://www.irtf.org/mailman/listinfo/hrpc
>


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

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

--001a1147121e2488f0053f216f5e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 to starting RGLC soon

On Saturday, October 15, 2016,=
 avri doria <avri@acm.org> wrote:=





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

>=C2=A0 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 neces=
sarily

> >> 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 tha=
t

> >> latter plan but just wanted to ask in case it helps the RG (a=
nd

> >> Avri who I guess will have the fun of figuring this out:-).
> >>



Personally, given the importance I find in this bit of work, I think the
greater value is in finding rough consensus, not in getting something

out quickly.=C2=A0 I think there are lots of ways to get research published=
,

and the value of an IRTF RFC is partly in the rough consensus it involves.<=
br>


The question, though may involve finding out where the rough lies.=C2=A0 I<=
br>
think the work needs wider exposure and it is possible that a RGLC may a
good way to determine that with a wider audience.=C2=A0 One of the things I=


have noticed with my own work in RGs in the past, is that sometimes it

takes more than 1 RGLC to get to the rough consensus point, so assuming

that enough people think that a RGLC is warranted, it may be worth

calling one.



Still looking for more opinions, more feedback and more discussion on

the points Stephen is making.



avri





avri





---

This email has been checked for viruses by Avast antivirus software.

https://www.a=
vast.com/antivirus



_______________________________________________

hrpc mailing list

hrpc@irtf.org

ht=
tps://www.irtf.org/mailman/listinfo/hrpc




-- 
Joseph Lorenzo Hall
Chief Technologist, Cent=
er for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC=
 20005-3497
e: joe@cdt.=
org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D=
7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871

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


--001a1147121e2488f0053f216f5e--


From nobody Tue Oct 18 07:59:37 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8745B12967B for ; Tue, 18 Oct 2016 07:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6EfBK32EQwm for ; Tue, 18 Oct 2016 07:59:34 -0700 (PDT)
Received: from mail.article19.io (mail.article19.io [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE60129682 for ; Tue, 18 Oct 2016 07:59:33 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id C30F411583BAD for ; Tue, 18 Oct 2016 14:59:31 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id B280A12A5C00B for ; Tue, 18 Oct 2016 14:59:31 +0000 (UTC)
Received: from [192.168.1.78] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 9FBFB11583BAD for ; Tue, 18 Oct 2016 14:59:31 +0000 (UTC)
To: hrpc@irtf.org
References: <147603046639.30603.1999554475476570569.idtracker@ietfa.amsl.com> <20161014151328.aofaigf5byraghzf@nic.fr>
From: Niels ten Oever 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Tue, 18 Oct 2016 16:59:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161014151328.aofaigf5byraghzf@nic.fr>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N0qeHJQvqO0wrmnxhMLvi8p3HfoV8aVKB"
Archived-At: 
Subject: Re: [hrpc] I-D Action: draft-irtf-hrpc-research-01.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 14:59:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--N0qeHJQvqO0wrmnxhMLvi8p3HfoV8aVKB
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Stephane,

Reply inline:

On 10/14/2016 05:13 PM, Stephane Bortzmeyer wrote:
> On Sun, Oct 09, 2016 at 09:27:46AM -0700,
>  internet-drafts@ietf.org  wrote=20
>  a message of 53 lines which said:
>=20
>>         Title           : Research into Human Rights Protocol Consider=
ations
>>         Authors         : Niels ten Oever
>>                           Corinne Cath
>> 	Filename        : draft-irtf-hrpc-research-01.txt
>=20
> IMHO, it is more or less ready for a Last Call in this group. We do
> not try to have an important protocol on the Standards Track, which
> would require a perfect document. We are trying to document something
> which was never explicit before, the fact that apparently technical
> decisions have consequences for human rights. IMHO, this is more
> important than trying to have a perfect RFC. I suggest we worked on it
> long enough. Stephen Farrell's remarks
> 
> were good and interesting but I do not think they are a pre-requisite
> for the Last Call.
>=20
> However, I would be glad if some issues were really addressed. For
> instance, I still do not find a clear definition of "public space"
> (this is related to the dDoS discussion), despite
> ,

Have been puzzling with this, removing public space seemed the easiest
way out, without getting into a new rabbit hole. What I have now is:


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


> the text about script encoding is still unclear despite
> ...
>=20

Would this work:

Does your protocol have text strings that have to be understood or
entered by humans? Does your protocol allow Unicode encoded in UTF-8
only? If other character sets or encodings are allowed, does your
protocol mandate a proper tagging of the charset? Did you have a look at
{{RFC6365}}?

Cheers,

Niels

> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


--N0qeHJQvqO0wrmnxhMLvi8p3HfoV8aVKB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYBjjTAAoJEAi1oPJjbWjp0lAH/0imzKwVDQv8tvyvhpx8GJz7
tmHFaVVZ/ZKe/U3sEV+4wMd4FKDrz2YjCfBp1RFHuzfBSn9xe6mnZW94erxuHUYs
VLm4S202ByfELUIF7r2l2iouFWV5aoFPiVUHnixoIdNyVLJME6OzlcAg3rfWeNJw
4EcaG3fIm6wfA82aCdySVBE8gTLo3tE4y1xpfsuhUOfxBtCavDc78BUsqnSxWNUl
YPbGhhzGg0noAtfBzQWFqmjsB4x/YRPYdGnWbJ3MyHxnEonUUyZJIUqkmKcRwqWf
iSjIJ1oDs/omCCJmrhaD+ClegnmZGlfu0UMdfHuKQlaVF6sK/7X3TATS6SF3ZrQ=
=/6d5
-----END PGP SIGNATURE-----

--N0qeHJQvqO0wrmnxhMLvi8p3HfoV8aVKB--


From nobody Tue Oct 18 08:15:01 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6159D1294C0 for ; Tue, 18 Oct 2016 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-t3mIl4q1Xw for ; Tue, 18 Oct 2016 08:14:58 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD269127A91 for ; Tue, 18 Oct 2016 08:05:41 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id x128so23227169ybg.1 for ; Tue, 18 Oct 2016 08:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tIJXAeQsHrTtc4rXDB6M8ZFwXMpqNSSAdwfdNJ1XQF8=; b=dTRGt208VgD6njPQhvNkhT74utTsN6yum2BQ0eNk8RJkjaSqBof7moRzvYe2xEszhM Vd3er0TW8L70tvFBnL3qodr3W+FtlW3MJlrreNlkpzAw6o0CxlzPZLfM+5Y/bdcxUFen sfBM2bj8EkdAkwGRAzGInLKEuzGlq8qVijfi3mFuSEQMsy+lnRxlbBmWjqNbqLUE+LIA 1dOUVIPAUTNAxBNH1FN0gK4zwFZgZ50zlpdTPoyiopKcCHA6j3JpP4FTIS3itTfZdjvb E7KbLQzQcR3H/ximnl9hufpMdykgFxNaKmYlyK6PlCvm94LY13iRAOvZPJj3eR84Aeo9 VyrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tIJXAeQsHrTtc4rXDB6M8ZFwXMpqNSSAdwfdNJ1XQF8=; b=ItVB1AjMhYBYpkfZ3/FNVufntC7fahHVfypz874SYAfAoLhQIVV3ZJcwD1LMZ/U0Dg d8NsmyauAp2g/U6jSplx6QHeSGWryaFhc3ciigkjmK/K/ZrKvhJUPgq1pKfWoGjhhinA kc9icCf3rktXf6fJajgBzgc+vcHiDds8mVPMD7ymImt7DcPDl7ZDSIs7NmTQac2VYJ4I MncZBAXXwUsRIH6kuWpn7Jflt6seZ4j/uNxXMo179Xi3kocRzNmEywQEeWicoOqCeT7Q JHTRqsFGj6zEcllgSvaVWpF1AXYJ8TSdKAww9MzlCLmadNWn8nXznOH4aAIC1gRQS95k 9gpw==
X-Gm-Message-State: AA6/9RmW+Oox20EkyPsj/FdZQPpArJ5ut3QnDVGSGXfidwr+DS7vbZI2+l71euJ7FHcA0GmOTyXd9itqYjM/RA==
X-Received: by 10.37.208.130 with SMTP id h124mr1048027ybg.25.1476803140990; Tue, 18 Oct 2016 08:05:40 -0700 (PDT)
MIME-Version: 1.0
Sender: cattekwaad@gmail.com
Received: by 10.37.60.133 with HTTP; Tue, 18 Oct 2016 08:05:39 -0700 (PDT)
In-Reply-To: 
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <93327a79-ca3e-3980-9753-98e9fedee4f4@acm.org> 
From: Corinne Cath 
Date: Tue, 18 Oct 2016 16:05:39 +0100
X-Google-Sender-Auth: ECuk-98CKkFlAjAt9y2dSysQaGU
Message-ID: 
To: Joseph Lorenzo Hall 
Content-Type: multipart/alternative; boundary=94eb2c05552a9f60f7053f2506ae
Archived-At: 
Cc: "avri@acm.org" , "hrpc@irtf.org" 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 15:15:00 -0000

--94eb2c05552a9f60f7053f2506ae
Content-Type: text/plain; charset=UTF-8

+1 to Joe's +1

On Tue, Oct 18, 2016 at 11:48 AM, Joseph Lorenzo Hall  wrote:

> +1 to starting RGLC soon
>
>
> On Saturday, October 15, 2016, avri doria  wrote:
>
>>
>>
>> On 15-Oct-16 15:17, Stephen Farrell wrote:
>> >  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:-).
>> > >>
>>
>> Personally, given the importance I find in this bit of work, I think the
>> greater value is in finding rough consensus, not in getting something
>> out quickly.  I think there are lots of ways to get research published,
>> and the value of an IRTF RFC is partly in the rough consensus it involves.
>>
>> The question, though may involve finding out where the rough lies.  I
>> think the work needs wider exposure and it is possible that a RGLC may a
>> good way to determine that with a wider audience.  One of the things I
>> have noticed with my own work in RGs in the past, is that sometimes it
>> takes more than 1 RGLC to get to the rough consensus point, so assuming
>> that enough people think that a RGLC is warranted, it may be worth
>> calling one.
>>
>> Still looking for more opinions, more feedback and more discussion on
>> the points Stephen is making.
>>
>> avri
>>
>>
>> avri
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org
> ]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>
> Tech Prom, CDT's Annual Dinner, is April 20, 2017!
> https://cdt.org/annual-dinner
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>
>


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

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: ccath@turing.ac.uk & corinnecath@gmail.com
Twitter: @C_Cath

--94eb2c05552a9f60f7053f2506ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 to Joe's +1 
<=
br>
On Tue, Oct 18, 2016 at 11:48 AM, Joseph Lore=
nzo Hall <joe@cdt.org> wrote:
+1=
 to starting RGLC soon
=


On Saturday, October 15, 2016, avri doria <avri@acm.org> wrote:




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

>=C2=A0 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 neces=
sarily

> >> 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 tha=
t

> >> latter plan but just wanted to ask in case it helps the RG (a=
nd

> >> Avri who I guess will have the fun of figuring this out:-).
> >>



Personally, given the importance I find in this bit of work, I think the
greater value is in finding rough consensus, not in getting something

out quickly.=C2=A0 I think there are lots of ways to get research published=
,

and the value of an IRTF RFC is partly in the rough consensus it involves.<=
br>


The question, though may involve finding out where the rough lies.=C2=A0 I<=
br>
think the work needs wider exposure and it is possible that a RGLC may a
good way to determine that with a wider audience.=C2=A0 One of the things I=


have noticed with my own work in RGs in the past, is that sometimes it

takes more than 1 RGLC to get to the rough consensus point, so assuming

that enough people think that a RGLC is warranted, it may be worth

calling one.



Still looking for more opinions, more feedback and more discussion on

the points Stephen is making.



avri





avri





---

This email has been checked for viruses by Avast antivirus software.

https://www.a=
vast.com/antivirus



_______________________________________________

hrpc mailing list

hrpc@irtf.org

ht=
tps://www.irtf.org/mailman/listinfo/hrpc




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

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


_______________________________________________

hrpc mailing list

hrpc@irtf.org

https://www.irtf.org/mailman/listinfo/hrpc





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

=
Web: www.oii.ox.ac.uk/people/corinne-cat=
h 
Email: cc=
ath@turing.ac.uk & corinnecath@gmail.com
Twitter: @C_Cath
=





--94eb2c05552a9f60f7053f2506ae--


From nobody Tue Oct 18 08:57:35 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9E012945E for ; Tue, 18 Oct 2016 08:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgCV7FCNSlXI for ; Tue, 18 Oct 2016 08:57:31 -0700 (PDT)
Received: from mail.article19.io (mail.article19.io [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A887C1295B0 for ; Tue, 18 Oct 2016 08:57:30 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 3A7691624A0A; Tue, 18 Oct 2016 15:57:29 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 2ABC285D612A; Tue, 18 Oct 2016 15:57:29 +0000 (UTC)
Received: from [192.168.1.78] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id EBFC01624A0A; Tue, 18 Oct 2016 15:57:28 +0000 (UTC)
From: Niels ten Oever 
To: Stephen Farrell , hrpc@irtf.org
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
X-Enigmail-Draft-Status: N1110
Message-ID: <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>
Date: Tue, 18 Oct 2016 17:57:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X2gu7Qro6WmTo3NDsHjh6GfbtrQAt5xvx"
Archived-At: 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 15:57:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--X2gu7Qro6WmTo3NDsHjh6GfbtrQAt5xvx
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Stephen,

Reply inline:

On 10/15/2016 03:17 PM, Stephen Farrell wrote:
>=20
> Hi Niels,
>=20
> On 09/10/16 17:31, 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 argument=
s
>> 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
>=20
> Great thanks. I'll respond only to the more general points in
> this mail. I'll send a response to the rest later.
>=20
>>
>> 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!
>=20
> Well, the RG has yet to produce any RFCs so I'm not clear
> that there's a bar we're lowering or raising. In any case
> this was just a suggestion for Avri to consider so we need
> say no more.
>=20
>>
>>> (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 i=
t
>> 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.
>=20
> Sorry, that's non-responsive to the main point: this is too
> long and the bit that's important for the claimed audience
> (IETFers) is buried at the end. I still suggest making that
> structural change. Why not?

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

>=20
>>
>>
>>> (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 =E2=80=93 as it=
 pertains
>> to the remit of the IETF. Would it be better if the first mention of t=
he
>> word architecture came with the following clarification: =E2=80=98Inte=
rnet
>> architecture is a catch-all phrase. In order to ensure it does not rin=
g
>> hollow we want to clarify what we mean by this term. Our definition is=

>> partly based on the consensus understanding of the term architecture a=
s
>> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many membe=
rs 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=E2=80=
=99.
>> 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.=E2=80=99=
 Would
>> such a definition clarify our use of the word architecture sufficientl=
y?
>=20
> No, I think that's worse tbh, as will any attempt to define "the
> Internet architecture" most likely. Others may disagree but I think
> by far the best thing here is to remove as many uses of the term as
> possible and to carefully say exactly what's meant in any remaining
> cases (and I bet you'll find remaining cases mean different things).
>=20

Why is it worse?

>>
>> Additionally, we would like to push back a bit against the argument th=
at
>> because there is no consensus in the IETF on what the term architectur=
e
>> means, we cannot use it in the text. The IRTF should be the space wher=
e
>> 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.
>=20
> Sorry, "pushing boundaries" is just fine, but one is not doing that
> by using ill-defined terms in ill-defined ways. I also don't think
> hrpc is a good venue for trying to define this particular term, nor
> do I think such an activity is interesting or fruitful. Much better
> to avoid use of the ill-defined term where it's not needed, which
> is almost everywhere IMO.
>=20

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

>>
>>
>>> (4) What does "=3D" mean here?
>>>
>>> In section 2 and later (in 5.2.2) you have diagrams with
>>> bracketed terms on the left, then "=3D" and then another term on
>>> the right. I just don't get what you mean by that "=3D" 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,
>=20
> Correct:-)
>=20
>> 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 we=
ll
>> as authenticity.
>=20
> No, the security model of TLS does not include anonymity. The security
> model of Tor does. It's important to be precise like that I think in
> this document. These uses of "=3D" or "=3D=3D=3D>" are nowhere near pre=
cise IMO.
>=20

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

>>
>> I think it can easily be argued than in many models of security, priva=
cy
>> and anonymity play a role, in others anonymity may be less important.
>=20
> It can be argued yes. That argument is wrong where it comes to
> anonymity which is a very very hard goal to even approach.
>=20
>>
>> To reflect this I changed the text to:
>>
>> A combination of reliability, confidentiality, integrity, anonymity, a=
nd
>> authenticity is what makes up security on the Internet.
>=20
> I think that is still plain wrong in multiple ways, but certainly
> wrt anonymity.
>=20

Why? Because anonymity is never part of any definition or concept of
security? That doesn't make sense to me.
>>
>> I also changed the '=3D' in to an '=E2=87=92'
>>
>=20
> Not using "=3D" is a minor editorial improvement.
>=20


OK

>>
>>> 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 "=3D" 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 betwee=
n
>> the LHS and the RHS should be 'contribute to an enabling environment
>> for', so I replaced the '=3D' with '=E2=87=92' and added an explanatio=
n.
>=20
> TBH, I think those diagrams have outlived their usefulness and
> could just be deleted or moved to an appendix only about the
> method used in this work that does not claim that these relations
> are well defined. (See also my point (2) above about structure.)

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


>=20
>>>
>>> (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 analys=
is
>> a case of technology and it's impact human rights. So, it has a
>> completely different role from RFC3552, even though the conclusions ar=
e
>> largely the same.
>=20
> That is non-responsive to the main point here. The scope of
> the DDoS discussion is still wrong. Can you respond to the
> main point?
>=20

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

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



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



>>
>>
>>> (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 presente=
d
>> the outcomes at the session in Berlin and were also posted to the list=
=2E
>=20
> Can you send links to those please? I don't recall those as having
> used the questions as listed but I may be mis-remembering. I still
> find some of the questions non-useful for the intended audience
> but of course I may be wrong or an outlier there.
>=20

Presentation of Shane and Giovane at IETF:

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF96_HRPC&c=
hapter=3Dchapter_1

their earlier emails to the list:

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

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

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

>>
>>> (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 n=
o
>> consensus in the law community about how this should be done. There ar=
e
>> many scholarly papers written about this, and I would large go with th=
e
>> approach in the UN Guiding Principles for Business and Human Rights. S=
o
>> 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.
>=20
> I like that text, thanks. I'd suggest adding a bit of text to
> cover what I think might be a misinterpretation that could be
> common for the more literal-minded typical IETFer such as
> myself:-) Something like:
>=20
> "The fact that rights can always be in conflict with one another
> means that all human rights are contingent and none are absolute.

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

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

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

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

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

Cheers,

Niels

>=20
>>
>>> Specific comments (without reference to importance:-)
>=20
> Will get back to these later, when I get time.
>=20
> Cheers,
> S.
>=20
>=20
>=20



--X2gu7Qro6WmTo3NDsHjh6GfbtrQAt5xvx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYBkZnAAoJEAi1oPJjbWjpz/kH/0lym3wg8vhNvelHwhxUMg8X
9VV72sSYuMv/lbn0anaRALAzryLS2LlWeifgRUao/tFxNWi37zgDR9kFJ/0DisRu
IgjZhrCrM8cPq3RyycVbq15rhTG29C8sFb63CSbqf0R0I4lDFGDXCJsXPE2TdhbB
350PUxA6mDwAxodKd8TZo77oHiDF67R/JZ/tR/p037xQ537RWkXtYkxNCNqlaM2Z
Wg5Lpnpp4jWptgpi0T50aYfnAXBIfUtQTe2OBgBb2ea951zZuIAULa50xJI2i1pj
c1dcE4Ba+2Bh8ZeX9VPzkYqKNbvyxDf0UoPFe06eXBFqMnY6Gd9h6I0fHUsU1z0=
=cUs4
-----END PGP SIGNATURE-----

--X2gu7Qro6WmTo3NDsHjh6GfbtrQAt5xvx--


From nobody Tue Oct 18 09:02:38 2016
Return-Path: 
X-Original-To: hrpc@irtf.org
Delivered-To: hrpc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2A1296B8; Tue, 18 Oct 2016 09:02:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.35.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147680655733.30835.9185151793035956379.idtracker@ietfa.amsl.com>
Date: Tue, 18 Oct 2016 09:02:37 -0700
Archived-At: 
Cc: hrpc@irtf.org
Subject: [hrpc] I-D Action: draft-irtf-hrpc-research-02.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 16:02:37 -0000

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

        Title           : Research into Human Rights Protocol Considerations
        Authors         : Niels ten Oever
                          Corinne Cath
	Filename        : draft-irtf-hrpc-research-02.txt
	Pages           : 68
	Date            : 2016-10-18

Abstract:
   This document provides a proposal for a vocabulary to discuss the
   relation between human rights and Internet protocols, an overview of
   the discussion in technical and academic literature and communities,
   a proposal for the mapping of the relation between human rights and
   technical concepts, and a proposal for guidelines for human rights
   considerations, similar to the work done on the guidelines for
   privacy considerations [RFC6973].

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  This documents aims to be a consensus
   document of the Human Rights Protocol Consideration Research Group of
   the Internet Research Task Force (IRTF).

   Discussion of this draft at: hrpc@irtf.org //
   https://www.irtf.org/mailman/listinfo/hrpc


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-hrpc-research-02

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


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

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


From nobody Tue Oct 18 09:38:15 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8611296CF for ; Tue, 18 Oct 2016 09:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.732
X-Spam-Level: 
X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aXa_rZucj7r for ; Tue, 18 Oct 2016 09:38:11 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD581296C3 for ; Tue, 18 Oct 2016 09:38:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61918BE2E; Tue, 18 Oct 2016 17:38:08 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaTvUmOeC_s2; Tue, 18 Oct 2016 17:38:08 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C29BEBE2C; Tue, 18 Oct 2016 17:38:07 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476808688; bh=XQd2mjL3jRAfKmUD/3eFxRuVmlKNcRz6Yk7g1p1w6us=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UUickZGkhU4T9Xfkap1cXhP8JyIwQrtqhYv7HubDcf0OPiXDOOIYWQSEtgXCw19No XIQ5I+7rU7nXu/59wjQepeccyTbRI9Tii8dOSKmXnnukmutkWt+gmDUxkfr3Qxcim4 avL7F2kMwlOwsfeMvqy0XkrelXYbgy96sPuvGd/I=
To: Niels ten Oever , hrpc@irtf.org
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie>
Date: Tue, 18 Oct 2016 17:38:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ka1nLKTH7jQhSTkuw5QgLqjVDX5CUejrF"
Archived-At: 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 16:38:15 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ka1nLKTH7jQhSTkuw5QgLqjVDX5CUejrF
Content-Type: multipart/mixed; boundary="i3cFS7D8K3tI1coXdcH8ojO8fMKHUqGxR";
 protected-headers="v1"
From: Stephen Farrell 
To: Niels ten Oever , hrpc@irtf.org
Message-ID: <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie>
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
References: 
 
 <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
 <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>
In-Reply-To: <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>

--i3cFS7D8K3tI1coXdcH8ojO8fMKHUqGxR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

(trimming bits....)

On 18/10/16 16:57, Niels ten Oever wrote:
> Hi Stephen,
>=20
> Reply inline:
>=20
> On 10/15/2016 03:17 PM, Stephen Farrell wrote:
>>
>> Hi Niels,
>>
>> On 09/10/16 17:31, Niels ten Oever wrote:
>>> Hi Stephen,
>>>

>>>> (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 i=
t
>>> would be great to come up with next steps for 5.3.2, such as bringing=
 it
>>> into the IETF.
>>
>> Sorry, that's non-responsive to the main point: this is too
>> long and the bit that's important for the claimed audience
>> (IETFers) is buried at the end. I still suggest making that
>> structural change. Why not?
>=20
> Because the authors intend to produce a seperate document geared
> completely at providing considerations.

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

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


>>>> (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 ar=
e
>>> referring to the technical functioning of the Internet =E2=80=93 as i=
t pertains
>>> to the remit of the IETF. Would it be better if the first mention of =
the
>>> word architecture came with the following clarification: =E2=80=98Int=
ernet
>>> architecture is a catch-all phrase. In order to ensure it does not ri=
ng
>>> hollow we want to clarify what we mean by this term. Our definition i=
s
>>> partly based on the consensus understanding of the term architecture =
as
>>> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many memb=
ers of the
>>> Internet community would argue that there is no architecture, but onl=
y 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 th=
e
>>> 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 divers=
e
>>> hardware providing global connectivity is the "end to end argument=E2=
=80=99.
>>> Building on RFC1958 we hold that the word architecture, in the contex=
t
>>> 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.=E2=80=99=
 Would
>>> such a definition clarify our use of the word architecture sufficient=
ly?
>>
>> No, I think that's worse tbh, as will any attempt to define "the
>> Internet architecture" most likely. Others may disagree but I think
>> by far the best thing here is to remove as many uses of the term as
>> possible and to carefully say exactly what's meant in any remaining
>> cases (and I bet you'll find remaining cases mean different things).
>=20
> Why is it worse?

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

>=20
>>>
>>> Additionally, we would like to push back a bit against the argument t=
hat
>>> because there is no consensus in the IETF on what the term architectu=
re
>>> means, we cannot use it in the text. The IRTF should be the space whe=
re
>>> we can push the boundaries on that discussion, bringing in definition=
s
>>> from academia as we do in the text by referring to amongst others the=

>>> work of Prof. Denardis and Prof. Bowker on architecture.
>>
>> Sorry, "pushing boundaries" is just fine, but one is not doing that
>> by using ill-defined terms in ill-defined ways. I also don't think
>> hrpc is a good venue for trying to define this particular term, nor
>> do I think such an activity is interesting or fruitful. Much better
>> to avoid use of the ill-defined term where it's not needed, which
>> is almost everywhere IMO.
>>
>=20
> Well, we're providing references to infrastructure scholars, so am not
> so sure about ill-defined. Could you be a bit more precise in your
> objection?

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

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

>=20
>>>
>>>
>>>> (4) What does "=3D" mean here?
>>>>
>>>> In section 2 and later (in 5.2.2) you have diagrams with
>>>> bracketed terms on the left, then "=3D" and then another term on
>>>> the right. I just don't get what you mean by that "=3D" 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,
>>
>> Correct:-)
>>
>>> would
>>> be: depends on the usecase. If we for instance take the example of TL=
S
>>> for .onion websites, there the security model includes anonymity as w=
ell
>>> as authenticity.
>>
>> No, the security model of TLS does not include anonymity. The security=

>> model of Tor does. It's important to be precise like that I think in
>> this document. These uses of "=3D" or "=3D=3D=3D>" are nowhere near pr=
ecise IMO.
>>
>=20
> Because a function arrow doesn't seem in place here, or...?

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

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

>>
>> It can be argued yes. That argument is wrong where it comes to
>> anonymity which is a very very hard goal to even approach.
>>
>>>
>>> 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 think that is still plain wrong in multiple ways, but certainly
>> wrt anonymity.
>>
>=20
> Why? Because anonymity is never part of any definition or concept of
> security? That doesn't make sense to me.

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

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

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


>>>> 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 "=3D" 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 betwe=
en
>>> the LHS and the RHS should be 'contribute to an enabling environment
>>> for', so I replaced the '=3D' with '=E2=87=92' and added an explanati=
on.
>>
>> TBH, I think those diagrams have outlived their usefulness and
>> could just be deleted or moved to an appendix only about the
>> method used in this work that does not claim that these relations
>> are well defined. (See also my point (2) above about structure.)
>=20
> I think they have a clear role in the methodology as described, and
> therefore fit in this research document.

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

>=20
>=20
>>
>>>>
>>>> (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 analy=
sis
>>> a case of technology and it's impact human rights. So, it has a
>>> completely different role from RFC3552, even though the conclusions a=
re
>>> largely the same.
>>
>> That is non-responsive to the main point here. The scope of
>> the DDoS discussion is still wrong. Can you respond to the
>> main point?
>>
>=20
> I thought I responded to your main point, could you else rephrase it? I=
t
> also rewrote it a bit, maybe that helps:
>=20
> DDoS attacks can thus stifle freedom of expression, complicate the
> ability of independent media and human rights organizations to exercise=

> their right to (online) freedom of association, while facilitating the
> ability of governments to censor dissent.  When it comes to comparing
> DDoS attacks to protests in offline life, it is important to remember
> that only a limited number of DDoS attacks involved solely willing
> participants. In most cases, the clients are hacked computers of
> unrelated parties that have not consented to being part of a DDoS (for
> exceptions see Operation Abibil {{Abibil}} or the Iranian Green Movemen=
t
> DDoS {{GreenMovement}}). In addition, DDoS attacks are increasingly use=
d
> as an extortion tactic.
>=20
>=20
>=20
> All of these issues seem to suggest that the IETF should try to ensure
> that their protocols cannot be used for DDoS attacks, which is
> consistent with the long-standing IETF consensus that DDoS is an attack=

> that protocols should mitigate them to the extent they can {{BCP72}}.
> Decreasing the number of vulnerabilities in protocols and (outside of
> IETF) the number of bugs in the network stacks of routers or computers
> could address this issue. The IETF can clearly play a role in bringing
> about some of these changes but the IETF cannot be expected to take a
> positive stance on (specific) DDoS attacks, or create protocols to
> enable some attacks and inhibit others. What the IETF can do is
> critically reflect on its role in the development of the Internet, and
> how this impacts the ability of people to excercise their human rights,=

> such as freedom of expression.

Ok, fair enough, that is better.

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

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

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

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

>>>> (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 present=
ed
>>> the outcomes at the session in Berlin and were also posted to the lis=
t.
>>
>> Can you send links to those please? I don't recall those as having
>> used the questions as listed but I may be mis-remembering. I still
>> find some of the questions non-useful for the intended audience
>> but of course I may be wrong or an outlier there.
>>
>=20
> Presentation of Shane and Giovane at IETF:
>=20
> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF96_HRPC=
&chapter=3Dchapter_1
>=20

Didn't have time for that sorry.

> their earlier emails to the list:
>=20
> https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi4

Quoting from that:

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

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

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

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


>>>> (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 a=
re
>>> many scholarly papers written about this, and I would large go with t=
he
>>> 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 righ=
t
>>> to freedom of expression and the right to privacy. In such as case th=
e
>>> 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 proces=
s
>>> tangible and practical for protocol developers is what this research
>>> aims to ultimately contribute to.
>>
>> I like that text, thanks. I'd suggest adding a bit of text to
>> cover what I think might be a misinterpretation that could be
>> common for the more literal-minded typical IETFer such as
>> myself:-) Something like:
>>
>> "The fact that rights can always be in conflict with one another
>> means that all human rights are contingent and none are absolute.
>=20
> This is not true. Torture is for instance always prohibited. We would
> get here into concepts of proportionality and necessity (and perhaps
> even legal accountability), which would imho only make the text more,
> not less complex for literal-minded types (and the non-literal-minded
> types alike).

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

>=20
>> So, for example, if one posited a "right to encrypt" as a human
>> right that inherently means accepting that there are times when
>> that "right" would lose out in balancing of conflicting rights.
>> That means that there are technical concepts (e.g. arithmetic,
>> the ability to write code), the free exercise of which may be
>> better protected if they are not specifically claimed as human
>> rights."
>=20
> I see what you're trying to do here, but I think this is for another
> document.

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

Cheers,
S.

>=20
>>
>> (As an aside, it's interesting that you are sensitive here to
>> the difficultly of establishing consensus on this topic, whereas
>> I am not. And then we reverse roles when it comes to "Internet
>> architecture." Not that surprising I guess:-)
>=20
> Well, there seems to be more consensus on Internet architecture than
> this, at least as far as I could find, but am happy to be convinced (in=

> both cases).
>=20
> Cheers,
>=20
> Niels
>=20
>>
>>>
>>>> Specific comments (without reference to importance:-)
>>
>> Will get back to these later, when I get time.
>>
>> Cheers,
>> S.
>>
>>
>>
>=20
>=20
>=20
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


--i3cFS7D8K3tI1coXdcH8ojO8fMKHUqGxR--

--Ka1nLKTH7jQhSTkuw5QgLqjVDX5CUejrF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYBk/vAAoJEC88hzaAX42iJysH/RUlCSR7WTWkVaLuR8UZLdDi
Z7l9azQfcWsfc8KtXkGkqPof2YRjsUdjSXKEbkunhLtkRQGox35ybVemRTSuxCy3
Z6udGICsqxVu1HNnQFCPB+qTxpuOBx9HeHwaPQNVjwpARyOyIIcIKtsjTBRZ7ti8
snJkf0YudbOk6NBkqE3Sll1qwE9r9q946+945LphH/KoSCOkHQMO6J5N6REa3k+Z
8DnXXZy6GKbC8kWdibeOqcRbVQme+kzS02+GI+DYTjyXYGZfr6MQisNkRuR0SJyv
ibdqVgYSbllDrBAILXCXB1M79k/9TNpEM/6AzlbiK2QMb/zmdMdA7oeVrCpXIvo=
=hMyl
-----END PGP SIGNATURE-----

--Ka1nLKTH7jQhSTkuw5QgLqjVDX5CUejrF--


From nobody Tue Oct 18 12:04:36 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4B4129482 for ; Tue, 18 Oct 2016 12:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxL6XOZ0ulfn for ; Tue, 18 Oct 2016 12:04:32 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF70D128E18 for ; Tue, 18 Oct 2016 12:04:32 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id t192so2107734ywf.0 for ; Tue, 18 Oct 2016 12:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=izSR/dO/xwmUCC7mgya5+YX1W698ISmkfZx/teZtWD4=; b=VCe5hQtcog6wVG2Mg4lgwe/vqottODv+O8frgRG+v61oD0PktE8DKV0Uhj+uYctGEd 8A+XGagbwUnfwmsjcE6H9otnZF5saNUHKOn4ZEM7Drfg/Oa/bu5+bJhMD+X/CqLWUKxx cL/gJRJcayrk3NLR96w6l76/ijKn1zOtSTR9I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=izSR/dO/xwmUCC7mgya5+YX1W698ISmkfZx/teZtWD4=; b=C1pN6RAUz/dzRdm83gWkfL1jC97f8rzRQgFTzx6NahlWMdK4TV9hkG6+NDU7Pi6c62 JpDeVVvhen3aBxrT+w28BHDyoBdCBNLXFVnKZmfb7cpzSZVM2alh7JwPzpYeydaWcZAk 2su+cq+LknlXgZAT7IL4N3/VkY8sQ8aNTdBTo6TZbyHL/ebxHWrYJM5GBHUsGnLUfivC OQPZqwBOAdMEkofosTH1vj2OwKYkzHfp9+WSieo1FsX0YrJDDU60ZVzq+vhCQeN9jSZT MGfsq4pX1NUc9wDjxL58PnsRp3+uSlVeWjpY39ivQyfuYufePW402S/MZI5CisJ1BP/l qoog==
X-Gm-Message-State: AA6/9Rk0/2v1pnWYG75RBsI5iJ4+78hOJ1Y/0cRFxwWX4iL0v4e6cxrqRLFF5ue56n53hTImWzWrDjNd+i714vcO
X-Received: by 10.129.161.84 with SMTP id y81mr2028735ywg.347.1476817471834; Tue, 18 Oct 2016 12:04:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.70.212 with HTTP; Tue, 18 Oct 2016 12:04:11 -0700 (PDT)
In-Reply-To: <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>
From: Joseph Lorenzo Hall 
Date: Tue, 18 Oct 2016 15:04:11 -0400
Message-ID: 
To: Niels ten Oever 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: hrpc@irtf.org, Stephen Farrell 
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 19:04:34 -0000

On Tue, Oct 18, 2016 at 11:57 AM, Niels ten Oever  wro=
te:
>>>> 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 "=3D" 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 '=3D' with '=E2=87=92' and added an explanation=
.
>>
>> TBH, I think those diagrams have outlived their usefulness and
>> could just be deleted or moved to an appendix only about the
>> method used in this work that does not claim that these relations
>> are well defined. (See also my point (2) above about structure.)
>
> I think they have a clear role in the methodology as described, and
> therefore fit in this research document.

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

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

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

best, Joe

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

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


From nobody Tue Oct 18 14:39:36 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EE41298A9 for ; Tue, 18 Oct 2016 14:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.732
X-Spam-Level: 
X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lsd4oBGSqfYV for ; Tue, 18 Oct 2016 14:39:34 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D2C12989D for ; Tue, 18 Oct 2016 14:39:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5C3F3BE2E; Tue, 18 Oct 2016 22:39:32 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNALVm2mtlah; Tue, 18 Oct 2016 22:39:31 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8133BE2C; Tue, 18 Oct 2016 22:39:30 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476826771; bh=ULIbSK+Lm7q484ttZIHMGMfr/kWR6+diVCoFTCZDdPE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dfHspjfnW7mC1HVmWU8MVvWIGsXHxPkHAK3zmIXUj2Ja0wPwriYo4VVJsZVuq5SBn mcj4aJLp4i1cqdQ0Yh0sF3lbPI5syG0JXR2YQXxVtZVOAX1ITgYLOngxNmGMF+slxD C+V0R9Zw7k6+ezwnFAJ25yxK9DOFfcBfLl5UZg0A=
To: Joseph Lorenzo Hall , Niels ten Oever 
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <09181eec-0731-bf37-412d-a6e627367f2c@article19.org> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <16215f78-3d89-12d2-233e-119dd998ed93@cs.tcd.ie>
Date: Tue, 18 Oct 2016 22:39:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010309050600090402090301"
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Oct 2016 21:39:35 -0000

This is a cryptographically signed message in MIME format.

--------------ms010309050600090402090301
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 18/10/16 20:04, Joseph Lorenzo Hall wrote:
>=20
> Some combination of the concepts on the LHS support the concept on the =
RHS.

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

S.


--------------ms010309050600090402090301
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTgy
MTM5MzFaMC8GCSqGSIb3DQEJBDEiBCD9iCVwJOedhS423ONHyWa1DKj7PmVDHukOLljPaciK
TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQBtnpTvR91VBvVMIKIQmyQQK7rKpUflKpA56yOw1trY9T9B0ghs/CCu
XHTvWigIvUIxa2PSKBEoGSunPg1H9C/9Lgvvp5kvOfEqkUncADEJb6to3RIsg8wVVYgDaX9H
VcmT7y7/bZCT+Yl1MR2ih8I7JxrgvvTUYiqF7BEYwGwDOZBBqoSPFAkT89Luchk7MGkGg/x/
vob2CUwdvH7Y329nkF5tc1DEVFNfNnKswLjfHxhsCgl5EY/xMH6IoaV9wNrvY9btkIx6U38N
UYJF7pc7JwtUPyezd4y91gli4TnYQt7LjdTtGIE3e6mp3L4YrCrkk8ZGx44Fm0QIRghRs/ra
AAAAAAAA
--------------ms010309050600090402090301--


From nobody Thu Oct 20 05:16:35 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7965129560 for ; Thu, 20 Oct 2016 05:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Level: 
X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjMji9XNmkmh for ; Thu, 20 Oct 2016 05:16:29 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48E41298A6 for ; Thu, 20 Oct 2016 05:16:29 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E61B42806B5 for ; Thu, 20 Oct 2016 14:16:27 +0200 (CEST)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id E20F62806B4 for ; Thu, 20 Oct 2016 14:16:27 +0200 (CEST)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id E0371B38004 for ; Thu, 20 Oct 2016 14:15:57 +0200 (CEST)
Received: by b12.nic.fr (Postfix, from userid 1000) id DE37A3FFBF; Thu, 20 Oct 2016 14:15:57 +0200 (CEST)
Date: Thu, 20 Oct 2016 14:15:57 +0200
From: Stephane Bortzmeyer 
To: hrpc@irtf.org
Message-ID: <20161020121557.ic6cxhs52kuv7sgc@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Operating-System: Debian GNU/Linux stretch/sid
X-Kernel: Linux 4.7.0-1-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20160916 (1.7.0)
Archived-At: 
Subject: [hrpc] Inclusivity in domain names
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2016 12:16:32 -0000

A funny experience with IDN at the last DNS-OARC meeting or "the
Internet is not made for hieroglyphs":

https://indico.dns-oarc.net/event/25/session/8/contribution/1/material/slides/1.pdf


From nobody Thu Oct 20 06:40:55 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C1E129970 for ; Thu, 20 Oct 2016 06:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.732
X-Spam-Level: 
X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkEuBGG4narx for ; Thu, 20 Oct 2016 06:40:51 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF77129964 for ; Thu, 20 Oct 2016 06:40:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed;  h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:x-originating-ip:x-clientproxiedby; bh=aZixeNRThIYdx5r04E+RBsFmPLcRe9RVWm9IdcKUp2c=; b=HE9nWzA+PFUrxqQypantZJhxVQtNNFNwxw30BpM2n87jHhyET89TqmftLeTvHQz7KOTwaR5kODluxpkEchdYYTIh7JkXcSuyfxRtDEGSVRr6814nq7t3AMkaKBVyuYMoue5ZNvzpfxDYJDeMgDCrlU5xCi/iAR6qelo8+/7GJyKRtV7vD46o6kDz42zugu1evdiBTVjdGwzvlF445l0Vwd50b++AsCDiKVmMHKVS55UtJdd8Mz5/4DDPwNSLn0CqLWm1sIHIiT1uSv2mv0iGtzy+EnnSZDJqo7YsfXMEV94rD3yC16aSUzv7OhZjJaILk/YiOc4/nRhTo4h3xvBIMg==
Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl  with ESMTP id u9KDei8d008787-u9KDei8f008787 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 20 Oct 2016 15:40:44 +0200
Received: from dhcp162.sidnlabs.nl (94.198.159.162) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 20 Oct 2016 15:40:44 +0200
To: 
References: <20161020121557.ic6cxhs52kuv7sgc@nic.fr>
From: "Marco Davids (SIDN)" 
Message-ID: 
Date: Thu, 20 Oct 2016 15:40:39 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Thunderbird/51.0a2
MIME-Version: 1.0
In-Reply-To: <20161020121557.ic6cxhs52kuv7sgc@nic.fr>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090203010909090604070100"
X-Originating-IP: [94.198.159.162]
X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177)
X-FEAS-SPF: 2 / 2, ip=94.198.159.162, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl
Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.162 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl
Archived-At: 
Subject: Re: [hrpc] Inclusivity in domain names
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2016 13:40:53 -0000

--------------ms090203010909090604070100
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Nice! :-)

Reminds me of this one though:

https://lists.isc.org/pipermail/bind-users/2016-October/097841.html

--
Marco


On 20/10/2016 14:15, Stephane Bortzmeyer wrote:
> A funny experience with IDN at the last DNS-OARC meeting or "the
> Internet is not made for hieroglyphs":
>=20
> https://indico.dns-oarc.net/event/25/session/8/contribution/1/material/=
slides/1.pdf


--------------ms090203010909090604070100
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CucwggT9MIID5aADAgECAhBEhHBK+ywnjF/Ez19KUgEnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwNTEwMjAyMzI5WhcNMTcwNTEwMjAyMzI5WjBEMR0wGwYDVQQDDBRtYXJj
by5kYXZpZHNAc2lkbi5ubDEjMCEGCSqGSIb3DQEJARYUbWFyY28uZGF2aWRzQHNpZG4ubmww
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDI2yA2kvqV+Ul/x++/XWCzYEtrZkfM
TQIRP1jlNKqhejnMKIo8NrGBvvsa5XaJPG8lHH+l/iKL9CSR0N0rcW7i+uKlFW1JWKm5D7bj
l4YBb3CttNxbrbpIYqUflbFwGvjxfF2dcimDdTFtsjUMdkEezjJLZQ0rtgWGW1q1dibNZtPb
zsCXrbYLQXxF8gbTRq4RkBzuaLxv+U1gd7sMLkmBpEgfYAf7BpA3dw2XgDUXmBCotzZnAk1k
ldysz2mRiW2m3+x2nHOGiZwb45E8ERdL4fzDIljH1ICtNVD6zBjyfrSJ0J3hAUTXkYIVWDbg
FEosWG0kH3y+ix8aPKqcKpT9AgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFJQEzlf9K5AY
a9hELugjjzxPCunxMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF
BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF
BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js
MB8GA1UdEQQYMBaBFG1hcmNvLmRhdmlkc0BzaWRuLm5sMCMGA1UdEgQcMBqGGGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH
AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB
AFmlkci6l6dzl5KDFniVok2aS4zYq7E1Eri7COGQeAmYLlZxy4L0XuzbQRSjMCElecnEMIUl
nB9y+7S3f4TePAFuEn7CkTWbEM1Ie62EasNkstQB81DiTJKr9sYC11Q6BuWc0GoiZK8iEv39
31nJ0One0autcTSn8nsRLoXfwbOFHYhWpliS4Ner6YNfgOt2Afpb4jVkwuJ93SpIeC409Jma
AhcP5j4i8mXKIsemIOAJYuAuCtWawEdIepgyQxFmrTo85Ok14gSO04hn0r0NflG/MQAhmQDY
eOllADQbWE0PLNrDmhW23YZ7kwnFe+TmtdT9CSbT6Dmfw2oLCBgegyYwggXiMIIDyqADAgEC
AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake
fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL
A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC
S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my
Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR
9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0
cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF
BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh
LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn
SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g
ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI
hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L
IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS
EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP
v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue
/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6
UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM
zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK
KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ
8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw
dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx
IENsaWVudCBDQQIQRIRwSvssJ4xfxM9fSlIBJzANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDIwMTM0MDM5WjAvBgkq
hkiG9w0BCQQxIgQgVf/v5RW3sTnFeYhsUbNsslp3TGl3rGgILg+gFkrX5sIwbAYJKoZIhvcN
AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB
BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw
JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh
cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEESEcEr7LCeMX8TPX0pSAScwgZwGCyqGSIb3DQEJ
EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD
VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD
b20gQ2xhc3MgMSBDbGllbnQgQ0ECEESEcEr7LCeMX8TPX0pSAScwDQYJKoZIhvcNAQEBBQAE
ggEAT+aASDHJhSDybt0qFG+ZgWUKUo+dXSI4W9qmn1xdGbp+VkfkeG+tt97AbMPoFPMM6Lcb
Ip/1DkvYvexwXUTWWfggyZOlqQLvHHCmqbnvDNwT6SCyT88KSCR92OL81rkCpzZAy1aSUfD3
dtlkovt/FRmNOTWVE1C73WaADQmza85eQpATARtlDL4FIlPSnPuui/eiBB5npN3dgErGLBEf
MJSY5rNB9VphAwFV5FIQuv0arlNJBWgISBMNjQEb9/U+UUvHQ9Cib7DGPpcWY0KN8GhkM12b
tIEqX/Ow73xZpYBEDMw7MivhAzCEN83TV8v9l//qW8LPa0xNIHHb5BOO+QAAAAAAAA==
--------------ms090203010909090604070100--


From nobody Thu Oct 20 07:00:25 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96955129612 for ; Thu, 20 Oct 2016 07:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwz-tqwd_qFF for ; Thu, 20 Oct 2016 07:00:16 -0700 (PDT)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92607129452 for ; Thu, 20 Oct 2016 07:00:07 -0700 (PDT)
Received: from [2001:470:78c8:2:8451:b161:196c:6f38] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bxDt3-0006mT-N9; Thu, 20 Oct 2016 14:00:02 +0000
Date: Thu, 20 Oct 2016 16:00:01 +0200
From: Shane Kerr 
To: "Marco Davids (SIDN)" 
Message-ID: <20161020160001.058081f9@pallas.home.time-travellers.org>
In-Reply-To: 
References: <20161020121557.ic6cxhs52kuv7sgc@nic.fr> 
X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/TYBfwXGEzIU5HtKdjKdzKXq"; protocol="application/pgp-signature"
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] Inclusivity in domain names
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2016 14:00:23 -0000

--Sig_/TYBfwXGEzIU5HtKdjKdzKXq
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Marco,

For those further interested in archeology, a little digging will find
the first traces of this in the RIPE DNS working group:

https://www.ripe.net/participate/mail/forum/dns-wg/PDIwMTYwNDIxMTUyNjQwLjJm=
ZmYwZjNjQHBhbGxhcy5ob21lLnRpbWUtdHJhdmVsbGVycy5vcmc+

I have no idea what "dig" will do on various systems. Don't try it as
root? ;)

Cheers,

--
Shane

At 2016-10-20 15:40:39 +0200
"Marco Davids (SIDN)"  wrote:

> Nice! :-)
>=20
> Reminds me of this one though:
>=20
> https://lists.isc.org/pipermail/bind-users/2016-October/097841.html
>=20
> --
> Marco
>=20
>=20
> On 20/10/2016 14:15, Stephane Bortzmeyer wrote:
> > A funny experience with IDN at the last DNS-OARC meeting or "the
> > Internet is not made for hieroglyphs":
> >=20
> > https://indico.dns-oarc.net/event/25/session/8/contribution/1/material/=
slides/1.pdf =20
>=20

--Sig_/TYBfwXGEzIU5HtKdjKdzKXq
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAlgIzeEACgkQMsfZxBO4kbTQigCfUZpdaK5NamzFtGgVwjOz/dyO
IX0AnROzJVzJ1QP2rfy0L3ZUe79kTQsn
=UHKX
-----END PGP SIGNATURE-----

--Sig_/TYBfwXGEzIU5HtKdjKdzKXq--


From nobody Thu Oct 20 07:21:55 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF01129475 for ; Thu, 20 Oct 2016 07:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjXerkwpys06 for ; Thu, 20 Oct 2016 07:21:51 -0700 (PDT)
Received: from nm24-vm4.bullet.mail.ne1.yahoo.com (nm24-vm4.bullet.mail.ne1.yahoo.com [98.138.91.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AA6129632 for ; Thu, 20 Oct 2016 07:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476973310; bh=Rpa6Ib3IzaUU2Uz+nb0CH7SOdDLn8SlcaUXUsB1gkZM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=OcSvl69d69eiqJ/L3UQKKBY0ockAbCkzJnbfzd8viPtRvx65UeNDwxTfSoS/GUl1VWIMCPn93BUhOerFM7UBJIcLpnupethc0wH3Z3AMrLP/P4mapFzRLQcN036orbHon6N4xam8IRqiS4UAJurBgTR0zg4XxLld/dL3vCaRfapdFJ0U5TJ3KLtNN0/kryy+O5JsFXtZjzVQY0xqvBGVtI3t2XR02JK3n/xT7DnKdvMBrghB7e/giwGyfsHeVvscPFg/HJp5zNowX7mwsdlO3NpcFqiwd3TYP+c0wOag8pyUc69raPW6uSn87onQQd2qAotK+9NT/DfdmA4el9Xvyw==
Received: from [98.138.226.179] by nm24.bullet.mail.ne1.yahoo.com with NNFMP;  20 Oct 2016 14:21:50 -0000
Received: from [98.138.226.163] by tm14.bullet.mail.ne1.yahoo.com with NNFMP;  20 Oct 2016 14:21:50 -0000
Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 20 Oct 2016 14:21:50 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 906271.84186.bm@omp1064.mail.ne1.yahoo.com
X-YMail-OSG: GVlfG1sVM1lctxmi60jOHzDJ97VlOxzN5e.u6qAezPhkK8oTfGsHEOxIlaQcRGW xp0pmGftkrMgHyCtLYnreBUWqyHSnG254l8GeRxvWwGNd8LmwP6OSY64umyi6aaoF64bne.BQiJA XBFRA0dxUvfHZOb5r_SiM.ztvgADkLO.9pH5QYXYAO_7ST4fKGOmJSYna2TOQ89ixg6q9QwS6T4O ZNyx.4rosiVbGFh5zP2O9qhLyVBIxt8sYKR7QJ0UaWaWwCJEz4k7JJEOLSG4UknfiVNhYZmDTr1g _C502kDUbumKzyHhXwguHIprEur2zHWxHhe.lQLjeoNXtbSbTrlw_0IpwXqIuADnuRbKoAijBYYn RDe1moigCq2oEpyu08mkow64A1LSJVYVPuYIbi3DoqOaN3TGOtb5rjhTTjguLgsWBtHyWvUYWwZ1 jijEQ3yuQ5bOH5ZkSY6YkqPX3mH4htsp20aroW1mLhM226Nq_VQTm0gMiU6uQ.8duTlLR8_iMzLb Ln65rQ.A32BeQVEMgwSyKgfUwOA.ML.bU8c.aqGH5mIezUA2Yt.2rtHi0.Sqw.fiOOpYGla4-
Received: from jws200121.mail.ne1.yahoo.com by sendmailws143.mail.ne1.yahoo.com; Thu, 20 Oct 2016 14:21:50 +0000; 1476973310.493
Date: Thu, 20 Oct 2016 14:21:49 +0000 (UTC)
From: 
To: Shane Kerr ,  "Marco Davids (SIDN)" 
Message-ID: <1986350435.336891.1476973309750@mail.yahoo.com>
In-Reply-To: <20161020160001.058081f9@pallas.home.time-travellers.org>
References: <20161020121557.ic6cxhs52kuv7sgc@nic.fr>  <20161020160001.058081f9@pallas.home.time-travellers.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "hrpc@irtf.org" 
Subject: Re: [hrpc] Inclusivity in domain names
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: nalini.elkins@insidethestack.com
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Oct 2016 14:21:54 -0000

Guys,

This discussion makes me think that there may be some interest in one thing that we are doing in Seoul (and of course, following on!)

We wanted to have a discussion in Seoul of "Deployment Challenges / Barriers to IDN - IEA" so that we could start documenting them and building a core group to carry on with this work.


This is an important issue for people who want to have email addresses in Hindi, Swahili, etc.  There is also much to discuss about the challenges of using domain names in non-English languages.

You may want to look at a draft that is the starting point of some of this work:


https://datatracker.ietf.org/doc/draft-elkchow-iea-deploy/?include_text=1
We will also be working on a document "Use Cases of Email Addresses".  Email addresses are used as "identities" in a number of instances.  For shopping, government, email lists, etc.  We may want to discuss this.

We plan to have a breakfast meeting at 8:00am Korea time on Thursday, November 17, 2016.  Remote access will be provided.


Please let me know if you are interested in participating in this discussion either live or remotely.  Replying to me unicast is just fine or on the list.  Whichever you prefer.

You may also wish to subscribe to the IMA@IETF.ORG email list, if you want to follow some of the discussions around these topics.

 
Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360



________________________________
From: Shane Kerr 
To: Marco Davids (SIDN)  
Cc: hrpc@irtf.org
Sent: Thursday, October 20, 2016 7:00 AM
Subject: Re: [hrpc] Inclusivity in domain names


Marco,

For those further interested in archeology, a little digging will find
the first traces of this in the RIPE DNS working group:

https://www.ripe.net/participate/mail/forum/dns-wg/PDIwMTYwNDIxMTUyNjQwLjJmZmYwZjNjQHBhbGxhcy5ob21lLnRpbWUtdHJhdmVsbGVycy5vcmc+

I have no idea what "dig" will do on various systems. Don't try it as
root? ;)

Cheers,

--
Shane

At 2016-10-20 15:40:39 +0200
"Marco Davids (SIDN)"  wrote:


> Nice! :-)
> 
> Reminds me of this one though:
> 
> https://lists.isc.org/pipermail/bind-users/2016-October/097841.html
> 
> --
> Marco
> 
> 
> On 20/10/2016 14:15, Stephane Bortzmeyer wrote:
> > A funny experience with IDN at the last DNS-OARC meeting or "the
> > Internet is not made for hieroglyphs":
> > 
> > https://indico.dns-oarc.net/event/25/session/8/contribution/1/material/slides/1.pdf 
> 

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


From nobody Fri Oct 21 16:28:37 2016
Return-Path: 
X-Original-To: hrpc@irtf.org
Delivered-To: hrpc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B434E1299AB; Fri, 21 Oct 2016 16:21:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147709208473.28214.9639150717436876790.idtracker@ietfa.amsl.com>
Date: Fri, 21 Oct 2016 16:21:24 -0700
Archived-At: 
Cc: hrpc@irtf.org, irtf-chair@irtf.org
Subject: [hrpc] hrpc - Requested session has been scheduled for IETF 97
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Oct 2016 23:21:26 -0000

Dear Niels Oever,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

hrpc Session 1 (1:30:00)
    Monday, Morning Session I 0930-1200
    Room Name: Park Ballroom 1 size: 125
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Human Rights Protocol Considerations
Area Name: IRTF
Session Requester: Niels Oever

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 90
Conflicts to Avoid: 
 First Priority: saag
 Second Priority: dnsop
 Third Priority: homenet


Special Requests:
  please also not schedule together with openpgp
---------------------------------------------------------


From nobody Sun Oct 23 15:17:02 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937FE1293EE for ; Sun, 23 Oct 2016 15:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmPXd-wbGnXb for ; Sun, 23 Oct 2016 15:16:57 -0700 (PDT)
Received: from mail.article19.io (mail.article19.io [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9468E127058 for ; Sun, 23 Oct 2016 15:16:56 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 66FC8E85641; Sun, 23 Oct 2016 22:16:53 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 54C2D162715D; Sun, 23 Oct 2016 22:16:53 +0000 (UTC)
Received: from wolgograd (tunnel.greenhost.nl [195.190.28.22]) by mail.article19.io (Postfix) with ESMTPSA id 09979E85641; Sun, 23 Oct 2016 22:16:48 +0000 (UTC)
Date: Sun, 23 Oct 2016 18:16:42 -0400
From: Niels ten Oever 
To: Stephen Farrell 
Message-ID: <20161023221641.GB22091@wolgograd>
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <09181eec-0731-bf37-412d-a6e627367f2c@article19.org> <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD"
Content-Disposition: inline
In-Reply-To: <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Oct 2016 22:17:01 -0000

--uZ3hkaAS1mZxFaxD
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hiya,

On Tue, Oct 18, 2016 at 05:38:07PM +0100, Stephen Farrell wrote:
>=20
> Hiya,
>=20
> (trimming bits....)
>=20
> On 18/10/16 16:57, Niels ten Oever wrote:
> > Hi Stephen,
> >=20
> > Reply inline:
> >=20
> > On 10/15/2016 03:17 PM, Stephen Farrell wrote:
> >>
> >> Hi Niels,
> >>
> >> On 09/10/16 17:31, Niels ten Oever wrote:
> >>> Hi Stephen,
> >>>
>=20
> >>>> (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.
> >>
> >> Sorry, that's non-responsive to the main point: this is too
> >> long and the bit that's important for the claimed audience
> >> (IETFers) is buried at the end. I still suggest making that
> >> structural change. Why not?
> >=20
> > Because the authors intend to produce a seperate document geared
> > completely at providing considerations.
>=20
> Hmm. If that'd be an hrpc document then it'd fully
> overlap with this. If not, then what kind of document
> would that be? An IETF one? I think we're some way
> from being ready for that tbh.
>=20

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

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

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


>=20
> >>>> (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 =E2=80=93 as i=
t pertains
> >>> to the remit of the IETF. Would it be better if the first mention of =
the
> >>> word architecture came with the following clarification: =E2=80=98Int=
ernet
> >>> architecture is a catch-all phrase. In order to ensure it does not ri=
ng
> >>> 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: =E2=80=98Many memb=
ers of the
> >>> Internet community would argue that there is no architecture, but onl=
y 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=E2=
=80=99.
> >>> 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.=E2=80=
=99 Would
> >>> such a definition clarify our use of the word architecture sufficient=
ly?
> >>
> >> No, I think that's worse tbh, as will any attempt to define "the
> >> Internet architecture" most likely. Others may disagree but I think
> >> by far the best thing here is to remove as many uses of the term as
> >> possible and to carefully say exactly what's meant in any remaining
> >> cases (and I bet you'll find remaining cases mean different things).
> >=20
> > Why is it worse?
>=20
> Because I don't think it's likely an RG-consensus definition
> of "Internet architecture" but even more important I think
> this document doesn't have to depend on their being such a
> consensus definition. (Just because there's a hole beside
> us doesn't mean we need to dig it deeper:-)
>=20

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

> >=20
> >>>
> >>> Additionally, we would like to push back a bit against the argument t=
hat
> >>> because there is no consensus in the IETF on what the term architectu=
re
> >>> means, we cannot use it in the text. The IRTF should be the space whe=
re
> >>> 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.
> >>
> >> Sorry, "pushing boundaries" is just fine, but one is not doing that
> >> by using ill-defined terms in ill-defined ways. I also don't think
> >> hrpc is a good venue for trying to define this particular term, nor
> >> do I think such an activity is interesting or fruitful. Much better
> >> to avoid use of the ill-defined term where it's not needed, which
> >> is almost everywhere IMO.
> >>
> >=20
> > Well, we're providing references to infrastructure scholars, so am not
> > so sure about ill-defined. Could you be a bit more precise in your
> > objection?
>=20
> More precise than "you don't need it, and you've not defined
> it in a way that I think would garner consensus"? :-)
>=20
> I'd again encourage you to try not use the term at all as it's
> not needed.
>=20

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


> >=20
> >>>
> >>>
> >>>> (4) What does "=3D" mean here?
> >>>>
> >>>> In section 2 and later (in 5.2.2) you have diagrams with
> >>>> bracketed terms on the left, then "=3D" and then another term on
> >>>> the right. I just don't get what you mean by that "=3D" 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,
> >>
> >> Correct:-)
> >>
> >>> 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 w=
ell
> >>> as authenticity.
> >>
> >> No, the security model of TLS does not include anonymity. The security
> >> model of Tor does. It's important to be precise like that I think in
> >> this document. These uses of "=3D" or "=3D=3D=3D>" are nowhere near pr=
ecise IMO.
> >>
> >=20
> > Because a function arrow doesn't seem in place here, or...?
>=20
> I answered that above. Regardless of the symbol there's a
> lack of precision in the concepts here but the presentation
> implies that such precision exists. See the TLS/Tor text
> just above.
>=20
> >=20
> >>>
> >>> I think it can easily be argued than in many models of security, priv=
acy
> >>> and anonymity play a role, in others anonymity may be less important.
> >>
> >> It can be argued yes. That argument is wrong where it comes to
> >> anonymity which is a very very hard goal to even approach.
> >>
> >>>
> >>> 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 think that is still plain wrong in multiple ways, but certainly
> >> wrt anonymity.
> >>
> >=20
> > Why? Because anonymity is never part of any definition or concept of
> > security? That doesn't make sense to me.
>=20
> I think we'd agree TLS is currently the most important
> security protocol widely used on the Internet. TLS has
> no concept of anonymity. Saying that "a,b,c, anonymity, e
> and f is what makes up security on the Internet" is IMO
> therefore wrong, for all a,b,c, e and f.
>=20
> Another issue with "anonymity" is that it's not at all
> clear what you might mean by that. Is the use of a source
> IP address allowed? What about a MAC address? What about
> identifiers in client certificates? What about a TLS
> session ticket? And all of those are just TLS examples.
>=20
> Any the "is what makes up" just seems like arm-waving.
> I really am not seeing how we benefit from making such
> ostensibly definitive (mis)statements. (While at the
> same time being fine that such constructs were found
> useful when organising the work earlier on.)
>=20
>=20
> >>>> 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 "=3D" 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 betwe=
en
> >>> the LHS and the RHS should be 'contribute to an enabling environment
> >>> for', so I replaced the '=3D' with '=E2=87=92' and added an explanati=
on.
> >>
> >> TBH, I think those diagrams have outlived their usefulness and
> >> could just be deleted or moved to an appendix only about the
> >> method used in this work that does not claim that these relations
> >> are well defined. (See also my point (2) above about structure.)
> >=20
> > I think they have a clear role in the methodology as described, and
> > therefore fit in this research document.
>=20
> Yes, those may have been helpful in doing the work. That
> does not mean it is helpful to present them as if they
> are defining precise relationships, as they are not. Hence
> my suggestion to move them to an appendix and present
> them there as a tool that was used in the research and
> not as (seems to me to be the case) as some results of
> the work that define precise relationships.
>=20

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

> >=20
> >=20
> >>
> >>>>
> >>>> (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 analy=
sis
> >>> a case of technology and it's impact human rights. So, it has a
> >>> completely different role from RFC3552, even though the conclusions a=
re
> >>> largely the same.
> >>
> >> That is non-responsive to the main point here. The scope of
> >> the DDoS discussion is still wrong. Can you respond to the
> >> main point?
> >>
> >=20
> > I thought I responded to your main point, could you else rephrase it? It
> > also rewrote it a bit, maybe that helps:
> >=20
> > DDoS attacks can thus stifle freedom of expression, complicate the
> > ability of independent media and human rights organizations to exercise
> > their right to (online) freedom of association, while facilitating the
> > ability of governments to censor dissent.  When it comes to comparing
> > DDoS attacks to protests in offline life, it is important to remember
> > that only a limited number of DDoS attacks involved solely willing
> > participants. In most cases, the clients are hacked computers of
> > unrelated parties that have not consented to being part of a DDoS (for
> > exceptions see Operation Abibil {{Abibil}} or the Iranian Green Movement
> > DDoS {{GreenMovement}}). In addition, DDoS attacks are increasingly used
> > as an extortion tactic.
> >=20
> >=20
> >=20
> > All of these issues seem to suggest that the IETF should try to ensure
> > that their protocols cannot be used for DDoS attacks, which is
> > consistent with the long-standing IETF consensus that DDoS is an attack
> > that protocols should mitigate them to the extent they can {{BCP72}}.
> > Decreasing the number of vulnerabilities in protocols and (outside of
> > IETF) the number of bugs in the network stacks of routers or computers
> > could address this issue. The IETF can clearly play a role in bringing
> > about some of these changes but the IETF cannot be expected to take a
> > positive stance on (specific) DDoS attacks, or create protocols to
> > enable some attacks and inhibit others. What the IETF can do is
> > critically reflect on its role in the development of the Internet, and
> > how this impacts the ability of people to excercise their human rights,
> > such as freedom of expression.
>=20
> Ok, fair enough, that is better.
>=20
> I still think "limited number" and "in most cases" misrepresent
> the reality though which is that maybe 99.999% of DDoS attacks
> involve zombies.
>=20
> I also don't think the linkage to freedom of expression survives
> taking away the (bad) idea that some DDoS attacks are "ok."
>=20
> Isn't the real problem with DDoS mitigation that it nearly forces
> people to use commercial services, and not that DDoS mitigation
> prevents people from saying what they want (e.g. protesting).
>=20
> So I still think the above text could be improved but it's
> no longer a show-stopper for me.
>=20
> >>>> (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 present=
ed
> >>> the outcomes at the session in Berlin and were also posted to the lis=
t.
> >>
> >> Can you send links to those please? I don't recall those as having
> >> used the questions as listed but I may be mis-remembering. I still
> >> find some of the questions non-useful for the intended audience
> >> but of course I may be wrong or an outlier there.
> >>
> >=20
> > Presentation of Shane and Giovane at IETF:
> >=20
> > http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF96_HRPC=
&chapter=3Dchapter_1
> >=20
>=20
> Didn't have time for that sorry.
>=20
> > their earlier emails to the list:
> >=20
> > https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi4
>=20
> Quoting from that:
>=20
> "
> Conclusion
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> My own feeling is that while this checklist is helpful in the current
> form, it should probably be shortened and clarified."
>=20
> >=20
> > https://mailarchive.ietf.org/arch/msg/hrpc/OJKXq7Yq3AwX4j3Yv0Oi32MTzV8
> >=20
> > https://mailarchive.ietf.org/arch/msg/hrpc/ZPvhLL0pj2vJxkVFKW3qM-stsoE
>=20
> There Giovane said a bunch of the questions were not
> relevant to him. (I'm not clear what the diference
> between the two postings from his is btw, but that's
> probably ok.)
>=20
> Honestly, I'm not seeing "exhaustive," and I maintain my
> position that a number of the questions won't have any good
> answers for the intended audience.
>=20
>=20
> >>>> (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 a=
re
> >>> many scholarly papers written about this, and I would large go with t=
he
> >>> 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.
> >>
> >> I like that text, thanks. I'd suggest adding a bit of text to
> >> cover what I think might be a misinterpretation that could be
> >> common for the more literal-minded typical IETFer such as
> >> myself:-) Something like:
> >>
> >> "The fact that rights can always be in conflict with one another
> >> means that all human rights are contingent and none are absolute.
> >=20
> > This is not true. Torture is for instance always prohibited. We would
> > get here into concepts of proportionality and necessity (and perhaps
> > even legal accountability), which would imho only make the text more,
> > not less complex for literal-minded types (and the non-literal-minded
> > types alike).
>=20
> I'm more interested that the point below be included and don't
> mind how that's introduced.
>=20
> >=20
> >> So, for example, if one posited a "right to encrypt" as a human
> >> right that inherently means accepting that there are times when
> >> that "right" would lose out in balancing of conflicting rights.
> >> That means that there are technical concepts (e.g. arithmetic,
> >> the ability to write code), the free exercise of which may be
> >> better protected if they are not specifically claimed as human
> >> rights."
> >=20
> > I see what you're trying to do here, but I think this is for another
> > document.
>=20
> FWIW, I think it's important to include that point in this
> document, given what I know of IETFers.
>=20

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

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

Cheers,

Niels


> Cheers,
> S.
>=20
> >=20
> >>
> >> (As an aside, it's interesting that you are sensitive here to
> >> the difficultly of establishing consensus on this topic, whereas
> >> I am not. And then we reverse roles when it comes to "Internet
> >> architecture." Not that surprising I guess:-)
> >=20
> > Well, there seems to be more consensus on Internet architecture than
> > this, at least as far as I could find, but am happy to be convinced (in
> > both cases).
> >=20
> > Cheers,
> >=20
> > Niels
> >=20
> >>
> >>>
> >>>> Specific comments (without reference to importance:-)
> >>
> >> Will get back to these later, when I get time.
> >>
> >> Cheers,
> >> S.
> >>
> >>
> >>
> >=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > hrpc mailing list
> > hrpc@irtf.org
> > https://www.irtf.org/mailman/listinfo/hrpc
> >=20
>=20




--uZ3hkaAS1mZxFaxD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJYDTbJAAoJEAi1oPJjbWjp9SkH/jx60Nz3KsxvvW2zM9IwJBdO
IKr4q5i9whdxgGJJEUQDKRTg8nWRnRe0RwJOx4qAW+yKFEUMJlhIECnv4LPOCKQE
bv1NMfPe0Asb9/nvNQ1oQKk37DuqsgUkIpSGPBIdeRPTDHSCqQRqnnssy99WW2UO
LZPiKYYrfwi07UhEOOp713nM/mir9XLQg8sLNtTZys/sJX3UbzSYHgnjnu5ANjA2
vCXBCuLBTcRMCBuHJsuhzVGsRJAdXfT1tBmtyELUxPvamqPUk8BWYPd5UtkrvBbU
zcOxkbRDr+88C8+Uf6vU9AW/TiVRDWSt0rG0xJjYCzieokJK+CAWJvHJvvyNYFY=
=JxUj
-----END PGP SIGNATURE-----

--uZ3hkaAS1mZxFaxD--


From nobody Sun Oct 23 15:23:40 2016
Return-Path: 
X-Original-To: hrpc@irtf.org
Delivered-To: hrpc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B2E127058; Sun, 23 Oct 2016 15:23:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147726141905.15955.1927298857453932125.idtracker@ietfa.amsl.com>
Date: Sun, 23 Oct 2016 15:23:39 -0700
Archived-At: 
Cc: hrpc@irtf.org
Subject: [hrpc] I-D Action: draft-irtf-hrpc-research-03.txt
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Oct 2016 22:23:39 -0000

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

        Title           : Research into Human Rights Protocol Considerations
        Authors         : Niels ten Oever
                          Corinne Cath
	Filename        : draft-irtf-hrpc-research-03.txt
	Pages           : 68
	Date            : 2016-10-23

Abstract:
   This document provides a proposal for a vocabulary to discuss the
   relation between human rights and Internet protocols, an overview of
   the discussion in technical and academic literature and communities,
   a proposal for the mapping of the relation between human rights and
   technical concepts, and a proposal for guidelines for human rights
   considerations, similar to the work done on the guidelines for
   privacy considerations [RFC6973].

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  This documents aims to be a consensus
   document of the Human Rights Protocol Consideration Research Group of
   the Internet Research Task Force (IRTF).

   Discussion of this draft at: hrpc@irtf.org //
   https://www.irtf.org/mailman/listinfo/hrpc


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-hrpc-research-03

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


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

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


From nobody Sun Oct 23 15:44:19 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F5D129611 for ; Sun, 23 Oct 2016 15:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.732
X-Spam-Level: 
X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w_mKeTGHPuv for ; Sun, 23 Oct 2016 15:44:14 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2093A129440 for ; Sun, 23 Oct 2016 15:44:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C338BE2E; Sun, 23 Oct 2016 23:44:10 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3MlQprfZqgV; Sun, 23 Oct 2016 23:44:07 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C22C0BDCC; Sun, 23 Oct 2016 23:44:06 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477262647; bh=S+ag64NA9o7GCQwE+JWlYMcrVH52xMIquOAMh6MlOgw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=CGcaExGPQQsyGQEOIH7x4ncy+Ji+Zo8YZzfOk85T41sAGkf+R05XzZ/8bzhcD67SD NuWClNgIzrhpLSPokio2/EfzaxPAeGt85OPi6KfGqbd+DMfXyf8DlwhAgLhy7tDthk fuVHIv2w0QERgO9wW8Pr93lnVLrFkmZH3Egh9WJ8=
To: Niels ten Oever 
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <09181eec-0731-bf37-412d-a6e627367f2c@article19.org> <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie> <20161023221641.GB22091@wolgograd>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <417d8625-52aa-7243-f866-a1329390abad@cs.tcd.ie>
Date: Sun, 23 Oct 2016 23:44:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <20161023221641.GB22091@wolgograd>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CroDsEP61qTj3NBCsFV0h7Vl4FpXN2nR6"
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Oct 2016 22:44:18 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CroDsEP61qTj3NBCsFV0h7Vl4FpXN2nR6
Content-Type: multipart/mixed; boundary="h9ANTuQHPuMtIBidsjf7OwjNbmX7gNswC";
 protected-headers="v1"
From: Stephen Farrell 
To: Niels ten Oever 
Cc: hrpc@irtf.org
Message-ID: <417d8625-52aa-7243-f866-a1329390abad@cs.tcd.ie>
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
References: 
 
 <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie>
 <09181eec-0731-bf37-412d-a6e627367f2c@article19.org>
 <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie>
 <20161023221641.GB22091@wolgograd>
In-Reply-To: <20161023221641.GB22091@wolgograd>

--h9ANTuQHPuMtIBidsjf7OwjNbmX7gNswC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 23/10/16 23:16, Niels ten Oever wrote:
> Hiya,
>=20
> On Tue, Oct 18, 2016 at 05:38:07PM +0100, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> (trimming bits....)
>>
>> On 18/10/16 16:57, Niels ten Oever wrote:
>>> Hi Stephen,
>>>
>>> Reply inline:
>>>
>>> On 10/15/2016 03:17 PM, Stephen Farrell wrote:
>>>>
>>>> Hi Niels,
>>>>
>>>> On 09/10/16 17:31, Niels ten Oever wrote:
>>>>> Hi Stephen,
>>>>>
>>
>>>>>> (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 a=
s 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 bringi=
ng it
>>>>> into the IETF.
>>>>
>>>> Sorry, that's non-responsive to the main point: this is too
>>>> long and the bit that's important for the claimed audience
>>>> (IETFers) is buried at the end. I still suggest making that
>>>> structural change. Why not?
>>>
>>> Because the authors intend to produce a seperate document geared
>>> completely at providing considerations.
>>
>> Hmm. If that'd be an hrpc document then it'd fully
>> overlap with this. If not, then what kind of document
>> would that be? An IETF one? I think we're some way
>> from being ready for that tbh.
>>
>=20
> IETF one, and I think we're indeed still some time away from that.
>=20
>> Anyway, doesn't that mean the comment stands for this
>> document? Producing another document doesn't answer
>> the point raised about the structure of this one.
>>
>=20
> And I think my point also still stands. It is logical to put=20
> the conclusion of the research, after the research overview, at the=20
> bottom. At least in a Research Document (which is what we're=20
> developing here).

Many things are logical but unwise.

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

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

>=20
>=20
>>
>>>>>> (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 =E2=80=93 as=
 it pertains
>>>>> to the remit of the IETF. Would it be better if the first mention o=
f the
>>>>> word architecture came with the following clarification: =E2=80=98I=
nternet
>>>>> 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 architectur=
e as
>>>>> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many me=
mbers of the
>>>>> Internet community would argue that there is no architecture, but o=
nly a
>>>>> tradition, which was not written down for  the first 25 years (or a=
t
>>>>> least not by the IAB).  However, in very general terms, the communi=
ty
>>>>> 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 sho=
w
>>>>> 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 provide=
rs,
>>>>> and flourishes in the increasingly liberal and competitive commerci=
al
>>>>> telecommunications environment. The key to global connectivity is t=
he
>>>>> inter-networking layer.  The key to exploiting this layer over dive=
rse
>>>>> hardware providing global connectivity is the "end to end argument=E2=
=80=99.
>>>>> Building on RFC1958 we hold that the word architecture, in the cont=
ext
>>>>> 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.=E2=80=
=99 Would
>>>>> such a definition clarify our use of the word architecture sufficie=
ntly?
>>>>
>>>> No, I think that's worse tbh, as will any attempt to define "the
>>>> Internet architecture" most likely. Others may disagree but I think
>>>> by far the best thing here is to remove as many uses of the term as
>>>> possible and to carefully say exactly what's meant in any remaining
>>>> cases (and I bet you'll find remaining cases mean different things).=

>>>
>>> Why is it worse?
>>
>> Because I don't think it's likely an RG-consensus definition
>> of "Internet architecture" but even more important I think
>> this document doesn't have to depend on their being such a
>> consensus definition. (Just because there's a hole beside
>> us doesn't mean we need to dig it deeper:-)
>>
>=20
> I am not sure if this point is widely shared. Would love to=20
> hear from others. For me the way it is used does not seem=20
> problematic. Perhaps you could point out more specifically where you=20
> see problems (except in process)?

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

>=20
>>>
>>>>>
>>>>> 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 architec=
ture
>>>>> means, we cannot use it in the text. The IRTF should be the space w=
here
>>>>> we can push the boundaries on that discussion, bringing in definiti=
ons
>>>>> from academia as we do in the text by referring to amongst others t=
he
>>>>> work of Prof. Denardis and Prof. Bowker on architecture.
>>>>
>>>> Sorry, "pushing boundaries" is just fine, but one is not doing that
>>>> by using ill-defined terms in ill-defined ways. I also don't think
>>>> hrpc is a good venue for trying to define this particular term, nor
>>>> do I think such an activity is interesting or fruitful. Much better
>>>> to avoid use of the ill-defined term where it's not needed, which
>>>> is almost everywhere IMO.
>>>>
>>>
>>> Well, we're providing references to infrastructure scholars, so am no=
t
>>> so sure about ill-defined. Could you be a bit more precise in your
>>> objection?
>>
>> More precise than "you don't need it, and you've not defined
>> it in a way that I think would garner consensus"? :-)
>>
>> I'd again encourage you to try not use the term at all as it's
>> not needed.
>>
>=20
> Pls show me how it is ill-defined, cause I do not see it. But this=20
> might be me of course!

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

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


>=20
>=20
>>>
>>>>>
>>>>>
>>>>>> (4) What does "=3D" mean here?
>>>>>>
>>>>>> In section 2 and later (in 5.2.2) you have diagrams with
>>>>>> bracketed terms on the left, then "=3D" and then another term on
>>>>>> the right. I just don't get what you mean by that "=3D" 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,
>>>>
>>>> Correct:-)
>>>>
>>>>> 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.
>>>>
>>>> No, the security model of TLS does not include anonymity. The securi=
ty
>>>> model of Tor does. It's important to be precise like that I think in=

>>>> this document. These uses of "=3D" or "=3D=3D=3D>" are nowhere near =
precise IMO.
>>>>
>>>
>>> Because a function arrow doesn't seem in place here, or...?
>>
>> I answered that above. Regardless of the symbol there's a
>> lack of precision in the concepts here but the presentation
>> implies that such precision exists. See the TLS/Tor text
>> just above.
>>
>>>
>>>>>
>>>>> I think it can easily be argued than in many models of security, pr=
ivacy
>>>>> and anonymity play a role, in others anonymity may be less importan=
t.
>>>>
>>>> It can be argued yes. That argument is wrong where it comes to
>>>> anonymity which is a very very hard goal to even approach.
>>>>
>>>>>
>>>>> 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 think that is still plain wrong in multiple ways, but certainly
>>>> wrt anonymity.
>>>>
>>>
>>> Why? Because anonymity is never part of any definition or concept of
>>> security? That doesn't make sense to me.
>>
>> I think we'd agree TLS is currently the most important
>> security protocol widely used on the Internet. TLS has
>> no concept of anonymity. Saying that "a,b,c, anonymity, e
>> and f is what makes up security on the Internet" is IMO
>> therefore wrong, for all a,b,c, e and f.
>>
>> Another issue with "anonymity" is that it's not at all
>> clear what you might mean by that. Is the use of a source
>> IP address allowed? What about a MAC address? What about
>> identifiers in client certificates? What about a TLS
>> session ticket? And all of those are just TLS examples.
>>
>> Any the "is what makes up" just seems like arm-waving.
>> I really am not seeing how we benefit from making such
>> ostensibly definitive (mis)statements. (While at the
>> same time being fine that such constructs were found
>> useful when organising the work earlier on.)
>>
>>
>>>>>> 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 "=3D" 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 bet=
ween
>>>>> the LHS and the RHS should be 'contribute to an enabling environmen=
t
>>>>> for', so I replaced the '=3D' with '=E2=87=92' and added an explana=
tion.
>>>>
>>>> TBH, I think those diagrams have outlived their usefulness and
>>>> could just be deleted or moved to an appendix only about the
>>>> method used in this work that does not claim that these relations
>>>> are well defined. (See also my point (2) above about structure.)
>>>
>>> I think they have a clear role in the methodology as described, and
>>> therefore fit in this research document.
>>
>> Yes, those may have been helpful in doing the work. That
>> does not mean it is helpful to present them as if they
>> are defining precise relationships, as they are not. Hence
>> my suggestion to move them to an appendix and present
>> them there as a tool that was used in the research and
>> not as (seems to me to be the case) as some results of
>> the work that define precise relationships.
>>
>=20
> OK - created a table as suggested by Joe and removed the formulas.=20
> Hope that this will provide more clarity.

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

>=20
>>>
>>>
>>>>
>>>>>>
>>>>>> (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 ana=
lysis
>>>>> 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.
>>>>
>>>> That is non-responsive to the main point here. The scope of
>>>> the DDoS discussion is still wrong. Can you respond to the
>>>> main point?
>>>>
>>>
>>> I thought I responded to your main point, could you else rephrase it?=
 It
>>> also rewrote it a bit, maybe that helps:
>>>
>>> DDoS attacks can thus stifle freedom of expression, complicate the
>>> ability of independent media and human rights organizations to exerci=
se
>>> their right to (online) freedom of association, while facilitating th=
e
>>> ability of governments to censor dissent.  When it comes to comparing=

>>> DDoS attacks to protests in offline life, it is important to remember=

>>> that only a limited number of DDoS attacks involved solely willing
>>> participants. In most cases, the clients are hacked computers of
>>> unrelated parties that have not consented to being part of a DDoS (fo=
r
>>> exceptions see Operation Abibil {{Abibil}} or the Iranian Green Movem=
ent
>>> DDoS {{GreenMovement}}). In addition, DDoS attacks are increasingly u=
sed
>>> as an extortion tactic.
>>>
>>>
>>>
>>> All of these issues seem to suggest that the IETF should try to ensur=
e
>>> that their protocols cannot be used for DDoS attacks, which is
>>> consistent with the long-standing IETF consensus that DDoS is an atta=
ck
>>> that protocols should mitigate them to the extent they can {{BCP72}}.=

>>> Decreasing the number of vulnerabilities in protocols and (outside of=

>>> IETF) the number of bugs in the network stacks of routers or computer=
s
>>> could address this issue. The IETF can clearly play a role in bringin=
g
>>> about some of these changes but the IETF cannot be expected to take a=

>>> positive stance on (specific) DDoS attacks, or create protocols to
>>> enable some attacks and inhibit others. What the IETF can do is
>>> critically reflect on its role in the development of the Internet, an=
d
>>> how this impacts the ability of people to excercise their human right=
s,
>>> such as freedom of expression.
>>
>> Ok, fair enough, that is better.
>>
>> I still think "limited number" and "in most cases" misrepresent
>> the reality though which is that maybe 99.999% of DDoS attacks
>> involve zombies.
>>
>> I also don't think the linkage to freedom of expression survives
>> taking away the (bad) idea that some DDoS attacks are "ok."
>>
>> Isn't the real problem with DDoS mitigation that it nearly forces
>> people to use commercial services, and not that DDoS mitigation
>> prevents people from saying what they want (e.g. protesting).
>>
>> So I still think the above text could be improved but it's
>> no longer a show-stopper for me.

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

>>
>>>>>> (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 prese=
nted
>>>>> the outcomes at the session in Berlin and were also posted to the l=
ist.
>>>>
>>>> Can you send links to those please? I don't recall those as having
>>>> used the questions as listed but I may be mis-remembering. I still
>>>> find some of the questions non-useful for the intended audience
>>>> but of course I may be wrong or an outlier there.
>>>>
>>>
>>> Presentation of Shane and Giovane at IETF:
>>>
>>> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF96_HR=
PC&chapter=3Dchapter_1
>>>
>>
>> Didn't have time for that sorry.
>>
>>> their earlier emails to the list:
>>>
>>> https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi=
4
>>
>> Quoting from that:
>>
>> "
>> Conclusion
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> My own feeling is that while this checklist is helpful in the current
>> form, it should probably be shortened and clarified."
>>
>>>
>>> https://mailarchive.ietf.org/arch/msg/hrpc/OJKXq7Yq3AwX4j3Yv0Oi32MTzV=
8
>>>
>>> https://mailarchive.ietf.org/arch/msg/hrpc/ZPvhLL0pj2vJxkVFKW3qM-stso=
E
>>
>> There Giovane said a bunch of the questions were not
>> relevant to him. (I'm not clear what the diference
>> between the two postings from his is btw, but that's
>> probably ok.)
>>
>> Honestly, I'm not seeing "exhaustive," and I maintain my
>> position that a number of the questions won't have any good
>> answers for the intended audience.
>>

No response?

>>
>>>>>> (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 als=
o 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=
=2E So
>>>>> I would offer the following text:
>>>>>
>>>>>     Human rights can be in conflict with each other, such as the ri=
ght
>>>>> 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 proc=
ess
>>>>> tangible and practical for protocol developers is what this researc=
h
>>>>> aims to ultimately contribute to.
>>>>
>>>> I like that text, thanks. I'd suggest adding a bit of text to
>>>> cover what I think might be a misinterpretation that could be
>>>> common for the more literal-minded typical IETFer such as
>>>> myself:-) Something like:
>>>>
>>>> "The fact that rights can always be in conflict with one another
>>>> means that all human rights are contingent and none are absolute.
>>>
>>> This is not true. Torture is for instance always prohibited. We would=

>>> get here into concepts of proportionality and necessity (and perhaps
>>> even legal accountability), which would imho only make the text more,=

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

>>> types alike).
>>
>> I'm more interested that the point below be included and don't
>> mind how that's introduced.
>>
>>>
>>>> So, for example, if one posited a "right to encrypt" as a human
>>>> right that inherently means accepting that there are times when
>>>> that "right" would lose out in balancing of conflicting rights.
>>>> That means that there are technical concepts (e.g. arithmetic,
>>>> the ability to write code), the free exercise of which may be
>>>> better protected if they are not specifically claimed as human
>>>> rights."
>>>
>>> I see what you're trying to do here, but I think this is for another
>>> document.
>>
>> FWIW, I think it's important to include that point in this
>> document, given what I know of IETFers.
>>
>=20
> OK - so let's get a bit deeper into this. We're saying that security=20
> is a human rights.=20

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

> We're not saying that encryption is a human=20
> rights, only that encryption can enable a specific human right. That=20
> is as far as we go here.=20

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

> I do not think that saying 'a specific=20
> technology is a human right' makes much sense, because it is context=20
> dependent. I do think privacy is a human rights and therefore we=20
> should use encryption.  And that is the point we're making imho. But=20
> maybe you see that differently?

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

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

Cheers,
S.


>=20
> I hope that with this we can now start the Research Group Last Call.
>=20
> Cheers,
>=20
> Niels
>=20
>=20
>> Cheers,
>> S.
>>
>>>
>>>>
>>>> (As an aside, it's interesting that you are sensitive here to
>>>> the difficultly of establishing consensus on this topic, whereas
>>>> I am not. And then we reverse roles when it comes to "Internet
>>>> architecture." Not that surprising I guess:-)
>>>
>>> Well, there seems to be more consensus on Internet architecture than
>>> this, at least as far as I could find, but am happy to be convinced (=
in
>>> both cases).
>>>
>>> Cheers,
>>>
>>> Niels
>>>
>>>>
>>>>>
>>>>>> Specific comments (without reference to importance:-)
>>>>
>>>> Will get back to these later, when I get time.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>
>>
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


--h9ANTuQHPuMtIBidsjf7OwjNbmX7gNswC--

--CroDsEP61qTj3NBCsFV0h7Vl4FpXN2nR6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYDT02AAoJEC88hzaAX42iXQsIALxUeCdkLdOYEltHOKhoXK/G
o5A231EAIupXQ+Jg9Fz0JqU3lcDLmMaG93iOvSk3zjW6l6zsouENyuXnAEreda0A
9xSrOO2CjUMhH1AGbtWjr5RvpZQVLxB9QbrUsHV/85XrNmi2eNZwdQQIwKAR9faR
+gvlPuuTImd4EXNQkqKz/BxMfC8X23slw37b1hFJvxOcOL6ve/GriuP3vNDI92Pf
5e98M2kNgYHHucElomBt10Qh3eWVXRgQ+b6xkzad/tOOg6aP0Guw2v4dU2Hts5av
0AlXH3hfETaUiRLd83mLJaTKO12SCr7D8WadmO1UQrXI/99UPcVqtBiujDZwR+g=
=6BGN
-----END PGP SIGNATURE-----

--CroDsEP61qTj3NBCsFV0h7Vl4FpXN2nR6--


From nobody Sun Oct 23 17:45:22 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4812961A for ; Sun, 23 Oct 2016 17:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.331
X-Spam-Level: 
X-Spam-Status: No, score=-7.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHFFJNkfKJcQ for ; Sun, 23 Oct 2016 17:45:17 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCFE1294FD for ; Sun, 23 Oct 2016 17:45:16 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.31,539,1473112800"; d="scan'208";a="242020585"
Received: from zmbs3.inria.fr ([128.93.142.16]) by mail2-relais-roc.national.inria.fr with ESMTP; 24 Oct 2016 02:45:13 +0200
Date: Mon, 24 Oct 2016 02:45:13 +0200 (CEST)
From: Harry Halpin 
To: Stephen Farrell 
Message-ID: <1692561380.13801362.1477269913865.JavaMail.zimbra@inria.fr>
In-Reply-To: <417d8625-52aa-7243-f866-a1329390abad@cs.tcd.ie>
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <09181eec-0731-bf37-412d-a6e627367f2c@article19.org> <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie> <20161023221641.GB22091@wolgograd> <417d8625-52aa-7243-f866-a1329390abad@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [82.245.174.113]
X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF47 (Linux)/8.0.9_GA_6191)
Thread-Topic: review of draft-irtf-hrpc-research-00
Thread-Index: 1GQob0UgKhV2k594TZI9m6Zrb3K9pw==
Archived-At: 
Cc: Niels ten Oever , hrpc@irtf.org
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2016 00:45:21 -0000

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

My two cents,
     harry


----- Mail original -----
> De: "Stephen Farrell" 
> =C3=80: "Niels ten Oever" 
> Cc: hrpc@irtf.org
> Envoy=C3=A9: Lundi 24 Octobre 2016 00:44:06
> Objet: Re: [hrpc] review of draft-irtf-hrpc-research-00
>=20
>=20
>=20
> On 23/10/16 23:16, Niels ten Oever wrote:
> > Hiya,
> >=20
> > On Tue, Oct 18, 2016 at 05:38:07PM +0100, Stephen Farrell wrote:
> >>
> >> Hiya,
> >>
> >> (trimming bits....)
> >>
> >> On 18/10/16 16:57, Niels ten Oever wrote:
> >>> Hi Stephen,
> >>>
> >>> Reply inline:
> >>>
> >>> On 10/15/2016 03:17 PM, Stephen Farrell wrote:
> >>>>
> >>>> Hi Niels,
> >>>>
> >>>> On 09/10/16 17:31, Niels ten Oever wrote:
> >>>>> Hi Stephen,
> >>>>>
> >>
> >>>>>> (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 a=
s 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 bringi=
ng
> >>>>> it
> >>>>> into the IETF.
> >>>>
> >>>> Sorry, that's non-responsive to the main point: this is too
> >>>> long and the bit that's important for the claimed audience
> >>>> (IETFers) is buried at the end. I still suggest making that
> >>>> structural change. Why not?
> >>>
> >>> Because the authors intend to produce a seperate document geared
> >>> completely at providing considerations.
> >>
> >> Hmm. If that'd be an hrpc document then it'd fully
> >> overlap with this. If not, then what kind of document
> >> would that be? An IETF one? I think we're some way
> >> from being ready for that tbh.
> >>
> >=20
> > IETF one, and I think we're indeed still some time away from that.
> >=20
> >> Anyway, doesn't that mean the comment stands for this
> >> document? Producing another document doesn't answer
> >> the point raised about the structure of this one.
> >>
> >=20
> > And I think my point also still stands. It is logical to put
> > the conclusion of the research, after the research overview, at the
> > bottom. At least in a Research Document (which is what we're
> > developing here).
>=20
> Many things are logical but unwise.
>=20
> The length of this document and the target audience make
> the current structure unwise.
>=20
> I think in the above argument you also seem to be changing
> the target audience a bit, moving from protocol developers
> (IETFers) to those interested in reading about research.
> Both are valid but very different target audiences.
>=20
> >=20
> >=20
> >>
> >>>>>> (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 =E2=80=93 as=
 it pertains
> >>>>> to the remit of the IETF. Would it be better if the first mention o=
f
> >>>>> the
> >>>>> word architecture came with the following clarification: =E2=80=98I=
nternet
> >>>>> 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 architectur=
e as
> >>>>> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many me=
mbers of the
> >>>>> Internet community would argue that there is no architecture, but o=
nly
> >>>>> a
> >>>>> tradition, which was not written down for  the first 25 years (or a=
t
> >>>>> least not by the IAB).  However, in very general terms, the communi=
ty
> >>>>> 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 sho=
w
> >>>>> 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 provide=
rs,
> >>>>> and flourishes in the increasingly liberal and competitive commerci=
al
> >>>>> telecommunications environment. The key to global connectivity is t=
he
> >>>>> inter-networking layer.  The key to exploiting this layer over dive=
rse
> >>>>> hardware providing global connectivity is the "end to end argument=
=E2=80=99.
> >>>>> Building on RFC1958 we hold that the word architecture, in the cont=
ext
> >>>>> 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.=E2=80=
=99 Would
> >>>>> such a definition clarify our use of the word architecture
> >>>>> sufficiently?
> >>>>
> >>>> No, I think that's worse tbh, as will any attempt to define "the
> >>>> Internet architecture" most likely. Others may disagree but I think
> >>>> by far the best thing here is to remove as many uses of the term as
> >>>> possible and to carefully say exactly what's meant in any remaining
> >>>> cases (and I bet you'll find remaining cases mean different things).
> >>>
> >>> Why is it worse?
> >>
> >> Because I don't think it's likely an RG-consensus definition
> >> of "Internet architecture" but even more important I think
> >> this document doesn't have to depend on their being such a
> >> consensus definition. (Just because there's a hole beside
> >> us doesn't mean we need to dig it deeper:-)
> >>
> >=20
> > I am not sure if this point is widely shared. Would love to
> > hear from others. For me the way it is used does not seem
> > problematic. Perhaps you could point out more specifically where you
> > see problems (except in process)?
>=20
> Didn't I do that in the detailed comments? Thought I had
> anyway.
>=20
> >=20
> >>>
> >>>>>
> >>>>> 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 architec=
ture
> >>>>> means, we cannot use it in the text. The IRTF should be the space w=
here
> >>>>> we can push the boundaries on that discussion, bringing in definiti=
ons
> >>>>> from academia as we do in the text by referring to amongst others t=
he
> >>>>> work of Prof. Denardis and Prof. Bowker on architecture.
> >>>>
> >>>> Sorry, "pushing boundaries" is just fine, but one is not doing that
> >>>> by using ill-defined terms in ill-defined ways. I also don't think
> >>>> hrpc is a good venue for trying to define this particular term, nor
> >>>> do I think such an activity is interesting or fruitful. Much better
> >>>> to avoid use of the ill-defined term where it's not needed, which
> >>>> is almost everywhere IMO.
> >>>>
> >>>
> >>> Well, we're providing references to infrastructure scholars, so am no=
t
> >>> so sure about ill-defined. Could you be a bit more precise in your
> >>> objection?
> >>
> >> More precise than "you don't need it, and you've not defined
> >> it in a way that I think would garner consensus"? :-)
> >>
> >> I'd again encourage you to try not use the term at all as it's
> >> not needed.
> >>
> >=20
> > Pls show me how it is ill-defined, cause I do not see it. But this
> > might be me of course!
>=20
> Assuming there exists one true definition for the Internet
> architecture is problematic. You already reference RFC1958
> which says "The principle of constant change is perhaps the
> only principle of the Internet that should survive indefinitely."
> and which begins it's section 2.1 by saying "Many members of the
> Internet community would argue that there is no architecture..."
> While 1958 does go on to talk more about that (the that in
> question being the topic of the RFC:-) I do not believe that
> the core situation has changed over the last 20 years.
>=20
> As to showing, I believe I did that in the original detailed
> comments. (Would have to check though.)
>=20
>=20
> >=20
> >=20
> >>>
> >>>>>
> >>>>>
> >>>>>> (4) What does "=3D" mean here?
> >>>>>>
> >>>>>> In section 2 and later (in 5.2.2) you have diagrams with
> >>>>>> bracketed terms on the left, then "=3D" and then another term on
> >>>>>> the right. I just don't get what you mean by that "=3D" 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,
> >>>>
> >>>> Correct:-)
> >>>>
> >>>>> 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.
> >>>>
> >>>> No, the security model of TLS does not include anonymity. The securi=
ty
> >>>> model of Tor does. It's important to be precise like that I think in
> >>>> this document. These uses of "=3D" or "=3D=3D=3D>" are nowhere near =
precise IMO.
> >>>>
> >>>
> >>> Because a function arrow doesn't seem in place here, or...?
> >>
> >> I answered that above. Regardless of the symbol there's a
> >> lack of precision in the concepts here but the presentation
> >> implies that such precision exists. See the TLS/Tor text
> >> just above.
> >>
> >>>
> >>>>>
> >>>>> 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 importan=
t.
> >>>>
> >>>> It can be argued yes. That argument is wrong where it comes to
> >>>> anonymity which is a very very hard goal to even approach.
> >>>>
> >>>>>
> >>>>> 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 think that is still plain wrong in multiple ways, but certainly
> >>>> wrt anonymity.
> >>>>
> >>>
> >>> Why? Because anonymity is never part of any definition or concept of
> >>> security? That doesn't make sense to me.
> >>
> >> I think we'd agree TLS is currently the most important
> >> security protocol widely used on the Internet. TLS has
> >> no concept of anonymity. Saying that "a,b,c, anonymity, e
> >> and f is what makes up security on the Internet" is IMO
> >> therefore wrong, for all a,b,c, e and f.
> >>
> >> Another issue with "anonymity" is that it's not at all
> >> clear what you might mean by that. Is the use of a source
> >> IP address allowed? What about a MAC address? What about
> >> identifiers in client certificates? What about a TLS
> >> session ticket? And all of those are just TLS examples.
> >>
> >> Any the "is what makes up" just seems like arm-waving.
> >> I really am not seeing how we benefit from making such
> >> ostensibly definitive (mis)statements. (While at the
> >> same time being fine that such constructs were found
> >> useful when organising the work earlier on.)
> >>
> >>
> >>>>>> 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 "=3D" 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 bet=
ween
> >>>>> the LHS and the RHS should be 'contribute to an enabling environmen=
t
> >>>>> for', so I replaced the '=3D' with '=E2=87=92' and added an explana=
tion.
> >>>>
> >>>> TBH, I think those diagrams have outlived their usefulness and
> >>>> could just be deleted or moved to an appendix only about the
> >>>> method used in this work that does not claim that these relations
> >>>> are well defined. (See also my point (2) above about structure.)
> >>>
> >>> I think they have a clear role in the methodology as described, and
> >>> therefore fit in this research document.
> >>
> >> Yes, those may have been helpful in doing the work. That
> >> does not mean it is helpful to present them as if they
> >> are defining precise relationships, as they are not. Hence
> >> my suggestion to move them to an appendix and present
> >> them there as a tool that was used in the research and
> >> not as (seems to me to be the case) as some results of
> >> the work that define precise relationships.
> >>
> >=20
> > OK - created a table as suggested by Joe and removed the formulas.
> > Hope that this will provide more clarity.
>=20
> The tables are better than the formulae. I continue to
> disagree with the "is what makes up" statement.
>=20
> >=20
> >>>
> >>>
> >>>>
> >>>>>>
> >>>>>> (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.
> >>>>
> >>>> That is non-responsive to the main point here. The scope of
> >>>> the DDoS discussion is still wrong. Can you respond to the
> >>>> main point?
> >>>>
> >>>
> >>> I thought I responded to your main point, could you else rephrase it?=
 It
> >>> also rewrote it a bit, maybe that helps:
> >>>
> >>> DDoS attacks can thus stifle freedom of expression, complicate the
> >>> ability of independent media and human rights organizations to exerci=
se
> >>> their right to (online) freedom of association, while facilitating th=
e
> >>> ability of governments to censor dissent.  When it comes to comparing
> >>> DDoS attacks to protests in offline life, it is important to remember
> >>> that only a limited number of DDoS attacks involved solely willing
> >>> participants. In most cases, the clients are hacked computers of
> >>> unrelated parties that have not consented to being part of a DDoS (fo=
r
> >>> exceptions see Operation Abibil {{Abibil}} or the Iranian Green Movem=
ent
> >>> DDoS {{GreenMovement}}). In addition, DDoS attacks are increasingly u=
sed
> >>> as an extortion tactic.
> >>>
> >>>
> >>>
> >>> All of these issues seem to suggest that the IETF should try to ensur=
e
> >>> that their protocols cannot be used for DDoS attacks, which is
> >>> consistent with the long-standing IETF consensus that DDoS is an atta=
ck
> >>> that protocols should mitigate them to the extent they can {{BCP72}}.
> >>> Decreasing the number of vulnerabilities in protocols and (outside of
> >>> IETF) the number of bugs in the network stacks of routers or computer=
s
> >>> could address this issue. The IETF can clearly play a role in bringin=
g
> >>> about some of these changes but the IETF cannot be expected to take a
> >>> positive stance on (specific) DDoS attacks, or create protocols to
> >>> enable some attacks and inhibit others. What the IETF can do is
> >>> critically reflect on its role in the development of the Internet, an=
d
> >>> how this impacts the ability of people to excercise their human right=
s,
> >>> such as freedom of expression.
> >>
> >> Ok, fair enough, that is better.
> >>
> >> I still think "limited number" and "in most cases" misrepresent
> >> the reality though which is that maybe 99.999% of DDoS attacks
> >> involve zombies.
> >>
> >> I also don't think the linkage to freedom of expression survives
> >> taking away the (bad) idea that some DDoS attacks are "ok."
> >>
> >> Isn't the real problem with DDoS mitigation that it nearly forces
> >> people to use commercial services, and not that DDoS mitigation
> >> prevents people from saying what they want (e.g. protesting).
> >>
> >> So I still think the above text could be improved but it's
> >> no longer a show-stopper for me.
>=20
> Note that the above is still a comment on the draft. Just
> because I don't think it a show-stopper doesn't mean that
> it's good to ignore.
>=20
> >>
> >>>>>> (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 prese=
nted
> >>>>> the outcomes at the session in Berlin and were also posted to the l=
ist.
> >>>>
> >>>> Can you send links to those please? I don't recall those as having
> >>>> used the questions as listed but I may be mis-remembering. I still
> >>>> find some of the questions non-useful for the intended audience
> >>>> but of course I may be wrong or an outlier there.
> >>>>
> >>>
> >>> Presentation of Shane and Giovane at IETF:
> >>>
> >>> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF96_HR=
PC&chapter=3Dchapter_1
> >>>
> >>
> >> Didn't have time for that sorry.
> >>
> >>> their earlier emails to the list:
> >>>
> >>> https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7vi=
4
> >>
> >> Quoting from that:
> >>
> >> "
> >> Conclusion
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> My own feeling is that while this checklist is helpful in the current
> >> form, it should probably be shortened and clarified."
> >>
> >>>
> >>> https://mailarchive.ietf.org/arch/msg/hrpc/OJKXq7Yq3AwX4j3Yv0Oi32MTzV=
8
> >>>
> >>> https://mailarchive.ietf.org/arch/msg/hrpc/ZPvhLL0pj2vJxkVFKW3qM-stso=
E
> >>
> >> There Giovane said a bunch of the questions were not
> >> relevant to him. (I'm not clear what the diference
> >> between the two postings from his is btw, but that's
> >> probably ok.)
> >>
> >> Honestly, I'm not seeing "exhaustive," and I maintain my
> >> position that a number of the questions won't have any good
> >> answers for the intended audience.
> >>
>=20
> No response?
>=20
> >>
> >>>>>> (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 als=
o 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 ri=
ght
> >>>>> 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 proc=
ess
> >>>>> tangible and practical for protocol developers is what this researc=
h
> >>>>> aims to ultimately contribute to.
> >>>>
> >>>> I like that text, thanks. I'd suggest adding a bit of text to
> >>>> cover what I think might be a misinterpretation that could be
> >>>> common for the more literal-minded typical IETFer such as
> >>>> myself:-) Something like:
> >>>>
> >>>> "The fact that rights can always be in conflict with one another
> >>>> means that all human rights are contingent and none are absolute.
> >>>
> >>> This is not true. Torture is for instance always prohibited. We would
> >>> get here into concepts of proportionality and necessity (and perhaps
> >>> even legal accountability), which would imho only make the text more,
> >>> not less complex for literal-minded types (and the non-literal-minded
> >>> types alike).
> >>
> >> I'm more interested that the point below be included and don't
> >> mind how that's introduced.
> >>
> >>>
> >>>> So, for example, if one posited a "right to encrypt" as a human
> >>>> right that inherently means accepting that there are times when
> >>>> that "right" would lose out in balancing of conflicting rights.
> >>>> That means that there are technical concepts (e.g. arithmetic,
> >>>> the ability to write code), the free exercise of which may be
> >>>> better protected if they are not specifically claimed as human
> >>>> rights."
> >>>
> >>> I see what you're trying to do here, but I think this is for another
> >>> document.
> >>
> >> FWIW, I think it's important to include that point in this
> >> document, given what I know of IETFers.
> >>
> >=20
> > OK - so let's get a bit deeper into this. We're saying that security
> > is a human rights.
>=20
> I don't think that statement is in the draft. And while that
> sentence may be one stated in various HR contexts, I don't
> think that anyone has a good understanding of the mapping of
> that to technical concepts that are meaningful to IETFers.
> See the TLS/anonymity comments above.
>=20
> > We're not saying that encryption is a human
> > rights, only that encryption can enable a specific human right. That
> > is as far as we go here.
>=20
> Again. You don't currently say that in the draft. (And nor
> should you I think.)
>=20
> > I do not think that saying 'a specific
> > technology is a human right' makes much sense, because it is context
> > dependent. I do think privacy is a human rights and therefore we
> > should use encryption.  And that is the point we're making imho. But
> > maybe you see that differently?
>=20
> I think you're missing my point so I'll try again.
>=20
> There is a risk that IETFers take a very literal approach to
> the topic of considering human rights and as a result argue
> that anything they consider "good" is a human right. This
> draft should, I think, help avoid that by describing at least
> one major pitfall in such an approach. And I think the example
> of encryption is a good one to use for this.
>=20
> Cheers,
> S.
>=20
>=20
> >=20
> > I hope that with this we can now start the Research Group Last Call.
> >=20
> > Cheers,
> >=20
> > Niels
> >=20
> >=20
> >> Cheers,
> >> S.
> >>
> >>>
> >>>>
> >>>> (As an aside, it's interesting that you are sensitive here to
> >>>> the difficultly of establishing consensus on this topic, whereas
> >>>> I am not. And then we reverse roles when it comes to "Internet
> >>>> architecture." Not that surprising I guess:-)
> >>>
> >>> Well, there seems to be more consensus on Internet architecture than
> >>> this, at least as far as I could find, but am happy to be convinced (=
in
> >>> both cases).
> >>>
> >>> Cheers,
> >>>
> >>> Niels
> >>>
> >>>>
> >>>>>
> >>>>>> Specific comments (without reference to importance:-)
> >>>>
> >>>> Will get back to these later, when I get time.
> >>>>
> >>>> Cheers,
> >>>> S.
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> hrpc mailing list
> >>> hrpc@irtf.org
> >>> https://www.irtf.org/mailman/listinfo/hrpc
> >>>
> >>
> >=20
> >=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > hrpc mailing list
> > hrpc@irtf.org
> > https://www.irtf.org/mailman/listinfo/hrpc
> >=20
>=20
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


From nobody Sun Oct 23 19:05:37 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0168F12949A for ; Sun, 23 Oct 2016 19:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ra9Uw6qEFkr for ; Sun, 23 Oct 2016 19:05:32 -0700 (PDT)
Received: from mail.article19.io (mail.article19.io [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E9B12946B for ; Sun, 23 Oct 2016 19:05:31 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 80EB1D457D5; Mon, 24 Oct 2016 02:05:30 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 65D6DE8566A; Mon, 24 Oct 2016 02:05:30 +0000 (UTC)
Received: from [10.66.44.40] (unknown [137.99.108.95]) by mail.article19.io (Postfix) with ESMTPSA id 2F20CD457D5; Mon, 24 Oct 2016 02:05:29 +0000 (UTC)
To: Stephen Farrell 
References:   <4f22b77a-a660-1217-e787-a0cc509cacc2@cs.tcd.ie> <09181eec-0731-bf37-412d-a6e627367f2c@article19.org> <1f4f14e4-26eb-2750-3ae5-1e0750bb4b1c@cs.tcd.ie> <20161023221641.GB22091@wolgograd> <417d8625-52aa-7243-f866-a1329390abad@cs.tcd.ie>
From: Niels ten Oever 
X-Enigmail-Draft-Status: N1110
Message-ID: <94ccdba3-ca23-484d-f4ad-22278dcd3b75@article19.org>
Date: Sun, 23 Oct 2016 22:05:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <417d8625-52aa-7243-f866-a1329390abad@cs.tcd.ie>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NgwUJrcX8nUmHGrNQH5L6WIiOc3WMWDUI"
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] review of draft-irtf-hrpc-research-00
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Oct 2016 02:05:36 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--NgwUJrcX8nUmHGrNQH5L6WIiOc3WMWDUI
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hiya,

On 10/23/2016 06:44 PM, Stephen Farrell wrote:
>=20
>=20
> On 23/10/16 23:16, Niels ten Oever wrote:
>> Hiya,
>>
>> On Tue, Oct 18, 2016 at 05:38:07PM +0100, Stephen Farrell wrote:
>>>
>>> Hiya,
>>>
>>> (trimming bits....)
>>>
>>> On 18/10/16 16:57, Niels ten Oever wrote:
>>>> Hi Stephen,
>>>>
>>>> Reply inline:
>>>>
>>>> On 10/15/2016 03:17 PM, Stephen Farrell wrote:
>>>>>
>>>>> Hi Niels,
>>>>>
>>>>> On 09/10/16 17:31, Niels ten Oever wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>
>>>>>>> (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 thin=
k it
>>>>>> would be great to come up with next steps for 5.3.2, such as bring=
ing it
>>>>>> into the IETF.
>>>>>
>>>>> Sorry, that's non-responsive to the main point: this is too
>>>>> long and the bit that's important for the claimed audience
>>>>> (IETFers) is buried at the end. I still suggest making that
>>>>> structural change. Why not?
>>>>
>>>> Because the authors intend to produce a seperate document geared
>>>> completely at providing considerations.
>>>
>>> Hmm. If that'd be an hrpc document then it'd fully
>>> overlap with this. If not, then what kind of document
>>> would that be? An IETF one? I think we're some way
>>> from being ready for that tbh.
>>>
>>
>> IETF one, and I think we're indeed still some time away from that.
>>
>>> Anyway, doesn't that mean the comment stands for this
>>> document? Producing another document doesn't answer
>>> the point raised about the structure of this one.
>>>
>>
>> And I think my point also still stands. It is logical to put=20
>> the conclusion of the research, after the research overview, at the=20
>> bottom. At least in a Research Document (which is what we're=20
>> developing here).
>=20
> Many things are logical but unwise.
>=20
> The length of this document and the target audience make
> the current structure unwise.
>=20
> I think in the above argument you also seem to be changing
> the target audience a bit, moving from protocol developers
> (IETFers) to those interested in reading about research.
> Both are valid but very different target audiences.
>=20

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

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


>>
>>
>>>
>>>>>>> (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 =E2=80=93 a=
s 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: =E2=80=98=
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 definitio=
n is
>>>>>> partly based on the consensus understanding of the term architectu=
re as
>>>>>> laid out in RFC RFC1958 section 2.1, which states: =E2=80=98Many m=
embers 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 commun=
ity
>>>>>> 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 sh=
ow
>>>>>> 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 provid=
ers,
>>>>>> and flourishes in the increasingly liberal and competitive commerc=
ial
>>>>>> telecommunications environment. The key to global connectivity is =
the
>>>>>> inter-networking layer.  The key to exploiting this layer over div=
erse
>>>>>> hardware providing global connectivity is the "end to end argument=
=E2=80=99.
>>>>>> Building on RFC1958 we hold that the word architecture, in the con=
text
>>>>>> of the IETF, refers to all the protocols, procedures, processes an=
d
>>>>>> their accompanying people and politics that go into ensuring the
>>>>>> Internet remains a medium for unfettered global connectivity.=E2=80=
=99 Would
>>>>>> such a definition clarify our use of the word architecture suffici=
ently?
>>>>>
>>>>> No, I think that's worse tbh, as will any attempt to define "the
>>>>> Internet architecture" most likely. Others may disagree but I think=

>>>>> by far the best thing here is to remove as many uses of the term as=

>>>>> possible and to carefully say exactly what's meant in any remaining=

>>>>> cases (and I bet you'll find remaining cases mean different things)=
=2E
>>>>
>>>> Why is it worse?
>>>
>>> Because I don't think it's likely an RG-consensus definition
>>> of "Internet architecture" but even more important I think
>>> this document doesn't have to depend on their being such a
>>> consensus definition. (Just because there's a hole beside
>>> us doesn't mean we need to dig it deeper:-)
>>>
>>
>> I am not sure if this point is widely shared. Would love to=20
>> hear from others. For me the way it is used does not seem=20
>> problematic. Perhaps you could point out more specifically where you=20
>> see problems (except in process)?
>=20
> Didn't I do that in the detailed comments? Thought I had
> anyway.
>=20

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

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

You think it's too broad to be meaningful?

>>
>>>>
>>>>>>
>>>>>> Additionally, we would like to push back a bit against the argumen=
t that
>>>>>> because there is no consensus in the IETF on what the term archite=
cture
>>>>>> 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 definit=
ions
>>>>>> from academia as we do in the text by referring to amongst others =
the
>>>>>> work of Prof. Denardis and Prof. Bowker on architecture.
>>>>>
>>>>> Sorry, "pushing boundaries" is just fine, but one is not doing that=

>>>>> by using ill-defined terms in ill-defined ways. I also don't think
>>>>> hrpc is a good venue for trying to define this particular term, nor=

>>>>> do I think such an activity is interesting or fruitful. Much better=

>>>>> to avoid use of the ill-defined term where it's not needed, which
>>>>> is almost everywhere IMO.
>>>>>
>>>>
>>>> Well, we're providing references to infrastructure scholars, so am n=
ot
>>>> so sure about ill-defined. Could you be a bit more precise in your
>>>> objection?
>>>
>>> More precise than "you don't need it, and you've not defined
>>> it in a way that I think would garner consensus"? :-)
>>>
>>> I'd again encourage you to try not use the term at all as it's
>>> not needed.
>>>
>>
>> Pls show me how it is ill-defined, cause I do not see it. But this=20
>> might be me of course!
>=20
> Assuming there exists one true definition for the Internet
> architecture is problematic. You already reference RFC1958
> which says "The principle of constant change is perhaps the
> only principle of the Internet that should survive indefinitely."
> and which begins it's section 2.1 by saying "Many members of the
> Internet community would argue that there is no architecture..."
> While 1958 does go on to talk more about that (the that in
> question being the topic of the RFC:-) I do not believe that
> the core situation has changed over the last 20 years.
>=20
> As to showing, I believe I did that in the original detailed
> comments. (Would have to check though.)
>=20

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

>=20
>>
>>
>>>>
>>>>>>
>>>>>>
>>>>>>> (4) What does "=3D" mean here?
>>>>>>>
>>>>>>> In section 2 and later (in 5.2.2) you have diagrams with
>>>>>>> bracketed terms on the left, then "=3D" and then another term on
>>>>>>> the right. I just don't get what you mean by that "=3D" 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,
>>>>>
>>>>> Correct:-)
>>>>>
>>>>>> would
>>>>>> be: depends on the usecase. If we for instance take the example of=
 TLS
>>>>>> for .onion websites, there the security model includes anonymity a=
s well
>>>>>> as authenticity.
>>>>>
>>>>> No, the security model of TLS does not include anonymity. The secur=
ity
>>>>> model of Tor does. It's important to be precise like that I think i=
n
>>>>> this document. These uses of "=3D" or "=3D=3D=3D>" are nowhere near=
 precise IMO.
>>>>>
>>>>
>>>> Because a function arrow doesn't seem in place here, or...?
>>>
>>> I answered that above. Regardless of the symbol there's a
>>> lack of precision in the concepts here but the presentation
>>> implies that such precision exists. See the TLS/Tor text
>>> just above.
>>>
>>>>
>>>>>>
>>>>>> I think it can easily be argued than in many models of security, p=
rivacy
>>>>>> and anonymity play a role, in others anonymity may be less importa=
nt.
>>>>>
>>>>> It can be argued yes. That argument is wrong where it comes to
>>>>> anonymity which is a very very hard goal to even approach.
>>>>>
>>>>>>
>>>>>> To reflect this I changed the text to:
>>>>>>
>>>>>> A combination of reliability, confidentiality, integrity, anonymit=
y, and
>>>>>> authenticity is what makes up security on the Internet.
>>>>>
>>>>> I think that is still plain wrong in multiple ways, but certainly
>>>>> wrt anonymity.
>>>>>
>>>>
>>>> Why? Because anonymity is never part of any definition or concept of=

>>>> security? That doesn't make sense to me.
>>>
>>> I think we'd agree TLS is currently the most important
>>> security protocol widely used on the Internet. TLS has
>>> no concept of anonymity. Saying that "a,b,c, anonymity, e
>>> and f is what makes up security on the Internet" is IMO
>>> therefore wrong, for all a,b,c, e and f.
>>>
>>> Another issue with "anonymity" is that it's not at all
>>> clear what you might mean by that. Is the use of a source
>>> IP address allowed? What about a MAC address? What about
>>> identifiers in client certificates? What about a TLS
>>> session ticket? And all of those are just TLS examples.
>>>
>>> Any the "is what makes up" just seems like arm-waving.
>>> I really am not seeing how we benefit from making such
>>> ostensibly definitive (mis)statements. (While at the
>>> same time being fine that such constructs were found
>>> useful when organising the work earlier on.)
>>>
>>>
>>>>>>> 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 "=3D" 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 be=
tween
>>>>>> the LHS and the RHS should be 'contribute to an enabling environme=
nt
>>>>>> for', so I replaced the '=3D' with '=E2=87=92' and added an explan=
ation.
>>>>>
>>>>> TBH, I think those diagrams have outlived their usefulness and
>>>>> could just be deleted or moved to an appendix only about the
>>>>> method used in this work that does not claim that these relations
>>>>> are well defined. (See also my point (2) above about structure.)
>>>>
>>>> I think they have a clear role in the methodology as described, and
>>>> therefore fit in this research document.
>>>
>>> Yes, those may have been helpful in doing the work. That
>>> does not mean it is helpful to present them as if they
>>> are defining precise relationships, as they are not. Hence
>>> my suggestion to move them to an appendix and present
>>> them there as a tool that was used in the research and
>>> not as (seems to me to be the case) as some results of
>>> the work that define precise relationships.
>>>
>>
>> OK - created a table as suggested by Joe and removed the formulas.=20
>> Hope that this will provide more clarity.
>=20
> The tables are better than the formulae. I continue to
> disagree with the "is what makes up" statement.
>=20

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


>>
>>>>
>>>>
>>>>>
>>>>>>>
>>>>>>> (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 an=
alysis
>>>>>> a case of technology and it's impact human rights. So, it has a
>>>>>> completely different role from RFC3552, even though the conclusion=
s are
>>>>>> largely the same.
>>>>>
>>>>> That is non-responsive to the main point here. The scope of
>>>>> the DDoS discussion is still wrong. Can you respond to the
>>>>> main point?
>>>>>
>>>>
>>>> I thought I responded to your main point, could you else rephrase it=
? It
>>>> also rewrote it a bit, maybe that helps:
>>>>
>>>> DDoS attacks can thus stifle freedom of expression, complicate the
>>>> ability of independent media and human rights organizations to exerc=
ise
>>>> their right to (online) freedom of association, while facilitating t=
he
>>>> ability of governments to censor dissent.  When it comes to comparin=
g
>>>> DDoS attacks to protests in offline life, it is important to remembe=
r
>>>> that only a limited number of DDoS attacks involved solely willing
>>>> participants. In most cases, the clients are hacked computers of
>>>> unrelated parties that have not consented to being part of a DDoS (f=
or
>>>> exceptions see Operation Abibil {{Abibil}} or the Iranian Green Move=
ment
>>>> DDoS {{GreenMovement}}). In addition, DDoS attacks are increasingly =
used
>>>> as an extortion tactic.
>>>>
>>>>
>>>>
>>>> All of these issues seem to suggest that the IETF should try to ensu=
re
>>>> that their protocols cannot be used for DDoS attacks, which is
>>>> consistent with the long-standing IETF consensus that DDoS is an att=
ack
>>>> that protocols should mitigate them to the extent they can {{BCP72}}=
=2E
>>>> Decreasing the number of vulnerabilities in protocols and (outside o=
f
>>>> IETF) the number of bugs in the network stacks of routers or compute=
rs
>>>> could address this issue. The IETF can clearly play a role in bringi=
ng
>>>> about some of these changes but the IETF cannot be expected to take =
a
>>>> positive stance on (specific) DDoS attacks, or create protocols to
>>>> enable some attacks and inhibit others. What the IETF can do is
>>>> critically reflect on its role in the development of the Internet, a=
nd
>>>> how this impacts the ability of people to excercise their human righ=
ts,
>>>> such as freedom of expression.
>>>
>>> Ok, fair enough, that is better.
>>>
>>> I still think "limited number" and "in most cases" misrepresent
>>> the reality though which is that maybe 99.999% of DDoS attacks
>>> involve zombies.
>>>

Changed it into:

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


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

That is the conclusion of these three paras.

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

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

>>> So I still think the above text could be improved but it's
>>> no longer a show-stopper for me.
>=20
> Note that the above is still a comment on the draft. Just
> because I don't think it a show-stopper doesn't mean that
> it's good to ignore.
>=20

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


>>>
>>>>>>> (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 pres=
ented
>>>>>> the outcomes at the session in Berlin and were also posted to the =
list.
>>>>>
>>>>> Can you send links to those please? I don't recall those as having
>>>>> used the questions as listed but I may be mis-remembering. I still
>>>>> find some of the questions non-useful for the intended audience
>>>>> but of course I may be wrong or an outlier there.
>>>>>
>>>>
>>>> Presentation of Shane and Giovane at IETF:
>>>>
>>>> http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF96_H=
RPC&chapter=3Dchapter_1
>>>>
>>>
>>> Didn't have time for that sorry.
>>>
>>>> their earlier emails to the list:
>>>>
>>>> https://mailarchive.ietf.org/arch/msg/hrpc/gmKmE0Uw35vK249zNLvBcBk7v=
i4
>>>
>>> Quoting from that:
>>>
>>> "
>>> Conclusion
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> My own feeling is that while this checklist is helpful in the current=

>>> form, it should probably be shortened and clarified."
>>>
>>>>
>>>> https://mailarchive.ietf.org/arch/msg/hrpc/OJKXq7Yq3AwX4j3Yv0Oi32MTz=
V8
>>>>
>>>> https://mailarchive.ietf.org/arch/msg/hrpc/ZPvhLL0pj2vJxkVFKW3qM-sts=
oE
>>>
>>> There Giovane said a bunch of the questions were not
>>> relevant to him. (I'm not clear what the diference
>>> between the two postings from his is btw, but that's
>>> probably ok.)
>>>
>>> Honestly, I'm not seeing "exhaustive," and I maintain my
>>> position that a number of the questions won't have any good
>>> answers for the intended audience.
>>>
>=20
> No response?
>=20

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

>>>
>>>>>>> (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 al=
so no
>>>>>> consensus in the law community about how this should be done. Ther=
e are
>>>>>> many scholarly papers written about this, and I would large go wit=
h the
>>>>>> approach in the UN Guiding Principles for Business and Human Right=
s. So
>>>>>> I would offer the following text:
>>>>>>
>>>>>>     Human rights can be in conflict with each other, such as the r=
ight
>>>>>> 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 pro=
cess
>>>>>> tangible and practical for protocol developers is what this resear=
ch
>>>>>> aims to ultimately contribute to.
>>>>>
>>>>> I like that text, thanks. I'd suggest adding a bit of text to
>>>>> cover what I think might be a misinterpretation that could be
>>>>> common for the more literal-minded typical IETFer such as
>>>>> myself:-) Something like:
>>>>>
>>>>> "The fact that rights can always be in conflict with one another
>>>>> means that all human rights are contingent and none are absolute.
>>>>
>>>> This is not true. Torture is for instance always prohibited. We woul=
d
>>>> get here into concepts of proportionality and necessity (and perhaps=

>>>> even legal accountability), which would imho only make the text more=
,
>>>> not less complex for literal-minded types (and the non-literal-minde=
d
>>>> types alike).
>>>
>>> I'm more interested that the point below be included and don't
>>> mind how that's introduced.
>>>
>>>>
>>>>> So, for example, if one posited a "right to encrypt" as a human
>>>>> right that inherently means accepting that there are times when
>>>>> that "right" would lose out in balancing of conflicting rights.
>>>>> That means that there are technical concepts (e.g. arithmetic,
>>>>> the ability to write code), the free exercise of which may be
>>>>> better protected if they are not specifically claimed as human
>>>>> rights."
>>>>
>>>> I see what you're trying to do here, but I think this is for another=

>>>> document.
>>>
>>> FWIW, I think it's important to include that point in this
>>> document, given what I know of IETFers.
>>>
>>
>> OK - so let's get a bit deeper into this. We're saying that security=20
>> is a human rights.=20
>=20
> I don't think that statement is in the draft. And while that
> sentence may be one stated in various HR contexts, I don't
> think that anyone has a good understanding of the mapping of
> that to technical concepts that are meaningful to IETFers.
> See the TLS/anonymity comments above.
>=20

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


>> We're not saying that encryption is a human=20
>> rights, only that encryption can enable a specific human right. That=20
>> is as far as we go here.=20
>=20
> Again. You don't currently say that in the draft. (And nor
> should you I think.)

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

>=20
>> I do not think that saying 'a specific=20
>> technology is a human right' makes much sense, because it is context=20
>> dependent. I do think privacy is a human rights and therefore we=20
>> should use encryption.  And that is the point we're making imho. But=20
>> maybe you see that differently?
>=20
> I think you're missing my point so I'll try again.
>=20
> There is a risk that IETFers take a very literal approach to
> the topic of considering human rights and as a result argue
> that anything they consider "good" is a human right. This
> draft should, I think, help avoid that by describing at least
> one major pitfall in such an approach. And I think the example
> of encryption is a good one to use for this.
>=20

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

Cheers,

Niels


> Cheers,
> S.
>=20
>=20
>>
>> I hope that with this we can now start the Research Group Last Call.
>>
>> Cheers,
>>
>> Niels
>>
>>
>>> Cheers,
>>> S.
>>>
>>>>
>>>>>
>>>>> (As an aside, it's interesting that you are sensitive here to
>>>>> the difficultly of establishing consensus on this topic, whereas
>>>>> I am not. And then we reverse roles when it comes to "Internet
>>>>> architecture." Not that surprising I guess:-)
>>>>
>>>> Well, there seems to be more consensus on Internet architecture than=

>>>> this, at least as far as I could find, but am happy to be convinced =
(in
>>>> both cases).
>>>>
>>>> Cheers,
>>>>
>>>> Niels
>>>>
>>>>>
>>>>>>
>>>>>>> Specific comments (without reference to importance:-)
>>>>>
>>>>> Will get back to these later, when I get time.
>>>>>
>>>>> Cheers,
>>>>> S.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> hrpc mailing list
>>>> hrpc@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>>
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>=20


--NgwUJrcX8nUmHGrNQH5L6WIiOc3WMWDUI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYDWxnAAoJEAi1oPJjbWjphSEH/0uSyGoHUYOy7SXUAtAzz9Kt
rFkGCDdVt5V7CV5qq74tTizTLfjr+3U/ik3VnB1XgojCLlk55F33JDosBDhvEQix
6tfEQ3QMGYFbc8OWHlAnkWO+YddO3dxiRNhoiKUgXnDf99z3QNzdLu61G8tVdhUF
TezVmqKuTDIcEO2swKHUELcGSXbtvWR0g6Ijsiz3NDjclTZnDh3blcoAHydONSaL
fnRiTe6McOn/xU1bQ0YDj4+rnKR9yt4GSTiDYYE8Opnda/012E8iWyk8yyrsFRAL
i/hRRqzZMCXGA4Vl6foBmk3v5be/AEnGed9tiL6qyT5DlfK7Fcnmn/7TGFpAZWc=
=KVeX
-----END PGP SIGNATURE-----

--NgwUJrcX8nUmHGrNQH5L6WIiOc3WMWDUI--


From nobody Thu Oct 27 13:25:13 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808A81294B7 for ; Thu, 27 Oct 2016 13:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h_nmDbLOA2k for ; Thu, 27 Oct 2016 13:25:10 -0700 (PDT)
Received: from mail.article19.io (mail.article19.io [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7760912953E for ; Thu, 27 Oct 2016 13:25:10 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id C339A14C9B40 for ; Thu, 27 Oct 2016 20:25:08 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id B35271624FB9 for ; Thu, 27 Oct 2016 20:25:08 +0000 (UTC)
Received: from [192.168.1.80] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 9C5DB14C9B40 for ; Thu, 27 Oct 2016 20:25:08 +0000 (UTC)
To: "hrpc@irtf.org" 
From: Niels ten Oever 
X-Enigmail-Draft-Status: N1110
Message-ID: <988d83ef-94ab-48b4-b277-396b172e98ba@article19.org>
Date: Thu, 27 Oct 2016 22:25:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TnhEqxxCkQKmqlGxoJ7qOHoGxFEqENopT"
Archived-At: 
Subject: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2016 20:25:12 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TnhEqxxCkQKmqlGxoJ7qOHoGxFEqENopT
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

Unfortunately both our speakers for the hrpc session (Francesca Musiani
and Sarah Spiekerman) have canceled their presentation for the hrpc
session due to timezone constraints.

It would be great if others could help us suggest (and find) two other
speakers that could help us broaden our horizon and get a better
understanding of the relationship between human rights and standards in
specific and technology in general.

All suggestions would be appreciated.

Best,

Niels
--=20
Niels ten Oever
Head of Digital

Article 19
www.article19.org

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


--TnhEqxxCkQKmqlGxoJ7qOHoGxFEqENopT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYEmKkAAoJEAi1oPJjbWjpIloH/j+mcU8fVtBij+67S9V5ojLa
OfceEAEXLBxb8E/TtqQgiGlcDoVDnpbL3nesHsppgVEPHfgWPAyu8jsAxaZlISos
T/Bvb4n/y0AspYPJt+01VChyTMokL/PvlAHSZ6idyRlkerHKLD14xWpVZgG//aUJ
sNTMig3tvXgqeTy8kfrjBPPc5Uht3MMG3GRc57keGZ2WN/BwFqqh88g2mQ9NEMqp
h7fiZfcRvLV31dzRenH9N/paC7Kk5upiSXQve4PR/CpjkexrKxF/AAEFlLVeL0QK
Pd6JIDCyOnEgs/TYsBKfTZr1zeLSB/tRU8XlyHRIIvnvRHkb+t8EGZv9bwrSNEA=
=7wob
-----END PGP SIGNATURE-----

--TnhEqxxCkQKmqlGxoJ7qOHoGxFEqENopT--


From nobody Thu Oct 27 13:25:18 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B45A12953E for ; Thu, 27 Oct 2016 13:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hkxsOLmAyVS for ; Thu, 27 Oct 2016 13:25:11 -0700 (PDT)
Received: from mail.article19.io (mail.article19.io [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7762A129585 for ; Thu, 27 Oct 2016 13:25:10 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id BBA331C1829 for ; Thu, 27 Oct 2016 20:25:08 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id A9BC014C9B6A for ; Thu, 27 Oct 2016 20:25:08 +0000 (UTC)
Received: from [192.168.1.80] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 991BA1C1829 for ; Thu, 27 Oct 2016 20:25:08 +0000 (UTC)
To: "hrpc@irtf.org" 
From: Niels ten Oever 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Thu, 27 Oct 2016 22:25:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PilInshoigAJj0BigBx4q88a2d78uiTQF"
Archived-At: 
Subject: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2016 20:25:14 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PilInshoigAJj0BigBx4q88a2d78uiTQF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

Unfortunately both our speakers for the hrpc session (Francesca Musiani
and Sarah Spiekerman) have canceled their presentation for the hrpc
session due to timezone constraints.

It would be great if others could help us suggest (and find) two other
speakers that could help us broaden our horizon and get a better
understanding of the relationship between human rights and standards in
specific and technology in general.

All suggestions would be appreciated.

Best,

Niels
--=20
Niels ten Oever
Head of Digital

Article 19
www.article19.org

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


--PilInshoigAJj0BigBx4q88a2d78uiTQF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYEmKkAAoJEAi1oPJjbWjpIloH/j+mcU8fVtBij+67S9V5ojLa
OfceEAEXLBxb8E/TtqQgiGlcDoVDnpbL3nesHsppgVEPHfgWPAyu8jsAxaZlISos
T/Bvb4n/y0AspYPJt+01VChyTMokL/PvlAHSZ6idyRlkerHKLD14xWpVZgG//aUJ
sNTMig3tvXgqeTy8kfrjBPPc5Uht3MMG3GRc57keGZ2WN/BwFqqh88g2mQ9NEMqp
h7fiZfcRvLV31dzRenH9N/paC7Kk5upiSXQve4PR/CpjkexrKxF/AAEFlLVeL0QK
Pd6JIDCyOnEgs/TYsBKfTZr1zeLSB/tRU8XlyHRIIvnvRHkb+t8EGZv9bwrSNEA=
=7wob
-----END PGP SIGNATURE-----

--PilInshoigAJj0BigBx4q88a2d78uiTQF--


From nobody Thu Oct 27 15:30:09 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E7312944D for ; Thu, 27 Oct 2016 15:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.255
X-Spam-Level: 
X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7_jXVyU4xF4 for ; Thu, 27 Oct 2016 15:30:07 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9031294C4 for ; Thu, 27 Oct 2016 15:30:06 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 94F563521D6 for ; Thu, 27 Oct 2016 22:30:05 +0000 (UTC)
X-Session-Marker: 6176726940646F7269612E6F7267
X-Spam-Summary: 2, -15, 0, , d41d8cd98f00b204, avri@acm.org, ::, RULES_HIT:41:355:379:599:800:854:871:967:973:988:989:1000:1260:1261:1313:1314:1345:1359:1381:1437:1516:1518:1534:1541:1575:1594:1711:1730:1747:1777:1792:1963:2194:2198:2199:2200:2393:2525:2553:2560:2563:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4362:4860:5007:6117:6506:6747:6748:7281:7652:7903:7909:8660:9010:9025:9108:10004:10848:11232:11604:11658:11914:12043:12291:12379:12438:12683:12740:13019:13148:13161:13229:13230:13846:14095:14096:14180:14181:14227:14658:14659:14721:21060:21063:21080:21212:21324:21433:21450:30054:30060, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:2, LUA_SUMMARY:none
X-HE-Tag: shop80_3af2135939614
X-Filterd-Recvd-Size: 3719
Received: from [127.0.0.1] (wsip-68-15-42-104.ri.ri.cox.net [68.15.42.104]) (Authenticated sender: avri@doria.org) by omf01.hostedemail.com (Postfix) with ESMTPA for ; Thu, 27 Oct 2016 22:30:04 +0000 (UTC)
References: 
To: hrpc@irtf.org
From: avri doria 
Message-ID: <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>
Date: Thu, 27 Oct 2016 18:29:59 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="75stH0x42Ndq4MwnLMV6EBlXS8noV7bp8"
X-Antivirus: avast! (VPS 161027-2, 10/27/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: avri@acm.org
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2016 22:30:08 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--75stH0x42Ndq4MwnLMV6EBlXS8noV7bp8
Content-Type: multipart/mixed; boundary="7tcSpJbhBigP0Gx2SU2hPpu1LOWJ2nuVN";
 protected-headers="v1"
From: avri doria 
Reply-To: avri@acm.org
To: hrpc@irtf.org
Message-ID: <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>
Subject: Re: [hrpc] speakers canceled, suggestions requested
References: 
In-Reply-To: 

--7tcSpJbhBigP0Gx2SU2hPpu1LOWJ2nuVN
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

I think that we could well spend the meeting discussing the remaining
open issues in draft-irtf-hrpc-research-03.txt.=20

I have avoided starting the last call because I do not think have have
reached a stable consensus point with the document, though I do see the
changes being made. I must admit that I still do not see consensus and
still do not hear enough voices to let me figure out where the rough is.

In prep I would like to build of list of still contentious points and
walk through them in the face to face situation.  Would that seem ok to
the rest of you?

thanks

avri


On 27-Oct-16 16:25, Niels ten Oever wrote:
> Hi all,
>
> Unfortunately both our speakers for the hrpc session (Francesca Musiani=

> and Sarah Spiekerman) have canceled their presentation for the hrpc
> session due to timezone constraints.
>
> It would be great if others could help us suggest (and find) two other
> speakers that could help us broaden our horizon and get a better
> understanding of the relationship between human rights and standards in=

> specific and technology in general.
>
> All suggestions would be appreciated.
>
> Best,
>
> Niels
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc



--7tcSpJbhBigP0Gx2SU2hPpu1LOWJ2nuVN--

--75stH0x42Ndq4MwnLMV6EBlXS8noV7bp8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYEn/oAAoJEOo+L8tCe36HiYkH/2JKNBEntlwmwwNHG1G3ow38
X78E5aNaVilr2DFWLLqqPIzDHPYbdYvdSWXpJ0mZTkkegKxFg3HlKm3siA8OY/6z
xNS4abysOCjxUAsaAWqf8D47mKn0wwVA9pml1ZlMiJbAcOnJU/DqYCWZoHW8kxk5
dQWKwBi854HXSCziMOIXAQH13yHOu9FhffQgC3cMF9YACy2Mo3hUOds1NELCcCLX
9XNvicj1fNgASDYznlMYRFM/9ejdKPHBVBaAVmjPC6XAqWIE2Ayw0ffhtHi3V0KQ
AhJlK3f8Ok2bDqVfLCaaF6t0cAIZ8m1QO3rsTw+GRcntaG1wx+XWFfTRbP4gvRg=
=KS/A
-----END PGP SIGNATURE-----

--75stH0x42Ndq4MwnLMV6EBlXS8noV7bp8--


From nobody Thu Oct 27 16:49:42 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801B01296E4 for ; Thu, 27 Oct 2016 16:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.732
X-Spam-Level: 
X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mGmEsymQ760 for ; Thu, 27 Oct 2016 16:49:39 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2651295FE for ; Thu, 27 Oct 2016 16:49:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BAC21BE2F; Fri, 28 Oct 2016 00:49:36 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvX_T05Lk16I; Fri, 28 Oct 2016 00:49:35 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8C8C5BE32; Fri, 28 Oct 2016 00:49:34 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1477612175; bh=P7Iyz9xnuFJPLYCV0fJgZ/Ot8QaMHTHAafEtWI6GzbM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=H2ZW1Ziv9cna1hgRvL4IiuHx0tDwlNPYcrK9hgEWpr4CPaVW6/sgRRer6BexVLsnr yyONK7XOqo4xAlklVDjCm3C5/ODLtSziQQCbNbn3Wdfqo1Kn334jI16/N41sinraDD HCTkIWoZU4CeRfQZJ1asBPeoUTjdUvxPgz9kFI8s=
To: avri@acm.org, hrpc@irtf.org
References:  <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: 
Date: Fri, 28 Oct 2016 00:49:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="95Cwun76hLfRIJ7b6SdmGRVNdLs6w1Kn3"
Archived-At: 
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Oct 2016 23:49:41 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--95Cwun76hLfRIJ7b6SdmGRVNdLs6w1Kn3
Content-Type: multipart/mixed; boundary="r7dfL8cpUi1KD2fpmjs3ocohlmhw4FpRJ";
 protected-headers="v1"
From: Stephen Farrell 
To: avri@acm.org, hrpc@irtf.org
Message-ID: 
Subject: Re: [hrpc] speakers canceled, suggestions requested
References: 
 <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>
In-Reply-To: <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>

--r7dfL8cpUi1KD2fpmjs3ocohlmhw4FpRJ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 27/10/16 23:29, avri doria wrote:
> Hi,
>=20
> I think that we could well spend the meeting discussing the remaining
> open issues in draft-irtf-hrpc-research-03.txt.=20
>=20
> I have avoided starting the last call because I do not think have have
> reached a stable consensus point with the document, though I do see the=

> changes being made. I must admit that I still do not see consensus and
> still do not hear enough voices to let me figure out where the rough is=
=2E
>=20
> In prep I would like to build of list of still contentious points and
> walk through them in the face to face situation.  Would that seem ok to=

> the rest of you?

Yes. Replacing speakers with issue-resolution does sound a bit
more boring but much better use of f2f time;-)

Ta,
S.


>=20
> thanks
>=20
> avri
>=20
>=20
> On 27-Oct-16 16:25, Niels ten Oever wrote:
>> Hi all,
>>
>> Unfortunately both our speakers for the hrpc session (Francesca Musian=
i
>> and Sarah Spiekerman) have canceled their presentation for the hrpc
>> session due to timezone constraints.
>>
>> It would be great if others could help us suggest (and find) two other=

>> speakers that could help us broaden our horizon and get a better
>> understanding of the relationship between human rights and standards i=
n
>> specific and technology in general.
>>
>> All suggestions would be appreciated.
>>
>> Best,
>>
>> Niels
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>=20
>=20
>=20
>=20
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>=20


--r7dfL8cpUi1KD2fpmjs3ocohlmhw4FpRJ--

--95Cwun76hLfRIJ7b6SdmGRVNdLs6w1Kn3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYEpKOAAoJEC88hzaAX42iMFoIAIMyuEcQlkt3EGXnyRaE3yRs
JmZXSCVSLGQp/RQtSvHTNmIxh2k87F6yKetoUH1aZPJodGMcMDDwRyoUHEns2B8n
t+eGk6msOb4oaC9wavmET3ajeIN0rFNdNWUtUS9dOLt4AAOcseCfftptoz9VtnNF
o/zRbHIxb8+BMrayoiJdUku5ngd6JORJO1eLMeAq06iBXi9PAC/VVtCYQIYO3Iue
Wfmd14Dg+ij9KRF2ZLNndTL1Wp6sOGlOG5noCFXWqp6bFiC1bk3h9xWsr6eI8Uij
Tw+VuiqE89sPabuJk1wz9ET+Y52MYBCg1updxpLV8TYo/1DrkkA3YtJQ+9kEAsw=
=FVhb
-----END PGP SIGNATURE-----

--95Cwun76hLfRIJ7b6SdmGRVNdLs6w1Kn3--


From nobody Thu Oct 27 21:44:45 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F101295CE for ; Thu, 27 Oct 2016 21:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0nWQG8rM_-3 for ; Thu, 27 Oct 2016 21:44:43 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E421295AC for ; Thu, 27 Oct 2016 21:44:42 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id 51so28110812uai.1 for ; Thu, 27 Oct 2016 21:44:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q3RwB2Zb8G56weiBHfE9qR8k4pN36q+B9fCujW/TxUQ=; b=rMJokciOgYuqGpLRFwJ/RlxLlzO0a89Fb92TC8pInKplMs5n/i2uOOySl9gnSRpLg5 7vOpbmYI4oBcrAlZIf68m75qYhP+MasHvezIq6ngXahSmkpfSEittaSboD++g1mGyyle 4vmKTUNZOl5T6zvBCP2bcbVG/kP2/HcSu3BTo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q3RwB2Zb8G56weiBHfE9qR8k4pN36q+B9fCujW/TxUQ=; b=A3OJA+HV+h3o64jsJJdgexmxBEOUEzxjTrC1tXI+PbGTZW77YlIgIO/MVEeFA23hkU O0lStQffFgu0WwS3KmoaqNqxxd65j3IQ77bmXfMmUSGaHFDp9y0UiNUJrj7Sp3JPw00x WBktdkO4ZJdp0TznuaXxrgRZS/crJKpTYgVFD/0TOaAXrdg1e3MknVoSuM9A0/p/byuy gbUB2z/bKdojap4juQGXgiLwxvioFxyfr3hrsd+PxL7iIjzkyaZfODqXDGnVs8ggWY92 UvmwTIFAHWrLPV8m/lYvap3k3GbEx1nfyxbW8iNKDFVgoCZ+vHSM1T+6RNfW2icYZhEW PX1g==
X-Gm-Message-State: ABUngve5U32ijUoK5g4Zv7lNVbno27tsGfimGACCdz/SAMIkvOwoyBCNfSxTPMmEbAoMHjN4ENR+qn8ZgvnLUUXe
X-Received: by 10.176.66.103 with SMTP id i94mr9526351uai.166.1477629881761; Thu, 27 Oct 2016 21:44:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.33.208 with HTTP; Thu, 27 Oct 2016 21:44:21 -0700 (PDT)
In-Reply-To: 
References:  <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org> 
From: Joseph Lorenzo Hall 
Date: Thu, 27 Oct 2016 21:44:21 -0700
Message-ID: 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Avri Doria , hrpc@irtf.org
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Oct 2016 04:44:45 -0000

I was hoping to get to RGLC sooner than that, but I'd be definitely
down to have more of a working session too, as I think we can work
through a lot of this better synchronously f2f. best, Joe

On Thu, Oct 27, 2016 at 4:49 PM, Stephen Farrell
 wrote:
>
>
> On 27/10/16 23:29, avri doria wrote:
>> Hi,
>>
>> I think that we could well spend the meeting discussing the remaining
>> open issues in draft-irtf-hrpc-research-03.txt.
>>
>> I have avoided starting the last call because I do not think have have
>> reached a stable consensus point with the document, though I do see the
>> changes being made. I must admit that I still do not see consensus and
>> still do not hear enough voices to let me figure out where the rough is.
>>
>> In prep I would like to build of list of still contentious points and
>> walk through them in the face to face situation.  Would that seem ok to
>> the rest of you?
>
> Yes. Replacing speakers with issue-resolution does sound a bit
> more boring but much better use of f2f time;-)
>
> Ta,
> S.
>
>
>>
>> thanks
>>
>> avri
>>
>>
>> On 27-Oct-16 16:25, Niels ten Oever wrote:
>>> Hi all,
>>>
>>> Unfortunately both our speakers for the hrpc session (Francesca Musiani
>>> and Sarah Spiekerman) have canceled their presentation for the hrpc
>>> session due to timezone constraints.
>>>
>>> It would be great if others could help us suggest (and find) two other
>>> speakers that could help us broaden our horizon and get a better
>>> understanding of the relationship between human rights and standards in
>>> specific and technology in general.
>>>
>>> All suggestions would be appreciated.
>>>
>>> Best,
>>>
>>> Niels
>>>
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>>
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>



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

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


From nobody Thu Oct 27 21:45:36 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2E8129584 for ; Thu, 27 Oct 2016 21:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOp0E_3ah0BS for ; Thu, 27 Oct 2016 21:45:31 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A39D129455 for ; Thu, 27 Oct 2016 21:45:31 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id 64so39901592uap.3 for ; Thu, 27 Oct 2016 21:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RHWUospESOc8//f0g/A/fdbkKZY4rKZlvDwHamTQKcE=; b=Z8i2MLvMhlpWuuphogd8iDc6ANcl7nhG/rgje9w3An+F1/UvgVWZ0WG08T0FaM44NA rICKEUDUuwbZQM++v1RJm5ed4zNRbDDaYMNC5976CfSx7zlKoag/cJavaQ/bx347riL2 d5HTO5X/Qi/M+dJ3dYiQ68um8r2Hl6KP9QkSw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RHWUospESOc8//f0g/A/fdbkKZY4rKZlvDwHamTQKcE=; b=GMH3HXGvH9sP5ZDHYx04pVEqBuvyfuUhjoarr0U+gNnsWwK8ufe5gUCNjRJMyj6Mgf DRm0N6sJ4pLK2YEzVAqzKwcG3kLg3Lj+y38drJI7GHLCrCTQyGzPkywZQBkpa9OBv5dK XKebIhnGJi9kCcU8WFHIUO17Rd5+h5jaUPZvCjPfh/wyBD2uhbiGFJZbuzy52D4zXS7O jriVE+jKBcPXSBGg0DNM46Pr3MR+5DxRPbSjLau5VL15FOACDevcWRlG6LnHD/P77afN 2fjMCCSaw0HJSrOomdZXEuD/uAIRBPb9+KKIvlSyt1GP8bwb3WDKFE278coGKM3NUE3f 5psQ==
X-Gm-Message-State: ABUngve6SAEHEL2i7iJvXinHU+pgqSb6ZOYnvL4eVdBJtXFbJFiY5vVT1EQoR3M19gXJLTvwPIL/OCDmzXPUcfVJ
X-Received: by 10.176.2.247 with SMTP id 110mr10731136uah.162.1477629930290; Thu, 27 Oct 2016 21:45:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.33.208 with HTTP; Thu, 27 Oct 2016 21:45:09 -0700 (PDT)
In-Reply-To: 
References:  <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>  
From: Joseph Lorenzo Hall 
Date: Thu, 27 Oct 2016 21:45:09 -0700
Message-ID: 
To: Stephen Farrell 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Avri Doria , hrpc@irtf.org
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Oct 2016 04:45:34 -0000

although I suspect Stephane may have particularly good ideas for
Asia-based HR-relevant potential speakers... maybe someone ping him?
best, Joe

On Thu, Oct 27, 2016 at 9:44 PM, Joseph Lorenzo Hall  wrote:
> I was hoping to get to RGLC sooner than that, but I'd be definitely
> down to have more of a working session too, as I think we can work
> through a lot of this better synchronously f2f. best, Joe
>
> On Thu, Oct 27, 2016 at 4:49 PM, Stephen Farrell
>  wrote:
>>
>>
>> On 27/10/16 23:29, avri doria wrote:
>>> Hi,
>>>
>>> I think that we could well spend the meeting discussing the remaining
>>> open issues in draft-irtf-hrpc-research-03.txt.
>>>
>>> I have avoided starting the last call because I do not think have have
>>> reached a stable consensus point with the document, though I do see the
>>> changes being made. I must admit that I still do not see consensus and
>>> still do not hear enough voices to let me figure out where the rough is.
>>>
>>> In prep I would like to build of list of still contentious points and
>>> walk through them in the face to face situation.  Would that seem ok to
>>> the rest of you?
>>
>> Yes. Replacing speakers with issue-resolution does sound a bit
>> more boring but much better use of f2f time;-)
>>
>> Ta,
>> S.
>>
>>
>>>
>>> thanks
>>>
>>> avri
>>>
>>>
>>> On 27-Oct-16 16:25, Niels ten Oever wrote:
>>>> Hi all,
>>>>
>>>> Unfortunately both our speakers for the hrpc session (Francesca Musiani
>>>> and Sarah Spiekerman) have canceled their presentation for the hrpc
>>>> session due to timezone constraints.
>>>>
>>>> It would be great if others could help us suggest (and find) two other
>>>> speakers that could help us broaden our horizon and get a better
>>>> understanding of the relationship between human rights and standards in
>>>> specific and technology in general.
>>>>
>>>> All suggestions would be appreciated.
>>>>
>>>> Best,
>>>>
>>>> Niels
>>>>
>>>>
>>>> _______________________________________________
>>>> hrpc mailing list
>>>> hrpc@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
>
> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>
> Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner



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

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


From nobody Fri Oct 28 05:02:42 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8DE12940E for ; Fri, 28 Oct 2016 05:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.214
X-Spam-Level: 
X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxoRl_5H7HNW for ; Fri, 28 Oct 2016 05:02:38 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206A3129AA7 for ; Fri, 28 Oct 2016 05:02:38 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 92D63352199 for ; Fri, 28 Oct 2016 12:02:36 +0000 (UTC)
X-Session-Marker: 6176726940646F7269612E6F7267
X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, avri@acm.org, :, RULES_HIT:41:152:355:379:387:599:854:967:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1437:1513:1515:1516:1518:1521:1534:1541:1593:1594:1711:1730:1747:1777:1792:2194:2199:2393:2525:2553:2560:2563:2682:2685:2691:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:4425:5007:6117:6119:7652:7903:8985:9025:9108:10004:10400:10848:11232:11658:11914:12043:12740:13069:13071:13161:13200:13229:13311:13357:13618:14096:14097:14180:14181:14721:14764:14777:21060:21212:21366:21433:21451:30022:30054, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:6, LUA_SUMMARY:none
X-HE-Tag: fish71_16bacceeae308
X-Filterd-Recvd-Size: 2667
Received: from [127.0.0.1] (wsip-68-15-42-104.ri.ri.cox.net [68.15.42.104]) (Authenticated sender: avri@doria.org) by omf06.hostedemail.com (Postfix) with ESMTPA for ; Fri, 28 Oct 2016 12:02:36 +0000 (UTC)
References:  <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>  
Cc: hrpc@irtf.org
From: avri doria 
Message-ID: <4744cc9d-3ea2-eca2-1f16-4ac90d381c0f@acm.org>
Date: Fri, 28 Oct 2016 08:02:31 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Antivirus: avast! (VPS 161027-2, 10/27/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: avri@acm.org
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Oct 2016 12:02:40 -0000

Hi,


On 28-Oct-16 00:44, Joseph Lorenzo Hall wrote:
> I was hoping to get to RGLC sooner than that, but I'd be definitely
> down to have more of a working session too, as I think we can work
> through a lot of this better synchronously f2f. best, Joe

I was too.  But there seem to still be unresolved issues, and I think
that we have to both have sufficient review in the RG and have settled
issues before going out for LC.  And while I know we can have multiple
LC, I think it is better to have something the group believes is ready
for publication before starting that first LC. 

The point of any all reviews is to improves the document. I think that
the pre LC conversations we are having now are helping to tighten the
draft and improve it.

RFC 5743 indicates that in the IRSG : "reviewers should assess whether
sufficient editorial and technical review has been conducted within the
RG and the requirements of this process document have been met, for
example, reviewers should evaluate whether the breadth of review the
document has received is adequate for the material at hand."

I want to make sure we meet that criteria before submitting it.


On 27-Oct-16 19:49, Stephen Farrell wrote:
> Yes. Replacing speakers with issue-resolution does sound a bit
> more boring but much better use of f2f time;-)

As the co-chair shepherding the doc in the RG, I have the honor of being
the 'bit more boring' co-chair. : )


avri
avri


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


From nobody Mon Oct 31 14:06:26 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09435129B16 for ; Mon, 31 Oct 2016 14:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FelSiKVaBzyy for ; Mon, 31 Oct 2016 14:06:22 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A2512941A for ; Mon, 31 Oct 2016 14:06:22 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id 20so98545022uak.0 for ; Mon, 31 Oct 2016 14:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fik6lojDoFxGwNOj3GmtsyiuVPvO0j5qK44YX8mt5Zk=; b=EADovPWLe79/tgXlI71GyonNgOgZvN4pW3lizrXRDzo09K1bsNP6H5j4I5Hb071Opz 3uW30QuVYfV4iXtU3i0aOvkeQX4SxSR5PdvmnMFmhodNOn/SxjITUOyG3QcY0TqIPIBX h1N1xNK6FPRbHIjeOkkBWENMvycdE5BSzsVp8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fik6lojDoFxGwNOj3GmtsyiuVPvO0j5qK44YX8mt5Zk=; b=h0iUThOnjMJCLUT3MelMvdHu36MB2OjyILQotZ9G6oxClnAtCihwwKhy+GPCMJTvDY eA2Logw45TKyoxnxhMlDy6GxGmwkP1hqXw5OfZHOvuGSk1jNng+KfNt37w2jHd41B/tu NBO7x4yX8kF1fpUcySjZkfVK2etkL7VA6cL76YB+2BjPRFRh9HqdmSzQThP6UA/oDE2J YiohB2dUAwvKXVsXS5YhkU1IlSuXzprWQ81c7dL49SEq4JLHpoot8qSRUxp6J6als3L/ /YixPiD4Qp5JRir6mOgKUOvBtpuhGNJWEal8ZYpMmG1HkF78azNssL0wB5x+TkYULRmP +Zug==
X-Gm-Message-State: ABUngvfXV2FaeNlrI7NZ6TjKzbaFp5eXkyWqhnZhB0513AqlcyIhYyAI/eg2b63tjBX8/nkV2xnjkkBnfb8V3Jjb
X-Received: by 10.176.83.92 with SMTP id y28mr24248902uay.128.1477947981613; Mon, 31 Oct 2016 14:06:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.33.208 with HTTP; Mon, 31 Oct 2016 14:06:01 -0700 (PDT)
In-Reply-To: <4744cc9d-3ea2-eca2-1f16-4ac90d381c0f@acm.org>
References:  <09f1c38b-2f4c-d067-5401-5a45da9eba66@acm.org>   <4744cc9d-3ea2-eca2-1f16-4ac90d381c0f@acm.org>
From: Joseph Lorenzo Hall 
Date: Mon, 31 Oct 2016 17:06:01 -0400
Message-ID: 
To: Avri Doria 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2016 21:06:25 -0000

On Fri, Oct 28, 2016 at 8:02 AM, avri doria  wrote:
>
> On 27-Oct-16 19:49, Stephen Farrell wrote:
>> Yes. Replacing speakers with issue-resolution does sound a bit
>> more boring but much better use of f2f time;-)
>
> As the co-chair shepherding the doc in the RG, I have the honor of being
> the 'bit more boring' co-chair. : )

All this being said, it would be great to have at least one speaker
with a modest slot (15-20m)... I've heard a few people (I think
Stephane was one of them) say that we "get different perspectives
about human rights issues in Asia when meetings are held there".

I probably have a very sparse set of contacts for human rights issues
in networking technologies based out of the Asian/ASEAN -- and those I
do have would probably be somewhat controversial. It would be great to
try and get someone who could speak to protocols and human rights and
then do the balance of the session in "bit more boring" mode. :)

best, Joe

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

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


From nobody Mon Oct 31 14:47:55 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E5D129B54 for ; Mon, 31 Oct 2016 14:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=privaterra.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGEAC_5I1HYr for ; Mon, 31 Oct 2016 14:47:47 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBFA129B36 for ; Mon, 31 Oct 2016 14:47:47 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id o68so179584815qkf.3 for ; Mon, 31 Oct 2016 14:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=privaterra.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2/47VBCLw/39dtYEI2tUVIyeRxuMRI3QygRcFXgJtWY=; b=MDLqVpTzJPA6/5n8mAkHsJzMFUTEpYPQ2rCkGHgUtzHxlIkDhRUjy9w7n0nHB0tsvI v9qBc/6+lPM8/So2tAG8aF70RYGy6GrZ4r1+18Lpp7CkTfIOseWSomY7EQhAWqF8gNyW u8vkFn7OUC7N6ADw6vilc3ZUGDbEx6hXGBTaM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2/47VBCLw/39dtYEI2tUVIyeRxuMRI3QygRcFXgJtWY=; b=hn+w7yPZKKaYi2ajOLM0Rs81KCjVKjYqqFUPpSOnlP8ijjpQ+R4fmjIKdsvMYJb3M+ bG+/yKZS6DO4ubD7/M6Yg6n4plDN5HmMKJlqvowwM737fP3kbczUOWNqh9LdNfcLadOZ LWlJqw/vpsbtgnjLHdN1+J6R54WoDGvzF8k4QLNXOv5Sbeb/bY3L3/PEDN43t4/VDUqc nqerg/YJzMdUj5uXuDvmrG2oEojkQdmALSOuP8Yi4sGRmkDSd0RwrAk+bsyup4M3InET AkVdW2Cf7XG1feKUnGfmbeZz6w4lCOnG1Pk/GNp5r722R/ITinU1W5MCya3EhyAZUL60 pNyw==
X-Gm-Message-State: ABUngvdxz3uHxRzeH9N1f93kJha+nDnLgt5KRVkPel4ocbr3k7SNnoLMBB5mExzNosnEjBsy9ayWwE5uNVHuGUcc
X-Received: by 10.233.237.147 with SMTP id c141mr24110892qkg.175.1477950466515;  Mon, 31 Oct 2016 14:47:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.169.19 with HTTP; Mon, 31 Oct 2016 14:47:15 -0700 (PDT)
In-Reply-To: <988d83ef-94ab-48b4-b277-396b172e98ba@article19.org>
References: <988d83ef-94ab-48b4-b277-396b172e98ba@article19.org>
From: Robert Guerra 
Date: Mon, 31 Oct 2016 17:47:15 -0400
Message-ID: 
To: Niels ten Oever 
Content-Type: multipart/alternative; boundary=001a114f3cce8d99820540302862
Archived-At: 
Cc: "hrpc@irtf.org" 
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2016 21:47:49 -0000

--001a114f3cce8d99820540302862
Content-Type: text/plain; charset=UTF-8

Niels,

Might I suggest Professor Laura DeNardis, from American University. She's
not coming to the ICANN meeting, but can connect her in remotely if you are
interested.

Her email is - denardis@american.edu





On Thu, Oct 27, 2016 at 4:25 PM, Niels ten Oever 
wrote:

> Hi all,
>
> Unfortunately both our speakers for the hrpc session (Francesca Musiani
> and Sarah Spiekerman) have canceled their presentation for the hrpc
> session due to timezone constraints.
>
> It would be great if others could help us suggest (and find) two other
> speakers that could help us broaden our horizon and get a better
> understanding of the relationship between human rights and standards in
> specific and technology in general.
>
> All suggestions would be appreciated.
>
> 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
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>
>

--001a114f3cce8d99820540302862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Niels,

Might I suggest Professor Laura =
DeNardis, from American University. She's not coming to the ICANN meeti=
ng, but can connect her in remotely if you are interested.

Her email is -=C2=A0denar=
dis@american.edu





=
On Thu, Oct 27, 2016 at 4:25 PM, Niels ten Oever <niels@article19.org> wrote:
Hi all,



Unfortunately both our speakers for the hrpc session (Francesca Musiani

and Sarah Spiekerman) have canceled their presentation for the hrpc

session due to timezone constraints.



It would be great if others could help us suggest (and find) two other

speakers that could help us broaden our horizon and get a better

understanding of the relationship between human rights and standards in

specific and technology in general.



All suggestions would be appreciated.



Best,



Niels

--

Niels ten Oever

Head of Digital



Article 19

w=
ww.article19.org



PGP fingerprint=C2=A0 =C2=A0 8D9F C567 BEE4 A431 56C4

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0678B 0=
8B5 A0F2 636D 68E9




_______________________________________________

hrpc mailing list

hrpc@irtf.org

https://www.irtf.org/mailman/listinfo/hrpc





--001a114f3cce8d99820540302862--


From nobody Mon Oct 31 14:55:18 2016
Return-Path: 
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEC6129B50 for ; Mon, 31 Oct 2016 14:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WS8h1HFLdkK for ; Mon, 31 Oct 2016 14:55:14 -0700 (PDT)
Received: from mail.article19.io (mail.article19.io [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546C4129B5D for ; Mon, 31 Oct 2016 14:55:14 -0700 (PDT)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id CF3AC83864D; Mon, 31 Oct 2016 21:55:12 +0000 (UTC)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id BE33B968F23; Mon, 31 Oct 2016 21:55:12 +0000 (UTC)
Received: from [10.234.214.181] (unknown [94.205.252.246]) by mail.article19.io (Postfix) with ESMTPSA id D51E983864D; Mon, 31 Oct 2016 21:55:11 +0000 (UTC)
Date: Mon, 31 Oct 2016 22:55:08 +0100
From: Niels ten Oever 
To: Robert Guerra 
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Message-Id: <20161031215511.D51E983864D@mail.article19.io>
Archived-At: 
Cc: hrpc@irtf.org
Subject: Re: [hrpc] speakers canceled, suggestions requested
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Oct 2016 21:55:17 -0000

PHAgZGlyPSJsdHIiPlRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24gUm9iZXJ0LCBidXQgTGF1cmEg
c3Bva2UgYXQgb3VyIGxhc3Qgc2Vzc2lvbi48L3A+CjxwIGRpcj0ibHRyIj5JIHdhcyB0aGlua2lu
Zywgd2hhdCB3b3VsZCBwZW9wbGUgdGhpbmsgaWYgd2UnZCBpbnZpdGUgdGhlIGF1dGhvciBvZiB0
aGlzIGFydGljbGU6PC9wPgo8cCBkaXI9Imx0ciI+aHR0cDovL3BlZXJwcm9kdWN0aW9uLm5ldC9p
c3N1ZXMvaXNzdWUtOS1hbHRlcm5hdGl2ZS1pbnRlcm5ldHMvcGVlci1yZXZpZXdlZC1wYXBlcnMv
YW50aS1jb2xvbmlhbC1oYWNraW5nLzwvcD4KPHAgZGlyPSJsdHIiPkJlc3QsPC9wPgo8cCBkaXI9
Imx0ciI+TmllbHM8L3A+CjxkaXYgY2xhc3M9InF1b3RlIj5PbiAzMSBPY3QgMjAxNiAyMjo0Nywg
Um9iZXJ0IEd1ZXJyYSAmbHQ7cmd1ZXJyYUBwcml2YXRlcnJhLm9yZyZndDsgd3JvdGU6PGJyIHR5
cGU9J2F0dHJpYnV0aW9uJz48YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46
MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48
ZGl2IGRpcj0ibHRyIj5OaWVscyw8ZGl2PjxiciAvPjwvZGl2PjxkaXY+TWlnaHQgSSBzdWdnZXN0
IFByb2Zlc3NvciBMYXVyYSBEZU5hcmRpcywgZnJvbSBBbWVyaWNhbiBVbml2ZXJzaXR5LiBTaGUm
IzM5O3Mgbm90IGNvbWluZyB0byB0aGUgSUNBTk4gbWVldGluZywgYnV0IGNhbiBjb25uZWN0IGhl
ciBpbiByZW1vdGVseSBpZiB5b3UgYXJlIGludGVyZXN0ZWQuPC9kaXY+PGRpdj48YnIgLz48L2Rp
dj48ZGl2PkhlciBlbWFpbCBpcyAtwqA8YSBocmVmPSJtYWlsdG86ZGVuYXJkaXMmIzY0O2FtZXJp
Y2FuLmVkdSI+ZGVuYXJkaXMmIzY0O2FtZXJpY2FuLmVkdTwvYT48L2Rpdj48ZGl2PjxiciAvPjwv
ZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGRpdj48YnIgLz48L2Rpdj48ZGl2PjxiciAvPjwvZGl2Pjwv
ZGl2PjxkaXY+PGJyIC8+PGRpdiBjbGFzcz0iZWxpZGVkLXRleHQiPk9uIFRodSwgT2N0IDI3LCAy
MDE2IGF0IDQ6MjUgUE0sIE5pZWxzIHRlbiBPZXZlciA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhy
ZWY9Im1haWx0bzpuaWVscyYjNjQ7YXJ0aWNsZTE5Lm9yZyI+bmllbHMmIzY0O2FydGljbGUxOS5v
cmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIC8+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjow
IDAgMCAwLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5I
aSBhbGwsPGJyIC8+DQo8YnIgLz4NClVuZm9ydHVuYXRlbHkgYm90aCBvdXIgc3BlYWtlcnMgZm9y
IHRoZSBocnBjIHNlc3Npb24gKEZyYW5jZXNjYSBNdXNpYW5pPGJyIC8+DQphbmQgU2FyYWggU3Bp
ZWtlcm1hbikgaGF2ZSBjYW5jZWxlZCB0aGVpciBwcmVzZW50YXRpb24gZm9yIHRoZSBocnBjPGJy
IC8+DQpzZXNzaW9uIGR1ZSB0byB0aW1lem9uZSBjb25zdHJhaW50cy48YnIgLz4NCjxiciAvPg0K
SXQgd291bGQgYmUgZ3JlYXQgaWYgb3RoZXJzIGNvdWxkIGhlbHAgdXMgc3VnZ2VzdCAoYW5kIGZp
bmQpIHR3byBvdGhlcjxiciAvPg0Kc3BlYWtlcnMgdGhhdCBjb3VsZCBoZWxwIHVzIGJyb2FkZW4g
b3VyIGhvcml6b24gYW5kIGdldCBhIGJldHRlcjxiciAvPg0KdW5kZXJzdGFuZGluZyBvZiB0aGUg
cmVsYXRpb25zaGlwIGJldHdlZW4gaHVtYW4gcmlnaHRzIGFuZCBzdGFuZGFyZHMgaW48YnIgLz4N
CnNwZWNpZmljIGFuZCB0ZWNobm9sb2d5IGluIGdlbmVyYWwuPGJyIC8+DQo8YnIgLz4NCkFsbCBz
dWdnZXN0aW9ucyB3b3VsZCBiZSBhcHByZWNpYXRlZC48YnIgLz4NCjxiciAvPg0KQmVzdCw8YnIg
Lz4NCjxiciAvPg0KTmllbHM8YnIgLz4NCjxmb250IGNvbG9yPSIjODg4ODg4Ij4tLTxiciAvPg0K
TmllbHMgdGVuIE9ldmVyPGJyIC8+DQpIZWFkIG9mIERpZ2l0YWw8YnIgLz4NCjxiciAvPg0KQXJ0
aWNsZSAxOTxiciAvPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5hcnRpY2xlMTkub3JnIj53d3cuYXJ0
aWNsZTE5Lm9yZzwvYT48YnIgLz4NCjxiciAvPg0KUEdQIGZpbmdlcnByaW50wqAgwqAgOEQ5RiBD
NTY3IEJFRTQgQTQzMSA1NkM0PGJyIC8+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDY3
OEIgMDhCNSBBMEYyIDYzNkQgNjhFOTxiciAvPg0KPGJyIC8+DQo8L2ZvbnQ+PGJyIC8+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPHdiciAvPl9fX19fX19fX19fX19fX19fPGJyIC8+DQpo
cnBjIG1haWxpbmcgbGlzdDxiciAvPg0KPGEgaHJlZj0ibWFpbHRvOmhycGMmIzY0O2lydGYub3Jn
Ij5ocnBjJiM2NDtpcnRmLm9yZzwvYT48YnIgLz4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlydGYu
b3JnL21haWxtYW4vbGlzdGluZm8vaHJwYyI+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi88
d2JyIC8+bGlzdGluZm8vaHJwYzwvYT48YnIgLz4NCjxiciAvPjwvYmxvY2txdW90ZT48L2Rpdj48
YnIgLz48L2Rpdj4NCjwvYmxvY2txdW90ZT48L2Rpdj4=