From nobody Sun May 1 03:54:51 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 3735A12B071 for ; Sun, 1 May 2016 03:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.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=-0.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 P441bD-NmAgV for ; Sun, 1 May 2016 03:54:47 -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 97E3F12B061 for ; Sun, 1 May 2016 03:54:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32467BE5D for ; Sun, 1 May 2016 11:54:46 +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 ftAJgCnIePwE for ; Sun, 1 May 2016 11:54:43 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.22.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1856ABE5B for ; Sun, 1 May 2016 11:54:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462100083; bh=CgHoFiiptbHEW6XUomAjJ4CBNqRJHPt/lFE5MxFV6nI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=YLI+td47+fJZtmsdXsjGjNJMeWkKMwaBwlV3+B7eXAZQWIS30v8iF2WYm+1QcLLuS gS0SyOFHoATw/nwY/IN9aoCItCRNTETofPVLf1h/zzD6WnNaAiB8hpTZ1bF8O3hBqI fGg/P3UuJhF37k51qisDIrs1xS6FqBLWZ76FOgRY= References: <201605010713.u417DLVH007291@new.toad.com> To: "hrpc@irtf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <201605010713.u417DLVH007291@new.toad.com> Message-ID: <5725E071.1010104@cs.tcd.ie> Date: Sun, 1 May 2016 11:54:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201605010713.u417DLVH007291@new.toad.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050500040800080802090704" Archived-At: Subject: [hrpc] Ethics thread, a possible case-study (was: Fwd: Re: [Cryptography] USB 3.0 authentication: market power and DRM?) 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, 01 May 2016 10:54:50 -0000 This is a cryptographically signed message in MIME format. --------------ms050500040800080802090704 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, See below for what might be an interesting case study relevant to the ethics in networked systems thread. (NB: I say "might" since I'm not familiar with the facts in this case but John's analysis below seems convincing enough to at least indicate that there're issues to consider here.) If someone had the time and interest to analyse a case like this, that could be a fine thing for the RG to document so that folks participating in the IETF had an example of that kind of analysis and could point to it if other participants were of a mind to propose such features. Apologies if this is a bit off-topic (I'm not sure being able to use any USB charger rises to the level of being a human right;-) but it seems to me like this might be a useful case to look at more, partly as it's a bit simpler than others we might see in the Internet. S. -------- Forwarded Message -------- Subject: Re: [Cryptography] USB 3.0 authentication: market power and DRM?= Date: Sun, 01 May 2016 00:13:20 -0700 From: John Gilmore To: dj@deadhat.com CC: cryptography@metzdowd.com, Pete > This may look odd. There are reasons. This spec is the first > part. It's addressing the authenticity of PD (powerdelivery) devices > by checking that they have been provisioned with certsunder a root > controlled by the certification body. These devices may nothave USB > data capability. The PD wires carry a low speed protocol tonegotiate > volts and amps. The 'problem' is counterfeit chargers anddefective > cables that can and do damage expensive computers and phones. I love the concept of the new Power Delivery modes (100w of power, by sending up to 20v at 5A over suitable cables). If done right, I can see people wiring their house and business wall outlets (and cars) with much safer, more compact, and Internet-enabled USB-PD sockets, replacing 110v or 220v wiring for a lot of uses. Particularly in places where the power source is DC anyway (like solar or cars) and/or where they want data or video connectivity as well as power. But I don't see how authentication fits in technically. It looks like it's there to build monopolies. The alleged problem statement seems to be: Some expensive devices will decline to spend the money to protect themselves from overvoltage or overcurrent situations, thereby being damaged by out-of-spec power supplies. We need to authenticate chargers so this won't happen. Let's examine this from an engineering point of view, then look at the politics. The One Laptop Per Child folks built their ~$100 laptops with power inputs that accept 11 to 24 V usable, -32 to +40V tolerated without damage. This lets them be used with all kinds of janky third world power, direct plug-ins to solar panels (the laptop does MPPT to optimize charging direct from solar too), etc. So it'll charge at +12 thru +24V, will decline to accept power at +35V or -12V or -24V but be undamaged. If you exceed this, e.g. by feeding 220V AC power to that input by accident, it will blow an internal fuse that's easy for a hardware tech to repair. But that's a well designed yet cheap device. Expensive USB3-PD devices could use similar circuitry to protect their expensive devices from overvoltage or overcurrent. Or, they could spend years in standards committees designing authentication. But I don't see how the standards committee solves the problem. Let's suppose that an expensive phone does USB3 authentication of its putative power source and decides that the authentication FAILS. Oh my god, it's been attached to a "counterfeit" charger or a "defective" cable! How does it protect itself? If it doesn't have circuitry that disconnects it from the power wires, it will fry anyway. But if it does have circuitry that disconnects it from the power wires, why not trigger that disconnect based on measuring overvoltage or overcurrent, rather than triggering it on failed authentication? It seems to me that a counterfeit charger could short 110V down the USB3 cable, with or without authentication. What protects the phone from that? Similarly, what prevents a counterfeit charger from using a chip and a flash image (including a signed certificate) that's identical to the one in a certified, tested, approved, paid-up charger. The counterfeiter only has to clone that real chip one time, then they can put it in all their products. Or they could actually buy the real chips on the open market, and just clone the firmware and the cert. Yet their shoddy wiring, Grade Z external components, faulty housing, etc, around that chip could still short 110V down the cable during the wrong phase of the moon. So the authentication will pass, but the voltages and currents will at sudden times be dangerous. I guess your expensive phone will fry anyway, despite the crypto, because you didn't spend 20c on protective components in the phone. What am I missing here? It looks like the alleged solution doesn't solve the alleged problem. Perhaps there's something else going on here.= > The 'problem' is counterfeit chargers and defective > cables that can and do damage expensive computers and phones. "Can and do" is a misnomer here. There are no counterfeit USB3-PD chargers, because there are essentially no USB3-PD chargers on the market yet. I've been looking. So there isn't a problem "yet" from fake USB3-PD gear... Perhaps you are talking about counterfeit USB2 chargers, that don't even negotiate the voltage, just have resistor / capacitor networks that signal the option to draw >500ma power at 5v? Now let's look at the politics. It is well understood in the consumer electronics industry how to use authentication requirements to exert market power. To be able to build a peripheral devie that plugs into an iPhone, you have to include a chip made only by Apple. The phone won't talk to you without having that chip in your thingy to answer a crypto challenge sent by the iPhone. Apple will only sell the chip to you if you give them a significant part of the purchase price of the peripheral. The chip authentication is the technical hook that drives you to sign a contract with Apple to become an "Apple Certified Peripheral". There are no "Apple uncertified peripherals" in the market, they don't sell because they don't work, because Apple forces them to not work, using Apple's control over the iPhone firmware to not let them work. Didn't you wonder why every iPhone dock and iPhone charger and iPhone cable was vastly overpriced? Even from a variety of competing third-party manufacturers? That's Apple raking in their 40% or whatever. And if your gadget competes too well against one of Apple's peripherals, maybe they won't certify you at all. Like the authentication-checking on apps in the "app store": at any time, Apple can put you right out of business, at their whim, and you have no recourse. My initial suspicion is that THIS is what the USB3 "authentication" spec is for. A very similar scheme is the technical hook that forces you to sign a contract to put DRM into your products in order to be able to make an HDMI product that will interoperate with other HDMI products. In that case it isn't even to extract money for a single vendor -- it is to exert market power on behalf of a group that doesn't even make devices -- Hollywood. They used business pressure ("negotiation") against Intel to convince Intel to build this into the HDMI support in their motherboards, to deny every competitor the ability to build products that do things that consumers want but that Hollywood doesn't. So just like the bastards who are trying to put DRM into the HTML standards at the W3C, I suspect "someone" also trying to put DRM into the USB standards. This "USB Authentication" is the "hook" that means you have to do whatever the "certification body" says you have to do. Hey dj, who runs the org that will keep the master keys? Or is that a political issue that's conveniently outside the scope of the technical USB Authentication specs? Or will the certification be vendor-by-vendor, e.g. Apple devices will look for a cert signed by key X, while Blu-Ray devices will look for a cert signed by key Y? How convenient -- a generic "hook" that ANY vendor can use to make their USB products deliberately incompatible, unless you enter into a one-sided coerced contract with them! What a sneaky way to undermine the intent of the "Universal" Serial Bus! But never fear, it's all to prevent fried phones from those dastardly "counterfeiters". The leaders of our tech industry would NEVER use this power for evil, only for good. John Gilmore _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography --------------ms050500040800080802090704 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MDEx MDU0NDFaMC8GCSqGSIb3DQEJBDEiBCB5o8hXiNY0eXtHdCqXZaTwl/GF6W+4CUkbtIhoXehU /TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCIhJ2yZ8j8okbSUUyw5gy/HSrCGGaMreQeiADo8FtSC9th7emIhwub SxYLOeDYW0KF2CqSjgZnOw9pOfXsVj3kMHI0St3iWxle3ME7cmncn5fRjHzdHXLHBY6DomPL gb7eEn3+apfy4jUfvv+x3lQ026fAYByqfZ05w7+ymHDXgAx3hREF4EKxt1+eHP66FhF+rq5d 0688DMzOPsjwYNT0guUQ+yCgKIXovULK7k2U+znA0QaGK/fxPRs6JIgfmminWNZAXO1bzHIx dJcd0qvsog/ZhhnLhlFvbCVKwG2UourcWsKCypoDPHontlBsE2Jfe3pprm5DJM7XHJ9i3mzo AAAAAAAA --------------ms050500040800080802090704-- From nobody Mon May 2 08:48: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 BC7D412D09B for ; Mon, 2 May 2016 08:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6YHI9tXrThfG for ; Mon, 2 May 2016 08:48:14 -0700 (PDT) Received: from positron.dckd.nl (positron.dckd.nl [94.142.246.99]) (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 8E42912B038 for ; Mon, 2 May 2016 08:48:14 -0700 (PDT) Received: from [IPv6:2001:610:6a1::418:2fbb:af74:10cf] (unknown [IPv6:2001:610:6a1:0:418:2fbb:af74:10cf]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by positron.dckd.nl (Postfix) with ESMTPSA id D0AFF7648C; Mon, 2 May 2016 17:48:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail 2.6b2 X-Universally-Unique-Identifier: 5BF9E43D-9EF3-49D0-A9C0-23DA2BEDD094 From: Jeroen van der Ham X-Mailer: iPhone Mail (13E238) In-Reply-To: <5725E071.1010104@cs.tcd.ie> Date: Mon, 2 May 2016 17:47:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <31583C80-1B71-4224-A1E6-94534CE8B1EC@os3.nl> X-Smtp-Server: 64276FD4-A07D-49B2-BED0-425CF7763C5E References: <201605010713.u417DLVH007291@new.toad.com> <5725E071.1010104@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Ethics thread, a possible case-study (was: Fwd: Re: [Cryptography] USB 3.0 authentication: market power and DRM?) 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, 02 May 2016 15:48:16 -0000 Hi, I=E2=80=99ve read the thread on the Cryptography mailinglist also, and the c= urrent conclusion there seems to be that it is very unclear what the purpose= of the crypto would be in the USB3 standard. Summarising: - News articles and the standard are claiming to use crypto in USB3 for clai= ms regarding power capabilities in devices and cables. - If you want to stop power transfer while checking crypto claims, you will n= eed to put in circuitry to control power transfer. - If you=E2=80=99re putting in circuitry to control power transfer, it is pr= obably cheaper to add circuitry to verify actual power capabilities than it i= s to include crypto circuitry. - With current devices it may still be necessary to check power capabilities= anyway, as simple crypto chips can currently be easily cloned. So things are not looking good for this idea, and that=E2=80=99s even withou= t looking at the ethics :) Jeroen. > On 01 May 2016, at 12:54, Stephen Farrell wrot= e: >=20 >=20 > Hiya, >=20 > See below for what might be an interesting case study relevant > to the ethics in networked systems thread. (NB: I say "might" > since I'm not familiar with the facts in this case but John's > analysis below seems convincing enough to at least indicate > that there're issues to consider here.) >=20 > If someone had the time and interest to analyse a case like > this, that could be a fine thing for the RG to document so that > folks participating in the IETF had an example of that kind of > analysis and could point to it if other participants were of > a mind to propose such features. >=20 > Apologies if this is a bit off-topic (I'm not sure being able > to use any USB charger rises to the level of being a human > right;-) but it seems to me like this might be a useful case > to look at more, partly as it's a bit simpler than others we > might see in the Internet. >=20 > S. >=20 >=20 > -------- Forwarded Message -------- > Subject: Re: [Cryptography] USB 3.0 authentication: market power and DRM? > Date: Sun, 01 May 2016 00:13:20 -0700 > From: John Gilmore > To: dj@deadhat.com > CC: cryptography@metzdowd.com, Pete >=20 >> This may look odd. There are reasons. This spec is the first >> part. It's addressing the authenticity of PD (powerdelivery) devices >> by checking that they have been provisioned with certsunder a root >> controlled by the certification body. These devices may nothave USB >> data capability. The PD wires carry a low speed protocol tonegotiate >> volts and amps. The 'problem' is counterfeit chargers anddefective >> cables that can and do damage expensive computers and phones. >=20 > I love the concept of the new Power Delivery modes (100w of power, by > sending up to 20v at 5A over suitable cables). If done right, I can > see people wiring their house and business wall outlets (and cars) > with much safer, more compact, and Internet-enabled USB-PD sockets, > replacing 110v or 220v wiring for a lot of uses. Particularly in > places where the power source is DC anyway (like solar or cars) and/or > where they want data or video connectivity as well as power. >=20 > But I don't see how authentication fits in technically. It looks like > it's there to build monopolies. >=20 > The alleged problem statement seems to be: Some expensive devices will > decline to spend the money to protect themselves from overvoltage or > overcurrent situations, thereby being damaged by out-of-spec power > supplies. We need to authenticate chargers so this won't happen. > Let's examine this from an engineering point of view, then look at > the politics. >=20 > The One Laptop Per Child folks built their ~$100 laptops with power > inputs that accept 11 to 24 V usable, -32 to +40V tolerated without > damage. This lets them be used with all kinds of janky third world > power, direct plug-ins to solar panels (the laptop does MPPT to > optimize charging direct from solar too), etc. So it'll charge at +12 > thru +24V, will decline to accept power at +35V or -12V or -24V but be > undamaged. If you exceed this, e.g. by feeding 220V AC power to that > input by accident, it will blow an internal fuse that's easy for a > hardware tech to repair. But that's a well designed yet cheap device. >=20 > Expensive USB3-PD devices could use similar circuitry to protect their > expensive devices from overvoltage or overcurrent. Or, they could > spend years in standards committees designing authentication. But I > don't see how the standards committee solves the problem. >=20 > Let's suppose that an expensive phone does USB3 authentication of its > putative power source and decides that the authentication FAILS. Oh > my god, it's been attached to a "counterfeit" charger or a "defective" > cable! How does it protect itself? >=20 > If it doesn't have circuitry that disconnects it from the power wires, > it will fry anyway. >=20 > But if it does have circuitry that disconnects it from the power > wires, why not trigger that disconnect based on measuring overvoltage or > overcurrent, rather than triggering it on failed authentication? >=20 > It seems to me that a counterfeit charger could short 110V down > the USB3 cable, with or without authentication. What protects > the phone from that? >=20 > Similarly, what prevents a counterfeit charger from using a chip and a > flash image (including a signed certificate) that's identical to the > one in a certified, tested, approved, paid-up charger. The > counterfeiter only has to clone that real chip one time, then they can > put it in all their products. Or they could actually buy the real > chips on the open market, and just clone the firmware and the cert. > Yet their shoddy wiring, Grade Z external components, faulty housing, > etc, around that chip could still short 110V down the cable during the > wrong phase of the moon. So the authentication will pass, but the > voltages and currents will at sudden times be dangerous. I guess your > expensive phone will fry anyway, despite the crypto, because you > didn't spend 20c on protective components in the phone. >=20 > What am I missing here? It looks like the alleged solution doesn't > solve the alleged problem. Perhaps there's something else going on here. >=20 >> The 'problem' is counterfeit chargers and defective >> cables that can and do damage expensive computers and phones. >=20 > "Can and do" is a misnomer here. There are no counterfeit USB3-PD > chargers, because there are essentially no USB3-PD chargers on the > market yet. I've been looking. So there isn't a problem "yet" > from fake USB3-PD gear... >=20 > Perhaps you are talking about counterfeit USB2 chargers, that don't > even negotiate the voltage, just have resistor / capacitor networks > that signal the option to draw >500ma power at 5v? >=20 > Now let's look at the politics. >=20 > It is well understood in the consumer electronics industry how to use > authentication requirements to exert market power. To be able to > build a peripheral devie that plugs into an iPhone, you have to > include a chip made only by Apple. The phone won't talk to you > without having that chip in your thingy to answer a crypto challenge > sent by the iPhone. Apple will only sell the chip to you if you give > them a significant part of the purchase price of the peripheral. The > chip authentication is the technical hook that drives you to sign a > contract with Apple to become an "Apple Certified Peripheral". There > are no "Apple uncertified peripherals" in the market, they don't sell > because they don't work, because Apple forces them to not work, using > Apple's control over the iPhone firmware to not let them work. Didn't > you wonder why every iPhone dock and iPhone charger and iPhone cable > was vastly overpriced? Even from a variety of competing third-party > manufacturers? That's Apple raking in their 40% or whatever. And if > your gadget competes too well against one of Apple's peripherals, > maybe they won't certify you at all. Like the authentication-checking > on apps in the "app store": at any time, Apple can put you right out > of business, at their whim, and you have no recourse. >=20 > My initial suspicion is that THIS is what the USB3 "authentication" > spec is for. >=20 > A very similar scheme is the technical hook that forces you to sign a > contract to put DRM into your products in order to be able to make an > HDMI product that will interoperate with other HDMI products. In that > case it isn't even to extract money for a single vendor -- it is to > exert market power on behalf of a group that doesn't even make devices > -- Hollywood. They used business pressure ("negotiation") against > Intel to convince Intel to build this into the HDMI support in their > motherboards, to deny every competitor the ability to build products > that do things that consumers want but that Hollywood doesn't. >=20 > So just like the bastards who are trying to put DRM into the HTML > standards at the W3C, I suspect "someone" also trying to put DRM into > the USB standards. This "USB Authentication" is the "hook" that means > you have to do whatever the "certification body" says you have to do. > Hey dj, who runs the org that will keep the master keys? Or is that a > political issue that's conveniently outside the scope of the technical > USB Authentication specs? >=20 > Or will the certification be vendor-by-vendor, e.g. Apple devices will > look for a cert signed by key X, while Blu-Ray devices will look for a > cert signed by key Y? How convenient -- a generic "hook" that ANY > vendor can use to make their USB products deliberately incompatible, > unless you enter into a one-sided coerced contract with them! What a > sneaky way to undermine the intent of the "Universal" Serial Bus! >=20 > But never fear, it's all to prevent fried phones from those dastardly > "counterfeiters". The leaders of our tech industry would NEVER use > this power for evil, only for good. >=20 > John Gilmore >=20 > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Mon May 2 17:49:49 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 44AFA12D53C for ; Mon, 2 May 2016 17:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xoiUb0IKHsDG for ; Mon, 2 May 2016 17:49:47 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 815FC12D6AC for ; Mon, 2 May 2016 17:49:41 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CA6E422E255 for ; Mon, 2 May 2016 20:49:34 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2016 10:49:32 +1000 References: <634effd8-3591-4ec5-b92b-2ea1259968cb@w3.org> To: hrpc@irtf.org Message-Id: <01B022DB-5866-40E7-9EC0-741193B92DAF@mnot.net> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [hrpc] Fwd: Proposed W3C Charter: Technology and Policy Interest Group (until 2016-05-31) 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, 03 May 2016 00:49:49 -0000 May be interesting to some here... > Begin forwarded message: >=20 > From: Xueyuan Jia > Subject: Proposed W3C Charter: Technology and Policy Interest Group = (until 2016-05-31) > Date: 29 April 2016 at 10:49:10 PM AEST > To: > Resent-From: > Archived-At: = >=20 >=20 > Hello, >=20 > Today W3C Advisory Committee Representatives received a Proposal > to review a draft charter for the Technology and Policy Interest = Group: > https://www.w3.org/2016/02/proposed-techpolig.htm >=20 > As part of ensuring that the community is aware of proposed work > at W3C, this draft charter is public during the Advisory > Committee review period. >=20 > W3C invites public comments through 2016-05-31 on the > proposed charter. Please send comments to > public-new-work@w3.org, which has a public archive: > http://lists.w3.org/Archives/Public/public-new-work/ >=20 > Other than comments sent in formal responses by W3C Advisory > Committee Representatives, W3C cannot guarantee a response to > comments. If you work for a W3C Member [1], please coordinate > your comments with your Advisory Committee Representative. For > example, you may wish to make public comments via this list and > have your Advisory Committee Representative refer to it from his > or her formal review comments. >=20 > If you should have any questions or need further information, please > contact Daniel Dardailler, Director of International relations at = . >=20 > Thank you, >=20 > Xueyuan Jia, W3C Marketing & Communications >=20 > [1] http://www.w3.org/Consortium/Member/List >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed May 4 05:48:52 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 3981612D68D for ; Wed, 4 May 2016 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tR5hRFZlXccv for ; Wed, 4 May 2016 05:48:47 -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 C436D12D693 for ; Wed, 4 May 2016 05:48:47 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 87DF220E4C7 for ; Wed, 4 May 2016 12:48:45 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 7936020E4D8 for ; Wed, 4 May 2016 12:48:45 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 6D20620E4C7 for ; Wed, 4 May 2016 12:48:45 +0000 (UTC) To: hrpc@irtf.org References: <20160317131136.17432.10088.idtracker@ietfa.amsl.com> <56EAAE6D.2000404@article19.org> <5702C5E1.5040602@acm.org> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <5729EFAC.9020002@article19.org> Date: Wed, 4 May 2016 14:48:44 +0200 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: <5702C5E1.5040602@acm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H3smkPx6FGbVSKNhDWtxDfj1UkxNUIhpU" Archived-At: Subject: Re: [hrpc] New Version Notification for draft-tenoever-hrpc-research-00.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: Wed, 04 May 2016 12:48:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H3smkPx6FGbVSKNhDWtxDfj1UkxNUIhpU Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Avri, We're working hard on resolving some of these questions and making a big review. Much of the work can be followed in realtime here: https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md Some replies inline to your email while I was drafting: On 04/04/2016 09:52 PM, avri doria wrote: > Hi, >=20 > I did a read through but have not had a chance to write up the comments= > in a legible manner. >=20 > These are some general comments >=20 > - the discussion centers around general behaviors and there is very > little discussion of protocol element. Will take this into account while re-writing. I am also trying to focus on which behavior a protocol allows and disallows (or even stimulates). I think that is inherent part of the protocols >=20 > - Many of the effects seem more related to IP issues (e.g. visible SRC = & > DST) than to elements of the specific protocol itself.=20 IP is also a protocol, right? > In a sense they > seem to be larger architectural issues (also a part of the RG's work) a= s > opposed to protocol issues.=20 Not sure if it is either/or. > But they are not broken out that way.=20 > Might be worth differentiating between the architectural issues and the= > protocol issues. Have been thinking about this and having a hard time coming up with a clear difference between the two. Would you have suggestions that can help us further? >=20 > - Much on the comment of the protocols is more about how people can > misuse the protocols and not abut protocol elements that enable bad or > good behavior.=20 >=20 > - also, so much of the discussion seems to circle around implementation= > and not the protocols themselves. >=20 Will try to add more concrete protocol examples, but I think there are also a lot of examples that show how protocol design allows for misuse, I think that should also be addressed at protocol level (as for instance done in html2) > - I think the discussion needs to take some of the work that is going > into protecting these protocols into account (e.g. HTTP -> HTTPS). The > draft did this for P2P but not for many of other discussions. >=20 Working on it. > - much of the discussion focuses on privacy elements, which are already= > covered and not on other aspects of FoE and FoA. Ie. something is a > problem because the lack of privacy affects the FoE or FoA. This is=20 > good point, but is it specific to the protocols?=20 >=20 Working on it. > - I think the consideration questions at the end are good questions, bu= t > I am not sure I see how they all come from the issues discussion in man= y > cases. Might be good to link questions to specifics discussed earlier > in the draft. >=20 Working on it. > Sorry to be so last minute and somewhat less than fully coherent about > these. >=20 They're great and very useful. Always happy to discuss. Best, Niels --H3smkPx6FGbVSKNhDWtxDfj1UkxNUIhpU 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 iQEcBAEBCAAGBQJXKe+tAAoJEAi1oPJjbWjph3AH/Akl/aad9/mwH3mOYuSSbyEq GuOtx4Han1TMs5DOF6Jk9/+N6azZ5tmPT538uV268sZCS2E5tINODCpY36VJ/04e vFRD7ixCPQaSf552bpBLUBKQX4n/8VfhIFj1S5egLAMhZpr0MdZNU1IRHH57yhY9 8gA0G2VAUIB2UUpqvIB2kvdG9WZR8hx9LsER7bn3LcShdE+GX2eGjBJSGqO6HuHR ojPy2yB85VuSqSI4SdQh5W7zaiR/6gAJoXdiLHO3YlChyTHkNhRNgEiwOFnDIDV5 daTMdmx+3lI0G1nTgQPDeXurz4u3dvDHrqWrrzf/S1rzHHwckDv/E7VHs2XUNXg= =P21W -----END PGP SIGNATURE----- --H3smkPx6FGbVSKNhDWtxDfj1UkxNUIhpU-- From nobody Wed May 4 07:06:29 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 1DD8912D1EC for ; Wed, 4 May 2016 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 6kt81jZq9eLF for ; Wed, 4 May 2016 07:06:26 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 0213A12D1DF for ; Wed, 4 May 2016 07:06:25 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id e201so189682208wme.0 for ; Wed, 04 May 2016 07:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TdgOSei0Hk8o3ZoyZPYb4jzqp2DS/tAyjP0S0wyMnRM=; b=Np5kL/zIvMRfzHyjVWg+WOGkVYcU6If8B+WRNAJNCFpvKOzPLaiu3G4Ah6YejO6QQR 0D4YsTkejtDurT0Ucc65829jYbEfTDpSKEpvxaLhjXBzVTVGi+g614nU58nfXhdCqy54 zv9UbygxTZnIEJ6Bvnk8zy56xNXZE5QadgoO3ePbraogcx9FW/cQ3RMA+jNbKnaks4u8 sixMjsEtpY1F7ibjaVhckFIcPmRQ3f9F2GVV2BHOEkZNq/8s6iB5J3EHUtORLlvoLYg6 O8Oocm+Py2HQQQ3jT2htlH6eMa6U9SmWp6v6zwVSGhpz7N8ZpdxUrfFLvGXiPRw0Nsw9 9zhw== 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:date :message-id:subject:from:to:cc; bh=TdgOSei0Hk8o3ZoyZPYb4jzqp2DS/tAyjP0S0wyMnRM=; b=EqCxH/8ZHwOqmhBq0vUcDaMliVSZjrYQvCeaOUHa1HOQA62nqbZiA5cYGQdZYrb8Vl OhOFeQ979AkyNJtCtSrqlw+QnXjPrDdaJx7iMUjRZnddZ/I2wGcHvuc5KHExCaUWoxNN LwQkGFMW6H0KXNnR8M8PwLwlkSBc3OXZkVfrSGL2AI0i2yXYCmZKAdqQ+B36JHtgNTxp 89CBBrKe8jFW06A19D3bmk6RltOgul/eC4EzXVK7cp6KHh8BR/7lU0Z41X8kUNeJFqBT nNcYrOWcg2ooUbjhIme8elG5LItrDbgr7qur4r2RVKjF5llD8N85qWjUsDr8E0OQ19pt C2ow== X-Gm-Message-State: AOPr4FW+loVQJ8P/LOdbn6tVmCXuPdULIX4r0+u9bEIA7ckE9im0vc2GfgpxGZdon6wfibooBFweu2H2+Ps+kQ== MIME-Version: 1.0 X-Received: by 10.194.231.196 with SMTP id ti4mr9625497wjc.41.1462370784507; Wed, 04 May 2016 07:06:24 -0700 (PDT) Received: by 10.194.41.233 with HTTP; Wed, 4 May 2016 07:06:24 -0700 (PDT) In-Reply-To: <01B022DB-5866-40E7-9EC0-741193B92DAF@mnot.net> References: <634effd8-3591-4ec5-b92b-2ea1259968cb@w3.org> <01B022DB-5866-40E7-9EC0-741193B92DAF@mnot.net> Date: Wed, 4 May 2016 15:06:24 +0100 Message-ID: From: Corinne Cath To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11369ab8241183053204bbb4 Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Fwd: Proposed W3C Charter: Technology and Policy Interest Group (until 2016-05-31) 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: Wed, 04 May 2016 14:06:28 -0000 --001a11369ab8241183053204bbb4 Content-Type: text/plain; charset=UTF-8 Thanks for sharing! relevant and timely work. Best, Corinne On Tue, May 3, 2016 at 1:49 AM, Mark Nottingham wrote: > May be interesting to some here... > > > > Begin forwarded message: > > > > From: Xueyuan Jia > > Subject: Proposed W3C Charter: Technology and Policy Interest Group > (until 2016-05-31) > > Date: 29 April 2016 at 10:49:10 PM AEST > > To: > > Resent-From: > > Archived-At: < > http://www.w3.org/mid/634effd8-3591-4ec5-b92b-2ea1259968cb@w3.org> > > > > > > Hello, > > > > Today W3C Advisory Committee Representatives received a Proposal > > to review a draft charter for the Technology and Policy Interest Group: > > https://www.w3.org/2016/02/proposed-techpolig.htm > > > > As part of ensuring that the community is aware of proposed work > > at W3C, this draft charter is public during the Advisory > > Committee review period. > > > > W3C invites public comments through 2016-05-31 on the > > proposed charter. Please send comments to > > public-new-work@w3.org, which has a public archive: > > http://lists.w3.org/Archives/Public/public-new-work/ > > > > Other than comments sent in formal responses by W3C Advisory > > Committee Representatives, W3C cannot guarantee a response to > > comments. If you work for a W3C Member [1], please coordinate > > your comments with your Advisory Committee Representative. For > > example, you may wish to make public comments via this list and > > have your Advisory Committee Representative refer to it from his > > or her formal review comments. > > > > If you should have any questions or need further information, please > > contact Daniel Dardailler, Director of International relations at < > danield@w3.org>. > > > > Thank you, > > > > Xueyuan Jia, W3C Marketing & Communications > > > > [1] http://www.w3.org/Consortium/Member/List > > > > > > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- 'The management of normality is hard work' --001a11369ab8241183053204bbb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for sharing! relevant and timely work. Best, Corinne

On T= ue, May 3, 2016 at 1:49 AM, Mark Nottingham <mnot@mnot.net> wr= ote:
May be interesting to some here...

> Begin forwarded message:
>
> From: Xueyuan Jia <xueyuan@w3.org= >
> Subject: Proposed W3C Charter: Technology and Policy Interest Group (u= ntil 2016-05-31)
> Date: 29 April 2016 at 10:49:10 PM AEST
> To: <public-new-work@w3.o= rg>
> Resent-From: <public-new-= work@w3.org>
> Archived-At: <http://www.w3= .org/mid/634effd8-3591-4ec5-b92b-2ea1259968cb@w3.org>
>
>
> Hello,
>
> Today W3C Advisory Committee Representatives received a Proposal
> to review a draft charter for the Technology and Policy Interest Group= :
>=C2=A0 https://www.w3.org/2016/02/proposed-tech= polig.htm
>
> As part of ensuring that the community is aware of proposed work
> at W3C, this draft charter is public during the Advisory
> Committee review period.
>
> W3C invites public comments through 2016-05-31 on the
> proposed charter. Please send comments to
> public-new-work@w3.org, = which has a public archive:
>=C2=A0 http://lists.w3.org/Archives/Public/p= ublic-new-work/
>
> Other than comments sent in formal responses by W3C Advisory
> Committee Representatives, W3C cannot guarantee a response to
> comments. If you work for a W3C Member [1], please coordinate
> your comments with your Advisory Committee Representative. For
> example, you may wish to make public comments via this list and
> have your Advisory Committee Representative refer to it from his
> or her formal review comments.
>
> If you should have any questions or need further information, please > contact Daniel Dardailler, Director of International relations at <= danield@w3.org>.
>
> Thank you,
>
> Xueyuan Jia, W3C Marketing & Communications
>
> [1] http://www.w3.org/Consortium/Member/List
>
>
>

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

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



--


'The management of normality is hard work'

<= /div>
--001a11369ab8241183053204bbb4-- From nobody Wed May 4 07:29:44 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 6047F12D6B0 for ; Wed, 4 May 2016 07:29:43 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 bifqdKDlP4Zo for ; Wed, 4 May 2016 07:29:41 -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 462A812D6AC for ; Wed, 4 May 2016 07:29:41 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id j74so83279586ywg.1 for ; Wed, 04 May 2016 07:29:41 -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=Yix1nKmdWapaJyr86n5qeW6nmDCw7DmVeCMVH8yq3w4=; b=M5a8RzhIClDW7QwE62jzAbcQFeWGsyDTF1+G/SWvDXs3ToHtYkaCy/80eUL/wFPoVy ylGWfRUwgBeM4A2XkbVnXBNVMv6fDinXqa8AgGFqFajAxSL/pN5wqWhmv6VkHDsqn7PP +3purMAGzmuJ7aA5e1VM4caYJW+Lp0NkVCmd0= 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=Yix1nKmdWapaJyr86n5qeW6nmDCw7DmVeCMVH8yq3w4=; b=LzN+SgkIlOJwRHgggOIoSaL3uw/p4j2oxQd2ETavLZtWNPwHIKgu7Xpz5yQ1ALgf+c R3x5mif5JRQvJeM7q7G+myMYa7DJJgKDTRCSe3dF4QVjjX2jB7C5wZOOE2UW1k0Q2jcX Gb/fIAqNhTv3tEqPlYWRrbXqNFWoudjaNHMTxgmZty6/3ys2UZq2NWBcsNTYR0kpgk9J 9xtJOJgZRlBYiVAf+42PVw3YTw2ut0RjDH5NtJ3T+3Li5ebe5AQI+DqCBC5+P4Kupaf0 e8wScpK92tOFtDPYRFA1GC8P4ucfmi3ZK3wYJ7oFPoLPCmWkn901S/6Gu59wrN33Il3F jr5w== X-Gm-Message-State: AOPr4FVY8KjbA8CDEcD0C4yi10qVPjystKDT/jiXphmGVlaj8hKMQEH5u8W1+ebzNCNJ96od+d+f9mtP6Kv1XlvQ X-Received: by 10.176.1.79 with SMTP id 73mr5500575uak.123.1462372180386; Wed, 04 May 2016 07:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.6 with HTTP; Wed, 4 May 2016 07:29:20 -0700 (PDT) In-Reply-To: <5729EFAC.9020002@article19.org> References: <20160317131136.17432.10088.idtracker@ietfa.amsl.com> <56EAAE6D.2000404@article19.org> <5702C5E1.5040602@acm.org> <5729EFAC.9020002@article19.org> From: Joseph Lorenzo Hall Date: Wed, 4 May 2016 10:29:20 -0400 Message-ID: To: Niels ten Oever Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-tenoever-hrpc-research-00.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: Wed, 04 May 2016 14:29:43 -0000 Point of order: should we reivew the 00 document or is there a readable version in the repo we should look at? (i.e., if you could transform a working copy of the md into txt that would be wonderful). best, Joe On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever wrote: > Hi Avri, > > We're working hard on resolving some of these questions and making a big > review. Much of the work can be followed in realtime here: > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > Some replies inline to your email while I was drafting: > > On 04/04/2016 09:52 PM, avri doria wrote: >> Hi, >> >> I did a read through but have not had a chance to write up the comments >> in a legible manner. >> >> These are some general comments >> >> - the discussion centers around general behaviors and there is very >> little discussion of protocol element. > > Will take this into account while re-writing. I am also trying to focus > on which behavior a protocol allows and disallows (or even stimulates). > I think that is inherent part of the protocols > >> >> - Many of the effects seem more related to IP issues (e.g. visible SRC & >> DST) than to elements of the specific protocol itself. > > IP is also a protocol, right? > >> In a sense they >> seem to be larger architectural issues (also a part of the RG's work) as >> opposed to protocol issues. > > Not sure if it is either/or. > >> But they are not broken out that way. >> Might be worth differentiating between the architectural issues and the >> protocol issues. > > Have been thinking about this and having a hard time coming up with a > clear difference between the two. Would you have suggestions that can > help us further? > >> >> - Much on the comment of the protocols is more about how people can >> misuse the protocols and not abut protocol elements that enable bad or >> good behavior. >> >> - also, so much of the discussion seems to circle around implementation >> and not the protocols themselves. >> > > Will try to add more concrete protocol examples, but I think there are > also a lot of examples that show how protocol design allows for misuse, > I think that should also be addressed at protocol level (as for instance > done in html2) > >> - I think the discussion needs to take some of the work that is going >> into protecting these protocols into account (e.g. HTTP -> HTTPS). The >> draft did this for P2P but not for many of other discussions. >> > > Working on it. > > >> - much of the discussion focuses on privacy elements, which are already >> covered and not on other aspects of FoE and FoA. Ie. something is a >> problem because the lack of privacy affects the FoE or FoA. This is >> good point, but is it specific to the protocols? >> > > Working on it. > >> - I think the consideration questions at the end are good questions, but >> I am not sure I see how they all come from the issues discussion in many >> cases. Might be good to link questions to specifics discussed earlier >> in the draft. >> > > Working on it. > >> Sorry to be so last minute and somewhat less than fully coherent about >> these. >> > > They're great and very useful. Always happy to discuss. > > Best, > > Niels > > > > > _______________________________________________ > 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 From nobody Wed May 4 10:21: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 0220A12D8D3 for ; Wed, 4 May 2016 10:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 W_NrmTdR6jSE for ; Wed, 4 May 2016 10:21:10 -0700 (PDT) Received: from positron.dckd.nl (positron.dckd.nl [IPv6:2a02:898:62:f6::63]) (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 67BB012D7FE for ; Wed, 4 May 2016 10:20:52 -0700 (PDT) Received: from [IPv6:2001:980:1aa1:1:d14:e143:2358:6616] (unknown [IPv6:2001:980:1aa1:1:d14:e143:2358:6616]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by positron.dckd.nl (Postfix) with ESMTPSA id 3E60D6829; Wed, 4 May 2016 19:20:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeroen van der Ham X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 4 May 2016 19:20:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160317131136.17432.10088.idtracker@ietfa.amsl.com> <56EAAE6D.2000404@article19.org> <5702C5E1.5040602@acm.org> <5729EFAC.9020002@article19.org> To: Joseph Lorenzo Hall Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-tenoever-hrpc-research-00.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: Wed, 04 May 2016 17:21:13 -0000 Hi Joe, Md is the Markdown format, which is basically plain text. You can get the ra= w format here: https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.= md Jeroen.=20 > On 04 May 2016, at 16:29, Joseph Lorenzo Hall wrote: >=20 > Point of order: should we reivew the 00 document or is there a > readable version in the repo we should look at? (i.e., if you could > transform a working copy of the md into txt that would be wonderful). > best, Joe >=20 >> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever wro= te: >> Hi Avri, >>=20 >> We're working hard on resolving some of these questions and making a big >> review. Much of the work can be followed in realtime here: >> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md >>=20 >> Some replies inline to your email while I was drafting: >>=20 >>> On 04/04/2016 09:52 PM, avri doria wrote: >>> Hi, >>>=20 >>> I did a read through but have not had a chance to write up the comments >>> in a legible manner. >>>=20 >>> These are some general comments >>>=20 >>> - the discussion centers around general behaviors and there is very >>> little discussion of protocol element. >>=20 >> Will take this into account while re-writing. I am also trying to focus >> on which behavior a protocol allows and disallows (or even stimulates). >> I think that is inherent part of the protocols >>=20 >>>=20 >>> - Many of the effects seem more related to IP issues (e.g. visible SRC &= >>> DST) than to elements of the specific protocol itself. >>=20 >> IP is also a protocol, right? >>=20 >>> In a sense they >>> seem to be larger architectural issues (also a part of the RG's work) as= >>> opposed to protocol issues. >>=20 >> Not sure if it is either/or. >>=20 >>> But they are not broken out that way. >>> Might be worth differentiating between the architectural issues and the >>> protocol issues. >>=20 >> Have been thinking about this and having a hard time coming up with a >> clear difference between the two. Would you have suggestions that can >> help us further? >>=20 >>>=20 >>> - Much on the comment of the protocols is more about how people can >>> misuse the protocols and not abut protocol elements that enable bad or >>> good behavior. >>>=20 >>> - also, so much of the discussion seems to circle around implementation >>> and not the protocols themselves. >>=20 >> Will try to add more concrete protocol examples, but I think there are >> also a lot of examples that show how protocol design allows for misuse, >> I think that should also be addressed at protocol level (as for instance >> done in html2) >>=20 >>> - I think the discussion needs to take some of the work that is going >>> into protecting these protocols into account (e.g. HTTP -> HTTPS). The >>> draft did this for P2P but not for many of other discussions. >>=20 >> Working on it. >>=20 >>=20 >>> - much of the discussion focuses on privacy elements, which are already >>> covered and not on other aspects of FoE and FoA. Ie. something is a >>> problem because the lack of privacy affects the FoE or FoA. This is >>> good point, but is it specific to the protocols? >>=20 >> Working on it. >>=20 >>> - I think the consideration questions at the end are good questions, but= >>> I am not sure I see how they all come from the issues discussion in many= >>> cases. Might be good to link questions to specifics discussed earlier >>> in the draft. >>=20 >> Working on it. >>=20 >>> Sorry to be so last minute and somewhat less than fully coherent about >>> these. >>=20 >> They're great and very useful. Always happy to discuss. >>=20 >> Best, >>=20 >> Niels >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 >=20 > --=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 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Wed May 4 10:24: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 5415A12D559 for ; Wed, 4 May 2016 10:24:44 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 SBbg-f5V0ztM for ; Wed, 4 May 2016 10:24:42 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 2E93F12D0F6 for ; Wed, 4 May 2016 10:24:41 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o66so107236176ywc.3 for ; Wed, 04 May 2016 10:24:41 -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=nqE786gWzEqWB1Qff/sgYN9VR8bC5eij1KHRfzB66Vc=; b=pPLa36/A3WlL9/TrTirHcHeF5Ecf7Y6Yppr8qCYgU9QuLWTDog6DsOWhrMOGWbZScV cAVRXrmWrmlG3eerZbchIWdPrGPeLqx2epmpxVspkIXR4pe1b0u7MJ+8DsHyNt0w2D82 cx1KfrBQiJSCYS9RBQcCuL74wwAKgtW4Q8tq4= 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=nqE786gWzEqWB1Qff/sgYN9VR8bC5eij1KHRfzB66Vc=; b=icznsWX50J4GnkMDBo3ZgGmT3wxxuRE97V3hjuf6qBGXmbWNa1UalbS09dlzsuZ/zX M1O5MnkKU+WS8QLECxeqjElisQJeyHdO8MyM51tYYGwtIyTjbKz7Ky7xa4trnLBpB4oA 5p7oy6AsFJdUQ3httGqA9YDmTJLGIWtbYrRy3/5pEQbz/nIF0SrY7uc3dlag0E7NdXtM 6n0E9V/2CaPdD1wwvca0qg0vmCs4Ji0x7vzV9VSv+57cqSlzc+RSeF0L/VTRE3hwHs3q Ix1QlGKG+dU/HUAw4xehCLHFTeHm5RMmCA4ZAhyLxA9IVwL2m7LZh3mVcgrwA/U/fymc sktw== X-Gm-Message-State: AOPr4FWjBNQdmS/BVG8YwmcqS6SU2U5t/duWtVVN4jG6S9piQhzWAmqeclqc+QBLaQ6EF/xSTvUGf09TDxsVq+m9 X-Received: by 10.176.66.4 with SMTP id i4mr6126958uai.99.1462382680957; Wed, 04 May 2016 10:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.6 with HTTP; Wed, 4 May 2016 10:24:21 -0700 (PDT) In-Reply-To: References: <20160317131136.17432.10088.idtracker@ietfa.amsl.com> <56EAAE6D.2000404@article19.org> <5702C5E1.5040602@acm.org> <5729EFAC.9020002@article19.org> From: Joseph Lorenzo Hall Date: Wed, 4 May 2016 13:24:21 -0400 Message-ID: To: Jeroen van der Ham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-tenoever-hrpc-research-00.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: Wed, 04 May 2016 17:24:44 -0000 I'm aware of that. It would be good to build RFC txt too, if that's not difficult (happy to craft a PR) On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham wrote: > Hi Joe, > Md is the Markdown format, which is basically plain text. You can get the raw format here: > > https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > Jeroen. > >> On 04 May 2016, at 16:29, Joseph Lorenzo Hall wrote: >> >> Point of order: should we reivew the 00 document or is there a >> readable version in the repo we should look at? (i.e., if you could >> transform a working copy of the md into txt that would be wonderful). >> best, Joe >> >>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever wrote: >>> Hi Avri, >>> >>> We're working hard on resolving some of these questions and making a big >>> review. Much of the work can be followed in realtime here: >>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md >>> >>> Some replies inline to your email while I was drafting: >>> >>>> On 04/04/2016 09:52 PM, avri doria wrote: >>>> Hi, >>>> >>>> I did a read through but have not had a chance to write up the comments >>>> in a legible manner. >>>> >>>> These are some general comments >>>> >>>> - the discussion centers around general behaviors and there is very >>>> little discussion of protocol element. >>> >>> Will take this into account while re-writing. I am also trying to focus >>> on which behavior a protocol allows and disallows (or even stimulates). >>> I think that is inherent part of the protocols >>> >>>> >>>> - Many of the effects seem more related to IP issues (e.g. visible SRC & >>>> DST) than to elements of the specific protocol itself. >>> >>> IP is also a protocol, right? >>> >>>> In a sense they >>>> seem to be larger architectural issues (also a part of the RG's work) as >>>> opposed to protocol issues. >>> >>> Not sure if it is either/or. >>> >>>> But they are not broken out that way. >>>> Might be worth differentiating between the architectural issues and the >>>> protocol issues. >>> >>> Have been thinking about this and having a hard time coming up with a >>> clear difference between the two. Would you have suggestions that can >>> help us further? >>> >>>> >>>> - Much on the comment of the protocols is more about how people can >>>> misuse the protocols and not abut protocol elements that enable bad or >>>> good behavior. >>>> >>>> - also, so much of the discussion seems to circle around implementation >>>> and not the protocols themselves. >>> >>> Will try to add more concrete protocol examples, but I think there are >>> also a lot of examples that show how protocol design allows for misuse, >>> I think that should also be addressed at protocol level (as for instance >>> done in html2) >>> >>>> - I think the discussion needs to take some of the work that is going >>>> into protecting these protocols into account (e.g. HTTP -> HTTPS). The >>>> draft did this for P2P but not for many of other discussions. >>> >>> Working on it. >>> >>> >>>> - much of the discussion focuses on privacy elements, which are already >>>> covered and not on other aspects of FoE and FoA. Ie. something is a >>>> problem because the lack of privacy affects the FoE or FoA. This is >>>> good point, but is it specific to the protocols? >>> >>> Working on it. >>> >>>> - I think the consideration questions at the end are good questions, but >>>> I am not sure I see how they all come from the issues discussion in many >>>> cases. Might be good to link questions to specifics discussed earlier >>>> in the draft. >>> >>> Working on it. >>> >>>> Sorry to be so last minute and somewhat less than fully coherent about >>>> these. >>> >>> They're great and very useful. Always happy to discuss. >>> >>> Best, >>> >>> Niels >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 From nobody Thu May 5 03:55:06 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 0631F12D126 for ; Thu, 5 May 2016 03:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2WLw3OPA4c5g for ; Thu, 5 May 2016 03:55:02 -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 04D8D12D0F5 for ; Thu, 5 May 2016 03:55:02 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 51A4A7CE349D; Thu, 5 May 2016 10:55:00 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 3E77E7CE34A9; Thu, 5 May 2016 10:55:00 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 2370C7CE349D; Thu, 5 May 2016 10:55:00 +0000 (UTC) To: Joseph Lorenzo Hall , Jeroen van der Ham References: <20160317131136.17432.10088.idtracker@ietfa.amsl.com> <56EAAE6D.2000404@article19.org> <5702C5E1.5040602@acm.org> <5729EFAC.9020002@article19.org> From: Niels ten Oever Message-ID: <572B2683.6040808@article19.org> Date: Thu, 5 May 2016 12:54:59 +0200 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="Ddkr7Sa4HDMGq4sGnN6tXIiDNdmfVnskd" Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] New Version Notification for draft-tenoever-hrpc-research-00.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: Thu, 05 May 2016 10:55:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ddkr7Sa4HDMGq4sGnN6tXIiDNdmfVnskd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe, Sorry for the delay, there were some building issues, and as you know kramdown-rfc2629 is not always as verbose as one wants to be :) Please find a new version here: https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ Comment and questions on the list, suggestions also very much welcome as pull requests here (preferably with a short describption in a mail to the list): https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: > I'm aware of that. It would be good to build RFC txt too, if that's > not difficult (happy to craft a PR) >=20 > On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham wrot= e: >> Hi Joe, >> Md is the Markdown format, which is basically plain text. You can get = the raw format here: >> >> https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-res= earch.md >> >> Jeroen. >> >>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall wrote: >>> >>> Point of order: should we reivew the 00 document or is there a >>> readable version in the repo we should look at? (i.e., if you could >>> transform a working copy of the md into txt that would be wonderful).= >>> best, Joe >>> >>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever wrote: >>>> Hi Avri, >>>> >>>> We're working hard on resolving some of these questions and making a= big >>>> review. Much of the work can be followed in realtime here: >>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md >>>> >>>> Some replies inline to your email while I was drafting: >>>> >>>>> On 04/04/2016 09:52 PM, avri doria wrote: >>>>> Hi, >>>>> >>>>> I did a read through but have not had a chance to write up the comm= ents >>>>> in a legible manner. >>>>> >>>>> These are some general comments >>>>> >>>>> - the discussion centers around general behaviors and there is very= >>>>> little discussion of protocol element. >>>> >>>> Will take this into account while re-writing. I am also trying to fo= cus >>>> on which behavior a protocol allows and disallows (or even stimulate= s). >>>> I think that is inherent part of the protocols >>>> >>>>> >>>>> - Many of the effects seem more related to IP issues (e.g. visible = SRC & >>>>> DST) than to elements of the specific protocol itself. >>>> >>>> IP is also a protocol, right? >>>> >>>>> In a sense they >>>>> seem to be larger architectural issues (also a part of the RG's wor= k) as >>>>> opposed to protocol issues. >>>> >>>> Not sure if it is either/or. >>>> >>>>> But they are not broken out that way. >>>>> Might be worth differentiating between the architectural issues and= the >>>>> protocol issues. >>>> >>>> Have been thinking about this and having a hard time coming up with = a >>>> clear difference between the two. Would you have suggestions that ca= n >>>> help us further? >>>> >>>>> >>>>> - Much on the comment of the protocols is more about how people can= >>>>> misuse the protocols and not abut protocol elements that enable bad= or >>>>> good behavior. >>>>> >>>>> - also, so much of the discussion seems to circle around implementa= tion >>>>> and not the protocols themselves. >>>> >>>> Will try to add more concrete protocol examples, but I think there a= re >>>> also a lot of examples that show how protocol design allows for misu= se, >>>> I think that should also be addressed at protocol level (as for inst= ance >>>> done in html2) >>>> >>>>> - I think the discussion needs to take some of the work that is goi= ng >>>>> into protecting these protocols into account (e.g. HTTP -> HTTPS). = The >>>>> draft did this for P2P but not for many of other discussions. >>>> >>>> Working on it. >>>> >>>> >>>>> - much of the discussion focuses on privacy elements, which are alr= eady >>>>> covered and not on other aspects of FoE and FoA. Ie. something is = a >>>>> problem because the lack of privacy affects the FoE or FoA. This i= s >>>>> good point, but is it specific to the protocols? >>>> >>>> Working on it. >>>> >>>>> - I think the consideration questions at the end are good questions= , but >>>>> I am not sure I see how they all come from the issues discussion in= many >>>>> cases. Might be good to link questions to specifics discussed earl= ier >>>>> in the draft. >>>> >>>> Working on it. >>>> >>>>> Sorry to be so last minute and somewhat less than fully coherent ab= out >>>>> these. >>>> >>>> They're great and very useful. Always happy to discuss. >>>> >>>> Best, >>>> >>>> Niels >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> hrpc mailing list >>>> hrpc@irtf.org >>>> https://www.irtf.org/mailman/listinfo/hrpc >>> >>> >>> >>> -- >>> Joseph Lorenzo Hall >>> Chief Technologist, Center for Democracy & Technology [https://www.cd= t.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 >>> >>> _______________________________________________ >>> hrpc mailing list >>> hrpc@irtf.org >>> https://www.irtf.org/mailman/listinfo/hrpc >> >=20 >=20 >=20 --Ddkr7Sa4HDMGq4sGnN6tXIiDNdmfVnskd 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 iQEcBAEBCAAGBQJXKyaDAAoJEAi1oPJjbWjpDtcH/iz9P2T2Act4tkfimd34BeJQ 5M/diF/dvGV0eFiUjRXnebg7+nYPgeLc5TNTMRuFL2aN9CFkDtolEr3F8g0iYf3U Ltb3P/eHuAKr426JGbEYchOm4RqyliJyqhSFh10YcxFY0qMeM0NAM1wGcGpETuT4 H56h8vhM43ZGtiVJxkZcP0/Pdzy3pUQOqa1OdOCO3dLzHgdHo3EKGZNUdm6ek2Uk hNEoo2yzOFzLepTZ0/I6rMaSmUL4s5+7kzjDM012YRKeZ3bcobqUULAU6wqrixRf 7UoRos8dDm8eqb21Yet0J6hudD7kxVjhQKLFHwMACt1XB7GbSMgBynZEjx949Ms= =jkMc -----END PGP SIGNATURE----- --Ddkr7Sa4HDMGq4sGnN6tXIiDNdmfVnskd-- From nobody Thu May 5 08:10:38 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 B0BBC12D618 for ; Thu, 5 May 2016 08:10:36 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 sqGDYWVIH7y3 for ; Thu, 5 May 2016 08:10:33 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 029F412DAA0 for ; Thu, 5 May 2016 08:02:44 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id r16so28844480vkf.3 for ; Thu, 05 May 2016 08:02:44 -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=w3BzihL0cd65ah3MLyluTDKT2Kp4NFs8BN7xFi4QXL4=; b=nUvv3ZLvIZjwZ4uiXu3TL6Zm2Q/wuVI9JvGpjpj5g50wzOQj4feLeMSv2PzTFBZpZz N9eUR/SYKEgKaIi7IhjBBB37L8AvWjGx1SQoMGZxmMkiTsj91IajGOw2+Ag69DBH5Jgn dk/QEGSkzgIkIWIL27d1ca0RVUHk0usDTfGnY= 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=w3BzihL0cd65ah3MLyluTDKT2Kp4NFs8BN7xFi4QXL4=; b=DMi9U4bYFptlDWjhAMtSeC1kPBP5dZN3Qscy9GGuo5lS8JV15QI/jKx2gnzwR1v17Z bSbxJOSg4sK/O5if6wvgd6pjOLPxcHY4i9u3DQue+ioNze7DlJhEh1lpWrYKT4lzlNKj kxxvHHApKkPmKmOxQ+7sOD7MzNd/a2HRpQ83WBD/GyY36Je4aTlD7wMpXfIW4g6GjpMQ 5CsZ/bJCnJSZFtJHI8vuzpqUZBauZWbfHUKxPoX4Ah2kZk7f8IgcWfExNLvWRTOyCgV5 FG+W8tWCJHQyHU/tgpmxNP861M9+5tMvtujJO6Il0sYjCVbNqNXZJMfDAtVLZvgWF9M+ AmIw== X-Gm-Message-State: AOPr4FXcwRSZwC8CJnzZucgZrBKUaIOvRs5fwTnqhTPh+LbfoXzG+px4oFetBXZaK1oCe1vPDRQ4wNJN5tE5GkYC X-Received: by 10.31.155.208 with SMTP id d199mr2717912vke.100.1462460564064; Thu, 05 May 2016 08:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.6 with HTTP; Thu, 5 May 2016 08:02:24 -0700 (PDT) In-Reply-To: <572B2683.6040808@article19.org> References: <20160317131136.17432.10088.idtracker@ietfa.amsl.com> <56EAAE6D.2000404@article19.org> <5702C5E1.5040602@acm.org> <5729EFAC.9020002@article19.org> <572B2683.6040808@article19.org> From: Joseph Lorenzo Hall Date: Thu, 5 May 2016 08:02:24 -0700 Message-ID: To: Niels ten Oever Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: hrpc@irtf.org, Jeroen van der Ham Subject: Re: [hrpc] New Version Notification for draft-tenoever-hrpc-research-00.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: Thu, 05 May 2016 15:10:36 -0000 Thanks a ton, Niels! I am way too familiar with vagaries of group kramdown building... so very much appreciate this. More soon! On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever wrote: > Hi Joe, > > Sorry for the delay, there were some building issues, and as you know > kramdown-rfc2629 is not always as verbose as one wants to be :) > > Please find a new version here: > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > > Comment and questions on the list, suggestions also very much welcome as > pull requests here (preferably with a short describption in a mail to > the list): > > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: >> I'm aware of that. It would be good to build RFC txt too, if that's >> not difficult (happy to craft a PR) >> >> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham wrote: >>> Hi Joe, >>> Md is the Markdown format, which is basically plain text. You can get the raw format here: >>> >>> https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md >>> >>> Jeroen. >>> >>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall wrote: >>>> >>>> Point of order: should we reivew the 00 document or is there a >>>> readable version in the repo we should look at? (i.e., if you could >>>> transform a working copy of the md into txt that would be wonderful). >>>> best, Joe >>>> >>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever wrote: >>>>> Hi Avri, >>>>> >>>>> We're working hard on resolving some of these questions and making a big >>>>> review. Much of the work can be followed in realtime here: >>>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md >>>>> >>>>> Some replies inline to your email while I was drafting: >>>>> >>>>>> On 04/04/2016 09:52 PM, avri doria wrote: >>>>>> Hi, >>>>>> >>>>>> I did a read through but have not had a chance to write up the comments >>>>>> in a legible manner. >>>>>> >>>>>> These are some general comments >>>>>> >>>>>> - the discussion centers around general behaviors and there is very >>>>>> little discussion of protocol element. >>>>> >>>>> Will take this into account while re-writing. I am also trying to focus >>>>> on which behavior a protocol allows and disallows (or even stimulates). >>>>> I think that is inherent part of the protocols >>>>> >>>>>> >>>>>> - Many of the effects seem more related to IP issues (e.g. visible SRC & >>>>>> DST) than to elements of the specific protocol itself. >>>>> >>>>> IP is also a protocol, right? >>>>> >>>>>> In a sense they >>>>>> seem to be larger architectural issues (also a part of the RG's work) as >>>>>> opposed to protocol issues. >>>>> >>>>> Not sure if it is either/or. >>>>> >>>>>> But they are not broken out that way. >>>>>> Might be worth differentiating between the architectural issues and the >>>>>> protocol issues. >>>>> >>>>> Have been thinking about this and having a hard time coming up with a >>>>> clear difference between the two. Would you have suggestions that can >>>>> help us further? >>>>> >>>>>> >>>>>> - Much on the comment of the protocols is more about how people can >>>>>> misuse the protocols and not abut protocol elements that enable bad or >>>>>> good behavior. >>>>>> >>>>>> - also, so much of the discussion seems to circle around implementation >>>>>> and not the protocols themselves. >>>>> >>>>> Will try to add more concrete protocol examples, but I think there are >>>>> also a lot of examples that show how protocol design allows for misuse, >>>>> I think that should also be addressed at protocol level (as for instance >>>>> done in html2) >>>>> >>>>>> - I think the discussion needs to take some of the work that is going >>>>>> into protecting these protocols into account (e.g. HTTP -> HTTPS). The >>>>>> draft did this for P2P but not for many of other discussions. >>>>> >>>>> Working on it. >>>>> >>>>> >>>>>> - much of the discussion focuses on privacy elements, which are already >>>>>> covered and not on other aspects of FoE and FoA. Ie. something is a >>>>>> problem because the lack of privacy affects the FoE or FoA. This is >>>>>> good point, but is it specific to the protocols? >>>>> >>>>> Working on it. >>>>> >>>>>> - I think the consideration questions at the end are good questions, but >>>>>> I am not sure I see how they all come from the issues discussion in many >>>>>> cases. Might be good to link questions to specifics discussed earlier >>>>>> in the draft. >>>>> >>>>> Working on it. >>>>> >>>>>> Sorry to be so last minute and somewhat less than fully coherent about >>>>>> these. >>>>> >>>>> They're great and very useful. Always happy to discuss. >>>>> >>>>> Best, >>>>> >>>>> Niels >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 From nobody Fri May 6 01:00:29 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 80D1112D1C9 for ; Fri, 6 May 2016 01:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 FKKVT9K0VbCG for ; Fri, 6 May 2016 01:00:22 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 2A1C012D14D for ; Fri, 6 May 2016 01:00:22 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id 190so107792892iow.1 for ; Fri, 06 May 2016 01:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=2fs0IzIFHL1V0k05F68MSNhGAFOiwjJiMiRTDmA/Rec=; b=kuoccxewm2zSvZov6iUFO8Rt7Aq1KrxYP3G5XaIabIklJD7BTp81DdyQA+20/dnntz aqRcOk/mFV7/myfbOTEoBKR18K+5067l17TEQ9+eb4xSks6fzzno41rFS94nh3ZdF6Dm QcLD+7h2jqGjdkFeBVO59E5gDyAXqBtIko9qgalIvPCpYS64+uSHWFKp9HkDkGk0y/Rw s9nRCfaAzYdFKGvNyQHUFcwSkGBbrWQBm5DSWs3su1cH5xmJmf2lqsL6SCCqdgQO10+6 Bl6l5D2j2gUj/3ZAhQ/mo9wGqfB0UM1mcq8xEWZ/urb1mMoNK223bfcYHPvhKkl7o/uv 1opA== 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:date :message-id:subject:from:to; bh=2fs0IzIFHL1V0k05F68MSNhGAFOiwjJiMiRTDmA/Rec=; b=FLNSQ5omo5BeIVnIjFfBSlgkRX0Rt0Xu+t72bwx4liBO1kmkhVOcipZCeZ8Fae8Srg 1K5ZfetNBeCwQkunQjICxLzPUzY4vjCbf+FU8avxPQTsv9nix3fR33+ITcO+zrzePdXP NBsvqofzfwSoxYtw9FJV6xQewdOsbJ/KiBxCpFsZOVlkFNKqC3O/msnwt9YAYeJdPsBC c6+rU9GSOkPE2Y+hoS6S27v+QeYoy5xs/rbgp5ZVTPqtYCS65K36zCYHwTQiyHykN8KG 35ZL7n0B69d3nYLyIDgms3Ql90YdqCDwnNJeRRJa+D3XQf+ek+FrIVGcN1ZKRBeFwRmi 01vA== X-Gm-Message-State: AOPr4FUvcMHj8FL9HpRKdxFyThIQQMRo2sjBAwsf8elE3gcmAtM0XjTVxm/4aF40fg1Vnpd2ii6qi97syYqzfQ== MIME-Version: 1.0 X-Received: by 10.107.164.101 with SMTP id n98mr22659637ioe.93.1462521621399; Fri, 06 May 2016 01:00:21 -0700 (PDT) Received: by 10.107.14.141 with HTTP; Fri, 6 May 2016 01:00:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2016 11:00:21 +0300 Message-ID: From: Dessalegn Yehuala To: hrpc@irtf.org Content-Type: multipart/alternative; boundary=001a1141ccf2b85c0a053227d9a0 Archived-At: Subject: Re: [hrpc] hrpc Digest, Vol 14, Issue 6 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, 06 May 2016 08:00:27 -0000 --001a1141ccf2b85c0a053227d9a0 Content-Type: text/plain; charset=UTF-8 I have been a silent subscriber of the mailing list for some time, having read the Internet drafts published recently I thought it would be good to forward one item that can provide a new dimension to the ongoing work. It has been repeatedly said that access to the Internet is becoming more and more a human right issue- I feel the working group approach need to be beyond the protection of freedom of speech, as it has tried to be to an extent in the case of making the Internet environment accessible for people with disability. The large chunks of population in developing countries or countries in the global south are disconnected and the accessibility issue also need to be one of the targets in the design of a protocol that addresses human rights related issue. Dessalegn. On Thu, May 5, 2016 at 10:00 PM, wrote: > Send hrpc mailing list submissions to > hrpc@irtf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/hrpc > or, via email, send a message with subject or body 'help' to > hrpc-request@irtf.org > > You can reach the person managing the list at > hrpc-owner@irtf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of hrpc digest..." > > Today's Topics: > > 1. Re: New Version Notification for > draft-tenoever-hrpc-research-00.txt (Niels ten Oever) > 2. Re: New Version Notification for > draft-tenoever-hrpc-research-00.txt (Joseph Lorenzo Hall) > > > ---------- Forwarded message ---------- > From: Niels ten Oever > To: Joseph Lorenzo Hall , Jeroen van der Ham > Cc: hrpc@irtf.org > Date: Thu, 5 May 2016 12:54:59 +0200 > Subject: Re: [hrpc] New Version Notification for > draft-tenoever-hrpc-research-00.txt > Hi Joe, > > Sorry for the delay, there were some building issues, and as you know > kramdown-rfc2629 is not always as verbose as one wants to be :) > > Please find a new version here: > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > > Comment and questions on the list, suggestions also very much welcome as > pull requests here (preferably with a short describption in a mail to > the list): > > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: > > I'm aware of that. It would be good to build RFC txt too, if that's > > not difficult (happy to craft a PR) > > > > On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham > wrote: > >> Hi Joe, > >> Md is the Markdown format, which is basically plain text. You can get > the raw format here: > >> > >> > https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md > >> > >> Jeroen. > >> > >>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall wrote: > >>> > >>> Point of order: should we reivew the 00 document or is there a > >>> readable version in the repo we should look at? (i.e., if you could > >>> transform a working copy of the md into txt that would be wonderful). > >>> best, Joe > >>> > >>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever > wrote: > >>>> Hi Avri, > >>>> > >>>> We're working hard on resolving some of these questions and making a > big > >>>> review. Much of the work can be followed in realtime here: > >>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > >>>> > >>>> Some replies inline to your email while I was drafting: > >>>> > >>>>> On 04/04/2016 09:52 PM, avri doria wrote: > >>>>> Hi, > >>>>> > >>>>> I did a read through but have not had a chance to write up the > comments > >>>>> in a legible manner. > >>>>> > >>>>> These are some general comments > >>>>> > >>>>> - the discussion centers around general behaviors and there is very > >>>>> little discussion of protocol element. > >>>> > >>>> Will take this into account while re-writing. I am also trying to > focus > >>>> on which behavior a protocol allows and disallows (or even > stimulates). > >>>> I think that is inherent part of the protocols > >>>> > >>>>> > >>>>> - Many of the effects seem more related to IP issues (e.g. visible > SRC & > >>>>> DST) than to elements of the specific protocol itself. > >>>> > >>>> IP is also a protocol, right? > >>>> > >>>>> In a sense they > >>>>> seem to be larger architectural issues (also a part of the RG's > work) as > >>>>> opposed to protocol issues. > >>>> > >>>> Not sure if it is either/or. > >>>> > >>>>> But they are not broken out that way. > >>>>> Might be worth differentiating between the architectural issues and > the > >>>>> protocol issues. > >>>> > >>>> Have been thinking about this and having a hard time coming up with a > >>>> clear difference between the two. Would you have suggestions that can > >>>> help us further? > >>>> > >>>>> > >>>>> - Much on the comment of the protocols is more about how people can > >>>>> misuse the protocols and not abut protocol elements that enable bad > or > >>>>> good behavior. > >>>>> > >>>>> - also, so much of the discussion seems to circle around > implementation > >>>>> and not the protocols themselves. > >>>> > >>>> Will try to add more concrete protocol examples, but I think there are > >>>> also a lot of examples that show how protocol design allows for > misuse, > >>>> I think that should also be addressed at protocol level (as for > instance > >>>> done in html2) > >>>> > >>>>> - I think the discussion needs to take some of the work that is going > >>>>> into protecting these protocols into account (e.g. HTTP -> HTTPS). > The > >>>>> draft did this for P2P but not for many of other discussions. > >>>> > >>>> Working on it. > >>>> > >>>> > >>>>> - much of the discussion focuses on privacy elements, which are > already > >>>>> covered and not on other aspects of FoE and FoA. Ie. something is a > >>>>> problem because the lack of privacy affects the FoE or FoA. This is > >>>>> good point, but is it specific to the protocols? > >>>> > >>>> Working on it. > >>>> > >>>>> - I think the consideration questions at the end are good questions, > but > >>>>> I am not sure I see how they all come from the issues discussion in > many > >>>>> cases. Might be good to link questions to specifics discussed > earlier > >>>>> in the draft. > >>>> > >>>> Working on it. > >>>> > >>>>> Sorry to be so last minute and somewhat less than fully coherent > about > >>>>> these. > >>>> > >>>> They're great and very useful. Always happy to discuss. > >>>> > >>>> Best, > >>>> > >>>> Niels > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> _______________________________________________ > >>> hrpc mailing list > >>> hrpc@irtf.org > >>> https://www.irtf.org/mailman/listinfo/hrpc > >> > > > > > > > > > > ---------- Forwarded message ---------- > From: Joseph Lorenzo Hall > To: Niels ten Oever > Cc: hrpc@irtf.org, Jeroen van der Ham > Date: Thu, 5 May 2016 08:02:24 -0700 > Subject: Re: [hrpc] New Version Notification for > draft-tenoever-hrpc-research-00.txt > Thanks a ton, Niels! I am way too familiar with vagaries of group > kramdown building... so very much appreciate this. More soon! > > On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever > wrote: > > Hi Joe, > > > > Sorry for the delay, there were some building issues, and as you know > > kramdown-rfc2629 is not always as verbose as one wants to be :) > > > > Please find a new version here: > > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > > > > Comment and questions on the list, suggestions also very much welcome as > > pull requests here (preferably with a short describption in a mail to > > the list): > > > > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > > > 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: > >> I'm aware of that. It would be good to build RFC txt too, if that's > >> not difficult (happy to craft a PR) > >> > >> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham > wrote: > >>> Hi Joe, > >>> Md is the Markdown format, which is basically plain text. You can get > the raw format here: > >>> > >>> > https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md > >>> > >>> Jeroen. > >>> > >>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall wrote: > >>>> > >>>> Point of order: should we reivew the 00 document or is there a > >>>> readable version in the repo we should look at? (i.e., if you could > >>>> transform a working copy of the md into txt that would be wonderful). > >>>> best, Joe > >>>> > >>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever > wrote: > >>>>> Hi Avri, > >>>>> > >>>>> We're working hard on resolving some of these questions and making a > big > >>>>> review. Much of the work can be followed in realtime here: > >>>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > >>>>> > >>>>> Some replies inline to your email while I was drafting: > >>>>> > >>>>>> On 04/04/2016 09:52 PM, avri doria wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I did a read through but have not had a chance to write up the > comments > >>>>>> in a legible manner. > >>>>>> > >>>>>> These are some general comments > >>>>>> > >>>>>> - the discussion centers around general behaviors and there is very > >>>>>> little discussion of protocol element. > >>>>> > >>>>> Will take this into account while re-writing. I am also trying to > focus > >>>>> on which behavior a protocol allows and disallows (or even > stimulates). > >>>>> I think that is inherent part of the protocols > >>>>> > >>>>>> > >>>>>> - Many of the effects seem more related to IP issues (e.g. visible > SRC & > >>>>>> DST) than to elements of the specific protocol itself. > >>>>> > >>>>> IP is also a protocol, right? > >>>>> > >>>>>> In a sense they > >>>>>> seem to be larger architectural issues (also a part of the RG's > work) as > >>>>>> opposed to protocol issues. > >>>>> > >>>>> Not sure if it is either/or. > >>>>> > >>>>>> But they are not broken out that way. > >>>>>> Might be worth differentiating between the architectural issues and > the > >>>>>> protocol issues. > >>>>> > >>>>> Have been thinking about this and having a hard time coming up with a > >>>>> clear difference between the two. Would you have suggestions that can > >>>>> help us further? > >>>>> > >>>>>> > >>>>>> - Much on the comment of the protocols is more about how people can > >>>>>> misuse the protocols and not abut protocol elements that enable bad > or > >>>>>> good behavior. > >>>>>> > >>>>>> - also, so much of the discussion seems to circle around > implementation > >>>>>> and not the protocols themselves. > >>>>> > >>>>> Will try to add more concrete protocol examples, but I think there > are > >>>>> also a lot of examples that show how protocol design allows for > misuse, > >>>>> I think that should also be addressed at protocol level (as for > instance > >>>>> done in html2) > >>>>> > >>>>>> - I think the discussion needs to take some of the work that is > going > >>>>>> into protecting these protocols into account (e.g. HTTP -> HTTPS). > The > >>>>>> draft did this for P2P but not for many of other discussions. > >>>>> > >>>>> Working on it. > >>>>> > >>>>> > >>>>>> - much of the discussion focuses on privacy elements, which are > already > >>>>>> covered and not on other aspects of FoE and FoA. Ie. something is a > >>>>>> problem because the lack of privacy affects the FoE or FoA. This is > >>>>>> good point, but is it specific to the protocols? > >>>>> > >>>>> Working on it. > >>>>> > >>>>>> - I think the consideration questions at the end are good > questions, but > >>>>>> I am not sure I see how they all come from the issues discussion in > many > >>>>>> cases. Might be good to link questions to specifics discussed > earlier > >>>>>> in the draft. > >>>>> > >>>>> Working on it. > >>>>> > >>>>>> Sorry to be so last minute and somewhat less than fully coherent > about > >>>>>> these. > >>>>> > >>>>> They're great and very useful. Always happy to discuss. > >>>>> > >>>>> Best, > >>>>> > >>>>> Niels > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> 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 > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > --001a1141ccf2b85c0a053227d9a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been a silent subscriber of the mailing list for so= me time, having read the Internet drafts published recently I thought it wo= uld be good to forward one item that can provide a new dimension to the ong= oing work. It has been repeatedly said that access to the Internet is becom= ing more and more a human right issue- I feel the working group approach ne= ed to be beyond the protection of freedom of speech, as it has tried to be = to an extent in the case of making the Internet environment accessible for = people with disability. The large chunks of population in developing countr= ies or countries in the global south are disconnected and the accessibility= issue also need to be one of the targets in the design of a protocol that = addresses human rights related issue.

Dessalegn.

On Thu, May 5= , 2016 at 10:00 PM, <hrpc-request@irtf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Send hrpc mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc@irtf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.irtf.org/mailman/l= istinfo/hrpc
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc-r= equest@irtf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc-own= er@irtf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hrpc digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: New Version Notification for
=C2=A0 =C2=A0 =C2=A0 draft-tenoever-hrpc-research-00.txt (Niels ten Oever)<= br> =C2=A0 =C2=A02. Re: New Version Notification for
=C2=A0 =C2=A0 =C2=A0 draft-tenoever-hrpc-research-00.txt (Joseph Lorenzo Ha= ll)


---------- Forwarded message ----------
From:=C2=A0Niels ten Oev= er <niels@article19.org>To:=C2=A0Joseph Lorenzo Hall <joe@cdt.o= rg>, Jeroen van der Ham <jeroen@= os3.nl>
Cc:=C2=A0hrpc@irtf.org
Date:=C2=A0Thu, 5 May 2016 12:54:59 +0200
Subject:=C2=A0Re: [hrpc]= New Version Notification for draft-tenoever-hrpc-research-00.txt
Hi Joe= ,

Sorry for the delay, there were some building issues, and as you know
kramdown-rfc2629 is not always as verbose as one wants to be :)

Please find a new version here:
https://datatracker.ietf.org/doc/draft= -tenoever-hrpc-research/

Comment and questions on the list, suggestions also very much welcome as pull requests here (preferably with a short describption in a mail to
the list):

https://github.com/nllz/IRTF-HRPC/blo= b/master/draft-research.md

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

On 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote:
> I'm aware of that. It would be good to build RFC txt too, if that&= #39;s
> not difficult (happy to craft a PR)
>
> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham <jeroen@os3.nl> wrote:
>> Hi Joe,
>> Md is the Markdown format, which is basically plain text. You can = get the raw format here:
>>
>> https://raw.g= ithubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md
>>
>> Jeroen.
>>
>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall <joe@cdt.org> wrote:
>>>
>>> Point of order: should we reivew the 00 document or is there a=
>>> readable version in the repo we should look at? (i.e., if you = could
>>> transform a working copy of the md into txt that would be wond= erful).
>>> best, Joe
>>>
>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever <niels@article19.org> wrote:
>>>> Hi Avri,
>>>>
>>>> We're working hard on resolving some of these question= s and making a big
>>>> review. Much of the work can be followed in realtime here:=
>>>> https://github.com/n= llz/IRTF-HRPC/blob/master/draft-research.md
>>>>
>>>> Some replies inline to your email while I was drafting: >>>>
>>>>> On 04/04/2016 09:52 PM, avri doria wrote:
>>>>> Hi,
>>>>>
>>>>> I did a read through but have not had a chance to writ= e up the comments
>>>>> in a legible manner.
>>>>>
>>>>> These are some general comments
>>>>>
>>>>> - the discussion centers around general behaviors and = there is very
>>>>> little discussion of protocol element.
>>>>
>>>> Will take this into account while re-writing. I am also tr= ying to focus
>>>> on which behavior a protocol allows and disallows (or even= stimulates).
>>>> I think that is inherent part of the protocols
>>>>
>>>>>
>>>>> - Many of the effects seem more related to IP issues (= e.g. visible SRC &
>>>>> DST) than to elements of the specific protocol itself.=
>>>>
>>>> IP is also a protocol, right?
>>>>
>>>>> In a sense they
>>>>> seem to be larger architectural issues (also a part of= the RG's work) as
>>>>> opposed to protocol issues.
>>>>
>>>> Not sure if it is either/or.
>>>>
>>>>> But they are not broken out that way.
>>>>> Might be worth differentiating between the architectur= al issues and the
>>>>> protocol issues.
>>>>
>>>> Have been thinking about this and having a hard time comin= g up with a
>>>> clear difference between the two. Would you have suggestio= ns that can
>>>> help us further?
>>>>
>>>>>
>>>>> - Much on the comment of the protocols is more about h= ow people can
>>>>> misuse the protocols and not abut protocol elements th= at enable bad or
>>>>> good behavior.
>>>>>
>>>>> - also, so much of the discussion seems to circle arou= nd implementation
>>>>> and not the protocols themselves.
>>>>
>>>> Will try to add more concrete protocol examples, but I thi= nk there are
>>>> also a lot of examples that show how protocol design allow= s for misuse,
>>>> I think that should also be addressed at protocol level (a= s for instance
>>>> done in html2)
>>>>
>>>>> - I think the discussion needs to take some of the wor= k that is going
>>>>> into protecting these protocols into account (e.g. HTT= P -> HTTPS). The
>>>>> draft did this for P2P but not for many of other discu= ssions.
>>>>
>>>> Working on it.
>>>>
>>>>
>>>>> - much of the discussion focuses on privacy elements, = which are already
>>>>> covered and not on other aspects of FoE and FoA.=C2=A0= Ie. something is a
>>>>> problem because the lack of privacy affects the FoE or= FoA.=C2=A0 This is
>>>>> good point, but is it specific to the protocols?
>>>>
>>>> Working on it.
>>>>
>>>>> - I think the consideration questions at the end are g= ood questions, but
>>>>> I am not sure I see how they all come from the issues = discussion in many
>>>>> cases.=C2=A0 Might be good to link questions to specif= ics discussed earlier
>>>>> in the draft.
>>>>
>>>> Working on it.
>>>>
>>>>> Sorry to be so last minute and somewhat less than full= y coherent about
>>>>> these.
>>>>
>>>> They're great and very useful. Always happy to discuss= .
>>>>
>>>> Best,
>>>>
>>>> Niels
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> hrpc mailing list
>>>> hrpc@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/hrp= c
>>>
>>>
>>>
>>> --
>>> Joseph Lorenzo Hall
>>> Chief Technologist, Center for Democracy & Technology [https://w= ww.cdt.org]
>>> 1401 K ST NW STE 200, Washington DC 20005-3497
>>> e: joe@cdt.org, p: 202.407.8825, pgp: ht= tps://josephhall.org/gpg-key
>>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A= 9 A871
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>
>
>
>



---------- Forwarded message ----------
From:=C2=A0Joseph Lorenz= o Hall <joe@cdt.org>
To:=C2=A0N= iels ten Oever <niels@article19.o= rg>
Cc:=C2=A0hrpc@irtf.org, = Jeroen van der Ham <jeroen@os3.nl&g= t;
Date:=C2=A0Thu, 5 May 2016 08:02:24 -0700
Subject:=C2=A0Re: [hrpc]= New Version Notification for draft-tenoever-hrpc-research-00.txt
Thanks= a ton, Niels! I am way too familiar with vagaries of group
kramdown building... so very much appreciate this. More soon!

On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever <niels@article19.org> wrote:
> Hi Joe,
>
> Sorry for the delay, there were some building issues, and as you know<= br> > kramdown-rfc2629 is not always as verbose as one wants to be :)
>
> Please find a new version here:
> https://datatracker.ietf.org/doc/= draft-tenoever-hrpc-research/
>
> Comment and questions on the list, suggestions also very much welcome = as
> pull requests here (preferably with a short describption in a mail to<= br> > the list):
>
> https://github.com/nllz/IRTF-HRP= C/blob/master/draft-research.md
>
> Best,
>
> Niels
>
>
>
> Niels ten Oever
> Head of Digital
>
> Article 19
> www.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=A0 6= 78B 08B5 A0F2 636D 68E9
>
> On 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote:
>> I'm aware of that. It would be good to build RFC txt too, if t= hat's
>> not difficult (happy to craft a PR)
>>
>> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham <jeroen@os3.nl> wrote:
>>> Hi Joe,
>>> Md is the Markdown format, which is basically plain text. You = can get the raw format here:
>>>
>>> https://r= aw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md >>>
>>> Jeroen.
>>>
>>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall <joe@cdt.org> wrote:
>>>>
>>>> Point of order: should we reivew the 00 document or is the= re a
>>>> readable version in the repo we should look at? (i.e., if = you could
>>>> transform a working copy of the md into txt that would be = wonderful).
>>>> best, Joe
>>>>
>>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever <niels@article19.org> wrote:
>>>>> Hi Avri,
>>>>>
>>>>> We're working hard on resolving some of these ques= tions and making a big
>>>>> review. Much of the work can be followed in realtime h= ere:
>>>>> https://github.c= om/nllz/IRTF-HRPC/blob/master/draft-research.md
>>>>>
>>>>> Some replies inline to your email while I was drafting= :
>>>>>
>>>>>> On 04/04/2016 09:52 PM, avri doria wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I did a read through but have not had a chance to = write up the comments
>>>>>> in a legible manner.
>>>>>>
>>>>>> These are some general comments
>>>>>>
>>>>>> - the discussion centers around general behaviors = and there is very
>>>>>> little discussion of protocol element.
>>>>>
>>>>> Will take this into account while re-writing. I am als= o trying to focus
>>>>> on which behavior a protocol allows and disallows (or = even stimulates).
>>>>> I think that is inherent part of the protocols
>>>>>
>>>>>>
>>>>>> - Many of the effects seem more related to IP issu= es (e.g. visible SRC &
>>>>>> DST) than to elements of the specific protocol its= elf.
>>>>>
>>>>> IP is also a protocol, right?
>>>>>
>>>>>> In a sense they
>>>>>> seem to be larger architectural issues (also a par= t of the RG's work) as
>>>>>> opposed to protocol issues.
>>>>>
>>>>> Not sure if it is either/or.
>>>>>
>>>>>> But they are not broken out that way.
>>>>>> Might be worth differentiating between the archite= ctural issues and the
>>>>>> protocol issues.
>>>>>
>>>>> Have been thinking about this and having a hard time c= oming up with a
>>>>> clear difference between the two. Would you have sugge= stions that can
>>>>> help us further?
>>>>>
>>>>>>
>>>>>> - Much on the comment of the protocols is more abo= ut how people can
>>>>>> misuse the protocols and not abut protocol element= s that enable bad or
>>>>>> good behavior.
>>>>>>
>>>>>> - also, so much of the discussion seems to circle = around implementation
>>>>>> and not the protocols themselves.
>>>>>
>>>>> Will try to add more concrete protocol examples, but I= think there are
>>>>> also a lot of examples that show how protocol design a= llows for misuse,
>>>>> I think that should also be addressed at protocol leve= l (as for instance
>>>>> done in html2)
>>>>>
>>>>>> - I think the discussion needs to take some of the= work that is going
>>>>>> into protecting these protocols into account (e.g.= HTTP -> HTTPS). The
>>>>>> draft did this for P2P but not for many of other d= iscussions.
>>>>>
>>>>> Working on it.
>>>>>
>>>>>
>>>>>> - much of the discussion focuses on privacy elemen= ts, which are already
>>>>>> covered and not on other aspects of FoE and FoA.= =C2=A0 Ie. something is a
>>>>>> problem because the lack of privacy affects the Fo= E or FoA.=C2=A0 This is
>>>>>> good point, but is it specific to the protocols? >>>>>
>>>>> Working on it.
>>>>>
>>>>>> - I think the consideration questions at the end a= re good questions, but
>>>>>> I am not sure I see how they all come from the iss= ues discussion in many
>>>>>> cases.=C2=A0 Might be good to link questions to sp= ecifics discussed earlier
>>>>>> in the draft.
>>>>>
>>>>> Working on it.
>>>>>
>>>>>> Sorry to be so last minute and somewhat less than = fully coherent about
>>>>>> these.
>>>>>
>>>>> They're great and very useful. Always happy to dis= cuss.
>>>>>
>>>>> Best,
>>>>>
>>>>> Niels
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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=C2=A0 1607 5F86 6987= 40A9 A871
>>>>
>>>> _______________________________________________
>>>> hrpc mailing list
>>>> hrpc@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/hrp= c
>>>
>>
>>
>>
>



--
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://josephha= ll.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871



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


--001a1141ccf2b85c0a053227d9a0-- From nobody Fri May 6 05:03: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 068A212D959 for ; Fri, 6 May 2016 05:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9y0BaxRL5Dme for ; Fri, 6 May 2016 05:03:17 -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 3619212D11D for ; Fri, 6 May 2016 05:03:16 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 300AD2E2AE0 for ; Fri, 6 May 2016 12:03:15 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 1FF802E2AF6 for ; Fri, 6 May 2016 12:03:15 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 0C8202E2AE0 for ; Fri, 6 May 2016 12:03:15 +0000 (UTC) To: hrpc@irtf.org References: From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <572C8802.6040405@article19.org> Date: Fri, 6 May 2016 14:03:14 +0200 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="gDftwftXOHUaTCD8LcaEOraoPvNi85C1X" Archived-At: Subject: Re: [hrpc] access 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, 06 May 2016 12:03:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gDftwftXOHUaTCD8LcaEOraoPvNi85C1X Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Dessalegn, Thank you for your email. I think in the draft [0] we have been focusing on topics that go beyond freedom of speech, for instance where we looked at freedom of association, non-discrimination, equal protection, political participation, participation in cultural life, arts and science and the right to security. As you say, connectivity is an inherent part of freedom as expression, and that is also how it is defined in the draft. But I am afraid that providing access to the Internet is not a protocol issue where is comes to providing the actual connection and providing bandwith (please correct me if I'm wrong!). Therefore I think it is outside of the purview of this document and research group. We do however have explicit references to usage of protocols on low bandwith, high latency connections, have for instance a look at '5.3.2.1.11. Accessibility' and '5.3.2.1.14. Reliability'. Always happy to discuss. All the best, Niels https://tools.ietf.org/html/draft-tenoever-hrpc-research-01 Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 05/06/2016 10:00 AM, Dessalegn Yehuala wrote: > I have been a silent subscriber of the mailing list for some time, > having read the Internet drafts published recently I thought it would b= e > good to forward one item that can provide a new dimension to the ongoin= g > work. It has been repeatedly said that access to the Internet is > becoming more and more a human right issue- I feel the working group > approach need to be beyond the protection of freedom of speech, as it > has tried to be to an extent in the case of making the Internet > environment accessible for people with disability. The large chunks of > population in developing countries or countries in the global south are= > disconnected and the accessibility issue also need to be one of the > targets in the design of a protocol that addresses human rights related= > issue. >=20 > Dessalegn. >=20 > On Thu, May 5, 2016 at 10:00 PM, > wrote: >=20 > Send hrpc mailing list submissions to > hrpc@irtf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/hrpc > or, via email, send a message with subject or body 'help' to > hrpc-request@irtf.org >=20 > You can reach the person managing the list at > hrpc-owner@irtf.org >=20 > When replying, please edit your Subject line so it is more specific= > than "Re: Contents of hrpc digest..." >=20 > Today's Topics: >=20 > 1. Re: New Version Notification for > draft-tenoever-hrpc-research-00.txt (Niels ten Oever) > 2. Re: New Version Notification for > draft-tenoever-hrpc-research-00.txt (Joseph Lorenzo Hall) >=20 >=20 > ---------- Forwarded message ---------- > From: Niels ten Oever > > To: Joseph Lorenzo Hall >, Jeroen > van der Ham > > Cc: hrpc@irtf.org > Date: Thu, 5 May 2016 12:54:59 +0200 > Subject: Re: [hrpc] New Version Notification for > draft-tenoever-hrpc-research-00.txt > Hi Joe, >=20 > Sorry for the delay, there were some building issues, and as you kn= ow > kramdown-rfc2629 is not always as verbose as one wants to be :) >=20 > Please find a new version here: > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ >=20 > Comment and questions on the list, suggestions also very much welco= me as > pull requests here (preferably with a short describption in a mail = to > the list): >=20 > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md >=20 > Best, >=20 > Niels >=20 >=20 >=20 > Niels ten Oever > Head of Digital >=20 > Article 19 > www.article19.org >=20 > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 >=20 > On 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: > > I'm aware of that. It would be good to build RFC txt too, if that= 's > > not difficult (happy to craft a PR) > > > > On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham > wrote: > >> Hi Joe, > >> Md is the Markdown format, which is basically plain text. You ca= n > get the raw format here: > >> > >> > https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-= research.md > >> > >> Jeroen. > >> > >>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall > wrote: > >>> > >>> Point of order: should we reivew the 00 document or is there a > >>> readable version in the repo we should look at? (i.e., if you c= ould > >>> transform a working copy of the md into txt that would be > wonderful). > >>> best, Joe > >>> > >>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever > > wrote: > >>>> Hi Avri, > >>>> > >>>> We're working hard on resolving some of these questions and > making a big > >>>> review. Much of the work can be followed in realtime here: > >>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.m= d > >>>> > >>>> Some replies inline to your email while I was drafting: > >>>> > >>>>> On 04/04/2016 09:52 PM, avri doria wrote: > >>>>> Hi, > >>>>> > >>>>> I did a read through but have not had a chance to write up th= e > comments > >>>>> in a legible manner. > >>>>> > >>>>> These are some general comments > >>>>> > >>>>> - the discussion centers around general behaviors and there i= s > very > >>>>> little discussion of protocol element. > >>>> > >>>> Will take this into account while re-writing. I am also trying= > to focus > >>>> on which behavior a protocol allows and disallows (or even > stimulates). > >>>> I think that is inherent part of the protocols > >>>> > >>>>> > >>>>> - Many of the effects seem more related to IP issues (e.g. > visible SRC & > >>>>> DST) than to elements of the specific protocol itself. > >>>> > >>>> IP is also a protocol, right? > >>>> > >>>>> In a sense they > >>>>> seem to be larger architectural issues (also a part of the > RG's work) as > >>>>> opposed to protocol issues. > >>>> > >>>> Not sure if it is either/or. > >>>> > >>>>> But they are not broken out that way. > >>>>> Might be worth differentiating between the architectural > issues and the > >>>>> protocol issues. > >>>> > >>>> Have been thinking about this and having a hard time coming up= > with a > >>>> clear difference between the two. Would you have suggestions > that can > >>>> help us further? > >>>> > >>>>> > >>>>> - Much on the comment of the protocols is more about how > people can > >>>>> misuse the protocols and not abut protocol elements that > enable bad or > >>>>> good behavior. > >>>>> > >>>>> - also, so much of the discussion seems to circle around > implementation > >>>>> and not the protocols themselves. > >>>> > >>>> Will try to add more concrete protocol examples, but I think > there are > >>>> also a lot of examples that show how protocol design allows fo= r > misuse, > >>>> I think that should also be addressed at protocol level (as fo= r > instance > >>>> done in html2) > >>>> > >>>>> - I think the discussion needs to take some of the work that > is going > >>>>> into protecting these protocols into account (e.g. HTTP -> > HTTPS). The > >>>>> draft did this for P2P but not for many of other discussions.= > >>>> > >>>> Working on it. > >>>> > >>>> > >>>>> - much of the discussion focuses on privacy elements, which > are already > >>>>> covered and not on other aspects of FoE and FoA. Ie. > something is a > >>>>> problem because the lack of privacy affects the FoE or FoA.=20 > This is > >>>>> good point, but is it specific to the protocols? > >>>> > >>>> Working on it. > >>>> > >>>>> - I think the consideration questions at the end are good > questions, but > >>>>> I am not sure I see how they all come from the issues > discussion in many > >>>>> cases. Might be good to link questions to specifics discusse= d > earlier > >>>>> in the draft. > >>>> > >>>> Working on it. > >>>> > >>>>> Sorry to be so last minute and somewhat less than fully > coherent about > >>>>> these. > >>>> > >>>> They're great and very useful. Always happy to discuss. > >>>> > >>>> Best, > >>>> > >>>> Niels > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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= > >>> > >>> _______________________________________________ > >>> hrpc mailing list > >>> hrpc@irtf.org > >>> https://www.irtf.org/mailman/listinfo/hrpc > >> > > > > > > >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: Joseph Lorenzo Hall > > To: Niels ten Oever > > Cc: hrpc@irtf.org , Jeroen van der Ham > > > Date: Thu, 5 May 2016 08:02:24 -0700 > Subject: Re: [hrpc] New Version Notification for > draft-tenoever-hrpc-research-00.txt > Thanks a ton, Niels! I am way too familiar with vagaries of group > kramdown building... so very much appreciate this. More soon! >=20 > On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever > wrote: > > Hi Joe, > > > > Sorry for the delay, there were some building issues, and as you = know > > kramdown-rfc2629 is not always as verbose as one wants to be :) > > > > Please find a new version here: > > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > > > > Comment and questions on the list, suggestions also very much > welcome as > > pull requests here (preferably with a short describption in a mai= l to > > the list): > > > > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > > > 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: > >> I'm aware of that. It would be good to build RFC txt too, if tha= t's > >> not difficult (happy to craft a PR) > >> > >> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham > wrote: > >>> Hi Joe, > >>> Md is the Markdown format, which is basically plain text. You > can get the raw format here: > >>> > >>> > https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-= research.md > >>> > >>> Jeroen. > >>> > >>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall > wrote: > >>>> > >>>> Point of order: should we reivew the 00 document or is there a= > >>>> readable version in the repo we should look at? (i.e., if you = could > >>>> transform a working copy of the md into txt that would be > wonderful). > >>>> best, Joe > >>>> > >>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever > > wrote: > >>>>> Hi Avri, > >>>>> > >>>>> We're working hard on resolving some of these questions and > making a big > >>>>> review. Much of the work can be followed in realtime here: > >>>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.= md > >>>>> > >>>>> Some replies inline to your email while I was drafting: > >>>>> > >>>>>> On 04/04/2016 09:52 PM, avri doria wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I did a read through but have not had a chance to write up > the comments > >>>>>> in a legible manner. > >>>>>> > >>>>>> These are some general comments > >>>>>> > >>>>>> - the discussion centers around general behaviors and there > is very > >>>>>> little discussion of protocol element. > >>>>> > >>>>> Will take this into account while re-writing. I am also tryin= g > to focus > >>>>> on which behavior a protocol allows and disallows (or even > stimulates). > >>>>> I think that is inherent part of the protocols > >>>>> > >>>>>> > >>>>>> - Many of the effects seem more related to IP issues (e.g. > visible SRC & > >>>>>> DST) than to elements of the specific protocol itself. > >>>>> > >>>>> IP is also a protocol, right? > >>>>> > >>>>>> In a sense they > >>>>>> seem to be larger architectural issues (also a part of the > RG's work) as > >>>>>> opposed to protocol issues. > >>>>> > >>>>> Not sure if it is either/or. > >>>>> > >>>>>> But they are not broken out that way. > >>>>>> Might be worth differentiating between the architectural > issues and the > >>>>>> protocol issues. > >>>>> > >>>>> Have been thinking about this and having a hard time coming u= p > with a > >>>>> clear difference between the two. Would you have suggestions > that can > >>>>> help us further? > >>>>> > >>>>>> > >>>>>> - Much on the comment of the protocols is more about how > people can > >>>>>> misuse the protocols and not abut protocol elements that > enable bad or > >>>>>> good behavior. > >>>>>> > >>>>>> - also, so much of the discussion seems to circle around > implementation > >>>>>> and not the protocols themselves. > >>>>> > >>>>> Will try to add more concrete protocol examples, but I think > there are > >>>>> also a lot of examples that show how protocol design allows > for misuse, > >>>>> I think that should also be addressed at protocol level (as > for instance > >>>>> done in html2) > >>>>> > >>>>>> - I think the discussion needs to take some of the work that= > is going > >>>>>> into protecting these protocols into account (e.g. HTTP -> > HTTPS). The > >>>>>> draft did this for P2P but not for many of other discussions= =2E > >>>>> > >>>>> Working on it. > >>>>> > >>>>> > >>>>>> - much of the discussion focuses on privacy elements, which > are already > >>>>>> covered and not on other aspects of FoE and FoA. Ie. > something is a > >>>>>> problem because the lack of privacy affects the FoE or FoA. = > This is > >>>>>> good point, but is it specific to the protocols? > >>>>> > >>>>> Working on it. > >>>>> > >>>>>> - I think the consideration questions at the end are good > questions, but > >>>>>> I am not sure I see how they all come from the issues > discussion in many > >>>>>> cases. Might be good to link questions to specifics > discussed earlier > >>>>>> in the draft. > >>>>> > >>>>> Working on it. > >>>>> > >>>>>> Sorry to be so last minute and somewhat less than fully > coherent about > >>>>>> these. > >>>>> > >>>>> They're great and very useful. Always happy to discuss. > >>>>> > >>>>> Best, > >>>>> > >>>>> Niels > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 A87= 1 > >>>> > >>>> _______________________________________________ > >>>> hrpc mailing list > >>>> hrpc@irtf.org > >>>> https://www.irtf.org/mailman/listinfo/hrpc > >>> > >> > >> > >> > > >=20 >=20 >=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 >=20 >=20 >=20 > _______________________________________________ > 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 --gDftwftXOHUaTCD8LcaEOraoPvNi85C1X 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 iQEcBAEBCAAGBQJXLIgCAAoJEAi1oPJjbWjp1FkIAJc5BbdiyPaRGZ/yNj/U86eT DxtD/6CtV+1fl8p+GEyuMV72KKapjUxylDMKmT8LoORF4OmhYALOHSEy5SQ8aBs3 oRJVFsTxUVzUBqJuq4EuMyaxEL91EqjdhUyLXDyl8XBKXmn8umVbTLIrptS0bn2p AHzvKqYo2TV571AKCtENwzvGu+39o6AUUXGao6tl7ARDWQWI3THjcecoFh1Gz8rj kgABaQ4Xk/b+j9S44CEIZTsj0Q/7O0QrRJ4LubpbKiRuRPsKCLNQ81A7nlXk2/7W kyx3AtGeiBmPxqgelGx4B+G4GyfgtYL8cp4TvtRjUHrOrCPwTzdSYpoKzPveRBg= =gm79 -----END PGP SIGNATURE----- --gDftwftXOHUaTCD8LcaEOraoPvNi85C1X-- From nobody Sat May 7 01:10: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 0684912D0DE for ; Sat, 7 May 2016 01:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WTKnubUNIvOO for ; Sat, 7 May 2016 01:10:53 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 A137112B042 for ; Sat, 7 May 2016 01:10:53 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id u185so155062653iod.3 for ; Sat, 07 May 2016 01:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=8+kif/ZL6kxEvY3/azumKitRbrCrVETk8jp1BXfgOD0=; b=I8bHjA2Dfv8uNAgyfXZgayct9OqhGGS5S7Q4dh6S3GFvGSCmro1Y9zmFi5mij7hPCz Nt6mXnA573bfxzo1+J56FZvG/BLR9upak0cKqZQWB5Mh4XpCklJMWPNGXmj0QIk3F1bV 07MDi//0v6Wyc/HIcMYPEEHyQDJgOuuiZ9AHPnph3Fm7dA+a1USNn6Ux8T1HYKJd8Qoj akmei5ChMqN/d0qEIizo7Tp5K9XcjByS1GROZzqpK/0QuE1EKI/lPCAFWOQWvBYi7IDr mAfbnmhfXhnohcIrrdGvGvdvUVizPSBEtBxOleuH1NfYVlQSoDlSliECMV4OffpR+5Um M6fw== 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:date :message-id:subject:from:to; bh=8+kif/ZL6kxEvY3/azumKitRbrCrVETk8jp1BXfgOD0=; b=ZlGsLJHEkZH49G+7wOYkTXS75KsCz7SLLv8A0yzPxsFIUYtsVwlsIZYqeRGTgyj1dG Hzrx1qIFIJtPL0s2fBZS9rn1bQ3A+zffTohrnLrLXnC1nZK4Ua3BKVBPrGBiUM/E2oxe eQuI7k7SddcLMAGrXqfb6JuSDV6fToYMyUy8q+mYhF0f7w2X87Wiv0tfYGYJBBsRxmwx hM0/XMPFALbs0tMe9lFxoGVLP+/RbDXpUomziQjmxYhbzHlqeXUBFxia0h7zvr776Kpc 2R3LfcVs2i1tAKwDxoa7i3Qkg8DMYJWyDdKfcccDvnDetrWHGRD8ka7WsYDtilZaKBdS Z/vw== X-Gm-Message-State: AOPr4FX6Ew8OCDOb7jq49zhBxNGhAGVA+C9e+dMG4lndnthto4r+sadatfuWriEOy4Tkx0Vgox9hWaCV1qWV7w== MIME-Version: 1.0 X-Received: by 10.107.10.208 with SMTP id 77mr28684546iok.51.1462608651793; Sat, 07 May 2016 01:10:51 -0700 (PDT) Received: by 10.107.14.141 with HTTP; Sat, 7 May 2016 01:10:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 May 2016 11:10:51 +0300 Message-ID: From: Dessalegn Yehuala To: hrpc@irtf.org Content-Type: multipart/alternative; boundary=001a113f8d1622e18f05323c1d7e Archived-At: Subject: Re: [hrpc] hrpc Digest, Vol 14, Issue 8 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, 07 May 2016 08:10:58 -0000 --001a113f8d1622e18f05323c1d7e Content-Type: text/plain; charset=UTF-8 Thank you Niel for the reply. I understand there are elements of the connectivity issue that cannot be solved technically. What I tried to points out in my previous e-mail is that making protocol adaptive to the various types of challenges that characterize the telecommunication infrastructure of developing countries is another dimension the work need to consider- connectivity being too often intermittent, slowness or bandwidth is too low, etc. Accessibility in its truest sense also need to consider users quality of experience which is not the case for most developing countries due to the factors mentioned earlier. I would also suggest resource sharing like traffic peering and others to be treated in the manner other factors are being considered- it potentially enhances accessibility . Best, Dessalegn On Fri, May 6, 2016 at 10:00 PM, wrote: > Send hrpc mailing list submissions to > hrpc@irtf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/hrpc > or, via email, send a message with subject or body 'help' to > hrpc-request@irtf.org > > You can reach the person managing the list at > hrpc-owner@irtf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of hrpc digest..." > > Today's Topics: > > 1. Re: access (Niels ten Oever) > > > ---------- Forwarded message ---------- > From: Niels ten Oever > To: hrpc@irtf.org > Cc: > Date: Fri, 6 May 2016 14:03:14 +0200 > Subject: Re: [hrpc] access > Dear Dessalegn, > > Thank you for your email. I think in the draft [0] we have been focusing > on topics that go beyond freedom of speech, for instance where we looked > at freedom of association, non-discrimination, equal protection, > political participation, participation in cultural life, arts and > science and the right to security. > > As you say, connectivity is an inherent part of freedom as expression, > and that is also how it is defined in the draft. But I am afraid that > providing access to the Internet is not a protocol issue where is comes > to providing the actual connection and providing bandwith (please > correct me if I'm wrong!). Therefore I think it is outside of the > purview of this document and research group. > > We do however have explicit references to usage of protocols on low > bandwith, high latency connections, have for instance a look at > '5.3.2.1.11. Accessibility' and '5.3.2.1.14. Reliability'. > > Always happy to discuss. > > All the best, > > Niels > > https://tools.ietf.org/html/draft-tenoever-hrpc-research-01 > > > > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > > On 05/06/2016 10:00 AM, Dessalegn Yehuala wrote: > > I have been a silent subscriber of the mailing list for some time, > > having read the Internet drafts published recently I thought it would be > > good to forward one item that can provide a new dimension to the ongoing > > work. It has been repeatedly said that access to the Internet is > > becoming more and more a human right issue- I feel the working group > > approach need to be beyond the protection of freedom of speech, as it > > has tried to be to an extent in the case of making the Internet > > environment accessible for people with disability. The large chunks of > > population in developing countries or countries in the global south are > > disconnected and the accessibility issue also need to be one of the > > targets in the design of a protocol that addresses human rights related > > issue. > > > > Dessalegn. > > > > On Thu, May 5, 2016 at 10:00 PM, > > wrote: > > > > Send hrpc mailing list submissions to > > hrpc@irtf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.irtf.org/mailman/listinfo/hrpc > > or, via email, send a message with subject or body 'help' to > > hrpc-request@irtf.org > > > > You can reach the person managing the list at > > hrpc-owner@irtf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of hrpc digest..." > > > > Today's Topics: > > > > 1. Re: New Version Notification for > > draft-tenoever-hrpc-research-00.txt (Niels ten Oever) > > 2. Re: New Version Notification for > > draft-tenoever-hrpc-research-00.txt (Joseph Lorenzo Hall) > > > > > > ---------- Forwarded message ---------- > > From: Niels ten Oever niels@article19.org>> > > To: Joseph Lorenzo Hall >, Jeroen > > van der Ham > > > Cc: hrpc@irtf.org > > Date: Thu, 5 May 2016 12:54:59 +0200 > > Subject: Re: [hrpc] New Version Notification for > > draft-tenoever-hrpc-research-00.txt > > Hi Joe, > > > > Sorry for the delay, there were some building issues, and as you know > > kramdown-rfc2629 is not always as verbose as one wants to be :) > > > > Please find a new version here: > > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > > > > Comment and questions on the list, suggestions also very much > welcome as > > pull requests here (preferably with a short describption in a mail to > > the list): > > > > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > > > 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: > > > I'm aware of that. It would be good to build RFC txt too, if that's > > > not difficult (happy to craft a PR) > > > > > > On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham > > wrote: > > >> Hi Joe, > > >> Md is the Markdown format, which is basically plain text. You can > > get the raw format here: > > >> > > >> > > > https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > >> > > >> Jeroen. > > >> > > >>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall > > wrote: > > >>> > > >>> Point of order: should we reivew the 00 document or is there a > > >>> readable version in the repo we should look at? (i.e., if you > could > > >>> transform a working copy of the md into txt that would be > > wonderful). > > >>> best, Joe > > >>> > > >>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever > > > wrote: > > >>>> Hi Avri, > > >>>> > > >>>> We're working hard on resolving some of these questions and > > making a big > > >>>> review. Much of the work can be followed in realtime here: > > >>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > >>>> > > >>>> Some replies inline to your email while I was drafting: > > >>>> > > >>>>> On 04/04/2016 09:52 PM, avri doria wrote: > > >>>>> Hi, > > >>>>> > > >>>>> I did a read through but have not had a chance to write up the > > comments > > >>>>> in a legible manner. > > >>>>> > > >>>>> These are some general comments > > >>>>> > > >>>>> - the discussion centers around general behaviors and there is > > very > > >>>>> little discussion of protocol element. > > >>>> > > >>>> Will take this into account while re-writing. I am also trying > > to focus > > >>>> on which behavior a protocol allows and disallows (or even > > stimulates). > > >>>> I think that is inherent part of the protocols > > >>>> > > >>>>> > > >>>>> - Many of the effects seem more related to IP issues (e.g. > > visible SRC & > > >>>>> DST) than to elements of the specific protocol itself. > > >>>> > > >>>> IP is also a protocol, right? > > >>>> > > >>>>> In a sense they > > >>>>> seem to be larger architectural issues (also a part of the > > RG's work) as > > >>>>> opposed to protocol issues. > > >>>> > > >>>> Not sure if it is either/or. > > >>>> > > >>>>> But they are not broken out that way. > > >>>>> Might be worth differentiating between the architectural > > issues and the > > >>>>> protocol issues. > > >>>> > > >>>> Have been thinking about this and having a hard time coming up > > with a > > >>>> clear difference between the two. Would you have suggestions > > that can > > >>>> help us further? > > >>>> > > >>>>> > > >>>>> - Much on the comment of the protocols is more about how > > people can > > >>>>> misuse the protocols and not abut protocol elements that > > enable bad or > > >>>>> good behavior. > > >>>>> > > >>>>> - also, so much of the discussion seems to circle around > > implementation > > >>>>> and not the protocols themselves. > > >>>> > > >>>> Will try to add more concrete protocol examples, but I think > > there are > > >>>> also a lot of examples that show how protocol design allows for > > misuse, > > >>>> I think that should also be addressed at protocol level (as for > > instance > > >>>> done in html2) > > >>>> > > >>>>> - I think the discussion needs to take some of the work that > > is going > > >>>>> into protecting these protocols into account (e.g. HTTP -> > > HTTPS). The > > >>>>> draft did this for P2P but not for many of other discussions. > > >>>> > > >>>> Working on it. > > >>>> > > >>>> > > >>>>> - much of the discussion focuses on privacy elements, which > > are already > > >>>>> covered and not on other aspects of FoE and FoA. Ie. > > something is a > > >>>>> problem because the lack of privacy affects the FoE or FoA. > > This is > > >>>>> good point, but is it specific to the protocols? > > >>>> > > >>>> Working on it. > > >>>> > > >>>>> - I think the consideration questions at the end are good > > questions, but > > >>>>> I am not sure I see how they all come from the issues > > discussion in many > > >>>>> cases. Might be good to link questions to specifics discussed > > earlier > > >>>>> in the draft. > > >>>> > > >>>> Working on it. > > >>>> > > >>>>> Sorry to be so last minute and somewhat less than fully > > coherent about > > >>>>> these. > > >>>> > > >>>> They're great and very useful. Always happy to discuss. > > >>>> > > >>>> Best, > > >>>> > > >>>> Niels > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > >>> > > >>> _______________________________________________ > > >>> hrpc mailing list > > >>> hrpc@irtf.org > > >>> https://www.irtf.org/mailman/listinfo/hrpc > > >> > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > From: Joseph Lorenzo Hall > > > To: Niels ten Oever >> > > Cc: hrpc@irtf.org , Jeroen van der Ham > > > > > Date: Thu, 5 May 2016 08:02:24 -0700 > > Subject: Re: [hrpc] New Version Notification for > > draft-tenoever-hrpc-research-00.txt > > Thanks a ton, Niels! I am way too familiar with vagaries of group > > kramdown building... so very much appreciate this. More soon! > > > > On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever > > wrote: > > > Hi Joe, > > > > > > Sorry for the delay, there were some building issues, and as you > know > > > kramdown-rfc2629 is not always as verbose as one wants to be :) > > > > > > Please find a new version here: > > > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > > > > > > Comment and questions on the list, suggestions also very much > > welcome as > > > pull requests here (preferably with a short describption in a mail > to > > > the list): > > > > > > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > > > > > 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote: > > >> I'm aware of that. It would be good to build RFC txt too, if > that's > > >> not difficult (happy to craft a PR) > > >> > > >> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham > > wrote: > > >>> Hi Joe, > > >>> Md is the Markdown format, which is basically plain text. You > > can get the raw format here: > > >>> > > >>> > > > https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > >>> > > >>> Jeroen. > > >>> > > >>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall > > wrote: > > >>>> > > >>>> Point of order: should we reivew the 00 document or is there a > > >>>> readable version in the repo we should look at? (i.e., if you > could > > >>>> transform a working copy of the md into txt that would be > > wonderful). > > >>>> best, Joe > > >>>> > > >>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever > > > wrote: > > >>>>> Hi Avri, > > >>>>> > > >>>>> We're working hard on resolving some of these questions and > > making a big > > >>>>> review. Much of the work can be followed in realtime here: > > >>>>> > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md > > >>>>> > > >>>>> Some replies inline to your email while I was drafting: > > >>>>> > > >>>>>> On 04/04/2016 09:52 PM, avri doria wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I did a read through but have not had a chance to write up > > the comments > > >>>>>> in a legible manner. > > >>>>>> > > >>>>>> These are some general comments > > >>>>>> > > >>>>>> - the discussion centers around general behaviors and there > > is very > > >>>>>> little discussion of protocol element. > > >>>>> > > >>>>> Will take this into account while re-writing. I am also trying > > to focus > > >>>>> on which behavior a protocol allows and disallows (or even > > stimulates). > > >>>>> I think that is inherent part of the protocols > > >>>>> > > >>>>>> > > >>>>>> - Many of the effects seem more related to IP issues (e.g. > > visible SRC & > > >>>>>> DST) than to elements of the specific protocol itself. > > >>>>> > > >>>>> IP is also a protocol, right? > > >>>>> > > >>>>>> In a sense they > > >>>>>> seem to be larger architectural issues (also a part of the > > RG's work) as > > >>>>>> opposed to protocol issues. > > >>>>> > > >>>>> Not sure if it is either/or. > > >>>>> > > >>>>>> But they are not broken out that way. > > >>>>>> Might be worth differentiating between the architectural > > issues and the > > >>>>>> protocol issues. > > >>>>> > > >>>>> Have been thinking about this and having a hard time coming up > > with a > > >>>>> clear difference between the two. Would you have suggestions > > that can > > >>>>> help us further? > > >>>>> > > >>>>>> > > >>>>>> - Much on the comment of the protocols is more about how > > people can > > >>>>>> misuse the protocols and not abut protocol elements that > > enable bad or > > >>>>>> good behavior. > > >>>>>> > > >>>>>> - also, so much of the discussion seems to circle around > > implementation > > >>>>>> and not the protocols themselves. > > >>>>> > > >>>>> Will try to add more concrete protocol examples, but I think > > there are > > >>>>> also a lot of examples that show how protocol design allows > > for misuse, > > >>>>> I think that should also be addressed at protocol level (as > > for instance > > >>>>> done in html2) > > >>>>> > > >>>>>> - I think the discussion needs to take some of the work that > > is going > > >>>>>> into protecting these protocols into account (e.g. HTTP -> > > HTTPS). The > > >>>>>> draft did this for P2P but not for many of other discussions. > > >>>>> > > >>>>> Working on it. > > >>>>> > > >>>>> > > >>>>>> - much of the discussion focuses on privacy elements, which > > are already > > >>>>>> covered and not on other aspects of FoE and FoA. Ie. > > something is a > > >>>>>> problem because the lack of privacy affects the FoE or FoA. > > This is > > >>>>>> good point, but is it specific to the protocols? > > >>>>> > > >>>>> Working on it. > > >>>>> > > >>>>>> - I think the consideration questions at the end are good > > questions, but > > >>>>>> I am not sure I see how they all come from the issues > > discussion in many > > >>>>>> cases. Might be good to link questions to specifics > > discussed earlier > > >>>>>> in the draft. > > >>>>> > > >>>>> Working on it. > > >>>>> > > >>>>>> Sorry to be so last minute and somewhat less than fully > > coherent about > > >>>>>> these. > > >>>>> > > >>>>> They're great and very useful. Always happy to discuss. > > >>>>> > > >>>>> Best, > > >>>>> > > >>>>> Niels > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 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 > > >>>> > > >>>> _______________________________________________ > > >>>> 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 > > > > > > > > _______________________________________________ > > 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 > > --001a113f8d1622e18f05323c1d7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Niel for the reply. I understand there are eleme= nts of the connectivity issue that cannot be solved technically. What I tri= ed to points out in my previous e-mail is that making protocol adaptive to = the various types of challenges that characterize the telecommunication inf= rastructure of developing countries is another dimension the work need to c= onsider- connectivity being too often intermittent, slowness or bandwidth i= s too low, etc. Accessibility in its truest sense also need to consider use= rs quality of experience which is not the case for most developing countrie= s due to the factors mentioned earlier.=C2=A0 I would also suggest resource= sharing like traffic peering and others to be treated in the manner other = factors are being considered- it potentially =C2=A0enhances accessibility .=

Best,
Dessalegn

On Fri, May 6, 2016 at 10:00 PM, <= span dir=3D"ltr"><hrpc-request@irtf.org> wrote:
Send hrpc mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc@irtf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.irtf.org/mailman/l= istinfo/hrpc
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc-r= equest@irtf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc-own= er@irtf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hrpc digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: access (Niels ten Oever)


---------- Forwarded message ----------
From:=C2=A0Niels ten Oev= er <niels@article19.org>To:=C2=A0hrpc@irtf.org
Cc:=C2=A0<= br>Date:=C2=A0Fri, 6 May 2016 14:03:14 +0200
Subject:=C2=A0Re: [hrpc] ac= cess
Dear Dessalegn,

Thank you for your email. I think in the draft [0] we have been focusing on topics that go beyond freedom of speech, for instance where we looked at freedom of association, non-discrimination, equal protection,
political participation, participation in cultural life, arts and
science and the right to security.

As you say, connectivity is an inherent part of freedom as expression,
and that is also how it is defined in the draft. But I am afraid that
providing access to the Internet is not a protocol issue where is comes
to providing the actual connection and providing bandwith (please
correct me if I'm wrong!). Therefore I think it is outside of the
purview of this document and research group.

We do however have explicit references to usage of protocols on low
bandwith, high latency connections, have for instance a look at
'5.3.2.1.11.=C2=A0 Accessibility' and '5.3.2.1.14.=C2=A0 Reliab= ility'.

Always happy to discuss.

All the best,

Niels

https://tools.ietf.org/html/draft-tenoeve= r-hrpc-research-01



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

On 05/06/2016 10:00 AM, Dessalegn Yehuala wrote:
> I have been a silent subscriber of the mailing list for some time,
> having read the Internet drafts published recently I thought it would = be
> good to forward one item that can provide a new dimension to the ongoi= ng
> work. It has been repeatedly said that access to the Internet is
> becoming more and more a human right issue- I feel the working group > approach need to be beyond the protection of freedom of speech, as it<= br> > has tried to be to an extent in the case of making the Internet
> environment accessible for people with disability. The large chunks of=
> population in developing countries or countries in the global south ar= e
> disconnected and the accessibility issue also need to be one of the > targets in the design of a protocol that addresses human rights relate= d
> issue.
>
> Dessalegn.
>
> On Thu, May 5, 2016 at 10:00 PM, <hrpc-request@irtf.org
> <mailto:hrpc-request@irtf.= org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Send hrpc mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hrpc@irtf.org <mailto:hrp= c@irtf.org>
>
>=C2=A0 =C2=A0 =C2=A0To subscribe or unsubscribe via the World Wide Web,= visit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //www.irtf.org/mailman/listinfo/hrpc
>=C2=A0 =C2=A0 =C2=A0or, via email, send a message with subject or body = 'help' to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hrpc-request@irtf.org <mailto:hrpc-request@irtf.org>
>
>=C2=A0 =C2=A0 =C2=A0You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hrpc-owner@irtf.org <mailto:hrpc-owner@irtf.org>
>
>=C2=A0 =C2=A0 =C2=A0When replying, please edit your Subject line so it = is more specific
>=C2=A0 =C2=A0 =C2=A0than "Re: Contents of hrpc digest..."
>
>=C2=A0 =C2=A0 =C2=A0Today's Topics:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Re: New Version Notification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tenoever-hrpc-research-0= 0.txt (Niels ten Oever)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Re: New Version Notification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tenoever-hrpc-research-0= 0.txt (Joseph Lorenzo Hall)
>
>
>=C2=A0 =C2=A0 =C2=A0---------- Forwarded message ----------
>=C2=A0 =C2=A0 =C2=A0From: Niels ten Oever <niels@article19.org <mailto:niels@article19.org>>
>=C2=A0 =C2=A0 =C2=A0To: Joseph Lorenzo Hall <joe@cdt.org <mailto:joe@cdt.o= rg>>, Jeroen
>=C2=A0 =C2=A0 =C2=A0van der Ham <je= roen@os3.nl <mailto:jeroen@os3.nl>>
>=C2=A0 =C2=A0 =C2=A0Cc: hrpc@irtf.org<= /a> <mailto:hrpc@irtf.org>
>=C2=A0 =C2=A0 =C2=A0Date: Thu, 5 May 2016 12:54:59 +0200
>=C2=A0 =C2=A0 =C2=A0Subject: Re: [hrpc] New Version Notification for >=C2=A0 =C2=A0 =C2=A0draft-tenoever-hrpc-research-00.txt
>=C2=A0 =C2=A0 =C2=A0Hi Joe,
>
>=C2=A0 =C2=A0 =C2=A0Sorry for the delay, there were some building issue= s, and as you know
>=C2=A0 =C2=A0 =C2=A0kramdown-rfc2629 is not always as verbose as one wa= nts to be :)
>
>=C2=A0 =C2=A0 =C2=A0Please find a new version here:
>=C2=A0 =C2=A0 =C2=A0https://datatr= acker.ietf.org/doc/draft-tenoever-hrpc-research/
>
>=C2=A0 =C2=A0 =C2=A0Comment and questions on the list, suggestions also= very much welcome as
>=C2=A0 =C2=A0 =C2=A0pull requests here (preferably with a short describ= ption in a mail to
>=C2=A0 =C2=A0 =C2=A0the list):
>
>=C2=A0 =C2=A0 =C2=A0https://githu= b.com/nllz/IRTF-HRPC/blob/master/draft-research.md
>
>=C2=A0 =C2=A0 =C2=A0Best,
>
>=C2=A0 =C2=A0 =C2=A0Niels
>
>
>
>=C2=A0 =C2=A0 =C2=A0Niels ten Oever
>=C2=A0 =C2=A0 =C2=A0Head of Digital
>
>=C2=A0 =C2=A0 =C2=A0Article 19
>=C2=A0 =C2=A0 =C2=A0www.article19.org <http://www.article19.org>
>
>=C2=A0 =C2=A0 =C2=A0PGP fingerprint=C2=A0 =C2=A0 8D9F C567 BEE4 A431 56= C4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 678B 08B5 A0F2 636D 68E9
>
>=C2=A0 =C2=A0 =C2=A0On 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote:<= br> >=C2=A0 =C2=A0 =C2=A0> I'm aware of that. It would be good to bui= ld RFC txt too, if that's
>=C2=A0 =C2=A0 =C2=A0> not difficult (happy to craft a PR)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der= Ham <jeroen@os3.nl
>=C2=A0 =C2=A0 =C2=A0<mailto:jeroen@= os3.nl>> wrote:
>=C2=A0 =C2=A0 =C2=A0>> Hi Joe,
>=C2=A0 =C2=A0 =C2=A0>> Md is the Markdown format, which is basica= lly plain text. You can
>=C2=A0 =C2=A0 =C2=A0get the raw format here:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-resear= ch.md
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Jeroen.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>> On 04 May 2016, at 16:29, Joseph Loren= zo Hall <joe@cdt.org
>=C2=A0 =C2=A0 =C2=A0<mailto:joe@cdt.o= rg>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Point of order: should we reivew the 0= 0 document or is there a
>=C2=A0 =C2=A0 =C2=A0>>> readable version in the repo we should= look at? (i.e., if you could
>=C2=A0 =C2=A0 =C2=A0>>> transform a working copy of the md int= o txt that would be
>=C2=A0 =C2=A0 =C2=A0wonderful).
>=C2=A0 =C2=A0 =C2=A0>>> best, Joe
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On Wed, May 4, 2016 at 8:48 AM, Ni= els ten Oever
>=C2=A0 =C2=A0 =C2=A0<niels@ar= ticle19.org <mailto:niels@art= icle19.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>> Hi Avri,
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> We're working hard on resolvin= g some of these questions and
>=C2=A0 =C2=A0 =C2=A0making a big
>=C2=A0 =C2=A0 =C2=A0>>>> review. Much of the work can be fo= llowed in realtime here:
>=C2=A0 =C2=A0 =C2=A0>>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Some replies inline to your email = while I was drafting:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> On 04/04/2016 09:52 PM, avri d= oria wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>> Hi,
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I did a read through but have = not had a chance to write up the
>=C2=A0 =C2=A0 =C2=A0comments
>=C2=A0 =C2=A0 =C2=A0>>>>> in a legible manner.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> These are some general comment= s
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - the discussion centers aroun= d general behaviors and there is
>=C2=A0 =C2=A0 =C2=A0very
>=C2=A0 =C2=A0 =C2=A0>>>>> little discussion of protocol = element.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Will take this into account while = re-writing. I am also trying
>=C2=A0 =C2=A0 =C2=A0to focus
>=C2=A0 =C2=A0 =C2=A0>>>> on which behavior a protocol allow= s and disallows (or even
>=C2=A0 =C2=A0 =C2=A0stimulates).
>=C2=A0 =C2=A0 =C2=A0>>>> I think that is inherent part of t= he protocols
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - Many of the effects seem mor= e related to IP issues (e.g.
>=C2=A0 =C2=A0 =C2=A0visible SRC &
>=C2=A0 =C2=A0 =C2=A0>>>>> DST) than to elements of the s= pecific protocol itself.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> IP is also a protocol, right?
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> In a sense they
>=C2=A0 =C2=A0 =C2=A0>>>>> seem to be larger architectura= l issues (also a part of the
>=C2=A0 =C2=A0 =C2=A0RG's work) as
>=C2=A0 =C2=A0 =C2=A0>>>>> opposed to protocol issues. >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Not sure if it is either/or.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> But they are not broken out th= at way.
>=C2=A0 =C2=A0 =C2=A0>>>>> Might be worth differentiating= between the architectural
>=C2=A0 =C2=A0 =C2=A0issues and the
>=C2=A0 =C2=A0 =C2=A0>>>>> protocol issues.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Have been thinking about this and = having a hard time coming up
>=C2=A0 =C2=A0 =C2=A0with a
>=C2=A0 =C2=A0 =C2=A0>>>> clear difference between the two. = Would you have suggestions
>=C2=A0 =C2=A0 =C2=A0that can
>=C2=A0 =C2=A0 =C2=A0>>>> help us further?
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - Much on the comment of the p= rotocols is more about how
>=C2=A0 =C2=A0 =C2=A0people can
>=C2=A0 =C2=A0 =C2=A0>>>>> misuse the protocols and not a= but protocol elements that
>=C2=A0 =C2=A0 =C2=A0enable bad or
>=C2=A0 =C2=A0 =C2=A0>>>>> good behavior.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - also, so much of the discuss= ion seems to circle around
>=C2=A0 =C2=A0 =C2=A0implementation
>=C2=A0 =C2=A0 =C2=A0>>>>> and not the protocols themselv= es.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Will try to add more concrete prot= ocol examples, but I think
>=C2=A0 =C2=A0 =C2=A0there are
>=C2=A0 =C2=A0 =C2=A0>>>> also a lot of examples that show h= ow protocol design allows for
>=C2=A0 =C2=A0 =C2=A0misuse,
>=C2=A0 =C2=A0 =C2=A0>>>> I think that should also be addres= sed at protocol level (as for
>=C2=A0 =C2=A0 =C2=A0instance
>=C2=A0 =C2=A0 =C2=A0>>>> done in html2)
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - I think the discussion needs= to take some of the work that
>=C2=A0 =C2=A0 =C2=A0is going
>=C2=A0 =C2=A0 =C2=A0>>>>> into protecting these protocol= s into account (e.g. HTTP ->
>=C2=A0 =C2=A0 =C2=A0HTTPS). The
>=C2=A0 =C2=A0 =C2=A0>>>>> draft did this for P2P but not= for many of other discussions.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Working on it.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - much of the discussion focus= es on privacy elements, which
>=C2=A0 =C2=A0 =C2=A0are already
>=C2=A0 =C2=A0 =C2=A0>>>>> covered and not on other aspec= ts of FoE and FoA.=C2=A0 Ie.
>=C2=A0 =C2=A0 =C2=A0something is a
>=C2=A0 =C2=A0 =C2=A0>>>>> problem because the lack of pr= ivacy affects the FoE or FoA.
>=C2=A0 =C2=A0 =C2=A0This is
>=C2=A0 =C2=A0 =C2=A0>>>>> good point, but is it specific= to the protocols?
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Working on it.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - I think the consideration qu= estions at the end are good
>=C2=A0 =C2=A0 =C2=A0questions, but
>=C2=A0 =C2=A0 =C2=A0>>>>> I am not sure I see how they a= ll come from the issues
>=C2=A0 =C2=A0 =C2=A0discussion in many
>=C2=A0 =C2=A0 =C2=A0>>>>> cases.=C2=A0 Might be good to = link questions to specifics discussed
>=C2=A0 =C2=A0 =C2=A0earlier
>=C2=A0 =C2=A0 =C2=A0>>>>> in the draft.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Working on it.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Sorry to be so last minute and= somewhat less than fully
>=C2=A0 =C2=A0 =C2=A0coherent about
>=C2=A0 =C2=A0 =C2=A0>>>>> these.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> They're great and very useful.= Always happy to discuss.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Best,
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Niels
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> __________________________________= _____________
>=C2=A0 =C2=A0 =C2=A0>>>> hrpc mailing list
>=C2=A0 =C2=A0 =C2=A0>>>> h= rpc@irtf.org <mailto:hrpc@irtf.org<= /a>>
>=C2=A0 =C2=A0 =C2=A0>>>> https://www.irtf.= org/mailman/listinfo/hrpc
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> --
>=C2=A0 =C2=A0 =C2=A0>>> Joseph Lorenzo Hall
>=C2=A0 =C2=A0 =C2=A0>>> Chief Technologist, Center for Democra= cy & Technology
>=C2=A0 =C2=A0 =C2=A0[https://www.cdt.org]
>=C2=A0 =C2=A0 =C2=A0>>> 1401 K ST NW STE 200, Washington DC 20= 005-3497
>=C2=A0 =C2=A0 =C2=A0>>> e: joe@= cdt.org <mailto:joe@cdt.org>, = p: 202.407.8825
>=C2=A0 =C2=A0 =C2=A0<tel:202.407.8825>, pgp: https://josephhall.org/gpg-key=
>=C2=A0 =C2=A0 =C2=A0>>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10= =C2=A0 1607 5F86 6987 40A9 A871
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> ______________________________________= _________
>=C2=A0 =C2=A0 =C2=A0>>> hrpc mailing list
>=C2=A0 =C2=A0 =C2=A0>>> hrpc@= irtf.org <mailto:hrpc@irtf.org&= gt;
>=C2=A0 =C2=A0 =C2=A0>>> https://www.irtf.org/= mailman/listinfo/hrpc
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>
>
>
>=C2=A0 =C2=A0 =C2=A0---------- Forwarded message ----------
>=C2=A0 =C2=A0 =C2=A0From: Joseph Lorenzo Hall <joe@cdt.org <mailto:joe@cdt= .org>>
>=C2=A0 =C2=A0 =C2=A0To: Niels ten Oever <niels@article19.org <mailto:niels@article19.org>>
>=C2=A0 =C2=A0 =C2=A0Cc: hrpc@irtf.org<= /a> <mailto:hrpc@irtf.org>, Jero= en van der Ham
>=C2=A0 =C2=A0 =C2=A0<jeroen@os3.nl<= /a> <mailto:jeroen@os3.nl>> >=C2=A0 =C2=A0 =C2=A0Date: Thu, 5 May 2016 08:02:24 -0700
>=C2=A0 =C2=A0 =C2=A0Subject: Re: [hrpc] New Version Notification for >=C2=A0 =C2=A0 =C2=A0draft-tenoever-hrpc-research-00.txt
>=C2=A0 =C2=A0 =C2=A0Thanks a ton, Niels! I am way too familiar with vag= aries of group
>=C2=A0 =C2=A0 =C2=A0kramdown building... so very much appreciate this. = More soon!
>
>=C2=A0 =C2=A0 =C2=A0On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever <= ;niels@article19.org
>=C2=A0 =C2=A0 =C2=A0<mailto:n= iels@article19.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0> Hi Joe,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Sorry for the delay, there were some building = issues, and as you know
>=C2=A0 =C2=A0 =C2=A0> kramdown-rfc2629 is not always as verbose as o= ne wants to be :)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Please find a new version here:
>=C2=A0 =C2=A0 =C2=A0> https://d= atatracker.ietf.org/doc/draft-tenoever-hrpc-research/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Comment and questions on the list, suggestions= also very much
>=C2=A0 =C2=A0 =C2=A0welcome as
>=C2=A0 =C2=A0 =C2=A0> pull requests here (preferably with a short de= scribption in a mail to
>=C2=A0 =C2=A0 =C2=A0> the list):
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> https://= github.com/nllz/IRTF-HRPC/blob/master/draft-research.md
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Best,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Niels
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Niels ten Oever
>=C2=A0 =C2=A0 =C2=A0> Head of Digital
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Article 19
>=C2=A0 =C2=A0 =C2=A0> www.article19.org <http://www.article19.o= rg>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> PGP fingerprint=C2=A0 =C2=A0 8D9F C567 BEE4 A4= 31 56C4
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 678B 08B5 A0F2 636D 68E9
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On 05/04/2016 07:24 PM, Joseph Lorenzo Hall wr= ote:
>=C2=A0 =C2=A0 =C2=A0>> I'm aware of that. It would be good to= build RFC txt too, if that's
>=C2=A0 =C2=A0 =C2=A0>> not difficult (happy to craft a PR)
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On Wed, May 4, 2016 at 1:20 PM, Jeroen van= der Ham <jeroen@os3.nl
>=C2=A0 =C2=A0 =C2=A0<mailto:jeroen@= os3.nl>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>> Hi Joe,
>=C2=A0 =C2=A0 =C2=A0>>> Md is the Markdown format, which is ba= sically plain text. You
>=C2=A0 =C2=A0 =C2=A0can get the raw format here:
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-resear= ch.md
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Jeroen.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 04 May 2016, at 16:29, Joseph L= orenzo Hall <joe@cdt.org
>=C2=A0 =C2=A0 =C2=A0<mailto:joe@cdt.o= rg>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Point of order: should we reivew t= he 00 document or is there a
>=C2=A0 =C2=A0 =C2=A0>>>> readable version in the repo we sh= ould look at? (i.e., if you could
>=C2=A0 =C2=A0 =C2=A0>>>> transform a working copy of the md= into txt that would be
>=C2=A0 =C2=A0 =C2=A0wonderful).
>=C2=A0 =C2=A0 =C2=A0>>>> best, Joe
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> On Wed, May 4, 2016 at 8:48 AM= , Niels ten Oever
>=C2=A0 =C2=A0 =C2=A0<niels@ar= ticle19.org <mailto:niels@art= icle19.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>> Hi Avri,
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> We're working hard on reso= lving some of these questions and
>=C2=A0 =C2=A0 =C2=A0making a big
>=C2=A0 =C2=A0 =C2=A0>>>>> review. Much of the work can b= e followed in realtime here:
>=C2=A0 =C2=A0 =C2=A0>>>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md=
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Some replies inline to your em= ail while I was drafting:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 04/04/2016 09:52 PM, av= ri doria wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>> Hi,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> I did a read through but h= ave not had a chance to write up
>=C2=A0 =C2=A0 =C2=A0the comments
>=C2=A0 =C2=A0 =C2=A0>>>>>> in a legible manner.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> These are some general com= ments
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> - the discussion centers a= round general behaviors and there
>=C2=A0 =C2=A0 =C2=A0is very
>=C2=A0 =C2=A0 =C2=A0>>>>>> little discussion of proto= col element.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Will take this into account wh= ile re-writing. I am also trying
>=C2=A0 =C2=A0 =C2=A0to focus
>=C2=A0 =C2=A0 =C2=A0>>>>> on which behavior a protocol a= llows and disallows (or even
>=C2=A0 =C2=A0 =C2=A0stimulates).
>=C2=A0 =C2=A0 =C2=A0>>>>> I think that is inherent part = of the protocols
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> - Many of the effects seem= more related to IP issues (e.g.
>=C2=A0 =C2=A0 =C2=A0visible SRC &
>=C2=A0 =C2=A0 =C2=A0>>>>>> DST) than to elements of t= he specific protocol itself.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> IP is also a protocol, right?<= br> >=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> In a sense they
>=C2=A0 =C2=A0 =C2=A0>>>>>> seem to be larger architec= tural issues (also a part of the
>=C2=A0 =C2=A0 =C2=A0RG's work) as
>=C2=A0 =C2=A0 =C2=A0>>>>>> opposed to protocol issues= .
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Not sure if it is either/or. >=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> But they are not broken ou= t that way.
>=C2=A0 =C2=A0 =C2=A0>>>>>> Might be worth differentia= ting between the architectural
>=C2=A0 =C2=A0 =C2=A0issues and the
>=C2=A0 =C2=A0 =C2=A0>>>>>> protocol issues.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Have been thinking about this = and having a hard time coming up
>=C2=A0 =C2=A0 =C2=A0with a
>=C2=A0 =C2=A0 =C2=A0>>>>> clear difference between the t= wo. Would you have suggestions
>=C2=A0 =C2=A0 =C2=A0that can
>=C2=A0 =C2=A0 =C2=A0>>>>> help us further?
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> - Much on the comment of t= he protocols is more about how
>=C2=A0 =C2=A0 =C2=A0people can
>=C2=A0 =C2=A0 =C2=A0>>>>>> misuse the protocols and n= ot abut protocol elements that
>=C2=A0 =C2=A0 =C2=A0enable bad or
>=C2=A0 =C2=A0 =C2=A0>>>>>> good behavior.
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> - also, so much of the dis= cussion seems to circle around
>=C2=A0 =C2=A0 =C2=A0implementation
>=C2=A0 =C2=A0 =C2=A0>>>>>> and not the protocols them= selves.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Will try to add more concrete = protocol examples, but I think
>=C2=A0 =C2=A0 =C2=A0there are
>=C2=A0 =C2=A0 =C2=A0>>>>> also a lot of examples that sh= ow how protocol design allows
>=C2=A0 =C2=A0 =C2=A0for misuse,
>=C2=A0 =C2=A0 =C2=A0>>>>> I think that should also be ad= dressed at protocol level (as
>=C2=A0 =C2=A0 =C2=A0for instance
>=C2=A0 =C2=A0 =C2=A0>>>>> done in html2)
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> - I think the discussion n= eeds to take some of the work that
>=C2=A0 =C2=A0 =C2=A0is going
>=C2=A0 =C2=A0 =C2=A0>>>>>> into protecting these prot= ocols into account (e.g. HTTP ->
>=C2=A0 =C2=A0 =C2=A0HTTPS). The
>=C2=A0 =C2=A0 =C2=A0>>>>>> draft did this for P2P but= not for many of other discussions.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Working on it.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> - much of the discussion f= ocuses on privacy elements, which
>=C2=A0 =C2=A0 =C2=A0are already
>=C2=A0 =C2=A0 =C2=A0>>>>>> covered and not on other a= spects of FoE and FoA.=C2=A0 Ie.
>=C2=A0 =C2=A0 =C2=A0something is a
>=C2=A0 =C2=A0 =C2=A0>>>>>> problem because the lack o= f privacy affects the FoE or FoA.
>=C2=A0 =C2=A0 =C2=A0This is
>=C2=A0 =C2=A0 =C2=A0>>>>>> good point, but is it spec= ific to the protocols?
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Working on it.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> - I think the consideratio= n questions at the end are good
>=C2=A0 =C2=A0 =C2=A0questions, but
>=C2=A0 =C2=A0 =C2=A0>>>>>> I am not sure I see how th= ey all come from the issues
>=C2=A0 =C2=A0 =C2=A0discussion in many
>=C2=A0 =C2=A0 =C2=A0>>>>>> cases.=C2=A0 Might be good= to link questions to specifics
>=C2=A0 =C2=A0 =C2=A0discussed earlier
>=C2=A0 =C2=A0 =C2=A0>>>>>> in the draft.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Working on it.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Sorry to be so last minute= and somewhat less than fully
>=C2=A0 =C2=A0 =C2=A0coherent about
>=C2=A0 =C2=A0 =C2=A0>>>>>> these.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> They're great and very use= ful. Always happy to discuss.
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Best,
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> Niels
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> ______________________________= _________________
>=C2=A0 =C2=A0 =C2=A0>>>>> hrpc mailing list
>=C2=A0 =C2=A0 =C2=A0>>>>> hrpc@irtf.org <mailto:hrpc@irtf.= org>
>=C2=A0 =C2=A0 =C2=A0>>>>> https://www.i= rtf.org/mailman/listinfo/hrpc
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> --
>=C2=A0 =C2=A0 =C2=A0>>>> Joseph Lorenzo Hall
>=C2=A0 =C2=A0 =C2=A0>>>> Chief Technologist, Center for Dem= ocracy & Technology
>=C2=A0 =C2=A0 =C2=A0[https://www.cdt.org]
>=C2=A0 =C2=A0 =C2=A0>>>> 1401 K ST NW STE 200, Washington D= C 20005-3497
>=C2=A0 =C2=A0 =C2=A0>>>> e: = joe@cdt.org <mailto:joe@cdt.org&g= t;, p: 202.407.8825=
>=C2=A0 =C2=A0 =C2=A0<tel:202.407.8825>, pgp: https://josephhall.org/gpg-key=
>=C2=A0 =C2=A0 =C2=A0>>>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4= B10=C2=A0 1607 5F86 6987 40A9 A871
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> __________________________________= _____________
>=C2=A0 =C2=A0 =C2=A0>>>> hrpc mailing list
>=C2=A0 =C2=A0 =C2=A0>>>> h= rpc@irtf.org <mailto:hrpc@irtf.org<= /a>>
>=C2=A0 =C2=A0 =C2=A0>>>> https://www.irtf.= org/mailman/listinfo/hrpc
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>
>
>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Joseph Lorenzo Hall
>=C2=A0 =C2=A0 =C2=A0Chief Technologist, Center for Democracy & Tech= nology
>=C2=A0 =C2=A0 =C2=A0[https://www.cdt.org]
>=C2=A0 =C2=A0 =C2=A01401 K ST NW STE 200, Washington DC 20005-3497
>=C2=A0 =C2=A0 =C2=A0e: joe@cdt.org &= lt;mailto:joe@cdt.org>, p: 202.407.8825
>=C2=A0 =C2=A0 =C2=A0<tel:202.407.8825>, pgp: https://josephhall.org/gpg-key=
>=C2=A0 =C2=A0 =C2=A0Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F= 86 6987 40A9 A871
>
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0hrpc mailing list
>=C2=A0 =C2=A0 =C2=A0hrpc@irtf.org = <mailto:hrpc@irtf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.irtf.org/mailman/listi= nfo/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


--001a113f8d1622e18f05323c1d7e-- From nobody Sat May 7 04:47:21 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 737C912B028 for ; Sat, 7 May 2016 04:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.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 ULHuwlSaJUXZ for ; Sat, 7 May 2016 04:47:17 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAB312B00A for ; Sat, 7 May 2016 04:47:17 -0700 (PDT) Received: from hub01.nexus.ox.ac.uk ([163.1.154.218] helo=HUB01.ad.oak.ox.ac.uk) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1az0hX-00059t-kK for hrpc@irtf.org; Sat, 07 May 2016 12:47:15 +0100 Received: from MBX05.ad.oak.ox.ac.uk ([169.254.5.103]) by HUB01.ad.oak.ox.ac.uk ([163.1.154.92]) with mapi id 14.03.0248.002; Sat, 7 May 2016 12:47:15 +0100 From: Bryce Goodman To: "hrpc@irtf.org" Thread-Topic: Help Thread-Index: AQHRqFYyL5GUfKZ+Rky3SxYUk8e9wg== Date: Sat, 7 May 2016 11:47:14 +0000 Message-ID: <7862C106-37E0-433B-800E-27942231C4DA@stx.ox.ac.uk> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [hrpc] Help 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, 07 May 2016 11:47:19 -0000 Please unsubscribe me.=20 Thank you! Bryce > On May 7, 2016, at 9:11 AM, "hrpc-request@irtf.org" wrote: >=20 > Send hrpc mailing list submissions to > hrpc@irtf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.irtf.org/mailman/listinfo/hrpc > or, via email, send a message with subject or body 'help' to > hrpc-request@irtf.org >=20 > You can reach the person managing the list at > hrpc-owner@irtf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of hrpc digest..." > Today's Topics: >=20 > 1. Re: hrpc Digest, Vol 14, Issue 8 (Dessalegn Yehuala) > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Sun May 8 05:29: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 73B9E12D0D9 for ; Sun, 8 May 2016 05:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 0qRp6TyMKZ2f for ; Sun, 8 May 2016 05:29:54 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 B449512D4FD for ; Sun, 8 May 2016 05:29:53 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id g17so144190099wme.1 for ; Sun, 08 May 2016 05:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GCg/YcbzxASd1S5CI53iQJ/EsFNe6aFvelKSz3aoYWc=; b=BEecNxTAi/MvVqeu45Oi+S7LDDEWD+DD4Io17zGAQ4Cp03jEp2COGRXPqTfdMm/Oyf YuwOzJPS7zjA5XcDP1D3lJN2ZGIg1AzPfhTdIh85+FPoekv0288QPPN9duAfb5XmGKkq QyoXWP38xAuatf9llRHpK+ZmHnVyCEZSMLlm7JE0EPuGEiFbYi8lkg0tGEdmbmU3EB26 5F7L0uuXpBm6frP2V0p6AFMJuGnIPveo24TLX1os4nliSqL09DCYu1IvEXzuRUaZzXKx Xj8/EQ22BDAnaXzg63WB0XkkigXxV1TRgI38lGGgbEATvNfbnmTRRAKXSrTS453OtHIj imcQ== 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:date :message-id:subject:from:to:cc; bh=GCg/YcbzxASd1S5CI53iQJ/EsFNe6aFvelKSz3aoYWc=; b=eMjiDSETgnxrMEVUK3PFGIdHTExrAbJCTvoLxRcSRI35Yp6/v2mv7096E3r7M1J45M uAuyjR9iZlsWvpm1aCp7h0WtV1Kj0Sa7KMgENMJpgqT3wWoTJuOoEjZ0hmeP8oeP5lYN KC89UM3LwZuhWGxTO8R/LgJv3UNj5zpXdG6BSnxdEWyWU7swdh06OB4qFw5XwZvvdNGf KH9TrzMPsSPKSmlCUpiqeRt3tkuSmaf7i18sTrnbX+naPUgRH6P+qIXVYz1qW4SNTymn dEzcybzvLuTCaNUYrb0e/lA/fNba1eJyGrqzsqTB8AnW2ooFaw8DipmjlxRRhEvSeZJ1 Uumg== X-Gm-Message-State: AOPr4FUU+Yuq8D3PZEvKQeDTQaLklMsJyU8mr4M9ub9SVqwpJvEnsIYWF1T44Ud+JqXQVmQ3WEicEVbwDLbbAg== MIME-Version: 1.0 X-Received: by 10.28.105.200 with SMTP id z69mr6357228wmh.78.1462710592294; Sun, 08 May 2016 05:29:52 -0700 (PDT) Received: by 10.194.41.233 with HTTP; Sun, 8 May 2016 05:29:52 -0700 (PDT) In-Reply-To: <7862C106-37E0-433B-800E-27942231C4DA@stx.ox.ac.uk> References: <7862C106-37E0-433B-800E-27942231C4DA@stx.ox.ac.uk> Date: Sun, 8 May 2016 13:29:52 +0100 Message-ID: From: Corinne Cath To: Bryce Goodman Content-Type: multipart/alternative; boundary=001a11467c0e43554b053253d9d7 Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Help 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, 08 May 2016 12:29:57 -0000 --001a11467c0e43554b053253d9d7 Content-Type: text/plain; charset=UTF-8 Dear Bryce, Please go to this website: https://www.irtf.org/mailman/listinfo/hrpc Under the orange heading "HRPC subscribers" you will find the sentence: "To unsubscribe from hrpc, get a password reminder, or change your subscription options enter your subscription email address" Please enter your email address there to unsubscribe. And voila! Have a lovely Sunday, Corinne On Sat, May 7, 2016 at 12:47 PM, Bryce Goodman wrote: > Please unsubscribe me. > > Thank you! > Bryce > > > On May 7, 2016, at 9:11 AM, "hrpc-request@irtf.org" < > hrpc-request@irtf.org> wrote: > > > > Send hrpc mailing list submissions to > > hrpc@irtf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.irtf.org/mailman/listinfo/hrpc > > or, via email, send a message with subject or body 'help' to > > hrpc-request@irtf.org > > > > You can reach the person managing the list at > > hrpc-owner@irtf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of hrpc digest..." > > Today's Topics: > > > > 1. Re: hrpc Digest, Vol 14, Issue 8 (Dessalegn Yehuala) > > > > _______________________________________________ > > 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 > -- 'The management of normality is hard work' --001a11467c0e43554b053253d9d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Bryce,

Please go to this website: https://www.irtf.org/mailman/listinf= o/hrpc

Under the orange heading "HRPC subscribers" y= ou will find the sentence:

"To unsubscribe from hrpc, get a password reminder, or change your subscription options enter your subscription email address"

Please enter your email address there t= o unsubscribe. And voila!

Have a lovely Sunday,

Corinne =

O= n Sat, May 7, 2016 at 12:47 PM, Bryce Goodman <bryce.goodman@stx.= ox.ac.uk> wrote:
Please u= nsubscribe me.

Thank you!
Bryce

> On May 7, 2016, at 9:11 AM, "hrpc-request@irtf.org" <hrpc-request@irtf.org> wrote:
>
> Send hrpc mailing list submissions to
>=C2=A0 =C2=A0 hrpc@irtf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>=C2=A0 =C2=A0 https://www.irtf.org/mailman/listinfo/hr= pc
> or, via email, send a message with subject or body 'help' to >=C2=A0 =C2=A0 hrpc-request@irt= f.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 hrpc-owner@irtf.or= g
>
> When replying, please edit your Subject line so it is more specific > than "Re: Contents of hrpc digest..."
> Today's Topics:
>
>=C2=A0 =C2=A01. Re: hrpc Digest, Vol 14, Issue 8 (Dessalegn Yehuala) > <mime-attachment>
> _______________________________________________
> 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



--


'The management of normality is hard work'

<= /div>
--001a11467c0e43554b053253d9d7-- From nobody Tue May 10 23:36:24 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 1C4C312D198 for ; Tue, 10 May 2016 23:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t8mx1NJdihKw for ; Tue, 10 May 2016 23:36:20 -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 DA6BB12D0CC for ; Tue, 10 May 2016 23:36:19 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id A57133400D0A; Wed, 11 May 2016 06:36:17 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 95F3F3400D07; Wed, 11 May 2016 06:36:17 +0000 (UTC) Received: from [192.168.179.21] (62-251-43-97.ip.xs4all.nl [62.251.43.97]) by mail.article19.io (Postfix) with ESMTPSA id 8189E135913; Wed, 11 May 2016 06:36:17 +0000 (UTC) Date: Sat, 07 May 2016 14:11:24 +0200 From: Niels ten Oever To: Bryce Goodman MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: <20160511063617.8189E135913@mail.article19.io> Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Help 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: Wed, 11 May 2016 06:36:22 -0000 SGkgQnJ5Y2UsCgpZb3UgY2FuIHVuc3Vic2NyaWJlIGF0IHRoZSBsaW5rIGF0IHRoZSBib3R0b20g b2YgZXZlcnkgZW1haWwgdGhhdCBpcyBzaGFyZWQgb3ZlciB0aGlzIGxpc3QuCgpMZXQgbWUga25v dyBpZiBpdCBkb2Vzbid0IHdvcmsgb3V0IGZvciB5b3UuCgpCZXN0LAoKTmllbHNPbiA3IE1heSAy MDE2IDEzOjQ3LCBCcnljZSBHb29kbWFuIDxicnljZS5nb29kbWFuQHN0eC5veC5hYy51az4gd3Jv dGU6Cj4KPiBQbGVhc2UgdW5zdWJzY3JpYmUgbWUuIAo+Cj4gVGhhbmsgeW91ISAKPiBCcnljZSAK Pgo+ID4gT24gTWF5IDcsIDIwMTYsIGF0IDk6MTEgQU0sICJocnBjLXJlcXVlc3RAaXJ0Zi5vcmci IDxocnBjLXJlcXVlc3RAaXJ0Zi5vcmc+IHdyb3RlOiAKPiA+IAo+ID4gU2VuZCBocnBjIG1haWxp bmcgbGlzdCBzdWJtaXNzaW9ucyB0byAKPiA+wqDCoMKgIGhycGNAaXJ0Zi5vcmcgCj4gPiAKPiA+ IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNp dCAKPiA+wqDCoMKgIGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vaHJwYyAK PiA+IG9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdo ZWxwJyB0byAKPiA+wqDCoMKgIGhycGMtcmVxdWVzdEBpcnRmLm9yZyAKPiA+IAo+ID4gWW91IGNh biByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0IAo+ID7CoMKgwqAgaHJwYy1v d25lckBpcnRmLm9yZyAKPiA+IAo+ID4gV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBT dWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYyAKPiA+IHRoYW4gIlJlOiBDb250ZW50 cyBvZiBocnBjIGRpZ2VzdC4uLiIgCj4gPiBUb2RheSdzIFRvcGljczogCj4gPiAKPiA+wqDCoCAx LiBSZTogaHJwYyBEaWdlc3QsIFZvbCAxNCwgSXNzdWUgOCAoRGVzc2FsZWduIFllaHVhbGEpIAo+ ID4gPG1pbWUtYXR0YWNobWVudD4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXyAKPiA+IGhycGMgbWFpbGluZyBsaXN0IAo+ID4gaHJwY0BpcnRmLm9y ZyAKPiA+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vaHJwYyAKPgo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIAo+IGhycGMgbWFp bGluZyBsaXN0IAo+IGhycGNAaXJ0Zi5vcmcgCj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ocnBjIAo= From nobody Fri May 13 05:07:33 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 9999812D185 for ; Fri, 13 May 2016 05:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 bJwSQfVG-fex for ; Fri, 13 May 2016 05:07:30 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 238DD12B05F for ; Fri, 13 May 2016 05:07:30 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id g17so26647920wme.1 for ; Fri, 13 May 2016 05:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=WRvSIFVjMpkVnh8HBXTcreDuT/EzJEi8qcvqorwR6eU=; b=OLUKBdKBxYlYl67OSpsuGk3A+tyIvHD+L3u7F0BWu5X2HBb3UmqcPu1G9JVszJjpUL +Ni+ohaXrTcxDjMrN7OosP2CULQtV7/U9GQQ15SJIMjXovU7XnSqjRvd+o9sw1MGN/7K RF3wOct29fmECYpqPVjLt4lFTZMzwsAjnaYggj9JHalmmTJNdTkfQm0tLoRdg6YzOO1n PeHQRfZRG85YHo+8lkJBGs1AKLNIlUnleSABTpLekOGkTQQ95E+8BOIxeqtjYzTt7n12 ZNIR0ykJoWGyIEFpmZ8MLp0W+6K+/tSR6/1TZinSX6UQXWhFD+f6l1MLshoGQVsbD5FJ 9XCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=WRvSIFVjMpkVnh8HBXTcreDuT/EzJEi8qcvqorwR6eU=; b=Zk+6tNx5MrVXU21o5D3GTuVMbN0fNffPRxI4/oeJz15TakA9PfIrOWbxEeFfrk+f+S v/tG0PLFhRrTJQ3zmGGcqDNusoFn3gNY2qIhPssi/K07OXST1bFF792UQky61ywUVErK T1tkryAQWN7NXqdu9aleWCA9hnL2BF9iaDC1XHhIc55yY5JM95uabrXiVYrfIOdGZzQ2 s8K4q12bXcNoNXyF+Zm6JoEXuk/UEVg4x/jFauGDyCi1PoXvaWM6NYQ67J5gjBAtxLde YBMJXOVkDOr9+Blw/oosHLfVU9Ni7pAqgI72Q8ezk55qAaBHUWIAr5iURBQKJ3O+WILq ol7Q== X-Gm-Message-State: AOPr4FXkw/1oZRfrG1W6duYsTLdaOT5Y+WQFC1hP4tstCwXrRcmxXjzEwKUqzx1ZZofDtg== X-Received: by 10.28.105.200 with SMTP id z69mr3360036wmh.78.1463141248651; Fri, 13 May 2016 05:07:28 -0700 (PDT) Received: from [192.168.1.35] (host31-52-143-57.range31-52.btcentralplus.com. [31.52.143.57]) by smtp.gmail.com with ESMTPSA id f11sm2969046wmf.22.2016.05.13.05.07.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 May 2016 05:07:27 -0700 (PDT) From: Scott Craig Content-Type: multipart/alternative; boundary="Apple-Mail=_187CE8B8-E945-4EC2-8456-7B73F8E16878" Message-Id: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> Date: Fri, 13 May 2016 13:07:26 +0100 To: hrpc@irtf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [hrpc] HRPC draft research feedback 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, 13 May 2016 12:07:32 -0000 --Apple-Mail=_187CE8B8-E945-4EC2-8456-7B73F8E16878 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Corrine, Niels, I have been reading though your recent draft = =C2=A0 = on = protocol considerations. There were a couple of things I couldn=E2=80=99t = figure out from the text that I was hoping you might be able to clarify.=20= Firstly, what specific relationship is the visual equation (of = architectural features to rights) intended to imply? =20 eg. ( Connectivity ) ( Privacy ) ( Security ) =3D Right to freedom of expression ( Content agnosticism ) ( Internationalization ) ( Censorship resistance ) ( Open Standards ) ( Heterogeneity support ) Is it intended to imply that no other architectural feature bears upon = that right? Or, is it intended to imply that ALL of the listed = architectural features MUST be present in order for the right to be = protected? And If not all, then how many features need not be present = before a protocol can be considered to abrogate a right? =09 Secondly, what method/principals have you used to determine which rights = are affected by which architectural features (technical concepts)? I was = expecting an explanation of this in section 5.2.2 of the methodology but = I can=E2=80=99t seem to find one there or elsewhere in the doc. Have I = missed this somewhere? Many thanks, and great work! Scott Scott Craig | Ford-Mozilla Fellow Center for Democracy & Technology | cdt.org E: scraig@cdt.org | D: 1.202.407.8887 = | @scottdavidcraig --Apple-Mail=_187CE8B8-E945-4EC2-8456-7B73F8E16878 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hey Corrine, = Niels,

I= have been reading though your recent draft on protocol considerations. There were a couple of = things I couldn=E2=80=99t figure out from the text that I was hoping you = might be able to clarify. 

Firstly, what specific relationship is = the visual equation (of architectural features to rights) intended to = imply?  

eg. (  Connectivity = )
   (      =
Privacy                )
   (      Security               )   =3D Right to freedom of expression
   (      Content agnosticism    )
   (      Internationalization   )
   (      Censorship resistance  )
   (      Open Standards         )
    (     Heterogeneity support )

Is it intended to imply = that no other architectural feature bears upon that right? Or, i
s it intended to = imply that ALL of the 
listed
 
architectural features MUST be present in order for the = right to be protected? And 
If not all, then h
ow = many features need not be present before a protocol can be considered to = abrogate a right?
=
Secondly, = w
hat method/principals have you used to = determine which rights are affected by which architectural features (technical = concepts)? 
I was = expecting an explanation of this = in 
section 5.2.2 of the = methodology but I can=E2=80=99t seem to find one there or elsewhere in = the doc. Have I missed this somewhere?

Many thanks, and great = work!

Scott

Scott Craig | Ford-Mozilla Fellow
Center for = Democracy & Technology | cdt.org
E: scraig@cdt.org | D: 1.202.407.8887 | @scottdavidcraig


= --Apple-Mail=_187CE8B8-E945-4EC2-8456-7B73F8E16878-- From scraig@cdt.org Fri May 13 05:12:00 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 32A7412D1AB for ; Fri, 13 May 2016 05:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 fsPLjzNgG2IA for ; Fri, 13 May 2016 05:11:58 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 AF09412D18F for ; Fri, 13 May 2016 05:11:57 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id g17so3142760wme.0 for ; Fri, 13 May 2016 05:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=from:subject:message-id:date:to:mime-version; bh=3WTHe7JelX6PtzLGJumKb6C/G+RWht3ju/q65qJbcok=; b=QluNScRZZRozj6JomvNq0qxlHTV92zm+Q78YYPEc1x96OjooHFsIXv5mC9pcJ3hzw3 N76ciaRvFQfg6Jm7JK0rWi+moRC96fo6MheaaWinfP1xWB2bx1e5KA/k5q/rolQW/Qq1 5KeWI7XJPNtvIijVqWgbu9AmiuEszh6eO0IkI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=3WTHe7JelX6PtzLGJumKb6C/G+RWht3ju/q65qJbcok=; b=PwAzofDG1ypBLp/3KdsgwmuhRdjOStkSuTWhnsn4UCYHSOwovn1jaNB8tldv+euXZ4 1UBhFKu56eYPmz67/kho5q8f9DG2h4QM+rTBd7AKB0rEj53JWzBB7VShZ8sLxoklHRD+ CLv5qJ0ZY4EnO/6Zcv44xO9TkWrfVsyKVKGmRNzD3cOI5OhmA3U1arr8S3p8G9c/+YxV LGknZcC+GUaBlbobuhwPdHvfbc52EGsc50aW6QiLO1DPXPSSNKDXgEBtzJ8Jm6nL15UQ gHsh5Os2qm5zyazksvWjldlwoUYzoMrQqgUw01qRmBVZvnQ6jRhyMvluT2LkpiYki7x+ wOPw== X-Gm-Message-State: AOPr4FXuiqlDo8ScNK/LdSoYWOYU70oZ30FwqU/j/XfNDIzJ3jALjWEk9tgO1u7tgY1CnpFn X-Received: by 10.194.166.3 with SMTP id zc3mr15876986wjb.104.1463141516113; Fri, 13 May 2016 05:11:56 -0700 (PDT) Received: from [192.168.1.35] (host31-52-143-57.range31-52.btcentralplus.com. [31.52.143.57]) by smtp.gmail.com with ESMTPSA id ip10sm18306797wjb.33.2016.05.13.05.11.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 May 2016 05:11:55 -0700 (PDT) From: Scott Craig Content-Type: multipart/alternative; boundary="Apple-Mail=_29030BF5-4730-4794-AB89-BE6CCEAFC07E" Message-Id: <9AFE02D9-50FE-483B-A3D8-139DB7149240@cdt.org> Date: Fri, 13 May 2016 13:11:54 +0100 To: hrpc@irtf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Fri, 13 May 2016 05:20:54 -0700 Subject: [hrpc] HRPC draft research feedback 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, 13 May 2016 12:14:13 -0000 --Apple-Mail=_29030BF5-4730-4794-AB89-BE6CCEAFC07E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Corrine, Niels, I have been reading though your recent draft = =C2=A0 = on = protocol considerations. There were a couple of things I couldn=E2=80=99t = figure out from the text that I was hoping you might be able to clarify.=20= Firstly, what specific relationship is the visual equation (of = architectural features to rights) intended to imply? =20 eg. ( Connectivity ) ( Privacy ) ( Security ) =3D Right to freedom of expression ( Content agnosticism ) ( Internationalization ) ( Censorship resistance ) ( Open Standards ) ( Heterogeneity support ) Is it intended to imply that no other architectural feature bears upon = that right? Or, is it intended to imply that ALL of the listed = architectural features MUST be present in order for the right to be = protected? And If not all, then how many need not be present before a = protocol can be considered to abrogate a right? =09 Secondly, what method/principals have you used to determine which rights = are affected by which architectural features (technical concepts)? I = expected to see an explanation of this in section 5.2.2 of the = methodology but t I couldn't seem to find one there or elsewhere in the = doc. Have I missed this somewhere? Many thanks, and great work! Scott Scott Craig | Ford-Mozilla Fellow Center for Democracy & Technology | cdt.org E: scraig@cdt.org | D: 1.202.407.8887 = | @scottdavidcraig --Apple-Mail=_29030BF5-4730-4794-AB89-BE6CCEAFC07E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hey Corrine, = Niels,

I= have been reading though your recent draft on protocol considerations. There were a couple of = things I couldn=E2=80=99t figure out from the text that I was hoping you = might be able to clarify. 

Firstly, what specific relationship is = the visual equation (of architectural features to rights) intended to = imply?  

eg. (  Connectivity = )
   (      =
Privacy                )
   (      Security               )   =3D Right to freedom of expression
   (      Content agnosticism    )
   (      Internationalization   )
   (      Censorship resistance  )
   (      Open Standards         )
    (     Heterogeneity support )

Is it intended to imply = that no other architectural feature bears upon that right? Or, i
s it intended to = imply that ALL of the 
listed
 
architectural features MUST be present in order for the = right to be protected? And 
If not all, then h
ow = many need not be present before a protocol can be considered to abrogate = a right?
=
Secondly, = w
hat method/principals have you used to = determine which rights are affected by which architectural features (technical = concepts)? 
I = expected to see an explanation of this = in 
section 5.2.2 of the = methodology but t I couldn't seem to find one there or elsewhere in the = doc. Have I missed this somewhere?

Many thanks, and great work!

Scott

Scott Craig | Ford-Mozilla Fellow
Center for = Democracy & Technology | cdt.org
E: scraig@cdt.org | D: 1.202.407.8887 | @scottdavidcraig


= --Apple-Mail=_29030BF5-4730-4794-AB89-BE6CCEAFC07E-- From nobody Fri May 13 09:47:52 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 0ADE612D5F4 for ; Fri, 13 May 2016 09:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tayhaSQLE4ZX for ; Fri, 13 May 2016 09:47:49 -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 7913D12D5AB for ; Fri, 13 May 2016 09:47:48 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 6839221527C5 for ; Fri, 13 May 2016 16:47:47 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5930D21527A8 for ; Fri, 13 May 2016 16:47:47 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 4B284210028 for ; Fri, 13 May 2016 16:47:47 +0000 (UTC) References: <20160513163159.10607.55584.idtracker@ietfa.amsl.com> To: "hrpc@irtf.org" From: Niels ten Oever X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20160513163159.10607.55584.idtracker@ietfa.amsl.com> Message-ID: <57360532.2020308@article19.org> Date: Fri, 13 May 2016 18:47:46 +0200 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: <20160513163159.10607.55584.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T69WDV90SC6sHF7PKgXQeCWeqb1tAsbOI" Archived-At: Subject: [hrpc] Fwd: New Version Notification for draft-tenoever-hrpc-research-02.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, 13 May 2016 16:47:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T69WDV90SC6sHF7PKgXQeCWeqb1tAsbOI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, There is a new version of the research document. This document addresses: - The comments made at the mic at the hrpc in Buenos Aires at IETF95 - The comments made by Avri [0] - The suggestions made by Nick Doty to revise the questionnaire in line with the W3C privacy and security questionnaire [1] - Improvements after a full re-read by Corinne and me. I think with this all outstanding issues in the draft have been addresses and we're feeling pretty confident about the maturity of the document. But it is of course always good to hear your ideas, suggestions and comments. Best, Niels [0] https://www.ietf.org/mail-archive/web/hrpc/current/msg00372.html [1] https://www.w3.org/wiki/Privacy_and_security_questionnaire -------- Forwarded Message -------- Subject: New Version Notification for draft-tenoever-hrpc-research-02.txt= Date: Fri, 13 May 2016 09:31:59 -0700 From: internet-drafts@ietf.org To: Corinne Cath , Niels ten Oever A new version of I-D, draft-tenoever-hrpc-research-02.txt has been successfully submitted by Niels ten Oever and posted to the IETF repository. Name: draft-tenoever-hrpc-research Revision: 02 Title: Research into Human Rights Protocol Considerations Document date: 2016-05-13 Group: Individual Submission Pages: 67 URL: https://www.ietf.org/internet-drafts/draft-tenoever-hrpc-research-02.txt Status: https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ Htmlized: https://tools.ietf.org/html/draft-tenoever-hrpc-research-= 02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tenoever-hrpc-research-02 Abstract: The increaseing convolution of Internet and society increases the impact of the Internet on the lives of individuals. Because of this, the design and development of the architecture of the Internet also has an increasing impact on society. This has led to an increasing recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in the development and management of the Internet [HRC2012] [UNGA2013] [NETmundial]. It has also been argued that the Internet should be strengthened as a human rights enabling environment [Brown]. 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]. Discussion of this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/listinfo/hrpc Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --T69WDV90SC6sHF7PKgXQeCWeqb1tAsbOI 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 iQEcBAEBCAAGBQJXNgUyAAoJEAi1oPJjbWjpsQUH/17/MkTiX6Ov6vzC+Yw1dNDU fHRJOTMWc3Uj4XdBSKsSvqXePQBAtwPoCPxSvj0EDz/hFA64jydWKp2UeNhKdvQn W2azY5xaf4n8dwIhszqoDDXr2o9Qen9OGF5MfQYyQ34flqsG2EEs2rR5BCiVwVRg +lxoixJgxQ4MDNZ4xNVVGcSG59oFcppLdXr5VBgDqXD06wk49d6Xu9y0ALvrPpZz xHEeLhqLMuNIvtVF6/0DtKSTmYKPSgwX8gA0eA6Wj2EknBoGnoYBshZ6DcIpz5RN 5riE39bFB1RJCFMugnSSJfDROKuyz6fWgaznE5hOY/8eX70S/xdB68DOBrAje1A= =ldRQ -----END PGP SIGNATURE----- --T69WDV90SC6sHF7PKgXQeCWeqb1tAsbOI-- From nobody Fri May 13 10:02:00 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 EB8B312D5AB for ; Fri, 13 May 2016 10:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 NiB9WNHHj3xm for ; Fri, 13 May 2016 10:01:57 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 03B1712D60C for ; Fri, 13 May 2016 10:01:57 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id x201so180193122oif.3 for ; Fri, 13 May 2016 10:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FvkGhrXlqCRuRdxqEPWdhbyh2hp+RgcY4AntHZ9Igjg=; b=HOFjS0We/i5uUpK1MpLS7qyiRAJbTc7IsX0Zc+szIcGoznPl2BQQL7Fyq5KRYiPBSf Mz/gpVnroLVSW2j2/avyI1zgQqIZhC7H6Js8FvN9PPSFE487KUqwQe4scEGDSjcsCdAk deau8Mw+JoXOA3nUP4TaVkv3EuBUnscVlrpmw= 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:date :message-id:subject:from:to:cc; bh=FvkGhrXlqCRuRdxqEPWdhbyh2hp+RgcY4AntHZ9Igjg=; b=a2cB7TbuiBfecIx4+ep191BS6kQ6kYfAWyuLLG9V74OXjhJoOOBpK4UDKYMNf0g7Eq 4wSjtaOZg8Jr5YszSq+aUyLHf0H/JUXJgwlv0pM/cvP8tdHzA8xJrCkIvozc1htlIPqh 7jsxqahUNStfT+d63ljPmVwp7P6EVR9wpVpHYlaMYqjuT+4MN2urtfKFmefWcMmWwhtu 8P3Q6GJGlHQLymcndRMKd1dw1HMedcZzXh1TQbJwRM9ZfpgQ1/tADl0tE0eW7IFVg8MA bRYZNP/uEZj6uIaDJEgnsUdNBfpbPDFsuharDAh/utptGE+5c9t2dSj2c0GRQkxhcg+N +/RA== X-Gm-Message-State: AOPr4FWLjoyra7mmi22QTJPfjUrjl4Tc6HdVyYhjM3wSx0vWlpTMio1AfJBvwBjPiQr5hxRuJCSkW5s/nTFVnGLi MIME-Version: 1.0 X-Received: by 10.202.86.215 with SMTP id k206mr9740037oib.115.1463158916334; Fri, 13 May 2016 10:01:56 -0700 (PDT) Received: by 10.202.213.198 with HTTP; Fri, 13 May 2016 10:01:56 -0700 (PDT) In-Reply-To: <57360532.2020308@article19.org> References: <20160513163159.10607.55584.idtracker@ietfa.amsl.com> <57360532.2020308@article19.org> Date: Fri, 13 May 2016 18:01:56 +0100 Message-ID: From: Scott Craig To: Niels ten Oever Content-Type: multipart/alternative; boundary=001a113d7ba6755e690532bc3ba3 Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Fwd: New Version Notification for draft-tenoever-hrpc-research-02.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, 13 May 2016 17:02:00 -0000 --001a113d7ba6755e690532bc3ba3 Content-Type: text/plain; charset=UTF-8 Hi Niels, I sent an email earlier today to the list with some feedback. However, because I sent it by my work email (which isn't subscribed) as opposed to my own email (which is subscribed) it went to the moderator (you) for approval. Has that come through to you, or should I resend the feedback? Thanks, Scott -- *Scott Craig* | Ford-Mozilla Fellow Center for Democracy & Technology |* cdt.org * *E:* scraig@cdt.org | *D:* 1.202.407.8887 | @scottdavidcraig On Fri, May 13, 2016 at 5:47 PM, Niels ten Oever wrote: > Dear all, > > There is a new version of the research document. > > This document addresses: > - The comments made at the mic at the hrpc in Buenos Aires at IETF95 > - The comments made by Avri [0] > - The suggestions made by Nick Doty to revise the questionnaire in line > with the W3C privacy and security questionnaire [1] > - Improvements after a full re-read by Corinne and me. > > I think with this all outstanding issues in the draft have been > addresses and we're feeling pretty confident about the maturity of the > document. But it is of course always good to hear your ideas, > suggestions and comments. > > Best, > > Niels > > > [0] https://www.ietf.org/mail-archive/web/hrpc/current/msg00372.html > [1] https://www.w3.org/wiki/Privacy_and_security_questionnaire > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-tenoever-hrpc-research-02.txt > Date: Fri, 13 May 2016 09:31:59 -0700 > From: internet-drafts@ietf.org > To: Corinne Cath , Niels ten Oever > > > > A new version of I-D, draft-tenoever-hrpc-research-02.txt > has been successfully submitted by Niels ten Oever and posted to the > IETF repository. > > Name: draft-tenoever-hrpc-research > Revision: 02 > Title: Research into Human Rights Protocol Considerations > Document date: 2016-05-13 > Group: Individual Submission > Pages: 67 > URL: > https://www.ietf.org/internet-drafts/draft-tenoever-hrpc-research-02.txt > Status: > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > Htmlized: > https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-tenoever-hrpc-research-02 > > Abstract: > The increaseing convolution of Internet and society increases the > impact of the Internet on the lives of individuals. Because of this, > the design and development of the architecture of the Internet also > has an increasing impact on society. This has led to an increasing > recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in > the development and management of the Internet [HRC2012] [UNGA2013] > [NETmundial]. It has also been argued that the Internet should be > strengthened as a human rights enabling environment [Brown]. > > 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]. > > Discussion of this draft at: hrpc@irtf.org // > https://www.irtf.org/mailman/listinfo/hrpc > > > > > > 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. > > The IETF Secretariat > > > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > --001a113d7ba6755e690532bc3ba3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Niels,=C2=A0

I sent an email=C2=A0earlier today= =C2=A0to the list with some feedback. However, because I sent it by my work= email (which isn't subscribed) as=C2=A0opposed to my own email (which = is subscribed) it went to the moderator (you) for approval.=C2=A0

Ha= s that come through to you, or should I resend the feedback?

=
Thanks,

Scott
--=C2=A0

Scott Craig=C2=A0|=C2=A0Ford-Mozilla Fellow
Center for Democra= cy & Technology=C2=A0|=C2=A0cdt.org
E:=C2=A0scraig@cdt.org=C2=A0|=C2=A0D:=C2=A01.202.407.8887=C2=A0|=C2=A0@scottdavidcraig

<= /div>


On= Fri, May 13, 2016 at 5:47 PM, Niels ten Oever <niels@article19.org&= gt; wrote:
Dear all,

There is a new version of the research document.

This document addresses:
- The comments made at the mic at the hrpc in Buenos Aires at IETF95
- The comments made by Avri [0]
- The suggestions made by Nick Doty to revise the questionnaire in line
with the W3C privacy and security questionnaire [1]
- Improvements after a full re-read by Corinne and me.

I think with this all outstanding issues in the draft have been
addresses and we're feeling pretty confident about the maturity of the<= br> document. But it is of course always good to hear your ideas,
suggestions and comments.

Best,

Niels


[0] https://www.ietf.org/mail-archiv= e/web/hrpc/current/msg00372.html
[1] https://www.w3.org/wiki/Privacy_and_se= curity_questionnaire



-------- Forwarded Message --------
Subject: New Version Notification for draft-tenoever-hrpc-research-02.txt Date: Fri, 13 May 2016 09:31:59 -0700
From: internet-drafts@ietf.org<= /a>
To: Corinne Cath <corinnecath@g= mail.com>, Niels ten Oever
<niels@article19.org>


A new version of I-D, draft-tenoever-hrpc-research-02.txt
has been successfully submitted by Niels ten Oever and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tenoever-hrpc-research<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Research into Human Rights Protoco= l Considerations
Document date:=C2=A0 2016-05-13
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 67
URL:
https://www.ietf.org/interne= t-drafts/draft-tenoever-hrpc-research-02.txt
Status:
https://datatracker.ietf.org/doc/draft= -tenoever-hrpc-research/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-tenoever-hrpc-research-02
Diff:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-tenoever-hrpc-research-02

Abstract:
=C2=A0 =C2=A0The increaseing convolution of Internet and society increases = the
=C2=A0 =C2=A0impact of the Internet on the lives of individuals.=C2=A0 Beca= use of this,
=C2=A0 =C2=A0the design and development of the architecture of the Internet= also
=C2=A0 =C2=A0has an increasing impact on society.=C2=A0 This has led to an = increasing
=C2=A0 =C2=A0recognition that human rights [UDHR] [ICCPR] [ICESCR] have a r= ole in
=C2=A0 =C2=A0the development and management of the Internet [HRC2012] [UNGA= 2013]
=C2=A0 =C2=A0[NETmundial].=C2=A0 It has also been argued that the Internet = should be
=C2=A0 =C2=A0strengthened as a human rights enabling environment [Brown].
=C2=A0 =C2=A0This document provides a proposal for a vocabulary to discuss = the
=C2=A0 =C2=A0relation between human rights and Internet protocols, an overv= iew of
=C2=A0 =C2=A0the discussion in technical and academic literature and commun= ities,
=C2=A0 =C2=A0a proposal for the mapping of the relation between human right= s and
=C2=A0 =C2=A0technical concepts, and a proposal for guidelines for human ri= ghts
=C2=A0 =C2=A0considerations, similar to the work done on the guidelines for=
=C2=A0 =C2=A0privacy considerations [RFC6973].

=C2=A0 =C2=A0Discussion of this draft at: = hrpc@irtf.org //
=C2=A0 =C2=A0https://www.irtf.org/mailman/listinfo/hrpc





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

The IETF Secretariat





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


=

=


=

=
--001a113d7ba6755e690532bc3ba3-- From nobody Fri May 13 10:08:49 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 A79CC12D62B for ; Fri, 13 May 2016 10:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o-yCEpncsjp5 for ; Fri, 13 May 2016 10:08:46 -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 F210E12D626 for ; Fri, 13 May 2016 10:08:45 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id BE65B1358E0 for ; Fri, 13 May 2016 17:08:44 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id AD2E21358E7 for ; Fri, 13 May 2016 17:08:44 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 9FDB31358E0 for ; Fri, 13 May 2016 17:08:44 +0000 (UTC) To: hrpc@irtf.org References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <57360A1B.2020000@article19.org> Date: Fri, 13 May 2016 19:08:43 +0200 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: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="saPTxqrnx3IMIxLp3mLMo5inbJr3DJJI4" Archived-At: Subject: Re: [hrpc] HRPC draft research feedback 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, 13 May 2016 17:08:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --saPTxqrnx3IMIxLp3mLMo5inbJr3DJJI4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Scott, Thanks for your question. The relationship that is implied (and I think it is in the text, if not I should definitely add it), that these concepts shape the enabling environment on the Internet for exercising a specific right. That does not mean that we could not imagine another Internet without these properties where these rights could also be exercised, but in the current Internet we think these are the crucial ingredient for enabling the ability to exercise specific rights. How we came to this is described in step 5.2.1.4. Translating Human Rights Concept into Technical Definitions Hope this helps, and looking forward to discuss! Best, Niels PS If you think this is not clear from the text, please say so (or even better, create a pull request here: https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md ) Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 05/13/2016 02:07 PM, Scott Craig wrote: > Hey Corrine, Niels, >=20 > I have been reading though your recent draft > =20 > on > protocol considerations. There were a couple of things I couldn=92t fig= ure > out from the text that I was hoping you might be able to clarify.=20 >=20 > Firstly, what specific relationship is the visual equation (of > architectural features to rights) intended to imply? =20 >=20 > eg. ( Connectivity ) >=20 > ( Privacy ) > ( Security ) =3D Right to freedom of expression= > ( Content agnosticism ) > ( Internationalization ) > ( Censorship resistance ) > ( Open Standards ) > ( Heterogeneity support ) >=20 >=20 > Is it intended to imply that no other architectural feature bears upon > that right? Or, i** > *s it intended to imply *that ALL of the=20 > **** > listed > ** ** > architectural features MUST be present in order for the right to > be protected? And=20 > **** > * > *If not all, then h* > *ow many features need not be present before a protocol can be > considered to abrogate a right? > ** > Secondly, w > hat method/principals have you used to determine which rights are > affected by which architectural features (technical concepts)?=20 > I was expecting an explanation of this in=20 > section 5.2.2 of the methodology but I can=92t seem to find one there o= r > elsewhere in the doc. Have I missed this somewhere? > * >=20 > Many thanks, and great work! >=20 > Scott > * >=20 > *Scott Craig* | Ford-Mozilla Fellow > Center for Democracy & Technology |* cdt.org * > *E:* scraig@cdt.org | *D:* 1.202.407.8887 > | **@scottdavidcraig >=20 >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --saPTxqrnx3IMIxLp3mLMo5inbJr3DJJI4 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 iQEcBAEBCAAGBQJXNgocAAoJEAi1oPJjbWjpSjcH/1wfn0kH+nm4NI+N6pTyHBMx s4jDFhGt0xTBO4CGsOxs3xQ3JHEk8abc7yVzBz3WT78VAApB8O1R0WytlkJQxbwI 0Ur9fwt1y9QvKngtmkq/PxmG1uNV5Xw5dkB7M2ab6RT5TWUXooI/0vXnh0Dk4FyU dTQ8/lRKq9doEYGpdGTWeIVGTG/FKtcZXfrwioWgmET3dsNdqZtvc6XTj56Ipgun 0odWLp1qn6fA2mxAwTDS0j/WkUlThtadyXUmvLfK5hA6qconLfny4mUtSuwffjc6 Xniys+v6/1TpPKk7q2D7vCbndaeF232TbYNNLeBSkK+wqEseAbD47ZM3w3Bej3E= =TTmK -----END PGP SIGNATURE----- --saPTxqrnx3IMIxLp3mLMo5inbJr3DJJI4-- From nobody Fri May 13 10:09:56 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 1C2A512D1B5 for ; Fri, 13 May 2016 10:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LYaFlGXbiR3X for ; Fri, 13 May 2016 10:09:52 -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 5E6D612D09E for ; Fri, 13 May 2016 10:09:52 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 320381358E0; Fri, 13 May 2016 17:09:51 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 2121F1358E7; Fri, 13 May 2016 17:09:51 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 1203C1358E0; Fri, 13 May 2016 17:09:51 +0000 (UTC) To: Scott Craig References: <20160513163159.10607.55584.idtracker@ietfa.amsl.com> <57360532.2020308@article19.org> From: Niels ten Oever Message-ID: <57360A5E.9090002@article19.org> Date: Fri, 13 May 2016 19:09:50 +0200 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="lIXDGq3jSmMF8dPP1CKTF6MAage4l9fbt" Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Fwd: New Version Notification for draft-tenoever-hrpc-research-02.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, 13 May 2016 17:09:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lIXDGq3jSmMF8dPP1CKTF6MAage4l9fbt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think I just responded :) 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 05/13/2016 07:01 PM, Scott Craig wrote: > Hi Niels,=20 >=20 > I sent an email earlier today to the list with some feedback. However, > because I sent it by my work email (which isn't subscribed) as opposed > to my own email (which is subscribed) it went to the moderator (you) fo= r > approval.=20 >=20 > Has that come through to you, or should I resend the feedback? >=20 > Thanks, >=20 > Scott > --=20 >=20 > *Scott Craig* | Ford-Mozilla Fellow > Center for Democracy & Technology |* cdt.org * > *E:* scraig@cdt.org | *D:* 1.202.407.8887 > | **@scottdavidcraig >=20 >=20 >=20 > On Fri, May 13, 2016 at 5:47 PM, Niels ten Oever > wrote: >=20 > Dear all, >=20 > There is a new version of the research document. >=20 > This document addresses: > - The comments made at the mic at the hrpc in Buenos Aires at IETF9= 5 > - The comments made by Avri [0] > - The suggestions made by Nick Doty to revise the questionnaire in = line > with the W3C privacy and security questionnaire [1] > - Improvements after a full re-read by Corinne and me. >=20 > I think with this all outstanding issues in the draft have been > addresses and we're feeling pretty confident about the maturity of = the > document. But it is of course always good to hear your ideas, > suggestions and comments. >=20 > Best, >=20 > Niels >=20 >=20 > [0] https://www.ietf.org/mail-archive/web/hrpc/current/msg00372.htm= l > [1] https://www.w3.org/wiki/Privacy_and_security_questionnaire >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-tenoever-hrpc-research-02.txt > Date: Fri, 13 May 2016 09:31:59 -0700 > From: internet-drafts@ietf.org > To: Corinne Cath >, Niels ten Oever > > >=20 >=20 > A new version of I-D, draft-tenoever-hrpc-research-02.txt > has been successfully submitted by Niels ten Oever and posted to th= e > IETF repository. >=20 > Name: draft-tenoever-hrpc-research > Revision: 02 > Title: Research into Human Rights Protocol Considerations > Document date: 2016-05-13 > Group: Individual Submission > Pages: 67 > URL: > https://www.ietf.org/internet-drafts/draft-tenoever-hrpc-research-0= 2.txt > Status: > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ > Htmlized: =20 > https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-tenoever-hrpc-research-02= >=20 > Abstract: > The increaseing convolution of Internet and society increases th= e > impact of the Internet on the lives of individuals. Because of = this, > the design and development of the architecture of the Internet a= lso > has an increasing impact on society. This has led to an increas= ing > recognition that human rights [UDHR] [ICCPR] [ICESCR] have a rol= e in > the development and management of the Internet [HRC2012] [UNGA20= 13] > [NETmundial]. It has also been argued that the Internet should = be > strengthened as a human rights enabling environment [Brown]. >=20 > This document provides a proposal for a vocabulary to discuss th= e > relation between human rights and Internet protocols, an overvie= w of > the discussion in technical and academic literature and communit= ies, > a proposal for the mapping of the relation between human rights = and > technical concepts, and a proposal for guidelines for human righ= ts > considerations, similar to the work done on the guidelines for > privacy considerations [RFC6973]. >=20 > Discussion of this draft at: hrpc@irtf.org // > https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 >=20 >=20 >=20 > 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= > . >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 >=20 > */ > /* >=20 --lIXDGq3jSmMF8dPP1CKTF6MAage4l9fbt 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 iQEcBAEBCAAGBQJXNgpeAAoJEAi1oPJjbWjpfP0H/3/HiVEQXr3MIoS0a8PbVAK0 9ci5u38JRc0rUjkcpASJT8VmCgksIp4a9arHuDMUEKdru1hwUy9hZN7JIcZ32yzf 1mcqCaNF55K2uf2KIBBI28A0MOofvBHEHHh1PnZYb/5M2Z++IctDLkkC4CV5IGxK k7e24SPHoqvCEY9oKh7b12DPSatGN8f7i+KqRSeN527o9V3xy7bD6sU+f0okDWco iRfTSo7lFYvhjF6pDEmDdw/CB3HujpRhAzaudlNJXNazIFVT0ThEZkkusg2utEGX 5wFYs/7azrKcKFJvs2H+2oFBa0MiTOCxSj2bcu7TWYvNxMYBAT6Qx3hYvYsR750= =/sTD -----END PGP SIGNATURE----- --lIXDGq3jSmMF8dPP1CKTF6MAage4l9fbt-- From nobody Mon May 16 03:11: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 D798812B015 for ; Mon, 16 May 2016 03:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5ZCdv6TWD6gr for ; Mon, 16 May 2016 03:11:55 -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 B7925127058 for ; Mon, 16 May 2016 03:11:55 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 3B79321527C4 for ; Mon, 16 May 2016 10:11:53 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 2B82821527C6 for ; Mon, 16 May 2016 10:11:53 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 0C90021527C4 for ; Mon, 16 May 2016 10:11:52 +0000 (UTC) To: "hrpc@irtf.org" From: Niels ten Oever Message-ID: <57399CE7.90700@article19.org> Date: Mon, 16 May 2016 12:11:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V3QlfCs8dbDJ4dNxT5M6Uc7k6SrF2xVC6" Archived-At: Subject: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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, 16 May 2016 10:11:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V3QlfCs8dbDJ4dNxT5M6Uc7k6SrF2xVC6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear RG, This email serves as a call for RG adoption of draft-tenoever-hrpc-research-02 [0] as a RG document. The call for adoption will run for 2 weeks ending 5/30/2016. Several of your might have thought this document was already an RG document, but since it was never formally adopted we thought it might be a good idea to do that now (even though this is not strictly a requirement for this in the IRTF, but for the sake of clarity and transparency we'll follow the IETF procedure as decribed in RFC7221). Please note that this is a call for adoption, and not a last call for content of the document. Adopting a RG document simply means that the RG will focus its efforts on that particular draft going forward, and use that document for resolving open issues and documenting the RG=E2=80=99s = decisions. Please indicate whether you support adoption or not, and if not why. Issues you have with the current document itself can also be raised, but they should be raised in the context of what should be changed in the document going forward, rather than a pre-condition for adoption. Looking forward to hear your opinions. All the best, Niels [0] https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 --=20 Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 --V3QlfCs8dbDJ4dNxT5M6Uc7k6SrF2xVC6 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 iQEcBAEBCAAGBQJXOZzoAAoJEAi1oPJjbWjpyaIIAJpKGBKUNQaD8kmiGS0A3GT4 YH45L/HZl/ZH5jA2bLYbYySdoGYVnpqlUUFgpmX5XqHy9sxPoamqx+ZFmv8e7EPe I3LFPAhIg8Kbcqz0nGlbMlMblkWRJhFWd4VMXU4TVDC07wRK5bNfzfbywcCNCa4L +TOmQoWdpQxc1AhVb3bLyW5iWFAQd+qSK8Y4i1Kllhx1MgdAMqN9ybsmHmOKRyXO Gz+ji3U+XZpYkUPzrt5OtsRofgd09SVnt3Ph8ZcGNnl9KUvdYHjMN1sk23+1U4Lk 8QLU0xOQ2K1Z6STJcaj5H546gbErP2GO3EEI/P5jpZPHlMfywNUz7gPZveej6as= =oIHh -----END PGP SIGNATURE----- --V3QlfCs8dbDJ4dNxT5M6Uc7k6SrF2xVC6-- From nobody Mon May 16 03:37:17 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 1AF1A12D127 for ; Mon, 16 May 2016 03:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 XfJOSXl48BeE for ; Mon, 16 May 2016 03:37:14 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 C6FF712D0DD for ; Mon, 16 May 2016 03:37:13 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id n129so17019764wmn.1 for ; Mon, 16 May 2016 03:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=DJ3VEUuwmbWrklu2UoTif6ist82tgdqhWxY8uRhNkos=; b=HFpGrKLs6tDYyywfkHVlHg9sSJzzP5kQaUOuyhFdCQQJDxIfRokHOYRoLpTjfT0hC6 Qq0vq5QzFdsqj5WbLXegdzcq/ODYHNq21hLSUoQxREmOey+oaWLAOUcsPDk7D9UBJsTe URN6uJ2RCmYInv4fflyCDoHKh6uxqIoR60Hlg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=DJ3VEUuwmbWrklu2UoTif6ist82tgdqhWxY8uRhNkos=; b=KwLGqujIerYntNQ+jcQ32dbrZp+GzS8+MoJHpusUsv30ssHjYI1ibPzk/4uOlRkb7l Ex/q9NXLxXgAyoMQPLkq5y/GcmskzjA+2Tl/PMJhrM52n70iseBPYegb66qPzewzkV9Z JCIhPYTc7/2ncm9jS97hRx+bpJDp+kloXj4GCjweloutRe6YsvrCK/h6t2Sb3WL/Z0L3 kPYy0jetufQ/R4TWF0qPb+YQZhiX4KTj/UdpaA3L9tep9Qzju0DX/YmyRSOMwCnqkRCv 7AOBSnxXDch2kOu2rngE37TwlM60elS/T4baOzLtF9bxP+i9lU0DeyGbilDOauF/9Dz2 57Fw== X-Gm-Message-State: AOPr4FUjANTSCMG/4aJYq4HZfw9zuq72qgyGurxwxBwbLp1FxLRphM+eaWU0HLh2EW2GDxaA X-Received: by 10.28.11.82 with SMTP id 79mr16803799wml.33.1463395032224; Mon, 16 May 2016 03:37:12 -0700 (PDT) Received: from [192.168.1.35] (host31-52-143-57.range31-52.btcentralplus.com. [31.52.143.57]) by smtp.gmail.com with ESMTPSA id ib1sm32964282wjb.48.2016.05.16.03.37.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 16 May 2016 03:37:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EF1E5A2A-415A-4406-B2E2-4D3A64D7A770" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Scott Craig In-Reply-To: <57360A1B.2020000@article19.org> Date: Mon, 16 May 2016 11:37:07 +0100 Message-Id: <5FBC0A2C-1C45-4AE1-A559-C2706741FA9E@cdt.org> References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> <57360A1B.2020000@article19.org> To: Niels ten Oever X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hrpc@irtf.org Subject: [hrpc] What test determines whether an architectural feature is a crucial ingredient for enabling the ability to exercise specific right? 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, 16 May 2016 10:37:16 -0000 --Apple-Mail=_EF1E5A2A-415A-4406-B2E2-4D3A64D7A770 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Niels,=20 Thanks for the answer. I had another look through section 5.2.1.4. and I = couldn't find a description of the test you have applied to determine = whether an architectural feature is a 'crucial ingredient for enabling = the ability to exercise specific rights=92 (and therefore qualified for = inclusion in the equation below.)=20 >> eg. ( Connectivity ) >>=20 >> ( Privacy ) >> ( Security ) =3D Right to freedom of = expression >> ( Content agnosticism ) >> ( Internationalization ) >> ( Censorship resistance ) >> ( Open Standards ) >> ( Heterogeneity support ) Say, for example, that someone were to claim that a feature (or = combination of features) that you have listed as 'shaping the enabling = environment' for freedom of expression did not do so. What criteria = would be used to assess the merits of that claim? Is there a specific = test that was applied during the creation of the second list (see = quotation below) which could be examined? (this is what I=92ve been = trying to find). >> Mapping the protocols and standards that are related to human rights = and create a human rights enabeling environment was the first step. For = that we needed to focus on specific technical concepts that underlie = these protocols and standards. On the basis of this list a number of = technical concepts that appeared frequently was extracted, and used to = create a second list of technical terms that, when combined, create an = enabling environment for excercising human rights on the Internet.=20 If no test was used, then I would argue it would be highly beneficial to = develop one. A test would, I think, aid in ensuring the kind of clear, = explicit and Human Rights conscious design decisions you describe below = .=20 > It is however important to make consicious and explicit design = decisions that take into account the human rights protocol = considerations guidelines developed below. This will ensure that the = impact protocols can have on human rights is clear and explicit, both = for developers and for users. I'm therefore tentatively proposing two possibilities (based on UK = Judicial Review principals) for discussion: 1. Inevitability test (The stricter standard) An architectural feature does not impinge upon a right unless a = violation of the right in question would not be possible but for the = inclusion (or absence) of that feature acting alone or in combination = with at least one other feature.=20 2. Highly Likely test (The weaker standard) An architectural feature does not impinge upon a right unless the = probability of the right in question being violated would be = substantially different as a result of the presence (or absence) of that = feature acting alone or in combination with at least one other feature Scott Scott Craig | Ford-Mozilla Fellow Center for Democracy & Technology | cdt.org E: scraig@cdt.org | D: 1.202.407.8887 = | @scottdavidcraig > On 13 May 2016, at 18:08, Niels ten Oever wrote: >=20 > Hi Scott, >=20 > Thanks for your question. The relationship that is implied (and I = think > it is in the text, if not I should definitely add it), that these > concepts shape the enabling environment on the Internet for exercising = a > specific right. >=20 > That does not mean that we could not imagine another Internet without > these properties where these rights could also be exercised, but in = the > current Internet we think these are the crucial ingredient for = enabling > the ability to exercise specific rights. >=20 > How we came to this is described in step 5.2.1.4. Translating Human > Rights Concept into Technical Definitions >=20 > Hope this helps, and looking forward to discuss! >=20 > Best, >=20 > Niels >=20 > PS If you think this is not clear from the text, please say so (or = even > better, create a pull request here: > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md ) >=20 >=20 >=20 > Niels ten Oever > Head of Digital >=20 > Article 19 > www.article19.org >=20 > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 >=20 > On 05/13/2016 02:07 PM, Scott Craig wrote: >> Hey Corrine, Niels, >>=20 >> I have been reading though your recent draft >> =20 >> on >> protocol considerations. There were a couple of things I couldn=92t = figure >> out from the text that I was hoping you might be able to clarify.=20 >>=20 >> Firstly, what specific relationship is the visual equation (of >> architectural features to rights) intended to imply? =20 >>=20 >> eg. ( Connectivity ) >>=20 >> ( Privacy ) >> ( Security ) =3D Right to freedom of = expression >> ( Content agnosticism ) >> ( Internationalization ) >> ( Censorship resistance ) >> ( Open Standards ) >> ( Heterogeneity support ) >>=20 >>=20 >> Is it intended to imply that no other architectural feature bears = upon >> that right? Or, i** >> *s it intended to imply *that ALL of the=20 >> **** >> listed >> ** ** >> architectural features MUST be present in order for the right to >> be protected? And=20 >> **** >> * >> *If not all, then h* >> *ow many features need not be present before a protocol can be >> considered to abrogate a right? >> ** >> Secondly, w >> hat method/principals have you used to determine which rights are >> affected by which architectural features (technical concepts)?=20 >> I was expecting an explanation of this in=20 >> section 5.2.2 of the methodology but I can=92t seem to find one there = or >> elsewhere in the doc. Have I missed this somewhere? >> * >>=20 >> Many thanks, and great work! >>=20 >> Scott >> * >>=20 >> *Scott Craig* | Ford-Mozilla Fellow >> Center for Democracy & Technology |* cdt.org * >> *E:* scraig@cdt.org | *D:* 1.202.407.8887 >> | **@scottdavidcraig >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc >>=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --Apple-Mail=_EF1E5A2A-415A-4406-B2E2-4D3A64D7A770 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Niels, 

Thanks for the answer. I had another = look through section 5.2.1.4. and I couldn't find a description of the = test you have applied to determine whether an architectural feature is a = 'crucial ingredient for enabling the ability to exercise specific = rights=92 (and therefore qualified for inclusion in the equation = below.) 


eg. (  Connectivity = )

  ( =      Privacy =             &n= bsp;  )
  ( =      Security =             &n= bsp; )   =3D Right to freedom of expression
  (      Content = agnosticism    )
  ( =      Internationalization   )
  (      Censorship = resistance  )
  ( =      Open Standards =         )
   (     Heterogeneity = support )


Say, for example, that = someone were to claim that a feature (or combination of features) that = you have listed as 'shaping the enabling environment' for freedom of = expression did not do so. What criteria would be used to assess the = merits of that claim? Is there a specific test that was applied during = the creation of the second list (see quotation below) which could be = examined? (this is what I=92ve been trying to find).

Mapping the protocols = and standards that are related to human rights and create a human rights = enabeling environment was the first step. For that we needed to focus on = specific technical concepts that underlie these protocols and =  standards. On the basis of this list a number of technical = concepts that appeared frequently was extracted, and = used to create a second list of technical terms that, when combined, = create an enabling environment for excercising human rights on the = Internet. 

If no test was used, then I would argue = it would be highly beneficial to develop one. A = test would, I think, aid in ensuring the kind of clear, explicit and = Human Rights conscious design decisions you describe below = . 

 It is however = important to make consicious and explicit design decisions that take = into account the human rights protocol considerations guidelines = developed below. This will ensure that the impact protocols can have on = human rights is clear and explicit, both for developers and for = users.


I'm therefore tentatively = proposing two possibilities (based on UK Judicial Review principals) for = discussion:

1. Inevitability test (The stricter = standard)

An = architectural feature does not impinge upon a right unless a violation = of the right in question would not be possible but for the inclusion (or absence) of = that feature acting alone or in combination with at = least one other feature. 


2. Highly Likely test (The weaker = standard)

An = architectural feature does not impinge upon a right unless the probability of the right in question being = violated would = be substantially different as a result of the presence (or = absence) of that feature acting alone or in = combination with at least one other feature


Scott


Scott = Craig | Ford-Mozilla Fellow
Center for = Democracy & Technology | cdt.org
E: scraig@cdt.org | D: 1.202.407.8887 | @scottdavidcraig



On 13 May 2016, at 18:08, Niels ten Oever <niels@article19.org>= wrote:

Hi Scott,

Thanks for your = question. The relationship that is implied (and I think
it = is in the text, if not I should definitely add it), that these
concepts shape the enabling environment on the Internet for = exercising a
specific right.

That does not mean that we could not imagine another Internet = without
these properties where these rights could also be = exercised, but in the
current Internet we think these are = the crucial ingredient for enabling
the ability to = exercise specific rights.

How we came to = this is described in step 5.2.1.4.  Translating Human
Rights Concept into Technical Definitions

Hope this helps, and looking forward to discuss!

Best,

Niels

PS If you think this is not clear from the = text, please say so (or even
better, create a pull request = here:
https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md= )



Niels = ten Oever
Head of Digital

Article 19
www.article19.org

PGP = fingerprint    8D9F C567 BEE4 A431 56C4
=             &n= bsp;     678B 08B5 A0F2 636D 68E9

On 05/13/2016 02:07 PM, Scott Craig wrote:
Hey Corrine, Niels,

I have been reading though your recent = draft
<https://datatracker.ietf.org/doc/draft-tenoever-hrpc-resear= ch/>
<https://datatracker.ietf.org/doc/draft-tenoever-hrpc-resear= ch/>on
protocol considerations. There were a couple of = things I couldn=92t figure
out from the text that I was = hoping you might be able to clarify.

Firstly, what specific relationship is the visual equation = (of
architectural features to rights) intended to imply? =  

eg. (  Connectivity )

  ( =      Privacy =             &n= bsp;  )
  ( =      Security =             &n= bsp; )   =3D Right to freedom of expression
=   (      Content agnosticism =    )
  ( =      Internationalization   )
  (      Censorship = resistance  )
  ( =      Open Standards =         )
=    (     Heterogeneity support )


Is it intended to imply that no = other architectural feature bears upon
that right? Or, = i**
*s it intended to imply *that ALL of the
****
listed
** **
architectural features MUST be present in order for the right = to
be protected? And
****
*
*If not all, then h*
*ow many features need not = be present before a protocol can be
considered to abrogate = a right?
**
Secondly, w
hat = method/principals have you used to determine which rights are
affected by which architectural features (technical = concepts)?
I was expecting an explanation of this in
section 5.2.2 of the methodology but I can=92t seem to find = one there or
elsewhere in the doc. Have I missed this = somewhere?
*

Many thanks, and = great work!

Scott
*

*Scott Craig* | Ford-Mozilla Fellow
Center for Democracy & Technology |* cdt.org = <https://cdt.org/>*
*E:* scraig@cdt.org = <http://cdt.org/> | *D:* 1.202.407.8887
<tel:202.407.8887> | **@scottdavidcraig



_______________________________________________
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

= --Apple-Mail=_EF1E5A2A-415A-4406-B2E2-4D3A64D7A770-- From nobody Mon May 16 04:03:35 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 91B2312B038; Mon, 16 May 2016 04:03:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516110331.16841.97068.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 04:03:31 -0700 Archived-At: Cc: hrpc-chairs@ietf.org, niels@article19.org, hrpc@irtf.org, irtf-chair@irtf.org Subject: [hrpc] hrpc - Update to a Meeting Session Request for IETF 96 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: Mon, 16 May 2016 11:03:31 -0000 An update to a meeting session request has just been submitted by Niels ten Oever, a Chair of the hrpc working group. --------------------------------------------------------- Working Group Name: Human Rights Protocol Considerations Area Name: IRTF Session Requester: Niels Oever Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: irtfopen Second Priority: saag Third Priority: dprive Special Requests: Strong preference for Tuesday, Wednesday or Thursday --------------------------------------------------------- From nobody Mon May 16 04:30:46 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 6937212D0E9 for ; Mon, 16 May 2016 04:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 n5BDSKbxgPqI for ; Mon, 16 May 2016 04:30:42 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7384612D0C2 for ; Mon, 16 May 2016 04:30:42 -0700 (PDT) Received: from filter.hostedemail.com (unknown [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id 3229A12BA21 for ; Mon, 16 May 2016 11:30:41 +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:969:973:988:989:1000:1187:1260:1261:1313:1314:1345:1359:1381:1437:1516:1518:1534:1542:1575:1594:1711:1730:1747:1777:1792:2194:2198:2199:2200:2393:2525:2553:2561:2564:2682:2685:2693:2859:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3673:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4250:4425:4860:5007:6117:6506:6747:6748:7281:7652:7901:7903:7909:8660:9010:9025:9108:10004:10848:11232:11604:11658:11914:12043:12050:12109:12114:12291:12379:12438:12517:12519:12683:12740:13019:13148:13230:13846:14095:14180:14181:14227:14658:14659:14721:21060:21080:21212:21324:21326:21433:30022: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: hall99_230b290a3bb46 X-Filterd-Recvd-Size: 4566 Received: from [127.0.0.1] (ip72-221-122-9.ri.ri.cox.net [72.221.122.9]) (Authenticated sender: avri@doria.org) by omf12.hostedemail.com (Postfix) with ESMTPA for ; Mon, 16 May 2016 11:30:40 +0000 (UTC) References: <57399CE7.90700@article19.org> To: hrpc@irtf.org From: avri doria Message-ID: <5739AF53.6020808@acm.org> Date: Mon, 16 May 2016 07:30:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57399CE7.90700@article19.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0n64VIWmhGD2oNbEpXlrlNrS5shLGTaDC" X-Antivirus: avast! (VPS 160516-1, 05/16/2016), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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: Mon, 16 May 2016 11:30:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0n64VIWmhGD2oNbEpXlrlNrS5shLGTaDC Content-Type: multipart/mixed; boundary="ocE10OtsLhLnxXUIoiF8bO2SnneXGu3FM" From: avri doria Reply-To: avri@acm.org To: hrpc@irtf.org Message-ID: <5739AF53.6020808@acm.org> Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 References: <57399CE7.90700@article19.org> In-Reply-To: <57399CE7.90700@article19.org> --ocE10OtsLhLnxXUIoiF8bO2SnneXGu3FM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I personally think it might be premature for this call, but since it has been made, would like to know of people who read this draft and think that it is something that is ready to become a RG draft. Is anyone willing to review this with a light to making a recommendation on whether it should be a RG work item? Would like to get some deeper opinion on the draft and its contents, especially from an engineering perspective. I would also like to hear about others who are interested in working on this draft, as becoming an RG draft means moving it more into the main work stream of the RG and getting greater input that just the authors and a few commenters. I have not had a chance to read it yet, but will do so as soon as I can. avri On 16-May-16 06:11, Niels ten Oever wrote: > Dear RG, > > > > This email serves as a call for RG adoption of > draft-tenoever-hrpc-research-02 [0] as a RG document. The call for > adoption will run for 2 weeks ending 5/30/2016. > > > > Several of your might have thought this document was already an RG > document, but since it was never formally adopted we thought it might b= e > a good idea to do that now (even though this is not strictly a > requirement for this in the IRTF, but for the sake of clarity and > transparency we'll follow the IETF procedure as decribed in RFC7221). > > > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a RG document simply means that the R= G > will focus its efforts on that particular draft going forward, and use > that document for resolving open issues and documenting the RG=92s deci= sions. > > > > Please indicate whether you support adoption or not, and if not why. > Issues you have with the current document itself can also be raised, bu= t > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > > > Looking forward to hear your opinions. > > > > All the best, > > > > Niels > > > > [0] https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --ocE10OtsLhLnxXUIoiF8bO2SnneXGu3FM-- --0n64VIWmhGD2oNbEpXlrlNrS5shLGTaDC 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 iQEcBAEBAgAGBQJXOa9fAAoJEOo+L8tCe36H+FkH/AhgYaDqeLSGxGEOurft9pq1 i6t453DBORTZweNQeqUVYkTCmKO5ejBhvOWJKyo2i0YO2ZrXpQZRmKSKhT7L8qm0 7SvZB1NUKwGCXolJB7AQpsW8ZA0f/PP/5yYzQ53aC9u9gYn8dzkevzadH0GVs5Cn QE7MOwdg+DB9w4gs+LV/Ikwxi1hl4+JSwlh/bVDKB0ikkOPLheZyNLKMW0hZ9f0g 1HadXU+yndGj1BclHDCOCYTYYk1RSkFwkX6OoDg/u1rPzJKm877inLy/j800n+6F fIoCFC/PvMMaAHdGE6QW9HfE271vokD5HzfrOBm7MmImwjFYk6jy85mX2611RMg= =d3Jr -----END PGP SIGNATURE----- --0n64VIWmhGD2oNbEpXlrlNrS5shLGTaDC-- From nobody Mon May 16 06:49:16 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 7133E12D185 for ; Mon, 16 May 2016 06:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 XEF63XTK-uYe for ; Mon, 16 May 2016 06:49:13 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 BB6BE12D6CF for ; Mon, 16 May 2016 06:49:11 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n129so102060091wmn.1 for ; Mon, 16 May 2016 06:49:11 -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:date:message-id:subject :from:to; bh=Y+JNRUiHQbdkJtH3KxlGm96MSSsFHnDXar7bPw/t7Lg=; b=oTapdUteOO5ePce0UtlRGF5wrwPfWEj5ODbv4AFvYGwb0IacruSxQYhhENb1GD2qf/ Rh9vRlSclkLESdY9fsvMOCZy8hJHdGwWMcl/fn5SZPSdAlAFuZovRgjxdhxWqTCaC4PK f8WnDUWe1KwWEgrVMMqJsVJTpKXJ1XnZaZIcRovMeufL05GG/iHBq9aJRtmkcpO1HC6D yDsJP/0ESFYbn4an+uW+yQfQafBvoa85ZHEOsHEjXQDmBCSwrOgyGq35g3NgCoq93POu pvehCMDqQB8Ufen3j7nn5mvLzjWIluMd6W47VeGzKMADVCJSKa433KHDrCIcBpOvvtQ5 EZBg== 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:date :message-id:subject:from:to; bh=Y+JNRUiHQbdkJtH3KxlGm96MSSsFHnDXar7bPw/t7Lg=; b=gHEMUIlob/+d+n2zl0UZzCBd3yenXEnCnM9ao5JwgVZTyW9ugLi1RCMfLuxbQQua5M +gDuDipW9J3RqAKrsANAnBcXeUHDzNS+1XTsI0ik8MhwJ3wNWEShVzC6XuzhA38Q+X03 WL5jiG2LI/7jnee92aMR+dHdFCuqy2mWVjKgh/ovAD41VskCw0WSEZzi6Sh99cdNoX3A kgNn0M2yYFvPwaGrqlI5QSm60iNklhVCtt44tryewfg+Hs4Djj5mDygcgdgm4ropNMhk cdmKvaIX65wmiQHBOHZIbwiCN2Qj6XKcxDApdPOHQr1SVJJoihUR5Ha8giAgpHjTXfV1 1kkg== X-Gm-Message-State: AOPr4FX4eRp5vWwNdEbyWJIByQwcRyCArejQKQAEHkQJtuDBCp4CV9UWxrnWCkpPSGFKwrJKIfhBmik/naB89g== MIME-Version: 1.0 X-Received: by 10.28.92.18 with SMTP id q18mr19086256wmb.48.1463406550187; Mon, 16 May 2016 06:49:10 -0700 (PDT) Sender: cattekwaad@gmail.com Received: by 10.194.41.233 with HTTP; Mon, 16 May 2016 06:49:10 -0700 (PDT) In-Reply-To: <5FBC0A2C-1C45-4AE1-A559-C2706741FA9E@cdt.org> References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> <57360A1B.2020000@article19.org> <5FBC0A2C-1C45-4AE1-A559-C2706741FA9E@cdt.org> Date: Mon, 16 May 2016 14:49:10 +0100 X-Google-Sender-Auth: z--IdtfPe1GSI1X_WFh56uwwkho Message-ID: From: Corinne Cath To: Scott Craig , hrpc@irtf.org Content-Type: multipart/alternative; boundary=001a1145ad98960bbc0532f5e308 Archived-At: Subject: Re: [hrpc] What test determines whether an architectural feature is a crucial ingredient for enabling the ability to exercise specific right? 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, 16 May 2016 13:49:15 -0000 --001a1145ad98960bbc0532f5e308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Scott, Thanks again for your comments. Our methodology to determine whether an architectural feature is a 'crucial ingredient for enabling the ability to exercise specific rights' is based on several steps which you mentioned. The meta-approach of linking certain technical properties to certain social outcomes is based on the work done by Clark (1988) who explains the relation between the design goals and the features of the protocols. And that of Abbate (2000) and Denardis (2013,2014) who explain how social values, and the personal values of engineers enter into the Internet's architecture, creating technology that elevates certain social values. We argue that many of the technical features of the current Internet, like the crucial features mentioned by Clark (1988) (interoperability, redundancy, end-to-end etc), fundamentally enable human rights. In order to establish this we have compared the different properties of human rights to technical properties of protocols, and also gave multiple examples of cases where the presence of certain technological features objectively undermine or enable human rights (like injection of records, traffic interception, XMPP). It is on the basis of these various case studies, elaborate discussion on the mailinglist and at various IETF conferences that we came to determine whether an architectural feature is a 'crucial ingredient for enabling the ability to exercise specific rights=E2=80=99. I think we might need to specify that by enabling human rights we do not assume that if these features are present the realization of human rights automatically follows suit. Or in other words, these features are necessary but not sufficient. As we both know, for instance with freedom of expression, if you have an open, accessible free Internet on a protocol level but a government blocks access to it or filters for certain content you do not have freedom of expression in the fullest sense. The approach we take suggests that the relationship between technical properties and human rights should be approached as a continuum, where certain technical properties allow for human rights to be enabled to different extends. The relationship between the presence of certain legal principles for enabling human rights on the other hand is much more black or white. For example, the Internet can still enable freedom of expression when there is connectivity (even though the end-users runs a greater risk than when the technical properties of connectivity and privacy and security are also present) but freedom of expression (as defined in the UDHR) cannot be fully guaranteed when, for instance, people can seek and receive information but not impart it. As such I think it would be interesting to take up your suggestion and work out a way to use the "Highly Likely test", to define which features have what impact on human rights. However, at the same time I am unsure if a legal test is the best way to go about it. The potential impact of legal principles being present or absent has a much clearer impact on for instance human rights like freedom of expression, than does the presence or absence of certain technical principles. I would love to hear what you think! Best, On Mon, May 16, 2016 at 11:37 AM, Scott Craig wrote: > Hi Niels, > > Thanks for the answer. I had another look through section 5.2.1.4. and I > couldn't find a description of the test you have applied to determine > whether an architectural feature is a 'crucial ingredient for enabling th= e > ability to exercise specific rights=E2=80=99 (and therefore qualified for= inclusion > in the equation below.) > > > eg. ( Connectivity ) > > ( Privacy ) > ( Security ) =3D Right to freedom of expression > ( Content agnosticism ) > ( Internationalization ) > ( Censorship resistance ) > ( Open Standards ) > ( Heterogeneity support ) > > > > Say, for example, that someone were to claim that a feature (or > combination of features) that you have listed as 'shaping the enabling > environment' for freedom of expression did not do so. What criteria would > be used to assess the merits of that claim? Is there a specific test that > was applied during the creation of the second list (see quotation below) > which could be examined? (this is what I=E2=80=99ve been trying to find). > > Mapping the protocols and standards that are related to human rights and > create a human rights enabeling environment was the first step. For that = we > needed to focus on specific technical concepts that underlie these > protocols and standards. On the basis of this list a number of technical > concepts that appeared frequently was extracted, *and used to create a > second list of technical terms that, when combined, create an enabling > environment for excercising human rights on the Internet. * > > > If no test was used, then I would argue it would be *highly beneficial to > develop one*. A test would, I think, aid in ensuring the kind of clear, > explicit and Human Rights conscious design decisions you describe below . > > It is however important to make consicious and explicit design decisions > that take into account the human rights protocol considerations guideline= s > developed below. This will ensure that the impact protocols can have on > human rights is clear and explicit, both for developers and for users. > > > > I'm therefore tentatively proposing two possibilities (based on UK > Judicial Review principals) for discussion: > > *1. Inevitability *test (The stricter standard) > > An architectural feature does not impinge upon a right unless a violation > of the right in question would *not be possible but for the inclusion (or > absence)* of that feature acting *alone or in combination with at least > one other feature*. > > > *2. Highly Likely* test (The weaker standard) > > An architectural feature does not impinge upon a right unless the > *probability* of the right in question being violated *would > be substantially differen*t as a result of the presence (or absence) of > that feature acting* alone or in combination with at least one other > feature* > > > Scott > > > *Scott Craig* | Ford-Mozilla Fellow > Center for Democracy & Technology |* cdt.org * > *E:* scraig@cdt.org | *D:* 1.202.407.8887 | @scottdavidcraig > > > > On 13 May 2016, at 18:08, Niels ten Oever wrote: > > Hi Scott, > > Thanks for your question. The relationship that is implied (and I think > it is in the text, if not I should definitely add it), that these > concepts shape the enabling environment on the Internet for exercising a > specific right. > > That does not mean that we could not imagine another Internet without > these properties where these rights could also be exercised, but in the > current Internet we think these are the crucial ingredient for enabling > the ability to exercise specific rights. > > How we came to this is described in step 5.2.1.4. Translating Human > Rights Concept into Technical Definitions > > Hope this helps, and looking forward to discuss! > > Best, > > Niels > > PS If you think this is not clear from the text, please say so (or even > better, create a pull request here: > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md ) > > > > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > > On 05/13/2016 02:07 PM, Scott Craig wrote: > > Hey Corrine, Niels, > > I have been reading though your recent draft > > on > protocol considerations. There were a couple of things I couldn=E2=80=99t= figure > out from the text that I was hoping you might be able to clarify. > > Firstly, what specific relationship is the visual equation (of > architectural features to rights) intended to imply? > > eg. ( Connectivity ) > > ( Privacy ) > ( Security ) =3D Right to freedom of expression > ( Content agnosticism ) > ( Internationalization ) > ( Censorship resistance ) > ( Open Standards ) > ( Heterogeneity support ) > > > Is it intended to imply that no other architectural feature bears upon > that right? Or, i** > *s it intended to imply *that ALL of the > **** > listed > ** ** > architectural features MUST be present in order for the right to > be protected? And > **** > * > *If not all, then h* > *ow many features need not be present before a protocol can be > considered to abrogate a right? > ** > Secondly, w > hat method/principals have you used to determine which rights are > affected by which architectural features (technical concepts)? > I was expecting an explanation of this in > section 5.2.2 of the methodology but I can=E2=80=99t seem to find one the= re or > elsewhere in the doc. Have I missed this somewhere? > * > > Many thanks, and great work! > > Scott > * > > *Scott Craig* | Ford-Mozilla Fellow > Center for Democracy & Technology |* cdt.org * > *E:* scraig@cdt.org | *D:* 1.202.407.8887 > | **@scottdavidcraig > > > > > _______________________________________________ > 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 > > --=20 Corinne J.N. Cath --001a1145ad98960bbc0532f5e308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Scott,

Thanks again for your comments.

Our = methodology to determine whether an architectural feature is a 'crucial= ingredient for enabling the ability to exercise specific rights' is ba= sed on several steps which you mentioned.

The meta-approach of lin= king certain technical properties to certain social outcomes is based on th= e work done by Clark (1988) who explains the relation between the design go= als and the features of the protocols. And that of Abbate (2000) and=C2=A0 = Denardis (2013,2014) who explain how social values, and the personal values= of engineers enter into the Internet's architecture, creating technolo= gy that elevates certain social values.

We argue that many of the = technical features of the current Internet, like the crucial features menti= oned by Clark (1988) (interoperability, redundancy, end-to-end etc), fundam= entally enable human rights. In order to establish this we have compared th= e different properties of human rights to technical properties of protocols= , and also gave multiple examples of cases where the presence of certain te= chnological features objectively undermine or enable human rights (like inj= ection of records, traffic interception, XMPP). It is on the basis of these= various case studies, elaborate discussion on the mailinglist and at vario= us IETF conferences that we came to determine whether an architectural feat= ure is a 'crucial ingredient for enabling the ability to exercise speci= fic rights=E2=80=99.

I think we might need to specify that by enabl= ing human rights we do not assume that if these features are present the re= alization of human rights automatically follows suit. Or in other words, th= ese features are necessary but not sufficient. As we both know, for instanc= e with freedom of expression, if you have an open, accessible free Internet= on a protocol level but a government blocks access to it or filters for ce= rtain content you do not have freedom of expression in the fullest sense.
The approach we take suggests that the relationship between tech= nical properties and human rights should be approached as a continuum, wher= e certain technical properties allow for human rights to be enabled to diff= erent extends. The relationship between the presence of certain legal princ= iples for enabling human rights on the other hand is much more black or whi= te.

For example, the Internet can still enable freedom of expressio= n when=20 there is connectivity (even though the end-users runs a greater risk=20 than when the technical properties of connectivity and privacy and=20 security are also present) but freedom of expression (as defined in the=20 UDHR) cannot be fully guaranteed when, for instance, people can seek and receive information but not impart it.

As such I think it would be= interesting to take up your suggestion and work out a way to use the
&= quot;Highly Likely=C2=A0test", to define which features have what impact on human= =20 rights. However, at the same time I am unsure if a legal test is the=20 best way to go about it. The potential impact of legal principles being=20 present or absent has a much clearer impact on for instance human=20 rights like freedom of expression, than does the presence or absence of cer= tain technical=20 principles.

I would love to hear what you think!

=
Best,





=09

On Mon, May= 16, 2016 at 11:37 AM, Scott Craig <scraig@cdt.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi N= iels,=C2=A0

Thanks for the answer. I had another look th= rough section 5.2.1.4. and I couldn't find a description of the test yo= u have applied to determine whether an architectural feature is a 'cruc= ial ingredient for enabling the ability to exercise specific rights=E2=80= =99 (and therefore qualified for inclusion in the equation below.)=C2=A0


eg. ( =C2=A0Connectivity )

=C2=A0=C2=A0( =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Privacy =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0)
=C2=A0=C2=A0( =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Security =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0) =C2=A0=C2=A0=3D Right to freedom of e= xpression
=C2=A0=C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Content agnosticis= m =C2=A0=C2=A0=C2=A0)
=C2=A0=C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Intern= ationalization =C2=A0=C2=A0)
=C2=A0=C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Censorship resistance =C2=A0)
=C2=A0=C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Open Standards =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0)
= =C2=A0=C2=A0=C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0Heterogeneity support )


Say, for example, that someone we= re to claim that a feature (or combination of features) that you have liste= d as 'shaping the enabling environment' for freedom of expression d= id not do so. What criteria would be used to assess the merits of that clai= m? Is there a specific test that was applied during the creation of the sec= ond list (see quotation below) which could be examined? (this is what I=E2= =80=99ve been trying to find).

Mapping the protocols and standards that a= re related to human rights and create a human rights enabeling environment = was the first step. For that we needed to focus on specific technical conce= pts that underlie these protocols and =C2=A0standards. On the basis of this= list a number of technical concepts that appeared frequently was extracted= ,=C2=A0and used to create a second list of technical terms that, when co= mbined, create an enabling environment for excercising human rights on the = Internet.=C2=A0

If n= o test was used, then I would argue it would be=C2=A0highly beneficial t= o develop one. A test would, I think, aid in ensuring the kind of clear= , explicit and Human Rights conscious design decisions you describe below .= =C2=A0

=C2=A0It is howev= er important to make consicious and explicit design decisions that take int= o account the human rights protocol considerations guidelines developed bel= ow. This will ensure that the impact protocols can have on human rights is = clear and explicit, both for developers and for users.


I'm therefore tentatively proposing two possibili= ties (based on UK Judicial Review principals) for discussion:
1. Inevitability=C2=A0test (The stricter standard)
=

An architectural feature does not impinge upon a right = unless a violation of the right in question would=C2=A0not be=C2=A0possi= ble=C2=A0but for=C2=A0the inclusion (or absence)=C2=A0of that fe= ature acting=C2=A0alone or in combination with at least one other featur= e.=C2=A0


2. Highly Likely=C2=A0test (The weaker standard)

An architectural= feature does not impinge upon a right unless the=C2=A0probability= =C2=A0of the right in question being violated=C2=A0would be=C2=A0substan= tially=C2=A0different as a result of the presence (or absence) of that = feature acting=C2=A0alone or in combination with at least one other feat= ure


Scott

<= /div>

Scott Craig=C2=A0|=C2=A0Ford-Mozilla Fellow
Center for Democracy & Technology=C2=A0= |=C2=A0cdt.org
E:=C2=A0scraig@cdt.= org=C2=A0|=C2=A0D:=C2=A01.202.407.8887=C2=A0|=C2=A0@scottdavidcraig=



On 13 May 2016, at 18:08, Niels ten= Oever <niels@a= rticle19.org> wrote:

Hi Scott,

Thanks for = your question. The relationship that is implied (and I think
it is in th= e text, if not I should definitely add it), that these
concepts shape th= e enabling environment on the Internet for exercising a
specific right.<= br>
That does not mean that we could not imagine another Internet withou= t
these properties where these rights could also be exercised, but in th= e
current Internet we think these are the crucial ingredient for enablin= g
the ability to exercise specific rights.

How we came to this is= described in step 5.2.1.4.=C2=A0 Translating Human
Rights Concept into = Technical Definitions

Hope this helps, and looking forward to discus= s!

Best,

Niels

PS If you think this is not clear from = the text, please say so (or even
better, create a pull request here:
= https://github.com/nllz/IRTF-HRPC/blob/master/draft-rese= arch.md )



Niels ten Oever
Head of Digital

Arti= cle 19
www.articl= e19.org

PGP fingerprint =C2=A0=C2=A0=C2=A08D9F C567 BEE4 A431 56= C4
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0678B 08B5 A0F2 636D 68E9

O= n 05/13/2016 02:07 PM, Scott Craig wrote:
Hey = Corrine, Niels,

I have been reading though your recent draft
<= https://datatracker.ietf.org/doc/draft-tenoever-hrpc-rese= arch/>
<https://datatracker.ietf.org/doc/dr= aft-tenoever-hrpc-research/>on
protocol considerations. There wer= e a couple of things I couldn=E2=80=99t figure
out from the text that I = was hoping you might be able to clarify.

Firstly, what specific rel= ationship is the visual equation (of
architectural features to rights) i= ntended to imply? =C2=A0

eg. ( =C2=A0Connectivity )

=C2=A0= =C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Privacy =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0)
=C2=A0= =C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Security =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0) =C2=A0=C2=A0=3D = Right to freedom of expression
=C2=A0=C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Content agnosticism =C2=A0=C2=A0=C2=A0)
=C2=A0=C2=A0( =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Internationalization =C2=A0=C2=A0)
=C2=A0=C2=A0( = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Censorship resistance =C2=A0)
=C2=A0=C2= =A0( =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Open Standards =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0)
=C2=A0=C2=A0=C2=A0( =C2=A0=C2=A0=C2=A0=C2=A0H= eterogeneity support )


Is it intended to imply that no other arc= hitectural feature bears upon
that right? Or, i**
*s it intended to i= mply *that ALL of the
****
listed
** **
architectural features= MUST be present in order for the right to
be protected? And
*****
*If not all, then h*
*ow many features need not be present before = a protocol can be
considered to abrogate a right?
**
Secondly, what method/principals have you used to determine which rights are
affe= cted by which architectural features (technical concepts)?
I was expect= ing an explanation of this in
section 5.2.2 of the methodology but I ca= n=E2=80=99t seem to find one there or
elsewhere in the doc. Have I misse= d this somewhere?
*

Many thanks, and great work!

Scott
= *

*Scott Craig* | Ford-Mozilla Fellow
Center for Democracy & = Technology |* cdt.org <= https://cdt.org/>**E:* scraig@cdt.org <http://cdt.org/>= | *D:* 1.202.407.8887
<tel:202.407.8887> | **@scottdavidcraig
=



_______________________________________________
hrpc mai= ling list
hrpc@irtf.o= rg
https://www.irtf.org/mailman/listinfo/hrpc

=
_______________________________________________
hrpc mailing listhrpc@irtf.org
http= s://www.irtf.org/mailman/listinfo/hrpc


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




--
Corinne J.N. Cath
--001a1145ad98960bbc0532f5e308-- From nobody Mon May 16 06:58: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 3FE2412D177 for ; Mon, 16 May 2016 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 a5ATOR92AW1L for ; Mon, 16 May 2016 06:58:22 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4628312D16F for ; Mon, 16 May 2016 06:58:22 -0700 (PDT) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 501B4C5A5D for ; Mon, 16 May 2016 15:58:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id hJUi5G3dasCf for ; Mon, 16 May 2016 15:58:18 +0200 (CEST) X-Originating-IP: 95.91.242.109 Received: from [192.168.1.105] (ip5f5bf26d.dynamic.kabel-deutschland.de [95.91.242.109]) (Authenticated sender: lists@nex.sx) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 44C1EC5A60 for ; Mon, 16 May 2016 15:58:17 +0200 (CEST) To: hrpc@irtf.org References: <57399CE7.90700@article19.org> From: Nex Message-ID: <4d716782-a644-1ce4-6150-ae9e059954bb@nex.sx> Date: Mon, 16 May 2016 15:58:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57399CE7.90700@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eBMpiCQc9OuMW6T0UIaBJD8e1tXwseNmi" Archived-At: Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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, 16 May 2016 13:58:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eBMpiCQc9OuMW6T0UIaBJD8e1tXwseNmi Content-Type: multipart/mixed; boundary="4EJMNjv227qJEwMOMdXpAlhdeGlvwBWMh" From: Nex To: hrpc@irtf.org Message-ID: <4d716782-a644-1ce4-6150-ae9e059954bb@nex.sx> Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 References: <57399CE7.90700@article19.org> In-Reply-To: <57399CE7.90700@article19.org> --4EJMNjv227qJEwMOMdXpAlhdeGlvwBWMh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Needless to say, having helped directly on it ;), I wanted to express my support for the adoption of the document. All the best, Claudio Guarnieri On 05/16/2016 12:11 PM, Niels ten Oever wrote: > Dear RG, >=20 >=20 >=20 > This email serves as a call for RG adoption of > draft-tenoever-hrpc-research-02 [0] as a RG document. The call for > adoption will run for 2 weeks ending 5/30/2016. >=20 >=20 >=20 > Several of your might have thought this document was already an RG > document, but since it was never formally adopted we thought it might b= e > a good idea to do that now (even though this is not strictly a > requirement for this in the IRTF, but for the sake of clarity and > transparency we'll follow the IETF procedure as decribed in RFC7221). >=20 >=20 >=20 > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a RG document simply means that the R= G > will focus its efforts on that particular draft going forward, and use > that document for resolving open issues and documenting the RG=92s deci= sions. >=20 >=20 >=20 > Please indicate whether you support adoption or not, and if not why. > Issues you have with the current document itself can also be raised, bu= t > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. >=20 >=20 >=20 > Looking forward to hear your opinions. >=20 >=20 >=20 > All the best, >=20 >=20 >=20 > Niels >=20 >=20 >=20 > [0] https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 >=20 >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --4EJMNjv227qJEwMOMdXpAlhdeGlvwBWMh-- --eBMpiCQc9OuMW6T0UIaBJD8e1tXwseNmi 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 iQIcBAEBCAAGBQJXOdH5AAoJENFm8WZzWdiA7KIP/RPS7xyWTVFIRdJNOs37e0A5 wja7tBdgm1tyOethQupKG07Wqy3281nN1qSSPnmqu0UyhHAakQNpEboW39xo1yB1 fq+C22PjcJc3Vd06wydUXoCGeddnY06QshDVbdnpAvoVgL5OOmNmSc+9hE/0GShN 59CTKksy/RWFQcGPbRL4Z4CsSGuo7g/w+8try9NDad6eZqYlYsDlqfGiGqogXdrw wAS6cDOi3oc5tLaYunTOJ8ximmkxfONOP8WTLS5nRe+cK9uFOE4aJgiUf8yxts1w VIO7TeuA/L9PEmM05/mmH+S6ClHT5cHEcHj4P+h16KUU7cKZmGHoVEJ4t/f1eP9G l47ekne54nbF8u8MW7wqBuV1IS6obX3+PKhI51SmRuLrRp0qpfUBkOiy4UO7KwHC daMH2kVUxlPl/Y5Y75pILhzSUqgtrS5KLFvxmSBkiIAim/xqeHlyZAmy+fJXcvIk 69A2ZqhgZP3Z7z3f3T7EP6SmrKlcBkyn8F//5Kpb2QTzYDtYxgRltD7DpmNPeKtr y6SIAvDh4ZP5++xp65lMpr39P3amXcJgVhXpkiFd1ab07mt3CqsinGLZJt0sF3Tx 66hb73yunZdV3ku251lnF2zrV4oWIRDjDzva4mNfECVD6o86ayzj5Fw1n4N7us/p rlKxQUugGfpXOfxKT7nd =XCC3 -----END PGP SIGNATURE----- --eBMpiCQc9OuMW6T0UIaBJD8e1tXwseNmi-- From nobody Mon May 16 09:58: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 A9D8412D788 for ; Mon, 16 May 2016 09:58:39 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 LQnmtdnTMPM1 for ; Mon, 16 May 2016 09:58:37 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 6EFF712D790 for ; Mon, 16 May 2016 09:58:37 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id z184so66873989vkg.0 for ; Mon, 16 May 2016 09:58:37 -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=HYFoxZHcvDwArks0W0paTrvsVLo3pDViNv5oaJQ4oOY=; b=n0CcrmnB0ZL6S9kQuMaKqwkVpmwX6/IBPZomOf6oK8j2axELoeC6OVjWvptkYDKL0A nBI8xTmfxJ+WfcdVb8gNmGCFOXetJiq7c65nF97PEBei4veT7V6NoDHN/g/6LNKav6ZU O27oJLnMYIG6seUGppdgd/rt/uSaKOB4ASPX8= 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=HYFoxZHcvDwArks0W0paTrvsVLo3pDViNv5oaJQ4oOY=; b=eNxCWGkHQSTdjqv7Srqz6yE78fs0HeY3Jr7Hl0XGcgfYfAq9k3ur8Hli2Dq0UDpgL5 v8GCt1i8fnbBs1evlClGd26VOLDS2pGf/SAmyCwA/YXIZ4OeUDxF7fM3a1/6RVv8iNjX LKJhvKzXJszLpxNab7q32EDD9WodMXIHuVTykUIKolAX6JV+nNjqBvcy0eovdww83cut cTwo8KBnwutzR6m6FywKzrUNKuDZqN/Q43w8RncyhGVd9ZSkjZjJnkXVTJSJHBV0KJsb 4Sd/XjZKG9UKf8nm9gianSRfwqIVyuk6t4p32I4HxvQgrHICtC8c7fCEMIrnrebsmA81 0NtA== X-Gm-Message-State: AOPr4FUV5++B42CLKSa73T83ZzfO93nuydtK0i0kjA+9sxxBur+YmRIQ5k/wHvdugSJdyW3jgAataxu83bASZJsM X-Received: by 10.31.217.7 with SMTP id q7mr15412892vkg.134.1463417916445; Mon, 16 May 2016 09:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.6 with HTTP; Mon, 16 May 2016 09:58:17 -0700 (PDT) In-Reply-To: <5739AF53.6020808@acm.org> References: <57399CE7.90700@article19.org> <5739AF53.6020808@acm.org> From: Joseph Lorenzo Hall Date: Mon, 16 May 2016 12:58:17 -0400 Message-ID: To: Avri Doria Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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, 16 May 2016 16:58:40 -0000 Hmm, I'm not sure why this would be premature, Avri. It seems like a core document this group would work on in addition to methodology and glossary. We have a large quantity of comments on this draft (working with our fellow, Scott Craig) that we'll be sharing in coming weeks. We support adoption. best, Joe On Mon, May 16, 2016 at 7:30 AM, avri doria wrote: > Hi, > > I personally think it might be premature for this call, but since it has > been made, would like to know of people who read this draft and think > that it is something that is ready to become a RG draft. > > Is anyone willing to review this with a light to making a recommendation > on whether it should be a RG work item? Would like to get some deeper > opinion on the draft and its contents, especially from an engineering > perspective. > > I would also like to hear about others who are interested in working on > this draft, as becoming an RG draft means moving it more into the main > work stream of the RG and getting greater input that just the authors > and a few commenters. > > I have not had a chance to read it yet, but will do so as soon as I can. > > avri > > > On 16-May-16 06:11, Niels ten Oever wrote: >> Dear RG, >> >> >> >> This email serves as a call for RG adoption of >> draft-tenoever-hrpc-research-02 [0] as a RG document. The call for >> adoption will run for 2 weeks ending 5/30/2016. >> >> >> >> Several of your might have thought this document was already an RG >> document, but since it was never formally adopted we thought it might be >> a good idea to do that now (even though this is not strictly a >> requirement for this in the IRTF, but for the sake of clarity and >> transparency we'll follow the IETF procedure as decribed in RFC7221). >> >> >> >> Please note that this is a call for adoption, and not a last call for >> content of the document. Adopting a RG document simply means that the RG >> will focus its efforts on that particular draft going forward, and use >> that document for resolving open issues and documenting the RG=E2=80=99s= decisions. >> >> >> >> Please indicate whether you support adoption or not, and if not why. >> Issues you have with the current document itself can also be raised, but >> they should be raised in the context of what should be changed in the >> document going forward, rather than a pre-condition for adoption. >> >> >> >> Looking forward to hear your opinions. >> >> >> >> All the best, >> >> >> >> Niels >> >> >> >> [0] https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 >> >> >> >> _______________________________________________ >> 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 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 From nobody Mon May 16 10:07: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 20C8E12D7E2; Mon, 16 May 2016 10:07:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516170736.16817.56673.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 10:07:36 -0700 Archived-At: Cc: hrpc-chairs@ietf.org, avri@acm.org, hrpc@irtf.org, irtf-chair@irtf.org Subject: [hrpc] hrpc - Update to a Meeting Session Request for IETF 96 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: Mon, 16 May 2016 17:07:36 -0000 An update to a meeting session request has just been submitted by Avri Doria, a Chair of the hrpc working group. --------------------------------------------------------- Working Group Name: Human Rights Protocol Considerations Area Name: IRTF Session Requester: Avri Doria Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: irtfopen Second Priority: saag Third Priority: dprive Special Requests: Strong preference for Tuesday PM, Wednesday AM or Thursday --------------------------------------------------------- From nobody Mon May 16 10:22: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 D47D712D807 for ; Mon, 16 May 2016 10:22:20 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 I0Xy_5uUkPpP for ; Mon, 16 May 2016 10:22:19 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 20DFA12D7F8 for ; Mon, 16 May 2016 10:22:18 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id z184so67744717vkg.0 for ; Mon, 16 May 2016 10:22:18 -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=CZcmPJ5jM6yfun4TrgrXs8+2wyKwpDH+YB0EQhgT//g=; b=JPv7JGJEHL3lhILk/TRvS9B8mgtMFz4lACGOiR9Mb7CnXb775gPrh0HmBdiXeKrCnD JvYMDkPkerX5f8A/8Z7Ujp0lQqNGsvNYf0ehONJ3cMlEdhyF4nDetoB/pHBiN3Ngs0YQ G4dSeyv75N1opue8Igp+Jo0x8/2fKg0NLmc3w= 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=CZcmPJ5jM6yfun4TrgrXs8+2wyKwpDH+YB0EQhgT//g=; b=Ew6G1Hjb75LmJotGE9J5WkXOQKcWa2P8LJ9c+xJX6Eu1V0UxtONuD5wiGLdPM0NM5k DoM4sc8EUXvMjd9UfCTvcRxbThXcEaknz5n5TN/wiO+LClbONCTWYaVNyY1+92lW7Yqk w+p6xJOsCIq1VeJysfJR+OAe2F2QQzJ6+5FtmGlplqjeZ7WcZnxdWfetHzangw/yvFig ScQgBuYyI7Q+dqsHYkd9rba2ElrAwMgmiEngXNV0/J3q/LvucclfSiF35+6nOF2FOk2X wYgwKgh+AlV0/z0eLyugi1131pRa3pJvF1MXZRe5EEAJVeHdM+txfpwsQ/R9K83XT8zE 6dsg== X-Gm-Message-State: AOPr4FUeRZ5/cPiUChEdOxyjj3g5+WScfxBiF4ZVNqdrXSvDKNQbYb3cwyrpIOc3ksV64SFotcdtvezt8cOoPYHD X-Received: by 10.31.217.7 with SMTP id q7mr15467788vkg.134.1463419337119; Mon, 16 May 2016 10:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.6 with HTTP; Mon, 16 May 2016 10:21:57 -0700 (PDT) In-Reply-To: <57360A1B.2020000@article19.org> References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> <57360A1B.2020000@article19.org> From: Joseph Lorenzo Hall Date: Mon, 16 May 2016 13:21:57 -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 Subject: Re: [hrpc] HRPC draft research feedback 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, 16 May 2016 17:22:21 -0000 On Fri, May 13, 2016 at 1:08 PM, Niels ten Oever wrot= e: > Hi Scott, > > Thanks for your question. The relationship that is implied (and I think > it is in the text, if not I should definitely add it), that these > concepts shape the enabling environment on the Internet for exercising a > specific right. > > That does not mean that we could not imagine another Internet without > these properties where these rights could also be exercised, but in the > current Internet we think these are the crucial ingredient for enabling > the ability to exercise specific rights. > > How we came to this is described in step 5.2.1.4. Translating Human > Rights Concept into Technical Definitions > > Hope this helps, and looking forward to discuss! Thanks, Niels! So, from the text in 5.2.1.4, would you say that the bracketed list of concepts/ingredients/properties serves as "a list of technical concepts that when combined create an enabling environment for [a specific] human right"? It would be good to make sure we've interrogated, as a group, each of the technical concepts in the LHS of these equations. E.g., while I'm a privacy guy to the core, I suspect something more precise like confidentiality is the underlying technical concept? best, Joe > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > > On 05/13/2016 02:07 PM, Scott Craig wrote: >> Hey Corrine, Niels, >> >> I have been reading though your recent draft >> >> on >> protocol considerations. There were a couple of things I couldn=E2=80=99= t figure >> out from the text that I was hoping you might be able to clarify. >> >> Firstly, what specific relationship is the visual equation (of >> architectural features to rights) intended to imply? >> >> eg. ( Connectivity ) >> >> ( Privacy ) >> ( Security ) =3D Right to freedom of expression >> ( Content agnosticism ) >> ( Internationalization ) >> ( Censorship resistance ) >> ( Open Standards ) >> ( Heterogeneity support ) >> >> >> Is it intended to imply that no other architectural feature bears upon >> that right? Or, i** >> *s it intended to imply *that ALL of the >> **** >> listed >> ** ** >> architectural features MUST be present in order for the right to >> be protected? And >> **** >> * >> *If not all, then h* >> *ow many features need not be present before a protocol can be >> considered to abrogate a right? >> ** >> Secondly, w >> hat method/principals have you used to determine which rights are >> affected by which architectural features (technical concepts)? >> I was expecting an explanation of this in >> section 5.2.2 of the methodology but I can=E2=80=99t seem to find one th= ere or >> elsewhere in the doc. Have I missed this somewhere? >> * >> >> Many thanks, and great work! >> >> Scott >> * >> >> *Scott Craig* | Ford-Mozilla Fellow >> Center for Democracy & Technology |* cdt.org * >> *E:* scraig@cdt.org | *D:* 1.202.407.8887 >> | **@scottdavidcraig >> >> >> >> >> _______________________________________________ >> 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 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 From nobody Tue May 17 06:56: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 C08A512B019 for ; Tue, 17 May 2016 06:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WU1VzLsqlDEr for ; Tue, 17 May 2016 06:56:11 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 643AF1200A0 for ; Tue, 17 May 2016 06:56:11 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a17so32623088wme.0 for ; Tue, 17 May 2016 06:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NRiVTSecLTGp2zLHUX70ooEmJGIw64LDvu07V2vuScw=; b=ImzZItQXC8txAVCuJqBmo34+JSgJs5cotFUDfpU4rPOUCD1jAEehIM88YD5z+/ZCtB wWOiVukg24S/hFaU9NyjI1g16L7spffCXpzP0IxrOC1tnMcacIBJCmowpw/z03s46vpx Fca0wCbyeFn7UKYDzQGg+EkQLe42O9x/r8150BfgMT1H1IUjhBEHgo1Ug+R00nxQfhvA N3azNQyEUFIFDXrGooBoUJC/6uIgEjO847y4BC4/+I//YqF6eylfC1QMutnKy78NRC3Z Oi//QE7K+prKWCc+mS1gPZu/OGP0incLxYuwGi4ZkmIn58pdaZEyv7xSu77in14y97sj Af3A== 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:date :message-id:subject:from:to:cc; bh=NRiVTSecLTGp2zLHUX70ooEmJGIw64LDvu07V2vuScw=; b=SmvFChlF+Q30R2uEPqHxywq8tOdlhPcKhDOun/ppLlD5bg8o47tjyvqPU+wbYpgtPP 4YpCvr/NidJTqpjKuwZmm4f7bJr3wYc/EjKF3LXXHPI6S9Enj6hatdcVwyKA151yBrzb 4J69p8blFB5rUQ+cRyoiIKHgrl6Ch4WN83fxx3l0KNURNuLJsPYQ22GVZ7fLmeomcdSR +2ZSWlOewH88x5SzeD6x997yn/qR08w1f6FmlGon3L1jDUlkGGDOa9l0vgvdKWGlB2Pr 5hTzlZQD8mvyDTLZalHI6BcSffumyUhgd/dhxrUcYAZ7DTfjPWkDZpw1S5MzFpi19ss0 0ZAw== X-Gm-Message-State: AOPr4FV3lF0wvkMTW6FA2TV1uFANjmepapF/Aa8yhrTWSi7AdwduJYd9O5TK34QvAXjasP7YABzMd8BYPnOKRw== MIME-Version: 1.0 X-Received: by 10.28.224.70 with SMTP id x67mr23887085wmg.78.1463493369954; Tue, 17 May 2016 06:56:09 -0700 (PDT) Received: by 10.194.41.233 with HTTP; Tue, 17 May 2016 06:56:09 -0700 (PDT) In-Reply-To: References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> <57360A1B.2020000@article19.org> Date: Tue, 17 May 2016 14:56:09 +0100 Message-ID: From: Corinne Cath To: Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary=001a114b1ea0728e5905330a1a51 Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] HRPC draft research feedback 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, 17 May 2016 13:56:14 -0000 --001a114b1ea0728e5905330a1a51 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joe, Great note! I have replied to some of these points in another thread where I address Scott's comments. I think its titled "What test determines whether an architectural feature is a crucial ingredient for enabling the ability to exercise specific right?" Could you perhaps check if that thread already addresses some of the points you made here? Happy to further discuss, Best, Corinne On Mon, May 16, 2016 at 6:21 PM, Joseph Lorenzo Hall wrote: > On Fri, May 13, 2016 at 1:08 PM, Niels ten Oever > wrote: > > Hi Scott, > > > > Thanks for your question. The relationship that is implied (and I think > > it is in the text, if not I should definitely add it), that these > > concepts shape the enabling environment on the Internet for exercising = a > > specific right. > > > > That does not mean that we could not imagine another Internet without > > these properties where these rights could also be exercised, but in the > > current Internet we think these are the crucial ingredient for enabling > > the ability to exercise specific rights. > > > > How we came to this is described in step 5.2.1.4. Translating Human > > Rights Concept into Technical Definitions > > > > Hope this helps, and looking forward to discuss! > > > Thanks, Niels! > > So, from the text in 5.2.1.4, would you say that the bracketed list of > concepts/ingredients/properties serves as "a list of technical > concepts that when combined create an enabling environment for [a > specific] human right"? > > It would be good to make sure we've interrogated, as a group, each of > the technical concepts in the LHS of these equations. E.g., while I'm > a privacy guy to the core, I suspect something more precise like > confidentiality is the underlying technical concept? > > best, Joe > > > Niels ten Oever > > Head of Digital > > > > Article 19 > > www.article19.org > > > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > > 678B 08B5 A0F2 636D 68E9 > > > > On 05/13/2016 02:07 PM, Scott Craig wrote: > >> Hey Corrine, Niels, > >> > >> I have been reading though your recent draft > >> > >> on > >> protocol considerations. There were a couple of things I couldn=E2=80= =99t figure > >> out from the text that I was hoping you might be able to clarify. > >> > >> Firstly, what specific relationship is the visual equation (of > >> architectural features to rights) intended to imply? > >> > >> eg. ( Connectivity ) > >> > >> ( Privacy ) > >> ( Security ) =3D Right to freedom of expressio= n > >> ( Content agnosticism ) > >> ( Internationalization ) > >> ( Censorship resistance ) > >> ( Open Standards ) > >> ( Heterogeneity support ) > >> > >> > >> Is it intended to imply that no other architectural feature bears upon > >> that right? Or, i** > >> *s it intended to imply *that ALL of the > >> **** > >> listed > >> ** ** > >> architectural features MUST be present in order for the right to > >> be protected? And > >> **** > >> * > >> *If not all, then h* > >> *ow many features need not be present before a protocol can be > >> considered to abrogate a right? > >> ** > >> Secondly, w > >> hat method/principals have you used to determine which rights are > >> affected by which architectural features (technical concepts)? > >> I was expecting an explanation of this in > >> section 5.2.2 of the methodology but I can=E2=80=99t seem to find one = there or > >> elsewhere in the doc. Have I missed this somewhere? > >> * > >> > >> Many thanks, and great work! > >> > >> Scott > >> * > >> > >> *Scott Craig* | Ford-Mozilla Fellow > >> Center for Democracy & Technology |* cdt.org * > >> *E:* scraig@cdt.org | *D:* 1.202.407.8887 > >> | **@scottdavidcraig > >> > >> > >> > >> > >> _______________________________________________ > >> 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.or= g > ] > 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 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --=20 Corinne Cath 'The management of normality is hard work' --001a114b1ea0728e5905330a1a51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Great note! I have replied to some of these poi= nts in another thread where I address Scott's comments. I think its tit= led "What test determines whether an=20 architectural feature is a crucial ingredient for enabling the ability=20 to exercise specific right?"

=C2=A0Could you perhaps check if t= hat thread already addresses some of the points you made here?

Hap= py to further discuss,

Best, Corinne

On Mon, May 16, 2016 at 6:21 P= M, Joseph Lorenzo Hall <joe@cdt.org> wrote:
On Fri, May 13, 2016 at 1:08 PM, Niels ten O= ever <niels@article19.org>= wrote:
> Hi Scott,
>
> Thanks for your question. The relationship that is implied (and I thin= k
> it is in the text, if not I should definitely add it), that these
> concepts shape the enabling environment on the Internet for exercising= a
> specific right.
>
> That does not mean that we could not imagine another Internet without<= br> > these properties where these rights could also be exercised, but in th= e
> current Internet we think these are the crucial ingredient for enablin= g
> the ability to exercise specific rights.
>
> How we came to this is described in step 5.2.1.4.=C2=A0 Translating Hu= man
> Rights Concept into Technical Definitions
>
> Hope this helps, and looking forward to discuss!


Thanks, Niels!

So, from the text in 5.2.1.4, would you say that the bracketed list of
concepts/ingredients/properties serves as "a list of technical
concepts that when combined create an enabling environment for [a
specific] human right"?

It would be good to make sure we've interrogated, as a group, each of the technical concepts in the LHS of these equations. E.g., while I'm a privacy guy to the core, I suspect something more precise like
confidentiality is the underlying technical concept?

best, Joe

> Niels ten Oever
> Head of Digital
>
> Article 19
> www.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=A0 6= 78B 08B5 A0F2 636D 68E9
>
> On 05/13/2016 02:07 PM, Scott Craig wrote:
>> Hey Corrine, Niels,
>>
>> I have been reading though your recent draft
>> <https://datatracker.ietf.= org/doc/draft-tenoever-hrpc-research/>
>> <https://datatracker.ietf.= org/doc/draft-tenoever-hrpc-research/>on
>> protocol considerations. There were a couple of things I couldn=E2= =80=99t figure
>> out from the text that I was hoping you might be able to clarify.<= br> >>
>> Firstly, what specific relationship is the visual equation (of
>> architectural features to rights) intended to imply?
>>
>> eg. (=C2=A0 Connectivity )
>>
>>=C2=A0 =C2=A0 (=C2=A0 =C2=A0 =C2=A0 Privacy=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
>>=C2=A0 =C2=A0 (=C2=A0 =C2=A0 =C2=A0 Security=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)=C2=A0 =C2=A0=3D Right to freedom of exp= ression
>>=C2=A0 =C2=A0 (=C2=A0 =C2=A0 =C2=A0 Content agnosticism=C2=A0 =C2= =A0 )
>>=C2=A0 =C2=A0 (=C2=A0 =C2=A0 =C2=A0 Internationalization=C2=A0 =C2= =A0)
>>=C2=A0 =C2=A0 (=C2=A0 =C2=A0 =C2=A0 Censorship resistance=C2=A0 ) >>=C2=A0 =C2=A0 (=C2=A0 =C2=A0 =C2=A0 Open Standards=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0)
>>=C2=A0 =C2=A0 =C2=A0(=C2=A0 =C2=A0 =C2=A0Heterogeneity support ) >>
>>
>> Is it intended to imply that no other architectural feature bears = upon
>> that right? Or, i**
>> *s it intended to imply *that ALL of the
>> ****
>> listed
>> ** **
>> architectural features MUST be present in order for the right to >> be protected? And
>> ****
>> *
>> *If not all, then h*
>> *ow many features need not be present before a protocol can be
>> considered to abrogate a right?
>> **
>> Secondly, w
>> hat method/principals have you used to determine which rights are<= br> >> affected by which architectural features (technical concepts)?
>> I was expecting an explanation of this in
>> section 5.2.2 of the methodology but I can=E2=80=99t seem to find = one there or
>> elsewhere in the doc. Have I missed this somewhere?
>> *
>>
>> Many thanks, and great work!
>>
>> Scott
>> *
>>
>> *Scott Craig* | Ford-Mozilla Fellow
>> Center for Democracy & Technology |* cdt.org <https://cdt.org/>*
>> *E:* scraig@cdt.org <http://cdt.org= /> | *D:* 1.20= 2.407.8887
>> <tel:202.40= 7.8887> | **@scottdavidcraig
>>
>>
>>
>>
>> _______________________________________________
>> 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://josephha= ll.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871

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



--
Corinne Cath

'The management of = normality is hard work'

--001a114b1ea0728e5905330a1a51-- From nobody Tue May 17 07:17: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 784CB12D630 for ; Tue, 17 May 2016 07:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 MVp5QFhssEUC for ; Tue, 17 May 2016 07:17:20 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 38F3212D62B for ; Tue, 17 May 2016 07:17:20 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id n129so5153907wmn.1 for ; Tue, 17 May 2016 07:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=mRDCov9V/I9p231M3Ucz6ikQnqJ3eUe7lYIAkMNxu/I=; b=XbDAPYD7Bj8gxniuwmQPDlUUwXfT2IRjnlFXGH/ddwD3YiMULhTo8x1WV9IdSA8AcT /3UQnT52eG782OORuGThPxnDwunRs09yPnGak3+DZDXby5dILXTUhc9Qb7xa5KogDDnv fpAyrpiKNNOBpcSXVl9WzZpO/0rLpWvX4hROE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mRDCov9V/I9p231M3Ucz6ikQnqJ3eUe7lYIAkMNxu/I=; b=e+ROAvFPlyc4cWY07IndOLjylvRktKueT8vaQgHG02uygMFsJEauPw+Hk2bLg+wjRR ojUrNfM5V8FwBv3+QB7v3wGz6ZyEi4hW7r2zwpj0+H5Vf0dfxRzkUO+iBYXqj7hnjZHh Ah5rn9uE1Ta/SVz6tjH9/QKpjKfAeZ9AgmBoLK5wqDjsnll/SA7fchKWLyaMTMFgi2DG 6xVorq/ZxJoWyTpQ4sJQRkdr9P380iXpRZf9iA27jrdbeCzAWCU+qtijSFA0+I+ilgRt ulfNg0SyhK0xszNiZ7pRSb5+TwRhzPhX7ZpeRCgMG0BHb8oxduJl5tvv0QPdst9+/uO5 ZFlA== X-Gm-Message-State: AOPr4FXCiOJLUu0LHdBTg/JBqwz5b3WWXbICYTdmkP5hTp4MTYTMFf1b5dIpykQDm2xBXmZ8 X-Received: by 10.28.156.195 with SMTP id f186mr1815623wme.74.1463494634435; Tue, 17 May 2016 07:17:14 -0700 (PDT) Received: from [192.168.1.35] (host31-52-143-57.range31-52.btcentralplus.com. [31.52.143.57]) by smtp.gmail.com with ESMTPSA id r75sm24233915wme.18.2016.05.17.07.17.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 May 2016 07:17:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F2C959B2-685B-49C0-8EF5-7885427FE383" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Scott Craig In-Reply-To: Date: Tue, 17 May 2016 15:17:12 +0100 Message-Id: References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> <57360A1B.2020000@article19.org> <5FBC0A2C-1C45-4AE1-A559-C2706741FA9E@cdt.org> To: Corinne Cath X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] What test determines whether an architectural feature is a crucial ingredient for enabling the ability to exercise specific right? 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, 17 May 2016 14:17:25 -0000 --Apple-Mail=_F2C959B2-685B-49C0-8EF5-7885427FE383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Corrine,=20 That=E2=80=99s awesome, thanks for the explanation. To clarify, the aim of the test I=E2=80=99m proposing is not about = introducing any kind legal determination. Its purpose is to: (1) Set a cut-off point on the continuum you describe (above which the = effect of an architectural feature on a right can be considered to be = material) =20 (2) Constrain the authors=E2=80=99 scope of judgement (minimising = potential bias) I think the method you have described (quoted below) is great for = identifying candidate features. But my concern is that it=E2=80=99s = insufficient to determine that a candidate feature is an enabling (or = restricting) feature.=20 " It is on the basis of these various case studies, elaborate discussion = on the mailinglist and at various IETF conferences that we came to = determine whether an architectural feature is a 'crucial ingredient for = enabling the ability to exercise specific rights=E2=80=99. " If no explicit test is applied to the candidate features after = identification, I think this causes three problems: (1) Judgements are arbitrary =20 i.e there is no basis on which to argue that the threshold for inclusion = was the same for one technical concept as for another.=20 (2) Judgements are not replicable.=20 i.e it is not possible to claim that different authors would not have = come to significantly different conclusions than you have. (4) Judgements cannot be contested =20 e.g if someone were to disagree with your contention that = internationalisation has a bearing on the Right to political = participation, on what basis would we adjudicate who is correct? I would agree that the impact of a feature on a right will lie somewhere = on a continuum. And perhaps deciding not to have a cut off threshold = might actually be attractive (because it would allow us, when = convenient, to claim that any feature has a bearing on rights). However, the issue with the idea of a continuum is that there will = always be a cut of point somewhere (for what is or is not included in = the guidance). It would be much better that the point be based on some = verifiable test than be arbitrary. =20 As the time available for protocol designers to consider HR is always = going to be limited, I would argue that there is a need to demonstrate = that a feature crosses some threshold of effect in order to justify the = kind of extra consideration by protocol designers that the document = proposes. The alternative would be to accept that, since every feature could be = said to affect rights to some degree, every feature would have some = cause to be considered to some extent by a protocol designer. This would = make it much harder to argue that a protocol designer should give more = consideration to the features contained in the guidance than those not = outside it - potentially making the argument for producing such guidance = void.=20 Hope this makes sense! Scott Scott Craig | Ford-Mozilla Fellow Center for Democracy & Technology | cdt.org E: scraig@cdt.org | D: 1.202.407.8887 = | @scottdavidcraig > On 16 May 2016, at 14:49, Corinne Cath wrote: >=20 > Hi Scott, >=20 > Thanks again for your comments.=20 >=20 > Our methodology to determine whether an architectural feature is a = 'crucial ingredient for enabling the ability to exercise specific = rights' is based on several steps which you mentioned.=20 >=20 > The meta-approach of linking certain technical properties to certain = social outcomes is based on the work done by Clark (1988) who explains = the relation between the design goals and the features of the protocols. = And that of Abbate (2000) and Denardis (2013,2014) who explain how = social values, and the personal values of engineers enter into the = Internet's architecture, creating technology that elevates certain = social values.=20 >=20 > We argue that many of the technical features of the current Internet, = like the crucial features mentioned by Clark (1988) (interoperability, = redundancy, end-to-end etc), fundamentally enable human rights. In order = to establish this we have compared the different properties of human = rights to technical properties of protocols, and also gave multiple = examples of cases where the presence of certain technological features = objectively undermine or enable human rights (like injection of records, = traffic interception, XMPP). It is on the basis of these various case = studies, elaborate discussion on the mailinglist and at various IETF = conferences that we came to determine whether an architectural feature = is a 'crucial ingredient for enabling the ability to exercise specific = rights=E2=80=99.=20 >=20 > I think we might need to specify that by enabling human rights we do = not assume that if these features are present the realization of human = rights automatically follows suit. Or in other words, these features are = necessary but not sufficient. As we both know, for instance with freedom = of expression, if you have an open, accessible free Internet on a = protocol level but a government blocks access to it or filters for = certain content you do not have freedom of expression in the fullest = sense. >=20 > The approach we take suggests that the relationship between technical = properties and human rights should be approached as a continuum, where = certain technical properties allow for human rights to be enabled to = different extends. The relationship between the presence of certain = legal principles for enabling human rights on the other hand is much = more black or white.=20 >=20 > For example, the Internet can still enable freedom of expression when = there is connectivity (even though the end-users runs a greater risk = than when the technical properties of connectivity and privacy and = security are also present) but freedom of expression (as defined in the = UDHR) cannot be fully guaranteed when, for instance, people can seek and = receive information but not impart it.=20 >=20 > As such I think it would be interesting to take up your suggestion and = work out a way to use the=20 > "Highly Likely test", to define which features have what impact on = human rights. However, at the same time I am unsure if a legal test is = the best way to go about it. The potential impact of legal principles = being present or absent has a much clearer impact on for instance human = rights like freedom of expression, than does the presence or absence of = certain technical principles.=20 >=20 > I would love to hear what you think! >=20 > Best, >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, May 16, 2016 at 11:37 AM, Scott Craig > wrote: > Hi Niels,=20 >=20 > Thanks for the answer. I had another look through section 5.2.1.4. and = I couldn't find a description of the test you have applied to determine = whether an architectural feature is a 'crucial ingredient for enabling = the ability to exercise specific rights=E2=80=99 (and therefore = qualified for inclusion in the equation below.)=20 >=20 >=20 >>> eg. ( Connectivity ) >>>=20 >>> ( Privacy ) >>> ( Security ) =3D Right to freedom of = expression >>> ( Content agnosticism ) >>> ( Internationalization ) >>> ( Censorship resistance ) >>> ( Open Standards ) >>> ( Heterogeneity support ) >=20 >=20 > Say, for example, that someone were to claim that a feature (or = combination of features) that you have listed as 'shaping the enabling = environment' for freedom of expression did not do so. What criteria = would be used to assess the merits of that claim? Is there a specific = test that was applied during the creation of the second list (see = quotation below) which could be examined? (this is what I=E2=80=99ve = been trying to find). >=20 >>> Mapping the protocols and standards that are related to human rights = and create a human rights enabeling environment was the first step. For = that we needed to focus on specific technical concepts that underlie = these protocols and standards. On the basis of this list a number of = technical concepts that appeared frequently was extracted, and used to = create a second list of technical terms that, when combined, create an = enabling environment for excercising human rights on the Internet.=20 >=20 >=20 > If no test was used, then I would argue it would be highly beneficial = to develop one. A test would, I think, aid in ensuring the kind of = clear, explicit and Human Rights conscious design decisions you describe = below .=20 >=20 >> It is however important to make consicious and explicit design = decisions that take into account the human rights protocol = considerations guidelines developed below. This will ensure that the = impact protocols can have on human rights is clear and explicit, both = for developers and for users. >=20 >=20 > I'm therefore tentatively proposing two possibilities (based on UK = Judicial Review principals) for discussion: >=20 > 1. Inevitability test (The stricter standard) >=20 > An architectural feature does not impinge upon a right unless a = violation of the right in question would not be possible but for the = inclusion (or absence) of that feature acting alone or in combination = with at least one other feature.=20 >=20 >=20 > 2. Highly Likely test (The weaker standard) >=20 > An architectural feature does not impinge upon a right unless the = probability of the right in question being violated would be = substantially different as a result of the presence (or absence) of that = feature acting alone or in combination with at least one other feature >=20 >=20 > Scott >=20 >=20 > Scott Craig | Ford-Mozilla Fellow > Center for Democracy & Technology | cdt.org > E: scraig@cdt.org | D: 1.202.407.8887 = | @scottdavidcraig >=20 >=20 >=20 >> On 13 May 2016, at 18:08, Niels ten Oever > wrote: >>=20 >> Hi Scott, >>=20 >> Thanks for your question. The relationship that is implied (and I = think >> it is in the text, if not I should definitely add it), that these >> concepts shape the enabling environment on the Internet for = exercising a >> specific right. >>=20 >> That does not mean that we could not imagine another Internet without >> these properties where these rights could also be exercised, but in = the >> current Internet we think these are the crucial ingredient for = enabling >> the ability to exercise specific rights. >>=20 >> How we came to this is described in step 5.2.1.4. Translating Human >> Rights Concept into Technical Definitions >>=20 >> Hope this helps, and looking forward to discuss! >>=20 >> Best, >>=20 >> Niels >>=20 >> PS If you think this is not clear from the text, please say so (or = even >> better, create a pull request here: >> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md = ) >>=20 >>=20 >>=20 >> Niels ten Oever >> Head of Digital >>=20 >> Article 19 >> www.article19.org >>=20 >> PGP fingerprint 8D9F C567 BEE4 A431 56C4 >> 678B 08B5 A0F2 636D 68E9 >>=20 >> On 05/13/2016 02:07 PM, Scott Craig wrote: >>> Hey Corrine, Niels, >>>=20 >>> I have been reading though your recent draft >>> >=20 >>> >on >>> protocol considerations. There were a couple of things I couldn=E2=80=99= t figure >>> out from the text that I was hoping you might be able to clarify.=20 >>>=20 >>> Firstly, what specific relationship is the visual equation (of >>> architectural features to rights) intended to imply? =20 >>>=20 >>> eg. ( Connectivity ) >>>=20 >>> ( Privacy ) >>> ( Security ) =3D Right to freedom of = expression >>> ( Content agnosticism ) >>> ( Internationalization ) >>> ( Censorship resistance ) >>> ( Open Standards ) >>> ( Heterogeneity support ) >>>=20 >>>=20 >>> Is it intended to imply that no other architectural feature bears = upon >>> that right? Or, i** >>> *s it intended to imply *that ALL of the=20 >>> **** >>> listed >>> ** ** >>> architectural features MUST be present in order for the right to >>> be protected? And=20 >>> **** >>> * >>> *If not all, then h* >>> *ow many features need not be present before a protocol can be >>> considered to abrogate a right? >>> ** >>> Secondly, w >>> hat method/principals have you used to determine which rights are >>> affected by which architectural features (technical concepts)?=20 >>> I was expecting an explanation of this in=20 >>> section 5.2.2 of the methodology but I can=E2=80=99t seem to find = one there or >>> elsewhere in the doc. Have I missed this somewhere? >>> * >>>=20 >>> Many thanks, and great work! >>>=20 >>> Scott >>> * >>>=20 >>> *Scott Craig* | Ford-Mozilla Fellow >>> Center for Democracy & Technology |* cdt.org = >* >>> *E:* scraig@cdt.org > | *D:* 1.202.407.8887 >>> > | **@scottdavidcraig >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> hrpc mailing list >>> hrpc@irtf.org >>> https://www.irtf.org/mailman/listinfo/hrpc = >>>=20 >>=20 >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc = >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc = >=20 >=20 >=20 >=20 > --=20 > Corinne J.N. Cath=20 --Apple-Mail=_F2C959B2-685B-49C0-8EF5-7885427FE383 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hey Corrine, 

That=E2=80=99s awesome, thanks for the = explanation.

To clarify, the aim = of the test I=E2=80=99m proposing is not about introducing any kind = legal determination. Its purpose is to:

(1) Set a cut-off point on the continuum you describe = (above which the effect of an architectural feature on a right can be = considered to be material)  
(2) Constrain the authors=E2=80=99 scope of = judgement (minimising potential bias)

I think the method you have described = (quoted below) is great for identifying candidate = features. But my concern is that it=E2=80=99s insufficient to = determine that a candidate feature is an enabling (or restricting) = feature. 

" It is on the basis of = these various case studies, elaborate discussion on the mailinglist and = at various IETF conferences that we came to determine = whether an architectural feature is a 'crucial ingredient for = enabling the ability to exercise specific rights=E2=80=99. "

If no explicit test is applied to the = candidate features after identification, I think this causes three = problems:

(1) Judgements are arbitrary   =  
i.e there is = no basis on which to argue that the threshold for inclusion was the same = for one technical concept as for = another. 

(2) Judgements are not = replicable. 
i.e it is not possible to claim that different authors would = not have come to significantly different conclusions than you = have.

(4) Judgements cannot = be contested  
e.g if someone were to disagree with your contention that = internationalisation has a bearing on the Right to political = participation, on what basis would we adjudicate who is = correct?


I would agree that the impact of a = feature on a right will lie somewhere on a continuum. And = perhaps deciding not to have a cut off threshold might actually be = attractive (because it would allow us, when convenient, to claim that any feature has a bearing on rights).

However, = the issue with the idea of a continuum is that there will always be a = cut of point somewhere (for what is or is not included in the guidance). = It would be much better that the point be based on some verifiable test = than be arbitrary.   

As the time available for protocol = designers to consider HR is always going to be limited, I would argue = that there is a need to demonstrate that a feature crosses some = threshold of effect in order to justify the kind of extra consideration = by protocol designers that the document proposes.

The alternative would be = to accept that, since every feature could be said to affect rights to some degree, every feature would have some = cause to be considered to some extent by a = protocol designer. This would make it much harder to argue that a = protocol designer should give more consideration to the features = contained in the guidance than those not outside it - potentially making = the argument for producing such guidance void. 

Hope= this makes sense!

Scott
Scott Craig | Ford-Mozilla Fellow
Center for = Democracy & Technology | cdt.org
E: scraig@cdt.org | D: 1.202.407.8887 | @scottdavidcraig



On 16 May 2016, at 14:49, Corinne Cath <corinnecath@gmail.com> wrote:

Hi Scott,

Thanks again for your comments. =

Our methodology to determine = whether an architectural feature is a 'crucial ingredient for enabling = the ability to exercise specific rights' is based on several steps which = you mentioned.

The = meta-approach of linking certain technical properties to certain social = outcomes is based on the work done by Clark (1988) who explains the = relation between the design goals and the features of the protocols. And = that of Abbate (2000) and  Denardis (2013,2014) who explain how = social values, and the personal values of engineers enter into the = Internet's architecture, creating technology that elevates certain = social values.

We = argue that many of the technical features of the current Internet, like = the crucial features mentioned by Clark (1988) (interoperability, = redundancy, end-to-end etc), fundamentally enable human rights. In order = to establish this we have compared the different properties of human = rights to technical properties of protocols, and also gave multiple = examples of cases where the presence of certain technological features = objectively undermine or enable human rights (like injection of records, = traffic interception, XMPP). It is on the basis of these various case = studies, elaborate discussion on the mailinglist and at various IETF = conferences that we came to determine whether an architectural feature = is a 'crucial ingredient for enabling the ability to exercise specific = rights=E2=80=99.

I think we might need to = specify that by enabling human rights we do not assume that if these = features are present the realization of human rights automatically = follows suit. Or in other words, these features are necessary but not = sufficient. As we both know, for instance with freedom of expression, if = you have an open, accessible free Internet on a protocol level but a = government blocks access to it or filters for certain content you do not = have freedom of expression in the fullest sense.

The approach we take suggests that the = relationship between technical properties and human rights should be = approached as a continuum, where certain technical properties allow for = human rights to be enabled to different extends. The relationship = between the presence of certain legal principles for enabling human = rights on the other hand is much more black or white.

For example, the Internet can still enable freedom of = expression when=20 there is connectivity (even though the end-users runs a greater risk=20 than when the technical properties of connectivity and privacy and=20 security are also present) but freedom of expression (as defined in the=20= UDHR) cannot be fully guaranteed when, for instance, people can seek and receive information but not impart it.

As = such I think it would be interesting to take up your suggestion and work = out a way to use the
"Highly Likely test", to define which features have what impact on human=20= rights. However, at the same time I am unsure if a legal test is the=20 best way to go about it. The potential impact of legal principles being=20= present or absent has a much clearer impact on for instance human=20 rights like freedom of expression, than does the presence or absence of = certain technical=20 principles.

I would = love to hear what you think!

Best,





=09

On Mon, May 16, 2016 at 11:37 AM, Scott Craig = <scraig@cdt.org> wrote:
Hi = Niels, 

Thanks = for the answer. I had another look through section 5.2.1.4. and I = couldn't find a description of the test you have applied to determine = whether an architectural feature is a 'crucial ingredient for enabling = the ability to exercise specific rights=E2=80=99 (and therefore = qualified for inclusion in the equation below.) 


eg. (  Connectivity )

  (      Privacy =             &n= bsp;  )
  ( =      Security =             &n= bsp; )   =3D Right to freedom of expression
  (      Content = agnosticism    )
  ( =      Internationalization   )
  (      Censorship = resistance  )
  ( =      Open Standards =         )
   (     Heterogeneity = support )


Say, for example, that = someone were to claim that a feature (or combination of features) that = you have listed as 'shaping the enabling environment' for freedom of = expression did not do so. What criteria would be used to assess the = merits of that claim? Is there a specific test that was applied during = the creation of the second list (see quotation below) which could be = examined? (this is what I=E2=80=99ve been trying to find).

Mapping the protocols = and standards that are related to human rights and create a human rights = enabeling environment was the first step. For that we needed to focus on = specific technical concepts that underlie these protocols and =  standards. On the basis of this list a number of technical = concepts that appeared frequently was extracted, and = used to create a second list of technical terms that, when combined, = create an enabling environment for excercising human rights on the = Internet. 

If no test was used, then I would argue = it would be highly beneficial to develop one. A = test would, I think, aid in ensuring the kind of clear, explicit and = Human Rights conscious design decisions you describe below = . 

 It is however = important to make consicious and explicit design decisions that take = into account the human rights protocol considerations guidelines = developed below. This will ensure that the impact protocols can have on = human rights is clear and explicit, both for developers and for = users.


I'm therefore tentatively = proposing two possibilities (based on UK Judicial Review principals) for = discussion:

1. Inevitability test (The stricter = standard)

An = architectural feature does not impinge upon a right unless a violation = of the right in question would not be possible but for the inclusion (or absence) of = that feature acting alone or in combination with at = least one other feature. 


2. Highly Likely test (The weaker = standard)

An = architectural feature does not impinge upon a right unless the probability of the right in question being = violated would = be substantially different as a result of the presence (or = absence) of that feature acting alone or in = combination with at least one other feature


Scott


Scott = Craig | Ford-Mozilla Fellow
Center for Democracy & = Technology | cdt.org
E: scraig@cdt.org | D: 1.202.407.8887 | @scottdavidcraig



On 13 May 2016, at 18:08, Niels ten Oever <niels@article19.org> wrote:

Hi Scott,

Thanks = for your question. The relationship that is implied (and I think
it is in the text, if not I should definitely add it), that = these
concepts shape the enabling environment on the = Internet for exercising a
specific right.

That does not mean that we could not imagine another Internet = without
these properties where these rights could also be = exercised, but in the
current Internet we think these are = the crucial ingredient for enabling
the ability to = exercise specific rights.

How we came to = this is described in step 5.2.1.4.  Translating Human
Rights Concept into Technical Definitions

Hope this helps, and looking forward to discuss!

Best,

Niels

PS If you think this is not clear from the = text, please say so (or even
better, create a pull request = here:
https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md= )



Niels = ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
=             &n= bsp;     678B 08B5 A0F2 636D 68E9

On 05/13/2016 02:07 PM, Scott Craig wrote:
Hey Corrine, Niels,

I have been reading though your recent = draft
<https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/<= /a>>
<https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/<= /a>>on
protocol considerations. There were a couple of = things I couldn=E2=80=99t figure
out from the text that I = was hoping you might be able to clarify.

Firstly, what specific relationship is the visual equation = (of
architectural features to rights) intended to imply? =  

eg. (  Connectivity )

  ( =      Privacy =             &n= bsp;  )
  ( =      Security =             &n= bsp; )   =3D Right to freedom of expression
=   (      Content agnosticism =    )
  ( =      Internationalization   )
  (      Censorship = resistance  )
  ( =      Open Standards =         )
=    (     Heterogeneity support )


Is it intended to imply that no = other architectural feature bears upon
that right? Or, = i**
*s it intended to imply *that ALL of the
****
listed
** **
architectural features MUST be present in order for the right = to
be protected? And
****
*
*If not all, then h*
*ow many features need not = be present before a protocol can be
considered to abrogate = a right?
**
Secondly, w
hat = method/principals have you used to determine which rights are
affected by which architectural features (technical = concepts)?
I was expecting an explanation of this in
section 5.2.2 of the methodology but I can=E2=80=99t seem to = find one there or
elsewhere in the doc. Have I missed this = somewhere?
*

Many thanks, and = great work!

Scott
*

*Scott Craig* | Ford-Mozilla Fellow
Center for Democracy & Technology |* cdt.org <https://cdt.org/>*
*E:* scraig@cdt.org <http://cdt.org/> | *D:* 1.202.407.8887
<tel:202.407.8887> | **@scottdavidcraig




_______________________________________________
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




--
Corinne J.N. Cath =

= --Apple-Mail=_F2C959B2-685B-49C0-8EF5-7885427FE383-- From nobody Tue May 17 07:21:44 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 E291C12D644 for ; Tue, 17 May 2016 07:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 FEKlhTFt0-R2 for ; Tue, 17 May 2016 07:21:41 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 5EE8312B063 for ; Tue, 17 May 2016 07:21:41 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id a17so33994100wme.0 for ; Tue, 17 May 2016 07:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=TQpPBa2Z384Zddxy05FrMoRRG5BohGEMkT179Mrq2kQ=; b=RzL0uBiwNCFqXiSri3z/Km0yVNMKeN7QgJ857xTlrbfYGyzafBffVFpnJ5MknYqmw/ mTzHVotcjXyzVkJ6bewQtSRM0M7Kfoeyee770nM5IBSknySHbV7ofc9Ha+Osa0kRwoY2 jIOxUCpDtCYHJlh696LRw8h2osRbIfWDqeQR8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TQpPBa2Z384Zddxy05FrMoRRG5BohGEMkT179Mrq2kQ=; b=mPmdfvHRtbXA6iPyrFUXQtY7Faf0DPj0/tkK9B3Sb/1ALUl/fyshbX3vd3IzaB/lUF lRSjBj3HR/RoHs6F5Q75rvtdFZxIA/SLssTokokWnsFCeftcAtiTHap6ZhGsK4LgAy0a XO5gBQkZZ+unmdiS0FJr8U0C4RQiE3LaaF40qXUCDugww04EehpFysfqBQwc3FQk2ete cDbjRG03gtgks48uOoe2SH2PEARbcVOtKTi2MdiClm2QoVoACFoierUa+rQHcvq1FakR 9mNIf0py83Bl1k8ZkKCfiB1jJix4aPlbw9XpX5gkXiLyqWM68WCdg1sHQFjbDWLAN61D X55w== X-Gm-Message-State: AOPr4FWyY+JQEt8AvdAy3JIL7wWrijCmq2vq/EslblEoQHRSEEKD/TpfBDx4MzR6MfmoM4Ib X-Received: by 10.194.203.138 with SMTP id kq10mr1769928wjc.155.1463494899936; Tue, 17 May 2016 07:21:39 -0700 (PDT) Received: from [192.168.1.35] (host31-52-143-57.range31-52.btcentralplus.com. [31.52.143.57]) by smtp.gmail.com with ESMTPSA id v143sm24219990wmv.4.2016.05.17.07.21.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 May 2016 07:21:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A4F1A0D3-C15D-4D60-BCA2-AC019EAD5A08" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Scott Craig In-Reply-To: Date: Tue, 17 May 2016 15:21:37 +0100 Message-Id: <48B4C4AA-4009-45B7-9465-7E2E19618129@cdt.org> References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> <57360A1B.2020000@article19.org> <5FBC0A2C-1C45-4AE1-A559-C2706741FA9E@cdt.org> To: Corinne Cath X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] What test determines whether an architectural feature is a crucial ingredient for enabling the ability to exercise specific right? 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, 17 May 2016 14:21:43 -0000 --Apple-Mail=_A4F1A0D3-C15D-4D60-BCA2-AC019EAD5A08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Clarification; The final line should read 'than those outside it=E2=80=99 rather than = 'than those not outside it' Scott Craig | Ford-Mozilla Fellow Center for Democracy & Technology | cdt.org E: scraig@cdt.org | D: 1.202.407.8887 = | @scottdavidcraig > On 17 May 2016, at 15:17, Scott Craig wrote: >=20 > than those not outside it --Apple-Mail=_A4F1A0D3-C15D-4D60-BCA2-AC019EAD5A08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Clarification;

The final line should read  'than those = outside it=E2=80=99 rather than 'than = those not outside it'


Scott Craig | Ford-Mozilla Fellow
Center for = Democracy & Technology | cdt.org
E: scraig@cdt.org | D: 1.202.407.8887 | @scottdavidcraig



On 17 May 2016, at 15:17, Scott Craig <scraig@cdt.org> = wrote:

than those not outside = it

= --Apple-Mail=_A4F1A0D3-C15D-4D60-BCA2-AC019EAD5A08-- From nobody Tue May 17 14:51: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 E2E7312D1E7 for ; Tue, 17 May 2016 14:51:38 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 NH60RTl0u3Ds for ; Tue, 17 May 2016 14:51:36 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 8DF6912D52C for ; Tue, 17 May 2016 14:51:36 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s184so37899180vkb.3 for ; Tue, 17 May 2016 14:51:36 -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=/D49cEOeNx3Dj35SS2YVJ89VgIPa/tnyafbsUKNm/Ck=; b=nLmutrZ5Y1SAEofiM+K8tU0KlHVo8qvwa5cEjVRDVpSmYy1OArGgQZA8/HwCZZYumP nAXp5yoUAeDhs0tNzF31SxDF/bMpowYD4Eztrj+6ateTgFg9P0ORuTefQOTJjlvAmQYb ENYHkUWT1fmscygdhhtvwHhSlZGaKyJ/LnhW0= 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=/D49cEOeNx3Dj35SS2YVJ89VgIPa/tnyafbsUKNm/Ck=; b=dsMoOVNqcufGpsasl48pwmT3wLXR2fpyxDZ/z9+S2D3ghlUWEEDpdMvR4CQU/K0yZC w2hdc2WUoGx11XtPnZyB8wzFbtuNRyQ7rC2e+lYJ5y/I+flcjM7XuSD0TcAqtygRD4cP IO1NppGvaxIouf0Q6eUVB/jKZp+ffO21YnlgVB9mFUm4poL/hKenpICGULnRwkuqCXh8 1uQdAN/4HR6FOXQCddTVwv8gI6WF+Ocy6kbGI4j0UFFIHxyV2oBKsXBMpEZE6F5bhEAI 7/aqHjpoK9NNuK8UF4FwUmqoI+LzJX2P/f7jCT50onAnoCwse9EC+6z3/AyXWEsB5YYC aKIA== X-Gm-Message-State: AOPr4FXigzmQzi1N4pk313F0dvsB+YZgnmtk0MpMEH6Z2pAl/F5COhJMfKxkzz0+jr/RWsxe6WQUC5t4ei5rhKE6 X-Received: by 10.31.56.211 with SMTP id f202mr1971425vka.135.1463521895637; Tue, 17 May 2016 14:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.6 with HTTP; Tue, 17 May 2016 14:51:16 -0700 (PDT) In-Reply-To: References: <852BCC9D-4B8E-4F75-A83D-3037E9196396@gmail.com> <57360A1B.2020000@article19.org> From: Joseph Lorenzo Hall Date: Tue, 17 May 2016 17:51:16 -0400 Message-ID: To: Corinne Cath Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Niels ten Oever , hrpc@irtf.org Subject: Re: [hrpc] HRPC draft research feedback 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, 17 May 2016 21:51:39 -0000 Yes, I didn't want to send a "Oh, I didn't see that larger answer on the other thread". ::) On Tue, May 17, 2016 at 9:56 AM, Corinne Cath wrote: > Hi Joe, > > Great note! I have replied to some of these points in another thread wher= e I > address Scott's comments. I think its titled "What test determines whethe= r > an architectural feature is a crucial ingredient for enabling the ability= to > exercise specific right?" > > Could you perhaps check if that thread already addresses some of the poi= nts > you made here? > > Happy to further discuss, > > Best, Corinne > > On Mon, May 16, 2016 at 6:21 PM, Joseph Lorenzo Hall wrote: >> >> On Fri, May 13, 2016 at 1:08 PM, Niels ten Oever >> wrote: >> > Hi Scott, >> > >> > Thanks for your question. The relationship that is implied (and I thin= k >> > it is in the text, if not I should definitely add it), that these >> > concepts shape the enabling environment on the Internet for exercising= a >> > specific right. >> > >> > That does not mean that we could not imagine another Internet without >> > these properties where these rights could also be exercised, but in th= e >> > current Internet we think these are the crucial ingredient for enablin= g >> > the ability to exercise specific rights. >> > >> > How we came to this is described in step 5.2.1.4. Translating Human >> > Rights Concept into Technical Definitions >> > >> > Hope this helps, and looking forward to discuss! >> >> >> Thanks, Niels! >> >> So, from the text in 5.2.1.4, would you say that the bracketed list of >> concepts/ingredients/properties serves as "a list of technical >> concepts that when combined create an enabling environment for [a >> specific] human right"? >> >> It would be good to make sure we've interrogated, as a group, each of >> the technical concepts in the LHS of these equations. E.g., while I'm >> a privacy guy to the core, I suspect something more precise like >> confidentiality is the underlying technical concept? >> >> best, Joe >> >> > Niels ten Oever >> > Head of Digital >> > >> > Article 19 >> > www.article19.org >> > >> > PGP fingerprint 8D9F C567 BEE4 A431 56C4 >> > 678B 08B5 A0F2 636D 68E9 >> > >> > On 05/13/2016 02:07 PM, Scott Craig wrote: >> >> Hey Corrine, Niels, >> >> >> >> I have been reading though your recent draft >> >> >> >> on >> >> protocol considerations. There were a couple of things I couldn=E2=80= =99t >> >> figure >> >> out from the text that I was hoping you might be able to clarify. >> >> >> >> Firstly, what specific relationship is the visual equation (of >> >> architectural features to rights) intended to imply? >> >> >> >> eg. ( Connectivity ) >> >> >> >> ( Privacy ) >> >> ( Security ) =3D Right to freedom of expressi= on >> >> ( Content agnosticism ) >> >> ( Internationalization ) >> >> ( Censorship resistance ) >> >> ( Open Standards ) >> >> ( Heterogeneity support ) >> >> >> >> >> >> Is it intended to imply that no other architectural feature bears upo= n >> >> that right? Or, i** >> >> *s it intended to imply *that ALL of the >> >> **** >> >> listed >> >> ** ** >> >> architectural features MUST be present in order for the right to >> >> be protected? And >> >> **** >> >> * >> >> *If not all, then h* >> >> *ow many features need not be present before a protocol can be >> >> considered to abrogate a right? >> >> ** >> >> Secondly, w >> >> hat method/principals have you used to determine which rights are >> >> affected by which architectural features (technical concepts)? >> >> I was expecting an explanation of this in >> >> section 5.2.2 of the methodology but I can=E2=80=99t seem to find one= there or >> >> elsewhere in the doc. Have I missed this somewhere? >> >> * >> >> >> >> Many thanks, and great work! >> >> >> >> Scott >> >> * >> >> >> >> *Scott Craig* | Ford-Mozilla Fellow >> >> Center for Democracy & Technology |* cdt.org * >> >> *E:* scraig@cdt.org | *D:* 1.202.407.8887 >> >> | **@scottdavidcraig >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> hrpc mailing list >> hrpc@irtf.org >> https://www.irtf.org/mailman/listinfo/hrpc > > > > > -- > Corinne Cath > > > 'The management of normality is hard work' > --=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 From nobody Tue May 17 17:54:04 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 4B5B012D550 for ; Tue, 17 May 2016 17:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ascupenn.onmicrosoft.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 5aHEaasSp3xp for ; Tue, 17 May 2016 17:54:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7523F12D15D for ; Tue, 17 May 2016 17:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ascupenn.onmicrosoft.com; s=selector1-asc-upenn-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dcAnSPmku/5Bb7wGaJej1KhW5Catxfm0/A61WkvOfbQ=; b=ZWZigZOHalCQFYP7S8aA7mts7StUNRyAb3kISlp8J0lyEkcWactMd1aE+H1SgO5gGi0mClAamba6Eb/MVwWQxq1rprkr8JCJBVA0ualCUgv2pDO5YSNMAFakep5hHHS8DXWb9ASJYcErvO5Oeh+ZZBCueq+tE6tlahc/h4Ek+1M= Received: from BN1PR02CA0046.namprd02.prod.outlook.com (10.141.56.46) by DM2PR0201MB0781.namprd02.prod.outlook.com (10.160.95.14) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 00:53:58 +0000 Received: from BY2FFO11FD022.protection.gbl (2a01:111:f400:7c0c::118) by BN1PR02CA0046.outlook.office365.com (2a01:111:e400:2a::46) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Wed, 18 May 2016 00:53:57 +0000 Authentication-Results: spf=pass (sender IP is 128.91.58.229) smtp.mailfrom=asc.upenn.edu; cdt.org; dkim=none (message not signed) header.d=none;cdt.org; dmarc=bestguesspass action=none header.from=asc.upenn.edu; Received-SPF: Pass (protection.outlook.com: domain of asc.upenn.edu designates 128.91.58.229 as permitted sender) receiver=protection.outlook.com; client-ip=128.91.58.229; helo=exchange.asc.upenn.edu; Received: from exchange.asc.upenn.edu (128.91.58.229) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Wed, 18 May 2016 00:53:56 +0000 Received: from MB3.asc.local ([fe80::7d9f:8ade:7e16:f638]) by cashub2.asc.local ([10.30.18.102]) with mapi id 14.03.0195.001; Tue, 17 May 2016 20:53:25 -0400 From: Collin Anderson To: Joseph Lorenzo Hall , Avri Doria Thread-Topic: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 Thread-Index: AQHRr1tT1Uix7to7Hk6vsosYnVDw1p+7sQeAgABbmYCAAc+9Uw== Date: Wed, 18 May 2016 00:53:25 +0000 Message-ID: <349ADA6DBD724041A4BE91B7D08CFDC40477A3D1@MB3.asc.local> References: <57399CE7.90700@article19.org> <5739AF53.6020808@acm.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.18.254] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:128.91.58.229; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(377454003)(40784002)(199003)(24454002)(102836003)(5004730100002)(5008740100001)(561944003)(88552002)(6116002)(98436002)(3846002)(33656002)(4326007)(189998001)(8936002)(86362001)(8746002)(23746002)(92566002)(5001970100001)(5001770100001)(87936001)(2906002)(47776003)(2950100001)(230783001)(586003)(89122001)(106116001)(75432002)(106466001)(54356999)(9686002)(6806005)(15975445007)(1220700001)(3900700001)(5003600100002)(22746007)(55846006)(22756006)(104016004)(76176999)(19580395003)(19580405001)(2920100001)(2900100001)(8676002)(101616003)(50986999)(77096005)(42262002)(79686003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0201MB0781; H:exchange.asc.upenn.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:0; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD022; 1:bwiK80NS4bZRgVEm+uy0fMn2yBre0O2FoJUIUAZ5W8/p9k1XQvRHWrk+b3oWfN3STftQWlbF9ljcvw4TjsXMqnSdeJjjUobBsocLOQXueBPV7e8YKooLEJuJGjphHoX7XnT6WNCLiwcja+rM72eNRTVaUOZIBwW9234YZOzS/66TWjl/8pZ3W48LQqRJMWUMM2VZmE2wkf67eDxQDxlYmFQx3t2z4EI3+JDurMP6W2i3E7HqrylIDJJN8i1r7HA0q1w0C2v8cI2vnJAUzzrG1CYHbWMjTEJSg8w7klhj/R5eD0R2sG+MAL4DARsPaJ69aYItwPSzqKTy0/yLxrEumtdy1rr5KEPl5dj5JVqWKN0d/EZ/W6rJtqLWcRVwThzCqjuWtO4wdSd56mJ4PFgz6gHa16+Q1C0TmEXqBh2qwzYUqxBcfsqJfQMYu43MD7L9+iY9Me81B11R5xXFhzZUN+gD8ptHK/G1mdAdEHRZmwo= X-MS-Office365-Filtering-Correlation-Id: da6bb838-608f-4644-03cf-08d37eb6e488 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0781; 2:Hez+lpfkK6yTCI2kEONbCJPYBWuMb96+bEhDx7leFiVlldq+VmNVi1VtxHzNB43wrUDXhSBqVHWJAeEGJLZMhO8DTuK9MA7Jlu98bEwdvdmoxgn9t+ckN7cWfi2Li/UlgfPWCUC5tkad1JXimbVBMsbh+SXIu7jOVnYODq7JD1BbQNveahCyMvEDzhrI3kFI; 3:7CU4GSLXc9V602q/dFl1GTgwlYEBRh70venwGjWpHCc1HH6ImeKx9ct+HkwqMFTgirc2MRcrO7uDT4CA2/vsdLYZ9WVtzOWiY4/kYtgGa9ez1mIXsecW/sdkmBBrhIeNFkF40gSaLsr/Ldg5ZLI3jVtj9SN22zV0R2bif7po5KPfYS9ChHGG6sUVeFCwohx5xUXCnPifaqSH3IHeeffvuSr8HXtbxCFw/O3D9KdaTW8wQtBvaZw70kCBVEU//+c4j4QXLXiz85aFelQf/nsCbw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:DM2PR0201MB0781; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0781; 25:qhOagQUZ0GpMfiOAxZX/SlGafxjKXn6Se1NQSoQj+rsyffaefVvMnb7SQStRt9Ah+nNZ5JCGebDckk7KmbIpA8Mu8Jn/GmQZoJIeJw84xcyfouVPbt3GQGjJFtDlQLyerH/xnRxUMnGOdI9RMXmnbHCYT+imTJHHlj7aoU/1tEwCvWKuElXKXRRaYAa/nu6W/kdJtx5TMqBqQAjPK9h9USjN/tiHCCrmPhmnhL7aR3ndjcBi73ua0SNB9O0jJccfeAiAvgpoSsokBCQgcpB96V+7Rh3aPM86o/Cc3/aEQ3o2kihLp2cHrEHytgGBWENVjau1XMIYAkkYGpYUuuH4mPpu3DEhhrH1UXKv9Khf/HWiOmVHHOJ4Qu49jaZGKXw6oQED4txUTZjVVcde5IOiZ4pKjWGTv8HK9H6y2uJCg9E6PEZWRneL8b4t+HCMRvxK9q+66l6xNnnjE6rKrUpmXGGcjZ+RVytefHfToEYnIr6u5N2+vh9tPTVSXAQBXveS7OZFnw8bZIN7288CVH71wDbGuDZAoNzhm5vShsx9teOInRWfnl79/tVMhHLybdcAoSpKm5CwuV/NgyLO1u4Lr9he2VHnA3UvIKUZVLwaAzjdLa//802L/2uNKXnaYwSyzC5E7aJhul3FlKy8itsM6INaDK4e7iHmzWltpKqnmho9pg5pBbkbp4ICyTYlihg58LTQKq38mqOJR1u3DPbwaeh2z1GyH1z95G/rZzGdycl4VuRZQUlq5X3eGwfzVBGpP4GzaJOPYPYovyNyNw1BPGA3qPSgW5K9eLpD5dfZeSJ845xFrbYucD904IREADxJIJuAS78aYl3/1uRCtNhPrJYiCFDM59ax4zzIKMSRlav40Q8UPr+7yYKxBm4qe2ZG X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0781; 20:0n7j8zu3KPDgb44CMwr4WbkR+zhysSNFWPnuZfp8VrYOzGvoKalaOQNZv5QYN/IAXEKqZZmvn/+bFBpoVQOPxqyjM95h6KagwELKaWiUb9J2XTfii+9aQg4YLZNgYcM45f07lsMhAlitKLNNY8sPDErwE51X55dej0yrtxfD+XE6fdm3DJ/vXuMUFfbFJ0Mh83DcjM/IaMxmqyldsj5+vd3y1ScPqrGoFvGZRZFQjVPst90/shrJOjsRI86lZFiTs0xaHFxUzek4mDk1Yr3qDLhbQKRhrzK6dPyZOG2k2HeP290y1sH8VtrUjYaZKL5RTF8/Pcs7a8x8ng22ks4k7pUU8IJB5h433XILQW657j+18cvPDBxzR5hXYrJ7Mz5TrkL2rq8T1xjDDXHzMVyB205gvycexQ/E/xpe/2eEzwAqyZR987ykFFxxg7TONoJov1MZ8wbEMnFtZUfasfeTWdRCpRsLhrhCIoBuinmR7xUZa3bMeRyLDFsn1aqAdEvh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(13024025)(13015025)(13017025)(13018025)(5005006)(8121501046)(3002001)(10201501046); SRVR:DM2PR0201MB0781; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0781; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0781; 4:3Vy+T539uYiV9fEo6jHS7OJGuxy4x7eMbR12vgLPZcm6O6NEpXH36ibH4dykgA3Wj4KizLqtIy6zLOY8AHPknNp3tOQ1SM84Xn9R2u383N9+1KyXDxiEypOgNN9hQozknIWvp+csf2ulZxKoHHfF06/TX9Xpte6/7FZ70MmaoI+5v9VIo2TmVb2oeJOyKuAlUJk7KJZ0/OmkwQ4R3JM17AL3JNeqY9aNa6Oiu67PjUsyFNr8Qqc092Zycdbwn1gCb9B853hyrbLfwr1/etBIzXaPNm9AU2xWtSNGoi+Bov1XlCirconv3QEUbeyUbIMjap6DrwcADFns791MKw1togo/Qnn/LXqdfTlRkBVX0IVtjXpaGmQMK0RjxbP6h03hzPG9TmddNrlqV20lo5I00jsOKCTg0e8EnPTDaJkkRIxzxOBOvvxdhcpk4o+kuDtLEbX0P0NECwdNyBPGuS2QIQ== X-Forefront-PRVS: 0946DC87A1 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM2PR0201MB0781; 23:CXELwmDExjPSy5ZTKl1qk+NNIiYMkf523W5?= =?Windows-1252?Q?MG3BHhvfWAKpNW/ERIkrK0jATkAS5WjDTnIeFog39YoMhGJLyOIjg6A4?= =?Windows-1252?Q?8QkLRApeCclBt8ZGBp1kukjU5BpRHUNI2QcCI0VLRzjy1SMETStEucJF?= =?Windows-1252?Q?fkGpKwo5lpRGMA14WgxIBhE3srD5v2qikA4lo4BvElhfQCna2oMJK6xY?= =?Windows-1252?Q?+L1xvsn4fWC+5BanOy1gPLqxja/TPswfyvI6GXW7AyCwBkZspjkedn68?= =?Windows-1252?Q?u6Pp43tiZHt1JxBKWdGiRfMWYTu+0q5febuxrpVWn/xchhLWxo4xVM3p?= =?Windows-1252?Q?n+b7dGpPMaH10JuwAtLx8jGKr6iOMeezyqH8I0MBveg+xIon4pOJgqSi?= =?Windows-1252?Q?naJEI5wGeB0COLxGFwRCPusmjNuh2j2TQJqH0blNuB7NCmg8B/faefZN?= =?Windows-1252?Q?CEbQeSKvT/XHvylY1cUZPgSYmX1LMYWDIZXXnube0GfEC+ZJgrgf0NQX?= =?Windows-1252?Q?+YpyPbtHDSdRWd2Sj0MYRLh70K8b0PjzFfCb2UkuAFoRh3NFq4A92D1x?= =?Windows-1252?Q?oTvTKDiAvYO+U4I7GDm1V6+V+ekSNLg2TFnfGsDXG5URuzKkGJp9VolX?= =?Windows-1252?Q?3SRX5yAYHI9pba33Pk+T9hwl9Et6ssslQbXK7OcW2eYdTe57NkTY84yL?= =?Windows-1252?Q?ILaAaftbpz2UWQzT6v7Y+mBYBBgbqy3lS/bvcd/5Z/JhoeSWmVqISVp2?= =?Windows-1252?Q?eNgIIHqUIbodEifgP03YuEkqq6eHuxF8myTOpV4JBWMJUXslXGvIgQzp?= =?Windows-1252?Q?fvUS2P0URSafg3Gf8ToOBIdGrYbCEYQVhVQyPYBgqFb53tJRdcpilPI0?= =?Windows-1252?Q?JKFCKbMIFLU3ewHLebS1gNHDYRRFg4q27TH6MpbhDF1QUnbKloQ/yoav?= =?Windows-1252?Q?1IXWXDXNP7SMzzdZHS7pK48xzg6ZQkeO+MpFjcSoE9bpyNFGpuhhBAIG?= =?Windows-1252?Q?4Z0h5rLaZBIgUWnzDc5cTrdpxTkK4z6NgcIR1LrHPBVdf3lbm3Oq9kFD?= =?Windows-1252?Q?B/r2jjc7iXu/DnU1B291sBEqqGfDjHcafMizgWAAfbE1gFJUtJVEHgZY?= =?Windows-1252?Q?yR2KwMjNSTkrn/YCb9495dI08grASNWeOp7PBCqUu2DMX1h0aqKCZW8m?= =?Windows-1252?Q?mcxXfH4bQYfJsplvPn+lM1x5rT1cNlpY007xYcyhp8h0cdKu2/Gptqhl?= =?Windows-1252?Q?YG0sfi6p43MPDF3g4cmVcz0l5dkeP3RnirLrC45oA+tdzpCO1P7qHTVn?= =?Windows-1252?Q?UEXCh5y1bq7PlZdrDG9LnhJ+bGr2u8/WTdkNdyiytxM5tgKubE8iYLXx?= =?Windows-1252?Q?OCXcNnJ6JZuX2GAZqAGSM+MgZ2fnv4mbxQhbZPosOpQWABetZJtInc7v?= =?Windows-1252?Q?w0xvCz0jEZv8Ee7RNMtl8BDiZ+wXxV177HVDjheVqZhpAGg+msgQuMpd?= =?Windows-1252?Q?3OprEh0y8/w1Btbb1GFxYkMcmB2yGppNzeQ0NsW0mEZqK1bB5o5iMlye?= =?Windows-1252?Q?9/KVtuGj5LdsIBMRbm24X6RYAAVB4zuuk3krN?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0781; 5:1nenFxUX9Ec0oYlrn6cbukNp5J5UWorzFShNAxPreONzHGb7iybJ82x9Mm/8ILRHiLlNizIluRIg1kvuQKl3AlHi2BR5PPToaxPw7Gv+vctA+bOgGz38QGzLN6kXypayiuSh6Qe+OT3OUTUuSR60ZA==; 24:HHlthQ2UDlGRCdtibMG78B6JfvbuDxF0Q2TVYDbuXIyhm6ia60/RAEj8ie3qI+H3EJ/hkVZUdUhe25hN4PD0I3/JRE+UWw1Uc11P444XaaU=; 7:GSIaqFuHu8wi1mM90xg952LXd0yEfXvwnlNseGqMOLopoJhTMD1VfK+mWSBu4stgDybz21Ud7Op79jRbhYoC4sI7Obt+IdIwRPO6cRTuOKOmMe1G4MmldMw9KXEn8txcH4kN6Lfn1Dz/uTqjr5cgmMKpi1WFwiqtjXfwakswFUhSFmS5l8e1USeztJvcN71P SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: asc.upenn.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2016 00:53:56.8894 (UTC) X-MS-Exchange-CrossTenant-Id: c4c10fc3-fa47-4237-865d-872eb0388a0c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c4c10fc3-fa47-4237-865d-872eb0388a0c; Ip=[128.91.58.229]; Helo=[exchange.asc.upenn.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0781 Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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: Wed, 18 May 2016 00:54:03 -0000 Hi avri, > I would also like to hear about others who are interested in working on > this draft, as becoming an RG draft means moving it more into the main > work stream of the RG and getting greater input that just the authors > and a few commenters. I might not be your ideal base for this request since I have solely lurked = on this list from early on, out of professional interest as a network resea= rcher, and since I have not previously been involved in the IRTF process. H= owever, I would be willing to provide sustained feedback and comment from t= hat position of independence from the process thus far, and have a meaningf= ul history of research and publication on the underlying mechanisms associa= ted with the proposal =96 although I suspect that anything that Mr. Bortzme= yer is involved in will be quite technically solid in that respect. If anyt= hing, from my current read, the draft requires a bit of copyediting and som= e further degree of interrogation in order ensure clarity and to extend the= premise in certain areas, but I think those are a product of the document'= s ambition and not a sign of immaturity.=20 So, I would be happy to provide outside assistance and critiques based on m= y professional and research involvements for the document proposed for adop= tion as RG draft.=20 Cordially, Collin Anderson cda.io ________________________________________ From: hrpc [hrpc-bounces@irtf.org] on behalf of Joseph Lorenzo Hall [joe@cd= t.org] Sent: Monday, May 16, 2016 12:58 PM To: Avri Doria Cc: hrpc@irtf.org Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 Hmm, I'm not sure why this would be premature, Avri. It seems like a core document this group would work on in addition to methodology and glossary. We have a large quantity of comments on this draft (working with our fellow, Scott Craig) that we'll be sharing in coming weeks. We support adoption. best, Joe On Mon, May 16, 2016 at 7:30 AM, avri doria wrote: > Hi, > > I personally think it might be premature for this call, but since it has > been made, would like to know of people who read this draft and think > that it is something that is ready to become a RG draft. > > Is anyone willing to review this with a light to making a recommendation > on whether it should be a RG work item? Would like to get some deeper > opinion on the draft and its contents, especially from an engineering > perspective. > > I would also like to hear about others who are interested in working on > this draft, as becoming an RG draft means moving it more into the main > work stream of the RG and getting greater input that just the authors > and a few commenters. > > I have not had a chance to read it yet, but will do so as soon as I can. > > avri > > > On 16-May-16 06:11, Niels ten Oever wrote: >> Dear RG, >> >> >> >> This email serves as a call for RG adoption of >> draft-tenoever-hrpc-research-02 [0] as a RG document. The call for >> adoption will run for 2 weeks ending 5/30/2016. >> >> >> >> Several of your might have thought this document was already an RG >> document, but since it was never formally adopted we thought it might be >> a good idea to do that now (even though this is not strictly a >> requirement for this in the IRTF, but for the sake of clarity and >> transparency we'll follow the IETF procedure as decribed in RFC7221). >> >> >> >> Please note that this is a call for adoption, and not a last call for >> content of the document. Adopting a RG document simply means that the RG >> will focus its efforts on that particular draft going forward, and use >> that document for resolving open issues and documenting the RG=92s decis= ions. >> >> >> >> Please indicate whether you support adoption or not, and if not why. >> Issues you have with the current document itself can also be raised, but >> they should be raised in the context of what should be changed in the >> document going forward, rather than a pre-condition for adoption. >> >> >> >> Looking forward to hear your opinions. >> >> >> >> All the best, >> >> >> >> Niels >> >> >> >> [0] https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 >> >> >> >> _______________________________________________ >> 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 _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc= From nobody Fri May 20 07:06:23 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 4E0FE12D988 for ; Fri, 20 May 2016 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 F6_U50UuhgYo for ; Fri, 20 May 2016 07:06:19 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 9FADF12D98C for ; Fri, 20 May 2016 07:06:18 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n129so273595724wmn.1 for ; Fri, 20 May 2016 07:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YP43eFfmGjJwyX5aWWu6/H66PtyO9SUq7gd8CU3IqG0=; b=F8qOCpzYI77m+H+FEEReL+KEqEDOYDBof4DMiR+E5S6F7DRW7jNkI8EL0nVEoiaP6X ni7apZeLE6NX5tDXLyi7TTcvf1IpOW//bsDZ5Br1wlw3F6MD/5WZWJVssH/oS12gceXe hEIisxprvGOZg8n2APvz88mhl+OGLEWclakHJY/gsFMi815GrKLzARyfDlVQ4he7l8gk E+w3LJprwdxxlGc8qDm1FI/G2lokOHQE5lFabQBvN9UuvE7aJQmXi0uWnyA/ujFNu/gc GTGkU0Jj/aRNGZULQwvN8hEYjGgpimQpXd6/p4VBl0fGCAhTnJmaHRYFe2TzM7WC/6Ts XeYA== 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:date :message-id:subject:from:to:cc; bh=YP43eFfmGjJwyX5aWWu6/H66PtyO9SUq7gd8CU3IqG0=; b=ZTXkbtgl/LkiyPiInsKS3XK8YOCzIsd+Yva0Oqmhiw8+OzRQbDp6ZZXyKtTliW9ekD sf+47WdP+lhftMkmWb2Cm6LZu8F70PWxvQ79QXg3SKjx0b+QrI5aktJp4T01z/DGgoAO O/hFZOoqwnwfMUHCNyVlJl/7uY5/jGNPsNI7n25+BQz6Lv6E+o75qUwyUDXWUCdnZgfJ vzpO507a4jW/jtGO9hW7vhMAohuCGbIsMriyR7YVom+tOzVRNA3C18CLm+PBCNtPvK6M S0YU6Cff9/QBHRQon90X+aSL2Ciwk1ulBcI1qik+fIEI/v7vPMw7G1lDKqJa8WPS8MYQ UQHw== X-Gm-Message-State: AOPr4FWBWZIoctMhAQ2Y48degtmgggzqwZUXwGZ6oiww27qD6Lzz+hcLpgwU9RZa3DfAvTXSr9zRA8+7blmrQg== MIME-Version: 1.0 X-Received: by 10.28.113.67 with SMTP id m64mr3039816wmc.3.1463753177006; Fri, 20 May 2016 07:06:17 -0700 (PDT) Received: by 10.194.41.233 with HTTP; Fri, 20 May 2016 07:06:16 -0700 (PDT) In-Reply-To: <571DFE36.1090704@kit.edu> References: <571DFE36.1090704@kit.edu> Date: Fri, 20 May 2016 15:06:16 +0100 Message-ID: From: Corinne Cath To: "Bless, Roland (TM)" Content-Type: multipart/alternative; boundary=001a1147dab0278d89053346986f Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] =?utf-8?q?Values_and_Networks_=E2=80=93_Steps_Toward_Explo?= =?utf-8?q?ring_their_Relationships?= 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, 20 May 2016 14:06:22 -0000 --001a1147dab0278d89053346986f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Roland, I hope this email find you well. Thank you for sharing this paper it is very interesting. Upon reading it I had the following questions: - Do you believe that it might be interesting to also include the Ruggie principles in your discussion of human rights in paragraph 2.1? - "However, unlike physical measurements the theoretical knowledge required for establishing valid quantified measurements of moral values in general [22] and values of human rights in particular does not exist =E2=80=8B." =E2=80=8BAlthough I agree that it is difficult to establish qua= ntifiers for measuring moral values there exist legal tests to quantify if certain human rights standards are being met, which you yourself reference in the paper. As such the sentence above reads a little confusing, could you clarify what you mean? - Do you believe it is really unknown what values lie behind protocols? I think Denardis, Abbate and several others have done a decent job describing that both the social, ethical values of individual engineers and the commercial values of the companies they work become reflected in the technology they design. - "Although the juridical legitimacy of the IETF to enforce human rights by technical means might be questionable [4], rationales for responsibility of the IETF may stem from Art. 28 UDHR providing the right to an international or- der in which human rights can be realized. This claim is directed to global institutional actors [29]. In governance ar- eas where governments are absent or play a minor role, this claim affects the de facto governing actors, i.e., the IET." This is an interesting line of argumentation, do you plan to expand on it in your research? - In your conclusion you cover a lot of very relevant and broader questions, I was wondering if you have considered adding a short bit about the tension that exist in the debate on human rights and to what extend they are universal, and more particularly who gets to decide which values will be realized through protocols and why. Overall it is a great article, it really lays out the issues in structured and succinct way. Great to see the work of the HRPC group mentioned as well= . I was wondering what the time line is for you moving forward on this research= ? Best, Corinne On Mon, Apr 25, 2016 at 12:23 PM, Bless, Roland (TM) wrote: > Hi, > > as already announced, here is the pointer to the above article > (freely available): > http://www.sigcomm.org/ccr/papers/2016/April/0000000.0000003 > > The editor wrote: > > The second editorial, =E2=80=9CTowards Considering Relationships betwee= n Values > > and Networks=E2=80=9D looks at the interactions between human rights an= d the > > technology that we develop. It reminds us that when we decide to carry > > out research on a given topic, our research results may have a broader > > impact than simply a series of papers published in conference > > proceedings, journals or online libraries. Some of our work can > > influence, in one direction or another, the evolution of our society an= d > > some of our design choices may have a huge impact in the long term. I > > encourage you to read this editorial and then take some time to think > > about your ongoing work and the impact that it could have on values suc= h > > as human rights. > > PDF: > > http://www.sigcomm.org/sites/default/files/ccr/papers/2016/April/0000000-= 0000003.pdf > > Feedback appreciated :-) > > Regards, > Roland > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --=20 Corinne Cath 'The management of normality is hard work' --001a1147dab0278d89053346986f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Roland,

I hope this email find you well.

<= /div>
Thank you for sharing this paper it is very interest= ing. Upon reading it I had the following questions:

- Do you believe that it might be interesting to also= include the Ruggie principles in your discussion of human rights in paragr= aph 2.1?

- "However= , unlike physical measurements the theoretical knowledge required for estab= lishing valid quantified measurements of moral values in general [22] and values of human rights in particular does not exist
=E2=80=8B.&q= uot; =E2=80=8BAlthough I agree that it is difficult to establish quantifier= s for measuring moral values there exist legal tests to quantify if certain= human rights standards are being met, which you yourself reference in the = paper. As such the sentence above reads a little confusing, could you clari= fy what you mean?

- Do you=20 believe it is really unknown what values lie behind protocols? I think=20 Denardis, Abbate and several others have done a decent job describing=20 that both the social, ethical values of individual engineers and the commer= cial values of the companies they work become reflected in the technology they = design.=C2=A0

-=C2=A0 "Although the juridic= al legitimacy of the IETF to enforce human rights by technical means might be questionable [4], rationales for responsibility of the IETF may stem from Art. 28 UDHR providing the right to an international or- der in which human rights can be realized. This claim is directed to global institutional actors [29]. In governance ar- eas where governments are absent or play a minor role, this claim affects the de facto governing actors, i.e., the IET.&qu= ot;
This is an interesting line of argumentation, do you p= lan to expand on it in your research?

<= /span>
- I= n your conclusion you cover a lot of very relevant and broader questions, I= was wondering if you have considered adding a short bit about the tension = that exist in the debate on human rights and to what extend they are univer= sal, and more particularly who gets to decide which values will be realized= through protocols and why.

 =09 =09 Overall it = is a great article, it really lays out the issues in structured and succinc= t way. Great to see the work of the HRPC group mentioned as well. I was wondering what the time line is for you moving forward on this r= esearch?

Best,

Corinne

On Mon, Apr 25, 20= 16 at 12:23 PM, Bless, Roland (TM) <roland.bless@kit.edu>= wrote:
= Hi,
as already announced, here is the pointer to the above article
(freely available):
 http://www.sigcomm.org/ccr/papers/2016/April/000000= 0.0000003
The editor wrote:
> The second editorial, =E2=80=9CTowards Considering Relationships betwe= en Values
> and Networks=E2=80=9D looks at the interactions between human rights a= nd the
> technology that we develop. It reminds us that when we decide to carry=
> out research on a given topic, our research results may have a broader=
> impact than simply a series of papers published in conference
> proceedings, journals or online libraries. Some of our work can
> influence, in one direction or another, the evolution of our society a= nd
> some of our design choices may have a huge impact in the long term. I<= br> > encourage you to read this editorial and then take some time to think<= br> > about your ongoing work and the impact that it could have on values su= ch
> as human rights.
PDF:
 http://www.sigcomm.org/site= s/default/files/ccr/papers/2016/April/0000000-0000003.pdf
Feedback appreciated :-)
Regards,
=C2=A0Roland
_______________________________________________
hrpc mailing list
 hrpc@irtf.org
 https://www.irtf.org/mailman/listinfo/hrpc



--
Corinne Cath
=
=

'The management of normality is hard work'

--001a1147dab0278d89053346986f-- From nobody Fri May 20 19:32:40 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 C356112D105 for ; Fri, 20 May 2016 19:32:38 -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 ByW2LUgR8CjP for ; Fri, 20 May 2016 19:32:36 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D90412D0BE for ; Fri, 20 May 2016 19:32:36 -0700 (PDT) Received: from filter.hostedemail.com (unknown [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 4286729DD77; Sat, 21 May 2016 02:32:35 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, avri@acm.org, :::, RULES_HIT:2:41:355:379:599:800:854:960:967:969:973:988:989:1042:1260:1261:1277:1311:1313:1314:1345:1359:1431:1437:1515:1516:1518:1535:1593:1594:1605:1606:1683:1730:1747:1777:1792:2194:2198:2199:2200:2380:2393:2525:2551:2553:2568:2629:2682:2685:2693:2731:2743:2859:2903:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3673:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4117:4184:4250:4321:4362:4425:4860:5007:6117:6119:6238:7576:7652:7809:7861:7901:7903:7904:8660:8666:8985:9010:9025:9036:9108:9121:9545:9704:10004:10848:11232:11233:11473:11658:11914:12043:12050:12109:12114:12291:12379:12438:12517:12519:12555:12663:12683:12740:12926:13018:13019:13148:13151:13228:13230:13436:13846:13894:21060:21080:21094:21212:21324:21326:21366:21433:30022:30054:30060:30090:30091, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fp, MSBL X-HE-Tag: cap41_8acf24079b25b X-Filterd-Recvd-Size: 6466 Received: from [127.0.0.1] (unknown [23.106.43.243]) (Authenticated sender: avri@doria.org) by omf03.hostedemail.com (Postfix) with ESMTPA; Sat, 21 May 2016 02:32:33 +0000 (UTC) References: <57399CE7.90700@article19.org> <5739AF53.6020808@acm.org> <349ADA6DBD724041A4BE91B7D08CFDC40477A3D1@MB3.asc.local> To: cda@asc.upenn.edu From: avri doria Message-ID: Date: Fri, 20 May 2016 22:31:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <349ADA6DBD724041A4BE91B7D08CFDC40477A3D1@MB3.asc.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 160520-7, 05/20/2016), Outbound message X-Antivirus-Status: Clean Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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, 21 May 2016 02:32:39 -0000 Hi, Thanks I appreciate it. avri On 17-May-16 20:53, Collin Anderson wrote: > Hi avri, > >> I would also like to hear about others who are interested in working on >> this draft, as becoming an RG draft means moving it more into the main >> work stream of the RG and getting greater input that just the authors >> and a few commenters. > I might not be your ideal base for this request since I have solely lurked on this list from early on, out of professional interest as a network researcher, and since I have not previously been involved in the IRTF process. However, I would be willing to provide sustained feedback and comment from that position of independence from the process thus far, and have a meaningful history of research and publication on the underlying mechanisms associated with the proposal although I suspect that anything that Mr. Bortzmeyer is involved in will be quite technically solid in that respect. If anything, from my current read, the draft requires a bit of copyediting and some further degree of interrogation in order ensure clarity and to extend the premise in certain areas, but I think those are a product of the document's ambition and not a sign of immaturity. > > So, I would be happy to provide outside assistance and critiques based on my professional and research involvements for the document proposed for adoption as RG draft. > > Cordially, > Collin Anderson > > cda.io > > ________________________________________ > From: hrpc [hrpc-bounces@irtf.org] on behalf of Joseph Lorenzo Hall [joe@cdt.org] > Sent: Monday, May 16, 2016 12:58 PM > To: Avri Doria > Cc: hrpc@irtf.org > Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 > > Hmm, I'm not sure why this would be premature, Avri. It seems like a > core document this group would work on in addition to methodology and > glossary. > > We have a large quantity of comments on this draft (working with our > fellow, Scott Craig) that we'll be sharing in coming weeks. > > We support adoption. best, Joe > > On Mon, May 16, 2016 at 7:30 AM, avri doria wrote: >> Hi, >> >> I personally think it might be premature for this call, but since it has >> been made, would like to know of people who read this draft and think >> that it is something that is ready to become a RG draft. >> >> Is anyone willing to review this with a light to making a recommendation >> on whether it should be a RG work item? Would like to get some deeper >> opinion on the draft and its contents, especially from an engineering >> perspective. >> >> I would also like to hear about others who are interested in working on >> this draft, as becoming an RG draft means moving it more into the main >> work stream of the RG and getting greater input that just the authors >> and a few commenters. >> >> I have not had a chance to read it yet, but will do so as soon as I can. >> >> avri >> >> >> On 16-May-16 06:11, Niels ten Oever wrote: >>> Dear RG, >>> >>> >>> >>> This email serves as a call for RG adoption of >>> draft-tenoever-hrpc-research-02 [0] as a RG document. The call for >>> adoption will run for 2 weeks ending 5/30/2016. >>> >>> >>> >>> Several of your might have thought this document was already an RG >>> document, but since it was never formally adopted we thought it might be >>> a good idea to do that now (even though this is not strictly a >>> requirement for this in the IRTF, but for the sake of clarity and >>> transparency we'll follow the IETF procedure as decribed in RFC7221). >>> >>> >>> >>> Please note that this is a call for adoption, and not a last call for >>> content of the document. Adopting a RG document simply means that the RG >>> will focus its efforts on that particular draft going forward, and use >>> that document for resolving open issues and documenting the RGs decisions. >>> >>> >>> >>> Please indicate whether you support adoption or not, and if not why. >>> Issues you have with the current document itself can also be raised, but >>> they should be raised in the context of what should be changed in the >>> document going forward, rather than a pre-condition for adoption. >>> >>> >>> >>> Looking forward to hear your opinions. >>> >>> >>> >>> All the best, >>> >>> >>> >>> Niels >>> >>> >>> >>> [0] https://tools.ietf.org/html/draft-tenoever-hrpc-research-02 >>> >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From nobody Sun May 22 09:36:53 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 7D37312D12F for ; Sun, 22 May 2016 09:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 jZOcd3xdomIL for ; Sun, 22 May 2016 09:36:48 -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 6B1F512D13A for ; Sun, 22 May 2016 09:36:48 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 4D6EB28015E for ; Sun, 22 May 2016 18:36:46 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 494E5280145 for ; Sun, 22 May 2016 18:36:46 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 3CF134C002C for ; Sun, 22 May 2016 18:36:16 +0200 (CEST) Date: Sun, 22 May 2016 18:36:16 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160522163616.GB10729@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.3.0-1-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [hrpc] "many countries and activist corporations use human rights commitments as vehicles to limit individual's freedom of speech " 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, 22 May 2016 16:36:51 -0000 http://www.circleid.com/pdf/cruz-letter-20160519_ICANNLetter.pdf Yes, stop this stupid "human rights "thing. From nobody Sun May 22 10:18:11 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 2AA5012D10B for ; Sun, 22 May 2016 10:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3ykqZyMrkwDg for ; Sun, 22 May 2016 10:18:10 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 E8D7912D0F5 for ; Sun, 22 May 2016 10:18:09 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id C58CA31C98; Sun, 22 May 2016 19:18:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 37753190819; Sun, 22 May 2016 19:15:33 +0200 (CEST) Date: Sun, 22 May 2016 19:15:33 +0200 From: Stephane Bortzmeyer To: Niels ten Oever Message-ID: <20160522171533.GA10885@sources.org> References: <57399CE7.90700@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57399CE7.90700@article19.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.4 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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, 22 May 2016 17:18:11 -0000 On Mon, May 16, 2016 at 12:11:51PM +0200, Niels ten Oever wrote a message of 101 lines which said: > This email serves as a call for RG adoption of > draft-tenoever-hrpc-research-02 [0] as a RG document. The call for > adoption will run for 2 weeks ending 5/30/2016. I followed the group from the start (even if I did not participate) and I've read this draft (seriousy, I believe). I support the adoption by the RG. It is both useful and well-written (frankly, because of the novelty and difficulty of the project, I was skeptical at the beginning). I hope I will be able to act as a reviewer/etc. I do not say I fully agree with the current version. For instance, what is written about mobility and multicasting is [censored by myself because my son, looking over my shoulder, tells me I'm too harsh]. Some details: * is it really useful to mention Netmundial? Is it something else than one of the many diplomatic meetings of the governance circus? * there are still some self-contradiction in the draft. For instance, 5.2.4 starts by saying that, unlike ccTLD, .com does not impose limits on free speech and, later on, 5.2.4.1 rightly notes that .com is NOT floating above governments and states, it is a USA ccTLD. From nobody Mon May 23 08:42:48 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 EC49F12D9AE for ; Mon, 23 May 2016 08:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 SVyy7ByTNQQ9 for ; Mon, 23 May 2016 08:42:45 -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 2F75212D99B for ; Mon, 23 May 2016 08:42:44 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 3938B2659452 for ; Mon, 23 May 2016 15:42:43 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 2A36D642107F for ; Mon, 23 May 2016 15:42:43 +0000 (UTC) Received: from [10.208.143.90] (host33-93-static.62-79-b.business.telecomitalia.it [79.62.93.33]) by mail.article19.io (Postfix) with ESMTPSA id A0D542659452 for ; Mon, 23 May 2016 15:42:42 +0000 (UTC) Date: Mon, 23 May 2016 17:42:43 +0200 From: Niels ten Oever To: hrpc@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: <20160523154242.A0D542659452@mail.article19.io> Archived-At: Subject: [hrpc] Relevant in relation to nondiscrimination 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, 23 May 2016 15:42:47 -0000 RXZlbiB0aG91Z2ggaXQgdGFrZXMgcGxhY2Ugb24gYW5vdGhlciBsYXllciwgdGhpcyBtaWdodCBi ZSByZWxldmFudCBmb3IgdXM6CgpQcm9QdWJsaWNhIChAUHJvUHVibGljYSkgdHdlZXRlZCBhdCAy OjMwIHAubS4gb24gTW9uLCBNYXkgMjMsIDIwMTY6CkhlcmUncyB0aGUgMXN0IGluIGEgc2VyaWVz IOKAlCAjTWFjaGluZUJpYXMg4oCUIG9uIHRoZSBoaWRkZW4gaW1wYWN0IG9mIGFsZ29yaXRobXMg aW4gb3VyIGxpdmVzOiBodHRwczovL3QuY28vRjhnZzRuS0xySSBodHRwczovL3QuY28vRTQxM1Aw WDA4bgooaHR0cHM6Ly90d2l0dGVyLmNvbS9Qcm9QdWJsaWNhL3N0YXR1cy83MzQ3MjMwNTQ3NTI4 Mjk0NDE/cz0wMik= From nobody Thu May 26 12:59: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 B1A7312D0F5 for ; Thu, 26 May 2016 12:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 ofQ_wyZCEWBE for ; Thu, 26 May 2016 12:59: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 E349612D8C3 for ; Thu, 26 May 2016 12:52:25 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5279A2806AF for ; Thu, 26 May 2016 21:52:24 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 4E37C2804D4 for ; Thu, 26 May 2016 21:52:24 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 42ECC4C009B for ; Thu, 26 May 2016 21:51:54 +0200 (CEST) Date: Thu, 26 May 2016 21:51:54 +0200 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20160526195154.GB28633@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.3.0-1-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [hrpc] Not everyone likes human rights 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, 26 May 2016 19:59:31 -0000 Beautiful rant against IETF. Encryption and LGBT rights, same struggle? http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_hole/ From nobody Fri May 27 04:56: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 4BC6F12D5BC for ; Fri, 27 May 2016 04:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zrmb0W6MhwXI for ; Fri, 27 May 2016 04:56:28 -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 7260E12D16E for ; Fri, 27 May 2016 04:56:27 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 567821675DDF for ; Fri, 27 May 2016 11:56:26 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 460E31675DD5 for ; Fri, 27 May 2016 11:56:26 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 3A5691A003F for ; Fri, 27 May 2016 11:56:26 +0000 (UTC) To: hrpc@irtf.org References: <20160526195154.GB28633@nic.fr> From: Niels ten Oever Message-ID: <574835E9.1000802@article19.org> Date: Fri, 27 May 2016 13:56:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160526195154.GB28633@nic.fr> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wTFFQIgwjfGc6gRaUSfe4WXOI7r8l9rit" Archived-At: Subject: Re: [hrpc] Not everyone likes human rights 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, 27 May 2016 11:56:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wTFFQIgwjfGc6gRaUSfe4WXOI7r8l9rit Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for this. With a lot of interest I have been following the discussion at ietf@ietf.org about the IETF100 location, for which the IAOC selected Singapore, and which was strongly questioned by Ted Hardie at in Buenos Aires at the plenary. I do not want to replicate that discussion here, but at several points it was brought up that the human rights situation in a specific country might be reason to not have a meeting there. I think this is something that deserves discussion here, and if we manage to come to a approach, we could suggest integration of that in this draft: https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-pro= cess-02 Curious to hear what you all think. 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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: > Beautiful rant against IETF. Encryption and LGBT rights, same > struggle? >=20 > http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_= rabbit_hole/ >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --wTFFQIgwjfGc6gRaUSfe4WXOI7r8l9rit 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 iQEcBAEBCAAGBQJXSDXpAAoJEAi1oPJjbWjpZbQH/Am0esWD38FqVEVl2X3s6Tqj mWhOLoml+arDFf0D2iFvZyEQLMclb+GAllb8UnUVSL1b1eGwFQEIHCBO+fE4D8G8 bCyM9LOFGI12gfvqaJlKzVkUZqMDORBgjDGkSCNgFrJy2UHd5Cr/5hxL0YInFPgc Sls+Mecf4PN3fDBRUdcp6xY9IrIcEVKzAKhD7J9iyl4BKOX9G7j0fFyBjT3SU6lA rcEFf6XtPARPkjsQV+AvYQZzrpsz379m4SCWbJbpGWz5kkwxs5zaSFbhsXeRuWS8 vOuZRea6AifmXlT7yhrvVGl+/sNJrD69UUsZnb3qtDw1ma5M/S7VrKT0uZE72Ec= =aRIu -----END PGP SIGNATURE----- --wTFFQIgwjfGc6gRaUSfe4WXOI7r8l9rit-- From nobody Fri May 27 05:31:51 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 3E12D12D516 for ; Fri, 27 May 2016 05:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_NONE=-0.0001] 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 fd0ZRmPp2-hQ for ; Fri, 27 May 2016 05:31:50 -0700 (PDT) Received: from pmta2.delivery5.ore.mailhop.org (pmta2.delivery5.ore.mailhop.org [54.186.218.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 0C0E312D5DF for ; Fri, 27 May 2016 05:31:49 -0700 (PDT) X-MHO-User: 11d07f96-2407-11e6-a09e-4d61a6885157 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 108.56.132.173 X-Mail-Handler: DuoCircle Outbound SMTP Received: from fullerite.fios-router.home (unknown [108.56.132.173]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA for ; Fri, 27 May 2016 12:32:26 +0000 (UTC) From: John Curran Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 27 May 2016 08:31:48 -0400 To: hrpc@irtf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [hrpc] draft-tenoever-hrpc-research-02 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, 27 May 2016 12:31:51 -0000 Folks -=20 A most excellent document - one that is definitely necessary since the = properties cyberspace is sufficiently different from real-world space to make the = mapping of=20 basic human rights a nontrivial exercise. Given that the document aims to be "a proposal for the mapping of the = relation=20 between human rights and technical concepts=E2=80=9D, has any = consideration been given=20 to UNDHR article 8, and how we go about mapping it to technical = concepts? Thanks, /John From nobody Fri May 27 05:33:34 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 BD40312D739 for ; Fri, 27 May 2016 05:33:32 -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=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 a-5_mRVaXQGd for ; Fri, 27 May 2016 05:33:31 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 9F3E812D170 for ; Fri, 27 May 2016 05:33:30 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x7so78070971qkd.3 for ; Fri, 27 May 2016 05:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=privaterra.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ud9HrmkcPngOG5DUO7ifUlhVCFlhuvAZGrTUKeHFOYU=; b=P8WwdtUB/k1dvzkN9d9n3QihnUMVTcK6ok426zm0NI0T4Ko2tr9Jmm/+KF3wqfboMl /mq7GUel42Fb0jvFOQgdtlnRGLFUNlFzjFDIGJpIze09+4qSCHRfHSHnn1OZjrMMUU4M +r42vhIeJGiNXdUUrYtYuh58+ePck7pThCdkI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ud9HrmkcPngOG5DUO7ifUlhVCFlhuvAZGrTUKeHFOYU=; b=EeHVL1t3OYOyN9B+dn/ZrEVn+HYhA2tL38B/2+9T7FWDneRHuU0Y6O2OWEmCKBknEY 4CmlwnG4PcX9BVC38zgTAq+ru5Fut7y6LgnVwZO9ZSx4UPeWnUtSULx1kmrKKuGfDzMu L/YpYqTh42baBqzipzE1krnttIae291Qb/eJg1B7leyy6r5+ytj2XL/I6KfhzXO7J0qz 5hRXQegt/W8sLYTiuaTAYnOVzdk8v0OpA+Az5DVkM7YwJzadIFbwM3k3JrJc8IBDRZGC FxiEkbMKy5DpmIrYSPkVN45Gr0IEfQVQfZsiU7NYtxhhEQnZIeXLNNn//DaiWRVvSK2c Qp3g== X-Gm-Message-State: ALyK8tJ8YRrLul8UzF2AgE69867PobjR8B1ccyEJD7bTflibndSi41VtmBdk/D4MzZIHcyhX X-Received: by 10.200.47.67 with SMTP id k3mr13203605qta.54.1464352409591; Fri, 27 May 2016 05:33:29 -0700 (PDT) Received: from [192.168.3.5] (pool-72-66-91-231.washdc.fios.verizon.net. [72.66.91.231]) by smtp.gmail.com with ESMTPSA id c68sm2522590qgc.12.2016.05.27.05.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 05:33:27 -0700 (PDT) From: "Robert Guerra" To: "Niels ten Oever" Date: Fri, 27 May 2016 08:33:27 -0400 Message-ID: In-Reply-To: <574835E9.1000802@article19.org> References: <20160526195154.GB28633@nic.fr> <574835E9.1000802@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] Not everyone likes human rights 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, 27 May 2016 12:33:32 -0000 Niels, Thanks for raising the issue. In the last two years two ICANN meetings were held in Singapore (ICANN = 49&52). Was that an issue then? Would it be an issue in the future with = =E2=80=9Chuman rights=E2=80=9D in the fundamental bylaws? As well, what w= here the = considerations when ICANN 46 was being planned in Beijing? Should the same criteria also be advanced at the RIR? For instance, = LACNIC just held its latest meeting in Havana, Cuba. Given the country = scores at the bottom of most rankings, should meetings in the future not = be planned there until there=E2=80=99s a considerable improvement in huma= n = rights condition in the country? Regards Robert -- Robert Guerra Twitter: twitter.com/netfreedom Email: rguerra@privaterra.org PGP Keys : https://keybase.io/rguerra On 27 May 2016, at 7:56, Niels ten Oever wrote: > Thanks for this. > > With a lot of interest I have been following the discussion at > ietf@ietf.org about the IETF100 location, for which the IAOC selected > Singapore, and which was strongly questioned by Ted Hardie at in = > Buenos > Aires at the plenary. > > I do not want to replicate that discussion here, but at several points > it was brought up that the human rights situation in a specific = > country > might be reason to not have a meeting there. > > I think this is something that deserves discussion here, and if we > manage to come to a approach, we could suggest integration of that in > this draft: > https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-p= rocess-02 > > Curious to hear what you all think. > > 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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: >> Beautiful rant against IETF. Encryption and LGBT rights, same >> struggle? >> >> http://www.circleid.com/posts/20160526_ietf_descent_into_the_political= _rabbit_hole/ >> >> _______________________________________________ >> 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 From nobody Fri May 27 05:51:29 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 85A4112D1CE for ; Fri, 27 May 2016 05:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 26y_MHp5Mlmi for ; Fri, 27 May 2016 05:51:26 -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 4A66712D103 for ; Fri, 27 May 2016 05:51:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id 8F8E1201C9A4 for ; Fri, 27 May 2016 13:51:24 +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 mF6u5a2JMQ1s for ; Fri, 27 May 2016 13:51:22 +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 11023201B674 for ; Fri, 27 May 2016 13:51:21 +0100 (BST) To: hrpc@irtf.org References: <20160526195154.GB28633@nic.fr> <574835E9.1000802@article19.org> From: Mallory Knodel X-Enigmail-Draft-Status: N1110 Message-ID: <574842C8.7080300@apc.org> Date: Fri, 27 May 2016 08:51:20 -0400 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/alternative; boundary="------------040202050407050808040806" Archived-At: Subject: Re: [hrpc] Not everyone likes human rights 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, 27 May 2016 12:51:28 -0000 This is a multi-part message in MIME format. --------------040202050407050808040806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi folks Just that there is a controversy and that it's being written about is a very good thing. I'm not sure if this was intentional by either side, but narrowing the options to address this clear political problem in Singapore to a single tactic, namely to host or not to host, makes it really difficult to leverage the discussion in other ways. What if instead we were prepared to host in Singapore and deliver a statement to the government? Host a press conference? Or on the action side: for Ted Hardie and others with him and/or in solidarity with him/them bring their partners in defiance of the laws (albeit as privileged foreigners). Probably there are other tactics. So the logic is that pulling out of the event hurts them economically, then perhaps we can think of that money as buying an audience in Singapore. I agree that we should join the discussion with an approach. -Mallory On 27/05/16 08:33 AM, Robert Guerra wrote: > Niels, > > Thanks for raising the issue. > > In the last two years two ICANN meetings were held in Singapore (ICANN > 49&52). Was that an issue then? Would it be an issue in the future > with “human rights” in the fundamental bylaws? As well, what where the > considerations when ICANN 46 was being planned in Beijing? > > Should the same criteria also be advanced at the RIR? For instance, > LACNIC just held its latest meeting in Havana, Cuba. Given the country > scores at the bottom of most rankings, should meetings in the future > not be planned there until there’s a considerable improvement in human > rights condition in the country? > > > > Regards > > Robert > > -- > Robert Guerra > Twitter: twitter.com/netfreedom > Email: rguerra@privaterra.org > PGP Keys : https://keybase.io/rguerra > > On 27 May 2016, at 7:56, Niels ten Oever wrote: > >> Thanks for this. >> >> With a lot of interest I have been following the discussion at >> ietf@ietf.org about the IETF100 location, for which the IAOC selected >> Singapore, and which was strongly questioned by Ted Hardie at in Buenos >> Aires at the plenary. >> >> I do not want to replicate that discussion here, but at several points >> it was brought up that the human rights situation in a specific country >> might be reason to not have a meeting there. >> >> I think this is something that deserves discussion here, and if we >> manage to come to a approach, we could suggest integration of that in >> this draft: >> https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02 >> >> >> Curious to hear what you all think. >> >> 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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: >>> Beautiful rant against IETF. Encryption and LGBT rights, same >>> struggle? >>> >>> http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_hole/ >>> >>> >>> _______________________________________________ >>> 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 -- Mallory Knodel Association for Progressive Communications :: apc.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------040202050407050808040806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi folks

Just that there is a controversy and that it's being written about is a very good thing.

I'm not sure if this was intentional by either side, but narrowing the options to address this clear political problem in Singapore to a single tactic, namely to host or not to host, makes it really difficult to leverage the discussion in other ways.

What if instead we were prepared to host in Singapore and deliver a statement to the government? Host a press conference? Or on the action side: for Ted Hardie and others with him and/or in solidarity with him/them bring their partners in defiance of the laws (albeit as privileged foreigners). Probably there are other tactics. So the logic is that pulling out of the event hurts them economically, then perhaps we can think of that money as buying an audience in Singapore.

I agree that we should join the discussion with an approach.

-Mallory

On 27/05/16 08:33 AM, Robert Guerra wrote:
Niels,

Thanks for raising the issue.

In the last two years two ICANN meetings were held in Singapore (ICANN 49&52). Was that an issue then? Would it be an issue in the future with “human rights” in the fundamental bylaws? As well, what where the considerations when ICANN 46 was being planned in Beijing?

Should the same criteria also be advanced at the RIR? For instance, LACNIC just held its latest meeting in Havana, Cuba. Given the country scores at the bottom of most rankings, should meetings in the future not be planned there until there’s a considerable improvement in human rights condition in the country?



Regards

Robert

--
Robert Guerra
Twitter: twitter.com/netfreedom
Email: rguerra@privaterra.org
PGP Keys : https://keybase.io/rguerra

On 27 May 2016, at 7:56, Niels ten Oever wrote:

Thanks for this.

With a lot of interest I have been following the discussion at
ietf@ietf.org about the IETF100 location, for which the IAOC selected
Singapore, and which was strongly questioned by Ted Hardie at in Buenos
Aires at the plenary.

I do not want to replicate that discussion here, but at several points
it was brought up that the human rights situation in a specific country
might be reason to not have a meeting there.

I think this is something that deserves discussion here, and if we
manage to come to a approach, we could suggest integration of that in
this draft:
https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02

Curious to hear what you all think.

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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote:
Beautiful rant against IETF. Encryption and LGBT rights, same
struggle?

http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_hole/

_______________________________________________
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

--
Mallory Knodel
Association for Progressive Communications :: apc.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
--------------040202050407050808040806-- From nobody Fri May 27 05:56:28 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 084B312DA6B for ; Fri, 27 May 2016 05:56:27 -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=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 EHDgLVYiQRoR for ; Fri, 27 May 2016 05:56:25 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 180F112D739 for ; Fri, 27 May 2016 05:56:25 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id c189so141969126vkb.1 for ; Fri, 27 May 2016 05:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=privaterra.org; s=google; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc; bh=6J3Ld/fEiqK1GiCVFRBFa2zt0tcSKLZj+eUXlkhM/5U=; b=NGqNJNtGuMuzTjvNQ4KLVsbXwy+lGsGtE/kaIwhUxtOACtvVm2bDOE3YNn2FmevwGM 2yW7kB4YByUg7ZFUCOzCd0Ss/1hQ7tvE96izXr5QV1s1+SiqLPksZ7nvTTWY+zvvrXtR Ml1kviBD+QoH4ufFbtDOgrkVT25pJ6zVA7xGw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:from:mime-version:in-reply-to:date :message-id:subject:to:cc; bh=6J3Ld/fEiqK1GiCVFRBFa2zt0tcSKLZj+eUXlkhM/5U=; b=fRHFHuyPD2S9hRTAU3rLEH7FmJjNz0dRWSsr7iaJiKW0FaRMxlHQjt2Vw4XjTs4JOZ 4gn2h9XsWjwrEelOrR5gkRWh6JTFr2+r7CsVYAkesH0zMLvl/6NlVG9k/D293k1LN13L XBc7Sm6DKqd+BeJqeq1ip+EoKiMWvWbXn2xjXgu9Y6xYgJ3VFK1Y713g2zhx05qYzf9D 6ncQj1QuCHhfHA68R12aTpl7qI9N1NrDP/g0CkY8llC5AadgwH4Oho0nNpzlxVHMeNVy HOSve03R/7v+fMnE1pDxm/XP8CTeAWk2N8fOZG5znarPzEhJtpzO1FRTvXUmNIQrCQRh SPRg== X-Gm-Message-State: ALyK8tL+PS8Pbadz77B3qW8tId/z9J8lMl12NowOSkxP+ju/j7Vcbo8wEYBFQ9EOz/M7HB0BcoFheEp/CCwciAMW X-Received: by 10.176.65.105 with SMTP id j96mr8649080uad.21.1464353783986; Fri, 27 May 2016 05:56:23 -0700 (PDT) References: <20160526195154.GB28633@nic.fr> <574835E9.1000802@article19.org> From: Robert Guerra Mime-Version: 1.0 (1.0) In-Reply-To: <574835E9.1000802@article19.org> Date: Fri, 27 May 2016 08:56:21 -0400 Message-ID: <2534901340066051293@unknownmsgid> To: Niels ten Oever Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Not everyone likes human rights 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, 27 May 2016 12:56:27 -0000 Is hosting a meeting a meeting in Singapore , how about the UAE? ICANN 60 will be held in Abu Dhabi . Does this group and others wish to raise any human rights concerns in regards to having the meeting held in the UAE Regards Robert Sent from my iPhone > On May 27, 2016, at 7:56 AM, Niels ten Oever wrote: > > Thanks for this. > > With a lot of interest I have been following the discussion at > ietf@ietf.org about the IETF100 location, for which the IAOC selected > Singapore, and which was strongly questioned by Ted Hardie at in Buenos > Aires at the plenary. > > I do not want to replicate that discussion here, but at several points > it was brought up that the human rights situation in a specific country > might be reason to not have a meeting there. > > I think this is something that deserves discussion here, and if we > manage to come to a approach, we could suggest integration of that in > this draft: > https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02 > > Curious to hear what you all think. > > 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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: >> Beautiful rant against IETF. Encryption and LGBT rights, same >> struggle? >> >> http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_hole/ >> >> _______________________________________________ >> 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 From nobody Fri May 27 06:00:29 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 AE4AC12D9B2 for ; Fri, 27 May 2016 06:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, 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 irNraoHVt8Bl for ; Fri, 27 May 2016 06:00:20 -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 9597112D1A3 for ; Fri, 27 May 2016 06:00:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 29103BE75; Fri, 27 May 2016 14:00:18 +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 Y9bcrZmW2rso; Fri, 27 May 2016 14:00:18 +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 97C79BE5D; Fri, 27 May 2016 14:00:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464354017; bh=6Ds/1S9YEc2MOC8eqU2LtQNzvryuwTn71wEg1teZ+2o=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vVU2CIZ8Xd8tSPUgaNaPD06/225JRcf3X/bfj/sdk4ZF9cX/vYIOBvEHSAbeQaGBy gKRUxAohf2PdMxeIxicDLZCK/q7stzf+tgqHIkn4O6O8Hn+41RBU51j4wR1mZKtztI I6gv9tf2NdsD9wcQH1g6NT4vUem4T9xc4m+aq7ec= To: Niels ten Oever , hrpc@irtf.org References: <20160526195154.GB28633@nic.fr> <574835E9.1000802@article19.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <574844E1.6050208@cs.tcd.ie> Date: Fri, 27 May 2016 14:00:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <574835E9.1000802@article19.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qcSXhGc3kSMI7UrhgucqHoVMUQ0CNjB8M" Archived-At: Subject: Re: [hrpc] Not everyone likes human rights 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, 27 May 2016 13:00:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qcSXhGc3kSMI7UrhgucqHoVMUQ0CNjB8M Content-Type: multipart/mixed; boundary="9CixtWR53c3BPiSXsP7IIgoj5g5MAicaC" From: Stephen Farrell To: Niels ten Oever , hrpc@irtf.org Message-ID: <574844E1.6050208@cs.tcd.ie> Subject: Re: [hrpc] Not everyone likes human rights References: <20160526195154.GB28633@nic.fr> <574835E9.1000802@article19.org> In-Reply-To: <574835E9.1000802@article19.org> --9CixtWR53c3BPiSXsP7IIgoj5g5MAicaC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 27/05/16 12:56, Niels ten Oever wrote: > Thanks for this. >=20 > With a lot of interest I have been following the discussion at > ietf@ietf.org about the IETF100 location, for which the IAOC selected > Singapore, and which was strongly questioned by Ted Hardie at in Buenos= > Aires at the plenary. >=20 > I do not want to replicate that discussion here, but at several points > it was brought up that the human rights situation in a specific country= > might be reason to not have a meeting there. >=20 > I think this is something that deserves discussion here, and if we > manage to come to a approach, we could suggest integration of that in > this draft: > https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-p= rocess-02 >=20 > Curious to hear what you all think. I think some calm, considered discussion here would be good if we have folks on this list with HR expertise, which I hope we do. One of the issues with such discussions on ietf@ietf.org is that a lot of us think we know a lot about stuff when we might not (me included;-) Improving on that would be good. As you say though, just repeating what's already been a pretty verbose discussion is unlikely to be helpful, so I really hope we don't do that. I'd not worry for now about what document might end up with what text - it's too early to say IMO. Cheers, S. >=20 > Best, >=20 > Niels >=20 > Niels ten Oever > Head of Digital >=20 > Article 19 > www.article19.org >=20 > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 >=20 > On 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: >> Beautiful rant against IETF. Encryption and LGBT rights, same >> struggle? >> >> http://www.circleid.com/posts/20160526_ietf_descent_into_the_political= _rabbit_hole/ >> >> _______________________________________________ >> 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 --9CixtWR53c3BPiSXsP7IIgoj5g5MAicaC-- --qcSXhGc3kSMI7UrhgucqHoVMUQ0CNjB8M 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 iQEcBAEBCAAGBQJXSEThAAoJEC88hzaAX42iug0H/i7vc98HDQ0KiNaFP5CZuQHI eoarEUXEjgdPepKRdCQKEmNu3yO7sZlW9g8WE9amQlJacatHFzbPIt3o17+8HP9l uJReMIuFJRs7aCqJCH/5cDSKZFu5ZVuOENpW1F7ut/wsSYgmmGeGJIJvZDHwHQSH FzfeOEgT2/vZsNoFBd0hhL1cM6ws+dKbRJu+HMN54ljZc+YGf1G/xQrAZZ9ynjaT yCJgOjmU1unBCtH01sVX1IKcjLmwFpapt4Rk68NJLATq0rTEuQ0RA81KMZRTauz4 AdDJYVco73HLWkXBE423C5UsL5il9o4fjBtFy8RM8esnYAwGuokCvHsU3rpMGcE= =8mx2 -----END PGP SIGNATURE----- --qcSXhGc3kSMI7UrhgucqHoVMUQ0CNjB8M-- From nobody Fri May 27 06:00: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 9883512DA85 for ; Fri, 27 May 2016 06:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jS9qNIU_xUwv for ; Fri, 27 May 2016 06:00:42 -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 73F8A12DA80 for ; Fri, 27 May 2016 06:00:42 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 21F908A6B5C5; Fri, 27 May 2016 13:00:41 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 0D8CE8A6B5C2; Fri, 27 May 2016 13:00:41 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id EDA6D65C198C; Fri, 27 May 2016 13:00:40 +0000 (UTC) To: Robert Guerra References: <20160526195154.GB28633@nic.fr> <574835E9.1000802@article19.org> <2534901340066051293@unknownmsgid> From: Niels ten Oever Message-ID: <574844F8.4060907@article19.org> Date: Fri, 27 May 2016 15:00:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 MIME-Version: 1.0 In-Reply-To: <2534901340066051293@unknownmsgid> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bj8Qmd0mq9BJGIF2hC6V4FwNV3NjwFO4v" Archived-At: Cc: "hrpc@irtf.org" Subject: Re: [hrpc] Not everyone likes human rights 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, 27 May 2016 13:00:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bj8Qmd0mq9BJGIF2hC6V4FwNV3NjwFO4v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Robert, Let's not come to rapid conclusions. Let's first see what different criteria there are (having meetings in different parts of the world also being one as clearly outlined here: https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-pro= cess-02 ) and when we have different criteria that are important we can prioritize them and develop a method of weighing them. And let's first keep this to the IETF, and when we work it out here, we can think of other fora. 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 05/27/2016 02:56 PM, Robert Guerra wrote: > Is hosting a meeting a meeting in Singapore , how about the UAE? >=20 > ICANN 60 will be held in Abu Dhabi . Does this group and others wish > to raise any human rights concerns in regards to having the meeting > held in the UAE >=20 > Regards >=20 > Robert >=20 >=20 > Sent from my iPhone >=20 >> On May 27, 2016, at 7:56 AM, Niels ten Oever wro= te: >> >> Thanks for this. >> >> With a lot of interest I have been following the discussion at >> ietf@ietf.org about the IETF100 location, for which the IAOC selected >> Singapore, and which was strongly questioned by Ted Hardie at in Bueno= s >> Aires at the plenary. >> >> I do not want to replicate that discussion here, but at several points= >> it was brought up that the human rights situation in a specific countr= y >> might be reason to not have a meeting there. >> >> I think this is something that deserves discussion here, and if we >> manage to come to a approach, we could suggest integration of that in >> this draft: >> https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-= process-02 >> >> Curious to hear what you all think. >> >> 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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: >>> Beautiful rant against IETF. Encryption and LGBT rights, same >>> struggle? >>> >>> http://www.circleid.com/posts/20160526_ietf_descent_into_the_politica= l_rabbit_hole/ >>> >>> _______________________________________________ >>> 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 --bj8Qmd0mq9BJGIF2hC6V4FwNV3NjwFO4v 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 iQEcBAEBCAAGBQJXSET4AAoJEAi1oPJjbWjpZCwH/2g22Q2eqE5Jtxjz5Rnx+UO9 FXMHq2Dh0tBK9+Bi3ollKjA4Y5Q5Cy7wfpXQNQSSGvNm46hCDp//WeYKp/ylFGij AfB3ZHzCSPbTHbs0vw9cith0eJvrAMMT3ADnuuWjgH8xc6Zwq5PvaYYOFFZgCFUR zzEinx4lLJM+r585VPx3dv95eUMR9lDDphXCClSyKmtfHmszlO/XTpQEFqX8KIMx yEmwQL15fD/hXQaTmtAtrp59opYI37obikji26Ty9Rrira/VElqWQ6znD4rz7uZP fwbAiHWcrxr3cmi4fgqeynsXPY4CNeTPKfODIEtklSFPfVj96imoRE/fj6tvhBY= =YA9E -----END PGP SIGNATURE----- --bj8Qmd0mq9BJGIF2hC6V4FwNV3NjwFO4v-- From nobody Fri May 27 06:12:43 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 631B412DA72 for ; Fri, 27 May 2016 06:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 OyfUTGJUp3Dr for ; Fri, 27 May 2016 06:12:39 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 9C03D12DA84 for ; Fri, 27 May 2016 06:12:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id EE82610BBE for ; Fri, 27 May 2016 13:12:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYTEsTf150uC for ; Fri, 27 May 2016 13:12:38 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id E58AD105A5 for ; Fri, 27 May 2016 13:12:37 +0000 (UTC) Date: Fri, 27 May 2016 09:12:35 -0400 From: Andrew Sullivan To: hrpc@irtf.org Message-ID: <20160527131234.GA13118@mx2.yitter.info> References: <20160526195154.GB28633@nic.fr> <574835E9.1000802@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <574835E9.1000802@article19.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [hrpc] on where to discuss venues (Was Re: Not everyone likes human rights) 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, 27 May 2016 13:12:42 -0000 Hi, On Fri, May 27, 2016 at 01:56:25PM +0200, Niels ten Oever wrote: > I do not want to replicate that discussion here, but at several points > it was brought up that the human rights situation in a specific country > might be reason to not have a meeting there. > > I think this is something that deserves discussion here Why does it deserve discussion _here_? This RG is supposed to be about protocol considerations, not meetings and not human rights in general. There is a list where people are discussing the venue selection, and I think that if people want human rights considerations to be brought to bear on that discussion they should go join that list and try to make sure those considerations are in fact brought to bear. But if we have this discussion in every list that the IETF or IRTF hosts where the venue selection could possibly be relevant to the list (i.e. all of them), it will never converge. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri May 27 06:31:04 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 3D9AF12DA90 for ; Fri, 27 May 2016 06:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 PtA8MrU0Wr6D for ; Fri, 27 May 2016 06:31:01 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 D62A412DA97 for ; Fri, 27 May 2016 06:30:58 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id k23so173798786oih.0 for ; Fri, 27 May 2016 06:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:date:message-id:subject:from:to:cc; bh=Txx0uB0na0OxrtErScfojE4u9JmioVgHhgK33JF9ulw=; b=rt6rg7r2BytaiYthQsn8KBF+yM0E9jxgz7Lxq3Uhc0ZCWtt3TyeAQ5iAVVULTEmz1N OVefAO6X48qwQazJ6G3inSt2l1eGjIX8WhedsXyf7FcnYkt06Lgj2crCm1gL40fnqvZv z7qhfUslFLQlkFc1Ta0qLSEGSLWhqa6NBfKAY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=Txx0uB0na0OxrtErScfojE4u9JmioVgHhgK33JF9ulw=; b=OTrSwj8j5T5xgwvcuyMqnVWHVyS2R4WfZ0zgb1UN/LbFXQfObMP/FDJzmLLQISPvBz rHl/2iT0qfYv1+/wexclMvuY5sndFdmbsyJNsgoMFY72SIJm+UjtqivzMpGUaL0QPnoS Llqpr/JEV7kjLVu2XbFDdeEosk+1/pDSGcZ/uKVz9imlvZjImUY6jvubssFZUfFsnJvS yt9IRoVwPyI0aslhFLN4neSWaCNRaivhg8swZnNNULlnE+PFLO9sK2rgV0m/kWjAUea7 KIqLu6DqLLSYW1dRriej8QZnrz51XBKVDsplbkyori1N3I4k87aVYDCF4/7YuBL13+TP ud4A== X-Gm-Message-State: ALyK8tLHh1l/FklB1qtgOtmm0TgswbeypgqJ5yViGYaD9uKfb0+O5Fl1wFg8yovf9/k9fWba2c85yLu/0rFWcdC8 MIME-Version: 1.0 X-Received: by 10.157.7.14 with SMTP id 14mr3634649ote.168.1464355857776; Fri, 27 May 2016 06:30:57 -0700 (PDT) Received: by 10.202.171.20 with HTTP; Fri, 27 May 2016 06:30:57 -0700 (PDT) Date: Fri, 27 May 2016 14:30:57 +0100 Message-ID: From: Scott Craig To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11370a72ba7d600533d2eadf Archived-At: Cc: hrpc@irtf.org Subject: [hrpc] Human Rights Considerations in IETF venue choice 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, 27 May 2016 13:31:03 -0000 --001a11370a72ba7d600533d2eadf Content-Type: text/plain; charset=UTF-8 Hi Andrew, The Charter of the group is to 'research whether standards and protocols can enable, strengthen or threaten human rights, as defined in the Universal Declaration of Human Rights (UDHR) and the International Covenant on Civil and Political Rights (ICCPR) A significant aspect of the investigation into whether standards and protocols enable, strengthen or threaten human rights concerns has been the means and mechanisms through which protocols are developed. Niels proposal that we investigate the degree of consideration, or lack thereof, given to the Human Rights in the choice of location venue seems well within the scope of the matter being investigated by the group. Regards, Scott Craig On Fri, May 27, 2016 at 2:12 PM, Andrew Sullivan wrote: > Hi, > > On Fri, May 27, 2016 at 01:56:25PM +0200, Niels ten Oever wrote: > > > I do not want to replicate that discussion here, but at several points > > it was brought up that the human rights situation in a specific country > > might be reason to not have a meeting there. > > > > I think this is something that deserves discussion here > > Why does it deserve discussion _here_? This RG is supposed to be > about protocol considerations, not meetings and not human rights in > general. > > There is a list where people are discussing the venue selection, and I > think that if people want human rights considerations to be brought to > bear on that discussion they should go join that list and try to make > sure those considerations are in fact brought to bear. But if we have > this discussion in every list that the IETF or IRTF hosts where the > venue selection could possibly be relevant to the list (i.e. all of > them), it will never converge. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- *Scott Craig* | Ford-Mozilla Fellow Center for Democracy & Technology |* cdt.org * *E:* scraig@cdt.org | *D:* 1.202.407.8887 | @scottdavidcraig --001a11370a72ba7d600533d2eadf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,=C2=A0

The Charter of the group is to = 9;research whether standards and protocols can enable, strengthen or threat= en human rights, as defined in the Universal Declaration of Human Rights (U= DHR) and the International Covenant on Civil and Political Rights (ICCPR)
A significant aspect of the investigation into whether standards and = protocols enable, strengthen or threaten human rights concerns has been the= means and mechanisms through which protocols are developed.=C2=A0

N= iels proposal that we investigate the degree of consideration, or lack ther= eof, given to the Human Rights in the choice of location venue seems well w= ithin the scope of the matter being investigated by the group.=C2=A0
Regards,=C2=A0

Scott Craig





On Fri, May 27, 2016 at 2:12 PM, Andre= w Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,

On Fri, May 27, 2016 at 01:56:25PM +0200, Niels ten Oever wrote:

> I do not want to replicate that discussion here, but at several points=
> it was brought up that the human rights situation in a specific countr= y
> might be reason to not have a meeting there.
>
> I think this is something that deserves discussion here

Why does it deserve discussion _here_?=C2=A0 This RG is supposed to be
about protocol considerations, not meetings and not human rights in
general.

There is a list where people are discussing the venue selection, and I
think that if people want human rights considerations to be brought to
bear on that discussion they should go join that list and try to make
sure those considerations are in fact brought to bear.=C2=A0 But if we have=
this discussion in every list that the IETF or IRTF hosts where the
venue selection could possibly be relevant to the list (i.e. all of
them), it will never converge.

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

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



--

Scott Craig=C2=A0|=C2=A0Ford-Mozilla Fellow
Center fo= r Democracy & Technology=C2=A0|=C2=A0cdt.org=
E:=C2=A0scraig@cdt.org=C2=A0|=C2=A0D:= =C2=A01.2= 02.407.8887=C2=A0|=C2=A0@= scottdavidcraig=

=



--001a11370a72ba7d600533d2eadf-- From nobody Fri May 27 07:04:27 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 D4D7512D6A1 for ; Fri, 27 May 2016 07:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eoZiXBTEGQ3f for ; Fri, 27 May 2016 07:04:07 -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 BA41812DABC for ; Fri, 27 May 2016 07:04:03 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 970D983864B for ; Fri, 27 May 2016 14:04:01 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 8621383866A for ; Fri, 27 May 2016 14:04:01 +0000 (UTC) Received: from [192.168.1.71] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 7617183864B for ; Fri, 27 May 2016 14:04:01 +0000 (UTC) To: hrpc@irtf.org References: From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <574853D0.2070907@article19.org> Date: Fri, 27 May 2016 16:04:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hBdUNeT5tJQ1QIQakADsshn5rkQPspL56" Archived-At: Subject: Re: [hrpc] draft-tenoever-hrpc-research-02 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, 27 May 2016 14:04:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hBdUNeT5tJQ1QIQakADsshn5rkQPspL56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, Are you referring to: Article 8 Everyone has the right to an effective remedy by the competent national tribunals for acts violating the fundamental rights granted him by the constitution or by law. If so, does this mean that your question could be reformulated as: 'Have you already resolved the Internet and jurisidition problem?' If this is the case, my answer would be: we're working with human rights because this is the most universal standard that we've got, exactly to not go down the rabbit hole of different situations in different jurisdictions. Does this help? 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 05/27/2016 02:31 PM, John Curran wrote: > Folks -=20 >=20 > A most excellent document - one that is definitely necessary since the = properties > cyberspace is sufficiently different from real-world space to make the = mapping of=20 > basic human rights a nontrivial exercise. >=20 > Given that the document aims to be "a proposal for the mapping of the r= elation=20 > between human rights and technical concepts=E2=80=9D, has any considera= tion been given=20 > to UNDHR article 8, and how we go about mapping it to technical concept= s? >=20 > Thanks, > /John >=20 >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --hBdUNeT5tJQ1QIQakADsshn5rkQPspL56 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 iQEcBAEBCAAGBQJXSFPRAAoJEAi1oPJjbWjpdRAH/16fKHzCBSwUEYew0C7N7uua 1mbVmhTnWrkmgwu47qSMrR4SFxWAath6S/47iaOKDFnmwTfLV/Ti7mQAHpZXLRu1 p8GlWar/DTM6mTC29+tMRaeN7YNrCEUzhdKH5cJ0+mzpDCddDxMDScaxv6VWjYEK LB8HjGXV5pXDaC9O0HoWtEEb1nUpK+shrODxR3+sZibVO+LW/a0peUWt2aInj7mk OxjcAfKH/y6VMmJpwMLAaYal12q3LhvlMO1crlehAFQMnV9WKUNJHdzXHk8iOLpH qCsWr8TQKD7ShdfE1K8gyAIGSv3UBawZRiQNtwhuf3juV2RHk7XxCiJuDw1t5l8= =RDvH -----END PGP SIGNATURE----- --hBdUNeT5tJQ1QIQakADsshn5rkQPspL56-- From nobody Fri May 27 07:04: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 25E0D12D645 for ; Fri, 27 May 2016 07:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] 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 tqBEMcMFJNm7 for ; Fri, 27 May 2016 07:04:54 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 DAB6612D0CA for ; Fri, 27 May 2016 07:04:47 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id b65so175275269oia.1 for ; Fri, 27 May 2016 07:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:date:message-id:subject:from:to:cc; bh=89yi1pqWWDNYdMeb+7F6S1STF/w3RHQRpdFcNJSlnN4=; b=OfsyTBHVUOvQ1WNzg5CzR12yqQ/X+YMI2/hPHeHPQNMZmvsZCVF/32JFzeinQd3Nay MgwVnVFmv8RMbkhxmCht0kmZ+Vdfnal83wKBVTL8jgHY1I3Up+zrHd6BY4rPTkbtEvRJ 88vbxWbQipSwoxTyyXCfTdJIovOKilS5DkHlk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=89yi1pqWWDNYdMeb+7F6S1STF/w3RHQRpdFcNJSlnN4=; b=jVOsjHo77eO8qAtoSdG0z4CloTUSvYac+RP+Gd6qRqEkpf/S1ZOiuAkzxZ8aC9meeH Eld+ETkllT86OAEKSIrcCEcP3rfyxMVDXUec8r5cRyg3gdkFchFzGGlRsItwuAwvSR5Y 7dL2KTGNCxoxJ3EuY+xunThHueXgpo8lXb6ZjO76nNQxBCjHP9h+jrJHty5c9xEvzeBn XQzWrO7d1k/V/YxoRUyU2YeLfq/yUesA9oZp5f35/zM4b4SXEE0pZktj49lCf9BiXNWV YRG2zXq/nbHjjWE76lWAXR6jGPWm1HoF+GbxVNuC+exIpazt+HpSA3BeB9xaqwAAGwUt Zi8w== X-Gm-Message-State: ALyK8tJSPvbWKJGBwhhR7hh7vYyoT3oYyH8iMDXbuhiPWJpdMfSmvyQUlQw4OmvcqaPz2aq2sMAUWhfu6FZebeE8 MIME-Version: 1.0 X-Received: by 10.157.9.162 with SMTP id q31mr8841669otd.57.1464357887099; Fri, 27 May 2016 07:04:47 -0700 (PDT) Received: by 10.202.171.20 with HTTP; Fri, 27 May 2016 07:04:47 -0700 (PDT) Date: Fri, 27 May 2016 15:04:47 +0100 Message-ID: From: Scott Craig To: Niels ten Oever Content-Type: multipart/alternative; boundary=001a1135166caf6a0b0533d3636a Archived-At: Cc: Robert Guerra , "hrpc@irtf.org" Subject: [hrpc] Examining existing Venue Selection criteria 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, 27 May 2016 14:04:57 -0000 --001a1135166caf6a0b0533d3636a Content-Type: text/plain; charset=UTF-8 H Niels, A couple of thoughts on the venue selection process https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02#section-3 *1. Can it be established whether or not the IETF considers Human Rights to be 'political criteria'. * Political considerations: The IETF does not make political statements. We do not decide who is or is not a country, and we do not choose or not choose venues based on political criteria. *2. Can it be established whether or not the IETF formally considered its 'principal of inclusiveness' in previous venue selections.* Inclusiveness: We *would like* to facilitate the onsite or remote participation of anyone who wants to be involved. Every country has limits on who it will permit within its borders. *This principle of inclusiveness militates against the selection of venues within countries that impose visa regulations and/or laws that effectively exclude people on the basis of race, religion, gender, sexual orientation, or national origin,* and to a lesser extent, *reduces the likelihood* of selecting countries that use such attributes to make entry difficult. Scott On Fri, May 27, 2016 at 2:00 PM, Niels ten Oever wrote: > Hi Robert, > > Let's not come to rapid conclusions. Let's first see what different > criteria there are (having meetings in different parts of the world also > being one as clearly outlined here: > > https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02 > ) and when we have different criteria that are important we can > prioritize them and develop a method of weighing them. > > And let's first keep this to the IETF, and when we work it out here, we > can think of other fora. > > 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 05/27/2016 02:56 PM, Robert Guerra wrote: > > Is hosting a meeting a meeting in Singapore , how about the UAE? > > > > ICANN 60 will be held in Abu Dhabi . Does this group and others wish > > to raise any human rights concerns in regards to having the meeting > > held in the UAE > > > > Regards > > > > Robert > > > > > > Sent from my iPhone > > > >> On May 27, 2016, at 7:56 AM, Niels ten Oever > wrote: > >> > >> Thanks for this. > >> > >> With a lot of interest I have been following the discussion at > >> ietf@ietf.org about the IETF100 location, for which the IAOC selected > >> Singapore, and which was strongly questioned by Ted Hardie at in Buenos > >> Aires at the plenary. > >> > >> I do not want to replicate that discussion here, but at several points > >> it was brought up that the human rights situation in a specific country > >> might be reason to not have a meeting there. > >> > >> I think this is something that deserves discussion here, and if we > >> manage to come to a approach, we could suggest integration of that in > >> this draft: > >> > https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02 > >> > >> Curious to hear what you all think. > >> > >> 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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: > >>> Beautiful rant against IETF. Encryption and LGBT rights, same > >>> struggle? > >>> > >>> > http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_hole/ > >>> > >>> _______________________________________________ > >>> 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 > > -- *Scott Craig* | Ford-Mozilla Fellow Center for Democracy & Technology |* cdt.org * *E:* scraig@cdt.org | *D:* 1.202.407.8887 | @scottdavidcraig --001a1135166caf6a0b0533d3636a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
H Niels,=20

A couple of thoughts on the venue selection p=
rocess 


https=
://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02=
#section-3=C2=A0 



1. Can it be esta=
blished whether or not the IETF considers Human Rights to be 'political=
 criteria'.=C2=A0

<=
span style=3D"font-size:13.3333px">Political considerations:
      The IETF does not make political statements.  We do not decide who
      is or is not a country, and we do not choose or not choose venues
      based on political criteria.

2. Can it be established whether or not the IETF formally conside=
red its 'principal of inclusiveness=
' in previous venue selections.

Inclusiveness:
      We would like to facilitate the onsite or remote participation of
      anyone who wants to be involved.  Every country has limits on who
      it will permit within its borders.  This principle of
      inclusiveness militates against the selection of venues within
      countries that impose visa regulations and/or laws that
      effectively exclude people on the basis of race, religion, gender,
      sexual orientation, or national origin, and to a lesser exten=
t,
      reduces the likelihood of selecting countries that use such
      attributes to make entry difficult.
Scott

On Fri= , May 27, 2016 at 2:00 PM, Niels ten Oever <niels@article19.org><= /span> wrote:
Hi Robert,

Let's not come to rapid conclusions. Let's first see what different=
criteria there are (having meetings in different parts of the world also being one as clearly outlined here:
https://tools.ietf.o= rg/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02
) and when we have different criteria that are important we can
prioritize them and develop a method of weighing them.

And let's first keep this to the IETF, and when we work it out here, we=
can think of other fora.

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

On 05/27/2016 02:56 PM, Robert Gue= rra wrote:
> Is hosting a meeting a meeting in Singapore , how about the UAE?
>
> ICANN 60 will be held in Abu Dhabi . Does this group and others wish > to raise any human rights concerns in regards to having the meeting > held in the UAE
>
> Regards
>
> Robert
>
>
> Sent from my iPhone
>
>> On May 27, 2016, at 7:56 AM, Niels ten Oever <niels@article19.org> wrote:
>>
>> Thanks for this.
>>
>> With a lot of interest I have been following the discussion at
>> ietf@ietf.org about the IETF1= 00 location, for which the IAOC selected
>> Singapore, and which was strongly questioned by Ted Hardie at in B= uenos
>> Aires at the plenary.
>>
>> I do not want to replicate that discussion here, but at several po= ints
>> it was brought up that the human rights situation in a specific co= untry
>> might be reason to not have a meeting there.
>>
>> I think this is something that deserves discussion here, and if we=
>> manage to come to a approach, we could suggest integration of that= in
>> this draft:
>> https://too= ls.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-02 >>
>> Curious to hear what you all think.
>>
>> Best,
>>
>> Niels
>>
>> Niels ten Oever
>> Head of Digital
>>
>> Article 19
>> www.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 08B5 A0F2 636D 68E9
>>
>>> On 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote:
>>> Beautiful rant against IETF. Encryption and LGBT rights, same<= br> >>> struggle?
>>>
>>> http= ://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_h= ole/
>>>
>>> _______________________________________________
>>> 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




--
=

Scott Craig=C2=A0|=C2=A0Ford-Mozilla Fellow
Center for Democra= cy & Technology=C2=A0|=C2=A0cdt.org
E:=C2=A0scraig@cdt.org=C2=A0|=C2=A0D:=C2= =A01.202.407.= 8887=C2=A0<= span style=3D"color:rgb(207,202,202)">|=C2=A0@scottdavi= dcraig


--001a1135166caf6a0b0533d3636a-- From nobody Fri May 27 07:30: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 1D61912D651 for ; Fri, 27 May 2016 07:30:09 -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=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 X5_vKqBDUxl9 for ; Fri, 27 May 2016 07:30:06 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 673CF12D17B for ; Fri, 27 May 2016 07:29:59 -0700 (PDT) Received: by mail-qg0-x229.google.com with SMTP id f92so51576805qgf.0 for ; Fri, 27 May 2016 07:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=privaterra.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8kMRFEhmICBzYx4VKLYO0c32qAIYkG7dRuBr8IAQRb8=; b=IkLV5kXUAt/8nkrKfK4af6cWYrF4qAJnN0RTEHmNugDPgoRVaGHjeAFY07alLaIPAG Oe590HhAqR3pH1hYGsI2cvis6PLYt9gbkPP4DxQbnqW+L/fXq08RO/yz0x9ycRE4ZQkQ nikfDA07VA0cF6/Adu9lzgHoBsxlXOjkBZ1OE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8kMRFEhmICBzYx4VKLYO0c32qAIYkG7dRuBr8IAQRb8=; b=EHvvTOUP/J/APmaXdiLT8Cum9NCYHDpM0y327PqKFdGZzAQ8vPxgUHDBe0/ab81Iab QjiUDTYRifJ6kR4OEdDYsnVlYrzSDHRkTf0uIq2K/cIWnsKH1EHqSBZJG6o3NtD10kei 59kmcev7ebNnjcRgiBHjbwyc6/RCANrRmBMU9ahL7GEcA95iGfiBembcy+v9ewKuoHNx zVOizOWRQlV1P0RpmVOqVs9qDVPQdKa2xIuHI4dl7PhrJavLIHdNsof0WTUqEiGwdVGv NLbPkpsqkkPfD/b54Ml8DoL5GNkNolSerpWDYNfxsmSu6FV0//AlKnKxcGolwWJJkCQa OYqA== X-Gm-Message-State: ALyK8tJNkiQhKKDQqWFO/CAIaPpzgxwVBXZ8ztsFnICIiZCeUW/GawjykNAgW1Ta74LW/vpj X-Received: by 10.140.174.133 with SMTP id u127mr14338369qhu.10.1464359398254; Fri, 27 May 2016 07:29:58 -0700 (PDT) Received: from [192.168.3.5] (pool-72-66-91-231.washdc.fios.verizon.net. [72.66.91.231]) by smtp.gmail.com with ESMTPSA id e7sm2656117qgd.45.2016.05.27.07.29.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 07:29:55 -0700 (PDT) From: "Robert Guerra" To: "Scott Craig" Date: Fri, 27 May 2016 10:29:53 -0400 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Niels ten Oever , "hrpc@irtf.org" Subject: Re: [hrpc] Examining existing Venue Selection criteria 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, 27 May 2016 14:30:09 -0000 Scott, If it=E2=80=99s not too late, might I propose a suggested revision to the= = paragraph so that it is consistent with language terms used in UN = processes, such as the ongoing Habitat III negotiations http://mirror.unhabitat.org/categories.asp?catid=3D831 Below is a suggested revision of the paragraph. We *would like* to facilitate the onsite or remote participation of = inclusive and free from any form of discrimination, based on gender, = age, health status, disability, income, nationality, ethnicity, = migratory condition, or political, religious or sexual orientation , = where all inhabitants, whether permanent or transitional, are granted = equal rights and opportunities, according to the United Nations Charter = principles and the relevant provisions of international law. This paragraph might be missing certain aspects of the original = paragraph. Do add them back in :) regards Robert -- Robert Guerra Twitter: twitter.com/netfreedom Email: rguerra@privaterra.org PGP Keys : https://keybase.io/rguerra On 27 May 2016, at 10:04, Scott Craig wrote: > H Niels, > > A couple of thoughts on the venue selection process > > https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-p= rocess-02#section-3 > > > > > > *1. Can it be established whether or not the IETF considers Human > Rights to be 'political criteria'. * > > > Political considerations: > The IETF does not make political statements. We do not decide = > who > is or is not a country, and we do not choose or not choose = > venues > based on political criteria. > > > *2. Can it be established whether or not the IETF formally considered > its 'principal of inclusiveness' in previous venue selections.* > Inclusiveness: > > We *would like* to facilitate the onsite or remote participation = > of > anyone who wants to be involved. Every country has limits on = > who > it will permit within its borders. *This principle of > inclusiveness militates against the selection of venues within > countries that impose visa regulations and/or laws that > effectively exclude people on the basis of race, religion, = > gender, > sexual orientation, or national origin,* and to a lesser extent, > *reduces the likelihood* of selecting countries that use such > attributes to make entry difficult. > > > Scott > > > On Fri, May 27, 2016 at 2:00 PM, Niels ten Oever > wrote: > >> Hi Robert, >> >> Let's not come to rapid conclusions. Let's first see what different >> criteria there are (having meetings in different parts of the world = >> also >> being one as clearly outlined here: >> >> https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-= process-02 >> ) and when we have different criteria that are important we can >> prioritize them and develop a method of weighing them. >> >> And let's first keep this to the IETF, and when we work it out here, = >> we >> can think of other fora. >> >> 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 05/27/2016 02:56 PM, Robert Guerra wrote: >>> Is hosting a meeting a meeting in Singapore , how about the UAE? >>> >>> ICANN 60 will be held in Abu Dhabi . Does this group and others wish >>> to raise any human rights concerns in regards to having the meeting >>> held in the UAE >>> >>> Regards >>> >>> Robert >>> >>> >>> Sent from my iPhone >>> >>>> On May 27, 2016, at 7:56 AM, Niels ten Oever >> wrote: >>>> >>>> Thanks for this. >>>> >>>> With a lot of interest I have been following the discussion at >>>> ietf@ietf.org about the IETF100 location, for which the IAOC = >>>> selected >>>> Singapore, and which was strongly questioned by Ted Hardie at in = >>>> Buenos >>>> Aires at the plenary. >>>> >>>> I do not want to replicate that discussion here, but at several = >>>> points >>>> it was brought up that the human rights situation in a specific = >>>> country >>>> might be reason to not have a meeting there. >>>> >>>> I think this is something that deserves discussion here, and if we >>>> manage to come to a approach, we could suggest integration of that = >>>> in >>>> this draft: >>>> >> https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-= process-02 >>>> >>>> Curious to hear what you all think. >>>> >>>> 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 05/26/2016 09:51 PM, Stephane Bortzmeyer wrote: >>>>> Beautiful rant against IETF. Encryption and LGBT rights, same >>>>> struggle? >>>>> >>>>> >> http://www.circleid.com/posts/20160526_ietf_descent_into_the_political= _rabbit_hole/ >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> > > > -- = > > *Scott Craig* | Ford-Mozilla Fellow > Center for Democracy & Technology |* cdt.org * > *E:* scraig@cdt.org | *D:* 1.202.407.8887 | @scottdavidcraig From nobody Fri May 27 07:49:51 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 231C312D1A0 for ; Fri, 27 May 2016 07:49:49 -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=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 CLsjhKKes3cE for ; Fri, 27 May 2016 07:49:46 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 B572712D17B for ; Fri, 27 May 2016 07:49:46 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id 90so51756599qgz.1 for ; Fri, 27 May 2016 07:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=privaterra.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3RVg/XwbLuPuSKzzdzKczupQj9tX69VZbgcgzKRCRTI=; b=Zu4SzLU0de0hSOBreJVmVHr6mEt25A5rOVuEJZx0f5g9NbNEhfYIr9mBhka5D0T4As nU8meL20MiQfoeTtXUT/MSlRicl/lBuG5NzSVWgAcnqPQPil9IRHuZ9CuuEjzjNhIppF /vfrhW0oy1akFg4sLh27oq2pRcsnMe0Emfr+s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3RVg/XwbLuPuSKzzdzKczupQj9tX69VZbgcgzKRCRTI=; b=fhMmaqXH0NVNMXZOLl7tpZMxvFfqCtpB935kGbdhv6GKjqRnRs3YLJBiqdCiYaKIG/ Mi0YZxelrB74c1NexnG4EOho266SVqMtB4muLuXgbsKaj6rt+/25SzQ4RWX3liaybKTM 0prp3d4gNyc1AcGnnShDVyuTPWj/b8URF0vZMnE/hKeK4sR3iFdJKhbVpDEjJsEGunbh uZbjIp8QwxpdKd60rkug++mhn+VH4gWs8c966ZUZNgStgMxI2igA3ORw9cUfepD+UebY e2gN5Fw7WvaVoTHlA2eA99rRmouHCXRcNfTVU/FvlGC3z7xb9EVnMmVN51qkfoeh3Q8u ZnwA== X-Gm-Message-State: ALyK8tJxJF+EGB1Xu9e5cxZRqGuocOB0ciYM74KfLQUows2X4PgHG89Svfo3OLbUGkUdXQd3 X-Received: by 10.141.0.3 with SMTP id b3mr14315298qhd.13.1464360585692; Fri, 27 May 2016 07:49:45 -0700 (PDT) Received: from [192.168.3.5] (pool-72-66-91-231.washdc.fios.verizon.net. [72.66.91.231]) by smtp.gmail.com with ESMTPSA id x13sm5413496qtc.12.2016.05.27.07.49.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 07:49:42 -0700 (PDT) From: "Robert Guerra" To: "Scott Craig" Date: Fri, 27 May 2016 10:49:41 -0400 Message-ID: <896785BB-07B7-457D-9733-4803F5635638@privaterra.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Niels ten Oever , "hrpc@irtf.org" Subject: Re: [hrpc] Examining existing Venue Selection criteria 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, 27 May 2016 14:49:49 -0000 Scott, I’ll defer to you and Niels on ways it might be possible to have my suggested language make it’s way to the IETF for consideration :) regards robert -- Robert Guerra Twitter: twitter.com/netfreedom Email: rguerra@privaterra.org PGP Keys : https://keybase.io/rguerra On 27 May 2016, at 10:47, Scott Craig wrote: > Hey Robert, > > The paragraphs aren't mine, they are cited are from the IETF's > guidance doc > linked above. Sorry that wasn't clear. The questions above them are > issues > I think they raise. > > Good suggestion though! > > Scott > > On Fri, May 27, 2016 at 3:29 PM, Robert Guerra > > wrote: > >> Scott, >> >> If it’s not too late, might I propose a suggested revision to the >> paragraph so that it is consistent with language terms used in UN >> processes, such as the ongoing Habitat III negotiations >> >> http://mirror.unhabitat.org/categories.asp?catid=831 >> >> Below is a suggested revision of the paragraph. >> >> >> >> We *would like* to facilitate the onsite or remote participation of >> inclusive and free from any form of discrimination, based on gender, >> age, >> health status, disability, income, nationality, ethnicity, migratory >> condition, or political, religious or sexual orientation , where all >> inhabitants, whether permanent or transitional, are granted equal >> rights >> and opportunities, according to the United Nations Charter principles >> and >> the relevant provisions of international law. >> >> >> This paragraph might be missing certain aspects of the original >> paragraph. >> Do add them back in :) >> >> regards >> >> Robert >> >> -- >> Robert Guerra >> Twitter: twitter.com/netfreedom >> Email: rguerra@privaterra.org >> PGP Keys : https://keybase.io/rguerra >> >> -- > > *Scott Craig* | Ford-Mozilla Fellow > Center for Democracy & Technology |* cdt.org * > *E:* scraig@cdt.org | *D:* 1.202.407.8887 | @scottdavidcraig From nobody Fri May 27 07:50:04 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 F204012D645 for ; Fri, 27 May 2016 07:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 WS3762DY43MT for ; Fri, 27 May 2016 07:49:52 -0700 (PDT) Received: from pmta2.delivery5.ore.mailhop.org (pmta2.delivery5.ore.mailhop.org [54.186.218.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 62B5112D59E for ; Fri, 27 May 2016 07:49:52 -0700 (PDT) X-MHO-User: 5ad037b2-241a-11e6-a09e-4d61a6885157 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 108.56.132.173 X-Mail-Handler: DuoCircle Outbound SMTP Received: from fullerite.fios-router.home (unknown [108.56.132.173]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 27 May 2016 14:50:28 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7B7B6265-4DF1-4184-8F87-E5E0B0F45FA6"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: John Curran In-Reply-To: <574853D0.2070907@article19.org> Date: Fri, 27 May 2016 10:49:44 -0400 Message-Id: <6B10B5EC-4A83-475D-BD8A-F040BCB21B2A@istaff.org> References: <574853D0.2070907@article19.org> To: Niels ten Oever X-Mailer: Apple Mail (2.3124) Archived-At: Cc: hrpc@irtf.org Subject: Re: [hrpc] draft-tenoever-hrpc-research-02 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, 27 May 2016 14:49:55 -0000 --Apple-Mail=_7B7B6265-4DF1-4184-8F87-E5E0B0F45FA6 Content-Type: multipart/alternative; boundary="Apple-Mail=_3D7D8859-2605-4D39-B1BA-068146761465" --Apple-Mail=_3D7D8859-2605-4D39-B1BA-068146761465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 27, 2016, at 10:04 AM, Niels ten Oever = wrote: >=20 > Hi John, >=20 > Are you referring to: >=20 > Article 8 > Everyone has the right to an effective remedy by the competent = national > tribunals for acts violating the fundamental rights granted him by the > constitution or by law. Yes. > If so, does this mean that your question could be reformulated as: > 'Have you already resolved the Internet and jurisidition problem?=E2=80=99= No, that is not a correct reformulation of my question. There are already existing processes in the real world for pursuit of = legal remedies between jurisdictions (e.g. MLAT)=E2=80=A6 They may (or may = not) work very well, but either way that=E2=80=99s not our job to resolve. My question is far simpler: What are the technical concepts that need to be considered in Internet protocol development so that the basic human right of =E2=80=98effective remedy=E2=80=99 for violation of their rights can = be provided? When someone is the victim of ransomware, it is quite likely that there = is not going to be a happy outcome to the story. There are many reasons for this, including the fact that our law enforcement cooperation = processes were developed decades ago, and presume a very small amount of trans- border criminal activity - as such, they operate in weeks/months and = lack any potential for operating at Internet speed. However, the fact that law enforcement has very limited ability to = pursue remedy in cyberspace doesn=E2=80=99t necessary equate to valid reasoning = for precluding meaningful engagement of law enforcement when an innocent party is robbed via the Internet. The IETF is quite capable of = designing protocols that make it effectively impossible to pursue effective = remedy, and if it does so, then it is actually inhibiting exercise of basic = human rights. (There is actually some merit in proactively taking a stand that the = human right of effective remedy simply cannot be satisfied on the Internet, = i.e. that the costs and implications for providing for such are too great. = If that is the case, then it is a fairly important IETF determination for = protocol developers to be aware of=E2=80=A6) > If this is the case, my answer would be: we're working with human = rights > because this is the most universal standard that we've got, exactly to > not go down the rabbit hole of different situations in different > jurisdictions. There is no reason to consider different jurisdictions, nor is that our = job. However, whether IETF protocols facilitate or obscure information needed in the determination of the relevant jurisdiction(s) and thus support = the human right of effective remedy/due process is definitely a valid = question. This is simply the question of whether someone=E2=80=99s basic right to = be able to initiating legal recourse is or is not not pre-empted via IETF design = decisions made during protocol development. You may perhaps consider that out of scope for your initial effort (i.e. left for future work or simply a = human right not to be protected on the Internet) but then there should be included = some form of statement to that effect. There has been extensive work in mapping UN Declaration of Human Rights to the online context, and this includes recent efforts = (including the Dynamic Coalition on human rights meeting at IGF) let to a nice statement on same - =E2=80=9CThe Charter of human rights and principles = for the internet=E2=80=9D - > It might be worth looking at this document, as it already has similar mappings of the various human rights into the online context and made provide an additional basis for this effort. Thanks! /John --Apple-Mail=_3D7D8859-2605-4D39-B1BA-068146761465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On May 27, 2016, at 10:04 AM, Niels ten Oever <niels@article19.org>= wrote:

Hi = John,

Are you referring to:
Article 8
Everyone has the right to an = effective remedy by the competent national
tribunals for = acts violating the fundamental rights granted him by the
constitution or by law.

Yes.

If so, does this mean that your question = could be reformulated as:
'Have you already resolved the = Internet and jurisidition problem?=E2=80=99
<= br class=3D"">
No, that is not a correct reformulation of my = question.

There are already existing = processes in the real world for pursuit of legal 
remedies between jurisdictions (e.g. MLAT)=E2=80=A6   = They may (or may not)
work very well, but either = way that=E2=80=99s not our job to resolve. 

My question is far simpler:

    What are = the technical concepts that need to be considered in 
    Internet protocol development so that the basic = human right of 
    =E2=80=98effective= remedy=E2=80=99 for violation of their rights can be = provided?

When = someone is the victim of ransomware, it is quite likely that there = is 
not going to be a happy outcome to the = story.  There are many reasons
for this, = including the fact that our law enforcement cooperation = processes
were developed decades ago, and presume a = very small amount of trans-
border criminal = activity - as such, they operate in weeks/months and lack
any potential for operating at Internet = speed. 

However, the fact that law enforcement has very limited = ability to pursue
remedy in cyberspace doesn=E2=80=99= t necessary equate to valid reasoning for 
precluding meaningful engagement of law enforcement when an = innocent
party is robbed via the Internet. =  The IETF is quite capable of designing
protocols that make it effectively impossible to pursue = effective remedy, 
and if it does so, then it = is actually inhibiting exercise of basic human rights.  

(There is actually some = merit in proactively taking a stand that the human
right of effective remedy simply cannot be satisfied on the = Internet, i.e.
that the costs and implications for = providing for such are too great.  If that
is = the case, then it is a fairly important IETF determination for = protocol
developers to be aware = of=E2=80=A6) 

If this is the = case, my answer would be: we're working with human rights
because this is the most universal standard that we've got, = exactly to
not go down the rabbit hole of different = situations in different
jurisdictions.

There is no reason to consider different = jurisdictions, nor is that our job. 
However, whether = IETF protocols facilitate or obscure information needed
in the = determination of the relevant jurisdiction(s) and thus support = the 
human right of effective remedy/due process is = definitely a valid question.

This is = simply the question of whether someone=E2=80=99s basic right to be able = to
initiating legal recourse is or is not not pre-empted via = IETF design decisions 
made during protocol development. =  You may perhaps consider that out of 
scope for = your initial effort (i.e. left for future work or simply a human = right 
not to be protected on the Internet) but then = there should be included some 
form of statement to that = effect. 

There has been = extensive work in mapping UN Declaration of Human
Rights to = the online context, and this includes recent efforts = (including 
the Dynamic Coalition on human rights meeting = at IGF) let to a nice 
statement on same - =E2=80=9CThe = Charter of human rights and principles for&n= bsp;
the internet=E2=80=9D - <http://internetrightsandprinciples.org/site/>   = It might 
be worth looking at this document, as it = already has similar mappings
of the various human rights into = the online context and made provide
an additional basis for = this effort.

Thanks!
/John




= --Apple-Mail=_3D7D8859-2605-4D39-B1BA-068146761465-- --Apple-Mail=_7B7B6265-4DF1-4184-8F87-E5E0B0F45FA6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAldIXo0ACgkQh22TQU2hnI5xYQCgm9MgzN2lfYnFDJnCseGMnlyX 0msAnj/PJS2DdcTSJfuP6uF6TC4Ft3yJ =vLhy -----END PGP SIGNATURE----- --Apple-Mail=_7B7B6265-4DF1-4184-8F87-E5E0B0F45FA6-- From nobody Fri May 27 07:54: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 C699512D112 for ; Fri, 27 May 2016 07:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=unavailable 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 4s9Apmi0QiIL for ; Fri, 27 May 2016 07:54:30 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 CF78E12D53E for ; Fri, 27 May 2016 07:47:06 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id b65so177227028oia.1 for ; Fri, 27 May 2016 07:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ERJ0CK8XgJHP7V4olv1A1n6GixqRi2qhzuoo4ZArHjo=; b=dy6SpEL3oyWQ02cbfdfAi0yu77oE/T+Uw2bvCAhgKsLuj3XCxr9qYJ/YdQ5tuHosa/ m5GabYHouW8huFGDjEcQbsf3dz/uPEyfwedsdUEpdP0WMOKukKKXmMVxMDagrdpSQKEw ccFICc/MfgUngy8PBvQL6uRJfBuhKQTRXVjPI= 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:date :message-id:subject:from:to:cc; bh=ERJ0CK8XgJHP7V4olv1A1n6GixqRi2qhzuoo4ZArHjo=; b=G6q2hd2SFvt2C/QpynKcTHsa2q4YqUIGH0QL+kKlvKHEGSSV6YWoJjdiGYNXT1Lpih yEM7Ea0pc1jKdMaZpCave4WOOJV6w9Uh2LjCIPx2UorVJTA6ufAIQWh/sfFxOa0k8g28 rWQSkPVCv3KSkpzhtWnEj2y9xsKlEvs2rivBCUwRFTzAAW6x7l5uYu5y494+/iKafxwn 6s4fWBWwSY4Y6ynkEBfuyEIGQx//z01uNTkv6kZSkeuqik0tVtk2wbvJ32e6zJTZusXW VGP3MBpTR5+MtKBPtO1JA0Ne6Sz8mrYj4JmCgOmXK7eYujAkQlSl62WPeqLueK5etpPQ H0/g== X-Gm-Message-State: ALyK8tL7gfLDZKM0tDRhpNTEk13W+KmEG+Wd7u1lrjazxyEruJFg+oAJIWCbOvcod0ASPcRCBRLXShHs0gAwNDtG MIME-Version: 1.0 X-Received: by 10.202.86.134 with SMTP id k128mr10294670oib.115.1464360426139; Fri, 27 May 2016 07:47:06 -0700 (PDT) Received: by 10.202.171.20 with HTTP; Fri, 27 May 2016 07:47:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 May 2016 15:47:06 +0100 Message-ID: From: Scott Craig To: Robert Guerra Content-Type: multipart/alternative; boundary=001a113de2bc06253b0533d3fb84 Archived-At: Cc: Niels ten Oever , "hrpc@irtf.org" Subject: Re: [hrpc] Examining existing Venue Selection criteria 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, 27 May 2016 14:54:34 -0000 --001a113de2bc06253b0533d3fb84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Robert, The paragraphs aren't mine, they are cited are from the IETF's guidance doc linked above. Sorry that wasn't clear. The questions above them are issues I think they raise. Good suggestion though! Scott On Fri, May 27, 2016 at 3:29 PM, Robert Guerra wrote: > Scott, > > If it=E2=80=99s not too late, might I propose a suggested revision to the > paragraph so that it is consistent with language terms used in UN > processes, such as the ongoing Habitat III negotiations > > http://mirror.unhabitat.org/categories.asp?catid=3D831 > > Below is a suggested revision of the paragraph. > > > > We *would like* to facilitate the onsite or remote participation of > inclusive and free from any form of discrimination, based on gender, age, > health status, disability, income, nationality, ethnicity, migratory > condition, or political, religious or sexual orientation , where all > inhabitants, whether permanent or transitional, are granted equal rights > and opportunities, according to the United Nations Charter principles and > the relevant provisions of international law. > > > This paragraph might be missing certain aspects of the original paragraph= . > Do add them back in :) > > regards > > Robert > > -- > Robert Guerra > Twitter: twitter.com/netfreedom > Email: rguerra@privaterra.org > PGP Keys : https://keybase.io/rguerra > > -- *Scott Craig* | Ford-Mozilla Fellow Center for Democracy & Technology |* cdt.org * *E:* scraig@cdt.org | *D:* 1.202.407.8887 | @scottdavidcraig --001a113de2bc06253b0533d3fb84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Robert,=C2=A0

The paragraphs aren't mine, t= hey are cited are from the IETF's guidance doc linked above. Sorry that= wasn't clear. The questions above them are issues I think they raise. = =C2=A0

Good suggestion though!

Scott

On Fri, May 27, 2016 at 3:= 29 PM, Robert Guerra <rguerra@privaterra.org> wrote:
Scott,

If it=E2=80=99s not too late, might I propose a suggested revision to the p= aragraph so that it is consistent with language terms used in=C2=A0 UN proc= esses, such as the ongoing Habitat III negotiations

http://mirror.unhabitat.org/categories.asp?cat= id=3D831

Below is a suggested revision of the paragraph.



We *would like* to facilitate the onsite or remote participation of inclusi= ve and free from any form of discrimination, based on gender, age, health s= tatus, disability, income, nationality, ethnicity, migratory condition, or = political, religious or sexual orientation , where all inhabitants, whether= permanent or transitional, are granted equal rights and opportunities, acc= ording to the United Nations Charter principles and the relevant provisions= of international law.


This paragraph might be missing certain aspects of the original paragraph. = Do add them back in :)

regards

Robert

--
Robert Guerra
Twitter: twitter.com/netfreedom
Email: rguerra@= privaterra.org
PGP Keys : https://keybase.io/rguerra

--

Scott Craig=C2=A0|=C2=A0Ford-Mozill= a Fellow
Center for Democracy & Technology=C2= =A0|=C2=A0cdt.org
E:=C2=A0scraig@cdt.org=C2=A0|=C2=A0D:=C2=A01.202.407.8887=C2=A0|=C2=A0@scottdavidcraig

=

=
--001a113de2bc06253b0533d3fb84-- From nobody Tue May 31 06:31: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 0423F12D1E3 for ; Tue, 31 May 2016 06:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1MG_GxAnWsZU for ; Tue, 31 May 2016 06:31:05 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB9512D1D5 for ; Tue, 31 May 2016 06:31:05 -0700 (PDT) Received: from filter.hostedemail.com (unknown [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 534379ED83 for ; Tue, 31 May 2016 13:31:03 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -5, 0, , d41d8cd98f00b204, avri@acm.org, ::, RULES_HIT:41:355:379:599:854:871:973:988:989:1000:1260:1261:1313:1314:1345:1359:1381:1437:1516:1518:1534:1541:1575:1594:1711:1730:1747:1777:1792:2393:2559:2562:2693:2898:2911:3138:3139:3140:3141:3142:3354:3673:3865:3866:3867:3868:3870:3871:3872:3874:4184:4250:4362:4425:5007:6117:6506:6747:6748:7281:7652:7875:7901:7909:8660:9010:10004:10848:11232:11604:11658:11914:12043:12050:12109:12114:12517:12519:13019:13148:13149:13160:13161:13200:13229:13230:14040:14096:14180:14227:14658:14659:14721:21060:21080:21212:21326:21433:30022:30054:30070, 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:7, LUA_SUMMARY:none X-HE-Tag: roll80_4359ca7eef63c X-Filterd-Recvd-Size: 4313 Received: from [127.0.0.1] (unknown [23.82.54.75]) (Authenticated sender: avri@doria.org) by omf05.hostedemail.com (Postfix) with ESMTPA for ; Tue, 31 May 2016 13:31:02 +0000 (UTC) References: <57399CE7.90700@article19.org> <5739AF53.6020808@acm.org> To: hrpc@irtf.org From: avri doria Message-ID: Date: Tue, 31 May 2016 09:30:09 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5739AF53.6020808@acm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eueHM7CbUUt1Le4T6QdfvsBJFuWN8u5NS" X-Antivirus: avast! (VPS 160531-0, 05/31/2016), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 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: Tue, 31 May 2016 13:31:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eueHM7CbUUt1Le4T6QdfvsBJFuWN8u5NS Content-Type: multipart/mixed; boundary="4SVPd4GMH2H7jFNHcLOUMG8KLToD4XGpb" From: avri doria Reply-To: avri@acm.org To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] Call for RG Adoption draft-tenoever-hrpc-research-02 References: <57399CE7.90700@article19.org> <5739AF53.6020808@acm.org> In-Reply-To: <5739AF53.6020808@acm.org> --4SVPd4GMH2H7jFNHcLOUMG8KLToD4XGpb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > This email serves as a call for RG adoption of > draft-tenoever-hrpc-research-02 [0] as a RG document. The call for > adoption will run for 2 weeks ending 5/30/2016. I had asked: > Is anyone willing to review this with a light to making a recommendatio= n > on whether it should be a RG work item? Would like to get some deeper > opinion on the draft and its contents, especially from an engineering > perspective. > > I would also like to hear about others who are interested in working on= > this draft, as becoming an RG draft means moving it more into the main > work stream of the RG and getting greater input that just the authors > and a few commenters. The period ended yesterday. We have had reviews and we have had commitments to work on it further. I would like to see more reviews and more commitments to read and work on it, but at this point am satisfied that it is more than just a couple of people who have done some serious reading and thinking on the draft. =46rom the email I have seen on the list, including from those who read and reviewed I would say that we have RG support for making this an RG document. I have seen several people indicate that it should be an RG doc and did not see anyone say it shouldn't be. If anyone disagrees with this assessment, please let the list know in the very near future. Personally, I finished reading it yesterday and while I have not written up any notes yet - will real soon now, I think it is now a strong draft and while I think it will benefit from further work, think it is a an I-D that serves the HRPC RG effort and ongoing work well. My suggestion would be that comments on the current draft continue for another couple of weeks and that the authors plan on putting out the RG draft in time for the Berlin meeting. I also suggest that the two current authors remain the co-authors for the RG draft. Thanks to those who participated in this call. avri --4SVPd4GMH2H7jFNHcLOUMG8KLToD4XGpb-- --eueHM7CbUUt1Le4T6QdfvsBJFuWN8u5NS 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 iQEcBAEBCAAGBQJXTZHuAAoJEOo+L8tCe36H/wUIAJZKAmszopBAf9CgXdl/98zw gNPDPE0sV/hnQOv5kJ+Fg3MIWP/NzYwFx+lZQA+NM1d7CLMdhKa55tHnIZQWfw+y jabq0KsHjYYh5Nm6XZS6ItF4LR5L2TlwUatAlzqsNEvvVdrerAVh2VSAqcusi2OD aI4iLGsUc7S5eLjXfOXx9mD4k1EELlZw1xSUZX/z/Ggj1uQ/AX0nqDjCsoKaBsIJ VQnnrBr/+sTZkwyFWMcbJi1G4DDEtnqLQu1nYQHaxCN3HyJHtFs5KPdULJJ9Fv2a zFp1flSuCDlHYMdfS188PG0tF7Z5HzFCc4SyZfDcw9qGP2XE7CNPATFf/l9y2uk= =u37l -----END PGP SIGNATURE----- --eueHM7CbUUt1Le4T6QdfvsBJFuWN8u5NS--