From nobody Thu Nov 1 11:58:30 2018 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 1FC871294D0 for ; Thu, 1 Nov 2018 11:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl header.b=Ck07XrK0; dkim=pass (1024-bit key) header.d=sidnka.onmicrosoft.com header.b=hkEOU5oV 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 fqhHTsCn60Uc for ; Thu, 1 Nov 2018 11:58:25 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF7A124BAA for ; Thu, 1 Nov 2018 11:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=dkim-signature:from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-clientproxiedby:authentication-results:x-ms-exchange-messagesentrepresentingtype:x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics:x-ms-office365-filtering-correlation-id:x-microsoft-antispam:x-ms-traffictypediagnostic:x-microsoft-antispam-prvs:x-exchange-antispam-report-test:x-ms-exchange-senderadcheck:x-exchange-antispam-report-cfa-test:x-forefront-prvs:x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info:spamdiagnosticoutput:spamdiagnosticmetadata:content-type:content-id:content-transfer-encoding:mime-version:x-originatororg:x-ms-exchange-crosstenant-network-message-id:x-ms-exchange-crosstenant-originalarrivaltime:x-ms-exchange-crosstenant-fromentityheader:x-ms-exchange-crosstenant-id:x-ms-exchange-transport-crosstenantheadersstamped; bh=TeOPmOFecrasarmyJW1536OF/l25o9iWVC3UUl7GMw4=; b=Ck07XrK05Y/8e9ZIgR2KMfsBJsIIgSvMxQ7+J0hHO+b3b57nG4AvnHI4cXJ/RhCYzZx0qabOjm5tABHiHdXXFJAKDF8L932c9OnelCz3e8ltS1UnqW3UACiklnmkiBBH/5P435IYJObvfGh/o5/WvctUo8DmWdRYepoVTsI1L2NTB2gOwoec7gadzjNt96eDsItpcJUvdkNQc8wnb4EiUDI9pBESkFU+/1fb9ZZ0Bi4NXqkZFDBre//ld5r3SoluTg+jVTbtqQDhP7btWN+lBJ+Nw+J4Ukzt6DzdrHjrUtEalJoLOIu0LMn5KBIZL0LUjztM8is86/PmRioGonWx7g== Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0206.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1f::206]) by arn2-kamx.sidn.nl with ESMTP id wA1IwMu2017130-wA1IwMu4017130 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 1 Nov 2018 19:58:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SIDNKA.onmicrosoft.com; s=selector1-sidn-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TeOPmOFecrasarmyJW1536OF/l25o9iWVC3UUl7GMw4=; b=hkEOU5oV+yaKv69K1RAxW8Yd9NoEIPTkJi7OwNqpZeUIrIjwO3R7e8qdteVOUS9g+072GgRp7Dw9JoKLwdtFz/R3l98lYPCNFfL9zCUV9tXU45Egar6ji5KWVudzFTo1H9yWyOHd2YZHnUHngCnC1sslmwtw35WNCRuZYadLU90= Received: from HE1P194MB0172.EURP194.PROD.OUTLOOK.COM (10.171.128.12) by HE1P194MB0092.EURP194.PROD.OUTLOOK.COM (10.171.127.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Thu, 1 Nov 2018 18:58:21 +0000 Received: from HE1P194MB0172.EURP194.PROD.OUTLOOK.COM ([fe80::49a7:1b4f:f72b:3931]) by HE1P194MB0172.EURP194.PROD.OUTLOOK.COM ([fe80::49a7:1b4f:f72b:3931%5]) with mapi id 15.20.1273.027; Thu, 1 Nov 2018 18:58:21 +0000 From: Giovane Moura To: "hrpc@irtf.org" Thread-Topic: Measurement papers on Censorship at IMC2018 Thread-Index: AQHUchTbhzETCDHZXkKgRiRegYZRhA== Date: Thu, 1 Nov 2018 18:58:21 +0000 Message-ID: <1c092c82-1620-fa3d-28d9-e61da661a989@sidn.nl> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: BN6PR05CA0031.namprd05.prod.outlook.com (2603:10b6:405:39::44) To HE1P194MB0172.EURP194.PROD.OUTLOOK.COM (2603:10a6:3:10b::12) Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 2a01:111:f400:7e1f::206 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl; dkim=pass header.i=@SIDNKA.onmicrosoft.com authentication-results: spf=none (sender IP is ) smtp.mailfrom=giovane.moura@sidn.nl; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [155.33.137.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1P194MB0092; 6:/TyyQslto8V0xuhVYMiWVz0ysmBdIWhqAOPYBKlBmjTRZ1I7tKoHa2eH+f2BnLB/t6enD5f43jEdf89GdOxVTve9P6etfA9Pv/IlFHIsGkKoMiPViOJxgkT2ihTWB4XhUYuow4nXqRUU8ANHwuJSgZtaskKs4J2j755vEkFcpyCyC+ZMZH+jEokl1uR3GHGyyN5XQVtp7KiMcd0z+jgNZTTOUqK3MFulkhMzHABXOepXT4+8VAoThQ8MFtBGwRFytRATydn9yeks9Ao0cOaby3TPGqCFS8yaSe3ZEwihJJ3NegwVSw3MS3TqgHTJjCoLGCeX6fGohQfjDFHW4OutlQzRd6U/wPBRv5+eWRpfD71kIQHFMbahjpOE0W6t6pDlAeuMQncvTTLfz7P24TRBFMHlBPrT0OXrAq1eGd/qarYf2wXnofw/CjiAU3YCm7kFjUq4PChuo9QWT+m65GIzsg==; 5:iGWaBOz/EZZfkDvmQhwHBBIkPaZ8oeND7JCre+C3uXwn2QcjRaxerpIwZnAqJ5zVCDbv8Bd/r81UsZ11fwPgLDgDUY7qTL7COCaRNCt4cuUojgjy+tx078TIz6enpqwt7tsB7o3byrD8csFau+n/PR0d7BySHhj/usLSQwg1Z8k=; 7:kTwAM3tI+7zBbmdDz8ES1iyhwnyd2g9GKq35HXsCNZKw4aSwdF83kgjOqYdA+WcAFi79/i/c3LqGdSYK2zX1pjG7mjdlUeRpG+4fGeqCAHgMQtIwlHnpTMKLLg57Hy1jEcTYrv2dLaIBHu+hhAd70A== x-ms-office365-filtering-correlation-id: 3a525f2e-380e-4078-b219-08d6402bfdf4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1P194MB0092; x-ms-traffictypediagnostic: HE1P194MB0092: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(101264311250101)(213716511872227); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1P194MB0092; BCL:0; PCL:0; RULEID:; SRVR:HE1P194MB0092; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39840400004)(136003)(396003)(199004)(189003)(6506007)(5660300001)(52116002)(386003)(446003)(71200400001)(256004)(5250100002)(71190400001)(305945005)(186003)(66066001)(25786009)(476003)(7736002)(14454004)(478600001)(102836004)(486006)(44832011)(26005)(966005)(31696002)(99286004)(76176011)(2616005)(11346002)(6512007)(6306002)(316002)(2900100001)(6436002)(81156014)(2351001)(6916009)(81166006)(5640700003)(6486002)(86362001)(53936002)(74482002)(8676002)(1730700003)(31686004)(36756003)(2501003)(68736007)(6116002)(3846002)(2906002)(106356001)(8936002)(97736004)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P194MB0092; H:HE1P194MB0172.EURP194.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sidn.nl does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7JWq24mnz4oqwRmuSO7uVxxbaYRO22p1fPlzCMPIZh16ulrJ3Oh7IY5c7eP5b5xCA5B6BuAgqJtdGhN00/F2hzzbSnbb8HuABee9QeYtd/RdPEcwPSsbgXAmBN60i9XxICp3o8BtpedMB8Sc0ElWnwTzMWPMMmTecHyOwDk9oDqSRnERB1gOjVRdVPoQmlF+JBkrP2twMwo9Y29buqc5jZwzCei8C/rhMOmMncr2SmveRr6jss6hc9d07mFSO6bM9e9kfg8XtPQynq6j4Tl1izwXPv7PsEc46xZwL8x85Czf6a/DQq1WN3LNIUZ8LaOc51sWMW50l32F5bRQcM7tp7betXlRgLrTSBgH4fBsy6Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <59E66FE3E8B22E429B35BF12DAD2FD59@EURP194.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 3a525f2e-380e-4078-b219-08d6402bfdf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2018 18:58:21.1650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P194MB0092 X-FEAS-SPF: 2 / 2, ip=2a01:111:f400:7e1f::206, helo=eur01-he1-obe.outbound.protection.outlook.com, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl X-FEAS-DKIM: Valid Archived-At: Subject: [hrpc] Measurement papers on Censorship at IMC2018 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 18:58:28 -0000 Rm9sa3MsDQoNCkkgcmVjb21tZW5kIHNvbWUgcGFwZXJzIGJlaW5nIHByZXNlbnRlZCB0aGlzIHdl ZWsgYXQgSU1DMjAxOCBoZXJlIGluIEJvc3RvbjoNCg0KMS4gQW4gRW1waXJpY2FsIFN0dWR5IG9m IHRoZSBJMlAgQW5vbnltaXR5IE5ldHdvcmsgYW5kIGl0cyBDZW5zb3JzaGlwIA0KUmVzaXN0YW5j ZQ0KICBwYXBlcjogaHR0cHM6Ly9kbC5hY20ub3JnL2F1dGhvcml6ZT9ONjYyNjU3DQoNCjIuIDQw MyBGb3JiaWRkZW46IEEgR2xvYmFsIFZpZXcgb2YgQ0ROIEdlb2Jsb2NraW5nDQpwYXBlcjogaHR0 cHM6Ly9kbC5hY20ub3JnL2F1dGhvcml6ZT9ONjYyNTM5DQoNCjMuIFdoZXJlIFRoZSBMaWdodCBH ZXRzIEluOiBBbmFseXppbmcgV2ViIENlbnNvcnNoaXAgTWVjaGFuaXNtcyBpbiBJbmRpYSANCnBh cGVyczogaHR0cHM6Ly9kbC5hY20ub3JnL2F1dGhvcml6ZT9ONjYyNTMyDQoNCkZ1bGwgcHJvZ3Jh bTogaHR0cHM6Ly9jb25mZXJlbmNlcy5zaWdjb21tLm9yZy9pbWMvMjAxOC9wcm9ncmFtLw0KDQoN Ci9naW92YW5lDQo= From nobody Sat Nov 3 04:21:28 2018 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 C7BF71288BD for ; Sat, 3 Nov 2018 04:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta2WxnKfcj5N for ; Sat, 3 Nov 2018 04:21:24 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 B54CD124BAA for ; Sat, 3 Nov 2018 04:21:23 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gItzU-0002LF-Jm; Sat, 03 Nov 2018 12:21:21 +0100 Date: Sat, 3 Nov 2018 11:21:19 +0000 (UTC) From: Mallory Knodel To: Arthit Suriyawongkul Cc: hrpc@irtf.org, ashwinjmathew@berkeley.edu Message-ID: <1080664341.37901803.1541244079939.JavaMail.zimbra@article19.org> In-Reply-To: References: <47500403-cf79-5839-1c55-e9f0d65d7247@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.7.11_GA_1854 (zclient/8.7.11_GA_1854) Thread-Topic: draft agenda 103 Thread-Index: Tb6zvLdb/nX/ea6qvwChaZkR5Uge4Q== X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: a350ae07b5350cdad28cef237d2e7179 Archived-At: Subject: Re: [hrpc] draft agenda 103 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 11:21:27 -0000 Hi Art, Yes that=E2=80=99s right. Maybe we can talk through the points of your pres= entation on Sunday? If you prefer, that is. Just here to help.=20 The hackathon work is under the Public interest technology heading of this = wiki page: https://trac.ietf.org/trac/ietf/meeting/wiki/103hackathon Welcome to join! Registration is free.=20 -M ----- Original Message ----- From: Arthit Suriyawongkul To: mallory@article19.org Cc: hrpc@irtf.org, ashwinjmathew@berkeley.edu Sent: Sat, 03 Nov 2018 01:42:19 -0000 (UTC) Subject: Re: [hrpc] draft agenda 103 It will be the first session, 9:00-11:00 on Monday November 5 Room Chitlada 1 I see that there will be an update from Hackathon (on Saturday and Sunday), can I know what's the topic they hack during the Hackathon? cheers, Art From nobody Sat Nov 3 14:32:39 2018 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 27793126DBF for ; Sat, 3 Nov 2018 14:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZbKj3DWNgGg for ; Sat, 3 Nov 2018 14:32:28 -0700 (PDT) Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.124]) (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 8FDDA128C65 for ; Sat, 3 Nov 2018 14:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1541280747; bh=3kVyriJU85czaEoS0Z1tSy6O3DRtrZvRMOivgW/07Hs=; h=Date:From:To:Subject:References:From:Subject; b=GrYbmp/e8r5wpejRWbYJi+m3Y4crSzi+NXggrGCuRVH7BNe+1XxJ7MPfgBo/XDLMtwCjP709J4LsYSYxamjMUyfxMUBCxJSp1tH7b+F1cQ1TgBDSNktSGe1b/0QOqPPYiNZUtQuA33ev6qWxSkyDZgggHzUzTiwPpilOquSEfpM187/79uZeOQ2eW9GvmJd91VdqSAHhv/G8KDDbAoHvbCjJXWQPhPUqOJSkD2kgzISuqe291yPJjrQp7DuSVLhrljAAUTaVTkEe1U7r53kZe0WW6vDX0f865G1W10pTFQZ+qpByLpCZTNsZr8m9lY/oMlcf/TjkY79Vpz3mrqpvaw== X-YMail-OSG: G7P_SfIVM1kOxf6SZ2JvmHhOvE6pcBRk22u6Oay_d0ynRZv1yldlH7cr.wGbS43 MyAoSc2hHfHmxLcTjIKMDC5W4WgEcKBJJ1DtPZ8SvmfMqY1DTPg4NdXBBTZi8WZp3IhnelsDUh_N VtEbCMfUV1d1n13bFdUlOxTC.ScF9uVs7ZllCNdRj8XthK5WMkg8ogND9Da3uHvlUcbJXB2xGABk ClGiG.GTvJFf7Z9XNsLx_GWk8DM.GrbsxqH9T9D5iN87Yeo0gueMDLuXPlts8kzu2ON54cVSXZh_ L9AvyZqU2vkRQYUARgSdHT7Ax9KV7Hd8VozupR4pAAEAQE.0W3tMGvc_gAbSpfoMNV_blOPgifhf kkXMKuyQy4EDIprL_fgHlSxFuqmJE0yIRD1aCxJgFZ1JnbzYSsSriAWPpgVJIqYK8lSE6Fz5J.3N lVsRPI7GTN8SJYvLVFnyPiBscyf03y8SxzkpqpS.G_3n3w7swwpFDNkmx5.JifHBSOzfixcaV2bE 2TADTbexNfQODAxi09VzV.JysKm8KMW_hVUf53V0a7BqDSb6AzfydfWtZHrWT8e5Tz_RdoGKz60X ixVGvQIbHTpGb24tKhZ1tbSMDpykWH2LP.lC4bUNXxxFWWGbR69M7By8KtntTgrSjjB2cgXsjcZ. 4HGGLQSEZ0_41Twpptg49dHkWRbg4y5.ClP7EkLowUAXzZBbFemQkN9dQ0d8I.U0okNPxavVhJa7 Jc9WJAaabTb8liZjai2Pkun83y4rLaidvAD8Bc5jd6QAsQWTAbU79CUUIl3UfsbvLzMCoEOOvp3t F3gmfzzkUgUudtQUdjN99kwY1clEece3VyxbQ18HC8kq1.gwi428A6VD4qFfZR9A9t0IZaaZelLu 8oII8aDLhBaYtfqln2PFjASJPG6VeYK5pI0yXdzCuOCmikLyGXwNretdU1cMHVtZup8UrCnRhuqw mx81OLSzLMMu43JdFiC5r7dNbg2m.BDhdw340Uyg8snwOB2KpIu1atiAXY3ohW.uCdfuEW5SHZuo fnzPiegvuWFYjs.LGqqZQ7Gpg3GZ0jfBG_DzB3s8If1wr7cKgk51VM0VNJH_m6sgEej_i3OU24JM qZ3ZU6_JyXnXmnVpo9HDDFldHMrEs_MGo7Eyxu7ESTm4KWCGxCKB_hRJLXIi3o5hlLe9YSNv9tg- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sat, 3 Nov 2018 21:32:27 +0000 Date: Sat, 3 Nov 2018 21:32:23 +0000 (UTC) From: Mark Perkins To: Hrpc , Hr-rt Message-ID: <1419803954.21799255.1541280743505@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21799254_2027134812.1541280743503" References: <1419803954.21799255.1541280743505.ref@mail.yahoo.com> X-Mailer: WebService/1.1.12512 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: [hrpc] Internet Architecture Board warns Australian encryption-busting laws could fragment the internet X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 21:32:31 -0000 ------=_Part_21799254_2027134812.1541280743503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Not sure if people had seen this news Internet Architecture Board warns Australian encryption-busting laws could fragment the internet https://www.zdnet.com/article/internet-architecture-board-warns-australian-encryption-busting-laws-could-fragment-the-internet/ Mark P. ------=_Part_21799254_2027134812.1541280743503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not sure if people had seen this news

Internet Architecture Boa= rd warns Australian encryption-busting laws could fragment the internet

https://www.zdnet.com/article/internet-architecture-bo= ard-warns-australian-encryption-busting-laws-could-fragment-the-internet/
Mark P.
------=_Part_21799254_2027134812.1541280743503-- From nobody Sat Nov 3 19:32:12 2018 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 74DA012F1AC for ; Sat, 3 Nov 2018 19:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 PXSp057t1o_4 for ; Sat, 3 Nov 2018 19:32:09 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) (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 E130712F1A6 for ; Sat, 3 Nov 2018 19:32:08 -0700 (PDT) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id wA42U1tI030013; Sat, 3 Nov 2018 22:30:04 -0400 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id wA42Kfdc016641; Sat, 3 Nov 2018 22:20:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23518.22393.46237.953386@gargle.gargle.HOWL> Date: Sat, 3 Nov 2018 22:20:41 -0400 From: bzs@theworld.com To: Mark Perkins Cc: Hrpc , Hr-rt In-Reply-To: <1419803954.21799255.1541280743505@mail.yahoo.com> References: <1419803954.21799255.1541280743505.ref@mail.yahoo.com> <1419803954.21799255.1541280743505@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] Internet Architecture Board warns Australian encryption-busting laws could fragment the internet X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 02:32:11 -0000 And Denmark will require "email encryption" as of 1/1/2019 or in European format 1/1/2019. https://litmus.com/blog/beyond-gdpr-denmark-makes-email-encryption-mandatory This has all become a massive buzzword cargo cult with legislators...they can manage to send/receive stuff on their phone so surely they are expert in how it all works. Apparently Denmark's legislation has chosen to omit the details of what they mean by encryption of emails (end to end? transport? other?) But the article linked below is your usual fantasy legislation. Why not just make cancer illegal? Millions suffer and die from cancer and it costs many billions to treat, we need a law! On November 3, 2018 at 21:32 marknoumea=40yahoo.com@dmarc.ietf.org (Mark Perkins) wrote: > Not sure if people had seen this news > > Internet Architecture Board warns Australian encryption-busting laws could > fragment the internet > > https://www.zdnet.com/article/ > internet-architecture-board-warns-australian-encryption-busting-laws-could-fragment-the-internet > / > > Mark P. > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Sat Nov 3 22:37:33 2018 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 E4A411271FF for ; Sat, 3 Nov 2018 22:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jea4XJFqBuRX for ; Sat, 3 Nov 2018 22:37:30 -0700 (PDT) Received: from sonic305-2.consmr.mail.bf2.yahoo.com (sonic305-2.consmr.mail.bf2.yahoo.com [74.6.133.41]) (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 F0D5B130DCF for ; Sat, 3 Nov 2018 22:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1541309848; bh=FdzSiwqQcxmjFfHQQcQj/WxS6GYyF/yNWR4Rnd3ne/w=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=OoqT1DX6Tf4gbyPFu6BhmnkhsX3IK2NCVWeLs+yiobIljRgsQ6nu21Mzr/bA+/4i7Krk+0GBC9+LBrKn2TgLqusR6/PiuaxaFXruHf/WcJK/MOEGf+7eF+jonIg6EuET6mSOHPNug/yInqbJk5ub83JAjj+D7aj/qzyEbQDlqsctt6zNhGuqtIggDeqYGuE/wxb7sE34QsTuTtCQlP24j9bDA+gJh/CPtDkXqWx3hCV54mlhzc5u2r/U3b1ny+xYHMLrVGTPgLbxeJRZKCkojMwekb17XHmmmDa5izI4JBIc1hdKf8iNS1s6kVDpkjoGIGj7GGKGI+Zi6fg5fdicEA== X-YMail-OSG: z6cyH6oVM1lgTkMoSFXWEeef1vku4rehlEbQGoFv0TZ5hlpQj7V.3pZqw_Qjx_u BffnrPwsKJ3MdILeR4ishoGDuIkHLpiw._rdVzTZQlCwAZYik3ma6QbMwNo633ycc_Ds_xBOleeX ZcerV3GtL0soE_5IyBf_VBiaSBNKZp1ZxQ6zrnZmiCFgSu9noOBtDKZi6pxqVzvuyMOc17S_GmO6 fI0gChbbzOMTejhuT87QcFTZEnds6hw.Mg6SQfFpOoPKPsNSqx6eW2Vh0Ow891_slTxgSwdIv3X4 oRBsvokGHXwnOFRxHNPUIfbU3uNhxjTRrHTyf.cBagdvz7hscfUFbKQldFYZrbdHwxHVc1u5GUfR HmheIPVx_4KpjA3s.kExWXWgCS4kkwX6RRi.oEHEBSjpEt_3c3iJvBkSGIZI4QjuIuv5bg6SOUOT nH5FKe8XhVAiZKzLsYgKspdyJBPWRZOCutb5JDZhL4G2TTAT_aXsir7hnS7p40NjbWZBQRv3GXdT ds_dQ8_qyxRvDcoXgG5_tT9mdfV.aeOT6D84waWXKOvr3ziQTrANlFTElPe2euZNjq3zr_Fe6FIe 6zkm3YQCZOEH973kDJb71DYAI1A0V8AR136BCEVRUK8ZOH0uabFKyCvsdBuIfImP76WtPDhUeWs1 JpqHyKDyzuKyySlYPR6EHa3a2OothFYoGJkJetnMg4AWhJtOKCl20fLGwEHi54okIXmuA0mWFfmL MddNB72ceXnw73gDIKBGHlgbjJxfMqh3bRsGTRHMj7v.qEUI_CT8owp5z7e5g3YrzU0JRSbBp6bD xvYjQ_FybUF_QXPw8mPH7Uh6t6imAYSmBjenYaiJV_9Gn_pXY3J82g.C6DrA8XE2RG88cqg_xJSm I0nUYQR1a9K9fBawvXh_8La5OSF3DDEFxMOg_yADZ7NbbyOui_cBAnRB5W.4zSKvRjDeaAEn61fC kQeMxo70ExDKsHfzAfD.ZFezq3s5aGkYCoJ4URrY3A7xFeQ.RbvYLzWrpwu2fpvZewTHgYqBC4wa gHsXQG2tVJWF6bjWFj4IEh3bxYFhn8rMaCtAzbmstZoNq7KT.sfpE12elRHPBKpZKNAkOW6nx4.U oV96eK7Xf9y8ziipWNgiEP.zNocfHZK_TDFJF.baBL8Lk3w2h9SQWdOv0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sun, 4 Nov 2018 05:37:28 +0000 Date: Sun, 4 Nov 2018 05:27:22 +0000 (UTC) From: Mark Perkins To: Mark Perkins , Cc: Hr-rt , Hrpc Message-ID: <1384177593.21911021.1541309242022@mail.yahoo.com> In-Reply-To: <23518.22393.46237.953386@gargle.gargle.HOWL> References: <1419803954.21799255.1541280743505.ref@mail.yahoo.com> <1419803954.21799255.1541280743505@mail.yahoo.com> <23518.22393.46237.953386@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21911020_1425689451.1541309242019" X-Mailer: WebService/1.1.12512 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: Re: [hrpc] Internet Architecture Board warns Australian encryption-busting laws could fragment the internet X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 05:37:32 -0000 ------=_Part_21911020_1425689451.1541309242019 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable BarryWith a bit of digging into the announcement (with help from Google Tr= anslate), it sems that Denmark is making existing recommendations obligator= y. The existing recommendations seem to be: "What type should we use? As mentioned in the section on rights and obligations above, it is always t= he data controller who, based on his risk assessment, must assess the level= of security that is appropriate. Accordingly, according to the Data Inspec= torate, there would be types of processing where encryption on the transpor= t layer is appropriate and there will be types of treatment where - due to = the high risk of the data subjects - the more secure end-to-end encryption = will be appropriate. This could be the case, for example, if a data control= ler, such as an insurance company, has to send health information about a l= arge number of registrants to a data broker for sending letters. In that ca= se, on the basis of a risk assessment, the data controller may decide that = end-to-end encryption will be an appropriate security measure. Due to ongoi= ng collaboration with the data processor, the two parties have exchanged S = / MIME certificates, so they can send e-mails back and forth to each other,= which is end-to-end encrypted." Mark P. On Sunday, November 4, 2018, 1:32:18 PM GMT+11, wrot= e: =20 =20 =20 And Denmark will require "email encryption" as of 1/1/2019 or in European format 1/1/2019. =C2=A0 https://litmus.com/blog/beyond-gdpr-denmark-makes-email-encryption-m= andatory This has all become a massive buzzword cargo cult with legislators...they can manage to send/receive stuff on their phone so surely they are expert in how it all works. Apparently Denmark's legislation has chosen to omit the details of what they mean by encryption of emails (end to end? transport? other?) But the article linked below is your usual fantasy legislation. Why not just make cancer illegal? Millions suffer and die from cancer and it costs many billions to treat, we need a law! On November 3, 2018 at 21:32 marknoumea=3D40yahoo.com@dmarc.ietf.org (Mark = Perkins) wrote: > Not sure if people had seen this news >=20 > Internet Architecture Board warns Australian encryption-busting laws cou= ld > fragment the internet >=20 > https://www.zdnet.com/article/ > internet-architecture-board-warns-australian-encryption-busting-laws-cou= ld-fragment-the-internet > / >=20 > Mark P. > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -Barry Shein Software Tool & Die=C2=A0 =C2=A0 | bzs@TheWorld.com=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD=C2=A0 =C2=A0 =C2=A0 | 800-T= HE-WRLD The World: Since 1989=C2=A0 | A Public Information Utility | *oo* _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_21911020_1425689451.1541309242019 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry
With a bit of digging into the announcement (w= ith help from Google Translate), it sems that Denmark is making existing re= commendations obligatory. The existing recommendations seem to be:

"What type should we use?

As mentioned in the section on rights and obligations above, it is always=20 the data controller who, based on his risk assessment, must assess the=20 level of security that is appropriate. Accordingly, according to the Data Inspectorate, there would be types of processing=20 where encryption on the transport layer is appropriate and there will be types of treatment where - due to the high risk of the data subjects -=20 the more secure end-to-end encryption will be appropriate. This could be the case, for example, if a data controller, such as an=20 insurance company, has to send health information about a large number=20 of registrants to a data broker for sending letters. In that case, on the basis of a risk assessment, the data controller may=20 decide that end-to-end encryption will be an appropriate security=20 measure. Due to ongoing collaboration with the data processor, the two parties have=20 exchanged S / MIME certificates, so they can send e-mails back and forth to each other, which is end-to-end encrypted."
<= div>

Mark P.


=20
=20
On Sunday, November 4, 2018, 1:32:18 PM GMT+11, <bz= s@theworld.com> wrote:



And Denmark will r= equire "email encryption" as of 1/1/2019 or in
European f= ormat 1/1/2019.

  https://litmus.com/blog/beyond-gdpr-denmark= -makes-email-encryption-mandatory

= This has all become a massive buzzword cargo cult with
le= gislators...they can manage to send/receive stuff on their phone so
surely they are expert in how it all works.
Apparently Denmark's legislation has chosen to omit the de= tails of
what they mean by encryption of emails (end to e= nd? transport? other?)

But the article= linked below is your usual fantasy legislation.

Why not just make cancer illegal? Millions suffer and die from c= ancer
and it costs many billions to treat, we need a law!=

On November 3, 2018 at 21:32 marknoumea=3D40yahoo.com@dmarc.ietf.org (Mark Perkins) wrote:
> Not sure if people had seen this news
> > Internet Architecture Board warns Australian encrypt= ion-busting laws could
> fragment the internet
>
> https://www.zdnet.com/article/<= /a>
> internet-architecture-board-warns-australian-en= cryption-busting-laws-could-fragment-the-internet
> /=
>
> Mark P.

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

--
 =       -Barry Shein

Sof= tware Tool & Die    | bzs@TheWorld.com  =           | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD      | 8= 00-THE-WRLD
The World: Since 1989  | A Public Inform= ation Utility | *oo*

_________________= ______________________________
hrpc mailing list
hrpc@irtf.org
https://w= ww.irtf.org/mailman/listinfo/hrpc

------=_Part_21911020_1425689451.1541309242019-- From nobody Sun Nov 4 01:46:06 2018 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 8BD70130DD5 for ; Sun, 4 Nov 2018 01:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 t5UCZVsip84p for ; Sun, 4 Nov 2018 01:46:01 -0700 (PDT) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D38127133 for ; Sun, 4 Nov 2018 01:46:00 -0700 (PDT) X-Originating-IP: 2.247.248.141 Received: from [172.20.10.5] (x2f7f88d.dyn.telefonica.de [2.247.248.141]) (Authenticated sender: lists@nex.sx) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 152701BF20A for ; Sun, 4 Nov 2018 08:45:57 +0000 (UTC) To: hrpc@irtf.org References: <1c092c82-1620-fa3d-28d9-e61da661a989@sidn.nl> From: Nex Openpgp: preference=signencrypt Autocrypt: addr=lists@nex.sx; prefer-encrypt=mutual; keydata= xsFNBFK5tlgBEADk5RsDbWSxuie0DleV5x7r8K2XE5nvh2uyr+EGrDEC9vv2h73xwKvTf9N2 AARrvvdDvoNbSJ+/v09r5GaibLnFDMg0vwdflSXDCBACFkxvtI4x5/x1MNJFuoNvDBgWP7t5 5VPf2w4Q2mcSPJyi6nBNa90NQdTMnCJXGifEDuj5fnlpIILtx1521STlKXxMH1bJkFY6Y/+0 wzyJdR9DZ98ZqbUDiU/o3UVSlEivzx1YkrP4SwnLGtUn75RIiUkeSaY5Ja4b8VNV5aqwtYI6 gB1tFEazwHWN/mApY7qZIEJXC9LzrgyBOsPeQMzewMV80P67fdB88rtW59oKY8ke7p2XV3UN ZbVuvstJdH1E/M26XKnd7QEOtQAKVQ0/lNy3R58/Re/+0PWPRxmdT9P1WFSY8kUCYartMs7g VLgw9ccROTmw+2fYi67BM/py05Jqd0f9/+IX/M+zx31/wVoXDgE968RWpdjb9LGJxtueLS5u NrbYYXdcfhE3OMZMQuZsCC2gDc3t51qdBJo/2nyEIMahKN2u1nc+UFTciS25tYrrI6VxV0HZ MnKuexCNK+rhAnSrKYWNL7mReDF6i6L3FD4IJ9J0PE8COvQq2bVQYHMVFSGNxrCF75QxIOFL yYi/e7I1LhmHFpo2jxAgtmZvOTXZ4TL8HYvvn834Di/L/9S5AwARAQABzRRUaGUgTmV4IDxu ZXhAbmV4LnN4PsLBmAQTAQIAQgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4ACGQEWIQQF IW87hoSKMDwv433RZvFmc1nYgAUCWfzVKgUJCwWF0gAKCRDRZvFmc1nYgK9DEACaHlXvBl6v JBpCgndDT9BqAQU1QKjpvsgw063vqFGei58tINRSA8p+DARYNWkO4HqJsZnyZXIyrsiqW5lK 4G59Eo9tjrDhJaY6G1rejAQ7tepLyhIveDPKOSxOYuOBzbevzKAdg7ULSEo6zvYdO6u9jiq7 2ZYOLwmxJisfZ98H+a89jgqJde/1B0bbIjtofhelryLMUfKDN8ALBPsC9u01oN7FuuVXwMey LCHpSZHVMwb2HH3llXH9F/VvpMB+Vmgg/4leWN+OYFt/mBQEXrMuF6yu5gYdTvFBGRNPyTE9 adEUIiaU0v0q4qVThvJIUGzuFPqRFb9ToSFet2w4fvzUgB2oTyFiApDv9udY9uoJhhqhvat9 sb9WVjHbcTMhnqZ0HgEzF/uS5iGSyfP+VAbd0mlN9NRbwVOFKh4Bl2zXadsRc7XVngkdQEvT Wnn9jVvlumVIe509l+wlF5zAQWiU5+u/PJGhJQgOQoSC2pQGxlWvlPMHaGgzHdvVIL0vokRZ NltUwcIhCZNnE/sk+8zsvxJdA5RbB9SjmCIARKAp/Vi54O9ctYJ725Zd4eX7V6o8W/7jQ+yB W5PU8mwDbXghg27BjCxSeMu6s9E7tq6T/qz4CGkz+ABekAU0BDYuovGwYW7e2aRcEW0q/Gbl 5nLWZfa4cBvGpgLGALKV+Yrsos7BTQRSubZYARAAxlOtEQkLh16j1iM/6bKvXcdi3VzprCmo DwwrLy5Cs2p5NOw0Fx4IXO5BojqjKJknmzHaq5V4w4z+gdBrH0L1FWP93hw1k8vr1VOkvpd3 mkvO/LpGe0jWM3HnHFgm4BGcbP3/YWFZYpN+C1RlgJX9GsQo7XOz8VxzOw7uh32P8z20M5tL hxwlBawCAYRfyPLvbkPf+uRSNjhxwadsUP8uMR2ivEPTuBqjrcHiCWuN7VlnljUOgbRLpQn4 /usr5nmy6OpngMWnCrc3+HuKp0GuqI29g3oszJGuZbHvOX6F7AqASVZqcyBNfF2GkVxmWR5r uJK5B6BlfhASbfsQ/91cQB0ldUdUX0SCCxkoC9TrrImlakIpYj6rGYA8cl1MEuSi7BAj21th 5NcQti/AiqR4cAp87VpScnkeOwXUBM7IycQrOnsx8TffTWPkgC1bxA2HLl3LEKRLkN7NeE7D q+yh6R/B3w/0zWn5yR7V2Nj/gOpidi0elyRuL+vwQRv8pfVsRr1t8fyFfM6qaadFJvv2cFO4 go74q2CRambzOzJV4oij6gJS9INb6pdgx0vFPOL6Uj3SNlM+tQr37kjWrfeBe9a1PW/Wh/CQ W7U5INBGotzBFz0kvUZeYFB+wEPcQUI36z2EMEdnFqHAOaVGvYU/BsgXudbW07x5uNheYxY8 73kAEQEAAcLBfAQYAQIAJgIbDBYhBAUhbzuGhIowPC/jfdFm8WZzWdiABQJZ/NVJBQkLBYXx AAoJENFm8WZzWdiAyUgP/jE8BVV0sSBooAeSU1MCEUfvuAiUCg3ECNhLvXvSH0IEN/rFW68W 5l79W5xRrRBWi5KKXibO5bB3pqRurKZKCha802bYgZm8GOUOxtLUP09ihOkjteTJN+r7LhXC ltpudwrx0GsYqbYGA6v6Ci6mSfVlCkijmQ4Kn7G9a0Kim+wIUBq2e1L+wwukvPC0kKuQfyx9 FhvnMnFFHBH5qyRGifbAhH/V380ZNFVn6sh3Adu1pc+rIcfy5U+ZNFl/c9HfinaPUcmlG/oG 7u1ne362ep9xDDrO5EK11RY5AM9R0hfdpQ32UdyxeA3RulEekdgLNqtMkgXbbrSIBtjpjwWZ O5lIvvHvoquyADutG7g6Uogu9JJDi3IXRM3d042xNKGGq4/2Nd3ODHW18ZyBQUYHX59KV3pw IzZTCcGgT1sC2bdcJdAF+VBHvoZHa/9oYnEksDGsYn8Y3ENYAFqMar/IUc2Ck66ayuftlHEA kgEuOkgBIZhiOo+iC4B8Lt7PyldV2P5K2iP0GdqnSELGKoGa7qybj0nzawvCr+SzWf1MEIdX 4aPhK7CInX3GOBej8ZZPQijEfHRpkNGVwQW/zQWLmgFo41GnCByPiFQM7k6BaRkQLgDcymMV sdtw9GT0aRBST0iPcgbMPCx6JJ6FINPe3x7z4jcfZzQ7SH3orwQdlsu5 Message-ID: <7bb7d4d3-4121-8952-bc9a-45c7fe74148a@nex.sx> Date: Sun, 4 Nov 2018 09:45:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1c092c82-1620-fa3d-28d9-e61da661a989@sidn.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] Measurement papers on Censorship at IMC2018 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 08:46:04 -0000 On 11/01/2018 07:58 PM, Giovane Moura wrote: > Folks, > > I recommend some papers being presented this week at IMC2018 here in Boston: > > 1. An Empirical Study of the I2P Anonymity Network and its Censorship > Resistance > paper: https://dl.acm.org/authorize?N662657 > > 2. 403 Forbidden: A Global View of CDN Geoblocking > paper: https://dl.acm.org/authorize?N662539 > > 3. Where The Light Gets In: Analyzing Web Censorship Mechanisms in India > papers: https://dl.acm.org/authorize?N662532 > > Full program: https://conferences.sigcomm.org/imc/2018/program/ > > > /giovane The first link you posted actually points to a different paper title "An Empirical Analysis of the Commercial VPN Ecosystem", which I found interesting and actually quite relevant for this group. This is the link to the paper on I2P: https://dl.acm.org/citation.cfm?id=3278565 /nex From nobody Sun Nov 4 02:35:26 2018 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 39B6412426A; Sun, 4 Nov 2018 02:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6_QI-oNw_Ej; Sun, 4 Nov 2018 02:35:11 -0800 (PST) Received: from nuanti.com (nuanti.com [207.192.69.172]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264A312958B; Sun, 4 Nov 2018 02:35:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nuanti.com (Postfix) with ESMTP id 21FFE280E6; Sun, 4 Nov 2018 10:35:10 +0000 (GMT) Received: from nuanti.com ([127.0.0.1]) by localhost (nuanti.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMOd9PsusLUg; Sun, 4 Nov 2018 10:35:09 +0000 (GMT) Received: from [10.66.85.143] (unknown [122.155.35.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alp) by nuanti.com (Postfix) with ESMTPSA id A9343280C3; Sun, 4 Nov 2018 10:35:06 +0000 (GMT) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-6965B59C-C528-496C-AC26-5BC7F7D873CA From: Alp Toker Mime-Version: 1.0 (1.0) Date: Sun, 4 Nov 2018 17:35:00 +0700 Message-Id: References: <908c5ba4-c9da-bd45-069a-ed9ac0a8b8c9@article19.org> In-Reply-To: <908c5ba4-c9da-bd45-069a-ed9ac0a8b8c9@article19.org> Cc: pitg@lists.mayfirst.org, hrpc@irtf.org, gaia@ietfa.amsl.com, hr-rt@irtf.org X-Mailer: iPhone Mail (16A404) Archived-At: Subject: Re: [hrpc] [pitg] IETF 103 PITG schedule (draft, please add) X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 10:35:13 -0000 --Apple-Mail-6965B59C-C528-496C-AC26-5BC7F7D873CA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Small change of plan for those attending. We tried and weren't impressed by o= ur previous choice so the 20:30 get-together will be at Green Garden, a bloc= k down from the venue. We'll gather folks together after the reception. For those following the public interest hackathon, we now have running code o= n RFC8484 (!): https://github.com/ntblk/dns-doh Presentation: Slides: https://github.com/IETF-Hackathon/ietf103-project-presentations/blob/master/= Public%20Interest%20DoH%20Measurement%20-%20NetBlocks%20IETF103.pdf https://twitter.com/netblocks/status/1058995059696140289 Cheers A. > On 26 Oct 2018, at 21:22, Mallory Knodel wrote: >=20 > Hi everyone, >=20 > As promised, below is a handy schedule that I've put together with info > of the meetings and events that might be of interest to engaged or > potentially engaged folks at the IETF 103 in Bangkok. >=20 > Please send any additions to the schedule to the list. >=20 > And please feel free to circulate to folks who are coming to Bangkok. >=20 > =3D=3D=3D >=20 > 3-9 November | IETF 103 | Marriott Marquis Queen=E2=80=99s Park >=20 > * Register here: https://www.ietf.org/how/meetings/register > * Full agenda here: https://datatracker.ietf.org/meeting/103/agenda.html >=20 > 3-4 November @ 9:00-22:00 | IETF Hackathon | Room Sala Thai Ballroom >=20 > * Don't forget to register here: > https://www.ietf.org/registration/ietf103/hackathonregistration.py > * Hackathon wiki page including "Public interest technology" group work > items: > https://trac.ietf.org/trac/ietf/meeting/wiki/103hackathon > * Alp's write up of the hackathon objectives: > https://netblocks.org/news/rights-and-privacy-next-generation-internet-pro= tocol-stack-ietf103-WRAeVWBg >=20 > 4 November @ 10:00-11:30 | Human Rights Review Team meeting | Hackathon >=20 > 4 November @ 20:30 | PITG post-Hackathon dinner | Khing Klao >=20 > * RSVP to alp@netblocks.org >=20 > 5 November @ 9:00-11:00 | HRPC | Chitlada 1 >=20 > * Agenda will be here: > https://datatracker.ietf.org/meeting/103/materials/agenda-103-hrpc-00 >=20 > 5 November @ 17:00-19:00 | PITG meeting | Room Pagoda >=20 > 5 November @ 19:30 | PITG dinner | Veganerie Concept >=20 > * No RSVP required > * Location: Behide Benjasiri Park, tel 02-258-8489 >=20 > 6 November @ 13:50-15:50 | GAIA | Room Meeting 2 >=20 > * Agenda will be here: > https://datatracker.ietf.org/meeting/103/materials/agenda-103-gaia-00 >=20 > 7 November @ 15:40-17:10 | PEARG | Room Meeting 1 >=20 > * Agenda is here: > https://datatracker.ietf.org/meeting/103/materials/agenda-103-pearg-01 >=20 > 8 November @ 16:00-18:00 | Oppressive Terminology side mtg | Room Pagoda >=20 > * Read the draft here: =E2=80=8B > https://datatracker.ietf.org/doc/draft-knodel-terminology >=20 > --=20 > Mallory Knodel > Head of Digital :: article19.org > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > _______________________________________________ > pitg mailing list >=20 > Post: pitg@lists.mayfirst.org > List info: https://lists.mayfirst.org/mailman/listinfo/pitg >=20 > To Unsubscribe > Send email to: pitg-unsubscribe@lists.mayfirst.org > Or visit: https://lists.mayfirst.org/mailman/options/pitg/alp%40net= blocks.org >=20 > You are subscribed as: alp@netblocks.org --Apple-Mail-6965B59C-C528-496C-AC26-5BC7F7D873CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Small change of plan for t= hose attending. We tried and weren't impressed by our previous choice so the= 20:30 get-together will be at Green Garden, a block down from the venue. We= 'll gather folks together after the reception.

For those following the public interest hackathon, we no= w have running code on RFC8484 (!):


Presentation= :

Slides:


Cheers
A.

On 26 O= ct 2018, at 21:22, Mallory Knodel <mallory@article19.org> wrote:

Hi everyone,

As p= romised, below is a handy schedule that I've put together with infoof the meetings and events that might be of interest to engaged or
potentially engaged folks at the IETF 103 in Bangkok.<= br>
Please send any additions to the schedule to the l= ist.

And please feel free to circulate to f= olks who are coming to Bangkok.

=3D=3D=3D

3-9 November | IETF 103 | Marriott Marquis Q= ueen=E2=80=99s Park

* Register here: https://www.ietf.org/how/m= eetings/register
* Full agenda here: https://datatracker.ietf.org/= meeting/103/agenda.html

3-4 November @ 9= :00-22:00 | IETF Hackathon | Room Sala Thai Ballroom
=
* Don't forget to register here:
https://www.i= etf.org/registration/ietf103/hackathonregistration.py
*= Hackathon wiki page including "Public interest technology" group work
items:
https://trac.ietf.org/trac/ietf/meeting/wiki/103= hackathon
* Alp's write up of the hackathon objectives:=
https://netblocks.or= g/news/rights-and-privacy-next-generation-internet-protocol-stack-ietf103-WR= AeVWBg

4 November @ 10:00-11:30 | Human= Rights Review Team meeting | Hackathon

4 N= ovember @ 20:30 | PITG post-Hackathon dinner | Khing Klao

* RSVP to alp@netblocks= .org

5 November @ 9:00-11:00 | HRPC | C= hitlada 1

* Agenda will be here:https://datatracker.ietf.org/meeting/103/materials/agenda-103-h= rpc-00

5 November @ 17:00-19:00 | PITG m= eeting | Room Pagoda

5 November @ 19:30 | P= ITG dinner | Veganerie Concept

* No RSVP r= equired
* Location: Behide Benjasiri Park, tel 02-258-8489<= /span>

6 November @ 13:50-15:50 | GAIA | Room Meet= ing 2

* Agenda will be here:
https://datatracker.ietf.org/meeting/103/materials/agenda-103-gaia-= 00

7 November @ 15:40-17:10 | PEARG | R= oom Meeting 1

* Agenda is here:
= https://datatracker.ietf.org/meeting/103/materials/agenda-103-p= earg-01

8 November @ 16:00-18:00 | Oppr= essive Terminology side mtg | Room Pagoda

*= Read the draft here: =E2=80=8B
https://datatracker.ietf.org/doc/d= raft-knodel-terminology

--
<= span>Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 6= 5A3 B240 BCD9  B071 0C32 A271 BD3C C780
_______________= ________________________________
pitg mailing list
Post: pit= g@lists.mayfirst.org
List info: https://lists.mayfirst.org/mailman/list= info/pitg

To Unsubscribe
       Send email to:  pitg-unsubscribe@lists.mayfirst= .org
       Or visit= : https://lists.mayfirst.org/mailman/options/pitg/alp%40netblocks.org

You are subscribed as: alp@netblocks.org
= = --Apple-Mail-6965B59C-C528-496C-AC26-5BC7F7D873CA-- From nobody Sun Nov 4 05:49:36 2018 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 33C4D1200D7 for ; Sun, 4 Nov 2018 05:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 UjdsEZ3PPZz8 for ; Sun, 4 Nov 2018 05:49:33 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 E7629120072 for ; Sun, 4 Nov 2018 05:49:32 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 1FD766A267; Sun, 4 Nov 2018 14:49:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1541339371; bh=dtgz+G6NXLOd5pVdiZ6PqCAgNXGQuZnz5SkoaTZH3bU=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=KtU+VNb1Ozp+eRbMfnBvb49DojVXpEy4K98bCGCVOpf9uZ+tf+g3sKzJVkSuQSITH 7IFkmgQgePlnp9a9tmXbQZsv3gmBi7HRoPATV8nHm7npjkXAkM4Dlm8YVR213U2LYP q165WpkCs4zncSaPf8hxg/GIMJH8FeYT8qS3b3hAdAr1UEgCtlH0ULnuPp37SoLk/e a8iyGNlzFfKjT21NhZmIilSE9R2s9TNXqOHivZ2aPUcyBynZj7gXpOiXE48bQEwoTB jaleJ3dY3WcXzOBQp1fC1bWbmECsViC7CwneCeGEwO52UE9/sF3Z2BBgTs4Fz6SIas nmF/0FRY3lD9A== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 12C3F3C1387; Sun, 4 Nov 2018 14:49:31 +0100 (CET) Date: Sun, 4 Nov 2018 14:49:30 +0100 (CET) From: Vittorio Bertola To: bzs@theworld.com Cc: Hrpc Message-ID: <927110798.6232.1541339371010@appsuite.open-xchange.com> In-Reply-To: <23518.22393.46237.953386@gargle.gargle.HOWL> References: <1419803954.21799255.1541280743505.ref@mail.yahoo.com> <1419803954.21799255.1541280743505@mail.yahoo.com> <23518.22393.46237.953386@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [hrpc] Internet Architecture Board warns Australian encryption-busting laws could fragment the internet X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 13:49:34 -0000 > Il 4 novembre 2018 alle 3.20 bzs@theworld.com ha scritto: > > > > And Denmark will require "email encryption" as of 1/1/2019 or in > European format 1/1/2019. It is already "required if appriopriate" by the GDPR and would also be explicitly required throughout the EU by several versions of/amendments to the upcoming (maybe) ePrivacy Regulation. Then, of course, no one still knows how to implement proper end-to-end encryption for email in general, as there are too many competing standards for certain things and no standard for others, and it is unclear how you could even get the average user to create and manage their encryption keys without letting the application/service provider do it for them, which turns end-to-end encryption into "managed" end-to-end encryption a la Whatsapp, which means that the content of the message is encrypted for everyone except the recipient... and Facebook. (Though with email you can at least choose your client/service provider, something you can't do with the instant messaging siloses.) But, again, this would be a good challenge for the Internet's technical community. Ciao -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Sun Nov 4 18:37:57 2018 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 1C338129C6B for ; Sun, 4 Nov 2018 18:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 gfQwTpS-fkrG for ; Sun, 4 Nov 2018 18:37:39 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 26D83126BED for ; Sun, 4 Nov 2018 18:37:38 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id y16so11129646qki.7 for ; Sun, 04 Nov 2018 18:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=jMnf4Ozq0LTNtI56YwNFT499bNe827nUvwK0vWe1IX8=; b=LBZjISrAXOEIpjXzdvVMftAdG2ikpCxqPGupXi75dbL4WJW4lRZFKGaRgDTrCaCRzE RyRWE0QSfrFbFTgka5aKAqtb9SrRH0t/HT1I1A+EtMJ+nJxkRT4kQSyIOu66TnuSVimR A4VIRffi5W4Vr8E62Qbqps9nM7trEKhMHtzr5lgSqSbH2wjl0zQiLgZjmczOQwH1fdqN APKTelnW015MlbMV+Sxha1i47KEMBgLYxYN1Cc8YZJX0EjKZ5TWdV5Rd8eAOGoq5icZG 4NbZvgx1CfmhyjvE1D9JomoiJ5YyN2HpRy0HTf871YTg85V+L/3JhIUaxjSCnxwfKDEi gsXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=jMnf4Ozq0LTNtI56YwNFT499bNe827nUvwK0vWe1IX8=; b=RKZBC9M16elZe3oxrUBgozjJ0+v7AbIA3pU/149tpIdIHq0TgstC1YQvQ0ZLsLhjWD BUlOHBxzBD+Cd0xUipt+ZEQ/qGcOIrn1trkblbLVp4OERoal40jDGu2Fkq4/9VGoiFNX nk1ie8DwR+hiUU+NlkRit4FO9k7nDp7kqmhM6hdfltJkgNfZ2Fq9ME5Wk6izeESbrohS KNmLNG+gr8s2wmd/EhIkbtzt3knpDn6JO88cRr083YKPVZXgb/+pCUDVVBBchymBtFp6 yuBrFwoBiXh0AIYOmvrvFXU4LHSLOyZRcLaXs2gq3Wiq+B4vll7dbBVq2l58el5Zz+gy 7/KQ== X-Gm-Message-State: AGRZ1gLaN3+46rtRGBJNE4RixFNbyYw0MIAoq8Os+CoHehZVcNP51CxS Obhu7wVHbllnoAbsOTqKE/O19UnnGfNHk/FVANYkFtu7fog= X-Google-Smtp-Source: AJdET5esSKi8sZIC9UCZb5LcxhkLdMDRzJ72g0xdOMOHd8IfVTfuyrj/JuXQGWYW/WG8ij//IYHAiR5PHMrTZplytYk= X-Received: by 2002:ac8:7181:: with SMTP id w1mr3113954qto.271.1541385457997; Sun, 04 Nov 2018 18:37:37 -0800 (PST) MIME-Version: 1.0 From: Ted Lemon Date: Mon, 5 Nov 2018 09:37:02 +0700 Message-ID: To: Nalini Elkins Cc: Hrpc Content-Type: multipart/alternative; boundary="000000000000afba450579e1c4ef" Archived-At: Subject: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 02:37:42 -0000 --000000000000afba450579e1c4ef Content-Type: text/plain; charset="UTF-8" Hi, I'm reviewing your draft at the moment, and I notice that you use the term "OTT" to refer to the normal use of the Internet, where the Internet is a routing and packet delivery plane, and services operate end-to-end. This is problematic. It implies that the normal functioning of the Internet is exceptional, and that the abnormal use of Internet services to deliver captive services is normal. I think you should not use this term. It seems to me to be actively harmful to human rights to talk about the Internet in this way, as if it is "bypassing" the "natural" control that ISPs ought to be able to exert over users. It's certainly true that ISPs would like to be able to treat us this way, and you address that in a subsequent paragraph. I think the term so use here is "end-to-end," not "over the top." --000000000000afba450579e1c4ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, I'm reviewing your draft at the moment, and I noti= ce that you use the term "OTT" to refer to the normal use of the = Internet, where the Internet is a routing and packet delivery plane, and se= rvices operate end-to-end.

This is problematic.=C2=A0 It= implies that the normal functioning of the Internet is exceptional, and th= at the abnormal use of Internet services to deliver captive services is nor= mal.

I think you should not use this term.=C2=A0 = =C2=A0It seems to me to be actively harmful to human rights to talk about t= he Internet in this way, as if it is "bypassing" the "natura= l" control that ISPs ought to be able to exert over users.=C2=A0 =C2= =A0It's certainly true that ISPs would like to be able to treat us this= way, and you address that in a subsequent paragraph.=C2=A0 =C2=A0

I think the term so use here is "end-to-end," no= t "over the top."


--000000000000afba450579e1c4ef-- From nobody Sun Nov 4 19:52:59 2018 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 7F6F9128CF2 for ; Sun, 4 Nov 2018 19:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 MI70zZSaovqN for ; Sun, 4 Nov 2018 19:52:55 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 7041C126BED for ; Sun, 4 Nov 2018 19:52:55 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 0AD006A267; Mon, 5 Nov 2018 04:52:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1541389973; bh=lAhsEqn4uXplNdwy2nPqeYnuTf0UOAdyLMgiuPfFpDc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=r/Ddf2CDH6lAOVP/GgQOMjMAyoROppLJlvKdhql5xo3ht26tTRxaMeKzVRhwoIxbe f3V7DivZ3NWSSAqngJpKw1bGfdC3qHOP+Dxt5nzBxbhWyQZPYRwvlEHfUaqTcphmzA zULWH4LIlDVQDu67O7+nH7e+y3ibpDeeipwh0gYQnqouVxOcqYelg7JOITGzuPrgP7 QcVADV5wqswDy0N273Ya1JXIA4X2Ydg3+KV84uok9Z/HBv/wD12YbZbnLAiidfokQF m/JwnR9s9nwnB9iCB7szFsZCcin8QsXZYDwURM7O+tMk/0g0POoMHnwKnNXtxuo2rd PcPECJ1IVuB2Q== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id E67D03C0024; Mon, 5 Nov 2018 04:52:52 +0100 (CET) Date: Mon, 5 Nov 2018 04:52:52 +0100 (CET) From: Vittorio Bertola To: Ted Lemon , Nalini Elkins Cc: Hrpc Message-ID: <740537359.6430.1541389972871@appsuite.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6429_104068956.1541389972863" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 03:52:58 -0000 ------=_Part_6429_104068956.1541389972863 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 5 novembre 2018 alle 3.37 Ted Lemon ha scritto: > > Hi, I'm reviewing your draft at the moment, and I notice that you use the term "OTT" to refer to the normal use of the Internet, where the Internet is a routing and packet delivery plane, and services operate end-to-end. > > This is problematic. It implies that the normal functioning of the Internet is exceptional, and that the abnormal use of Internet services to deliver captive services is normal. > > I think you should not use this term. It seems to me to be actively harmful to human rights to talk about the Internet in this way, as if it is "bypassing" the "natural" control that ISPs ought to be able to exert over users. It's certainly true that ISPs would like to be able to treat us this way, and you address that in a subsequent paragraph. > > I think the term so use here is "end-to-end," not "over the top." > I'm the person who introduced the term in the draft, so let me reply: "OTT" is the normal term used today in the ISP/telco industry to refer to anyone providing service over connectivity (though with a difference: in the U.S., as per its original meaning, it still seems to refer mostly just to providers of video/media services like Netflix and Youtube, while in Europe it is now used to refer to GAFAM and any big provider of Internet services that does not also provide connectivity). It does not have any negative implication, it's just a way to distinguish the two layers of network and application. (The first few references I found with Google about the European use of the OTT and ISP terminology: http://netecon.eurecom.fr/NetEcon2016/papers/Antonopoulos.pdf http://www.academia.edu/35287868/OTT-ISP_Joint_Service_Management_A_Customer_Lifetime_Value_Based_Approach http://www.hybrid.univ-paris8.fr/lodel/index.php?id=715&lang=en while Wikipedia still seems to have mostly the U.S. meaning, though it then refers to OTT messaging etc: https://en.wikipedia.org/wiki/Over-the-top_media_services ) I'm open to suggestions for other terms, as long as they can be understood; I'm not aware of any other standard terminology to indicate this dichotomy. (Separately, I am also wondering who qualified the "normal functioning of the Internet" as relying on a few big companies providing most of the services we use every day in exchange for tracking us, or even as being inherently positive for human rights in general, but that would be another discussion.) Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_6429_104068956.1541389972863 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 5 novembre 2018 alle 3.37 Ted Lemon <mellon@fugue.com> ha scritto:

Hi, I'm reviewing your draft at the moment, and I notice that you use the term "OTT" to refer to the normal use of the Internet, where the Internet is a routing and packet delivery plane, and services operate end-to-end.

This is problematic.  It implies that the normal functioning of the Internet is exceptional, and that the abnormal use of Internet services to deliver captive services is normal.

I think you should not use this term.   It seems to me to be actively harmful to human rights to talk about the Internet in this way, as if it is "bypassing" the "natural" control that ISPs ought to be able to exert over users.   It's certainly true that ISPs would like to be able to treat us this way, and you address that in a subsequent paragraph.   

I think the term so use here is "end-to-end," not "over the top."
I'm the person who introduced the term in the draft, so let me reply: "OTT" is the normal term used today in the ISP/telco industry to refer to anyone providing service over connectivity (though with a difference: in the U.S., as per its original meaning, it still seems to refer mostly just to providers of video/media services like Netflix and Youtube, while in Europe it is now used to refer to GAFAM and any big provider of Internet services that does not also provide connectivity). It does not have any negative implication, it's just a way to distinguish the two layers of network and application.

(The first few references I found with Google about the European use of the OTT and ISP terminology:
while Wikipedia still seems to have mostly the U.S. meaning, though it then refers to OTT messaging etc:
)

I'm open to suggestions for other terms, as long as they can be understood; I'm not aware of any other standard terminology to indicate this dichotomy.

(Separately, I am also wondering who qualified the "normal functioning of the Internet" as relying on a few big companies providing most of the services we use every day in exchange for tracking us, or even as being inherently positive for human rights in general, but that would be another discussion.)

Regards,

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_6429_104068956.1541389972863-- From nobody Sun Nov 4 19:59:59 2018 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 4381F130E17 for ; Sun, 4 Nov 2018 19:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 NUSiwNdZBXXJ for ; Sun, 4 Nov 2018 19:59:51 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 EA7D0130E77 for ; Sun, 4 Nov 2018 19:59:50 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id d19so12542695qkg.5 for ; Sun, 04 Nov 2018 19:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bFyYTC917BRbiA1ZsddVCKY98oFdRW4CaPTAfTmuAXo=; b=Aq0BoKSIDaiiznNiNl6Rd9naTFYR/O6YYDBedq5gsQYtn700D5pjSdkcUvl60iJYbG thbyBAjTSSGuFRZbs03794kQwCySU1ILKnVp1yC96Gwb+faHI8p7yb5nYCi6Hn71o0df W5ngA8KJZOYnKyxfVUpRDZoJaN26BzZsWNevfivKT0PMVWd+66ULv+FFIm/3OwsOYmlO Y9Y1uQdYsW+DMnPfiIPUZqD4sGX7/+NBY9kIXLTwunbECBEj7J9utlZX+ZIywO6OumGR zv9F4P6OQwRcKCc1KkuTnZrq/Y+M/f4p8fHs6pAk8ez4tw1x6oz4gm1kkfgBBiKD1Rs2 KYvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bFyYTC917BRbiA1ZsddVCKY98oFdRW4CaPTAfTmuAXo=; b=N0pRakFxV4PIiz7P9ZVo7YxlrKC4EzLVv0DptBJaRA0QSPsOFA1zGweUtbbEs4MfAr Rp/0OCPXp/tUVv9pTj+xdjGYDhNIXz+vZxRL9vJ75U2HJrnw0GhD7RUUS19Tw89WhWiH vzZO8kU9eyzfnLsAdOOVrsswP1xTwa/xj33s21sHiL0Gj9NHVkUBLs8XwpyKDCpYIWUi zcI44GqsxpXFxxbvlhkyR/pPmTUhCdiMjMu8kPsP66iHIa8syu9X9ayeHOvpGkRH2pbV SD6/xYQPOWdwffWANqZrA5y7TE4+zmggDzFwPLGC3lV4zsOlD4ZwLS9gFoH3XjFvJKif /U3A== X-Gm-Message-State: AGRZ1gLI/NI1JmeyIwBQOymB25zmazs9udTyT/4WCp3vTcHoeueuty0q rbkByt+s31f5fJdLeBWRdbKB7a3O7+6b2gLAw6zjWw== X-Google-Smtp-Source: AJdET5dBqZeS9oj5fkDERS6tGW8QVcklzM9PuHveFwrdtmPx37mqR17a1mHZonC7Som+mVOfm4ddXQa/Kme2jYAFnpg= X-Received: by 2002:ac8:24d4:: with SMTP id t20mr8408156qtt.43.1541390389947; Sun, 04 Nov 2018 19:59:49 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> In-Reply-To: <740537359.6430.1541389972871@appsuite.open-xchange.com> From: Ted Lemon Date: Mon, 5 Nov 2018 10:59:13 +0700 Message-ID: To: Vittorio Bertola Cc: Nalini Elkins , Hrpc Content-Type: multipart/alternative; boundary="000000000000a745660579e2ea50" Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 03:59:57 -0000 --000000000000a745660579e2ea50 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 5, 2018 at 10:52 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > I'm the person who introduced the term in the draft, so let me reply: > "OTT" is the normal term used today in the ISP/telco industry to refer to > anyone providing service over connectivity > In other words, anyone who is using end-to-end service on the internet. I realize that there are reasons to want to sneak this into an RFC as a term of art. This is what I am asking the working group to not do. The fact that it is in common use is not the point. > --000000000000a745660579e2ea50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5,= 2018 at 10:52 AM Vittorio Bertola <vittorio.bertola@open-xchange.com>= ; wrote:
=20 =20 =20
I'm the person who introduced the term in the draft, so let me r= eply: "OTT" is the normal term used today in the ISP/telco indust= ry to refer to anyone providing service over connectivity

In other words, anyone who is using end-to-end = service on the internet.=C2=A0

I realize that ther= e are reasons to want to sneak this into an RFC as a term of art.=C2=A0 =C2= =A0This is what I am asking the working group to not do.=C2=A0 =C2=A0The fa= ct that it is in common use is not the point.
=20
--000000000000a745660579e2ea50-- From nobody Sun Nov 4 20:11:13 2018 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 82617128BCC for ; Sun, 4 Nov 2018 20:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 19EVAKQYlmZM for ; Sun, 4 Nov 2018 20:11:09 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 64E55128B14 for ; Sun, 4 Nov 2018 20:11:09 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id A1CA46A267; Mon, 5 Nov 2018 05:11:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1541391067; bh=SRrUdCikyUxROwYWLMwtWNN4q0TC9mKMxe+YPHbdcoo=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=v25PkAZWYnEo1/5fG6OW0nzQEQYxaxno44y2iL01IKq0PdCpE9JSPZ6aanfMhiz+E n+e7QknfGPjg43s47/Q9REifuRD9JFgy7FU7LNW1y4++nO/eKD+BekLQSFQT4s3dVG 8iJ1LJ64uWwVh12a9pJcHXFnmyZA5GuwJHc3CSTCsgVbMssVRNAA7cNvOjGIlhaBZS +FUawC3hCa8eYCGyZgmPNI2yZc5WO7EMY9WebpiRGzUKy0OKhVkbeNnouLTGx8XW44 gV3m7ZTwFsM/tifovVV5KDudNAj8bnT1dz3UrqZEVdLLROR7GdmnBPjRqCC3ta3anc QBM9ov/SjwRgw== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 96FAA3C0024; Mon, 5 Nov 2018 05:11:07 +0100 (CET) Date: Mon, 5 Nov 2018 05:11:06 +0100 (CET) From: Vittorio Bertola To: Ted Lemon Cc: Hrpc , Nalini Elkins Message-ID: <2052205710.6437.1541391067525@appsuite.open-xchange.com> In-Reply-To: References: <740537359.6430.1541389972871@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6436_1167499640.1541391067517" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 04:11:11 -0000 ------=_Part_6436_1167499640.1541391067517 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 5 novembre 2018 alle 4.59 Ted Lemon ha scritto: > > On Mon, Nov 5, 2018 at 10:52 AM Vittorio Bertola < vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com > wrote: > > > > I'm the person who introduced the term in the draft, so let me reply: "OTT" is the normal term used today in the ISP/telco industry to refer to anyone providing service over connectivity > > > > > > In other words, anyone who is using end-to-end service on the internet. > > I realize that there are reasons to want to sneak this into an RFC as a term of art. This is what I am asking the working group to not do. The fact that it is in common use is not the point. > But also ISPs offer end-to-end services at the application level - the point here is whether the service is bundled with connectivity or not, as this changes the dynamics in terms of business, and also of regulation, jurisdiction, scale and centralization. And no, I am not trying to "sneak this into an RFC", I am just using the term that everyone has been using in all the recent discussions I've been having on this matter. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_6436_1167499640.1541391067517 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 5 novembre 2018 alle 4.59 Ted Lemon <mellon@fugue.com> ha scritto:

On Mon, Nov 5, 2018 at 10:52 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote:
I'm the person who introduced the term in the draft, so let me reply: "OTT" is the normal term used today in the ISP/telco industry to refer to anyone providing service over connectivity

In other words, anyone who is using end-to-end service on the internet. 

I realize that there are reasons to want to sneak this into an RFC as a term of art.   This is what I am asking the working group to not do.   The fact that it is in common use is not the point.
But also ISPs offer end-to-end services at the application level - the point here is whether the service is bundled with connectivity or not, as this changes the dynamics in terms of business, and also of regulation, jurisdiction, scale and centralization.
And no, I am not trying to "sneak this into an RFC", I am just using the term that everyone has been using in all the recent discussions I've been having on this matter.
Regards,

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_6436_1167499640.1541391067517-- From nobody Sun Nov 4 20:51:34 2018 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 97628128CF2 for ; Sun, 4 Nov 2018 20:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8az00Cb4aHbj for ; Sun, 4 Nov 2018 20:51:30 -0800 (PST) Received: from mail-yw1-f50.google.com (mail-yw1-f50.google.com [209.85.161.50]) (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 3EF09128B14 for ; Sun, 4 Nov 2018 20:51:30 -0800 (PST) Received: by mail-yw1-f50.google.com with SMTP id j202-v6so3138847ywa.13 for ; Sun, 04 Nov 2018 20:51:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=d7URb6iTEB9O7ey4jAm5hhYy9hHAXGnQyRMsluMdgLI=; b=SV8vO1IcH5LPjFt1cfS30/FgJ+McmnQ2TB2LrrIdmKYN05RtJKECngu082Rm8UmqrO D9yE4rCbzIJuVaaizSTExHOn/UKYnVcbqnNrMOEtfJDCeahjaKNqJrPjxC+IQbH31CUC qzbQY+ypGp6v2ethBCthEmxFb51GyfPy65xsCBxCIG6OhczRTFkyrpIB8UFHBIQDCxBN yVLZ2DLOfgyIV6y+YECdUC2oVUL14zRruZpXkd8h53CsMf4DmdjieHiMGqWnD4kVAUHi Zqb2hVYQ91vyJ9HGLc03jysdt158C7D4wHa1N7F7YIcitXY7eHONl4J9aXoczjVWCYec 6doA== X-Gm-Message-State: AGRZ1gJgpkILnEwPsRDnJ9XbnLCWbp2D0b7XBtbIU5KEtn29WS/IZS/V hZeN6QGxlbkds1DLBLsfqThhzOk8nfxNKfpm2g== X-Google-Smtp-Source: AJdET5fbjh9j4qNJKYD5Xj9sKbIB/q7TyDjkqWFrK4LEDtfbyaN+QMCFZUBX+gHWj7BQNP/iwaQYA2FoZQAB1sLj/kw= X-Received: by 2002:a0d:cf85:: with SMTP id r127-v6mr20388657ywd.109.1541393489165; Sun, 04 Nov 2018 20:51:29 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> In-Reply-To: <2052205710.6437.1541391067525@appsuite.open-xchange.com> Reply-To: joly@punkcast.com From: Joly MacFie Date: Sun, 4 Nov 2018 23:50:52 -0500 Message-ID: To: vittorio.bertola@open-xchange.com Cc: mellon@fugue.com, hrpc@irtf.org, Nalini J Elkins Content-Type: multipart/alternative; boundary="0000000000006183440579e3a3f0" Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 04:51:32 -0000 --0000000000006183440579e3a3f0 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 4, 2018 at 11:11 PM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > But also ISPs offer end-to-end services at the application level - the > point here is whether the service is bundled with connectivity or not, as > this changes the dynamics in terms of business, and also of regulation, > jurisdiction, scale and centralization. > As an example, some of my telecom friends, e.g Fred Goldstein, talk about VUIP to describe some ISP's phone offerings = Voice Under IP. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - --0000000000006183440579e3a3f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Nov 4, 2018 = at 11:11 PM Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
=20 =20 =20

But also ISPs offer end-to-end services at the application level - the p= oint here is whether the service is bundled with connectivity or not, as th= is changes the dynamics in terms of business, and also of regulation, juris= diction, scale and centralization.=C2=A0

<= /div>
As an example, = some of my telecom friends, e.g Fred Goldstein, talk about VUIP to describe= some ISP's phone offerings =3D Voice Under IP.=C2=A0




--
------------= ---------------------------------------------------
Joly MacFie=C2= =A0 218 565 9365 Skype:punkca= st
--------------------------------------------------------------=
-
--0000000000006183440579e3a3f0-- From nobody Sun Nov 4 21:12:17 2018 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 8512612F1AC for ; Sun, 4 Nov 2018 21:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 SToHq8E_R1Wl for ; Sun, 4 Nov 2018 21:12:14 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) (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 93AA4130EF7 for ; Sun, 4 Nov 2018 21:12:11 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id wA55BPum005949; Mon, 5 Nov 2018 00:11:27 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id wA555h8B021768; Mon, 5 Nov 2018 00:05:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23519.53159.467990.833045@gargle.gargle.HOWL> Date: Mon, 5 Nov 2018 00:05:43 -0500 From: bzs@theworld.com To: Mark Perkins Cc: Mark Perkins , , Hr-rt , Hrpc In-Reply-To: <1384177593.21911021.1541309242022@mail.yahoo.com> References: <1419803954.21799255.1541280743505.ref@mail.yahoo.com> <1419803954.21799255.1541280743505@mail.yahoo.com> <23518.22393.46237.953386@gargle.gargle.HOWL> <1384177593.21911021.1541309242022@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] Internet Architecture Board warns Australian encryption-busting laws could fragment the internet X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 05:12:17 -0000 A quick and very informal statistical glance at the ratio of successful vs unsuccessful SMTP TLS connections at this ISP (TheWorld.com) showed about 10% success. Granted that might be skewed by the number of totally insincere attempts by spammers and similar. But sometimes things look different from the trenches. I'm a little disturbed that the soon to be mandatory Danish recommendations specifically call for S/MIME certificates. There's nothing wrong with them -- well there are problems, everything has problems, e.g., EFAIL -- but there are other alternatives. I'll hope one can read that as "...or equivalent industry standard encryption methods". Another problem which leaps to mind is that email delivery is inherently store-and-forward which means a message might travel through various jurisdictions before final delivery. The bigger point is the sentiments might be laudable but the practical issues loom nonetheless. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Sun Nov 4 21:25:58 2018 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 22F8E128A6E for ; Sun, 4 Nov 2018 21:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 NQarswr_TFki for ; Sun, 4 Nov 2018 21:25:54 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 948E01277C8 for ; Sun, 4 Nov 2018 21:25:54 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id a132so12810552qkg.1 for ; Sun, 04 Nov 2018 21:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nt/+cdyFcwXbZ+ST0SvSgwNrHbgA2X0aqiacXIF8v/A=; b=mM+k78G5bFCGaeYOy+dv5O0eI/Llj4xOGBEZacW87/MdB/m+ZYwtBTQHZdcLbaopx4 aYFx3SUR3PQllNzeTbhwbbA72Si2dihUKub32fp1VB93P0R3vhftYYz6uY2cPZHOQnDC A9Yz7VxM8pJwkQZLnEnuKmjq6KSj8FUhqlydqj/lOfvDDT8bQVuzNgxHTGPfs0tfeJmm JHmLJJut376ADw0c7PQbP1it529QdHM4e53MNcb+EwH20gZgb1eMEE52q0IoBuB6mPeL 8rquQyVYcV7XhCM5/gjZOl0nP7itwzSkEzarpd5AiXKfR3+5ZrbapA/6P0JNdK/4dsKw xNXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nt/+cdyFcwXbZ+ST0SvSgwNrHbgA2X0aqiacXIF8v/A=; b=bf+vj3v1q7OKWzyOBLv0j6K4JDCQ0uW/X3D0fHqvodorPJKs9q+KTtxtAMS8am8eGE PLOyh/T4OACcw+6yZbblYLFvFHKZjSPtwz1G9UdFnkCXZray6poRvq5bRMOE6TTlxZ80 IvdAmj3/sKuKww5zWChxRj8nC8f2eEoyLlgz0IUn0he7+r7Iw/RwChLC5E/hAyc4B/0k 7TlT1VulN++7i1227LarOxgBLp6l9Z0oqz82xyBw32qZmh3yX5CI+9zaLXH9mgt391K5 iWVw6TfYysxMqGMRD4kIa+HI9ckarGHd7fuLsT2hc8W514U0Xv4l1kEoPPPprd48POUA wtZA== X-Gm-Message-State: AGRZ1gIya9Gio6f7MFr54SS4xkOQPTmhDvdQ45l4MR6QFXXgkKpRNLvZ wiPFgDfAIsTe3ufudH+bdX5FGLCGjfJvHEZJCeb3yi1jnlI= X-Google-Smtp-Source: AJdET5crbN7gxjG29nDrTtZ/T9h8BplQTtmMYm1RKQA77DUpwjD9nmhGs+zqk6wowQjvFzxxg48jQrSCbi0QbV+A2VY= X-Received: by 2002:a0c:c966:: with SMTP id v35mr20421974qvj.45.1541395553578; Sun, 04 Nov 2018 21:25:53 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> In-Reply-To: <2052205710.6437.1541391067525@appsuite.open-xchange.com> From: Ted Lemon Date: Mon, 5 Nov 2018 12:25:17 +0700 Message-ID: To: Vittorio Bertola Cc: Hrpc , Nalini Elkins Content-Type: multipart/alternative; boundary="0000000000006e09260579e41e72" Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 05:25:57 -0000 --0000000000006e09260579e41e72 Content-Type: text/plain; charset="UTF-8" I hear you. But I am asking you to not use this term, because of its connotations. The term is antithetical to the culture of the IETF. On Mon, Nov 5, 2018 at 11:11 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 5 novembre 2018 alle 4.59 Ted Lemon ha scritto: > > On Mon, Nov 5, 2018 at 10:52 AM Vittorio Bertola < > vittorio.bertola@open-xchange.com> wrote: > > I'm the person who introduced the term in the draft, so let me reply: > "OTT" is the normal term used today in the ISP/telco industry to refer to > anyone providing service over connectivity > > > In other words, anyone who is using end-to-end service on the internet. > > I realize that there are reasons to want to sneak this into an RFC as a > term of art. This is what I am asking the working group to not do. The > fact that it is in common use is not the point. > > But also ISPs offer end-to-end services at the application level - the > point here is whether the service is bundled with connectivity or not, as > this changes the dynamics in terms of business, and also of regulation, > jurisdiction, scale and centralization. > And no, I am not trying to "sneak this into an RFC", I am just using the > term that everyone has been using in all the recent discussions I've been > having on this matter. > Regards, > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --0000000000006e09260579e41e72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I hear you.=C2=A0 =C2=A0But I am asking you to not use thi= s term, because of its connotations.=C2=A0 =C2=A0The term is antithetical t= o the culture of the IETF.

On Mon, Nov 5, 2018 at 11:11 AM Vittorio Bertola <vittorio.bertola@open-xchange.com&g= t; wrote:
=20 =20 =20

Il 5 novembre 2018 alle 4.59 Ted Lemon <mellon@fugue.com> ha scritto:=20
=20
On Mon, Nov 5, 2018 at 10:52 AM Vittorio Bertola <=20 vittorio.bertola@open-xchange.com> wrote:=20
I'm the person who introduced the term in the draft, so let me = reply: "OTT" is the normal term used today in the ISP/telco indus= try to refer to anyone providing service over connectivity

In other words, anyone who is using end-to-end service on the interne= t.=C2=A0

I realize that there are reasons to want to sneak this into an RFC as= a term of art.=C2=A0 =C2=A0This is what I am asking the working group to n= ot do.=C2=A0 =C2=A0The fact that it is in common use is not the point.
But also ISPs offer end-to-end services at the application level - the p= oint here is whether the service is bundled with connectivity or not, as th= is changes the dynamics in terms of business, and also of regulation, juris= diction, scale and centralization.
And no, I am not trying to "sneak this into an RFC", I am just= using the term that everyone has been using in all the recent discussions = I've been having on this matter.
Regards,

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--0000000000006e09260579e41e72-- From nobody Sun Nov 4 22:15:49 2018 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 5644512F18C for ; Sun, 4 Nov 2018 22:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 x58pDzVsGzHq for ; Sun, 4 Nov 2018 22:15:45 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 B81B112EB11 for ; Sun, 4 Nov 2018 22:15:44 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id f23so705586lfc.13 for ; Sun, 04 Nov 2018 22:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9ZoqvFSA4W2ltUKwI8OKWcRsSpjl4RrrtFpfISbkoLk=; b=phWZgEVF9G41rlUCuT/T05QDtBGB5AWg0tHDTQ5XkyfnCNe0jHipNg1nBRRJFerA14 /4sNl0nBtTAFR7i95ZplqEtu8NYEWLpW8gL9szpwkvdYm/jVfdRvZiWQJ9kNE6mjmiKM RBHF6awwIj0SHzdtlEw7S/Ae043BFwVv4vs1tpCDohXF5pkLLmG3PBf1qOX7vcmBZeth +kJcy/zG9aR2BVWWlE8VRc5d+dgwbaQVtVkPdfmfD02LlA1Sl86wJh7KtDBS4dAenfIN 2Ecx3V1b8SK5ZMGgtbVQ0VWvRuDeK0WzLgcI/kIgzQTaWhzbLwRE/1IR0MXLDbwWLlhO owBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9ZoqvFSA4W2ltUKwI8OKWcRsSpjl4RrrtFpfISbkoLk=; b=o9V31EVu0xEL0hXd9C4O0NSWUne+VGeTrjZN+i7tc9cKZoRkEYpqS1HbxFXld4yzr1 ihxjdays0qOU0POcKz5eiwe8d5mbFsao6eVCfUVevXY13KNeJyT+KVHkvQf7VuaLR3m6 nGpAjDG6/1Hpi6nxjrauk3fekE3U86oVOrWG5iEk8E0E4dYelDesj4sH/A85G7hoKdNR 4NvX/8RP/5evGfRwvFAp3o17zhi3CPXMC4cpPwHR/w/w8RDKD27jOxj/bt+rGGzqpETC I4GY3JJo1bLwDc5KoWKsfyU+2WIn/cU8HPRlQ+44+FPtYCrsgzxKFgb/ayMdUvy95flQ ZjsA== X-Gm-Message-State: AGRZ1gIRwS8v4d5IUWjBR2UHSROuDXvjn1mEOvTE8Oj4CHjClLukdFyX GILuKrQr/Q5B946hkK8hcUAGL5s4d/dKpvkGYO0= X-Google-Smtp-Source: AJdET5cDqztePO/fuufOFvWfIC9fPGd6dZUwvPfu7f1cAAdWa3NNc5noXHUqjD5+zCIujY1IDwQrnEDHy251HpLuMhc= X-Received: by 2002:a19:920a:: with SMTP id u10mr1865323lfd.122.1541398542764; Sun, 04 Nov 2018 22:15:42 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> In-Reply-To: From: Seth Johnson Date: Mon, 5 Nov 2018 01:15:04 -0500 Message-ID: To: Ted Lemon Cc: vittorio.bertola@open-xchange.com, Hrpc , nalini.elkins@insidethestack.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 06:15:47 -0000 I am in complete agreement with Ted. OTT is a term with lots of industry and ITU context baggage, connected to standards developed for a vertically integrated telecom environment that has yet to properly recognize the normal functioning of the actual Internet to which he refers (nor best efforts or application-agnostic packet relaying, for that matter), for a facilities-based mode of competition rather than the open environment that gave us that normal functioning simply as a way to interoperate in that type of competitive environment among autonomous nodes on the basis of voluntary consensus standards. I find that the term OTT is used to code in the implication that a certain type of environment is the substrate that such "OTT" apps depend on, ride "over the top" of. Referring to an applications layer instead should do the work of representing what we who participate as independent and equal autonomous peers in the network of networks mean when we engage in consensus standards for our Internet. It should also be noted that at this moment the ITU Plenipotentiary conference is developing their next 4 years framework with a strong reference to "OTT" and building on this flawed set of premises. Seth On Mon, Nov 5, 2018 at 12:26 AM Ted Lemon wrote: > > I hear you. But I am asking you to not use this term, because of its co= nnotations. The term is antithetical to the culture of the IETF. > > On Mon, Nov 5, 2018 at 11:11 AM Vittorio Bertola wrote: >> >> >> Il 5 novembre 2018 alle 4.59 Ted Lemon ha scritto: >> >> On Mon, Nov 5, 2018 at 10:52 AM Vittorio Bertola < vittorio.bertola@open= -xchange.com> wrote: >> >> I'm the person who introduced the term in the draft, so let me reply: "O= TT" is the normal term used today in the ISP/telco industry to refer to any= one providing service over connectivity >> >> >> In other words, anyone who is using end-to-end service on the internet. >> >> I realize that there are reasons to want to sneak this into an RFC as a = term of art. This is what I am asking the working group to not do. The = fact that it is in common use is not the point. >> >> But also ISPs offer end-to-end services at the application level - the p= oint here is whether the service is bundled with connectivity or not, as th= is changes the dynamics in terms of business, and also of regulation, juris= diction, scale and centralization. >> And no, I am not trying to "sneak this into an RFC", I am just using the= term that everyone has been using in all the recent discussions I've been = having on this matter. >> Regards, >> >> -- >> >> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange >> vittorio.bertola@open-xchange.com >> Office @ Via Treviso 12, 10144 Torino, Italy > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Sun Nov 4 22:20:20 2018 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 088ED12F1A6 for ; Sun, 4 Nov 2018 22:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 7HQQu_5alTIY for ; Sun, 4 Nov 2018 22:20:13 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 E0A8A12D4F1 for ; Sun, 4 Nov 2018 22:20:12 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id w22-v6so595083plk.0 for ; Sun, 04 Nov 2018 22:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=TKBezCE54welYLXpIBIkrzITgw9WF1Z/x3ZgDS7U+EA=; b=xni7zUfeFjaIzoIQZz2yggU74vTN2nI5Sidd3Fs8J/LShak5FuNmDdUUvYErm7Js2m jP2Ar1R5ZN+pLUjqjz57PZVH2jMo8cMYHNmNKXxiBMzKgTpYXfvUBufK8son1sKNYyxx 9P8zGE6sGpdoKAiFJiy91Sfh5tCeh9chln+zay743IDSCRTMoWvJToqiuNaIlkL/Uto7 41nGxFLXcRRqK4RHu+n6ZDq4lul/mJVgEpw+GhRHMELrwMiua6H/J9mz/SPY6uxfIGdq DJeF7jRoZAxA8MSKKI/2MsSVDTxDKt3mNmzE+eFwBtlVn2fbxqZySxbcbsoBVMu0zDe8 IdRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TKBezCE54welYLXpIBIkrzITgw9WF1Z/x3ZgDS7U+EA=; b=UpNTxQ4JFr+Lk8pMp+ZXypBoJVG2itwMELdj7ISKgHB9R4JK5xLCUcoMcXEo/5zRrB RNBUlKluF83AoBxFDDHQDPo+VLyMsVabDBe+RiVnZWx/69BIZm3sW3AYYW5pnkcEg3zl gc0gUPijhGcoeuVHdcXPUOEVtMoZChVAApdC2aL8J/l/tZrcRA90GfuriWW/ez81jg6V Hxz4TQmDMA0q5mDMYLoedxLmX21T6+SrBrxmbOLBg8l2OusXv/Q4g+Okds+9rfh8OYqI cIBzR3Ai63j/ubHUR9hnGkkBkhoT566efYaYU/WfF7oS0c2DFQvpJjPAi0teAYFKhPdM 17IQ== X-Gm-Message-State: AGRZ1gIvh+QxNqHeBuuEmDu6GCcULjv9RPYU9Wg4ppcjoMLHsWduPwqu ZQVa1UDM3OtpfBuSI0m30qRoo2G+6u8+ X-Google-Smtp-Source: AJdET5fmEQPDzO4UU8uwsjtUqeaDuXqhVfY1SZg8U1rQxBOT4G6dPiJt37loti5ZPktqpwzoFdrEsw== X-Received: by 2002:a17:902:b7c5:: with SMTP id v5-v6mr9292567plz.40.1541398812066; Sun, 04 Nov 2018 22:20:12 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:3823:e159:70b:e436? ([2001:67c:1232:144:3823:e159:70b:e436]) by smtp.gmail.com with ESMTPSA id d126-v6sm62571077pgc.32.2018.11.04.22.20.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 22:20:11 -0800 (PST) To: hrpc@irtf.org References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> From: Melinda Shore Message-ID: Date: Mon, 5 Nov 2018 13:20:09 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 06:20:17 -0000 On 11/5/18 1:15 PM, Seth Johnson wrote: > It should also be noted that at this moment the ITU Plenipotentiary > conference is developing their next 4 years framework with a strong > reference to "OTT" and building on this flawed set of premises. My concern has less to do with the ITU-T and more to do with being clear in communication with this (IETF) community. I don't think that it's familiar terminology in the IETF and its use could lead to some confusion among people reading the document. My bias in looking at the tradeoffs in jargon use is to always choose clarity. Melinda From nobody Sun Nov 4 22:30:04 2018 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 25D6312F1A5 for ; Sun, 4 Nov 2018 22:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ROVOrSNAF8Ru for ; Sun, 4 Nov 2018 22:30:00 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 B4E4312EB11 for ; Sun, 4 Nov 2018 22:29:59 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id n26-v6so5293697lfl.1 for ; Sun, 04 Nov 2018 22:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vugDwsNtGI81gb1gfuPOkwkgT9TuNlCrG+H+NNOUWi8=; b=tmE0fmUXxxtHsT3BlhoVCszIt6QOhEo8h+G/Tf9sf8EIx2Bz+PaIYhWj/f/SIkg1DK AM6F6viQAAwsLMBDzE2oAkkvf0TQvIAcVwPYzQlsbodvucEoUbhOeqE1RVs1vo+wKwko z63QNLHiqfE0VEDFB8Pl7S/fzPWiCcqxh7SXyym+Zv6MENO2D2zR/cnIIgAZRaIVZQrY hgWb+LuIQMaLTj5FQcPL0NjlWlqQTD66nkbUPAKWlSaXUe5g3o1eTBOjVRslXxK4MLxy Exxmopw0GphWyDQns/KCLBkXTOVmAnM8x7f5ALqp3ROTXsztZhX5jXRoSnQ3W5xRU0mk co6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vugDwsNtGI81gb1gfuPOkwkgT9TuNlCrG+H+NNOUWi8=; b=BPTMFmVk6vhaSWKYk4QzULNdIU4OM5AkgQJphB7tQJ7jAjVLu5a9Hmvy3iNVrsoTqK 0CuTwWa/kAPF0MzHzHdzfIHfPDw6QYU2i5Ov1aVI5B38VATp1QzhpQ94gzkOMBkOBsTR 87pJnUDDmijax9kBffwUpCW1CUa6Qykbxmsg8pkyeJdOWF5mInvUNPFQEIVW0t0Qb2yd WWFgJnqwsf46AqfnJNQzHfbqMocvfuCkFt0r158TvEcymrfx6O3TvztA0xdferho06p6 YeYOYk1Qdk60vBVVLDXy6+af6Q2SA3V3QZ8C2vI7jSYiszWj6Fa80tC49QLxXc7UrRAx PFEA== X-Gm-Message-State: AGRZ1gJesu2bBSf2q5YFOYsOIFissSnFDabGE+WYIciqH2Ct6fXpN21a h7V5vYPuR08q8D3WdcIffRerTDcU2Z03LnhEQia+15P+ X-Google-Smtp-Source: AJdET5c8mqhIOsAEzGdw4l3eT7l2de4iuo0l7kF7AH2OU/p22l9mL5AhbQT172ZQZ1iuMEuZ2XcXCSO6l+NeQItCzrc= X-Received: by 2002:a19:cc46:: with SMTP id c67mr11514782lfg.145.1541399397897; Sun, 04 Nov 2018 22:29:57 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> In-Reply-To: From: Seth Johnson Date: Mon, 5 Nov 2018 01:29:19 -0500 Message-ID: To: melinda.shore@nomountain.net Cc: Hrpc Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 06:30:02 -0000 On Mon, Nov 5, 2018 at 1:20 AM Melinda Shore wrote: > > On 11/5/18 1:15 PM, Seth Johnson wrote: > > It should also be noted that at this moment the ITU Plenipotentiary > > conference is developing their next 4 years framework with a strong > > reference to "OTT" and building on this flawed set of premises. > > My concern has less to do with the ITU-T and more to do with being > clear in communication with this (IETF) community. I don't think that > it's familiar terminology in the IETF and its use could lead to some > confusion among people reading the document. My bias in looking at > the tradeoffs in jargon use is to always choose clarity. You are correct to focus on this concern. I would note that it is also important that this community not inadvertently accommodate the rationalizing work presently underway for another model/framework. Remember that I* representatives also participate at ITU-PP (and -T and -D and -R, but -PP is notably about governmental concord in the international arena), and they must wal;k away from the outputs of the ITU-PP having gone along with whatever it produces. I gave one hint of a way to clarity: just reference application layer and the problem of helping endorse a baggage that's out of sorts with the IETF frame of mind is evaded. I don't doubt that other ways will be needed as well. Seth > Melinda > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Sun Nov 4 22:43:39 2018 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 D4C6912F1A6 for ; Sun, 4 Nov 2018 22:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 EUYLhNERHrGL for ; Sun, 4 Nov 2018 22:43:36 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2F1AC12EB11 for ; Sun, 4 Nov 2018 22:43:35 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wA56gDqX020033; Mon, 5 Nov 2018 06:43:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=cl/DglD8j3iCwnTQOykwVJkvkssO7Q0UMGgmyJCnF3s=; b=h19NXpHWOLVu6uOQRHZoIyEloR8KLx0lH16qNxf5YHY22dWP7GbI1StD4kHJK5Wg488U ey22C8+OPFMb5D0AgTsUzRiS86Xh5T3dxweMPus+zesCozEzNaS72R5/WdhB+T2jlb/N MUq77koJIOHVJKHba/qdBgf18aOpQSqQbVYMrfRUJHIFdYjOlW2MPeSOaSB2fmjSrnR9 hWovcklGWXJ3u+Y4YM91DbDHpv3+ntXE5ygoIwIbT6bhPWJ0bQlXisumjO+Ot/9cJFDw QvB5MaCntscfKKOTUf1iyV3BzmaDwj3xubCWV/2oV0e+qwCL8vQBrQeAo7n1vW+GTVk6 og== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2nh6dqdfpf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Nov 2018 06:43:32 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wA56ZPNK011675; Mon, 5 Nov 2018 01:43:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2nh70w7ufw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 05 Nov 2018 01:43:30 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 5 Nov 2018 00:43:30 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Mon, 5 Nov 2018 00:43:30 -0600 From: "Salz, Rich" To: Ted Lemon , Vittorio Bertola CC: Hrpc , Nalini Elkins Thread-Topic: [hrpc] Over the top is over the top Thread-Index: AQHUdLCNV030Gy1Qg0uSoFm6/+hGhqVA8UEAgAABxoCAAANSAIAAFLqA///CCIA= Date: Mon, 5 Nov 2018 06:43:30 +0000 Message-ID: <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181014 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.152.138] Content-Type: multipart/alternative; boundary="_000_5AAA1A20647A4B5EB2B3EBF251B8B27Cakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-05_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=717 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811050060 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-05_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=708 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811050061 Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 06:43:38 -0000 --_000_5AAA1A20647A4B5EB2B3EBF251B8B27Cakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAgQnV0IEkgYW0gYXNraW5nIHlvdSB0byBub3QgdXNlIHRoaXMgdGVybSwgYmVjYXVzZSBvZiBp dHMgY29ubm90YXRpb25zLiAgIFRoZSB0ZXJtIGlzIGFudGl0aGV0aWNhbCB0byB0aGUgY3VsdHVy ZSBvZiB0aGUgSUVURg0KDQpJIHdvdWxkIG5vdCBnbyB0aGF0IGZhciwgYnV0IEkgYWdyZWUgdGhh dCB1c2luZyBPVFQgaXMgcHJvYmxlbWF0aWMuDQo= --_000_5AAA1A20647A4B5EB2B3EBF251B8B27Cakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <067C58DF81058845A7177670A45614C9@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZuYnNwO0J1dCBJ IGFtIGFza2luZyB5b3UgdG8gbm90IHVzZSB0aGlzIHRlcm0sIGJlY2F1c2Ugb2YgaXRzIGNvbm5v dGF0aW9ucy4mbmJzcDsgJm5ic3A7VGhlIHRlcm0gaXMgYW50aXRoZXRpY2FsIHRvIHRoZSBjdWx0 dXJlIG9mIHRoZSBJRVRGPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbm90IGdvIHRo YXQgZmFyLCBidXQgSSBhZ3JlZSB0aGF0IHVzaW5nIE9UVCBpcyBwcm9ibGVtYXRpYy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5AAA1A20647A4B5EB2B3EBF251B8B27Cakamaicom_-- From nobody Sun Nov 4 23:01:23 2018 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 D877612F1A6 for ; Sun, 4 Nov 2018 23:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 V5Od6Yf7Y0Cz for ; Sun, 4 Nov 2018 23:01:15 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 1CECF1271FF for ; Sun, 4 Nov 2018 23:01:15 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id t9-v6so3804080ljh.6 for ; Sun, 04 Nov 2018 23:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Et6i1T6ErhHmFGH8lUfWrSAjFUli1+oGGoABuzz3uw4=; b=AYJT1wc/HgVMizQ55WLOULwpg7E1GThvrgHiVQ5TDC4Akyn2U5nxXFcBGYhih9LHLj qnybjQCRFJCMS+P4cvjy61+qDQhmQ5jZP7SngKgs7FcKMqJIugjDHnfJ4zHIl9YlTXL4 O1yuNcz/9NzVGWBh00twP9T7aPXkUptJIfzItwS3L9lkTL5L6FjCldIM1q1vfFds/r4F el3wPqtTJgItldImD4We9EPuttGUeNP33NZj669v9bcmA3JbWZ9klwu5VAWc6S6p9KpJ 1vDF0OyPreKgN5GgS1GZzITvddj+oekvHV2InoBN4PPCs0K7Xc25jE41QBA8k2f0IYZi 9jJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Et6i1T6ErhHmFGH8lUfWrSAjFUli1+oGGoABuzz3uw4=; b=rw0LgFBk/vOOTb7D7ysssQRUo9oyXpvH8XcLoKIITv6MoPty7PhtVm9rlT6a8N25S9 VneKeSl3yHB0zOuUO7RcoeiOyLVjCsvHU9tSDlFJfG3lu0bQjq6MhDTkKv9LCObvRYXc pn6TnxHiYTfOofwoli+Fe8qZYFSjcPG438IQFkeFovn5uiAC1iAJaiL0wSVsR/CK4pPM REe7hvhNllhrO79xZSRR5WUHUuxZAFH4bk9injrVdHMTFAlk6EpmfGaFp7gWTz1pI5Ec 25dxPkX5K+dwpmuGCiWVU6/AjpZFEnDSPpTHzNWn64AM8QbzYiHSgGmiKsDAejLhK++P HVqQ== X-Gm-Message-State: AGRZ1gJu2QYR/W2DDq5RUgbv9GfRZP+/sbOHSCl/pylkORIQsgC65oyh T8bmU6vHctchTMABSLQqL3ZiZLk1ZyPB0KpofjE= X-Google-Smtp-Source: AJdET5cWYiD1pj36jGAEdfjiaRvF/qTwwgFHD6XBZ81Xq+0ZINkBp87hNvfgnzMbGxB91aLJ3J70+XKaHPovhJvP1VM= X-Received: by 2002:a2e:2416:: with SMTP id k22-v6mr8204817ljk.80.1541401273262; Sun, 04 Nov 2018 23:01:13 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> In-Reply-To: From: Seth Johnson Date: Mon, 5 Nov 2018 02:00:35 -0500 Message-ID: To: melinda.shore@nomountain.net Cc: Hrpc Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 07:01:22 -0000 Here's a publicly available document from Brazil for some flavor including a document on "International public policy issues concerning telecommunications-related aspects of OTT applications" (Patrik Falstrom recently posted a screenshot of this document): https://www.itu.int/md/S18-PP-C-0067/en On Mon, Nov 5, 2018 at 1:29 AM Seth Johnson wrote: > > On Mon, Nov 5, 2018 at 1:20 AM Melinda Shore > wrote: > > > > On 11/5/18 1:15 PM, Seth Johnson wrote: > > > It should also be noted that at this moment the ITU Plenipotentiary > > > conference is developing their next 4 years framework with a strong > > > reference to "OTT" and building on this flawed set of premises. > > > > My concern has less to do with the ITU-T and more to do with being > > clear in communication with this (IETF) community. I don't think that > > it's familiar terminology in the IETF and its use could lead to some > > confusion among people reading the document. My bias in looking at > > the tradeoffs in jargon use is to always choose clarity. > > > You are correct to focus on this concern. I would note that it is > also important that this community not inadvertently accommodate the > rationalizing work presently underway for another model/framework. > Remember that I* representatives also participate at ITU-PP (and -T > and -D and -R, but -PP is notably about governmental concord in the > international arena), and they must wal;k away from the outputs of the > ITU-PP having gone along with whatever it produces. > > I gave one hint of a way to clarity: just reference application layer > and the problem of helping endorse a baggage that's out of sorts with > the IETF frame of mind is evaded. I don't doubt that other ways will > be needed as well. > > > Seth > > > > Melinda > > > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc From nobody Sun Nov 4 23:03:20 2018 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 9ACEF130DC6 for ; Sun, 4 Nov 2018 23:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8TuvCVUynkM for ; Sun, 4 Nov 2018 23:03:14 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 4813C130D7A for ; Sun, 4 Nov 2018 23:03:09 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gJYui-0003gV-17 for hrpc@irtf.org; Mon, 05 Nov 2018 08:03:08 +0100 To: hrpc@irtf.org References: <1419803954.21799255.1541280743505.ref@mail.yahoo.com> <1419803954.21799255.1541280743505@mail.yahoo.com> <23518.22393.46237.953386@gargle.gargle.HOWL> <927110798.6232.1541339371010@appsuite.open-xchange.com> From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: <763ec608-3a5f-0a5e-4562-ab83b3efbefb@article19.org> Date: Mon, 5 Nov 2018 12:20:18 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <927110798.6232.1541339371010@appsuite.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 0ccaee305be983877c9e38c09cbf8ec4 Archived-At: Subject: Re: [hrpc] Internet Architecture Board warns Australian encryption-busting laws could fragment the internet X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 07:03:18 -0000 On 04/11/2018 20:49, Vittorio Bertola wrote: > > >> Il 4 novembre 2018 alle 3.20 bzs@theworld.com ha scritto: >> >> >> >> And Denmark will require "email encryption" as of 1/1/2019 or in >> European format 1/1/2019. > > It is already "required if appriopriate" by the GDPR and would also be explicitly required throughout the EU by several versions of/amendments to the upcoming (maybe) ePrivacy Regulation. Then, of course, no one still knows how to implement proper end-to-end encryption for email in general, as there are too many competing standards for certain things and no standard for others, and it is unclear how you could even get the average user to create and manage their encryption keys without letting the application/service provider do it for them, which turns end-to-end encryption into "managed" end-to-end encryption a la Whatsapp, which means that the content of the message is encrypted for everyone except the recipient... and Facebook. (Though with email you can at least choose your client/service provider, something you can't do with the instant messaging siloses.) > But, again, this would be a good challenge for the Internet's technical community. > Ciao > Hi, There is LEAP (Leap Encryption Access Project) that is trying to solve the issue of managed e2e encryption that doesn't disclose information to the server. https://leap.se I particularly like their analysis of The Hard Problems. But whether or not this project and code will reach all email users remains to be seen. -Mallory -- Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Sun Nov 4 23:35:22 2018 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 00FEB1274D0 for ; Sun, 4 Nov 2018 23:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toEQgFIZuBbH for ; Sun, 4 Nov 2018 23:35:18 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 62F4E128A6E for ; Sun, 4 Nov 2018 23:35:16 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gJZPm-0000IY-SG for hrpc@irtf.org; Mon, 05 Nov 2018 08:35:15 +0100 To: hrpc@irtf.org From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: <9640e5b2-9888-9fb3-c610-361b4cb5cf07@article19.org> Date: Mon, 5 Nov 2018 14:35:07 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: a8ecdd0179e5342c74548fafd5461917 Archived-At: Subject: [hrpc] Extending our session at IETF 103: Thursday @ 14-15:00 in Pagoda X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 07:35:20 -0000 Hi all, We had requests to finish the HRPC agenda after this morning's session in a side meeting later this week. We have booked Pagoda on Thursday, 8 November at 14-15:00. We will cover the last point on the agenda, which is (roughly): * Check in on: Where is the research group's interests? * And on what topics do we want to work? * Other discussion on methodologies, maybe? Apologies if not everyone can attend. We will extend the notes for 103 to include both sessions. We also take discussion on this to the list after we've had some face-to-face discussion. Thanks, -Mallory -- Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Mon Nov 5 11:52:15 2018 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 9CC21130DE0 for ; Mon, 5 Nov 2018 11:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 V5Vt8bvVEnLu for ; Mon, 5 Nov 2018 11:52:11 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) (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 B0BBD130DCA for ; Mon, 5 Nov 2018 11:52:11 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id wA5JpRP4011310; Mon, 5 Nov 2018 14:51:29 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id wA5JirDO022308; Mon, 5 Nov 2018 14:44:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23520.40373.219087.642362@gargle.gargle.HOWL> Date: Mon, 5 Nov 2018 14:44:53 -0500 From: bzs@theworld.com To: "Salz\, Rich" Cc: Ted Lemon , Vittorio Bertola , Hrpc , Nalini Elkins In-Reply-To: <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 19:52:14 -0000 Vittorio might recall that when "OTT" first appeared in Nalini's draft my reaction in private email was that this was not a term I was familiar with and wondered if it was just me or more generally true. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Mon Nov 5 12:55:33 2018 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 E812A1286E3 for ; Mon, 5 Nov 2018 12:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 MaR1vA57tfkc for ; Mon, 5 Nov 2018 12:55:25 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 AA767130DC0 for ; Mon, 5 Nov 2018 12:55:24 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id DD2466A263; Mon, 5 Nov 2018 21:55:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1541451321; bh=2JS/23d3lBNJUc8XIIv9nIY+a+C+sWNZ8tu5hnyVqJA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=LsfkAZ781Y5BHroKabHiWfQuGRianpLLqAH2QgzehOopO9n47xaDBwKI9szLzwG0R b3osWATGSGa1GAEdz6kLWzzggAP1BYJUKIdLVuFuYurDVOAkwaPuwGsYSHtxwhVD3r ecGU2LWrq40rvnUS10hKo9cA2QI/5DtVdUfCMn6VI+/k3Lw8kDO3O2BWgANANWdZxo zF0B6A/ciiM4CxtIhExKPdGRM1TR9j7l7E80Tduyr6cOV7EVmuLNDZff3Mr7Eqm1Si MNYJV13VvCyK52Aej0F9tvR84DA+MQJBLaGEr1m8v3jBl2FerQkVQW5FXvGIb6S2DV /X5Iv4M7kWB+A== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id C8DCF3C0766; Mon, 5 Nov 2018 21:55:21 +0100 (CET) Date: Mon, 5 Nov 2018 21:55:20 +0100 (CET) From: Vittorio Bertola To: bzs@theworld.com Cc: Hrpc Message-ID: <2084682636.12600.1541451321691@appsuite.open-xchange.com> In-Reply-To: <23520.40373.219087.642362@gargle.gargle.HOWL> References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> <23520.40373.219087.642362@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 20:55:27 -0000 > Il 5 novembre 2018 alle 20.44 bzs@theworld.com ha scritto: > > > > Vittorio might recall that when "OTT" first appeared in Nalini's draft > my reaction in private email was that this was not a term I was > familiar with and wondered if it was just me or more generally true. This is true, so initially I took Ted's concern as similar to yours, i.e. "this is a term I never heard and I don't like it". But thanks to Seth and other people now I understood what the real concern is, i.e. "this is a term which is commonly used in ITU/telco circles and I don't like it". Again, I don't have problems with finding a different term, though I note that the "OTT vs ISP" terminology is the common standard in policy and regulatory circles in Europe (and, as I see from the link, also in Latin America), so it's not necessarily overloaded with pro-ITU stances (ironically, I was one of those many people that 15-20 years ago put effort in preventing the ITU from becoming the main Internet policy-making venue). However, I don't think that there is any other equivalent term in common use that captures the problem and identifies a set of companies that do not supply connectivity, are huge, are transnational and are centralizing the Internet. Perhaps something like "[big] global Internet platforms"? Let me think at this. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Mon Nov 5 14:22:49 2018 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 A915A124D68 for ; Mon, 5 Nov 2018 14:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 198XWlt8l5ld for ; Mon, 5 Nov 2018 14:22:46 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 09312124C04 for ; Mon, 5 Nov 2018 14:22:46 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id n18so7367612lfh.6 for ; Mon, 05 Nov 2018 14:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bWJyLEdUhxw31IigaMtPv+O4nREEO+724/7+FKYrsS4=; b=Vz1MTqTI6x2FrHhkpRM/W9e1wME3W7Vs2l1oH3obp2sKi0Ei3xo7GrdLYwnP0e+fky CNw/8LhdaC217ypim1XWrwhWMX3WyZpGBkYt71YzTiXRCgAo+AgzFDG4zFCIkkZTVWCx IC3acZRnb0ty7CxN7+90tmaBfKgoFSmAOJnjBb/iE2ln1fQZrHUMNVlw6ICvWFzIxswW Z1roJyVbt4TdtgzMW3dhsgPvb0duPNE2X8YsNezM8bs2gjKlXDbEF1dlwApkytS9f1FG luz1t1YTcK1u61QTLGKg8kXnAZ5BRu5mSYoGeCjQo9CRUUlKDbYmWdzcmfIIDa6w21ks VShQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bWJyLEdUhxw31IigaMtPv+O4nREEO+724/7+FKYrsS4=; b=lRQ9PDqrfqH2cNkE9JQPZhUAzQvnIttbT4wxMQjxse8GFkQcqpyJ1cLw8qM9VkRsPE 8L6w+c9kLSoJtR/urteQ7UAEithi3PQjnSbXAsUT6Jeo8TRDY9BIMGuSvT9jENlgir5D icGsuL4RO64aqAIwRwq6OaN7RbhgwGWtmp7Nflaz+Vq1Iw03SGAIDcRly+f8X2FT+Qh3 ++5bGuzp6XENcbC6NU3JpKIDETE8lb3qItVv5089/M6tbqRN4LlhTiQ9iWTklVP+gfq5 /UhIzVkt7AK2y8vKTRRz0G3Bm9t3sy4c5zf0LZWBuvS8KEBglqUhTCmierFwXOReXcVO JUQw== X-Gm-Message-State: AGRZ1gK4Emxf1E/kkStuaW7bZNAVGsR6vn91gw0Uf+mpmcVgauaZVffB UHkdF7Ll2fHNg+Mi+jQjV/hoRLKE56nlDD8bp0A= X-Google-Smtp-Source: AJdET5effN/IBAkb4QyPeOtQfFPho44ErL/XsMrOrEjE8K4BMSAsLfdBFwonIWBC9ZJJvMUxcAjhxHTNPJFUmvkP3Yo= X-Received: by 2002:a19:c7c2:: with SMTP id x185mr14325663lff.123.1541456564056; Mon, 05 Nov 2018 14:22:44 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> <23520.40373.219087.642362@gargle.gargle.HOWL> <2084682636.12600.1541451321691@appsuite.open-xchange.com> In-Reply-To: <2084682636.12600.1541451321691@appsuite.open-xchange.com> From: Seth Johnson Date: Mon, 5 Nov 2018 06:39:37 -0500 Message-ID: To: vittorio.bertola@open-xchange.com Cc: bzs@theworld.com, Hrpc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 22:22:48 -0000 On Mon, Nov 5, 2018 at 3:55 PM Vittorio Bertola wrote: > > This is true, so initially I took Ted's concern as similar to yours, i.e.= "this is a term I never heard and I don't like it". But thanks to Seth and= other people now I understood what the real concern is, i.e. "this is a te= rm which is commonly used in ITU/telco circles and I don't like it". I'd say I don't like the policy environment that the telcos and ITU have developed and developed within, out of sorts with the one that gave us the open Internet. Sort of the thing I put in my first convoluted paragraph. But it's fair enough. These fora need what they're doing to be understood and recognized and it does fall on us to do that sort of delineation. When the policy environment returns, I'd go along to get along more with industry signals. :-) Seth/eom > Again, I don't have problems with finding a different term, though I note= that the "OTT vs ISP" terminology is the common standard in policy and reg= ulatory circles in Europe (and, as I see from the link, also in Latin Ameri= ca), so it's not necessarily overloaded with pro-ITU stances (ironically, I= was one of those many people that 15-20 years ago put effort in preventing= the ITU from becoming the main Internet policy-making venue). However, I d= on't think that there is any other equivalent term in common use that captu= res the problem and identifies a set of companies that do not supply connec= tivity, are huge, are transnational and are centralizing the Internet. Perh= aps something like "[big] global > Internet platforms"? Let me think at this. > > Regards, > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Mon Nov 5 14:31:05 2018 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 2C6EF124D68 for ; Mon, 5 Nov 2018 14:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 RaErQ5zbtbk7 for ; Mon, 5 Nov 2018 14:31:01 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 3FF0F124C04 for ; Mon, 5 Nov 2018 14:31:01 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id o125so17334243qkf.3 for ; Mon, 05 Nov 2018 14:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ko4lEohX5bxpPQDNzWcz7/EB+thQ/dL9VvHiIZuP+5Y=; b=y6uo5uTCwDhuPCF2vHBgL+t7Ksy26DyZF5Ycts+ezAj29cqP5NJxlWysSMbXgKzje/ NniNcCtV2UZEhYW88N9Zzq9p1fqP/QsJa7Tv6tkhA81xCA+eoX1eG1AmMiztfFl4fLWE XMD4jYpDLo9oT3u2a5rfK1VsE8GLnvejIYa0JtDBrC5LKSEeY41eVfTOWeJl7aoJ3Xmm +3mJ1vF2/1Nce+kdbF1N5de8OLqd5xzzFuDuhFAuk89J+5nQ+Sr8+Uv3h0KWBwM5DcS9 Q+MG9tQHpnZjv7SCfcQGnXnAz5jxh8JxUJLLvws+7MVSMvCDwba89VFd7O4pPwq47oL9 ch7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ko4lEohX5bxpPQDNzWcz7/EB+thQ/dL9VvHiIZuP+5Y=; b=QEySJKyWXu539IRhR/dZ76rPWnAPSWt6QUAt1xsmUkPk6gFYHcWIjLKPHMOpah9Tls 5GaSjUh09jHwiivtbmj9P7nOHSOiKBNuL4uplJKBHO6t1f9+9MhGIExCa8dX9FvSguLu gM3aFeBjq+RIWrHtu3i1/DN15r0vs2XRLDihPPWblK6K0qiRm71/UWolROPoBxDaje3U xjd5T0eCt6jeLMQjD1L2YgyY2iEENrEkX+HBqZJnOK4hTofrfHK89U1oPw8/JthRZD91 bDBAAe/ZiZnlGQAFgKGej0/lSRxlL9RDB6w7yJE66JDpqh/ACu4diiitkpGIqqJKnf++ gzgg== X-Gm-Message-State: AGRZ1gIXJW5sVGiUR+wLg6jDY34LKzXRXLbmdhjPBx/n8dNjqYd7SC8a JB7NB5KiI17ftXNCKMk49uo+GG9sGafoTN/z5gyPQBqmRuk= X-Google-Smtp-Source: AJdET5dPAtGD1UqkvOiQTAjntQZ3BPECdyfQFJ+o5X9DhGEDQPJrf3ynYL8y6EYJpW9ZvG1L5YR7g8CpTP+U5ZzQmk4= X-Received: by 2002:a37:8706:: with SMTP id j6-v6mr22311376qkd.216.1541457060261; Mon, 05 Nov 2018 14:31:00 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> <23520.40373.219087.642362@gargle.gargle.HOWL> <2084682636.12600.1541451321691@appsuite.open-xchange.com> In-Reply-To: <2084682636.12600.1541451321691@appsuite.open-xchange.com> From: Ted Lemon Date: Tue, 6 Nov 2018 05:30:24 +0700 Message-ID: To: Vittorio Bertola Cc: bzs@theworld.com, Hrpc Content-Type: multipart/alternative; boundary="000000000000838aca0579f2706c" Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 22:31:04 -0000 --000000000000838aca0579f2706c Content-Type: text/plain; charset="UTF-8" I thought I was pretty explicit about why I thought it was a bad term. If you want a term for Facebook or Youtube, I think "online service platform" works pretty well, and doesn't have the connotations that come with saying that it is "over the top." The distinction between an online service platform provided by an ISP (not over the top) and an online service platform not provided by the ISP (over the top) is an artificial distinction which exists because of the ISP's marketing strategy, not on some technical basis. On Tue, Nov 6, 2018 at 3:55 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 5 novembre 2018 alle 20.44 bzs@theworld.com ha scritto: > > > > > > > > Vittorio might recall that when "OTT" first appeared in Nalini's draft > > my reaction in private email was that this was not a term I was > > familiar with and wondered if it was just me or more generally true. > > This is true, so initially I took Ted's concern as similar to yours, i.e. > "this is a term I never heard and I don't like it". But thanks to Seth and > other people now I understood what the real concern is, i.e. "this is a > term which is commonly used in ITU/telco circles and I don't like it". > Again, I don't have problems with finding a different term, though I note > that the "OTT vs ISP" terminology is the common standard in policy and > regulatory circles in Europe (and, as I see from the link, also in Latin > America), so it's not necessarily overloaded with pro-ITU stances > (ironically, I was one of those many people that 15-20 years ago put effort > in preventing the ITU from becoming the main Internet policy-making venue). > However, I don't think that there is any other equivalent term in common > use that captures the problem and identifies a set of companies that do not > supply connectivity, are huge, are transnational and are centralizing the > Internet. Perhaps something like "[big] global > Internet platforms"? Let me think at this. > > Regards, > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000838aca0579f2706c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought I was pretty explicit about why I thought it was= a bad term.=C2=A0 =C2=A0If you want a term for Facebook or Youtube, I thin= k "online service platform" works pretty well, and doesn't ha= ve the connotations that come with saying that it is "over the top.&qu= ot;=C2=A0 =C2=A0The distinction between an online service platform provided= by an ISP (not over the top) and an online service platform not provided b= y the ISP (over the top) is an artificial distinction which exists because = of the ISP's marketing strategy, not on some technical basis.

=
On Tue, Nov 6, 2018 at 3:55 AM = Vittorio Bertola <v= ittorio.bertola@open-xchange.com> wrote:
> Il 5 novembre 2018 alle 20.44 bzs@theworld.com ha scritto:
>
>
>
> Vittorio might recall that when "OTT" first appeared in Nali= ni's draft
> my reaction in private email was that this was not a term I was
> familiar with and wondered if it was just me or more generally true.
This is true, so initially I took Ted's concern as similar to yours, i.= e. "this is a term I never heard and I don't like it". But th= anks to Seth and other people now I understood what the real concern is, i.= e. "this is a term which is commonly used in ITU/telco circles and I d= on't like it". Again, I don't have problems with finding a dif= ferent term, though I note that the "OTT vs ISP" terminology is t= he common standard in policy and regulatory circles in Europe (and, as I se= e from the link, also in Latin America), so it's not necessarily overlo= aded with pro-ITU stances (ironically, I was one of those many people that = 15-20 years ago put effort in preventing the ITU from becoming the main Int= ernet policy-making venue). However, I don't think that there is any ot= her equivalent term in common use that captures the problem and identifies = a set of companies that do not supply connectivity, are huge, are transnati= onal and are centralizing the Internet. Perhaps something like "[big] = global
=C2=A0Internet platforms"? Let me think at this.

Regards,
--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vitt= orio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000838aca0579f2706c-- From nobody Mon Nov 5 21:11:12 2018 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 6BEC6129619 for ; Mon, 5 Nov 2018 21:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 4tmDxXAmef2y for ; Mon, 5 Nov 2018 21:11:06 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 CCB3E12D4F0 for ; Mon, 5 Nov 2018 21:11:01 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42pyLW6psCzFmw for ; Tue, 6 Nov 2018 06:10:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1541481059; bh=Zok/auckO3tYKeSciDR67ptnUcteSrg/1dC+X9tDwBc=; h=Date:From:To:Subject; b=OVCVmeCdOi3RYgRxu2Se2VwOhw5GdxjZ/Xnmyx75kCGogpfJFALPkOZDKnsgGMaJG dNyKIf/vptacUK5/PBMVFPpFlzy/42evzLDkOVC0FYVHqKwpi11s5K74u5CE/yAEKe fUKMus2fnOKSa+9YRidOqO3fZuaMdG6VCzj4X21A= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JLYRGRfEXmIC for ; Tue, 6 Nov 2018 06:10:59 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 6 Nov 2018 06:10:59 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2F0C8681889; Tue, 6 Nov 2018 00:10:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2F0C8681889 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2562F41C3B26 for ; Tue, 6 Nov 2018 00:10:58 -0500 (EST) Date: Tue, 6 Nov 2018 00:10:58 -0500 (EST) From: Paul Wouters To: hrpc@irtf.org Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [hrpc] [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt (fwd) X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 05:11:08 -0000 [oops, CC:ed the wrong email address] ---------- Forwarded message ---------- Date: Tue, 6 Nov 2018 00:08:03 From: Paul Wouters Cc: dnsop , hrpc@ietf.org To: Paul Vixie Subject: Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt On Mon, 5 Nov 2018, Paul Vixie wrote: > Subject: Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt > > because of deliberate reconfiguration or takedown, i'll hope that > serve-stale offers authority operators (both apex and parent) a signalling > pattern that says, "actually, i want this dead, NOW." That sword cuts both ways. It would be useful to have a Human Rights section in the document that discusses this issue. Perhaps the HRPC WG can assist us here, Paul From nobody Tue Nov 6 00:30:22 2018 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 66365128A6E for ; Tue, 6 Nov 2018 00:30:20 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 wcQmaG4f6jEm for ; Tue, 6 Nov 2018 00:30:16 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 7B0C3130DD4 for ; Tue, 6 Nov 2018 00:30:16 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gJwkY-0001ha-2Q for hrpc@irtf.org; Tue, 06 Nov 2018 09:30:14 +0100 To: hrpc@irtf.org References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> <23520.40373.219087.642362@gargle.gargle.HOWL> <2084682636.12600.1541451321691@appsuite.open-xchange.com> From: Amelia Andersdotter Openpgp: preference=signencrypt Autocrypt: addr=amelia@article19.org; prefer-encrypt=mutual; keydata= xsFNBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABzSxBbWVsaWEgQW5k ZXJzZG90dGVyIDxhbWVsaWFAYW5kZXJzZG90dGVyLmNjPsLBlwQTAQgAQQIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJY1pdiAhkB AAoJEP7xwpS06AtVI0sP/Al6eUycymdT1R7v0uEQv4coonnOUV6FKj/4wc+wM+A0h7vlqADr j4nS7RRSQRUo8xJ9tvR9J1Eyske5bvakOYv64f9PrNY1Z6ABhJzK34kJxekEfeLmpXAB4wst GhD8dGC/z/b9Oau0AW1GWIP0eNWq4acDf9Qf+j0wqQi25OZUXnu5KeUX7mvPTHKZLyEZlwHV atXmZHWKnQWtEPZTQfv/zESsoBAm1TbaLapgxVG9uLW+I9kj72TB/AZ5hMSKMYWZ2dC+8eEs Xd22tn6907aUmZhFT89jbEyS996WeZ+SQ5G1Okrq02qYXcCi5vm3AuvLlbRYHguh42TLaVq1 er7PiYOYH77FFmnZWW6ChFnf7xsDep2tpNxn+QUZLgO3+5kL7TfO7D2H57kjVVMdkNn+01nz kfcn76K7nuU6Dc4pItPzbDndhdxulnm9cicOEfGQqvta9ffxk4YWyAu9PUNARVRNf6OnoDQQ Zo8l1o37q9PFXJyQwzvxdd9u6uzTny2wp9eig75pD3dYHCRIQeYmkv1kB81mc86cwgvuw1Qy /QwiCBNXSSuIvLO78b+/dB0DLVQC/c6gtyWXRpC4ysF4EaEZophjT60d12YRanR+fWuH+qu2 wsT+z1d4tC5/6UJMPr3bxREh9JHThm5Y3cDBmcn0PGqtDKkwjCkqex5bzsFNBFjWlnsBEADF jusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67TM7yBqsv5COPVgAV+xp+axor5 oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrHNUn73/rfeBD9KhKAXcNKKPoc cLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+CyYS7xfGolsZXXoBOKcyhfj/c kPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2dRl3omI/e2t3Vq33hFUUSAdxr FF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8yBdadw7CM08Uw8wqH7n9BA3oq //QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L91vobt8bM/Jbhl9h+X2Yq9oBC iTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVOPASdv9FRUYH1Va7QWQifoha0 B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUOxiYKBA4fppJt/LJF4jsaCEyI /CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+j+/WhzaVT1oVYp6eQXh0bBtq qH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABwsF8BBgBCAAmFiEEPV22yrhSuYgFWmpv /vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1XnRw//W4lzE8FddceKXGRwO/T1 u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vIAJXM9/HI1FZ09EUdJr5X/+YR EErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtksn/H4USdJL53ZPt10SVNK7H3 w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcPYmiU1GQi9QWkGxWRxk0YQXBw hekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAnEV3EqaGnf0PknXp3vNHAZWrf M+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmwsPt8VffbEXlf7qZqRBKaYeKt0 qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOAUWRSnDRyT6rv/vXxrbkL4uxW ax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB/ntv0DiMuh+fmLGk3zrxs4Xd 30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8fLk17AK7Q1ZTgcZ+8XLRFnavd PrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8REiawo+FvVt9j0fKdNEBeaJ3W Y5hlhNPcUXr4q1U= Organization: ARTICLE19 Message-ID: <62d2930f-b6a2-e3aa-fcb8-c2cb873650ef@article19.org> Date: Tue, 6 Nov 2018 09:30:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US-large X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: ee739817b6cd2655ac6326818c89325b Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:30:20 -0000 Hi all, Top-posting because topical but not immediately in response to anything. The term "Information society service" vertically separates the other way (I think of this personally in terms of OSI - while "OTT" tries to separate out layer 7 and perhaps 6, ISS indicates stuff that's on layer 3 and above and discards the physical/link). I'm proposing it as an alternative? It's an infrequently used term (it doesn't fit any marketing scheme, I guess) that is nevertheless established since the 1990s (including at the ITU, but less frequently used). best regards, Amelia On 2018-11-05 23:30, Ted Lemon wrote: > I thought I was pretty explicit about why I thought it was a bad > term.=C2=A0 =C2=A0If you want a term for Facebook or Youtube, I think "= online > service platform" works pretty well, and doesn't have the connotations > that come with saying that it is "over the top."=C2=A0 =C2=A0The distin= ction > between an online service platform provided by an ISP (not over the > top) and an online service platform not provided by the ISP (over the > top) is an artificial distinction which exists because of the ISP's > marketing strategy, not on some technical basis. > > On Tue, Nov 6, 2018 at 3:55 AM Vittorio Bertola > > wrote: > > > Il 5 novembre 2018 alle 20.44 bzs@theworld.com > ha scritto: > > > > > > > > Vittorio might recall that when "OTT" first appeared in Nalini's > draft > > my reaction in private email was that this was not a term I was > > familiar with and wondered if it was just me or more generally tr= ue. > > This is true, so initially I took Ted's concern as similar to > yours, i.e. "this is a term I never heard and I don't like it". > But thanks to Seth and other people now I understood what the real > concern is, i.e. "this is a term which is commonly used in > ITU/telco circles and I don't like it". Again, I don't have > problems with finding a different term, though I note that the > "OTT vs ISP" terminology is the common standard in policy and > regulatory circles in Europe (and, as I see from the link, also in > Latin America), so it's not necessarily overloaded with pro-ITU > stances (ironically, I was one of those many people that 15-20 > years ago put effort in preventing the ITU from becoming the main > Internet policy-making venue). However, I don't think that there > is any other equivalent term in common use that captures the > problem and identifies a set of companies that do not supply > connectivity, are huge, are transnational and are centralizing the > Internet. Perhaps something like "[big] global > =C2=A0Internet platforms"? Let me think at this. > > Regards, > --=20 > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > > Office @ Via Treviso 12, 10144 Torino, Italy > > _______________________________________________ > 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 Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 From nobody Tue Nov 6 00:37:14 2018 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 D8EDA130E86 for ; Tue, 6 Nov 2018 00:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nkom.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 Cf4w667Q5KlE for ; Tue, 6 Nov 2018 00:37:09 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.67]) (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 EE3A91277C8 for ; Tue, 6 Nov 2018 00:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nkom.no; s=s1; t=1541493426; i=@nkom.no; bh=mJQ2V4yNhELUpOKTgztT/HYoTY5ElNPkxiiXgBC4txs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cMg8cJwYxfjDt/l7dVfkGgoBbwFtSVrX1ZJ0j8DIOGTHXaGPmXwdEtC+Q5z0pXM2y MJQLRsYxh22zlDrtDCtQtyhIO9HQPEv2n91w/mY+4hMnQusxDBsnlGOYb3hFIqQaiB p5S6A6HP/VelM87LR43m8o5QXSF5c5t/3Up/uIwjZYMBN43fBfUlR6joMuHkNcXZK0 hNjFgCp5YOZaalZxea9xvcNO+ShWQn0GH8ci3dQfGxFMVH3R+i6vWEjVRrJaWQy8vb aAOruWfIFRq09G1+WX3kWDs+TXJuNT2au8lLZ6sRrcEbjPCHLFmBEFf3OzvDHc22aL YBO2x2VK6tfMQ== Received: from [46.226.52.196] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.eu-west-1.aws.symcld.net id 29/DB-12360-2B251EB5; Tue, 06 Nov 2018 08:37:06 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRWlGSWpSXmKPExsViF5OXq7sh6GG 0wa2DphbzPj9idGD0mLzxMFsAYxRrZl5SfkUCa8a257uZCrbyVGw+fo21gfECVxcjF4eQQDOj xN9VK5i6GDk52AScJe7d/skIYosIKEs83bSQDcQWFjCQmD7lFAtE3FDiRgdEvYhAlETjhy6we hYBFYmju2eD1fAK2ElsX3IJLC4k8IFZYtYOrS5GDg5OAXeJ218NQExGAVmJuU28IBXMAuISM4 7eAeuUEBCQWLLnPDOELSrx8vE/VghbTqLpRC8bhG0lsaj7HJStIfFo6Q4oW0Hi3NYzULa8xP6 XU5gh5utJ3Jg6hQ3C1pZYtvA1M8SVghInZz5hmcAoNgvJGbOQtMxC0jILScsCRpZVjOZJRZnp GSW5iZk5uoYGBrqGhka6hpaWuiYWeolVukl6qaW65anFJbqGeonlxXrFlbnJOSl6eaklmxiBE ZZScNxgB+OURemHGCU5mJREeTtYHkYL8SXlp1RmJBZnxBeV5qQWH2KU4eBQkuDdFQiUEyxKTU +tSMvMAcY6TFqCg0dJhHcTSJq3uCAxtzgzHSJ1ilGXo6epYQazEEtefl6qlDhvI0iRAEhRRmk e3AhY2rnEKCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSZi3CmQKT2ZeCdymV0BHMAEdcU/2AcgR JYkIKakGxl0C3s1aC0SfR7bq9an/bV9zd0f4i5SG0NjjatMDAuQluqY6e5pH9fef/CcjXhAr1 8+oUPiZ81xpUOTfMv8Hez/ax8xS9P78oSSoNeoPq0uhoXZdI+t9RvnKhNfcaywmr3psdUq72e fStJaArYYZ+uvur7KQfZTlMMHYLPrnjedTlvNv83yoxFKckWioxVxUnAgA3ls44DYDAAA= X-Env-Sender: frode.sorensen@Nkom.no X-Msg-Ref: server-17.tower-284.messagelabs.com!1541493424!1494615!1 X-Originating-IP: [62.92.110.109] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4927 invoked from network); 6 Nov 2018 08:37:04 -0000 Received: from 109.110.92.62.static.cust.telenor.com (HELO smtp.nkom.no) (62.92.110.109) by server-17.tower-284.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Nov 2018 08:37:04 -0000 Received: from EXMBX01.npta.no ([10.10.2.97]) by EXCAS.npta.no ([::1]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 09:37:03 +0100 From: =?iso-8859-1?Q?S=F8rensen=2C_Frode?= To: "hrpc@irtf.org" Thread-Topic: [hrpc] Over the top is over the top Thread-Index: AQHUdLCPN2GuhT6M+kmVRqY1lmPpvqVAe+gAgAABxoCAAANSAIAAFLqAgAEDDTmAAADOAIAAwb7w Date: Tue, 6 Nov 2018 08:37:02 +0000 Message-ID: <793D91975B99224DA9777562FF192808EAA6899C@exmbx01> References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> <23520.40373.219087.642362@gargle.gargle.HOWL> <2084682636.12600.1541451321691@appsuite.open-xchange.com> In-Reply-To: <2084682636.12600.1541451321691@appsuite.open-xchange.com> Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.7.21] x-tm-as-product-ver: SMEX-11.0.0.1251-8.100.1062-24204.003 x-tm-as-result: No--5.291000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 08:37:12 -0000 FYI, The European regulators organized under BEREC use the term "content and app= lication provider" or CAP instead of OTT. Thereby one has to main provider = categories ISPs and CAPs, the former category provides infrastructure and t= he latter doesn't. (Furthermore, one can of course distinguish between larg= er and smaller CAPs.) Ref. https://berec.europa.eu/eng/document_register/su= bject_matter/berec/download/0/6160-berec-guidelines-on-the-implementation-b= _0.pdf and check in particular page 3. By the way, an interesting discussion on the OTT term can be accessed at ht= tps://disruptivewireless.blogspot.com/2014/11/retiring-term-telco-ott-digit= al.html Best, Frode -------------------- Frode Sorensen Senior Adviser Norwegian Communications Authority www.nkom.no -----Opprinnelig melding----- Fra: hrpc P=E5 vegne av Vittorio Bertola Sendt: mandag 5. november 2018 21:55 Til: bzs@theworld.com Kopi: Hrpc Emne: Re: [hrpc] Over the top is over the top ... I don't have problems with finding a different term, though I note that= the "OTT vs ISP" terminology is the common standard in policy and regulato= ry circles in Europe ... ... I don't think that there is any other equivalent term in common use tha= t captures the problem and identifies a set of companies that do not supply= connectivity, are huge, are transnational and are centralizing the Interne= t... Regards, --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.berto= la@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Nov 7 21:26:08 2018 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 C994A127332 for ; Wed, 7 Nov 2018 21:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.902 X-Spam-Level: * X-Spam-Status: No, score=1.902 tagged_above=-999 required=5 tests=[BAYES_80=2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJmrAaTEWW49 for ; Wed, 7 Nov 2018 21:26:05 -0800 (PST) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 93085127148 for ; Wed, 7 Nov 2018 21:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1541654764; bh=mxO2vRzoGBtTEu4bZAOgaZscm457MLuNytKrURQBFSg=; h=Date:From:To:Cc:Subject:References:From:Subject; b=Vlr9JfjtIpa7BMXut4IJ9xNPcdjnGFEhUZQ2oWJFreAQuygEjGp2JitzhnOBg17IyojLdkqgzwVzcYQt5FMeVUcV9uI1FzkSxqX5zSNP4EFf4aAhbPLTJB8hLUphu57ANbEEmcENttNykeVETUvYmokNzfQnAdJwFW+gt6cvzmMWVGPL8AZS8qavDWPKn98YCUh97GMSCRW3pjVko9UXhFq3UUhlNw5Ur0V8u9s9lRKrCy0S4XIvNa7KOF2AR5+bPHlYxkWoOoMb69eLVC1pHnwG3dkrNxLZMgZhRXW4Q8LeENtNbpYqjwfv03B6m8T0CwLNBeXKO9AMjvsRgIjTSA== X-YMail-OSG: hZIJe7AVM1mZN9qqyNalihDbcuBFVOOOI6Ehps0eTiVd8nBy1i8H98kNHwTSzRW GsSqUp4Crh0_jDM_6SfpdksohY2DV9H_KDgDqaEaTKM5gMhnpSjnRTDmJMvpNsmqBD_g3zfWhlI3 kurSTY_RVZL_9BAOTnpQon0t9l2uq6yB6igjUbIeTJ7glJnWGOOd4vmA8I7bSdeOS8NB_m4m420g g0bhP4zCum3thzAD_xW3b5Lu38KeXn2VBSG4kvzB5UxZnclwiIreOPb0rYSFptlzmu7pMm156th_ JzwJaeiSACzKiyQVSoZSHULwUfkrCYuSmbtcBIXrGM5g.8kMKCWWDIpGSzhe_p4U7He2ilVcPEl2 fMPpjXawinYnQlVGwHQaCc6H8smKw78G61yIvFKj0JzOW3yB1tGAjRSPZtGAj9blNyu9mBpoDWJV 2Qsnm2nG.T3R7gpxE_6QYZrCpKBZP4MFAK.Ak_7ARx5mDMhzi_sRxpOX91cEV1G4_dy_vF5g7hoC 75bho7JmdnZY8yQHEdIHaqdRgjwBJJW86rzp8E9I_jVunKgKP4Mh8GKlmSWNGWEQON.67Tu89xNZ O0FpzqHLhRNlA7H6PyQCx5hdk.gVYYV7yRG8TbrSD8jeetqg8y59TR7ZWyfupIyxJehnBedB4MMP ppmHjxXMrnHpKdCABtbS2LX6DMi0LUipJsPizhSBVEvyDZ2lNFhO44v3PFQE_QmHYWQNdRZg9DRc T0s2I7gh95oROmsquhVQT.DS2.Z8NY82j7Q5wTnvnHHwYIF_wvTNqYidsJg6RJljhtpW5a1ta2ZL ZqHSMk5a3vepQKKX_dWebvMbT1NYKicQ8Y6kEcUAvUXx_aJ3dhf0jb2EJevJisGXnJMLz1bNENOK WEyDolo8qmusPFevmWKptN3JYRvflLBBGvgHlzp7PritT8eo0h5FdZVXYIkw3sz2Chx2cKMo5e6a Rmv3D3TrfuqSPOXk_OuBpjHe3PouHaog8D_LNTDSbze_oF9TALTj9SJt6FAkgphNVn1BzPKhV4Y0 CG4qA.KZIG05y2ISHk3_AkwZSYY4aZ4xGmcCmdTm3xHg60vNpw2ANix96oOmafZkIvmZbh9mbH6T OKuhaHa.rVskr9HtXUpgKBr7SEVrqtbPBWM.Y Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Thu, 8 Nov 2018 05:26:04 +0000 Date: Thu, 8 Nov 2018 05:26:00 +0000 (UTC) From: Mark Perkins To: Hrpc Cc: Hr-rt Message-ID: <1850578816.785963.1541654760579@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_785962_500566482.1541654760578" References: <1850578816.785963.1541654760579.ref@mail.yahoo.com> X-Mailer: WebService/1.1.12710 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: [hrpc] =?utf-8?q?UN_Special_Rapporteur_analyses_AI=E2=80=99s_imp?= =?utf-8?q?act_on_human_rights?= X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 05:26:07 -0000 ------=_Part_785962_500566482.1541654760578 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable UN Special Rapporteur analyses AI=E2=80=99s impact on human rightshttps://e= dri.org/un-special-rapporteur-report-artificial-intelligence-impact-human-r= ights/ Interesting reading Mark P. ------=_Part_785962_500566482.1541654760578 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
UN Special Rapporteur analyses AI=E2=80=99s impact on human rights<= /div>

Interestin= g reading

Mark P.
------=_Part_785962_500566482.1541654760578-- From nobody Thu Nov 8 01:39:27 2018 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 2241E130E6C; Thu, 8 Nov 2018 01:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nt_KsFlCLytm; Thu, 8 Nov 2018 01:39:22 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 4376A130E2E; Thu, 8 Nov 2018 01:39:22 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id v18-v6so1153320wrt.8; Thu, 08 Nov 2018 01:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dsCVyZDMeMOOxof2bnRYy1QmT4fMdsqoYLt4xBtsfcE=; b=a8Tzffg5nPAmHlqWdWCPQ8qNyI9URC40ZiYnG2Nsqsec6U9TE/43f87XOK6P1WXTtO XqdXRCdU2VdRsVa30RcGGs3PNrwll4Lq1LmComhZGruBJSrES+aTeiV9VbBnwApijF9K rHCDffPux7mGyz7yvvQXiN3HnXCP1FaWR7Rnmvl733dkKAWKQPB2WuFaizbQ86LEU+zt 4qhgeRX8omrL8WRLiyN3OfDKMXGLj/eG3jtapiiqoWA5Iof6vbzWmgtJn5jBCYyBfQz+ +PNhZ2WpsprjJLzjxyQTmF90ou0+29UGO9mQRawmZ22J5RrMG4WBVGVV5+7U3DOy0S5g Whlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dsCVyZDMeMOOxof2bnRYy1QmT4fMdsqoYLt4xBtsfcE=; b=R5EgdfUMrC2gy4+eehM27lh7En/B0ylzcpccGzXFPWjK4m7rZhZyvn4BofNMgeUeyo 02gpmKDwRvVsVBZcCitzHRa8Mg4fhlQkucHSKi4AJCZ+1SdCuSVMGJVa+h0kt5VxqLwO DSCacqdNvmdAgBtzBrFyaiBzoNdzl/poQaIJrXP+gy/QUU/q6v5ADo8RKdJ8oZsn5us5 m9sbMGPB+hpv/Nll5WYKG5Uie1BtvFLO4LP8nxR9H4bIVWlBt3A7K2j35Mt3a7dDx/Es 6ZzDipL2nAuuC4broJU3kzFSPVGuGAXJ7mtJ480amoTxPWYmhVQakZycZu7Jwzqsg8mk VocA== X-Gm-Message-State: AGRZ1gKhgAVpdwhBAME0/JtYA8bAEqSKOudB/oTeMYwCfEtqzNUFqN2Y mbURloYwUf4THrmc55KSVcLu7/NM2+1HmPWcrSE= X-Google-Smtp-Source: AJdET5eyNu1wvWiqW+1BjLOZUANBWCHji3WQCoGP59czGl9zqc8KVevzyPDA+YFskxic6uStqiE1hflOl7JOE7Ccz9g= X-Received: by 2002:adf:df0a:: with SMTP id y10-v6mr3220868wrl.127.1541669960459; Thu, 08 Nov 2018 01:39:20 -0800 (PST) MIME-Version: 1.0 References: <1850578816.785963.1541654760579.ref@mail.yahoo.com> <1850578816.785963.1541654760579@mail.yahoo.com> In-Reply-To: <1850578816.785963.1541654760579@mail.yahoo.com> From: Corinne Cath Date: Thu, 8 Nov 2018 16:38:41 +0700 Message-ID: To: Mark Perkins Cc: Hrpc , hr-rt@irtf.org Content-Type: multipart/alternative; boundary="0000000000005aaab7057a24024c" Archived-At: Subject: Re: [hrpc] =?utf-8?q?UN_Special_Rapporteur_analyses_AI=E2=80=99s_imp?= =?utf-8?q?act_on_human_rights?= X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 09:39:26 -0000 --0000000000005aaab7057a24024c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Edri also did a good short(ish) write-up of the report: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4. UN Special Rapporteur analyses AI=E2=80=99s impact on human rights =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In October 2018, the United Nations (UN) Special Rapporteur for the promotion and protection of the right to freedom of opinion and expression, David Kaye, released his report on the implications of artificial intelligence (AI) technologies for human rights. The report was submitted to the UN General Assembly on 29 August 2018 but has only been published recently. The text focuses in particular on freedom of expression and opinion, privacy and non-discrimination. In the report, the UN Special Rapporteur David Kaye first clarifies what he understands by artificial intelligence and what using AI entails for the current digital environment, debunking several myths. He then provides an overview of all potential human rights affected by relevant technological developments, before laying down a framework for a human rights-based approach to these new technologies. 1. Artificial intelligence is not a neutral technology David Kaye defines artificial intelligence as a =E2=80=9Cconstellation of processes and technologies enabling computers to complement or replace specific tasks otherwise performed by humans=E2=80=9D through =E2=80=9Ccomp= uter code [...] carrying instructions to translate data into conclusions, information or outputs.=E2=80=9D He states that AI is still highly dependen= t on human intervention, as humans need to design the systems, define their objectives and organise the datasets for the algorithms to function properly. The report points out that AI is therefore not a neutral technology, as the use of its outputs remains in the hands of humans. ----------------------------------------------------------------- Support our work - make a recurrent donation! https://edri.org/supporters/ ----------------------------------------------------------------- Current forms of AI systems are far from flawless, as they demand human scrutiny and sometimes even correction. The report considers that AI systems=E2=80=99 automated character, the quality of data analysis as well = as systems=E2=80=99 adaptability are sources of bias. Automated decisions may produce discriminatory effects as they rely exclusively on specific criteria, without necessarily balancing them, and they undermine scrutiny and transparency over the outcomes. AI systems also rely on huge amounts of data that has questionable origins and accuracy. Furthermore, AI can identify correlations that can be mistaken for causations. David Kaye points at the main problem of adaptability when losing human supervision: it poses challenges to ensuring transparency and accountability. 2. Current uses of artificial intelligence interfere with human rights David Kaye describes three main applications of AI technology that pose important threats to several human rights. The first problem raised is AI=E2=80=99s effect on freedom of expression an= d opinion. On one hand, =E2=80=9Cartificial intelligence shapes the world of information in a way that is opaque to the user=E2=80=9D and conceals its r= ole in determining what the user sees and consumes. On the other, the personalisation of information display has been shown to reinforce biases and =E2=80=9Cincentivize the promotion and recommendation of inflamm= atory content or disinformation in order to sustain users=E2=80=99 online engagem= ent=E2=80=9D. These practices impact individuals=E2=80=99 self-determination and autonomy= to form and develop personal opinions based on factual and varied information, therefore threatening freedom of expression and opinion. Secondly, similar concerns can be raised in relation to our right to privacy, in particular with regard to AI-enabled micro-targeting for advertisement purposes. As David Kaye states, profiling and targeting users foster mass collection of personal data, and lead to inferring =E2=80=9Csensitive information about people that they have not provided or confirmed=E2=80=9D. The few possibilities to control personal data collecte= d and generated by AI systems put into question the respect of privacy. Third, the Special Rapporteur highlights AI as an important threat to our rights to freedom of expression and non-discrimination due to AI=E2=80= =99s increasingly-allocated role in the moderation and filtering of content online. Despite some companies=E2=80=99 claims that artificial intelligence= can support exceeded human capacities, the report sees the recourse to automate moderation as impeding the exercise of human rights. In fact, artificial intelligence is unable to resist discriminatory assumptions or to grasp sarcasm and the cultural context for each piece of content published. As a result, freedom of expression and our right not to be discriminated against can be severely hampered by delegating complex censorship exercises to AI and private actors. 3. A set of recommendations for both companies and States Recalling that =E2=80=9Cethics=E2=80=9D is not a cover for companies and pu= blic authorities to neglect binding and enforceable human rights-based regulation, the UN Special Rapporteur recommends that =E2=80=9Cany efforts = to develop State policy or regulation in the field of artificial intelligence should ensure consideration of human rights concerns=E2=80=9D. David Kaye suggests human rights should guide development of business practices, AI design and deployment and calls for enhanced transparency, disclosure obligations and robust data protection legislation - including effective means for remedy. Online service providers should make clear which decisions are made with human review and which by artificial intelligence systems alone. This information should be accompanied by explanations of the decision-making logic used by algorithms. Further, the =E2=80=9Cexistence, purpose, constitution and impa= ct=E2=80=9D of AI systems should be disclosed in an effort to improve the level of individual users=E2=80=99 education around this topic. The report also recommends to make available and publicise data on the =E2=80=9Cfrequency a= t which AI systems are subject to complaints and requests for remedies, as well as the types and effectiveness of remedies available=E2=80=9D. States are identified as key actors responsible for creating a legislative framework hospitable to a pluralistic information landscape, preventing technology monopolies and supportive of network and device neutrality. Lastly, the Special Rapporteur provides useful tools to oversee AI development: (1) human rights impact assessments performed prior, during and after the use of AI systems, (2) external audits and consultations with human rights organisations; (3) enabled individual choice thanks to notice and consent; (4) effective remedy processes to end human rights violations. UN Special Rapporteur on Freedom of Expression and Opinion Report on AI and Freedom of Expression (29.08.2018) https://freedex.org/wp-content/blogs.dir/2015/files/2018/10/AI-and-FOE-GA.p= df Civil society calls for evidence-based solutions to disinformation (19.10.2018) https://edri.org/civil-society-calls-for-evidence-based-solutions-to-disinf= ormation/ (Contribution by Chlo=C3=A9 Berth=C3=A9l=C3=A9my, EDRi intern) On Thu, Nov 8, 2018 at 12:26 PM Mark Perkins wrote: > UN Special Rapporteur analyses AI=E2=80=99s impact on human rights > > https://edri.org/un-special-rapporteur-report-artificial-intelligence-imp= act-human-rights/ > > Interesting reading > > Mark P. > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --=20 Corinne Cath - Speth Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute Web: www.oii.ox.ac.uk/people/corinne-cath Email: ccath@turing.ac.uk & corinnecath@gmail.com Twitter: @C_Cath --0000000000005aaab7057a24024c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Edri also did a good short(ish) write-up of the report:

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
4. UN Speci= al Rapporteur analyses AI=E2=80=99s impact on human rights
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In October 2018, the United Nations (UN) Special Rapporteur for the
promotion and protection of the right = to freedom of opinion and
expression= , David Kaye, released his report on the implications of
artificial intelligence (AI) technologies for human ri= ghts. The report
was submitted to th= e UN General Assembly on 29 August 2018 but has only
been published recently. The text focuses in particular on= freedom of
expression and opinion, = privacy and non-discrimination. In the report,
the UN Special Rapporteur David Kaye first clarifies what he und= erstands
by artificial intelligence = and what using AI entails for the current
digital environment, debunking several myths. He then provides an
overview of all potential human rights = affected by relevant
technological d= evelopments, before laying down a framework for a human
rights-based approach to these new technologies.=

1. Artificial intelligence is not a neutral technology
David Kaye defines artificial intelligence as a =E2=80=9Cconstellat= ion of
processes and technologies en= abling computers to complement or replace
specific tasks otherwise performed by humans=E2=80=9D through =E2=80= =9Ccomputer code
[...] carrying inst= ructions to translate data into conclusions,
information or outputs.=E2=80=9D He states that AI is still highly= dependent on
human intervention, as= humans need to design the systems, define their
objectives and organise the datasets for the algorithms to fun= ction
properly. The report points ou= t that AI is therefore not a neutral
technology, as the use of its outputs remains in the hands of humans.

-----------------------------------------------------------------
Support our work - make a recurrent donation!
https://edri.org/supporters/
-----------------------------------------------------------------

Curr= ent forms of AI systems are far from flawless, as they demand human<= br style=3D"font-family:Arial,Helvetica,sans-serif">scrutiny and sometimes even correction. The= report considers that AI
systems=E2= =80=99 automated character, the quality of data analysis as well as<= br style=3D"font-family:Arial,Helvetica,sans-serif">systems=E2=80=99 adaptability are sources o= f bias. Automated decisions may
prod= uce discriminatory effects as they rely exclusively on specific
criteria, without necessarily balancing them, a= nd they undermine
scrutiny and trans= parency over the outcomes. AI systems also rely on
huge amounts of data that has questionable origins and accur= acy.
Furthermore, AI can identify co= rrelations that can be mistaken for
= causations. David Kaye points at the main problem of adaptability when
losing human supervision: it poses chall= enges to ensuring transparency
and a= ccountability.
<= br style=3D"font-family:Arial,Helvetica,sans-serif">2. Current uses of artificial intelligence = interfere with human rights

David Kaye describes three mai= n applications of AI technology that pose
important threats to several human rights.

The first= problem raised is AI=E2=80=99s effect on freedom of expression and<= br style=3D"font-family:Arial,Helvetica,sans-serif">opinion. On one hand, =E2=80=9Cartificial i= ntelligence shapes the world of
info= rmation in a way that is opaque to the user=E2=80=9D and conceals its role<= /span>
in determining what the user sees an= d consumes. On the other, the
person= alisation of information display has been shown to reinforce
biases and =E2=80=9Cincentivize the promotion and = recommendation of inflammatory
conte= nt or disinformation in order to sustain users=E2=80=99 online engagement= =E2=80=9D.
These practices impact in= dividuals=E2=80=99 self-determination and autonomy to
form and develop personal opinions based on factual and v= aried
information, therefore threate= ning freedom of expression and opinion.

Secondly, similar = concerns can be raised in relation to our right to
privacy, in particular with regard to AI-enabled micro-targe= ting for
advertisement purposes. As = David Kaye states, profiling and targeting
users foster mass collection of personal data, and lead to inferring=
=E2=80=9Csensitive information abou= t people that they have not provided or
confirmed=E2=80=9D. The few possibilities to control personal data coll= ected and
generated by AI systems pu= t into question the respect of privacy.

Third, the Special= Rapporteur highlights AI as an important threat to
our rights to freedom of expression and non-discrimination = due to AI=E2=80=99s
increasingly-all= ocated role in the moderation and filtering of content
online. Despite some companies=E2=80=99 claims that arti= ficial intelligence can
support exce= eded human capacities, the report sees the recourse to
automate moderation as impeding the exercise of human ri= ghts. In fact,
<= span style=3D"font-family:Arial,Helvetica,sans-serif">artificial intelligen= ce is unable to resist discriminatory assumptions
or to grasp sarcasm and the cultural context for each piece o= f content
published. As a result, fr= eedom of expression and our right not to be
discriminated against can be severely hampered by delegating comple= x
censorship exercises to AI and pri= vate actors.
3. A set of recommendations for both companie= s and States
Recalling that =E2=80=9Cethics=E2=80=9D is no= t a cover for companies and public
a= uthorities to neglect binding and enforceable human rights-based
regulation, the UN Special Rapporteur recommen= ds that =E2=80=9Cany efforts to
deve= lop State policy or regulation in the field of artificial
intelligence should ensure consideration of human r= ights concerns=E2=80=9D.

David Kaye suggests human right= s should guide development of business
practices, AI design and deployment and calls for enhanced transparency,=
disclosure obligations and robust d= ata protection legislation -
includi= ng effective means for remedy. Online service providers should
make clear which decisions are made with human r= eview and which by
artificial intell= igence systems alone. This information should be
accompanied by explanations of the decision-making logic used = by
algorithms. Further, the =E2=80= =9Cexistence, purpose, constitution and impact=E2=80=9D
of AI systems should be disclosed in an effort to impro= ve the level of
= individual users=E2= =80=99 education around this topic. The report also
recommends to make available and publicise data on the =E2= =80=9Cfrequency at
which AI systems = are subject to complaints and requests for remedies, as
well as the types and effectiveness of remedies availab= le=E2=80=9D.
States are identified as key actors responsib= le for creating a
legislative framew= ork hospitable to a pluralistic information landscape,
preventing technology monopolies and supportive of netwo= rk and device
neutrality.

Lastly, the Special Rapporteur provides useful tools to oversee AI
development: (1) human rights impact = assessments performed prior, during
= and after the use of AI systems, (2) external audits and consultations
with human rights organisations; (3) ena= bled individual choice thanks to
not= ice and consent; (4) effective remedy processes to end human rights<= br style=3D"font-family:Arial,Helvetica,sans-serif">violations.

UN Special Rap= porteur on Freedom of Expression and Opinion Report on AI
and Freedom of Expression (29.08.2018)
ht= tps://freedex.org/wp-content/blogs.dir/2015/files/2018/10/AI-and-FOE-GA.pdf=

Civil society calls for evidence-based solutions to disinfor= mation
(19.10.2018)
https://edri.org/civil-society-calls-for-evidence-based-solutions-to-disi= nformation/

(Contribution by Chlo=C3=A9 Berth=C3=A9l=C3=A9my,= EDRi intern)

On Thu, Nov 8, 2018 at 12:26 PM Mark Perkins <marknoumea=3D40yahoo.com@dmarc.ietf.org>= ; wrote:
UN Special Rapporteur analy= ses AI=E2=80=99s impact on human rights

Interesting reading

Mark P.
____________________= ___________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


--
=
Corinne Cath - Speth
Ph.D. Candidate, O= xford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Emai= l: ccath@turing.ac.= uk & cor= innecath@gmail.com
Twitter: @C_Cath
--0000000000005aaab7057a24024c-- From nobody Thu Nov 8 10:28:30 2018 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 286291293FB for ; Thu, 8 Nov 2018 10:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bFDjB76l4brD for ; Thu, 8 Nov 2018 10:28:26 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 5474512426A for ; Thu, 8 Nov 2018 10:28:26 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id z80-v6so18872698ljb.8 for ; Thu, 08 Nov 2018 10:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vr0DuGwGikd3jGbF1F1Ad0MF5RzN+UCO8TqkQhQFa0s=; b=UrWHPREzRd80MQSNysSDb6Jalvas+LspV+lvXPPhVn8MS65YJMsAMTyr1pGN7/Sg25 frptUzE+G4kagZT9S7UDq8qMBqY7K4khOOp5dzAJT7q+eHqXpQ3IhP2JvXTXVZ/tdnsG opEyIqCW0M9so47JeFgIy2NGrXnCI4SKPDxbyCVrdxUepCzkCfSW4h2ojaPhiK/5gVkK wTLPLFTba04FuI4Wj9DtWTuZTujLRLFHnKsAq2rFDlOnVSoDp24K9Mjxyam1YACWtLJl soeAdhcA7yYKojVWCliuoE86K0+iEg0Rk6t+Xzf6FJQwiC1C0KkE4PjuSxLjV05VpDdK rh+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vr0DuGwGikd3jGbF1F1Ad0MF5RzN+UCO8TqkQhQFa0s=; b=QP0XYtm0ghddHS4ldLSplzJbXiuRD7IKYOzZ7ZmtQZa0LGbmHuTHd6BQ4/SfV876o7 huVRMUKZAuC7GMsq43KFofEWESzvXs3yqkeYv6T5Uac3LS7s1s+G2JbU53Wx2e3pVjd7 mg/UOFXcHOdffZyq/IvFUQoNBRfI6tVDcxEoh5wecxzu49PqP6H78TH1bTJlwuAb+VgP MbKoU9KFj/hVNRO+xOwWbTxBuEiRUHxksLKLPg8iGZBoQGjJUXu8th5hT8AQJAssl1el zb/8tE5b0yFehqqxmVSyYhhLfp7pftxQF9mAzQ+Hx/9wDiWbJgpHTI3djrPVNd+g4p03 Q1JA== X-Gm-Message-State: AGRZ1gKcOfcteWtl8qnTvXux8DZDVI1p/52QxUgqoknmQ0wVjprbDLBv ZwJjFVZT6SGB7PU1/0JN8A7iRGPHUUEQuiyZBkA= X-Google-Smtp-Source: AJdET5eGCqnuHzx47NtyggkHcY10K2Ds6sYO7b78NhMirgJPsTEaohm51uzcj2S87Brpku9DON/zPZqVKI9j0esNYIE= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr3853579ljb.51.1541701704373; Thu, 08 Nov 2018 10:28:24 -0800 (PST) MIME-Version: 1.0 References: <740537359.6430.1541389972871@appsuite.open-xchange.com> <2052205710.6437.1541391067525@appsuite.open-xchange.com> <5AAA1A20-647A-4B5E-B2B3-EBF251B8B27C@akamai.com> <23520.40373.219087.642362@gargle.gargle.HOWL> <2084682636.12600.1541451321691@appsuite.open-xchange.com> <62d2930f-b6a2-e3aa-fcb8-c2cb873650ef@article19.org> In-Reply-To: <62d2930f-b6a2-e3aa-fcb8-c2cb873650ef@article19.org> From: Seth Johnson Date: Thu, 8 Nov 2018 13:27:39 -0500 Message-ID: To: Amelia Andersdotter Cc: Hrpc , vittorio.bertola@open-xchange.com, Ted Lemon Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [hrpc] Over the top is over the top X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 18:28:29 -0000 On Tue, Nov 6, 2018 at 3:30 AM Amelia Andersdotter wrote: > > Top-posting because topical but not immediately in response to anything. > The term "Information society service" vertically separates the other > way (I think of this personally in terms of OSI - while "OTT" tries to > separate out layer 7 and perhaps 6, ISS indicates stuff that's on layer > 3 and above and discards the physical/link). I'm proposing it as an > alternative? > > It's an infrequently used term (it doesn't fit any marketing scheme, I > guess) that is nevertheless established since the 1990s (including at > the ITU, but less frequently used). > > On 2018-11-05 23:30, Ted Lemon wrote: > > I thought I was pretty explicit about why I thought it was a bad > > term. If you want a term for Facebook or Youtube, I think "online > > service platform" works pretty well, and doesn't have the connotations > > that come with saying that it is "over the top." The distinction > > between an online service platform provided by an ISP (not over the > > top) and an online service platform not provided by the ISP (over the > > top) is an artificial distinction which exists because of the ISP's > > marketing strategy, not on some technical basis. A couple comments with reference to Amelia and Ted's comments above, but also the establishment of the term OTT as referenced by Vittorio below (and others like Frode) If you want to reference the big bad online service platforms like facebook and Google and Amazon, Ted's term works really well, doesn't designate the infrastructure being marketed by the ISPs. There is an infrastructure being marketed as well as rationalized by the ISPs via intergovernmental fora, so understanding how to separate is also important to the question of what you end up supporting by the terms you use. Terms that substitute for the type of layering the ISPs want us to have in mind as they establish their infrastructure don't really do the job, and yet sure recognized terms that key to established traditions are a preferred type of language, so Amelia's observation is really helpful. However, the Information Society is a part of the international manifestation of the domestic moves to vertical integration, began at that time (1995 G7 info society, then 1996 ISAD in South Africa UN started using the term [as well as the term ICT] -- but also telecom was reframed at the international level in 1996 as well), so I remain wary of references to it though I think you would be doing better if you keyed to the concept Amelia refers to, even though my guess is the IETF community is wary of UN or ITU terms (as I tend to be unless we can get them to understand the Internet better). I prefer Ted's term, though I think Amelia's making a very good point about wanting to choose a term that would more definitely separate better. I want to also point at ITU PP Resolution 178, which is still in sway though I've not heard any intention to engage on it at this plenipot: "ITU role in organizing the work on technical aspects of telecommunication networks to support the Internet" https://www.itu.int/en/action/internet/Documents/PP10-RESOLUTION%20178.pdf https://www.itu.int/en/action/internet/Pages/resolutions.aspx It's one I've been watching for awhile. This is really as "nitpicky" as their use of the term Internet. The rationalizing work it does is as follows: if they get governments going along with a certain notion of what's "under the top," this resolution lets them claim that as infrastructure *for the Internet as such.* So there's space to hold that off by avoiding terms that so specifically semantically designate a topological relationship like the term OTT. Of course, lots of other things code to this resolution this way, anything we might question regarding "technical infrastructure," but the term OTT is a particularly blunt example. Such is how these proceedings work, in many pieces over time. :-) Seth > > On Tue, Nov 6, 2018 at 3:55 AM Vittorio Bertola > > > > wrote: > > > > > Il 5 novembre 2018 alle 20.44 bzs@theworld.com > > ha scritto: > > > Vittorio might recall that when "OTT" first appeared in Nalini's > > draft > > > my reaction in private email was that this was not a term I was > > > familiar with and wondered if it was just me or more generally true. > > > > This is true, so initially I took Ted's concern as similar to > > yours, i.e. "this is a term I never heard and I don't like it". > > But thanks to Seth and other people now I understood what the real > > concern is, i.e. "this is a term which is commonly used in > > ITU/telco circles and I don't like it". Again, I don't have > > problems with finding a different term, though I note that the > > "OTT vs ISP" terminology is the common standard in policy and > > regulatory circles in Europe (and, as I see from the link, also in > > Latin America), so it's not necessarily overloaded with pro-ITU > > stances (ironically, I was one of those many people that 15-20 > > years ago put effort in preventing the ITU from becoming the main > > Internet policy-making venue). However, I don't think that there > > is any other equivalent term in common use that captures the > > problem and identifies a set of companies that do not supply > > connectivity, are huge, are transnational and are centralizing the > > Internet. Perhaps something like "[big] global > > Internet platforms"? Let me think at this. > > > > Regards, > > -- > > > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > > vittorio.bertola@open-xchange.com > > > > Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu Nov 8 13:54:20 2018 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 41FD4130DBE for ; Thu, 8 Nov 2018 13:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=NJbqsjcD; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=fFIMZ4GG 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 aQjRNjF2fxBP for ; Thu, 8 Nov 2018 13:54:17 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22718130934 for ; Thu, 8 Nov 2018 13:54:16 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.226.54.74]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id wA8Lrwdo013827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2018 13:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1541714049; x=1541800449; bh=hg5DrDdrIAWy0zMennuiDmO7va2xq/3UzC0xPA8pyhk=; h=Date:To:From:Subject; b=NJbqsjcDlVS2xU0qkZkQqeDD7Z0x+sT6llz6w3mPOvNE04BoA60+Koh72rD87e6z6 v6f5Kcw4EMLMC497M/BlzxRkrgwIcNHvAmk5WSBS+YvaFAxa4bZK8SjNASIl1Pd/cj CHRrpnrJAblofVyepUo5utc5H8j+btXLoPHQwZ7w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1541714049; x=1541800449; i=@elandsys.com; bh=hg5DrDdrIAWy0zMennuiDmO7va2xq/3UzC0xPA8pyhk=; h=Date:To:From:Subject; b=fFIMZ4GGsMmxgZYXtnjhQqHn2hidxbFPMlskFtuXISO2acHNZ+5ebSebYx4KAM4qL eArw5lnkRzYxI5K+9A/2yUcOK+8WFYWUbfq6tRBA+NN3IQZB9iT5Qdkjmx6YorrA0i jtJrf7Gb/hiyfgzyow30IJusiG68YkrKiCrKFv9g= Message-Id: <6.2.5.6.2.20181108134443.0df91750@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Nov 2018 13:45:33 -0800 To: Mallory Knodel , hrpc@irtf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] IESG and IETF Chair report for IETF 103 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 21:54:18 -0000 Hi Mallory, At 07:46 PM 07-11-2018, Mallory Knodel wrote: >I'm wondering if we might do some very careful work to present diversity >statistics. This might build evidence for some of what was discussed in >the open mic portion of the plenary. In the past I have seen requests >for this elsewhere in IETF but also in the larger technical community. >For example there was an analysis done of ICANN mailing list engagement >and meeting attendance. It wasn't comprehensive but it was precise. And >therefore useful! Will you be looking into intersectionality? Regards, S. Moonesamy From nobody Mon Nov 12 00:43:48 2018 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 5E0FC12958B for ; Mon, 12 Nov 2018 00:43:46 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 xGR5zm73V124 for ; Mon, 12 Nov 2018 00:43:44 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 A8665128D0C for ; Mon, 12 Nov 2018 00:43:44 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gM7op-0001y6-5h; Mon, 12 Nov 2018 09:43:39 +0100 To: S Moonesamy , hrpc@irtf.org References: <6.2.5.6.2.20181108134443.0df91750@elandsys.com> From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: <4b42a62f-df94-0ffd-d4cf-629abfcc7441@article19.org> Date: Mon, 12 Nov 2018 11:43:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20181108134443.0df91750@elandsys.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 51a43cd7ff6838d9e9bce89dbcde6c26 Archived-At: Subject: Re: [hrpc] IESG and IETF Chair report for IETF 103 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 08:43:46 -0000 On 09/11/2018 00:45, S Moonesamy wrote: > Hi Mallory, > At 07:46 PM 07-11-2018, Mallory Knodel wrote: >> I'm wondering if we might do some very careful work to present diversity >> statistics. This might build evidence for some of what was discussed in >> the open mic portion of the plenary. In the past I have seen requests >> for this elsewhere in IETF but also in the larger technical community. >> For example there was an analysis done of ICANN mailing list engagement >> and meeting attendance. It wasn't comprehensive but it was precise. And >> therefore useful! > > Will you be looking into intersectionality? > Hi, We have limited data and we are looking at how to present that data. Can you explain more what you mean or would expect from a presentation of diversity statistics that takes into account intersectionality? Thanks, -Mallory -- Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Mon Nov 12 09:19:07 2018 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 AEC7C130EAE for ; Mon, 12 Nov 2018 09:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=oc9T47Zy; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=KI5mRyp0 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 LodNSpw-Cxec for ; Mon, 12 Nov 2018 09:18:58 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D49130E96 for ; Mon, 12 Nov 2018 09:18:57 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.224.106.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id wACHId76007268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2018 09:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1542043130; x=1542129530; bh=Th/ytWjg6YhTCDHWby06IBTwDbvEoLBUMWtuOLrl66Q=; h=Date:To:From:Subject:In-Reply-To:References; b=oc9T47ZyY/o86LqW16Sx2D8qMP8B6tx847zrUy3PpaZKVdEGcN3z5MSUxDsGsWSOP xwWHUhxtlLv3fVmFXSt+J0UBnOxC5zJGQ5Sg4tU6JGUTG6paaAMgG+nO2JzWNeYdtZ Jcf29hdqFk7qDci0FEqLhgkExRdb+rN3+qENCgiE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1542043130; x=1542129530; i=@elandsys.com; bh=Th/ytWjg6YhTCDHWby06IBTwDbvEoLBUMWtuOLrl66Q=; h=Date:To:From:Subject:In-Reply-To:References; b=KI5mRyp021ToQEilQQKTFeNlv9w3aYBQ/t3QmX4ReTXZHnQOqfnmpjaWBg7Gua3cY dD1aE+m/cIn+AI+h7oJMt/KsFEgZayiVDYfX+obFbsFFiGYHdPh9yfB7jgfDzY7mL6 Hl0NCkKAVxF9AOACuyNsYArtShlPipXePoAloseo= Message-Id: <6.2.5.6.2.20181112072346.083239b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 Nov 2018 08:34:55 -0800 To: Mallory Knodel , hrpc@irtf.org From: S Moonesamy In-Reply-To: <4b42a62f-df94-0ffd-d4cf-629abfcc7441@article19.org> References: <6.2.5.6.2.20181108134443.0df91750@elandsys.com> <4b42a62f-df94-0ffd-d4cf-629abfcc7441@article19.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] IESG and IETF Chair report for IETF 103 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 17:19:04 -0000 Hi Mallory, At 12:43 AM 12-11-2018, Mallory Knodel wrote: >We have limited data and we are looking at how to present that data. Can >you explain more what you mean or would expect from a presentation of >diversity statistics that takes into account intersectionality? I came across a paper about the subject [1]. I haven't put in much thought in whether that perspective should be taken into account for the research The statistics could inform the reader about the different identities along which a person is mapped. Regards, S. Moonesamy 1. https://nam.edu/wp-content/uploads/2016/12/Health-Inequities-Social-Determinants-and-Intersectionality.pdf From nobody Mon Nov 12 11:17:33 2018 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 F236E130E4B for ; Mon, 12 Nov 2018 11:17:29 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 dDfwWuYwl2jd for ; Mon, 12 Nov 2018 11:17:27 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 AC461130DCE for ; Mon, 12 Nov 2018 11:17:27 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gMHi9-0003iw-2i; Mon, 12 Nov 2018 20:17:25 +0100 Date: Mon, 12 Nov 2018 19:17:24 +0000 (UTC) From: Mallory Knodel To: S Moonesamy Cc: hrpc@irtf.org Message-ID: <2054456186.46795053.1542050244582.JavaMail.zimbra@article19.org> In-Reply-To: <6.2.5.6.2.20181112072346.083239b8@elandnews.com> References: <6.2.5.6.2.20181108134443.0df91750@elandsys.com> <4b42a62f-df94-0ffd-d4cf-629abfcc7441@article19.org> <6.2.5.6.2.20181112072346.083239b8@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.7.11_GA_1854 (zclient/8.7.11_GA_1854) Thread-Topic: IESG and IETF Chair report for IETF 103 Thread-Index: JfbjE/SFVSOh0uVJB1bY9Ry8f+VMoQ== X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 8b3222cd26cce149ddb9ffa05c4da76e Archived-At: Subject: Re: [hrpc] IESG and IETF Chair report for IETF 103 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 19:17:30 -0000 Hi, >From the paper, =E2=80=9Cthe researcher engages in deep self-reflection tha= t contextualizes and recognizes the ways in which race, gender, class, sexu= al orientation, disability, and other axes of inequality constitute inter- = secting systems of oppression.=E2=80=9D I don=E2=80=99t think that the limited data on attendance and participation= in lists is going to give us the ability to look at these various aspects = as a whole, unfortunately. -M ----- Original Message ----- From: S Moonesamy To: Mallory Knodel , hrpc@irtf.org Sent: Mon, 12 Nov 2018 16:34:55 -0000 (UTC) Subject: Re: IESG and IETF Chair report for IETF 103 Hi Mallory, At 12:43 AM 12-11-2018, Mallory Knodel wrote: >We have limited data and we are looking at how to present that data. Can >you explain more what you mean or would expect from a presentation of >diversity statistics that takes into account intersectionality? I came across a paper about the subject [1]. I haven't put in much=20 thought in whether that perspective should be taken into account for=20 the research The statistics could inform the reader about the=20 different identities along which a person is mapped. Regards, S. Moonesamy 1.=20 https://nam.edu/wp-content/uploads/2016/12/Health-Inequities-Social-Determi= nants-and-Intersectionality.pdf=20 From nobody Wed Nov 14 04:50:23 2018 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 5F45E124408 for ; Wed, 14 Nov 2018 04:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Z_wVG_AgQDnl for ; Wed, 14 Nov 2018 04:50:18 -0800 (PST) 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 84C69130DDE for ; Wed, 14 Nov 2018 04:50:18 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 179F228051E for ; Wed, 14 Nov 2018 13:50:16 +0100 (CET) Received: from relay01.prive.nic.fr (pa-th3.interco.nic.fr [192.134.4.74]) by mx4.nic.fr (Postfix) with ESMTP id 127E62803BB for ; Wed, 14 Nov 2018 13:50:16 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 0F55E6423522 for ; Wed, 14 Nov 2018 13:50:16 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 096B540287; Wed, 14 Nov 2018 13:50:16 +0100 (CET) Date: Wed, 14 Nov 2018 13:50:16 +0100 From: Stephane Bortzmeyer To: hrpc@irtf.org Message-ID: <20181114125015.u7htljky6hn2yi4v@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 9.5 X-Kernel: Linux 4.9.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.11.14.123917 Archived-At: Subject: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 12:50:22 -0000 https://www.ietf.org/about/participate/get-started/ "We try to avoid policy and business questions, as much as possible." This seems at odds with several RFC (including of course RFC 8280). An old text which was never revised? From nobody Wed Nov 14 04:56:47 2018 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 EE62F130E3D for ; Wed, 14 Nov 2018 04:56:44 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ft1z5HfUYYMM for ; Wed, 14 Nov 2018 04:56:42 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 56BF7130E07 for ; Wed, 14 Nov 2018 04:56:42 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gMuim-0001bz-Cs for hrpc@irtf.org; Wed, 14 Nov 2018 13:56:40 +0100 To: hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= xsFNBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABzShOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+wsGZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI87BTQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAcLBZQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Wed, 14 Nov 2018 13:56:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181114125015.u7htljky6hn2yi4v@nic.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 71684ae416b12bc74806129cb02de027 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 12:56:45 -0000 Good catch, I forwarded it to the website team. On 11/14/18 1:50 PM, Stephane Bortzmeyer wrote: > https://www.ietf.org/about/participate/get-started/ > > "We try to avoid policy and business questions, as much as possible." > > This seems at odds with several RFC (including of course RFC > 8280). An old text which was never revised? > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Wed Nov 14 08:24:46 2018 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 46706130DD7 for ; Wed, 14 Nov 2018 08:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wdmDBRmDB8A9 for ; Wed, 14 Nov 2018 08:24:41 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 3D55612F1A6 for ; Wed, 14 Nov 2018 08:24:41 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id 96so1071719wrb.2 for ; Wed, 14 Nov 2018 08:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8CG7yM3YxrUInA1wYYKId/qMXW3QnZctVPsJvNp42m4=; b=gggo0kgFONk2OberPUfW9p0XL2dNEuTKAJqTFPOgb0Xo1OIaykhjUVUjDy9/hQoVQm GdM+pt5mlJw32rBG6al6HcQLLwv8Amyrg6eaL/xG3EmPBHsCdBwY/q/kUv6lyHXB85Xn YK5o2fuS8Czh0jjiX0IGys9O5tMtilDHCW4OZUzYwkqatpyMtZ8aCmwgl2KGQHnK0CMj U4CVWRhCh7KtoeIBrzihQRYjU3iI8JJU7GRpCIIWqbVkKwZVHeM7q8LUVR+J1gWAJ2pB LbsiqyLK0M86UINqZmzy0q0fITdj9xgIB5l24YY1ZfshM0DYKaOBZQO6fM8AC1N+586a rQRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8CG7yM3YxrUInA1wYYKId/qMXW3QnZctVPsJvNp42m4=; b=QXKAk+PRG77w1wzMMLpUzShkKgXMeIPbEMIvI7OSxZlrMFLr+YEHTjK5+tGrg1sn3r xHYjDUmwSvlEwBCBugAKcBu6a5Jg1uMWz6pkwNhB5WX/a7NNlxvfKFV3js+Es/0/St/1 1JCOcFlnR3HGDSSwS5Poo/V5w9vQ22TJ6lvV1jkoi8fh/zl1D2JHYokREFDtAl/BdC9A fGXGVDWD4wVIJat0BSg+k+/7/VeffGZ81UgkkbLMfeR4wItuFGrHjsis0s8WYXmWu/YE DE6d1ZPDpUJ7QSdlVpZQgDKsDb32Nk8o8BBW6/TmLu1yeCU7SAUs5IDeUsr/k0b4AtRC haaA== X-Gm-Message-State: AGRZ1gImBZ1JofoOySt6chfQfRVDwR+DqT648STl+vY5AsSVEng7PH2V mEPvkrGASCcyiO6X69KOaaUVNo7pVT15zxrWXEKgEleC X-Google-Smtp-Source: AJdET5dxYgjn9nV1OT1HX7AAnpNs3SNPf7vwAtisYPmmm4HHqarph//e5x+tKjZ38Mq7TgB0kCdMZSGZZsI1lIi2nhI= X-Received: by 2002:a5d:4344:: with SMTP id u4-v6mr2400765wrr.306.1542212679569; Wed, 14 Nov 2018 08:24:39 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> In-Reply-To: From: Corinne Cath Date: Wed, 14 Nov 2018 16:24:03 +0000 Message-ID: To: Niels ten Oever Cc: Hrpc Content-Type: multipart/alternative; boundary="000000000000ef204d057aa25e5c" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 16:24:44 -0000 --000000000000ef204d057aa25e5c Content-Type: text/plain; charset="UTF-8" which other RFCs is it at odds with? On Wed, Nov 14, 2018 at 12:56 PM Niels ten Oever wrote: > Good catch, I forwarded it to the website team. > > On 11/14/18 1:50 PM, Stephane Bortzmeyer wrote: > > https://www.ietf.org/about/participate/get-started/ > > > > "We try to avoid policy and business questions, as much as possible." > > > > This seems at odds with several RFC (including of course RFC > > 8280). An old text which was never revised? > > > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > -- > Niels ten Oever > Researcher and PhD Candidate > Datactive Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Corinne Cath - Speth Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute Web: www.oii.ox.ac.uk/people/corinne-cath Email: ccath@turing.ac.uk & corinnecath@gmail.com Twitter: @C_Cath --000000000000ef204d057aa25e5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
which other RFCs is it at odds with?

On Wed, Nov 14, 2018 at 12:56 PM Niels te= n Oever <mail@nielstenoever.ne= t> wrote:
Good catch, I forw= arded it to the website team.

On 11/14/18 1:50 PM, Stephane Bortzmeyer wrote:
> https://www.ietf.org/about/participate/get-s= tarted/
>
> "We try to avoid policy and business questions, as much as possib= le."
>
> This seems at odds with several RFC (including of course RFC
> 8280). An old text which was never revised?
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc
>

--
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint=C2=A0 =C2=A0 2458 0B70 5C4A FD8A 9488=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0643A 0= ED8 3F3A 468A C8B3

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


--
=
Corinne Cath - Speth
Ph.D. Candidate, O= xford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Emai= l: ccath@turing.ac.= uk & cor= innecath@gmail.com
Twitter: @C_Cath
--000000000000ef204d057aa25e5c-- From nobody Wed Nov 14 08:34:11 2018 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 472AC130EB7 for ; Wed, 14 Nov 2018 08:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 mqMQYNHUfrOe for ; Wed, 14 Nov 2018 08:34:07 -0800 (PST) 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 599F8130DD7 for ; Wed, 14 Nov 2018 08:34:07 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 8ECF3280141; Wed, 14 Nov 2018 17:34:04 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 88930280604; Wed, 14 Nov 2018 17:34:04 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 81115280141; Wed, 14 Nov 2018 17:34:04 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 7D48C642C581; Wed, 14 Nov 2018 17:34:04 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 7BAF240287; Wed, 14 Nov 2018 17:34:04 +0100 (CET) Date: Wed, 14 Nov 2018 17:34:04 +0100 From: Stephane Bortzmeyer To: Corinne Cath Cc: Niels ten Oever , Hrpc Message-ID: <20181114163404.eodmzqdirmfdhwdc@nic.fr> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.5 X-Kernel: Linux 4.9.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.148190, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.11.14.161518 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 16:34:10 -0000 On Wed, Nov 14, 2018 at 04:24:03PM +0000, Corinne Cath wrote a message of 125 lines which said: > which other RFCs is it at odds with? 1984, 2804, 6973, 7258, 8404 and certainly others. From nobody Wed Nov 14 08:56:10 2018 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 DBA04130E26 for ; Wed, 14 Nov 2018 08:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 5GyRrYn3yDeo for ; Wed, 14 Nov 2018 08:56:05 -0800 (PST) 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 D80EA130DE4 for ; Wed, 14 Nov 2018 08:56:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A9FBEBE4D; Wed, 14 Nov 2018 16:56:01 +0000 (GMT) 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 AnrJxF7vMc-Z; Wed, 14 Nov 2018 16:56:01 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 55A10BE38; Wed, 14 Nov 2018 16:56:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542214561; bh=jpwttF7gskwINSCnt35oBFyWTPfomVPTzvaINPSwHpg=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=vwTXPysy0HW1kJFG2EYUBPW+tfHYYybpVnECoEfqpRW0vZTBDbTF+FQKWxHBFOAkw wvanwxPjtG5k76SQ6Iq+jgK3b69xMk8HxYh111l58C9hwWECIUHX8JzgJm3v13u2YE zu1BwQLq7hfLfBYNFNW2fyBCD+55RvEU6x0agQ70= To: Stephane Bortzmeyer , Corinne Cath Cc: Hrpc , Niels ten Oever References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 14 Nov 2018 16:56:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181114163404.eodmzqdirmfdhwdc@nic.fr> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="198WJUpys2WunaPmcNxfBtj0AvF4crVe2" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 16:56:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --198WJUpys2WunaPmcNxfBtj0AvF4crVe2 Content-Type: multipart/mixed; boundary="4WSGHcXH3KgdYiKkazeg8tmn4DNLlO1gS"; protected-headers="v1" From: Stephen Farrell To: Stephane Bortzmeyer , Corinne Cath Cc: Hrpc , Niels ten Oever Message-ID: Subject: Re: [hrpc] "We try to avoid" References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> In-Reply-To: <20181114163404.eodmzqdirmfdhwdc@nic.fr> --4WSGHcXH3KgdYiKkazeg8tmn4DNLlO1gS Content-Type: multipart/mixed; boundary="------------79DAD43BAE65779F2C33EEC1" Content-Language: en-GB This is a multi-part message in MIME format. --------------79DAD43BAE65779F2C33EEC1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/11/2018 16:34, Stephane Bortzmeyer wrote: > On Wed, Nov 14, 2018 at 04:24:03PM +0000, > Corinne Cath wrote=20 > a message of 125 lines which said: >=20 >> which other RFCs is it at odds with? >=20 > 1984, 2804, 6973, 7258, 8404 and certainly others. Personally, I have no problem with "avoid... as much as possible" and don't think it actually conflicts with any of those RFCs. (Noting also that 8280 is an IRTF and not an IETF RFC.) So FWIW, I'm fine with the web page staying as-is. (And also: I wonder is this a change that's really worth much effort?) Cheers, S. >=20 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --------------79DAD43BAE65779F2C33EEC1 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------79DAD43BAE65779F2C33EEC1-- --4WSGHcXH3KgdYiKkazeg8tmn4DNLlO1gS-- --198WJUpys2WunaPmcNxfBtj0AvF4crVe2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvsU6AACgkQWrL68XsX K+riXQ/9EysMmBKReQWJjeluNaCHpvuNs9WyPeOL1yWkelv8cNue5Il0Lmcb2NKZ WjheHA9efJvP1wMNszPdwhL2oy0972yIzKpB0Ub1RKMYDkXx1LJz6oXSmqfvwFbN 1Q0UMswvIOSf8H9QDNVUmxhJE0REQfYrCEMvlLRDRCOtdR1DUvddGXdj7u4jMC+g tahQqRvaS8QOYXCI4YSKgXbnrvJsuWxanVUuAP2o6LBZup3M6NhmtiuFMD793e6d w13ji2QMFxZF0qHi3g22NyQMmyxCh8LNLiC8zQj/Y5bZHDmo4/MQU2/DT40yw4hg 7LhvBMS/I4pQPnV2+F7lleI05QTNQ2NOzUWjo+CvoWUv/2zbdQqw9DZMKEmSzCcG 1Ymtrm7vT77Hjz0AiGz8MycBK23k9lB3WOU3/9Zbu7xSZ1cC9+65xJZUbhVz8pV6 wqDTw3ap3UP1PwSPiyIWVjGKqel3QYdgGdmIedd2Wazn9AXtHSrsYF8MJz++hpV8 rLgXsBawS/RIuXYPx5L/1pRITLLmGuzeDkd44q4ZzS5TKzVeSNkGocmPVXPYjGqA 5+hAg6aM643il/3gKx7UHNCAUFNyL3LjpPuDwoZvmPHdc8h/uvANUtdbjKPZQq1b m3112s+P9oGo++e8nnIoWK4nJ2DSHZG7z7BOHFW9URRZ4RHrRko= =bS9D -----END PGP SIGNATURE----- --198WJUpys2WunaPmcNxfBtj0AvF4crVe2-- From nobody Wed Nov 14 09:43:57 2018 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 2F47112958B for ; Wed, 14 Nov 2018 09:43:56 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 Pzzx2ebSAsR1 for ; Wed, 14 Nov 2018 09:43:54 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 59F1A127333 for ; Wed, 14 Nov 2018 09:43:54 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id w22-v6so8130857plk.0 for ; Wed, 14 Nov 2018 09:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Kzpd+T4SCm9j3IOSiYkIlQNJLIWDKp1fKTPY1I5Y7fU=; b=w9DzUczHS48vpbCKAFuj6DQhfSBZP+iy6flCg+iuWj5pC/zHzh3SEYelxLb0cE6OJx GAJ0S2/bN4P4aDxsVVLlKQtz1W1ppLa4E+AnLVe8UvEZnHNva4trBFpVV3SiXh7XqgZQ 9m0mev7QkJBCkrj6USemIO0KmbJZO0p7oWKn8xxHDSaTJts/wxtRTtHP8TvrlaKvJR98 rRY4x+iG/EBgEjIiT6s/nabI0o5iZVVqd+2+BgO10FmIB87dXcNhU01NT2pQeS/Cqc+D yUAUyZ+BIkExb5yVlZNXqAOTLhMVFgPaO7qushpCnMRa6kz8jVj1Gt064t4ph0781rYW M1Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Kzpd+T4SCm9j3IOSiYkIlQNJLIWDKp1fKTPY1I5Y7fU=; b=nNrAz/HYiiWub8m2aivato6D720KTcmLUBujjivMzw1fn1mXiZBR0J6wbKsz/AEjVE c8515LCNvrvcI6kdu94vrm3QeKRp6QQuh0bSNVBSryp0X1GeWF6xiUUTbRjZYnqikyvr UzH8vDis7vHAkVh/bJNtFU/GRbYgRhXLftV4R2hpZ2yYeInEosFV6SXWLZ+x9IOlomWI G/e+P3yCteLTBKsSsu0hVLdo4yJGnMTSyWHYyn/Pc5UU7cucmeLsHDTNRrINiwNRezM0 NaDgyOKkbBo1lYVQ3zwAwosXxdbdVvZAg7bpY2m2n6Ooulq8LMnWXip8x04w3RTofREY //9A== X-Gm-Message-State: AGRZ1gL+tc/nmB1YAMZgsMRmXVQWD1+CigkU3FrH0thBgRv/TJK9lu/O GnFZiHrUXSfo5bnGW5b9fKwfQGoZ1A== X-Google-Smtp-Source: AJdET5eBDcsuV+W1HEzWvZW4AQtf5M9TuRYP3Vldc/EV5s0QUNKLowzrroIAKW4sS78xyvyfAFC2YQ== X-Received: by 2002:a17:902:b611:: with SMTP id b17-v6mr2880236pls.31.1542217433432; Wed, 14 Nov 2018 09:43:53 -0800 (PST) Received: from aspen.local (216-67-35-146-radius.dynamic.acsalaska.net. [216.67.35.146]) by smtp.gmail.com with ESMTPSA id 73-v6sm29928115pfl.142.2018.11.14.09.43.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Nov 2018 09:43:52 -0800 (PST) To: hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> From: Melinda Shore Message-ID: Date: Wed, 14 Nov 2018 08:43:50 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181114125015.u7htljky6hn2yi4v@nic.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 17:43:56 -0000 On 11/14/18 3:50 AM, Stephane Bortzmeyer wrote: > "We try to avoid policy and business questions, as much as possible." I like to think of that as aspirational, although clearly it's not really accurate. I'm not sure the consequences of leaving it in there are particularly problematic and would be fine with leaving it as-is. Melinda -- Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis From nobody Wed Nov 14 23:50:31 2018 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 EAC6112872C for ; Wed, 14 Nov 2018 23:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4lOgvT8FqCD for ; Wed, 14 Nov 2018 23:50:22 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 CC8F5126BED for ; Wed, 14 Nov 2018 23:50:20 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gNCPr-0006fA-3y for hrpc@irtf.org; Thu, 15 Nov 2018 08:50:19 +0100 To: hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: Date: Thu, 15 Nov 2018 10:50:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K58BMWSzcpHCT8S2XbHZeZQzdLxRKSaUv" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: a6d9551f4f6a9cf0aa9f9bf7e32696d9 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 07:50:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K58BMWSzcpHCT8S2XbHZeZQzdLxRKSaUv Content-Type: multipart/mixed; boundary="VnXW0MvBlDDebxq0CFshuTylznE7hSqs8"; protected-headers="v1" From: Mallory Knodel To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] "We try to avoid" References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> In-Reply-To: --VnXW0MvBlDDebxq0CFshuTylznE7hSqs8 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 14/11/2018 19:56, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 14/11/2018 16:34, Stephane Bortzmeyer wrote: >> On Wed, Nov 14, 2018 at 04:24:03PM +0000, >> Corinne Cath wrote=20 >> a message of 125 lines which said: >> >>> which other RFCs is it at odds with? >> >> 1984, 2804, 6973, 7258, 8404 and certainly others. >=20 > Personally, I have no problem with "avoid... as much as > possible" and don't think it actually conflicts with any > of those RFCs. (Noting also that 8280 is an IRTF and not > an IETF RFC.) So FWIW, I'm fine with the web page staying > as-is. >=20 > (And also: I wonder is this a change that's really worth > much effort?) I appreciate Stephen and Melinda weighing in that perhaps this is not an important statement to correct and that we can carry on. But just wondering, what is the original purpose of that statement? -Mallory --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --VnXW0MvBlDDebxq0CFshuTylznE7hSqs8-- --K58BMWSzcpHCT8S2XbHZeZQzdLxRKSaUv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlvtJTYACgkQDDKicb08 x4DK5ggAqxUtnPSpuvtASe5v1M1LyaqlyCwCNI2fyUE5qYQ9y+NvEKdM5i3HZhp1 5oOSiG37p2RPYihDDrTD2kbwjIYpkwY0D88TMNrArLtd014jOz02e5O5GQEdKnpA 3SIFOr30Wmwy0i117Pt89hYB8YeET3A1xEVEAC+yeGxC1HhAFu/wxf7NFK+xhl09 bllPh0TEoRv7tZss4pkNc51l5SrMHnfNKQTjMQgB+IvPbW9c8Pyf4Gw+fvgzpMHR i4urGU0P+eFM4xqAh1B+eyeoTHy6J29YGfk9oYSUPknXNMseUtKGBhLp0Vife6vu BK7gzmVHMfVQER3p48pB3X879T7lAw== =QJdS -----END PGP SIGNATURE----- --K58BMWSzcpHCT8S2XbHZeZQzdLxRKSaUv-- From nobody Wed Nov 14 23:53:23 2018 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 AF834128766 for ; Wed, 14 Nov 2018 23:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9WpRxEbda_8 for ; Wed, 14 Nov 2018 23:53:19 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 07A51126BED for ; Wed, 14 Nov 2018 23:53:19 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gNCSi-0007Q8-Pj for hrpc@irtf.org; Thu, 15 Nov 2018 08:53:17 +0100 To: hrpc@irtf.org From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: <139810c5-9d22-530c-f914-719cdb7ebf0c@article19.org> Date: Thu, 15 Nov 2018 10:53:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 7b320cd02cd98c580351ccd23ba1512a Archived-At: Subject: [hrpc] HRPC 103 minutes X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 07:53:21 -0000 Thanks a lot to dkg and Corinne for the minutes at both HRPC I and HRPC II (which was scheduled on Thursday for one hour after it was clear we needed to finish our full agenda). The minutes are in the datatracker please get at me if you want something corrected or added: https://datatracker.ietf.org/doc/minutes-103-hrpc/ Very productive meetings! Thanks so much, everyone, -Mallory -- Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Thu Nov 15 07:19:56 2018 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 E2A68130DCE for ; Thu, 15 Nov 2018 07:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 kweBV2JkNpZI for ; Thu, 15 Nov 2018 07:19:52 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 C226412D4EF for ; Thu, 15 Nov 2018 07:19:52 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id m5so32297639qka.9 for ; Thu, 15 Nov 2018 07:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/U+mBzBZNyh0V2oKkhECb9Q/sAM0IrH/6xhLDJEw234=; b=Rx6Mwjtu9LBha3kOXybKgm390Yyz4gR6qXxSXyPqpf/2LPy0wvBIIg88qEYHS3Hqow 0d1tUo9VGQL4Oz3pcKMuogZq1y/tcibG0sy5Qis9U1mmtBGuirTzQ4zuOWVkR6HxK9nD 1h9U9cAAnxBpDzSTtLHONpqjsInkv/Qj9eOwzR7oWOa5YyCsHEZXB7kAtywlmHPbS6Q7 SCDG5pby57mUX/yKuP+8gvQ+bNhd2Rn1cJLAPUJsnOIOYiHeRKsAI8re0w1OBxUyIH1G m0vYO5o8AP2Nn8yVvHmLlSifFQYYH/41x07NvMifsrqL3BggRJOiU/TDtb9jI8aDSmor WOoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/U+mBzBZNyh0V2oKkhECb9Q/sAM0IrH/6xhLDJEw234=; b=Ht5HGeYzXEdS2rewRXFxWpwVenunVAb12eZZZuhnfFuQ87MoWpJKLnF0nk/LcWw4Xm IowTlTOqORJMTGczar9gYKor3yBJhTR9+nTuKA0BFMXHoJ28na06V1XcZRCJ5QpPgfnp G435qUYR3MpzLxJQZteI498BIBOs0bd+tDCR+BR0y0AtxavChOPsC5vWzB7R0+b+a86T taZXBQEYvpAA6WUUQuKEdr9t5+yb+CTrNoqidRMxM0DzIrwC3HyXIWlO2olMe95ISBO3 Mv7meDMB7OC8PR+A/o83R8Uw1kWXBI46q9erdIGENWvkgjULy2TaU9Huj1jlqSQO9KRI DrOA== X-Gm-Message-State: AGRZ1gJJN8iZ/yxttLGfWaxcUoIEPHzdGQP9vqoxgsqgRbO/iaStRBWZ 0fchex+2R94L0B6vX4g++5o0HUpEM31p8+/rChLCFQ== X-Google-Smtp-Source: AJdET5dgSVNGnfDFYC1kIUYXGiowWhnNiFtuEDLcd/yIwi83Wm4Bpn50eLRXui/p0k0R786n8y719BtFkwXlQo79xLo= X-Received: by 2002:ac8:18fa:: with SMTP id o55mr6485817qtk.256.1542295191635; Thu, 15 Nov 2018 07:19:51 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> In-Reply-To: From: Ted Lemon Date: Thu, 15 Nov 2018 10:19:15 -0500 Message-ID: To: Mallory Knodel Cc: Hrpc Content-Type: multipart/alternative; boundary="000000000000096b4a057ab595d6" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 15:19:55 -0000 --000000000000096b4a057ab595d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel wrote: > But just wondering, what is the original purpose of that statement? > Preventing unmanageable scope creep. When you add business and policy to the mix, it makes it a lot harder to get work done, because they are matters of opinion, not fact, and competing interests will not be able to reach consensus. I think this is actually a useful thing for HRPC participants to be bearing in mind: to the extent that what we come with actually has clear policy implications, it's going to be difficult to get consensus on it. Look at the discussion we had over TLS 1.3 back in Prague. There was a clear technical goal: make connections as secure as reasonably possible (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94sorry!). And there was a competing business goal:= allow me to debug my network without retooling completely. The business goal lost not because it wasn't a real problem, but because it was a business problem, not a technical problem. Of course for the person dealing with the problem, it *feels* like a technical problem, but ultimately it's a problem because of the practices of the business being affected by the added security of TLS 1.3, *not* because there's actually a technical problem with TLS 1.3. So when we think about how the wording of this text implicates the work being done in HRPC, it would be good to be very careful not to jump to conclusions about what the wording implies. In this case, it's pretty clear (to me, of course!) that letting the right technical solution win was better for human rights. I think it's possible that this generalizes to some extent=E2=80=94my complaining about SMTP in the meeting is because alt= hough SMTP was a good enough technical solution, there were some very serious technical problems with it that weren't considered, and these problems came back to haunt us in a big way. You could say the same thing about BGP. And having had a week and a half to digest the BGP talk, the conclusion I've come to is that there's a clear net win for RPKI here. Yes, RPKI makes it possible for governments to openly blockade peers they don't like. But when they do so, it will be public, and not something that happened quietly in a room somewhere as a result of a failed trust relationship that couldn't be enforced. RPKI creates *problems* for human rights, but they are problems that we can figure out how to deal with. Not using RPKI creates problems we *can't* deal with. --000000000000096b4a057ab595d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 15= , 2018 at 2:50 AM Mallory Knodel <mallory@article19.org> wrote:
But just wondering, what is the original purpose of that statement?

Preventing unmanageable scope creep.=C2= =A0 =C2=A0When you add business and policy to the mix, it makes it a lot ha= rder to get work done, because they are matters of opinion, not fact, and c= ompeting interests will not be able to reach consensus.

I think this is actually a useful thing for HRPC participants to be b= earing in mind:=C2=A0 to the extent that what we come with actually has cle= ar policy implications, it's going to be difficult to get consensus on = it.

Look at the discussion we had over TLS 1.3 bac= k in Prague.=C2=A0 =C2=A0There was a clear technical goal: make connections= as secure as reasonably possible (I'm sure the TLS folks will heckle m= e for grossly oversimplifying=E2=80=94sorry!).=C2=A0 =C2=A0And there was a = competing business goal: allow me to debug my network without retooling com= pletely.=C2=A0 =C2=A0The business goal lost not because it wasn't a rea= l problem, but because it was a business problem, not a technical problem.= =C2=A0 =C2=A0Of course for the person dealing with the problem, it feels= =C2=A0like a technical problem, but ultimately it's a problem becau= se of the practices of the business being affected by the added security of= TLS 1.3, not=C2=A0because there's actually a technical problem = with TLS 1.3.

So when we think about how the wordi= ng of this text implicates the work being done in HRPC, it would be good to= be very careful not to jump to conclusions about what the wording implies.= =C2=A0 =C2=A0In this case, it's pretty clear (to me, of course!) that l= etting the right technical solution win was better for human rights.=C2=A0 = =C2=A0I think it's possible that this generalizes to some extent=E2=80= =94my complaining about SMTP in the meeting is because although SMTP was a = good enough technical solution, there were some very serious technical prob= lems with it that weren't considered, and these problems came back to h= aunt us in a big way.=C2=A0 =C2=A0You could say the same thing about BGP.

And having had a week and a half to digest the BGP = talk, the conclusion I've come to is that there's a clear net win f= or RPKI here.=C2=A0 =C2=A0Yes, RPKI makes it possible for governments to op= enly blockade peers they don't like.=C2=A0 =C2=A0But when they do so, i= t will be public, and not something that happened quietly in a room somewhe= re as a result of a failed trust relationship that couldn't be enforced= .=C2=A0 =C2=A0RPKI creates problems=C2=A0for human rights, but they = are problems that we can figure out how to deal with.=C2=A0 =C2=A0Not using= RPKI creates problems we can't=C2=A0deal with.

--000000000000096b4a057ab595d6-- From nobody Thu Nov 15 12:25:57 2018 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 5E671130DCC for ; Thu, 15 Nov 2018 12:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGJYY6cauJKL for ; Thu, 15 Nov 2018 12:25:54 -0800 (PST) Received: from sonic306-9.consmr.mail.bf2.yahoo.com (sonic306-9.consmr.mail.bf2.yahoo.com [74.6.132.48]) (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 A81D312F1AC for ; Thu, 15 Nov 2018 12:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542313552; bh=ixhjBXDoNS5j+64z6oOlgXOBAlUmfjoJHO9ODj8f/Oo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=mAmxfRpdJ2isMS0pdvfh/aqhbc2ic8wG7ry1nPsJJt48mfxo0eAR975GFWoPAgm0d5KTS1n+eQmwy45EE0vuqDtHxTZ+BEYOPepLPd6wrlE23u1CLAZ2LLCLmEnzQdYwH5hMNQCuD2XHJg+SkVffHqCIQLvHw8dqCfg7jJNCPYbsLlzGTGM2NpfiM7dIRIcH6JIHiI4rDDlVNNVBEVbg2IL5fo2qMG17w/rdEiv0XPEnVQOutOEpTN8q8HrRyMt7PZ1kEw8EkpyDm3xO60CQ20wGRCoGD0ktUCbSxIGilpPAZcpiXxpwFvwamxPM8M4zmstihX0nfEZbMPN4j0jzIQ== X-YMail-OSG: 3xi5Ty0VM1lo52Eyn.vT1SzVw3QWP0xI9xeuio6e5lomMdFyKXaXNBfrJPXZKXu tGMkQS_oOe4QngiX3r3d9oUHxO6opA2yp1glERefCYY8jqZjFUEyC5zE79Zy12drXQYg17E4sPAT gsnTbVTX_KaYcj2.Fta0_0MiejNc4cbAMiCPngf2u8aSYjqHzLmv_73MieXZv8QkedTT33Nd7fC5 zzcRiy3zSdyXsd0lloEl6ilpboXaQT5QVRfuk5T5Dl8FsWpXOxOX6QSZEL_yph6zPmlZfuzTDgIg Orl4CnHLKo6zTcmPllpdAVXJrnNsSa6vOdqBh1Ic1JVQTl7l65oBvLBbvytRI7n0P6yCX6iSjwYd 3EDJK8h91WTmes6Ri49rnrGr5w2hL8NTx4Nq4rYJV1d9v9X8y4LSUmUzp._YB9x1IlkaY8UBIgWy 0iF6XibK_vSDczTIMFIr50eVL.HOJBcFw1wi8kPrv2MAYYVpBsiAVMRBuToQ.PpDooPH.DJPSxY1 zZ7pxD.kVrszq8VS.vEmaxqKhaXxUhBXeNLFApWgXMfKZTooxHNpMy2mKbFS4UInqxDMUTiup6by WP0vOwkJ0BTNaluqgwyw57LrYAWt0cHMI0fpAH4tUhUPamXLelKVqScnsBGzftH2v.1h_wl3CXsM TmNsGMLhL4Yh9hVlqgb399BEPJofviGWOS_oYifZwx1krv5F2sajM1KkPsEiAh0e9qMjkXpcUJj0 kOfPMrh27NQ5W_tSVS8Wp1KsHqCSDTDA3DixqVoKjGpTQFIyXpi4JyaY3345ibMwQaQMlz_Ud3qc QdOg8B2lTQZjinpe1ho18n2AGxScuHk21s3CHqpQYTKRLBiNhiOTwZTyyjgbS6U1rdpphgsY6hSK Zh5fgoscFinZaO.4NwmK.32feIxLteibDdjsX_0RandWN3HMpxBy1JYoQtBn5ISTjgtI6m2weXlY oIQTxWn0KwnPVMMe3JaCajNs2StLiRfDjxupaiGWt7HRLPp.inyp6XC9Drh3htfSaEGroSOba6xY 9SN0f2qwXTQoV2Q5Ld2pkr9RNNNxe3BeNX9V2z._m Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 15 Nov 2018 20:25:52 +0000 Date: Thu, 15 Nov 2018 20:25:43 +0000 (UTC) From: Bill Jouris Reply-To: Bill Jouris To: Ted Lemon , Mallory Knodel Cc: Hrpc Message-ID: <1044765548.1272128.1542313543430@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1272127_1532049058.1542313543427" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 20:25:56 -0000 ------=_Part_1272127_1532049058.1542313543427 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2= =80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allow m= e to debug my network without retooling completely.=C2=A0 =C2=A0The busines= s goal lost not because it wasn't a real problem, but because it was a busi= ness problem, not a technical problem.=C2=A0 =C2=A0Of course for the person= dealing with the problem, it feels=C2=A0like a technical problem, but ulti= mately it's a problem because of the practices of the business being affect= ed by the added security of TLS 1.3, not=C2=A0because there's actually a te= chnical problem with TLS 1.3 The purpose of the IETF is to address technical issues in order to make the= Internet work better for Internet users.=C2=A0 And businesses are Internet= users every bit as much as individuals are.=C2=A0=20 That doesn't mean that business's issues should override individual concern= s.=C2=A0 But neither does it justify ignoring them -- which seems to be wha= t you are advocating.=C2=A0 If a technical change creates a "business probl= em", that doesn't mean we can just sit back and say "Oh, it's not a technic= al problem so tough on them."=C2=A0 Unless we can say "Here is a solution u= sing available technology which would allow you to address your business pr= oblem," it seems like an abdication of responsibility to try to wash our ha= nds of the whole thing.=20 Bill Jouris From: Ted Lemon To: Mallory Knodel =20 Cc: Hrpc Sent: Thursday, November 15, 2018 7:20 AM Subject: Re: [hrpc] "We try to avoid" =20 On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel wrot= e: But just wondering, what is the original purpose of that statement? Preventing unmanageable scope creep.=C2=A0 =C2=A0When you add business and = policy to the mix, it makes it a lot harder to get work done, because they = are matters of opinion, not fact, and competing interests will not be able = to reach consensus. I think this is actually a useful thing for HRPC participants to be bearing= in mind:=C2=A0 to the extent that what we come with actually has clear pol= icy implications, it's going to be difficult to get consensus on it. Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2= =80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allow m= e to debug my network without retooling completely.=C2=A0 =C2=A0The busines= s goal lost not because it wasn't a real problem, but because it was a busi= ness problem, not a technical problem.=C2=A0 =C2=A0Of course for the person= dealing with the problem, it feels=C2=A0like a technical problem, but ulti= mately it's a problem because of the practices of the business being affect= ed by the added security of TLS 1.3, not=C2=A0because there's actually a te= chnical problem with TLS 1.3. So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies.=C2=A0 =C2=A0In this case, it's pretty = clear (to me, of course!) that letting the right technical solution win was= better for human rights.=C2=A0 =C2=A0I think it's possible that this gener= alizes to some extent=E2=80=94my complaining about SMTP in the meeting is b= ecause although SMTP was a good enough technical solution, there were some = very serious technical problems with it that weren't considered, and these = problems came back to haunt us in a big way.=C2=A0 =C2=A0You could say the = same thing about BGP. And having had a week and a half to digest the BGP talk, the conclusion I'v= e come to is that there's a clear net win for RPKI here.=C2=A0 =C2=A0Yes, R= PKI makes it possible for governments to openly blockade peers they don't l= ike.=C2=A0 =C2=A0But when they do so, it will be public, and not something = that happened quietly in a room somewhere as a result of a failed trust rel= ationship that couldn't be enforced..=C2=A0 =C2=A0RPKI creates problems=C2= =A0for human rights, but they are problems that we can figure out how to de= al with.=C2=A0 =C2=A0Not using RPKI creates problems we can't=C2=A0deal wit= h. _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1272127_1532049058.1542313543427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Look at the discussion we had over TLS 1.3 back in Prag= ue.   There was a clear technical goal: make connections as secure as reasonably possible (I'm sure the TLS folks will heckle me for grossly=20 oversimplifying=E2=80=94sorry!).   And there was a competing busi= ness goal:=20 allow me to debug my network without retooling completely.   The= =20 business goal lost not because it wasn't a real problem, but because it=20 was a business problem, not a technical problem.   Of course for = the=20 person dealing with the problem, it feels like a technical problem, but ultimately it's a problem because of the=20 practices of the business being affected by the added security of TLS=20 1.3, not because there's actually a technical problem with TLS 1.3
<= span id=3D"yui_3_16_0_ym19_1_1542313178946_3681">
The purpose of the IETF is to address technical= issues in order to make the Internet work better for In= ternet users.  And businesses are Internet users every bit as = much as individuals are. 

That doesn't = mean that business's issues should override individual concerns.  But = neither does it justify ignoring them -- which seems to be what you are adv= ocating.  If a technical change creates a "business problem", that doe= sn't mean we can just sit back and say "Oh, it's not a technical problem so= tough on them."  Unless we can say "Here is a solution using availabl= e technology which would allow you to address your business problem," it se= ems like an abdication of responsibility to try to wash our hands of the wh= ole thing.

=
Bill Jouris

From: Ted Lemon <mellon@fugue.com>
= To: Mallory Knodel <mallor= y@article19.org>
Cc: Hrpc <hrpc@irtf.org>
Sent= : Thursday, November 15, 2018 7:20 AM
Subject: Re: [hrpc] "We try to avoid"

=
O= n Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel <mallory@article19.org> wrote:
But just w= ondering, what is the original purpose of that statement?

Preventing unmanageable sc= ope creep.   When you add business and policy to the mix, it make= s it a lot harder to get work done, because they are matters of opinion, no= t fact, and competing interests will not be able to reach consensus.
<= div>
I think this is actually a useful thing f= or HRPC participants to be bearing in mind:  to the extent that what w= e come with actually has clear policy implications, it's going to be diffic= ult to get consensus on it.

Look at= the discussion we had over TLS 1.3 back in Prague.   There was a= clear technical goal: make connections as secure as reasonably possible (I= 'm sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94so= rry!).   And there was a competing business goal: allow me to deb= ug my network without retooling completely.   The business goal l= ost not because it wasn't a real problem, but because it was a business pro= blem, not a technical problem.   Of course for the person dealing= with the problem, it feels like a technical problem, but ultim= ately it's a problem because of the practices of the business being affecte= d by the added security of TLS 1.3, not because there's actuall= y a technical problem with TLS 1.3.

So when we think about how the wording of this text implicates the work be= ing done in HRPC, it would be good to be very careful not to jump to conclu= sions about what the wording implies.   In this case, it's pretty= clear (to me, of course!) that letting the right technical solution win wa= s better for human rights.   I think it's possible that this gene= ralizes to some extent=E2=80=94my complaining about SMTP in the meeting is = because although SMTP was a good enough technical solution, there were some= very serious technical problems with it that weren't considered, and these= problems came back to haunt us in a big way.   You could say the= same thing about BGP.

And having h= ad a week and a half to digest the BGP talk, the conclusion I've come to is= that there's a clear net win for RPKI here.   Yes, RPKI makes it= possible for governments to openly blockade peers they don't like.  &= nbsp;But when they do so, it will be public, and not something that happene= d quietly in a room somewhere as a result of a failed trust relationship th= at couldn't be enforced..   RPKI creates problems for= human rights, but they are problems that we can figure out how to deal wit= h.   Not using RPKI creates problems we can't deal wi= th.

____________________________________= ___________
hrpc mailing list
hr= pc@irtf.org
https://www.irtf.org/mailman= /listinfo/hrpc


------=_Part_1272127_1532049058.1542313543427-- From nobody Thu Nov 15 12:59:48 2018 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 A23A6130DEC for ; Thu, 15 Nov 2018 12:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cez1YEHlSise for ; Thu, 15 Nov 2018 12:59:44 -0800 (PST) Received: from sonic313-17.consmr.mail.ne1.yahoo.com (sonic313-17.consmr.mail.ne1.yahoo.com [66.163.185.40]) (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 07580130DE5 for ; Thu, 15 Nov 2018 12:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542315582; bh=1n+4xA0hmbm3X53qji2UIJHIriuO1S0jz/eLwENMwnc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=hYTf8E0o2m5wECc/RAYvBhL9ctr4OCCdM0W7JwniPQND1v7ESGO/hxTz6zvD2rrx3Hx0WBYPzbrw7fQjoMGziryj1q+Zp8T36xJMSzpe1R5wewY3DrTjfItQFjnSPmcyVt6wjUruLDMARaAZR6IYCXhnpOPJKxAnpmc8JM6deXVY7yXXc/ZCgAtDzj6oS6OcsotBfuqy1KhOmUl/D01Uq9Va02P6nJ4rF0ee+97LKy/mzPSLsBJgulMUGgTxUE8IJ93Kw/Ylgx/nYGdtriB6sWa4qGPoX6MQEo5W1GOGEXwD20UOp6igI8/0f8gr4XMioTF1txezpze2Y43oHKfGUA== X-YMail-OSG: HBEe8F0VM1naAZYvXHer3kHDY.8COpae7ku4.VaQK02czMud9IKJ7be6CdoCURy FkbL88_KIVS23lLG0rG1GgMAUK7CocaNHnsWXCXu0wZT5XmnBxhpECKgNpaKtuHA5Rm9ETttyWLJ DkwX1l9XAY4BWniued6cY7aQImYvd.wuYdt7x08ehrwraW2Ni1dTyXXOUTFx6Pmsp3QyLaR3tr8d .ELen3CY3FK7NDVwXPsksGqT9rYD3MtZAMywXkqwpEadSZaVg9N_JkaM.4ecHRze1mxUCgmejPfW VPdttx2E4lzGVpNYmRtiXkwDfmO5UHl.U7Gk73ez.2H0wcMxyfdturyZGkY4r.eKh895ZIgvm8nh rHeNM8DJEbKmD1kErgzs1NUe1hpK6VwZxL5yEx0v89k4pvfFhN93daN0t8vbo6HUCgAZ7o.w_kTM TTQPWxANYCOOTOEEedptx44I.enR1uT5laRrEDu84CUu1f0sgDwvWl.OK3HIlYAU.8itjwdBoqzD Uo_UOydn.aQf1m5oMPloUdDF9VK1n3GerFV3xmCup.RwatsYxiva2aqPvj2cxZojh1CHRk7NW8rc cKjPU_WdBSsYqDCiyHUtvfqGRxj1Qm9v9ew6wlA2VThg2iMG9VQAv.DxCEdLWdwS7RYEY0lW0N3f RjgzRnaEOtXa0.h40mPkRux.x.0T3aE0aiVTh6c47oggaFy_aZYjmmqnc8Tr4qBV7UfAoefmTrvW pQtjp4L_.VG705NTr04lRzS4KWx5V_RF4sT4kfPUzCJvn12EAK1Zus6ZRCKxDKuiDlKGiWROz.31 RY5PMDedev9ub.7rGGEgnTfJbRC4Et4s9RSmor7jGBRRHLJbL3FSADjNX.2I2jkwH.fVuy90CWel O8PDRQkeAsIm_aAL5HlZqk6.eoSo0vL7bO3O7VZLFRdADbewEA.Uo8_YnVIstwt6FHTKtTX5iFzN M8Ye5FbmmQF4zf5Nh4ASCwmcjcwL5VoERd8XKr8jQkwhx9JEz17Wux90CcrLeY198gsXmXgdQJMT vDnva6w2h24fj81VgCwhmrxijd93IftHOWZSergLOd9wAplCRIVc5ArjWwNgiOtUA.w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Thu, 15 Nov 2018 20:59:42 +0000 Date: Thu, 15 Nov 2018 20:59:03 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Ted Lemon , Mallory Knodel Cc: Hrpc Message-ID: <2132865692.1278206.1542315543815@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 20:59:47 -0000 Ted, >Look at the discussion we had over TLS 1.3 back in Prague. There was a c= lear technical goal: make connections as secure as reasonably >possible (I'= m sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94sor= ry!). And there was a competing business goal: allow me to >debug my netw= ork without retooling completely. The business goal lost not because it w= asn't a real problem, but because it was a business >problem, not a technic= al problem. Of course for the person dealing with the problem, it feels l= ike a technical problem, but ultimately >it's a problem because of the prac= tices of the business being affected by the added security of TLS 1.3, not = because there's actually a >technical problem with TLS 1.3. Business problems are realities. No one has unlimited funds. I know my da= ughter thinks that money grows on trees, but I would beg to differ. In another example, quite a few of our villages in India have only 2g. Thi= s is due to economic realities. We are trying to work with this in protoco= l design. It is a reality of life where resources are not infinite. I do not know if you have seen protocol changes / RFCs in certain working g= roups which are intended to advantage certain businesses or vendor products= . I know I certainly have. This is certainly business. Some companies also send 50 or 100 people to the IETF. This could be becau= se they are generous contributors to the common good. I suspect it is more= likely because they find there is an economic advantage to be gained by do= ing so. =20 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Ted Lemon To: Mallory Knodel =20 Cc: Hrpc Sent: Thursday, November 15, 2018 7:20 AM Subject: Re: [hrpc] "We try to avoid" On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel wrot= e: But just wondering, what is the original purpose of that statement? > Preventing unmanageable scope creep. When you add business and policy to = the mix, it makes it a lot harder to get work done, because they are matter= s of opinion, not fact, and competing interests will not be able to reach c= onsensus. I think this is actually a useful thing for HRPC participants to be bearing= in mind: to the extent that what we come with actually has clear policy i= mplications, it's going to be difficult to get consensus on it. Look at the discussion we had over TLS 1.3 back in Prague. There was a cl= ear technical goal: make connections as secure as reasonably possible (I'm = sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94sorry= !). And there was a competing business goal: allow me to debug my network= without retooling completely. The business goal lost not because it wasn= 't a real problem, but because it was a business problem, not a technical p= roblem. Of course for the person dealing with the problem, it feels like = a technical problem, but ultimately it's a problem because of the practices= of the business being affected by the added security of TLS 1.3, not becau= se there's actually a technical problem with TLS 1.3. So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies. In this case, it's pretty clear (to = me, of course!) that letting the right technical solution win was better fo= r human rights. I think it's possible that this generalizes to some exten= t=E2=80=94my complaining about SMTP in the meeting is because although SMTP= was a good enough technical solution, there were some very serious technic= al problems with it that weren't considered, and these problems came back t= o haunt us in a big way. You could say the same thing about BGP. And having had a week and a half to digest the BGP talk, the conclusion I'v= e come to is that there's a clear net win for RPKI here. Yes, RPKI makes = it possible for governments to openly blockade peers they don't like. But= when they do so, it will be public, and not something that happened quietl= y in a room somewhere as a result of a failed trust relationship that could= n't be enforced.. RPKI creates problems for human rights, but they are pr= oblems that we can figure out how to deal with. Not using RPKI creates pr= oblems we can't deal with. _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc From nobody Thu Nov 15 13:11:09 2018 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 852F7130DEF for ; Thu, 15 Nov 2018 13:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 8A2oQCSC4emu for ; Thu, 15 Nov 2018 13:11:05 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 CBBE5130DEC for ; Thu, 15 Nov 2018 13:11:04 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id m5so34135392qka.9 for ; Thu, 15 Nov 2018 13:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=01eLlc+evsnhBAmfqH+mPA+2lcfDZcySKIu67SAGty8=; b=FGwz1WoOp5ece/ce7WczS7vBlo294mD+wQ9NUF+TJSS22miqPQCE+R8Xd+X5c5DvRr HbyNCBW8AlQED4nj9BmIE0YMKgr0VqQYxbcDlKW+G5s37A0oM62L1T8vBvDmF2MepzW/ nsBUaYmtTPs0oYI3RkHSRJ+JiesKWHY4oW76TVumwapnb57ZaOvUvIeV4u+Ivpv2I/eU 9zIvkQmZ07yyZiLgU0pCBrAsnaVkxO42dgcmjruRY0AQvgr5iZCr7vW7YS5J98uSZf1h rvdJhua+BXjIbLXCu/XPBXHK7XbEQqUcQfKjspYD46gDigqHbmrmz9pG5MaP1Hjs+hxj mwJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=01eLlc+evsnhBAmfqH+mPA+2lcfDZcySKIu67SAGty8=; b=rC3MM1bBzwr829sIYRnBkSHGRUhwXqHdelxXF6PSgB1Jt78nSiOdr9pcabqbgugE/h P8G4+ygo2ixocwGAHPg1euCBVdUNbby9XG+w2e7FV5M57DWN54PsLRujNySXFKc4XnNT 3RMqHWjvRKQ+3P892x9FE2EIFER90sOdc6CzMZN24Wa4boSo4k1Ndq7yVYcFvu4SrkEt XIQm2NuDF9QC1wVIZjk8sLPqmHf09HqLmbJK+/C7oSP0594q8dXIf5jNphp2fUlJ3Uh9 DJcXvRGqYlOojYfTT9MHyW3pDTTg9prG9U5ijadhdFnPZxaVkrTuhYuJkSCVIL1o2fFX R7bA== X-Gm-Message-State: AGRZ1gIDAGMahJbEmpr1YhJcHrv8FiFkWhFK5aom6Sw5XvkJPb+uBz44 XAIO31o3f/GWMFZ/A31/SgQYlXpa9zCNjuFI06w1Lw== X-Google-Smtp-Source: AJdET5c8HKXGMIJkQ9gSyHTTF1euCDYTuXMvkKfPcv3Y0qrPB4Ew3pFeR/JO7JQLAynpYwGx6pNes/z7PjyOcliU840= X-Received: by 2002:a0c:8aa8:: with SMTP id 37mr7750806qvv.23.1542316263765; Thu, 15 Nov 2018 13:11:03 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> In-Reply-To: <1044765548.1272128.1542313543430@mail.yahoo.com> From: Ted Lemon Date: Thu, 15 Nov 2018 16:10:27 -0500 Message-ID: To: b_jouris@yahoo.com Cc: Mallory Knodel , Hrpc Content-Type: multipart/alternative; boundary="00000000000008941d057aba7d27" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 21:11:08 -0000 --00000000000008941d057aba7d27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I hear your point. However, if the IETF were to take that on as a policy, the result would be that we would fail as a standards body, because no one protocol can reasonably account for every possible use case. The problem we had in this case is that TLS is a screwdriver, and the proponents of the "break TLS" use case needed a hammer. The solution to that is for them to use a hammer, not for the IETF to make a hamdriver. The appropriate IETF response to the statement "TLS 1.3 doesn't work for my use case" is "hm, what is your use case, and how can we best address it." We did that. The problem is that the answer wasn't to the liking of the folks who wanted to instead break TLS. This is *precisely* why we say that the IETF's purpose is not to get involved in that calculus. It's simply out of our possible scope. Of course there's no point in us building something that nobody will use, but when we build something, we need to build it to fit a particular use case; if there are two incompatible use cases, that means that we need to build two things. On Thu, Nov 15, 2018 at 3:25 PM Bill Jouris wrote: > *Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > problem, not a technical problem. Of course for the person dealing with > the problem, it feels like a technical problem, but ultimately it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, not because there's actually a technical probl= em > with TLS 1.3* > > The purpose of the IETF is to address technical issues *in order to make > the Internet work better for Internet users*. And businesses are > Internet users every bit as much as individuals are. > > That doesn't mean that business's issues should override individual > concerns. But neither does it justify ignoring them -- which seems to be > what you are advocating. If a technical change creates a "business > problem", that doesn't mean we can just sit back and say "Oh, it's not a > technical problem so tough on them." Unless we can say "Here is a soluti= on > using available technology which would allow you to address your business > problem," it seems like an abdication of responsibility to try to wash ou= r > hands of the whole thing. > > Bill Jouris > > > ------------------------------ > *From:* Ted Lemon > *To:* Mallory Knodel > *Cc:* Hrpc > *Sent:* Thursday, November 15, 2018 7:20 AM > *Subject:* Re: [hrpc] "We try to avoid" > > On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel > wrote: > > But just wondering, what is the original purpose of that statement? > > > Preventing unmanageable scope creep. When you add business and policy t= o > the mix, it makes it a lot harder to get work done, because they are > matters of opinion, not fact, and competing interests will not be able to > reach consensus. > > I think this is actually a useful thing for HRPC participants to be > bearing in mind: to the extent that what we come with actually has clear > policy implications, it's going to be difficult to get consensus on it. > > Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > problem, not a technical problem. Of course for the person dealing with > the problem, it *feels* like a technical problem, but ultimately it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, *not* because there's actually a technical > problem with TLS 1.3. > > So when we think about how the wording of this text implicates the work > being done in HRPC, it would be good to be very careful not to jump to > conclusions about what the wording implies. In this case, it's pretty > clear (to me, of course!) that letting the right technical solution win w= as > better for human rights. I think it's possible that this generalizes to > some extent=E2=80=94my complaining about SMTP in the meeting is because a= lthough > SMTP was a good enough technical solution, there were some very serious > technical problems with it that weren't considered, and these problems ca= me > back to haunt us in a big way. You could say the same thing about BGP. > > And having had a week and a half to digest the BGP talk, the conclusion > I've come to is that there's a clear net win for RPKI here. Yes, RPKI > makes it possible for governments to openly blockade peers they don't > like. But when they do so, it will be public, and not something that > happened quietly in a room somewhere as a result of a failed trust > relationship that couldn't be enforced.. RPKI creates *problems* for > human rights, but they are problems that we can figure out how to deal > with. Not using RPKI creates problems we *can't* deal with. > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > > --00000000000008941d057aba7d27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I hear your point.=C2=A0 =C2=A0However, if the IETF w= ere to take that on as a policy, the result would be that we would fail as = a standards body, because no one protocol can reasonably account for every = possible use case.=C2=A0 =C2=A0The problem we had in this case is that TLS = is a screwdriver, and the proponents of the "break TLS" use case = needed a hammer.=C2=A0 =C2=A0The solution to that is for them to use a hamm= er, not for the IETF to make a hamdriver.

The appropriat= e IETF response to the statement "TLS 1.3 doesn't work for my use = case" is "hm, what is your use case, and how can we best address = it."=C2=A0 =C2=A0We did that.=C2=A0 =C2=A0The problem is that the answ= er wasn't to the liking of the folks who wanted to instead break TLS.
This is precisely=C2=A0why we say that the IETF= 9;s purpose is not to get involved in that calculus.=C2=A0 =C2=A0It's s= imply out of our possible scope.=C2=A0 =C2=A0Of course there's no point= in us building something that nobody will use, but when we build something= , we need to build it to fit a particular use case; if there are two incomp= atible use cases, that means that we need to build two things.
<= /div>
On Thu, Nov 15, 2018 a= t 3:25 PM Bill Jouris <b_jouris@ya= hoo.com> wrote:
Look at the discussion we h= ad over TLS 1.3 back in Prague.=C2=A0 =C2=A0There was a clear technical goal: make connections as secure as reasonably possible (I'm sure the TLS folks will heckle me for grossly=20 oversimplifying=E2=80=94sorry!).=C2=A0 =C2=A0And there was a competing busi= ness goal:=20 allow me to debug my network without retooling completely.=C2=A0 =C2=A0The= =20 business goal lost not because it wasn't a real problem, but because it= =20 was a business problem, not a technical problem.=C2=A0 =C2=A0Of course for = the=20 person dealing with the problem, it feels=C2=A0like a technical problem, but ultimately it's a problem because of the=20 practices of the business being affected by the added security of TLS=20 1.3, not=C2=A0because there's actually a technical problem with TLS 1.3=

The purpose of the IETF is to a= ddress technical issues in order to make the Internet work better for Internet users.=C2=A0 And businesses are Internet users every bit as much as individ= uals are.=C2=A0

That doesn'= ;t mean that business's issues should override individual concerns.=C2= =A0 But neither does it justify ignoring them -- which seems to be what you= are advocating.=C2=A0 If a technical change creates a "business probl= em", that doesn't mean we can just sit back and say "Oh, it&#= 39;s not a technical problem so tough on them."=C2=A0 Unless we can sa= y "Here is a solution using available technology which would allow you= to address your business problem," it seems like an abdication of res= ponsibility to try to wash our hands of the whole thing.
<= div dir=3D"ltr" id=3D"m_-6187066949587121888yui_3_16_0_ym19_1_1542313178946= _3910">
Bill Jouris


From: Ted Lemon <mellon@fugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.org>
Sent: Thursday, November 15, 2018 7:20 AM
Subject: Re: [hrpc] "We try to avoi= d"

On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel <mallory@article19.org> wrote:
But just wondering, wh= at is the original purpose of that statement?

Preventing unmanageable scope creep.= =C2=A0 =C2=A0When you add business and policy to the mix, it makes it a lot= harder to get work done, because they are matters of opinion, not fact, an= d competing interests will not be able to reach consensus.

I think this is actually a useful thing for HRPC pa= rticipants to be bearing in mind:=C2=A0 to the extent that what we come wit= h actually has clear policy implications, it's going to be difficult to= get consensus on it.

Look at the d= iscussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0There was a clear= technical goal: make connections as secure as reasonably possible (I'm= sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94sorr= y!).=C2=A0 =C2=A0And there was a competing business goal: allow me to debug= my network without retooling completely.=C2=A0 =C2=A0The business goal los= t not because it wasn't a real problem, but because it was a business p= roblem, not a technical problem.=C2=A0 =C2=A0Of course for the person deali= ng with the problem, it feels=C2=A0like a technical problem, but ult= imately it's a problem because of the practices of the business being a= ffected by the added security of TLS 1.3, not=C2=A0because there'= ;s actually a technical problem with TLS 1.3.

=
So when we think about how the wording of this text implicates t= he work being done in HRPC, it would be good to be very careful not to jump= to conclusions about what the wording implies.=C2=A0 =C2=A0In this case, i= t's pretty clear (to me, of course!) that letting the right technical s= olution win was better for human rights.=C2=A0 =C2=A0I think it's possi= ble that this generalizes to some extent=E2=80=94my complaining about SMTP = in the meeting is because although SMTP was a good enough technical solutio= n, there were some very serious technical problems with it that weren't= considered, and these problems came back to haunt us in a big way.=C2=A0 = =C2=A0You could say the same thing about BGP.

=
And having had a week and a half to digest the BGP talk, the con= clusion I've come to is that there's a clear net win for RPKI here.= =C2=A0 =C2=A0Yes, RPKI makes it possible for governments to openly blockade= peers they don't like.=C2=A0 =C2=A0But when they do so, it will be pub= lic, and not something that happened quietly in a room somewhere as a resul= t of a failed trust relationship that couldn't be enforced..=C2=A0 =C2= =A0RPKI creates problems=C2=A0for human rights, but they are problem= s that we can figure out how to deal with.=C2=A0 =C2=A0Not using RPKI creat= es problems we can't=C2=A0deal with.

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


--00000000000008941d057aba7d27-- From nobody Thu Nov 15 13:17:15 2018 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 ED526130DF7 for ; Thu, 15 Nov 2018 13:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 HQ3OzlPpojAi for ; Thu, 15 Nov 2018 13:17:11 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 E25F3130DEC for ; Thu, 15 Nov 2018 13:17:10 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id r71so34132718qkr.10 for ; Thu, 15 Nov 2018 13:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t0oPxpmLcox+xNZwrtA9pVQq4KcYkc1h6XeiOtz9mbA=; b=XUT+xYOtYOJB1+xqSL+NoKTyrSo/m51WYP8F3TTYhMgvN/ragFzwPfU2T2vQBPD1PH 6NJQ6KxoIcKc/o9IpatPVlb2YNYgmgqgpvvKH5wlOMz4nFDqL4q/Y95J1h6FaCPI2UiT YJD6XxsFLzLvorpczniOSoB2c1BoR785dItgNuXvjCYRWUU/jV9c4gij8ZE5uOT7Z5nw sta6dPhCHqdXKNXfRSX4irRFhIHPnL0jA7sZaIX3NTKRPIHOBj6nyoUN8Gbc740qCrR1 ntpg5ZIfwkuxS1aPBs7+wpwc9z36zPECVxPni4vFYNK98ZmdFhns8NVVCpFm+3yoDzDq e1Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t0oPxpmLcox+xNZwrtA9pVQq4KcYkc1h6XeiOtz9mbA=; b=Cp6Hu1w+KlANnEnfRoKs8KMlwULBJhkv8vVKwz/+2ooe77K+vohXkyqXRWdxckaLbD OWK0keNiA54rklx+nU5YWyeRkgcmdgKDYromnGZbwbQ9cGwJ4+5dVZ8rjfRzUGGSQCNK aoBUWpgfcJYKGYiSdrlQlLyH3M8gMfDEQyCv9A9eBuzww/C9pObZdvDhrSwomRFE9tGD HgWlMZUFaK87s/EOzYNsg5rX7rODUwu1Jsuh6rgduI9Y/vjMkscHOQ4iX01Rpuaqjykm eEknu8i5EYcPLIo4GWK3vCGpWsOwyGIAgznEt04PSCJ3bCtXLAIm9rAnlpyiHhVNFAfA 8+5w== X-Gm-Message-State: AGRZ1gKlb8Xy+FEIDSCrY+6Q48FHvlsklDtr50fX3/r7NkuEWJQI+EMG RQLBVQMF4ie3k7xRr/MOZUiTKftXm/lm/YxSBY47MTsuUio= X-Google-Smtp-Source: AJdET5fVl9JQAmNs8wjrA0soD05eD6iU9Dz2Zdj+IzLbZUEqZI5CCsNzktbyq7Q9ddZpKhDBLGnVnGpQtRMLe2A/UVE= X-Received: by 2002:a37:c12:: with SMTP id 18mr7488869qkm.317.1542316629886; Thu, 15 Nov 2018 13:17:09 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> In-Reply-To: <2132865692.1278206.1542315543815@mail.yahoo.com> From: Ted Lemon Date: Thu, 15 Nov 2018 16:16:33 -0500 Message-ID: To: Nalini Elkins Cc: Mallory Knodel , Hrpc Content-Type: multipart/alternative; boundary="000000000000db674f057aba9217" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 21:17:14 -0000 --000000000000db674f057aba9217 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm pretty sure that the motivation for keeping TLS secure is that it benefits end users by preventing criminals (and businesses) from eavesdropping on their connections. That was certainly my motivation for engaging in the discussion. It frustrates me that you feel comfortable impugning the motives of IETF participants who really tried very hard to engage on this issue and propose solutions that addressed the use cases that we were talking about. It was very frustrating to simply be told "no, you have to break your protocol for us because we won't use that other protocol that actually addresses our use case and wouldn't break TLS." We may be wandering a bit off-topic, but in a sense this is an important discussion because when we get into a calculus like this, human rights are very much at risk. On Thu, Nov 15, 2018 at 3:59 PM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > Ted, > > >Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably >possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to >debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > >problem, not a technical problem. Of course for the person dealing wit= h > the problem, it feels like a technical problem, but ultimately >it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, not because there's actually a >technical > problem with TLS 1.3. > > Business problems are realities. No one has unlimited funds. I know my > daughter thinks that money grows on trees, but I would beg to differ. > > In another example, quite a few of our villages in India have only 2g. > This is due to economic realities. We are trying to work with this in > protocol design. It is a reality of life where resources are not infinite= . > > I do not know if you have seen protocol changes / RFCs in certain working > groups which are intended to advantage certain businesses or vendor > products. I know I certainly have. This is certainly business. > > Some companies also send 50 or 100 people to the IETF. This could be > because they are generous contributors to the common good. I suspect it = is > more likely because they find there is an economic advantage to be gained > by doing so. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ________________________________ > From: Ted Lemon > To: Mallory Knodel > Cc: Hrpc > Sent: Thursday, November 15, 2018 7:20 AM > Subject: Re: [hrpc] "We try to avoid" > > > > On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel > wrote: > > But just wondering, what is the original purpose of that statement? > > > > Preventing unmanageable scope creep. When you add business and policy t= o > the mix, it makes it a lot harder to get work done, because they are > matters of opinion, not fact, and competing interests will not be able to > reach consensus. > > I think this is actually a useful thing for HRPC participants to be > bearing in mind: to the extent that what we come with actually has clear > policy implications, it's going to be difficult to get consensus on it. > > Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > problem, not a technical problem. Of course for the person dealing with > the problem, it feels like a technical problem, but ultimately it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, not because there's actually a technical probl= em > with TLS 1.3. > > So when we think about how the wording of this text implicates the work > being done in HRPC, it would be good to be very careful not to jump to > conclusions about what the wording implies. In this case, it's pretty > clear (to me, of course!) that letting the right technical solution win w= as > better for human rights. I think it's possible that this generalizes to > some extent=E2=80=94my complaining about SMTP in the meeting is because a= lthough > SMTP was a good enough technical solution, there were some very serious > technical problems with it that weren't considered, and these problems ca= me > back to haunt us in a big way. You could say the same thing about BGP. > > And having had a week and a half to digest the BGP talk, the conclusion > I've come to is that there's a clear net win for RPKI here. Yes, RPKI > makes it possible for governments to openly blockade peers they don't > like. But when they do so, it will be public, and not something that > happened quietly in a room somewhere as a result of a failed trust > relationship that couldn't be enforced.. RPKI creates problems for huma= n > rights, but they are problems that we can figure out how to deal with. > Not using RPKI creates problems we can't deal with. > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000db674f057aba9217 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm pretty sure that the motivation for keeping TLS se= cure is that it benefits end users by preventing criminals (and businesses)= from eavesdropping on their connections.=C2=A0 =C2=A0That was certainly my= motivation for engaging in the discussion.=C2=A0 =C2=A0It frustrates me th= at you feel comfortable impugning the motives of IETF participants who real= ly tried very hard to engage on this issue and propose solutions that addre= ssed the use cases that we were talking about.=C2=A0 =C2=A0It was very frus= trating to simply be told "no, you have to break your protocol for us = because we won't use that other protocol that actually addresses our us= e case and wouldn't break TLS."

We may be wande= ring a bit off-topic, but in a sense this is an important discussion becaus= e when we get into a calculus like this, human rights are very much at risk= .

On Thu, Nov 15= , 2018 at 3:59 PM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
Ted,

>Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0= There was a clear technical goal: make connections as secure as reasonably = >possible (I'm sure the TLS folks will heckle me for grossly oversim= plifying=E2=80=94sorry!).=C2=A0 =C2=A0And there was a competing business go= al: allow me to >debug my network without retooling completely.=C2=A0 = =C2=A0The business goal lost not because it wasn't a real problem, but = because it was a business >problem, not a technical problem.=C2=A0 =C2= =A0Of course for the person dealing with the problem, it feels like a techn= ical problem, but ultimately >it's a problem because of the practice= s of the business being affected by the added security of TLS 1.3, not beca= use there's actually a >technical problem with TLS 1.3.

Business problems are realities.=C2=A0 No one has unlimited funds.=C2=A0 I = know my daughter thinks that money grows on trees, but I would beg to diffe= r.

In another example, quite a few of our villages in India have only 2g.=C2= =A0 This is due to economic realities.=C2=A0 We are trying to work with thi= s in protocol design. It is a reality of life where resources are not infin= ite.

I do not know if you have seen protocol changes / RFCs in certain working g= roups which are intended to advantage certain businesses or vendor products= .=C2=A0 I know I certainly have.=C2=A0 This is certainly business.

Some companies also send 50 or 100 people to the IETF.=C2=A0 This could be = because they are generous contributors to the common good.=C2=A0 I suspect = it is more likely because they find there is an economic advantage to be ga= ined by doing so.

Thanks,

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



________________________________
From: Ted Lemon <m= ellon@fugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.o= rg>
Sent: Thursday, November 15, 2018 7:20 AM
Subject: Re: [hrpc] "We try to avoid"



On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel <mallory@article19.org> wrote:

But just wondering, what is the original purpose of that statement?
>

Preventing unmanageable scope creep.=C2=A0 =C2=A0When you add business and = policy to the mix, it makes it a lot harder to get work done, because they = are matters of opinion, not fact, and competing interests will not be able = to reach consensus.

I think this is actually a useful thing for HRPC participants to be bearing= in mind:=C2=A0 to the extent that what we come with actually has clear pol= icy implications, it's going to be difficult to get consensus on it.
Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying= =E2=80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allo= w me to debug my network without retooling completely.=C2=A0 =C2=A0The busi= ness goal lost not because it wasn't a real problem, but because it was= a business problem, not a technical problem.=C2=A0 =C2=A0Of course for the= person dealing with the problem, it feels like a technical problem, but ul= timately it's a problem because of the practices of the business being = affected by the added security of TLS 1.3, not because there's actually= a technical problem with TLS 1.3.

So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies.=C2=A0 =C2=A0In this case, it's pre= tty clear (to me, of course!) that letting the right technical solution win= was better for human rights.=C2=A0 =C2=A0I think it's possible that th= is generalizes to some extent=E2=80=94my complaining about SMTP in the meet= ing is because although SMTP was a good enough technical solution, there we= re some very serious technical problems with it that weren't considered= , and these problems came back to haunt us in a big way.=C2=A0 =C2=A0You co= uld say the same thing about BGP.

And having had a week and a half to digest the BGP talk, the conclusion I&#= 39;ve come to is that there's a clear net win for RPKI here.=C2=A0 =C2= =A0Yes, RPKI makes it possible for governments to openly blockade peers the= y don't like.=C2=A0 =C2=A0But when they do so, it will be public, and n= ot something that happened quietly in a room somewhere as a result of a fai= led trust relationship that couldn't be enforced..=C2=A0 =C2=A0RPKI cre= ates problems for human rights, but they are problems that we can figure ou= t how to deal with.=C2=A0 =C2=A0Not using RPKI creates problems we can'= t deal with.

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000db674f057aba9217-- From nobody Thu Nov 15 13:32:09 2018 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 73C2C130DF7 for ; Thu, 15 Nov 2018 13:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3VRaYkgf_2U for ; Thu, 15 Nov 2018 13:32:05 -0800 (PST) Received: from sonic312-27.consmr.mail.bf2.yahoo.com (sonic312-27.consmr.mail.bf2.yahoo.com [74.6.128.89]) (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 178EA130DEC for ; Thu, 15 Nov 2018 13:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542317524; bh=VEtueylJVpRDVbf6yfptOR2zn4dzM8j43awM2HCU38w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=S3X3bZRYPE7cWy4iVvxqnw1Jw7IzSgvuzq4qONTISKzF0C2mdLE8AhkXLRRGOXd2roctCTPsBiOTIX9lFrwqXEuVtM7JH6/IK8GKCSZpmCFHGap5Slp0yScrOzAind5YIWo4Ftgdn2opsuZoyS64mOxT3sH1H8Ls99lYynCTbVxPAEZ2/uZzgJnki87SDtdpj0bFuj7Nx+Fx/d8IAgkj2Ml1roAfPC0tzbD03GAlUxC4cTYjSPr2luToyItxzL7eygLfOwlau+YfxsYo4dpbwH55sLuVDuUvfL1raJr6du4pCiDiREE1/Uy1k0FeSG+c5r5BtxnunjShPw68s2j28Q== X-YMail-OSG: QdyY8xQVM1nQkG8TVQ0U7wS2LlgSPUls4i.niY0vXjScd_a4X3gAi9UWMw.T563 PaxF_aiVT.t0mAXj2IbZ77Qr9_O7Y9joWkir5I5QTG6ayJsUSq.E6OU9WK3W1Rsu0chvQQWCKe3q UXwGKXXiqRZ_WK0pHTDlAF9FTdds8B3mmGc5uiSF19QpUbTGQQTMNO0vvDCN2iWYodKMQ_wH2ZlC cJN9pBMgMcwTO2k91Ig6qVTe53Jq8xJ7wUBFMuUi4mb2xkLCKCBNPw25x2KH3iaTHMOS5MFpEorv dKGazcNnkNScBpvnKrnNgOAhE67tfXz9XM0U3up2lNmUuDjk7uXIpAOKmNTvDQNRLBRkTrrVZU0. L_l0xx4azZ0FA2cjRldNauEO.HERJR9u57B6YH5R_OzwwLHhZvr6fBCsbnX6LOH4Tj51SzfYsAcT yO2U2G_lnETFMQTO1t7vcZb6EMcmgg6aa0YruQNHy3mPDbsr259uTc1heG6ij4G0Q8S30VVGob3. d39Oz4j4Ajen6Tiqs4CXVEHj9dtGZVzbVELX9PzcWLaBp87Z8CcNeMjBfUQ0CU6nPg3CGgjg0FrW veHGK.LneXQx9AOuosTEsFTlBCcf84eudW29Tfzjlj.V2GLl7PKKUGX6wi.0Suy53pFXmR6vsGo. XDwFTSomN0xpMrxigoAtyTpAyKTeucapTwGvJ9nBpmhILn7cuDlsUlkxNiOmGSGpWZHQLr.MObce J0I4oRo0qFLqNbbKM0kWL7vxi5aXatLm4PxrN4ETKQUpP9X7n5KNltKtaRVWFE0LSwIs34F88o6l yEkWv5_ZdnXiA7PdHGKB3La9MczD2PYybVideGnN3hJX7AoYVwhToi8KKzsirSRrHf5_n5wz9xZR TAxq4f0UxC3qK6oiEa_jj4U4t8889Mow.cFYXsKBLwOGNPhhSfILHdIfMdTOaDfAKd.fMqQv0SLg 4jFc90ePPaRVjsA0jt2wodqxh3510dAhjRfsaV6Z2EPfMQSpm99_ATw_WOk1IgF6amv94IxvtsJK 8c.HASl1NKkOGsGpicZhwt.yjaNu6R_DL Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 15 Nov 2018 21:32:04 +0000 Date: Thu, 15 Nov 2018 21:32:00 +0000 (UTC) From: Bill Jouris Reply-To: Bill Jouris To: Ted Lemon Cc: Mallory Knodel , Hrpc Message-ID: <733058385.1330061.1542317520560@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1330060_250291226.1542317520556" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 21:32:07 -0000 ------=_Part_1330060_250291226.1542317520556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems to me, however, that there is a fair amount of space between accou= nting for every possible business case that might arise (which we clearly c= an't) and totally ignoring the business impact of anything we do (which see= ms to have been the case heretofore).=C2=A0=20 Simply saying "slippery slope" ignores the possibility of actually consider= ing the impacts in specific cases and making judgement calls.=C2=A0 Certain= ly life is easier if we have a clear and simple rule about just where on th= e spectrum we will draw the line.=C2=A0 But developing that, to the extent = it can be done, will require amassing a lot more experience than we have ye= t acquired on specific cases.=C2=A0 It seems past time that we at least sta= rt paying attention to something besides the narrowest technical issues.=20 Bill Jouris From: Ted Lemon To: b_jouris@yahoo.com=20 Cc: Mallory Knodel ; Hrpc Sent: Thursday, November 15, 2018 1:11 PM Subject: Re: [hrpc] "We try to avoid" =20 Yes, I hear your point.=C2=A0 =C2=A0However, if the IETF were to take that = on as a policy, the result would be that we would fail as a standards body,= because no one protocol can reasonably account for every possible use case= .=C2=A0 =C2=A0The problem we had in this case is that TLS is a screwdriver,= and the proponents of the "break TLS" use case needed a hammer.=C2=A0 =C2= =A0The solution to that is for them to use a hammer, not for the IETF to ma= ke a hamdriver. The appropriate IETF response to the statement "TLS 1.3 doesn't work for my= use case" is "hm, what is your use case, and how can we best address it."= =C2=A0 =C2=A0We did that.=C2=A0 =C2=A0The problem is that the answer wasn't= to the liking of the folks who wanted to instead break TLS. This is precisely=C2=A0why we say that the IETF's purpose is not to get inv= olved in that calculus.=C2=A0 =C2=A0It's simply out of our possible scope.= =C2=A0 =C2=A0Of course there's no point in us building something that nobod= y will use, but when we build something, we need to build it to fit a parti= cular use case; if there are two incompatible use cases, that means that we= need to build two things. On Thu, Nov 15, 2018 at 3:25 PM Bill Jouris wrote: Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2= =80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allow m= e to debug my network without retooling completely.=C2=A0 =C2=A0The busines= s goal lost not because it wasn't a real problem, but because it was a busi= ness problem, not a technical problem.=C2=A0 =C2=A0Of course for the person= dealing with the problem, it feels=C2=A0like a technical problem, but ulti= mately it's a problem because of the practices of the business being affect= ed by the added security of TLS 1.3, not=C2=A0because there's actually a te= chnical problem with TLS 1.3 The purpose of the IETF is to address technical issues in order to make the= Internet work better for Internet users.=C2=A0 And businesses are Internet= users every bit as much as individuals are.=C2=A0=20 That doesn't mean that business's issues should override individual concern= s.=C2=A0 But neither does it justify ignoring them -- which seems to be wha= t you are advocating.=C2=A0 If a technical change creates a "business probl= em", that doesn't mean we can just sit back and say "Oh, it's not a technic= al problem so tough on them."=C2=A0 Unless we can say "Here is a solution u= sing available technology which would allow you to address your business pr= oblem," it seems like an abdication of responsibility to try to wash our ha= nds of the whole thing.=20 Bill Jouris From: Ted Lemon To: Mallory Knodel =20 Cc: Hrpc Sent: Thursday, November 15, 2018 7:20 AM Subject: Re: [hrpc] "We try to avoid" =20 On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel wrot= e: But just wondering, what is the original purpose of that statement? Preventing unmanageable scope creep.=C2=A0 =C2=A0When you add business and = policy to the mix, it makes it a lot harder to get work done, because they = are matters of opinion, not fact, and competing interests will not be able = to reach consensus. I think this is actually a useful thing for HRPC participants to be bearing= in mind:=C2=A0 to the extent that what we come with actually has clear pol= icy implications, it's going to be difficult to get consensus on it. Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2= =80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allow m= e to debug my network without retooling completely.=C2=A0 =C2=A0The busines= s goal lost not because it wasn't a real problem, but because it was a busi= ness problem, not a technical problem.=C2=A0 =C2=A0Of course for the person= dealing with the problem, it feels=C2=A0like a technical problem, but ulti= mately it's a problem because of the practices of the business being affect= ed by the added security of TLS 1.3, not=C2=A0because there's actually a te= chnical problem with TLS 1.3. So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies.=C2=A0 =C2=A0In this case, it's pretty = clear (to me, of course!) that letting the right technical solution win was= better for human rights.=C2=A0 =C2=A0I think it's possible that this gener= alizes to some extent=E2=80=94my complaining about SMTP in the meeting is b= ecause although SMTP was a good enough technical solution, there were some = very serious technical problems with it that weren't considered, and these = problems came back to haunt us in a big way.=C2=A0 =C2=A0You could say the = same thing about BGP. And having had a week and a half to digest the BGP talk, the conclusion I'v= e come to is that there's a clear net win for RPKI here.=C2=A0 =C2=A0Yes, R= PKI makes it possible for governments to openly blockade peers they don't l= ike.=C2=A0 =C2=A0But when they do so, it will be public, and not something = that happened quietly in a room somewhere as a result of a failed trust rel= ationship that couldn't be enforced..=C2=A0 =C2=A0RPKI creates problems=C2= =A0for human rights, but they are problems that we can figure out how to de= al with.=C2=A0 =C2=A0Not using RPKI creates problems we can't=C2=A0deal wit= h. _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1330060_250291226.1542317520556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems to me, however, that there is = a fair amount of space between accounting for every possible business case = that might arise (which we clearly can't) and totally ignoring the business= impact of anything we do (which seems to have been the case heretofore).&n= bsp;

Simply saying "slippery slope" ignores the possibility of actua= lly considering the impacts in specific cases and making judgement calls.&n= bsp; Certainly life is easier if we have a clear and simple rule about just= where on the spectrum we will draw the line.  But developing that, to= the extent it can be done, will require amassing a lot more experience tha= n we have yet acquired on specific cases.  It seems past time that we = at least start paying attention to something besides the narrowest technica= l issues.
Bill Jouris<= br>
From: Ted Lemon <mellon@fugue.com>
To: b_jouris@yahoo.com
Cc: Mallory Knodel <mallory@article19.org>; Hr= pc <hrpc@irtf.org>
Sent: Thursday, November 15, 2018 1:11 PM
Subject: Re: [hrpc] "We try to avoid"

Yes, I hear your point.   However, if the IETF were = to take that on as a policy, the result would be that we would fail as a st= andards body, because no one protocol can reasonably account for every poss= ible use case.   The problem we had in this case is that TLS is a= screwdriver, and the proponents of the "break TLS" use case needed a hamme= r.   The solution to that is for them to use a hammer, not for th= e IETF to make a hamdriver.

The appropria= te IETF response to the statement "TLS 1.3 doesn't work for my use case" is= "hm, what is your use case, and how can we best address it."   W= e did that.   The problem is that the answer wasn't to the liking= of the folks who wanted to instead break TLS.

This is precisely why we say that the IETF's purpose is n= ot to get involved in that calculus.   It's simply out of our pos= sible scope.   Of course there's no point in us building somethin= g that nobody will use, but when we build something, we need to build it to= fit a particular use case; if there are two incompatible use cases, that m= eans that we need to build two things.

=
On Thu, Nov 15, 2018 a= t 3:25 PM Bill Jouris <b_jouris@yahoo.com> wrote:
Look at the disc= ussion we had over TLS 1.3 back in Prague.   There was a clear technical goal: make connections as secure as reasonably possible (I'm sure the TLS folks will heckle me for grossly=20 oversimplifying=E2=80=94sorry!).   And there was a competing busi= ness goal:=20 allow me to debug my network without retooling completely.   The= =20 business goal lost not because it wasn't a real problem, but because it=20 was a business problem, not a technical problem.   Of course for = the=20 person dealing with the problem, it feels like a technical problem, but ultimately it's a problem because of the=20 practices of the business being affected by the added security of TLS=20 1.3, not because there's actually a technical problem with TLS 1.3

The purpose of the IETF is to address techn= ical issues in order to make the Internet work better for Int= ernet users.  And businesses are Internet users every bit as m= uch as individuals are. 

That doesn't mean that business's issues should override individual c= oncerns.  But neither does it justify ignoring them -- which seems to = be what you are advocating.  If a technical change creates a "business= problem", that doesn't mean we can just sit back and say "Oh, it's not a t= echnical problem so tough on them."  Unless we can say "Here is a solu= tion using available technology which would allow you to address your busin= ess problem," it seems like an abdication of responsibility to try to wash = our hands of the whole thing.

Bill Jouris


From: Ted Lemon <mellon@fugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.org>
Sent: Thursday, November= 15, 2018 7:20 AM
S= ubject: Re: [hrpc] "We try to avoid"
=

On Thu, Nov 15, 2018 at 2:50 AM Mallory = Knodel <mallory= @article19.org> wrote:
But just wonderi= ng, what is the original purpose of that statement?

Preventing unmanageable scope cr= eep.   When you add business and policy to the mix, it makes it a= lot harder to get work done, because they are matters of opinion, not fact= , and competing interests will not be able to reach consensus.
I think this is actually a useful thing for HRP= C participants to be bearing in mind:  to the extent that what we come= with actually has clear policy implications, it's going to be difficult to= get consensus on it.

Look at the d= iscussion we had over TLS 1.3 back in Prague.   There was a clear= technical goal: make connections as secure as reasonably possible (I'm sur= e the TLS folks will heckle me for grossly oversimplifying=E2=80=94sorry!).=    And there was a competing business goal: allow me to debug my = network without retooling completely.   The business goal lost no= t because it wasn't a real problem, but because it was a business problem, = not a technical problem.   Of course for the person dealing with = the problem, it feels like a technical problem, but ultimately = it's a problem because of the practices of the business being affected by t= he added security of TLS 1.3, not because there's actually a te= chnical problem with TLS 1.3.

So wh= en we think about how the wording of this text implicates the work being do= ne in HRPC, it would be good to be very careful not to jump to conclusions = about what the wording implies.   In this case, it's pretty clear= (to me, of course!) that letting the right technical solution win was bett= er for human rights.   I think it's possible that this generalize= s to some extent=E2=80=94my complaining about SMTP in the meeting is becaus= e although SMTP was a good enough technical solution, there were some very = serious technical problems with it that weren't considered, and these probl= ems came back to haunt us in a big way.   You could say the same = thing about BGP.

And having had a w= eek and a half to digest the BGP talk, the conclusion I've come to is that = there's a clear net win for RPKI here.   Yes, RPKI makes it possi= ble for governments to openly blockade peers they don't like.   B= ut when they do so, it will be public, and not something that happened quie= tly in a room somewhere as a result of a failed trust relationship that cou= ldn't be enforced..   RPKI creates problems for human= rights, but they are problems that we can figure out how to deal with.&nbs= p;  Not using RPKI creates problems we can't deal with.

_______________________________________________
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


------=_Part_1330060_250291226.1542317520556-- From nobody Thu Nov 15 13:46:00 2018 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 8A868130DEC for ; Thu, 15 Nov 2018 13:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 q3O8NbaF2pOp for ; Thu, 15 Nov 2018 13:45:57 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 DB8761277C8 for ; Thu, 15 Nov 2018 13:45:56 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id v9-v6so10325339pff.2 for ; Thu, 15 Nov 2018 13:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=yz1pFtkuRrow5cwwfpjV3j07iVApMw0tDR95O/7awfM=; b=GfkC02T3tnLAwy+y0xL/hDUTaifQ5T+p5H9/Kqb9/Bt4rW0FpyzwXbTfRq3YwDFEF+ VPTuo7QsdbMxlENG9ea+YGKbtMqknHVesNZJhOtVE8T2SvIBVcPC5dd+Zy/+8cqkoHgJ Qgnv6fLXW3wIYz8mow45pJiaBQXQ8BrmlW641OT7VKHLFFrIDWfFdQy3Wlstixuj9YrU Rolk48SAvILybpSMNG/Zeebs7fOEICNVVJPC74XLfmbKB0damTBYl8AX942P3ykyjNlq AcFID/4GO1x2xhX9eHeuE/3uz2iu5IhCEc/24f3HuVeR9PcWcgJHbYl+ax6NXux4cPVx KPgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yz1pFtkuRrow5cwwfpjV3j07iVApMw0tDR95O/7awfM=; b=NNiEZuyVsrOI8ZkzHTo70t4wnjTmMPqyA4ue4n1d32zKrxQnWnPL6djpzDT7IHjRpB LgKyv2/niD9GMqg49E3WKJxTCeZRJGQQOQlIoU84Isl3a3OV5PfiwOY45b/B1flwUzSE EWm1EvWRDd43N3UKrpdkqC0xKCHBloHWKiDGFzF0Vf7IcJVH1BZayADRBM7vcb6tSGF4 43wAuKdxUGeP9C8t0h8oo0xFZjWOM/7OUPdtXM6penTEwtzwQSHBnReJwoy9SOBzEoIb gitiwgRJdHNmEKT6prMW3Eu4rbH8khcqJu7OeLDXjbr2JSPkoMz+Z8N/kcqVOElp6xi6 0sPw== X-Gm-Message-State: AGRZ1gL9om0jeQe//ybf8cjqXqXow60ozZQ7VxQtZexD+ynH4mC487f7 3Y5LZZSEfaIHjCDhAsg88ZJl76+0MQ== X-Google-Smtp-Source: AJdET5eHD1W1OuM/gfoctbY3O/fak4baruZYFBZDB2ahhqFc4vpulqeYVsb+XShkSR1BmGKHMi42MA== X-Received: by 2002:a63:ed15:: with SMTP id d21mr7353235pgi.305.1542318355950; Thu, 15 Nov 2018 13:45:55 -0800 (PST) Received: from [192.168.1.126] (216-67-35-146-radius.dynamic.acsalaska.net. [216.67.35.146]) by smtp.gmail.com with ESMTPSA id s62-v6sm33824560pfb.73.2018.11.15.13.45.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 13:45:55 -0800 (PST) To: hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> <733058385.1330061.1542317520560@mail.yahoo.com> From: Melinda Shore Message-ID: <15c2d5a9-be7f-b076-2d19-b0162bb16ab0@nomountain.net> Date: Thu, 15 Nov 2018 12:45:52 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <733058385.1330061.1542317520560@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 21:45:59 -0000 On 11/15/18 12:32 PM, Bill Jouris wrote: > It seems to me, however, that there is a fair amount of space between > accounting for every possible business case that might arise (which we > clearly can't) and totally ignoring the business impact of anything we > do (which seems to have been the case heretofore).  I think this is represents a misunderstanding of the text. The question is not about business cases, but how business *models* are instantiated in the network. For example, we tend to assume that we're not going to change protocol design for certain kinds of network device intermediation, etc. Sometimes we come out with competing protocols (middlebox communication, for example) under the assumption that it's best to let the market sort it out. So, I think you're misreading the intent. Melinda -- Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Thu Nov 15 13:47:35 2018 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 D694E12870E for ; Thu, 15 Nov 2018 13:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 UIQRL2DmziPg for ; Thu, 15 Nov 2018 13:47:31 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 0E1961277C8 for ; Thu, 15 Nov 2018 13:47:31 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id a132so34327750qkg.1 for ; Thu, 15 Nov 2018 13:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q7QdLT5BLlUJqnakF1hr9Iz1+0jUwbOOSmz4I2XDeOA=; b=y/1/MSlO1pB8Fob2P5Xj/Twni+Y0HS2fMxGkz299z02DxNE6E1VXRb6tx8dDdgdDap UUUFcdIvjuWG/MOJ1sZsVDp23RUPkBh12YKxpCL1d9rY88IVoCZBKEDZh7LO6TR3suKP rQgBlkAxFfEweRjlxcPxLGOjQwspXtBRuu/Qvgu/jvLu8RaUuAejqoCukoN3VCtA9ynb R8pkF1V/FnNuoF5YsnDLwEeQuh3AsW8QzDDC6TQ/r9wwqoQ2ceCkWfrSfDnK+Exrg/MY 7YO82xg7Djqv+LAmmsVlMUIu230kAChFQNuqu4y9gGnTCl0wUwoqrUvf7TBXSskRsjib mVwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q7QdLT5BLlUJqnakF1hr9Iz1+0jUwbOOSmz4I2XDeOA=; b=NJit3+R1wj3Wu+GaHaJM4He/wzu2qSpQebSrYO0hKcv6WEVrwBzeu6aQgVm8Dn7fn7 n6zGmx/MjMhumxK5Ywfc5XWUcThQ3C3VupfJOzA7+3DEUQodc2CHYtjc7/LtgBULwjp5 V+lSMBn1wwn0fIF8Onwq9U/qO+uR2MRiV/iQHCZ84SO56+oa2Rc/jMeAvjg85gr9hOtu y76dr9SOaM1M3M2tcga0C2pZ6uRb+UyC28pUjnGRXnR5/z6yM3fL0rWoG7OOqQLQBEow B2zyR+FlG/9EKHfsbto5VtjJ9/qkFh/nIMAuio/Qdzjf/FzZX5EhZTCe36mgjjxD19KA p80w== X-Gm-Message-State: AGRZ1gJscFqUejiECaQEvlPZ+ElGAYxh3heHm0q1iUsJX/yRe0NLz9qu Nqvj8PZlNh1Z0wX2ZP6uPx1kmVQ1V3xBqpnJCtJJoA== X-Google-Smtp-Source: AJdET5esQ0hX/zBFww9/nKgyotY3/4BvMIy/3c3BrYjZhei61oUQCuUlUNEre8z7JM5u1gBntpnrSNp8MAguSAViieY= X-Received: by 2002:ac8:18fa:: with SMTP id o55mr7930229qtk.256.1542318450008; Thu, 15 Nov 2018 13:47:30 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> <733058385.1330061.1542317520560@mail.yahoo.com> In-Reply-To: <733058385.1330061.1542317520560@mail.yahoo.com> From: Ted Lemon Date: Thu, 15 Nov 2018 16:46:54 -0500 Message-ID: To: b_jouris@yahoo.com Cc: Mallory Knodel , Hrpc Content-Type: multipart/alternative; boundary="00000000000057fe84057abaffc6" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 21:47:34 -0000 --00000000000057fe84057abaffc6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Again, I hear you, but you're missing the point. The IETF has addressed the particular use case that was being proposed for TLS 1.3. They just didn't do it with TLS 1.3. TLS 1.3 addresses a different use case. The reason we "avoid policy and business questions as much as possible" is precisely because if we don't, we wind up in discussions like the TLS 1.3 discussion and this discussion. And there is no way for these discussions to end, because we don't agree on our goals, and we are never going to. This is not because I'm a stubborn jerk, or because you're not listening. It's because we have different goals. On Thu, Nov 15, 2018 at 4:32 PM Bill Jouris wrote: > It seems to me, however, that there is a fair amount of space between > accounting for every possible business case that might arise (which we > clearly can't) and totally ignoring the business impact of anything we do > (which seems to have been the case heretofore). > > Simply saying "slippery slope" ignores the possibility of actually > considering the impacts in specific cases and making judgement calls. > Certainly life is easier if we have a clear and simple rule about just > where on the spectrum we will draw the line. But developing that, to the > extent it can be done, will require amassing a lot more experience than w= e > have yet acquired on specific cases. It seems past time that we at least > start paying attention to something besides the narrowest technical issue= s. > Bill Jouris > > ------------------------------ > *From:* Ted Lemon > *To:* b_jouris@yahoo.com > *Cc:* Mallory Knodel ; Hrpc > *Sent:* Thursday, November 15, 2018 1:11 PM > *Subject:* Re: [hrpc] "We try to avoid" > > Yes, I hear your point. However, if the IETF were to take that on as a > policy, the result would be that we would fail as a standards body, becau= se > no one protocol can reasonably account for every possible use case. The > problem we had in this case is that TLS is a screwdriver, and the > proponents of the "break TLS" use case needed a hammer. The solution to > that is for them to use a hammer, not for the IETF to make a hamdriver. > > The appropriate IETF response to the statement "TLS 1.3 doesn't work for > my use case" is "hm, what is your use case, and how can we best address > it." We did that. The problem is that the answer wasn't to the liking > of the folks who wanted to instead break TLS. > > This is *precisely* why we say that the IETF's purpose is not to get > involved in that calculus. It's simply out of our possible scope. Of > course there's no point in us building something that nobody will use, bu= t > when we build something, we need to build it to fit a particular use case= ; > if there are two incompatible use cases, that means that we need to build > two things. > > On Thu, Nov 15, 2018 at 3:25 PM Bill Jouris wrote: > > *Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > problem, not a technical problem. Of course for the person dealing with > the problem, it feels like a technical problem, but ultimately it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, not because there's actually a technical probl= em > with TLS 1.3* > > The purpose of the IETF is to address technical issues *in order to make > the Internet work better for Internet users*. And businesses are > Internet users every bit as much as individuals are. > > That doesn't mean that business's issues should override individual > concerns. But neither does it justify ignoring them -- which seems to be > what you are advocating. If a technical change creates a "business > problem", that doesn't mean we can just sit back and say "Oh, it's not a > technical problem so tough on them." Unless we can say "Here is a soluti= on > using available technology which would allow you to address your business > problem," it seems like an abdication of responsibility to try to wash ou= r > hands of the whole thing. > > Bill Jouris > > > ------------------------------ > *From:* Ted Lemon > *To:* Mallory Knodel > > *Cc:* Hrpc > *Sent:* Thursday, November 15, 2018 7:20 AM > *Subject:* Re: [hrpc] "We try to avoid" > > On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel > wrote: > > But just wondering, what is the original purpose of that statement? > > > Preventing unmanageable scope creep. When you add business and policy t= o > the mix, it makes it a lot harder to get work done, because they are > matters of opinion, not fact, and competing interests will not be able to > reach consensus. > > I think this is actually a useful thing for HRPC participants to be > bearing in mind: to the extent that what we come with actually has clear > policy implications, it's going to be difficult to get consensus on it. > > Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > problem, not a technical problem. Of course for the person dealing with > the problem, it *feels* like a technical problem, but ultimately it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, *not* because there's actually a technical > problem with TLS 1.3. > > So when we think about how the wording of this text implicates the work > being done in HRPC, it would be good to be very careful not to jump to > conclusions about what the wording implies. In this case, it's pretty > clear (to me, of course!) that letting the right technical solution win w= as > better for human rights. I think it's possible that this generalizes to > some extent=E2=80=94my complaining about SMTP in the meeting is because a= lthough > SMTP was a good enough technical solution, there were some very serious > technical problems with it that weren't considered, and these problems ca= me > back to haunt us in a big way. You could say the same thing about BGP. > > And having had a week and a half to digest the BGP talk, the conclusion > I've come to is that there's a clear net win for RPKI here. Yes, RPKI > makes it possible for governments to openly blockade peers they don't > like. But when they do so, it will be public, and not something that > happened quietly in a room somewhere as a result of a failed trust > relationship that couldn't be enforced.. RPKI creates *problems* for > human rights, but they are problems that we can figure out how to deal > with. Not using RPKI creates problems we *can't* deal with. > > _______________________________________________ > 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 > > > --00000000000057fe84057abaffc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Again, I hear you, but you're missing the point.=C2=A0= =C2=A0The IETF has addressed the particular use case that was being propos= ed for TLS 1.3.=C2=A0 =C2=A0They just didn't do it with TLS 1.3.=C2=A0 = =C2=A0TLS 1.3 addresses a different use case.=C2=A0 =C2=A0The reason we &qu= ot;avoid policy and business questions as much as possible" is precise= ly because if we don't, we wind up in discussions like the TLS 1.3 disc= ussion and this discussion.=C2=A0 =C2=A0And there is no way for these discu= ssions to end, because we don't agree on our goals, and we are never go= ing to.=C2=A0 =C2=A0This is not because I'm a stubborn jerk, or because= you're not listening.=C2=A0 =C2=A0It's because we have different g= oals.

On Thu, Nov 15, = 2018 at 4:32 PM Bill Jouris <b_jou= ris@yahoo.com> wrote:
<= div style=3D"color:#000;background-color:#fff;font-family:Helvetica Neue,He= lvetica,Arial,Lucida Grande,sans-serif;font-size:16px">
It seems to me, however, that= there is a fair amount of space between accounting for every possible busi= ness case that might arise (which we clearly can't) and totally ignorin= g the business impact of anything we do (which seems to have been the case = heretofore).=C2=A0

Simply saying "slippery slope"= ignores the possibility of actually considering the impacts in specific ca= ses and making judgement calls.=C2=A0 Certainly life is easier if we have a= clear and simple rule about just where on the spectrum we will draw the li= ne.=C2=A0 But developing that, to the extent it can be done, will require a= massing a lot more experience than we have yet acquired on specific cases.= =C2=A0 It seems past time that we at least start paying attention to someth= ing besides the narrowest technical issues.
Bill Jouris

From: Ted Lemon <mellon@fugue.com>
To: b_jouris@yahoo.com
Cc: Mallory Knodel <mallory@article19.org>; Hrpc <hrpc@irtf.org>
Sent: Thursday, November 15, 2018 1:11 PM
= Subject: Re: [hrpc] "We tr= y to avoid"

Yes, I hear your point.=C2=A0 =C2=A0However, if the IETF were to= take that on as a policy, the result would be that we would fail as a stan= dards body, because no one protocol can reasonably account for every possib= le use case.=C2=A0 =C2=A0The problem we had in this case is that TLS is a s= crewdriver, and the proponents of the "break TLS" use case needed= a hammer.=C2=A0 =C2=A0The solution to that is for them to use a hammer, no= t for the IETF to make a hamdriver.

The a= ppropriate IETF response to the statement "TLS 1.3 doesn't work fo= r my use case" is "hm, what is your use case, and how can we best= address it."=C2=A0 =C2=A0We did that.=C2=A0 =C2=A0The problem is that= the answer wasn't to the liking of the folks who wanted to instead bre= ak TLS.

This is precisely=C2=A0why= we say that the IETF's purpose is not to get involved in that calculus= .=C2=A0 =C2=A0It's simply out of our possible scope.=C2=A0 =C2=A0Of cou= rse there's no point in us building something that nobody will use, but= when we build something, we need to build it to fit a particular use case;= if there are two incompatible use cases, that means that we need to build = two things.

On Thu, Nov 15, 2018 at 3:25 PM Bill Jouris <= b_jouris@yahoo.com> wrote:
Look at the dis= cussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0There was a clear technical goal: make connections as secure as reasonably possible (I'm sure the TLS folks will heckle me for grossly=20 oversimplifying=E2=80=94sorry!).=C2=A0 =C2=A0And there was a competing busi= ness goal:=20 allow me to debug my network without retooling completely.=C2=A0 =C2=A0The= =20 business goal lost not because it wasn't a real problem, but because it= =20 was a business problem, not a technical problem.=C2=A0 =C2=A0Of course for = the=20 person dealing with the problem, it feels=C2=A0like a technical problem, but ultimately it's a problem because of the=20 practices of the business being affected by the added security of TLS=20 1.3, not=C2=A0because there's actually a technical problem with TLS 1.3=

The purpose of the IETF is to = address technical issues in order to make the Internet work better for Internet users.= =C2=A0 And businesses are Internet users every bit as much as individuals a= re.=C2=A0

That = doesn't mean that business's issues should override individual conc= erns.=C2=A0 But neither does it justify ignoring them -- which seems to be = what you are advocating.=C2=A0 If a technical change creates a "busine= ss problem", that doesn't mean we can just sit back and say "= Oh, it's not a technical problem so tough on them."=C2=A0 Unless w= e can say "Here is a solution using available technology which would a= llow you to address your business problem," it seems like an abdicatio= n of responsibility to try to wash our hands of the whole thing.

Bill Jouris


=
From:= Ted Lemon <mellon@fugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.org>
Sent: Thursda= y, November 15, 2018 7:20 AM
Subject: Re: [hrpc] "We try to avoid"

On Thu, Nov 15, 2018 at 2:50 AM = Mallory Knodel <mallory@article19.org> wrote:
But just wondering, what is t= he original purpose of that statement?
=
Preventing unmanageable scope creep.=C2=A0 = =C2=A0When you add business and policy to the mix, it makes it a lot harder= to get work done, because they are matters of opinion, not fact, and compe= ting interests will not be able to reach consensus.

I think this is actually a useful thing for HRPC participa= nts to be bearing in mind:=C2=A0 to the extent that what we come with actua= lly has clear policy implications, it's going to be difficult to get co= nsensus on it.

Look at the discussi= on we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0There was a clear techni= cal goal: make connections as secure as reasonably possible (I'm sure t= he TLS folks will heckle me for grossly oversimplifying=E2=80=94sorry!).=C2= =A0 =C2=A0And there was a competing business goal: allow me to debug my net= work without retooling completely.=C2=A0 =C2=A0The business goal lost not b= ecause it wasn't a real problem, but because it was a business problem,= not a technical problem.=C2=A0 =C2=A0Of course for the person dealing with= the problem, it feels=C2=A0like a technical problem, but ultimately= it's a problem because of the practices of the business being affected= by the added security of TLS 1.3, not=C2=A0because there's actu= ally a technical problem with TLS 1.3.

<= div>So when we think about how the wording of this text implicates the work= being done in HRPC, it would be good to be very careful not to jump to con= clusions about what the wording implies.=C2=A0 =C2=A0In this case, it's= pretty clear (to me, of course!) that letting the right technical solution= win was better for human rights.=C2=A0 =C2=A0I think it's possible tha= t this generalizes to some extent=E2=80=94my complaining about SMTP in the = meeting is because although SMTP was a good enough technical solution, ther= e were some very serious technical problems with it that weren't consid= ered, and these problems came back to haunt us in a big way.=C2=A0 =C2=A0Yo= u could say the same thing about BGP.

And having had a week and a half to digest the BGP talk, the conclusion = I've come to is that there's a clear net win for RPKI here.=C2=A0 = =C2=A0Yes, RPKI makes it possible for governments to openly blockade peers = they don't like.=C2=A0 =C2=A0But when they do so, it will be public, an= d not something that happened quietly in a room somewhere as a result of a = failed trust relationship that couldn't be enforced..=C2=A0 =C2=A0RPKI = creates problems=C2=A0for human rights, but they are problems that w= e can figure out how to deal with.=C2=A0 =C2=A0Not using RPKI creates probl= ems we can't=C2=A0deal with.

_= ______________________________________________
hrpc maili= ng list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


__= _____________________________________________
hrpc mailin= g list
hrpc@irtf.org
https://w= ww.irtf.org/mailman/listinfo/hrpc


--00000000000057fe84057abaffc6-- From nobody Thu Nov 15 13:59:12 2018 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 11E5D130ECD for ; Thu, 15 Nov 2018 13:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, 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 z1QLbF97onb6 for ; Thu, 15 Nov 2018 13:59:07 -0800 (PST) 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 8A47F130EC7 for ; Thu, 15 Nov 2018 13:59:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37052BE7B; Thu, 15 Nov 2018 21:59:05 +0000 (GMT) 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 YBekT4KAj6KG; Thu, 15 Nov 2018 21:59:04 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 849CBBE5F; Thu, 15 Nov 2018 21:59:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542319143; bh=eCQuco77f8sGt1NE7A9P2b8Kf5M3SGmr3W9PyVPGSso=; h=To:References:From:Subject:Date:In-Reply-To:From; b=hk7oWnL0o6Dta8OSV9tZjMg5y/IIDJLXnQlB9BZ0Y2QihJpDhjnK/TejHlxWpR1th TF16MQ3ESZqJ8cRxJQfPm2HZiJpdHV3IPRD88IqvI74yWBmJyMucGjhOG8YvKWDBfa PR8t2U+5KiHo9Zjf2+cyRMX1m30Ll4q5Zwxle078= To: Mallory Knodel , hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 15 Nov 2018 21:59:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tgvjCxJQ2ezddsl4q75vsuqE10Ty8DLq0" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 21:59:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tgvjCxJQ2ezddsl4q75vsuqE10Ty8DLq0 Content-Type: multipart/mixed; boundary="VIGRpAYARRAva5l3vE5CiEuD8frGyKTsD"; protected-headers="v1" From: Stephen Farrell To: Mallory Knodel , hrpc@irtf.org Message-ID: Subject: Re: [hrpc] "We try to avoid" References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> In-Reply-To: --VIGRpAYARRAva5l3vE5CiEuD8frGyKTsD Content-Type: multipart/mixed; boundary="------------0F007EE3B6B208919A49D1F0" Content-Language: en-GB This is a multi-part message in MIME format. --------------0F007EE3B6B208919A49D1F0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15/11/2018 07:50, Mallory Knodel wrote: > But just wondering, what is the original purpose of that statement? I suspect that's a question to which you could get 100 answers from 50 IETFers, all of which'd be a little bit correct:-) FWIW, my take is a little different to Ted's but not unrelated. I think the idea was that it's better (in general) to develop IETF technologies that interoperate and can be used with many policies and business/operations models and to not develop protocols that are specific to one or a few policies or business models. That doesn't mean we have to be pseudo-neutral and claim that all policies and business models are equally ok, but it does mean we don't need to reach consensus on our opinions of them. There are some policies though that are such that we did need to consider them, e.g. in the case of RFC1984, where the policy in question that we did need to consider was to the effect that nobody (else) was allowed to use strong crypto. I suspect there's also an element of it just being more interesting and tractable for IETFers to stick to the more fun technical stuff and to not have to deal with often painful discussions that can be involved when mucking about with (or stopping people mucking about with) protocols for purely policy or business reasons. It's basically far easier (in the IETF) to debate the size of packets and similar than it is to discuss why someone would want to do something like break TLS or make money from ad auctions that expose huge amounts of user data to all bidders. S. --------------0F007EE3B6B208919A49D1F0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------0F007EE3B6B208919A49D1F0-- --VIGRpAYARRAva5l3vE5CiEuD8frGyKTsD-- --tgvjCxJQ2ezddsl4q75vsuqE10Ty8DLq0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvt7CUACgkQWrL68XsX K+opxA//Tpfs8d6NGMivwaxTdhfD9C5AZIGTUANpSRBfb/vB5gOyGUfV0AvbIMY2 q1AF3v2DUs2M//wZzHO/yQgJR+dEksR2rpFL22+9UMArQlc9eBq/13FKvtyXL60i t9+YKRFeIrq025EjuhVC9sYC6w8NHvoSKHHf5oi9+bgjBiMD1PNi9SBwG/hgjQUH N7uEABphDVbnBLvy2J2WTxeCCYYHmdQIdaMo62sG27sRwpl6+0by6+31qPg0O+5T 1VqamaR+LVgGty5i+OE6KTEaz1j0Jsamlpc5JVyStkz9fab4dZKXSfwRX4siSYqF zgTKBRPuf0+4wUDl/vmW65Cja554GpTUoeJ/IrB0qDlQYQRK3Oj9p9xguuezPI/0 RpaoyMvEy+1QxOkoC7x3hV1OQuK5BSo3lTbE49KeEK/bIr1TLyfPQ1T9zr73oDDW n8GpvganP+3h1zvbDZMBQaisjUPgO+pAjdYZ/mCLJ32y/o4j3jITIbnKBDjBQ+mb kDNMM+wZsIEdvuQNTWU+PeNQc3bl3gl2M/NlE961w6Qt/ezARj6O6VPMxzXReOWP 8lQFBg3dzCpuBob4vz2I0yjLjZ0VggHcb0BjZPVs2nZdZ3oGI5SFo/BDZoLBqHPm f+ZuR9AMzKLzDMR6Oq/zRrZaD1WKbwWwQGHN1ggemdd/a60/15o= =Cgsw -----END PGP SIGNATURE----- --tgvjCxJQ2ezddsl4q75vsuqE10Ty8DLq0-- From nobody Thu Nov 15 14:48:32 2018 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 DE771130E19 for ; Thu, 15 Nov 2018 14:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMETwa67ilkz for ; Thu, 15 Nov 2018 14:48:29 -0800 (PST) Received: from sonic302-4.consmr.mail.bf2.yahoo.com (sonic302-4.consmr.mail.bf2.yahoo.com [74.6.135.43]) (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 D112F12D4EA for ; Thu, 15 Nov 2018 14:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542322107; bh=OC416tSRBynH6pOXSBBqnotyqe1Sq7JDlgZQNoFdGLU=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Hbbe7csXDGZXCNyoHeFAUSG1FOOLEz5/SuXANMS4zKumKL3xnsPyM5laKjtG/48IukgVC9xlSILrrUdMb4zTcKjfpRjAacbUMPIgUKxEP/NrbRGiD4cReG5HGKpONWQT0jbIDzpDzANU97W4/sA4pZXnkrwY3SFTCqHd/bqNgRCHoGrcqOmrPqQvCgnI2EIfIKDqCOwMF1Ek3ilQB6bZQLS0WRIQjiogKIHcrgx0tRwq/T84IYI6sKC+B0fH2HlHmmOzN2xeQWhGXbehNxzfMDmqm+fOj4P8uQf+HEJDBWlJaos4ygDt+dVXYvXC08u/CioaHhCpxKGBquMM1jS3bA== X-YMail-OSG: u1sEphcVM1njYZQe3m_LEJz3YKIOvRMcIrcF5OnLxmXn59aQoKa5YGYvrLuvEcW RLIxtDT64P6lEIipS33IdItz0.d.Z5chZigNTUrcc9FQj7bYpwYLFS.Dt50zh8.JYrwGfjsTCBHx aPRU7oqUVvjgJf_d9T4ea9zbntIOsgFkIgBmC9S8Anbp1cZsMLmm9xEUI_F6jnyO7ccBJhLb34cq zqxk04Im24wp81AtWxsy.udcyQwxp1OImimgOJoTX.5_tYaD5sDKkyV0NaB1nGGw.Vs03oQiORBL 11s98__ZxgD35Qycy.tGnKFMfkqZ7Pk7cXV.uDSY7ZYbJ354jqfklNk9ismgDXn0sgrzFOSUiWFd 9xe.NrC..fSBUM5ohs.7hShI1l420Q5hb0aN0.gmMpIlfMMNG.YFRMwJ8fGIeP2FxeCfs.cvI_A_ zofyHmB4ekjmY78TiJ6ryAGlMhpy8A9mMBXjL3sUBVUT2c2UhiK44RTpXZ_ryWXAvul40bwHP53b RObYdHOcosGZrA5tJxulAxfybngbkDSqL926jFauEo0W_2n3uPtHVfeLi.MNQteYlyL7Jl8ZV_.. TToycL6kaNkwdGlGymLdjDVfJKtaX8oVg5Hwpstz0GG3UoFBLXQUbmV2aOPlTzjyNoScphs1D4mY jR3SEJ08gmDGigod8xeIA8rr1XbRzeSgURygcHJsgTZeOZ4hsZkpltKSjdtpunAOFbi.yIyj93C5 jtLoq64gKNcKMX.HCNlyVUi5JuyO2WofqsBDkXIX5Rm03_jZIeANDabNHywkUD1CPxOkLdHNciEL 8obs5TlTpVYVi2uuWlbDzK0UTDfW3DO9hkalHR2vUexg35ZBk3nQbzhcNuHyAeD2QxTjfRmQRTwO 8GtOqyY_.LtDOTAp_ZmqAoCmsvsz5HFSKvI7KRKcEjrLhO4HyVjyjRiZ4a56fapnvpRUrBgPXROT kLX31aMCUbF_GpSc3b5cBXvg8Y2cxafWWWzCTSvO6ItYY4vXLg1BdGiP4c25nE_47oB2IXMSSWWD mvREbIXloN7LP Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 15 Nov 2018 22:48:27 +0000 Date: Thu, 15 Nov 2018 22:48:25 +0000 (UTC) From: Mark Perkins To: Ted Lemon , Mallory Knodel , Nalini J Elkins Cc: Hrpc Message-ID: <612735664.1327555.1542322105746@mail.yahoo.com> In-Reply-To: <2132865692.1278206.1542315543815@mail.yahoo.com> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1327554_1413760106.1542322105744" X-Mailer: WebService/1.1.12729 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 22:48:32 -0000 ------=_Part_1327554_1413760106.1542322105744 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nalini I think you have 'hit the nail on the head'.. Yes, business problems are realities BUT business problems are not neutral = either.=20 As you state,=20 in some countries bandwidth is limited - Business Case A on the other hand, large corporations can send large delegations, or become= generous donors, to advance their profit making & competitive situation - = Business Case B I am sure we could come up with other business cases. Protocol design should be about 'end users', with 'business users' being se= en as intermediaries (important, but not ultimate). We should be VERY caref= ul in avoiding strengthening existing business players position against new= comers. Just because a new protocol creates a business problem FOR THEM is = no reason not to procede when the overall benefit to end users merits it. As always, the devil is in the details Mark P. On Friday, November 16, 2018, 7:59:55 AM GMT+11, Nalini J Elkins wrote: =20 =20 Ted, >Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 There was= a clear technical goal: make connections as secure as reasonably >possible= (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2=80= =94sorry!).=C2=A0 And there was a competing business goal: allow me to >deb= ug my network without retooling completely.=C2=A0 The business goal lost no= t because it wasn't a real problem, but because it was a business >problem,= not a technical problem.=C2=A0 Of course for the person dealing with the p= roblem, it feels like a technical problem, but ultimately >it's a problem b= ecause of the practices of the business being affected by the added securit= y of TLS 1.3, not because there's actually a >technical problem with TLS 1.= 3. Business problems are realities.=C2=A0 No one has unlimited funds.=C2=A0 I = know my daughter thinks that money grows on trees, but I would beg to diffe= r. In another example, quite a few of our villages in India have only 2g.=C2= =A0 This is due to economic realities.=C2=A0 We are trying to work with thi= s in protocol design. It is a reality of life where resources are not infin= ite. I do not know if you have seen protocol changes / RFCs in certain working g= roups which are intended to advantage certain businesses or vendor products= .=C2=A0 I know I certainly have.=C2=A0 This is certainly business. Some companies also send 50 or 100 people to the IETF.=C2=A0 This could be = because they are generous contributors to the common good.=C2=A0 I suspect = it is more likely because they find there is an economic advantage to be ga= ined by doing so. =20 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Ted Lemon To: Mallory Knodel =20 Cc: Hrpc Sent: Thursday, November 15, 2018 7:20 AM Subject: Re: [hrpc] "We try to avoid" On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel wrot= e: But just wondering, what is the original purpose of that statement? > Preventing unmanageable scope creep.=C2=A0 When you add business and policy= to the mix, it makes it a lot harder to get work done, because they are ma= tters of opinion, not fact, and competing interests will not be able to rea= ch consensus. I think this is actually a useful thing for HRPC participants to be bearing= in mind:=C2=A0 to the extent that what we come with actually has clear pol= icy implications, it's going to be difficult to get consensus on it. Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 There was = a clear technical goal: make connections as secure as reasonably possible (= I'm sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94s= orry!).=C2=A0 And there was a competing business goal: allow me to debug my= network without retooling completely.=C2=A0 The business goal lost not bec= ause it wasn't a real problem, but because it was a business problem, not a= technical problem.=C2=A0 Of course for the person dealing with the problem= , it feels like a technical problem, but ultimately it's a problem because = of the practices of the business being affected by the added security of TL= S 1.3, not because there's actually a technical problem with TLS 1.3. So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies.=C2=A0 In this case, it's pretty clear = (to me, of course!) that letting the right technical solution win was bette= r for human rights.=C2=A0 I think it's possible that this generalizes to so= me extent=E2=80=94my complaining about SMTP in the meeting is because altho= ugh SMTP was a good enough technical solution, there were some very serious= technical problems with it that weren't considered, and these problems cam= e back to haunt us in a big way.=C2=A0 You could say the same thing about B= GP. And having had a week and a half to digest the BGP talk, the conclusion I'v= e come to is that there's a clear net win for RPKI here.=C2=A0 Yes, RPKI ma= kes it possible for governments to openly blockade peers they don't like.= =C2=A0 But when they do so, it will be public, and not something that happe= ned quietly in a room somewhere as a result of a failed trust relationship = that couldn't be enforced..=C2=A0 RPKI creates problems for human rights, b= ut they are problems that we can figure out how to deal with.=C2=A0 Not usi= ng RPKI creates problems we can't deal with. _______________________________________________ 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 ------=_Part_1327554_1413760106.1542322105744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nalini

I think you have 'hit the nail= on the head'..

Yes, business problems are r= ealities BUT business problems are not neutral either.

As you state= ,

in some countries bandwidth is limited - Business Case A

o= n the other hand, large corporations can send large delegations, or become = generous donors, to advance their profit making & competitive situation= - Business Case B

I am sure we could come up with other business ca= ses.

Protocol design should be about 'end users', with 'business use= rs' being seen as intermediaries (important, but not ultimate). We should b= e VERY careful in avoiding strengthening existing business players position= against newcomers. Just because a new protocol creates a business problem = FOR THEM is no reason not to procede when the overall benefit to end users = merits it.

As always, the devil is in the details

Mark P.


=20
=20
On Friday, November 16, 2018, 7:59:55 AM GMT+11, Nalini= J Elkins <nalini.elkins@insidethestack.com> wrote:


Ted,

>Look at the discussion we had over TLS 1.3 back in Prague.  = There was a clear technical goal: make connections as secure as reasonably = >possible (I'm sure the TLS folks will heckle me for grossly oversimplif= ying=E2=80=94sorry!).  And there was a competing business goal: allow= me to >debug my network without retooling completely.  The busine= ss goal lost not because it wasn't a real problem, but because it was a bus= iness >problem, not a technical problem.  Of course for the person= dealing with the problem, it feels like a technical problem, but ultimatel= y >it's a problem because of the practices of the business being affecte= d by the added security of TLS 1.3, not because there's actually a >tech= nical problem with TLS 1.3.

Business p= roblems are realities.  No one has unlimited funds.  I know my da= ughter thinks that money grows on trees, but I would beg to differ.

In another example, quite a few of our villag= es in India have only 2g.  This is due to economic realities.  We= are trying to work with this in protocol design. It is a reality of life w= here resources are not infinite.

I do = not know if you have seen protocol changes / RFCs in certain working groups= which are intended to advantage certain businesses or vendor products.&nbs= p; I know I certainly have.  This is certainly business.

Some companies also send 50 or 100 people to the IE= TF.  This could be because they are generous contributors to the commo= n good.  I suspect it is more likely because they find there is an eco= nomic advantage to be gained by doing so.

Thanks,

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



_____________= ___________________
From: Ted Lemon <mello= n@fugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.org>
Sent: Thursday, November 15, 2018 = 7:20 AM
Subject: Re: [hrpc] "We try to avoid"



On Thu, Nov= 15, 2018 at 2:50 AM Mallory Knodel <mallory@artic= le19.org> wrote:

But just wonde= ring, what is the original purpose of that statement?
>= ;

Preventing unmanageable scope creep.=   When you add business and policy to the mix, it makes it a lot hard= er to get work done, because they are matters of opinion, not fact, and com= peting interests will not be able to reach consensus.
I think this is actually a useful thing for HRPC participan= ts to be bearing in mind:  to the extent that what we come with actual= ly has clear policy implications, it's going to be difficult to get consens= us on it.

Look at the discussion we ha= d over TLS 1.3 back in Prague.  There was a clear technical goal: mak= e connections as secure as reasonably possible (I'm sure the TLS folks will= heckle me for grossly oversimplifying=E2=80=94sorry!).  And there wa= s a competing business goal: allow me to debug my network without retooling= completely.  The business goal lost not because it wasn't a real pro= blem, but because it was a business problem, not a technical problem. = Of course for the person dealing with the problem, it feels like a techni= cal problem, but ultimately it's a problem because of the practices of the = business being affected by the added security of TLS 1.3, not because there= 's actually a technical problem with TLS 1.3.

So when we think about how the wording of this text implicates th= e work being done in HRPC, it would be good to be very careful not to jump = to conclusions about what the wording implies.  In this case, it's pr= etty clear (to me, of course!) that letting the right technical solution wi= n was better for human rights.  I think it's possible that this gener= alizes to some extent=E2=80=94my complaining about SMTP in the meeting is b= ecause although SMTP was a good enough technical solution, there were some = very serious technical problems with it that weren't considered, and these = problems came back to haunt us in a big way.  You could say the same = thing about BGP.

And having had a week= and a half to digest the BGP talk, the conclusion I've come to is that the= re's a clear net win for RPKI here.  Yes, RPKI makes it possible for = governments to openly blockade peers they don't like.  But when they = do so, it will be public, and not something that happened quietly in a room= somewhere as a result of a failed trust relationship that couldn't be enfo= rced..  RPKI creates problems for human rights, but they are problems= that we can figure out how to deal with.  Not using RPKI creates pro= blems we can't deal with.

____________= ___________________________________
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
------=_Part_1327554_1413760106.1542322105744-- From nobody Thu Nov 15 14:55:09 2018 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 A5BC812D4E6 for ; Thu, 15 Nov 2018 14:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 k5jQn9gDUaSw for ; Thu, 15 Nov 2018 14:55:04 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 3DA6B129619 for ; Thu, 15 Nov 2018 14:55:04 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id x30so13366601edx.2 for ; Thu, 15 Nov 2018 14:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mhqW7eebTXFEDeXOw7GN4geyW4c/MeIRWrASknRjOOQ=; b=AHnC03fL2/Ut02PlCzX/A7bGpt7POKTcwpqdJKGPwACc0ksEwMXfBnRs9Nk07ruWE7 HnGpHtOU6GT34FhWN4je8AjMDPLzAr358JDk/vMlOAy3LZ2cCfTfGIYwnz1WOOTed3/Z qgdSfQSQGuQWOuotKJw44tUskoBLhd48HVTnrh7TTLdQn+yDJnYHyg22O7SgsQ63QIQ+ lBu3anawJglWbu8s7O23YC6lvBPnFnzyhZGEyP089w5iRiEJKHRfieTc7uJopIwIltVi XLNooOsREVEKf8fddDnJ7MP/qB0kego6tnZNtMwQ01t+enOIgdYzlya+IszIHcvyezCZ 9x6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mhqW7eebTXFEDeXOw7GN4geyW4c/MeIRWrASknRjOOQ=; b=j2j0JyrgK813bEL3sU0CMWLzZl2+++Rb1yAtuqgnIJtVtzp0uqCWN3nJuHBBCE4Wfk RRcsC7XtLYQzjjVAKMlNcq8agl0DSb1xsOzOOJM1ioc9IMJKfBiSx0oR6SjRN45sszoI q4700TjyH7Afu3tUPSoYZcaaoDWYLTh1F6TIKZqP4084fGmF+Ce8OYcNcpwPoa/TsTfg olw45bCLuHu8IcNf0cEB9yhLAvRP5oPx1BiyEZAKEkPY5qw+/1sXsXKFc7PiX89+Vmi2 z8dvJfgFaAIRNJCqJL30UpeOMvpssccOSgVuB8f03IiDU4nLav/3F5ikI83qNu5FxuLW MZDw== X-Gm-Message-State: AGRZ1gK35BbIXGkenmBLwJxsxs57qmbvOte4YYLkACQs7xnbUCg3U2YU e35JhmtKRk48vWFJnqvlDO0= X-Google-Smtp-Source: AJdET5eYp0xXp9S5oYgTEn/G8Rw2x7RYEE3coSKp+ocaLlzXm6JSktSysEqeFpKthFL1TW8f2svD6A== X-Received: by 2002:a17:906:3712:: with SMTP id d18-v6mr6690561ejc.126.1542322502731; Thu, 15 Nov 2018 14:55:02 -0800 (PST) Received: from ?IPv6:2600:8802:5600:1546::1035? ([2600:8802:5600:1546::1035]) by smtp.gmail.com with ESMTPSA id h28-v6sm7827762ede.49.2018.11.15.14.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 14:55:01 -0800 (PST) From: Fred Baker Message-Id: <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9CD9E927-D4E9-49A8-8D11-84173EF82341"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 15 Nov 2018 14:54:57 -0800 In-Reply-To: <612735664.1327555.1542322105746@mail.yahoo.com> Cc: Ted Lemon , Mallory Knodel , Nalini Elkins , Hrpc To: Mark Perkins References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 22:55:07 -0000 --Apple-Mail=_9CD9E927-D4E9-49A8-8D11-84173EF82341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 15, 2018, at 2:48 PM, Mark Perkins = wrote: > Protocol design should be about 'end users', with 'business users' = being seen as intermediaries (important, but not ultimate). We should be = VERY careful in avoiding strengthening existing business players = position against newcomers. Just because a new protocol creates a = business problem FOR THEM is no reason not to procede when the overall = benefit to end users merits it. I agreed until you said that big companies (as opposed to small = companies) weren't end users. They actually are, and may have different = issues than smaller companies or individuals. It seems to me that we = miss something important when we decide that, without input or data, we = understand "end users" without considering all of them, and pick a = solution that seems right to us. = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_9CD9E927-D4E9-49A8-8D11-84173EF82341 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvt+UEACgkQEhdRnd2G P+CU6w/9E5RPYX5gFiEFQ6Ww0zYNLJshcbfEb6p+IzNuu042wZ/lu2cHGv92Afnz OFMN1jO/Xo8JG0tLk5PTJqECc1VRkYf3KTNW12+VSaRYWXsvYFSblH9ueHnKpPfw pWTN8y853Ph5Y8JifgE4b5uiFZ0YAh6Z9k6ipqJvsbIZKMjSiXUw476yiJ9GqSZB pd4gUfh+Y8yxvOymZ7IteLJJf7P2vOaAOitwGULNTObsN1wQHMOf941K6E0d+5md 4Z2C/UpYZeghH1ty5im3pA0tHhwnijlewh9o8GnLGWIoFmpebqnJ84Czud1ZAbhU LNKKy/TgGx5l/iCEiKZVf3Jjuxnhl9EBEsc06s8sDumBmyWEaoRngT9YGFnBNrt0 kNJdr1HWP31LOfbziSOGHICRXv89G2FhgZfcF++c051Qzc7qCBRDLQXzRJHacrAr t+0hTBO96tDyad5YHXvJo/A1ujNfhZzV5zCiQkFPPDekpJHwB5I6RlQbAwdkM24b 23XzG5EAthK2lsCDFiZoc2Nkhh/s4BVG9oDPV5jBdueymUA5zBOHix6b+dBJ0qVx Lgf//3DxXCjHZsIf7wynp4mGcXId9JUCzfsGpEZjDtKfzQz+Vrm0eJBEM1sO1cfD YTiGWzkfDM2IQtHvGY9wZbOBYPnIltf5nJRYNogsrwZIeo4OVkc= =RTj0 -----END PGP SIGNATURE----- --Apple-Mail=_9CD9E927-D4E9-49A8-8D11-84173EF82341-- From nobody Thu Nov 15 14:59:31 2018 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 80BFD129619 for ; Thu, 15 Nov 2018 14:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 xhPOgjazbNBh for ; Thu, 15 Nov 2018 14:59:28 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9E0D712D7F8 for ; Thu, 15 Nov 2018 14:59:28 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wAFMqkYN016462; Thu, 15 Nov 2018 22:59:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=IYFZaaicXZv15YWv87PmkRZ7+f7pQ4Hwmn6jWTysUKc=; b=E/+XPw8J1mVpOX6aENjVr2IOUINoeCTAdiCkgafvKYWhnYCDfCSjQwBgABcAI0mJMfN2 fY+Uo5MpVAQbC7rYOnFoSr3ZUFIAgtN2Bfl65oL3eXMNgyazxQ82iF7j05bDlvteiq1B 8J8D49H1LUXNelNigobzhwpCqRjZtx6yrQ7bgFp6HnKBR+1qgnR7jT5QHXn/OEt5/oIe YO3zB2+LW3gMajlhzhw6x+jY7oRRp8tiqlMpWvavDhnNBN2FVyheBoo5vddxH/WLvPWb Rsovr7Xg7SUPe4NehY1HP/F1WQObpV9lbtYsItd5UDMeSr/wcTaSQlbVogeoyBwkpJ7D dg== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2nrvnf3vkx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Nov 2018 22:59:21 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wAFMomHW006678; Thu, 15 Nov 2018 17:59:20 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2nr7jt290g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Nov 2018 17:59:20 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 15 Nov 2018 16:59:19 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Thu, 15 Nov 2018 16:59:19 -0600 From: "Salz, Rich" To: Fred Baker , Mark Perkins CC: Mallory Knodel , Ted Lemon , Hrpc , Nalini Elkins Thread-Topic: [hrpc] "We try to avoid" Thread-Index: AQHUfBimanAqVn1gvkONppl8bY4+oKVPn1uAgAA58oCAAALMAIAABiEAgAD52QCAAH10gIAAXvCAgAAej4CAAAHTgP//rWeA Date: Thu, 15 Nov 2018 22:59:19 +0000 Message-ID: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com> In-Reply-To: <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.13.0.181109 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.206] Content-Type: text/plain; charset="utf-8" Content-ID: <6A337EC3B8D30A46ADF2A314E5896E7A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-15_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=647 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811150198 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-15_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=636 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811150198 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 22:59:30 -0000 VGhlIG5hbWUgb2YgdGhpcyBSRyBpcyBodW1hbiByaWdodHMuDQoNCkkgaG9wZSB3ZSBhcmUgbm90 IGdvaW5nIHRvIGNvbnNpZGVyIENvcnBvcmF0aW9ucyBhcyBwb3NzZXNzaW5nIGh1bWFuIHJpZ2h0 cy4NCg0KIA0KDQo= From nobody Thu Nov 15 15:12:28 2018 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 097BE12D7F8 for ; Thu, 15 Nov 2018 15:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tppMoO5lMqEf for ; Thu, 15 Nov 2018 15:12:25 -0800 (PST) Received: from sonic317-28.consmr.mail.bf2.yahoo.com (sonic317-28.consmr.mail.bf2.yahoo.com [74.6.129.83]) (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 2E6AD12D4EA for ; Thu, 15 Nov 2018 15:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542323543; bh=iPu8ZYJjAZi/tSFHOEXZc2nbseBwDwXkN1VIlevLqN8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cMECLU/d0imLRyh2QRY/CTURbdY8Y5LVU4YTIudRM8X7j8rxc/S/x7qF1M200ao22TZZxOxUJz0+mDDSIvvfduMsVuUFJ/tq7Cj5XrFHinZiLAL4FnLV1fDJ1uMtrCPzzUMcNU+I617BDJMVrHWbVhsxigFk2EttDTgJiFNig8Ehqn8YxrZgxifMDYZDGqW+NQEUKR3dAMQ9C0IkNX0tmrtI0/Nhfir9eIkKTFaLNWKr4C8gG1Mn8KxXgddC+MrNo33EezzMKeXyKkVGZxubLG4QPb9EzJ238N5N+wDX7WIPMLy5NkwkxgHQlhKlhYiLLso/Rieki/2qRjP+wEobcg== X-YMail-OSG: 9reqlj4VM1nZTpYycUrgo4dRhiaUtRwkMEd3iWYo_Ifsraodq8ApECWA99_ljos FUC82n1P4oMU0LlMLIHH1GOgTVDsuSQpnwxWQ1gL5gngQgnY1LeLTmy0Ua1GTD3fxNaU6XcT_XTc tbJpTojqCsWOzVs_CfwseekAiKww3iQs29MKxQJtOZJcolJ74wV6gWGfsb.gr5d.OZwQH_sp5wUA hCHt048ibroGWRSskKFMSzLftyselRw7pIvU3bCOZpEwdmycgdIv3EqZNKxzT0Zf1Yznxwghdupi WMg5feq2k9_i.M.l1NNXGuR64dkH6mnCFsXNl.w.GO2DgbGazeGQWAaRO5uhivJJwewKrRv.W8AT 2K657RlOFS_7g2EMch.k_D5PfUgbFPHit7xnSeayXhZ0UOKOmPlGpApAxO5lww1GwqnKag60Ep37 52R3cQ8KMGkDgZJyNSxvIztJ7CWTBucptEgJV6tr6fg_UHNEgPCKW5lF63cvAK8EZuUD794vk_Ba WjEZL3otLUwqXoBPbyIanlvOLNBdHddU682GpK3P33jjsZTFBfmsM0ZV8NWUrTTxKSYtsMNHcT8H g6tLpZpZQbB4WKzXjpmL5l4RyQTa72nb_wIkwqumKGfT5BJIQjlksvAuAOZieZtpQMFXduE62jF7 lw5jkDcLvSM6a_YEiyo_4r5ch8fgIbVVGRqY5EstNpg8r.21V6cXpKxl6dUp3_W2D_ODPbdt4KBk R5P.m90iScAJT8VV9G7vqhWQZqksk_zFHiwQMTriuy1u9U7SStGYTO2lQ_iAdWOlU.XFfraPS3CX Q7.ekNHoedsbHIi4pjJPeBtzTLvUaLz511PZ7ig90F1cQq2R3kvDLvEi0_sOralRvOmozoJ6hjkX HKrvKjXScc4vlVLI33UduYJLyEHG7_NbJDxnBlCy6fZjzTEWd4_aFuRhJ44CD6jy_DbBVqpoOzAT KFot83MjjjRLG7nwPkrF0DLF9G8gOxHKr5.Ym9Bs9Ro7icTzQghTQF2Z9GAdeAPaj.ChmlFAADOM 6snhT1BodtGj5xzru Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Thu, 15 Nov 2018 23:12:23 +0000 Date: Thu, 15 Nov 2018 23:12:22 +0000 (UTC) From: Mark Perkins To: Fred Baker , "Salz, Rich" Cc: Mallory Knodel , Ted Lemon , Hrpc , Nalini Elkins Message-ID: <194830021.1361612.1542323542057@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1361611_128669672.1542323542056" X-Mailer: WebService/1.1.12729 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 23:12:27 -0000 ------=_Part_1361611_128669672.1542323542056 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Totally agree Rich - this has become so evident regarding copyright Mark P. On Friday, November 16, 2018, 9:59:28 AM GMT+11, Salz, Rich wrote: The name of this RG is human rights. I hope we are not going to consider Corporations as possessing human rights. ------=_Part_1361611_128669672.1542323542056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Totally agree Rich - this has become so evident regarding copyright

Mark P.

On Friday, November 16, 2018, 9:59:28 AM GMT+11, Salz, Rich <rsalz@akamai.com> wrote:


The name of this RG is human rights.

I hope we are not going to consider Corporations as possessing human rights.




------=_Part_1361611_128669672.1542323542056-- From nobody Thu Nov 15 15:25:02 2018 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 75227130EA8 for ; Thu, 15 Nov 2018 15:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrIVA3ZSZuAG for ; Thu, 15 Nov 2018 15:24:58 -0800 (PST) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (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 553FD12D4EA for ; Thu, 15 Nov 2018 15:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542324297; bh=4tMrBdJsPDtYuyTK3adpqnCCwe9A2lnI35oeMYG5bdc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=tVEYO8hcR/1l0CJp/0fx9txX46vrDloIkc9gk3GY0fvYXGSTIV36eIV2Bx9OcLaMR+l+Eel8ve3/gmyFm/NK57mwtbvJanmmeIjWV4TkFggspDs7R2YuCeEEiAGWfVma6dBv5PlG7Ca6eSYjn+7XxpLgfu32Paq96oydrlPqD2SkfwlCl+XxbhWFN6QW7auR/AK8N375eDgke+kRXxbIfUjvlR/A1Ptpm0dggQShJWcQGs9CdO9sfHukvzkPEcVXfPl3hOPbo+yC1aMv8mGuV/lUB6ZjvbN3RIf8xLMZ/jGukJ8UlCMNOGJWgGlY49/2BXvIoR2Wlg71M2YYA+L/sw== X-YMail-OSG: alQ0x4sVM1mzoPros4mWtBKheIasGrL7RCSSzYTWPQMAbL118HgDMC9Vu_zVaIm afxprFL8b55TPgs.dDWhNYNR7WFOXuIasWRripjiWUDc9DsDWeCgbkFXm5.wyugLiB8cV9qN2_vd x4zoaKKdKOWgTLKuF7y_Cq4kdQhDZDw6..FeBQQTO.Pd.YP2zJ9oO9PXrjevmJSXtudp.oMMHai3 oSl0qSEznMz_DTFY_JD324di75mksPQglc.xll4qJydGq8wqoPf83spQHsHEJ4L3xfsmiB4zI4Am 1azga1_3V_c8OzUU2wOnHf.Ff_TLjymHnHJVUjXSDVStUREX3vatrQ7up0C3W.ZhhjlpRsK1xvow lj_ljz_08WmDEA011CpM9cmfz9hz_bbNF8EWXSUawsiTnAjuw0y_wZtRW0Qrz5r2Db73yXdpHaLA 1Kh.4EiTj958Weftn8BuuIxMgRkTfxnCWFejWM9SAinUcs34b3u0nKyTb5YmD1D35pAoH7rPQNcQ n7rA9i4oLJ0XNh3tDFYQsZe8JtDbm4ILFYs_3HFTzDJHn3zrw_j9qQA5fqCQpqiEGvpvFospOPsW 4S9ZEHgUSOyVNqlGvjpAQKlIXUsVwcRA9NUht1LfKmSVnWjd3GHLI0Wwn0OJw2NCHMp59v3y8nb3 hkextG3YmOqE2pTu.MYmyl0CwR7Da7tU39A9MhJRX7.0F.QoT_9S6GYuzx4yUfgzPsrGCTwcBflu tYCZt4K3i9nkS_zncrED6N5mKpur8MDriiHExKjEZH0ChSdFV.InaZ8C27ZNqXik89Qz5BIRTN2W dDlWc4pGFzoWYTnrs5MdWD_lu0FJ8tYVOSEGaI8O_8G_kfxg65rnWoBIG_2a_m.cCSEllRKePdVM kFM2cHApMP.wiVRNR07dVV5UGLeHs4yvrG3mrM7BtQkrItwDrgVY9H5CLI4ri_RIrLK4NGs_00Om E7OTyQyiLUtYtqC7Cd1h9zSlnuL9LWkIb6raLboGro0WH6u86a4lzjoc95lKxKyDBewg8ukqTX3v vohi3MiHZeSMlpvwH Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Thu, 15 Nov 2018 23:24:57 +0000 Date: Thu, 15 Nov 2018 23:24:47 +0000 (UTC) From: Mark Perkins To: Mark Perkins , Fred Baker Cc: Mallory Knodel , Ted Lemon , Hrpc , Nalini Elkins Message-ID: <867030477.1385348.1542324287635@mail.yahoo.com> In-Reply-To: <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1385347_920083593.1542324287633" X-Mailer: WebService/1.1.12729 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 23:25:01 -0000 ------=_Part_1385347_920083593.1542324287633 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that B2B implies that businesses are protocol end users - though w= ithout human rights. Thus in these terms, they would be out of scope. From = a human rights perspective, they are only intermediaries. In terms of practicalities, business protocol end user problems clearly cou= nt (otherwise the implementation of protocols could be limited), but these = do not over-ride the human rights concerns (which are beyond business usage= problems),=20 Nor should business problems be either seen as an excuse for protecting exi= sting advantages (eg. the whole copyright maximalist fiasco) nor as favorin= g a certain sector. As I stated, this makes the business problem calculus d= ifficult, as protocol design needs to (should) look at the 'GLOBAL business= problem(s)' , current & future, and not just particular cases... Mark P. On Friday, November 16, 2018, 9:55:16 AM GMT+11, Fred Baker wrote: =20 =20 =20 On Nov 15, 2018, at 2:48 PM, Mark Perkins wrote: > Protocol design should be about 'end users', with 'business users' being = seen as intermediaries (important, but not ultimate). We should be VERY car= eful in avoiding strengthening existing business players position against n= ewcomers. Just because a new protocol creates a business problem FOR THEM i= s no reason not to procede when the overall benefit to end users merits it. I agreed until you said that big companies (as opposed to small companies) = weren't end users. They actually are, and may have different issues than sm= aller companies or individuals. It seems to me that we miss something impor= tant when we decide that, without input or data, we understand "end users" = without considering all of them, and pick a solution that seems right to us= . ---------------------------------------------------------------------------= ----- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. =C2=A0 =C2=A0 Sun Tzu _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1385347_920083593.1542324287633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that B2B implies that businesses are protocol end user= s - though without human rights. Thus in these terms, they would be out of = scope. From a human rights perspective, they are only intermediaries.
=

In terms of practicalities, business protocol end user = problems clearly count (otherwise the implementation of protocols could be = limited), but these do not over-ride the human rights concerns (which are b= eyond business usage problems),

Nor should bu= siness problems be either seen as an excuse for protecting existing advanta= ges (eg. the whole copyright maximalist fiasco) nor as favoring a certain s= ector. As I stated, this makes the business problem calculus difficult, as = protocol design needs to (should) look at the 'GLOBAL business problem(s)' = , current & future, and not just particular cases...

Mark P.
=20
On Friday, November 16, 2018, 9:55:16 AM GMT+11, Fred B= aker <fredbaker.ietf@gmail.com> wrote:




On Nov 15, 2018, at 2:48 PM= , Mark Perkins <marknoumea=3D40yahoo.com= @dmarc.ietf.org> wrote:
> Protocol design shoul= d be about 'end users', with 'business users' being seen as intermediaries = (important, but not ultimate). We should be VERY careful in avoiding streng= thening existing business players position against newcomers. Just because = a new protocol creates a business problem FOR THEM is no reason not to proc= ede when the overall benefit to end users merits it.


I agreed until you said that big companies (as opposed= to small companies) weren't end users. They actually are, and may have dif= ferent issues than smaller companies or individuals. It seems to me that we= miss something important when we decide that, without input or data, we un= derstand "end users" without considering all of them, and pick a solution t= hat seems right to us.
----------------------------------= ----------------------------------------------
Victorious= warriors win first and then go to war,
Defeated warriors= go to war first and then seek to win.
    Sun= Tzu

_____________________= __________________________
hrpc mailing list
hrpc@irtf.org
https://www.ir= tf.org/mailman/listinfo/hrpc
------=_Part_1385347_920083593.1542324287633-- From nobody Thu Nov 15 17:21:07 2018 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 CD53D130DE7 for ; Thu, 15 Nov 2018 17:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 V5GFnQq4kpD7 for ; Thu, 15 Nov 2018 17:21:02 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEAB12F18C for ; Thu, 15 Nov 2018 17:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9973; q=dns/txt; s=iport; t=1542331261; x=1543540861; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TUlIuoFy6z0Vpqe+3z3sH05LN0HQEGKP223/p+NMy7U=; b=JGQAqrcYsDjceJR3qCsndfT+/oS0CiPrWpIpODGMyk8yFwEXhwLrnUMi 5LTGfI61wRDu7kx7NBmMX2uLxDp/YQQe6JI8GiELaEc+Bxb2Y+ZjOMgZn tifIAuDZq1A780tPMWLZbc6J3Ns0JMAljTLkpQUPMFbnuYU3hlxKrdm9d Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAArGu5b/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ12ZoECJ4N4lXsliQeIW4VogWYLAQE?= =?us-ascii?q?YAQqESQIXgzkiNwYNAQMBAQIBAQJtHAyFPQEBBAEBIUsLEAIBCBgnAwICAh8?= =?us-ascii?q?GCxQRAgQOBRsDgwMBgR1MAxUPp02BL4gBDYIUBYwFF4FAP4E4DBOCTIJWRQE?= =?us-ascii?q?DgSQUPoJtMYImAoh0JIFsg3CGMooQLgkCjXeDKxiQdo42iSoCERSBJzUigVV?= =?us-ascii?q?wFTsqAYJBgicXiF6FPkExAYsRgk0BAQ?= X-IronPort-AV: E=Sophos;i="5.56,238,1539648000"; d="scan'208,217";a="480888882" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2018 01:21:00 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id wAG1L059003961 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Nov 2018 01:21:00 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 15 Nov 2018 19:20:59 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1395.000; Thu, 15 Nov 2018 19:20:59 -0600 From: "Eliot Lear (elear)" To: Mark Perkins CC: Fred Baker , Mallory Knodel , Ted Lemon , Hrpc , Nalini Elkins Thread-Topic: [hrpc] "We try to avoid" Thread-Index: AQHUfLfmeYQ3ndPJBEq1+72lxqA9WaVRWEiAgABe8YCAAB6OgIAAAdSAgAAIVYD//7vjzA== Date: Fri, 16 Nov 2018 01:20:59 +0000 Message-ID: <8DCE3DE8-6492-4506-8581-FF0BF3C15F02@cisco.com> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com>, <867030477.1385348.1542324287635@mail.yahoo.com> In-Reply-To: <867030477.1385348.1542324287635@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_8DCE3DE8649245068581FF0BF3C15F02ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 01:21:06 -0000 --_000_8DCE3DE8649245068581FF0BF3C15F02ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnVzaW5lc3NlcyBoYXZlIEhSIGFuZCBvdGhlciByZXNwb25zaWJpbGl0aWVzIHRoYXQgY2FuIGFu ZCBkbyBjb21lIGludG8gY29uZmxpY3Qgd2l0aCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIG9mIGVt cGxveWVlcy4gSG93IHRoYXQgcGxheXMgb3V0IGluIHByb3RvY29scyBpcyBhbiBpbXBvcnRhbnQg cXVlc3Rpb24uDQoNCkVsaW90DQoNCk9uIE5vdiAxNiwgMjAxOCwgYXQgMDg6MjUsIE1hcmsgUGVy a2lucyA8bWFya25vdW1lYT00MHlhaG9vLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86bWFya25v dW1lYT00MHlhaG9vLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpJIGFncmVlIHRoYXQg QjJCIGltcGxpZXMgdGhhdCBidXNpbmVzc2VzIGFyZSBwcm90b2NvbCBlbmQgdXNlcnMgLSB0aG91 Z2ggd2l0aG91dCBodW1hbiByaWdodHMuIFRodXMgaW4gdGhlc2UgdGVybXMsIHRoZXkgd291bGQg YmUgb3V0IG9mIHNjb3BlLiBGcm9tIGEgaHVtYW4gcmlnaHRzIHBlcnNwZWN0aXZlLCB0aGV5IGFy ZSBvbmx5IGludGVybWVkaWFyaWVzLg0KDQpJbiB0ZXJtcyBvZiBwcmFjdGljYWxpdGllcywgYnVz aW5lc3MgcHJvdG9jb2wgZW5kIHVzZXIgcHJvYmxlbXMgY2xlYXJseSBjb3VudCAob3RoZXJ3aXNl IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBwcm90b2NvbHMgY291bGQgYmUgbGltaXRlZCksIGJ1dCB0 aGVzZSBkbyBub3Qgb3Zlci1yaWRlIHRoZSBodW1hbiByaWdodHMgY29uY2VybnMgKHdoaWNoIGFy ZSBiZXlvbmQgYnVzaW5lc3MgdXNhZ2UgcHJvYmxlbXMpLA0KDQpOb3Igc2hvdWxkIGJ1c2luZXNz IHByb2JsZW1zIGJlIGVpdGhlciBzZWVuIGFzIGFuIGV4Y3VzZSBmb3IgcHJvdGVjdGluZyBleGlz dGluZyBhZHZhbnRhZ2VzIChlZy4gdGhlIHdob2xlIGNvcHlyaWdodCBtYXhpbWFsaXN0IGZpYXNj bykgbm9yIGFzIGZhdm9yaW5nIGEgY2VydGFpbiBzZWN0b3IuIEFzIEkgc3RhdGVkLCB0aGlzIG1h a2VzIHRoZSBidXNpbmVzcyBwcm9ibGVtIGNhbGN1bHVzIGRpZmZpY3VsdCwgYXMgcHJvdG9jb2wg ZGVzaWduIG5lZWRzIHRvIChzaG91bGQpIGxvb2sgYXQgdGhlICdHTE9CQUwgYnVzaW5lc3MgcHJv YmxlbShzKScgLCBjdXJyZW50ICYgZnV0dXJlLCBhbmQgbm90IGp1c3QgcGFydGljdWxhciBjYXNl cy4uLg0KDQpNYXJrIFAuDQpPbiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDE4LCA5OjU1OjE2IEFN IEdNVCsxMSwgRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPG1haWx0bzpmcmVk YmFrZXIuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQoNCg0KT24gTm92IDE1LCAyMDE4LCBh dCAyOjQ4IFBNLCBNYXJrIFBlcmtpbnMgPG1hcmtub3VtZWE9NDB5YWhvby5jb21AZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOjQweWFob28uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+IFByb3Rv Y29sIGRlc2lnbiBzaG91bGQgYmUgYWJvdXQgJ2VuZCB1c2VycycsIHdpdGggJ2J1c2luZXNzIHVz ZXJzJyBiZWluZyBzZWVuIGFzIGludGVybWVkaWFyaWVzIChpbXBvcnRhbnQsIGJ1dCBub3QgdWx0 aW1hdGUpLiBXZSBzaG91bGQgYmUgVkVSWSBjYXJlZnVsIGluIGF2b2lkaW5nIHN0cmVuZ3RoZW5p bmcgZXhpc3RpbmcgYnVzaW5lc3MgcGxheWVycyBwb3NpdGlvbiBhZ2FpbnN0IG5ld2NvbWVycy4g SnVzdCBiZWNhdXNlIGEgbmV3IHByb3RvY29sIGNyZWF0ZXMgYSBidXNpbmVzcyBwcm9ibGVtIEZP UiBUSEVNIGlzIG5vIHJlYXNvbiBub3QgdG8gcHJvY2VkZSB3aGVuIHRoZSBvdmVyYWxsIGJlbmVm aXQgdG8gZW5kIHVzZXJzIG1lcml0cyBpdC4NCg0KDQpJIGFncmVlZCB1bnRpbCB5b3Ugc2FpZCB0 aGF0IGJpZyBjb21wYW5pZXMgKGFzIG9wcG9zZWQgdG8gc21hbGwgY29tcGFuaWVzKSB3ZXJlbid0 IGVuZCB1c2Vycy4gVGhleSBhY3R1YWxseSBhcmUsIGFuZCBtYXkgaGF2ZSBkaWZmZXJlbnQgaXNz dWVzIHRoYW4gc21hbGxlciBjb21wYW5pZXMgb3IgaW5kaXZpZHVhbHMuIEl0IHNlZW1zIHRvIG1l IHRoYXQgd2UgbWlzcyBzb21ldGhpbmcgaW1wb3J0YW50IHdoZW4gd2UgZGVjaWRlIHRoYXQsIHdp dGhvdXQgaW5wdXQgb3IgZGF0YSwgd2UgdW5kZXJzdGFuZCAiZW5kIHVzZXJzIiB3aXRob3V0IGNv bnNpZGVyaW5nIGFsbCBvZiB0aGVtLCBhbmQgcGljayBhIHNvbHV0aW9uIHRoYXQgc2VlbXMgcmln aHQgdG8gdXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVmljdG9yaW91cyB3YXJyaW9ycyB3 aW4gZmlyc3QgYW5kIHRoZW4gZ28gdG8gd2FyLA0KRGVmZWF0ZWQgd2FycmlvcnMgZ28gdG8gd2Fy IGZpcnN0IGFuZCB0aGVuIHNlZWsgdG8gd2luLg0KICAgIFN1biBUenUNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmhycGMgbWFpbGluZyBsaXN0DQpo cnBjQGlydGYub3JnPG1haWx0bzpocnBjQGlydGYub3JnPg0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ocnBjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KaHJwYyBtYWlsaW5nIGxpc3QNCmhycGNAaXJ0Zi5vcmc8bWFpbHRvOmhy cGNAaXJ0Zi5vcmc+DQpodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hycGMN Cg== --_000_8DCE3DE8649245068581FF0BF3C15F02ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpC dXNpbmVzc2VzIGhhdmUgSFIgYW5kIG90aGVyIHJlc3BvbnNpYmlsaXRpZXMgdGhhdCBjYW4gYW5k IGRvIGNvbWUgaW50byBjb25mbGljdCB3aXRoIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgb2YgZW1w bG95ZWVzLiBIb3cgdGhhdCBwbGF5cyBvdXQgaW4gcHJvdG9jb2xzIGlzIGFuIGltcG9ydGFudCBx dWVzdGlvbi4mbmJzcDs8YnI+DQo8YnI+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiIGRp cj0ibHRyIj5FbGlvdDwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KT24gTm92IDE2LCAyMDE4 LCBhdCAwODoyNSwgTWFyayBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86bWFya25vdW1lYT00 MHlhaG9vLmNvbUBkbWFyYy5pZXRmLm9yZyI+bWFya25vdW1lYT00MHlhaG9vLmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9InlkcDgxYmJiZDc5eWFob28t c3R5bGUtd3JhcCIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2Es IEFyaWFsLCBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxM3B4OyI+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5J IGFncmVlIHRoYXQgQjJCIGltcGxpZXMgdGhhdCBidXNpbmVzc2VzIGFyZSBwcm90b2NvbCBlbmQg dXNlcnMgLSB0aG91Z2ggd2l0aG91dCBodW1hbiByaWdodHMuIFRodXMgaW4gdGhlc2UgdGVybXMs IHRoZXkgd291bGQgYmUgb3V0IG9mIHNjb3BlLiBGcm9tIGEgaHVtYW4gcmlnaHRzIHBlcnNwZWN0 aXZlLCB0aGV5IGFyZSBvbmx5IGludGVybWVkaWFyaWVzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SW4gdGVybXMgb2YgcHJhY3RpY2FsaXRpZXMsIGJ1c2luZXNzIHByb3RvY29sIGVu ZCB1c2VyIHByb2JsZW1zIGNsZWFybHkgY291bnQgKG90aGVyd2lzZSB0aGUgaW1wbGVtZW50YXRp b24gb2YgcHJvdG9jb2xzIGNvdWxkIGJlIGxpbWl0ZWQpLCBidXQgdGhlc2UgZG8gbm90IG92ZXIt cmlkZSB0aGUgaHVtYW4gcmlnaHRzIGNvbmNlcm5zICh3aGljaCBhcmUgYmV5b25kIGJ1c2luZXNz IHVzYWdlIHByb2JsZW1zKSwNCjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ Tm9yIHNob3VsZCBidXNpbmVzcyBwcm9ibGVtcyBiZSBlaXRoZXIgc2VlbiBhcyBhbiBleGN1c2Ug Zm9yIHByb3RlY3RpbmcgZXhpc3RpbmcgYWR2YW50YWdlcyAoZWcuIHRoZSB3aG9sZSBjb3B5cmln aHQgbWF4aW1hbGlzdCBmaWFzY28pIG5vciBhcyBmYXZvcmluZyBhIGNlcnRhaW4gc2VjdG9yLiBB cyBJIHN0YXRlZCwgdGhpcyBtYWtlcyB0aGUgYnVzaW5lc3MgcHJvYmxlbSBjYWxjdWx1cyBkaWZm aWN1bHQsIGFzIHByb3RvY29sIGRlc2lnbg0KIG5lZWRzIHRvIChzaG91bGQpIGxvb2sgYXQgdGhl ICdHTE9CQUwgYnVzaW5lc3MgcHJvYmxlbShzKScgLCBjdXJyZW50ICZhbXA7IGZ1dHVyZSwgYW5k IG5vdCBqdXN0IHBhcnRpY3VsYXIgY2FzZXMuLi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pk1hcmsgUC48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ieWFob29fcXVvdGVkXzI5 MTE5MTUzODgiIGNsYXNzPSJ5YWhvb19xdW90ZWQiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 J0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZjtmb250LXNpemU6 MTNweDtjb2xvcjojMjYyODJhOyI+DQo8ZGl2Pk9uIEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTgs IDk6NTU6MTYgQU0gR01UJiM0MzsxMSwgRnJlZCBCYWtlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZy ZWRiYWtlci5pZXRmQGdtYWlsLmNvbSI+ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgZGlyPSJsdHIiPjxiciBjbGVhcj0ibm9uZSI+DQo8ZGl2IGNsYXNzPSJ5cXQ0MjY0 ODQ5OTY3IiBpZD0ieXF0ZmQwNTYyMiI+PGJyIGNsZWFyPSJub25lIj4NCk9uIE5vdiAxNSwgMjAx OCwgYXQgMjo0OCBQTSwgTWFyayBQZXJraW5zICZsdDttYXJrbm91bWVhPTxhIHNoYXBlPSJyZWN0 IiB5bWFpbHRvPSJtYWlsdG86NDB5YWhvby4uY29tQGRtYXJjLmlldGYub3JnIiBocmVmPSJtYWls dG86NDB5YWhvby5jb21AZG1hcmMuaWV0Zi5vcmciPjQweWFob28uY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDsgd3JvdGU6PGJyIGNsZWFyPSJub25lIj4NCiZndDsgUHJvdG9jb2wgZGVzaWduIHNo b3VsZCBiZSBhYm91dCAnZW5kIHVzZXJzJywgd2l0aCAnYnVzaW5lc3MgdXNlcnMnIGJlaW5nIHNl ZW4gYXMgaW50ZXJtZWRpYXJpZXMgKGltcG9ydGFudCwgYnV0IG5vdCB1bHRpbWF0ZSkuIFdlIHNo b3VsZCBiZSBWRVJZIGNhcmVmdWwgaW4gYXZvaWRpbmcgc3RyZW5ndGhlbmluZyBleGlzdGluZyBi dXNpbmVzcyBwbGF5ZXJzIHBvc2l0aW9uIGFnYWluc3QgbmV3Y29tZXJzLiBKdXN0IGJlY2F1c2Ug YSBuZXcgcHJvdG9jb2wNCiBjcmVhdGVzIGEgYnVzaW5lc3MgcHJvYmxlbSBGT1IgVEhFTSBpcyBu byByZWFzb24gbm90IHRvIHByb2NlZGUgd2hlbiB0aGUgb3ZlcmFsbCBiZW5lZml0IHRvIGVuZCB1 c2VycyBtZXJpdHMgaXQuPC9kaXY+DQo8YnIgY2xlYXI9Im5vbmUiPg0KPGJyIGNsZWFyPSJub25l Ij4NCkkgYWdyZWVkIHVudGlsIHlvdSBzYWlkIHRoYXQgYmlnIGNvbXBhbmllcyAoYXMgb3Bwb3Nl ZCB0byBzbWFsbCBjb21wYW5pZXMpIHdlcmVuJ3QgZW5kIHVzZXJzLiBUaGV5IGFjdHVhbGx5IGFy ZSwgYW5kIG1heSBoYXZlIGRpZmZlcmVudCBpc3N1ZXMgdGhhbiBzbWFsbGVyIGNvbXBhbmllcyBv ciBpbmRpdmlkdWFscy4gSXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBtaXNzIHNvbWV0aGluZyBpbXBv cnRhbnQgd2hlbiB3ZSBkZWNpZGUgdGhhdCwgd2l0aG91dA0KIGlucHV0IG9yIGRhdGEsIHdlIHVu ZGVyc3RhbmQgJnF1b3Q7ZW5kIHVzZXJzJnF1b3Q7IHdpdGhvdXQgY29uc2lkZXJpbmcgYWxsIG9m IHRoZW0sIGFuZCBwaWNrIGEgc29sdXRpb24gdGhhdCBzZWVtcyByaWdodCB0byB1cy48YnIgY2xl YXI9Im5vbmUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xlYXI9Im5vbmUiPg0KVmlj dG9yaW91cyB3YXJyaW9ycyB3aW4gZmlyc3QgYW5kIHRoZW4gZ28gdG8gd2FyLDxiciBjbGVhcj0i bm9uZSI+DQpEZWZlYXRlZCB3YXJyaW9ycyBnbyB0byB3YXIgZmlyc3QgYW5kIHRoZW4gc2VlayB0 byB3aW4uPGJyIGNsZWFyPSJub25lIj4NCiZuYnNwOyAmbmJzcDsgU3VuIFR6dQ0KPGRpdiBjbGFz cz0ieXF0NDI2NDg0OTk2NyIgaWQ9InlxdGZkMzQyNTciPjxiciBjbGVhcj0ibm9uZSI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieXF0NDI2NDg0OTk2NyIgaWQ9InlxdGZkMjMxNjkiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsZWFyPSJu b25lIj4NCmhycGMgbWFpbGluZyBsaXN0PGJyIGNsZWFyPSJub25lIj4NCjxhIHNoYXBlPSJyZWN0 IiB5bWFpbHRvPSJtYWlsdG86aHJwY0BpcnRmLm9yZyIgaHJlZj0ibWFpbHRvOmhycGNAaXJ0Zi5v cmciPmhycGNAaXJ0Zi5vcmc8L2E+PGJyIGNsZWFyPSJub25lIj4NCjxhIHNoYXBlPSJyZWN0IiBo cmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hycGMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hycGM8L2E+PGJy IGNsZWFyPSJub25lIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPjxz cGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu Pjxicj4NCjxzcGFuPmhycGMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9 Im1haWx0bzpocnBjQGlydGYub3JnIj5ocnBjQGlydGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hycGMiPmh0 dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vaHJwYzwvYT48L3NwYW4+PGJyPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8DCE3DE8649245068581FF0BF3C15F02ciscocom_-- From nobody Thu Nov 15 22:16:54 2018 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 A1E2212777C for ; Thu, 15 Nov 2018 22:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huw2BuAKQ6k6 for ; Thu, 15 Nov 2018 22:16:51 -0800 (PST) Received: from sonic316-28.consmr.mail.ne1.yahoo.com (sonic316-28.consmr.mail.ne1.yahoo.com [66.163.187.154]) (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 D05151271FF for ; Thu, 15 Nov 2018 22:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542349009; bh=Yr4fkxKu3dAKNvURPKK23x5gYlbviLwfWzGTmWrT590=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=BGJ0LkKqkpApH+j/N+PqjXhRnYRACSxqExGFbPbx7VAnkmEQh0cH49xcNXM/QttzhB36AZ8LRveM/29rU08cNN1iO2Tmb4CmFRoEfN74b8ZWJURuleOoLCmmhRLhNnIgXkhJrLBh9EhDCEB9rhUWOUBJFlDVzb5OeO++kiBYQaydmbHBqw1urXDZVU0pLnRKWK7dU1d3SAuW41TF8cTAJHGJNTKL15dsUhMtFsEEbPze/SFVRZUfanQYtjf+39QUpHAEK92ddxMRxFxzb2dC7QYyjr8H3nE86843aXl9N9LM5TqqpvSnRshc1RJMKCpagwHJmSYbYz533WpDZKAAeQ== X-YMail-OSG: Ki3g7c0VM1ntioGf6GQIRpI__QD2FczPvLN8AuJmLfbaIUq2_E0ICgoaU3iheVl LxJ5s_RL4HK.EhP5riuCTKO9IAPAON.IyqNxo7CQWfdGjU9N.MXaQLGZYlK4G1.QJsKx7enLgHiq uSctjpPuUMUWlQpg5TijdMquDFqF_0ModT0FqRkbs9eT.gdU7gyOnD8HwkRS.SNgY0aqcQFOBEev pk2xUfFdxx3Q_gjgkww6wcJOtcasbFuuFuqOVBdHcOTl50vL18xRI8mx8HmoTu2rOts0yMbjYmnq 6L4l5tsVr872OjAqLo_iLu82c6oAseRioFk_OBcVPuFpTgM4XrACA60GhpJHbUcuj4zUsHE413.e utqeiWVvSjn00qcv3Pb8nTttf_rZ7iKWYkcYshVv7gVxExZig7Z2qjJ35vNZTth8nl4jij8wyk2w bQYFj25KqaY4cAAiPQ3e113fMW3TtTiJsLAmlWYtx_9soTX8EIW9HyeUDD4XwdAEzFy8EkaR751U 6ElTaTqInLYJXT4BuyuIqZtSKb7isyrxoyFP61Ndu8Kr7NfAwGoGU120UUburjM43jhvHBwLTIT_ GkUq.Q3zrtmmKx78igh8YrGynRqc8aAHwSCymUPhGYKym.raoBefxZ6GiLE0pkeqakUGFaJLBhJH iVfeFJcWP1skHQLMc8wRWGwH8vgDbFvK1gULKLgSYCOCkiDf02ls_02EXEy9XPD3V8WXMnP5VOnz ionwjmvRU8ovdxcbZcpWrzV2VvVoo0TanPHjHrnZ36cSP.SiufVi.PrbVeCnrr6auGDI_uf.Mq6O qn5047pVhFPZQG__082IOUrD9Yh3Vw0f7aAoWb_UMLvP1x31Pa5GCi_5mbsPNZS9FCiW89.71UKU jvDEWwzQcGfv8ioXe53ndY.4cNQ5dFuapfWq7qO8jbdrhhC2bio.iMriKjQPIK7xe6lCjpZjxj92 _OQLN5O9EKVm0CCfdFqoCAXnDOPdsKpZuS7YfauM1Vk.1rW6xtBlMF17rigZY3LrOow6.u9OZ6s1 R1wWdTg_.u7EnKSg7Y1sHpjFjIoYer40ln_8LMLD6n7l5Db3ULsMMbAQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 06:16:49 +0000 Date: Fri, 16 Nov 2018 06:16:28 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Ted Lemon Cc: Mallory Knodel , Hrpc Message-ID: <1368964404.1469671.1542348988205@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1469670_395923877.1542348988201" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 06:16:54 -0000 ------=_Part_1469670_395923877.1542348988201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ted, > It frustrates me that you feel comfortable impugning the motives of IETF = participants who really tried very hard to engage on this issue I don't know what leads you to say that I am doing that.=C2=A0 =C2=A0I am c= ompletely at a loss.=C2=A0 =C2=A0I have re-read what I wrote and I do not t= hink anything in what I wrote would lead to your statement. I am quite upset by what you are saying.=C2=A0 In the future, I think it is= best to not respond to email threads from you.=C2=A0 It seems to lead to t= oo much misunderstanding.=C2=A0 =C2=A0If at some point, you want to talk fa= ce to face, I am always open to that.=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Mallory Knodel ; Hrpc Sent: Thursday, November 15, 2018 1:17 PM Subject: Re: [hrpc] "We try to avoid" =20 I'm pretty sure that the motivation for keeping TLS secure is that it benef= its end users by preventing criminals (and businesses) from eavesdropping o= n their connections.=C2=A0 =C2=A0That was certainly my motivation for engag= ing in the discussion.=C2=A0 =C2=A0It frustrates me that you feel comfortab= le impugning the motives of IETF participants who really tried very hard to= engage on this issue and propose solutions that addressed the use cases th= at we were talking about.=C2=A0 =C2=A0It was very frustrating to simply be = told "no, you have to break your protocol for us because we won't use that = other protocol that actually addresses our use case and wouldn't break TLS.= " We may be wandering a bit off-topic, but in a sense this is an important di= scussion because when we get into a calculus like this, human rights are ve= ry much at risk. On Thu, Nov 15, 2018 at 3:59 PM Nalini J Elkins wrote: Ted, >Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0The= re was a clear technical goal: make connections as secure as reasonably >po= ssible (I'm sure the TLS folks will heckle me for grossly oversimplifying= =E2=80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allo= w me to >debug my network without retooling completely.=C2=A0 =C2=A0The bus= iness goal lost not because it wasn't a real problem, but because it was a = business >problem, not a technical problem.=C2=A0 =C2=A0Of course for the p= erson dealing with the problem, it feels like a technical problem, but ulti= mately >it's a problem because of the practices of the business being affec= ted by the added security of TLS 1.3, not because there's actually a >techn= ical problem with TLS 1.3. Business problems are realities.=C2=A0 No one has unlimited funds.=C2=A0 I = know my daughter thinks that money grows on trees, but I would beg to diffe= r. In another example, quite a few of our villages in India have only 2g.=C2= =A0 This is due to economic realities.=C2=A0 We are trying to work with thi= s in protocol design. It is a reality of life where resources are not infin= ite. I do not know if you have seen protocol changes / RFCs in certain working g= roups which are intended to advantage certain businesses or vendor products= .=C2=A0 I know I certainly have.=C2=A0 This is certainly business. Some companies also send 50 or 100 people to the IETF.=C2=A0 This could be = because they are generous contributors to the common good.=C2=A0 I suspect = it is more likely because they find there is an economic advantage to be ga= ined by doing so. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Ted Lemon To: Mallory Knodel =20 Cc: Hrpc Sent: Thursday, November 15, 2018 7:20 AM Subject: Re: [hrpc] "We try to avoid" On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel wrot= e: But just wondering, what is the original purpose of that statement? > Preventing unmanageable scope creep.=C2=A0 =C2=A0When you add business and = policy to the mix, it makes it a lot harder to get work done, because they = are matters of opinion, not fact, and competing interests will not be able = to reach consensus. I think this is actually a useful thing for HRPC participants to be bearing= in mind:=C2=A0 to the extent that what we come with actually has clear pol= icy implications, it's going to be difficult to get consensus on it. Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2= =80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allow m= e to debug my network without retooling completely.=C2=A0 =C2=A0The busines= s goal lost not because it wasn't a real problem, but because it was a busi= ness problem, not a technical problem.=C2=A0 =C2=A0Of course for the person= dealing with the problem, it feels like a technical problem, but ultimatel= y it's a problem because of the practices of the business being affected by= the added security of TLS 1.3, not because there's actually a technical pr= oblem with TLS 1.3. So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies.=C2=A0 =C2=A0In this case, it's pretty = clear (to me, of course!) that letting the right technical solution win was= better for human rights.=C2=A0 =C2=A0I think it's possible that this gener= alizes to some extent=E2=80=94my complaining about SMTP in the meeting is b= ecause although SMTP was a good enough technical solution, there were some = very serious technical problems with it that weren't considered, and these = problems came back to haunt us in a big way.=C2=A0 =C2=A0You could say the = same thing about BGP. And having had a week and a half to digest the BGP talk, the conclusion I'v= e come to is that there's a clear net win for RPKI here.=C2=A0 =C2=A0Yes, R= PKI makes it possible for governments to openly blockade peers they don't l= ike.=C2=A0 =C2=A0But when they do so, it will be public, and not something = that happened quietly in a room somewhere as a result of a failed trust rel= ationship that couldn't be enforced..=C2=A0 =C2=A0RPKI creates problems for= human rights, but they are problems that we can figure out how to deal wit= h.=C2=A0 =C2=A0Not using RPKI creates problems we can't deal with. _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1469670_395923877.1542348988201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1542292386499_34024">Ted,

> It frustrates me that you feel comforta= ble impugning the motives of IETF participants who really tried very hard t= o engage on this issue

I don't know what leads you to say that I am doing that.&nbs= p;  I am completely at a loss.   I have re-read what I wrote= and I do not think anything in what I wrote would lead to your statement.<= /span>
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= ">
I am quite = upset by what you are saying.  In the future, I think it is best to no= t respond to email threads from you.  It seems to lead to too much mis= understanding.   If at some point, you want to talk face to face,= I am always open to that.
 
Thanks,

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


From: Ted Lemon <mellon@fugue.com>
To: Nalini Elkins <nalini.elkins@i= nsidethestack.com>
Cc:<= /b> Mallory Knodel <mallory@article19.org>; Hrpc <hrpc@irtf.org>= ;
Sent: Thursday, Nove= mber 15, 2018 1:17 PM
Subject: Re: [hrpc] "We try to avoid"

I'm pretty sure that the motivation for keeping TLS secure is that it = benefits end users by preventing criminals (and businesses) from eavesdropp= ing on their connections.   That was certainly my motivation for = engaging in the discussion.   It frustrates me that you feel comf= ortable impugning the motives of IETF participants who really tried very ha= rd to engage on this issue and propose solutions that addressed the use cas= es that we were talking about.   It was very frustrating to simpl= y be told "no, you have to break your protocol for us because we won't use = that other protocol that actually addresses our use case and wouldn't break= TLS."

We may be wandering a bit off-topi= c, but in a sense this is an important discussion because when we get into = a calculus like this, human rights are very much at risk.

On Thu, Nov 15, 2018 at 3:59 PM Nalini = J Elkins <nalini.elkins@insidethestack.com> wrote:
Ted,

>Look at the discussion we had over TLS 1.3 back in Prague.   = There was a clear technical goal: make connections as secure as reasonably = >possible (I'm sure the TLS folks will heckle me for grossly oversimplif= ying=E2=80=94sorry!).   And there was a competing business goal: = allow me to >debug my network without retooling completely.   = The business goal lost not because it wasn't a real problem, but because it= was a business >problem, not a technical problem.   Of course= for the person dealing with the problem, it feels like a technical problem= , but ultimately >it's a problem because of the practices of the busines= s being affected by the added security of TLS 1.3, not because there's actu= ally a >technical problem with TLS 1.3.

Business problems are realities.  No one has unlimited funds.  I = know my daughter thinks that money grows on trees, but I would beg to diffe= r.

In another example, quite a few of our villages in India have only 2g. = ; This is due to economic realities.  We are trying to work with this = in protocol design. It is a reality of life where resources are not infinit= e.

I do not know if you have seen protocol changes / RFCs in certain working g= roups which are intended to advantage certain businesses or vendor products= .  I know I certainly have.  This is certainly business.

Some companies also send 50 or 100 people to the IETF.  This could be = because they are generous contributors to the common good.  I suspect = it is more likely because they find there is an economic advantage to be ga= ined by doing so.

Thanks,

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



________________________________
From: Ted Lemon <mellon@f= ugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.org>=
Sent: Thursday, November 15, 2018 7:20 AM
Subject: Re: [hrpc] "We try to avoid"



On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel <mallory@article19.org> wrote:

But just wondering, what is the original purpose of that statement?
>

Preventing unmanageable scope creep.   When you add business and = policy to the mix, it makes it a lot harder to get work done, because they = are matters of opinion, not fact, and competing interests will not be able = to reach consensus.

I think this is actually a useful thing for HRPC participants to be bearing= in mind:  to the extent that what we come with actually has clear pol= icy implications, it's going to be difficult to get consensus on it.

Look at the discussion we had over TLS 1.3 back in Prague.   Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying=E2= =80=94sorry!).   And there was a competing business goal: allow m= e to debug my network without retooling completely.   The busines= s goal lost not because it wasn't a real problem, but because it was a busi= ness problem, not a technical problem.   Of course for the person= dealing with the problem, it feels like a technical problem, but ultimatel= y it's a problem because of the practices of the business being affected by= the added security of TLS 1.3, not because there's actually a technical pr= oblem with TLS 1.3.

So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies.   In this case, it's pretty = clear (to me, of course!) that letting the right technical solution win was= better for human rights.   I think it's possible that this gener= alizes to some extent=E2=80=94my complaining about SMTP in the meeting is b= ecause although SMTP was a good enough technical solution, there were some = very serious technical problems with it that weren't considered, and these = problems came back to haunt us in a big way.   You could say the = same thing about BGP.

And having had a week and a half to digest the BGP talk, the conclusion I'v= e come to is that there's a clear net win for RPKI here.   Yes, R= PKI makes it possible for governments to openly blockade peers they don't l= ike.   But when they do so, it will be public, and not something = that happened quietly in a room somewhere as a result of a failed trust rel= ationship that couldn't be enforced..   RPKI creates problems for= human rights, but they are problems that we can figure out how to deal wit= h.   Not using RPKI creates problems we can't deal with.

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


------=_Part_1469670_395923877.1542348988201-- From nobody Thu Nov 15 22:21:09 2018 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 E33E7130E03 for ; Thu, 15 Nov 2018 22:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgNcqbCsDGiL for ; Thu, 15 Nov 2018 22:21:06 -0800 (PST) Received: from sonic314-28.consmr.mail.ne1.yahoo.com (sonic314-28.consmr.mail.ne1.yahoo.com [66.163.189.154]) (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 3E29A12426A for ; Thu, 15 Nov 2018 22:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542349265; bh=uMAxB8WCkKMdwU3aNl8plp/hRpGP5xb8gpqxLUAxjF8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=E6JxzMETegVZxgcMV3zOTd4QrilCFOHT9+3WQn9hZWeEXV8ib8N768nR4UFbCRGc5lVmoUR51yqM4IWez4ZwT448OKHp2RVc83ng9sWs1cX8VusTw2vjGievyGw3ZLla0huy5IDxyU6a3j9X9V0OXF/F7Ivyp7OvagiVeUi9bFLASB2lbSn3Gk7N33euGas+ZPWg3fXjds2HDgfvQLy2/M385TH6nYLV35Af6693jajgrwiGnjap7adSghydL12BKxT68/rJH9hSYqfUenUSQ/ryDgul8ckqActD0lf051HIfWtQpwP5GdCeDRd7oTYYlYr2UA0Bf7vvXUVwlBkHiw== X-YMail-OSG: fphmoJgVM1ntsAsGrKm1G2au5Jmk_yOtN25tqYqi_by5qtcZe7lhD9z2BIWOlfI OpjmD_hI6rxdAGXjMikG_6JLqgVuURulgrFN0UkHmkfJPRu5djJBZ85gMggWOUWrEAxbXv9h66iH TnRhW_jhpkFvdr.XYGkBBLvTGTriBI3vt4gbjUmY9S85cMLC9qLZcNsvwvbhld1Ydtsr6MuNeCc1 GAx.TCyM4G3SFmjo7XPjSNO3vF.yBmInG.rrFu3XMHpEkffgnpFsgQr42OyOKipXFN6ZjuaAojE5 270tUnBOkYZL9JWobVj9tyAMBa4ax54HD9e5vXSBoW1bErHN9V6F_YimAMD5iufPNKwIlXEB5raB rjEZFhLw3CVT7FinNWxwWcoT25yvJ3BqcR_SphSN5FlTHqtiasw1DUdkIJIYBykvXFTS41XvkmIM L8XUb4U1Jgyke5jwQPcTBNWWr_fvoDMqN99223uQ6Uw8ufHzDcQ6.97mVWz76VmoSvYYIyfhtFX9 .UmfVYZCgvYS59aDA4esdzUaTw_IFm1YruUoka_Wo1ytpR.ZAZVHVNuUSjjAdLG97Ph_9jovB7T_ KpGZAIbUKRYEL3GcJmPAu0C5nodplaL154LkfP763W8IwgKBIfyDxEP2ngoF2ykQPo4R3gKhe2IC Ek8uptS5B9ond_2jW3wNVNUvtrCclKpsVtgbtlynHCcqdnvF1hYfaBc3n0qF4hNF0Oy.aYeR22rq a5Zr3i3Zd6Wpi8I1oc2N5m7NYgNfkD3jb2O0TV3f3sl1AU5ZRkOL1wcAMBv.h2aPAed6JWaNwH3a o4ksmkODiuszYsOgerpqD4OQ1AvQIgbGfMW3Lhjl2OyrHUxGketLdAMO4xjAKRJDkxsZ.fCEde7U 0Lw1IPnObXwl7z8RQOOjIEpDG.vIdrk5N8VQnSr1KWiCWM54zrh6_ADIeVL3Ws5edMTuqjKxFy3b 8BzApU21Xi6gVLQcRV8924dMF4D304zviHFlbZmMdSoUjHZC8KINPThecZAt1LJ66S6QyaIhm_Sr jA99DahBNtW.sDHWZiOCI_8B3PwQH5gs8hSlEQXXR.d11ktva5Hxo_Ivs8LW69W0Ir0MS Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 06:21:05 +0000 Date: Fri, 16 Nov 2018 06:21:02 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: "Salz, Rich" , Fred Baker , Mark Perkins Cc: Mallory Knodel , Ted Lemon , Hrpc Message-ID: <165018031.1469955.1542349262429@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1E3F0BB8-2E9C-443D-AB22-539E7D88A19B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1469954_802062850.1542349262426" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 06:21:08 -0000 ------=_Part_1469954_802062850.1542349262426 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > I hope we are not going to consider Corporations as possessing human righ= ts. Have you so quickly forgotten Citizen's United?=C2=A0 Since corporations po= ssess free speech rights why should they not possess "human rights"? (Obviously a joke.)=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: "Salz, Rich" To: Fred Baker ; Mark Perkins =20 Cc: Mallory Knodel ; Ted Lemon ; H= rpc ; Nalini Elkins Sent: Thursday, November 15, 2018 2:59 PM Subject: Re: [hrpc] "We try to avoid" =20 The name of this RG is human rights. I hope we are not going to consider Corporations as possessing human rights= . =20 _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1469954_802062850.1542349262426 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ------=_Part_1469954_802062850.1542349262426-- From nobody Thu Nov 15 22:27:31 2018 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 EB6A8130E37 for ; Thu, 15 Nov 2018 22:27:29 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYQC-RZAdJKS for ; Thu, 15 Nov 2018 22:27:27 -0800 (PST) Received: from sonic314-28.consmr.mail.ne1.yahoo.com (sonic314-28.consmr.mail.ne1.yahoo.com [66.163.189.154]) (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 AA94312426A for ; Thu, 15 Nov 2018 22:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542349646; bh=XQi5svfHHrC6Fp30XXiW6R//83VwrU6Qm9wdJIa5eHE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=X3WSGaN0j7tiYCMgWfiggHqVxcrwUpgsU1vCoJqrde5DjdQI7pDjze3wewR/VRz1X8VT2HVb3SIMzJHCgAA+WBky/EQ0AR27G+U8H2LT+kinCpNaqIGqzwGaYXW3++sNHaGg+q5PhuLSjP6iE7SoG1zTmdUX2ypca18OlNKmbnxayqjIpMTmT2anNO9pLQraviZOzbtV5pxlbmujeP9Dd9JlWq1pDrUjmueSWM58cBvKOHIDQlHgG1ka/XVMqSgEmEuzHZ6ww+MxGGKZ30sAfAMMfCpY/SA3s8zayGWTugd/ug/CZiTjjoh38QABDcIOkiCNWT73CCQpJNRI2GWu3A== X-YMail-OSG: bM9DOVgVM1ldWM99_3bYx8E_GMuFUgeG2Y4wfKfJAUvx5m9faPHNAqYq1FW0a59 9dkQkF7zv8UZXEgTRU.46Sl1fYZwzs1Wzn5E3lx5jbUTrXhkjyxs0rHverHh9lbgLWAPV23LEnFn 4Ok.lKbLLA8cdi.W_f53Vy0HPJgqQsqrjtd66M7rOr0R85v6mc6uKVsV5AvxkdE_STlnf4IJIXjR FoddV.lEwzbpt3aaU.e75v1mhxezeGdN1t6yYHcBIbZoKIxB_dtZF1jATZklog4UfNoISUURr7LY SKXujsZ_BjMV.yEG_3_hzDMrJXzWNdy7mO5V3BAsRtb0X.RlEQJL.q6LraeD9iOz1Etp2dl3idQR VJZpE2d0qDTdNUIuZl4Vl316nT4wYruwlGYxsXSkNB8lsI0nPax7o_aB8A2MB1nViRDCnho1Ypnk um3g4sd8WBgFliklue8_nQ4ols5mAB1RNQxqNFxs.azoOn7Bvtxs0uHjy5hncSDP7LjFH.uzCOVk O7YAN0iOGltMlCE2etuB6xVzHBQL.yiE27LJsqnbiH.czsjpSo2UDcNKcMSOeRa1YqBcj7.7mMd4 PbdND8r2L8v3_nxWMPG_8TxMlfJ3X0.0vLzTvWAPFpWnDepb3gOzBnHim0XOhhv_SpZpN_dV8VvM uKj1k36O6Z0wMIoS.aV6Q8RkUby.FVQxnUNPy6yhDxpDu5LUpDsMkU3BGUJSQWU7248sB8bsXTgd og4U.q9VhwymnE9k7kw4tm1KZxojp5YDGc7C7KVI.Vjs52rPUJpwNOpjwekWmzMWswzqzCV4PpXK YKaaDjmRMrxsyZ6qBM9z3df7L4oIAxyXTLgPAH8aXHkTZNHu6jZdCLKMUlnJIdfgETpaaaNtLh1q QxOMfTxVbixjCYylAjwlP3S9BBw1Q99KBrm1xakNoaIJSFjgjy_a6oBiwXcuiWI6W.cvKwVnY6gE tq6TFENGHnsVTCwXMFSmcxTJWEOYvRPWo0HGobeVAcJwijEpzpbhiIQmaNjdzL0xF101t03IKLCY Kvu7sGG.zwy7GHTW1z2vMGspCkvM8MPPSHkQ3jZei Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 06:27:26 +0000 Date: Fri, 16 Nov 2018 06:27:13 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Mark Perkins , Ted Lemon , Mallory Knodel Cc: Hrpc Message-ID: <1745543794.1475888.1542349633202@mail.yahoo.com> In-Reply-To: <612735664.1327555.1542322105746@mail.yahoo.com> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 06:27:30 -0000 Mark, > I think you have 'hit the nail on the head'.. Thanks! . > on the other hand, large corporations can send large delegations, or beco= me generous donors, to advance their profit making & competitive situation = - Business Case B Yes, they *could*. But as someone who works with these corporations daily,= upper management does not always understand what problems the technicians = have. Also, there are pressures to make immediate quarterly profits vs. d= oing real long range planning. You may wish to read "Tailspin: The People = and Forces Behind America's Fifty-Year Fall--and Those Fighting to Reverse = It" by Steven Brill. It really illuminates some of the problems with the U= .S. economy. =20 It is in some ways the same problem as we have with our roads and infrastru= cture. For such a rich country, why are our bridges falling down? =20 We are working hard to show people the bigger picture and plan long term bu= t it is not easy. =20 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Mark Perkins To: Ted Lemon ; Mallory Knodel ; N= alini J Elkins =20 Cc: Hrpc Sent: Thursday, November 15, 2018 2:48 PM Subject: Re: [hrpc] "We try to avoid" Nalini I think you have 'hit the nail on the head'.. Yes, business problems are realities BUT business problems are not neutral = either.=20 As you state,=20 in some countries bandwidth is limited - Business Case A on the other hand, large corporations can send large delegations, or become= generous donors, to advance their profit making & competitive situation - = Business Case B I am sure we could come up with other business cases. Protocol design should be about 'end users', with 'business users' being se= en as intermediaries (important, but not ultimate). We should be VERY caref= ul in avoiding strengthening existing business players position against new= comers. Just because a new protocol creates a business problem FOR THEM is = no reason not to procede when the overall benefit to end users merits it. As always, the devil is in the details Mark P. On Friday, November 16, 2018, 7:59:55 AM GMT+11, Nalini J Elkins wrote:=20 Ted, >Look at the discussion we had over TLS 1.3 back in Prague. There was a c= lear technical goal: make connections as secure as reasonably >possible (I'= m sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94sor= ry!). And there was a competing business goal: allow me to >debug my netw= ork without retooling completely. The business goal lost not because it w= asn't a real problem, but because it was a business >problem, not a technic= al problem. Of course for the person dealing with the problem, it feels l= ike a technical problem, but ultimately >it's a problem because of the prac= tices of the business being affected by the added security of TLS 1.3, not = because there's actually a >technical problem with TLS 1.3. Business problems are realities. No one has unlimited funds. I know my da= ughter thinks that money grows on trees, but I would beg to differ. In another example, quite a few of our villages in India have only 2g. Thi= s is due to economic realities. We are trying to work with this in protoco= l design. It is a reality of life where resources are not infinite. I do not know if you have seen protocol changes / RFCs in certain working g= roups which are intended to advantage certain businesses or vendor products= . I know I certainly have. This is certainly business. Some companies also send 50 or 100 people to the IETF. This could be becau= se they are generous contributors to the common good. I suspect it is more= likely because they find there is an economic advantage to be gained by do= ing so. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Ted Lemon To: Mallory Knodel =20 Cc: Hrpc Sent: Thursday, November 15, 2018 7:20 AM Subject: Re: [hrpc] "We try to avoid" On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel wrot= e: But just wondering, what is the original purpose of that statement? > Preventing unmanageable scope creep. When you add business and policy to = the mix, it makes it a lot harder to get work done, because they are matter= s of opinion, not fact, and competing interests will not be able to reach c= onsensus. I think this is actually a useful thing for HRPC participants to be bearing= in mind: to the extent that what we come with actually has clear policy i= mplications, it's going to be difficult to get consensus on it. Look at the discussion we had over TLS 1.3 back in Prague. There was a cl= ear technical goal: make connections as secure as reasonably possible (I'm = sure the TLS folks will heckle me for grossly oversimplifying=E2=80=94sorry= !). And there was a competing business goal: allow me to debug my network= without retooling completely. The business goal lost not because it wasn= 't a real problem, but because it was a business problem, not a technical p= roblem. Of course for the person dealing with the problem, it feels like = a technical problem, but ultimately it's a problem because of the practices= of the business being affected by the added security of TLS 1.3, not becau= se there's actually a technical problem with TLS 1.3. So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies. In this case, it's pretty clear (to = me, of course!) that letting the right technical solution win was better fo= r human rights. I think it's possible that this generalizes to some exten= t=E2=80=94my complaining about SMTP in the meeting is because although SMTP= was a good enough technical solution, there were some very serious technic= al problems with it that weren't considered, and these problems came back t= o haunt us in a big way. You could say the same thing about BGP. And having had a week and a half to digest the BGP talk, the conclusion I'v= e come to is that there's a clear net win for RPKI here. Yes, RPKI makes = it possible for governments to openly blockade peers they don't like. But= when they do so, it will be public, and not something that happened quietl= y in a room somewhere as a result of a failed trust relationship that could= n't be enforced.. RPKI creates problems for human rights, but they are pr= oblems that we can figure out how to deal with. Not using RPKI creates pr= oblems we can't deal with. _______________________________________________ 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 From nobody Thu Nov 15 22:53:31 2018 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 B5A7F130DC2 for ; Thu, 15 Nov 2018 22:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 cZywJre2Ud4K for ; Thu, 15 Nov 2018 22:53:27 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 12DC3124D68 for ; Thu, 15 Nov 2018 22:53:27 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42x8825tZFzKKr for ; Fri, 16 Nov 2018 07:53:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542351202; bh=9ems+yxEcse+hQc2NmX6xM34ugEuZ7uiBALr/o5VK6g=; h=Date:From:To:Subject:In-Reply-To:References; b=dT8IIL/+r0jN9rUCsU8VBbP8EOmiof69pUMCzK58YUwqHl3pGm9emWvsjVGApiuUW 2WaVRbn4RJpaOhF/0pojt64YWJ1H03vjRMx9VwBuhFVpq8XTM6+fkETJhmd0gyRwM+ Hdorp/7/GSwXEPesox7ZwQSFoc5HbuEeY/jQtSII= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yv81RXBKz-qG for ; Fri, 16 Nov 2018 07:53:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 16 Nov 2018 07:53:19 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C20363A3788; Fri, 16 Nov 2018 01:53:18 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C20363A3788 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B3DD941C3B26 for ; Fri, 16 Nov 2018 01:53:18 -0500 (EST) Date: Fri, 16 Nov 2018 01:53:16 -0500 (EST) From: Paul Wouters To: Hrpc In-Reply-To: <1745543794.1475888.1542349633202@mail.yahoo.com> Message-ID: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 06:53:30 -0000 On Fri, 16 Nov 2018, Nalini J Elkins wrote: >> on the other hand, large corporations can send large delegations, or become generous donors, to advance their profit making & competitive situation - Business Case B > > Yes, they *could*. They did. We were lucky it did not change the outcome this time. > We are working hard to show people the bigger picture and plan long term but it is not easy. I think your suggestion that the TLS group did not "see the bigger picture" is quite wrong. It did see the bigger picture. It looked at the requirements of the enterprise, the requirement of endusers and the possible abuse of nation states, and concluded that the requirements for "enterprise TLS" were at fundemantal disagreement with enduser safety. It also concluded that everything needed for "enterprise customers" could be done without protocol changes, provided there was control of the enterprise user endpoint. It concluded the all proposed "enterprise" or "datacenter" solutions did nothing to ensure it was actually limited to that use case and could not be abused by nation states. What was left was only an argument of "ease of use and money". Frankly, I see this not as a problem but as an excellent opportunity for a new StartUp to deliver TLS1.3 enterprise monitoring support. As long as it is really "prohibitively expensive", there is an opportunity to make a LOT of money. So I simply do not buy the money argument. Let the next Cloudflare or Bluecoat or Palantir fix this. And the encumbents can then likely just buy that startup and make even more money. It is a win-win-win scenario for endusers, the free market and security. Paul From nobody Thu Nov 15 23:05:13 2018 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 E802A130DC8 for ; Thu, 15 Nov 2018 23:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 7QiDKq1TArGQ for ; Thu, 15 Nov 2018 23:05:07 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) (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 1EEC9124D68 for ; Thu, 15 Nov 2018 23:05:06 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id wAG741LU031134; Fri, 16 Nov 2018 02:04:04 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id wAG6jBi1010839; Fri, 16 Nov 2018 01:45:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23534.26487.474110.995164@gargle.gargle.HOWL> Date: Fri, 16 Nov 2018 01:45:11 -0500 From: bzs@theworld.com To: Nalini J Elkins Cc: Ted Lemon , Mallory Knodel , Hrpc In-Reply-To: <2132865692.1278206.1542315543815@mail.yahoo.com> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 07:05:11 -0000 Business and policy aspects are specialties. They tend to seem terribly subjective or arbitrary when people trained in, e.g., engineering try to do them or try to understand them without that specialized background. Yet a lot of the world still wants to understand, and is is obligated to deal with, those aspects of technical progress. And in the hands of those domain experts it generally isn't quite so subjective or arbitrary as they rely on a broad knowledge of precedent and their own forms of modeling etc. Many years ago when I worked in research in the dept of physiology, occupational health group, at the harvard school of public health we employed a full-time economist whose job it was to add his perspective to, for example, recommendations to limit occupational exposures. Because it's one thing to show an industrial exposure causes significant health problems -- what most of us there did for a living -- but quite a different thing to model the economic and policy issues mitigation would impose. Our findings often ended up in front of congress and big insurance agencies and affected businesses and they really wanted that whole picture. Occasionally the president of the US would call with some questions about relevant legislation he was being asked to sign. The IETF really has only two choices at this point in history, other than continuing to "wing" it: Either grow specialized arms to address these issues (much like this human rights group's intention), or allow others to do that which is likely to take the engineering aspect out of the equation as we've seen with important business and policy issues particularly of late. There's an old expression which goes: The only thing scarier than an electrical engineer writing software is a software engineer with a soldering iron (or similar.) We've reached a juncture where the only thing scarier than a network engineer trying to develop policy and business models for technical developments is policy and business people with jurisdiction over technical standards. Maybe it's a specialization which the IETF needs rather than this breast-beating over how distracting it can be for engineers et al to take responsibility for these aspects. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Fri Nov 16 01:22:17 2018 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 B155112D4E9 for ; Fri, 16 Nov 2018 01:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 072KvsvM3ozm for ; Fri, 16 Nov 2018 01:22:14 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 1F74D12896A for ; Fri, 16 Nov 2018 01:22:14 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id AA5636A357 for ; Fri, 16 Nov 2018 10:22:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542360131; bh=Wo8I8lni4cGzH0Qo/MT0bpo5KMKKY4Jo1K3niPFyxW4=; h=Date:From:To:In-Reply-To:References:Subject:From; b=9G6IBhxFyOq4HGQAMM/ZgX2UdEP1zacoTRiqt0v465hcfdgM7xs3fyaYpDfoXi87q PbDYPaRxkF3NrEv7chhgycuD2WcH17LR8v0xmT0kELJNb31d8qu4AvKgkxleHXxh9u 2momK3wusIknbRZdsY0AhuIZ+1fOeelvooWLJZvj9MnEnW02h7DSXBMAktomrV9yPy S9mY0Uc5hJGiXA3TM0oyE3VZt2y3Z5mm2CwhOSyypnpxVnGXgtlsZyUNl6U++TOC2L NKGBfboyDJpZGZrnIITbSsqxrcUTcaLaVHJIUcx+NPfzN/LQhn3olPc1cfDcCH1AB6 bKs5DEEZ8TYPQ== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id A2DB83C031A for ; Fri, 16 Nov 2018 10:22:11 +0100 (CET) Date: Fri, 16 Nov 2018 10:22:11 +0100 (CET) From: Vittorio Bertola To: Hrpc Message-ID: <99198595.14360.1542360131606@appsuite.open-xchange.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 09:22:16 -0000 > Il 16 novembre 2018 alle 7.53 Paul Wouters ha scritto: > > I think your suggestion that the TLS group did not "see the bigger > picture" is quite wrong. It did see the bigger picture. It looked at > the requirements of the enterprise, the requirement of endusers and the > possible abuse of nation states, and concluded that the requirements for > "enterprise TLS" were at fundemantal disagreement with enduser safety. It > also concluded that everything needed for "enterprise customers" could > be done without protocol changes, provided there was control of the > enterprise user endpoint. It concluded the all proposed "enterprise" > or "datacenter" solutions did nothing to ensure it was actually limited > to that use case and could not be abused by nation states. Well, the problem is that the distinction between technology and policy/business is artificial and often impossible to draw, as many technical choices have inherent economic and even political implications. Your reply about TLS illustrates this well: you say that this was a technical decision, and yet the statement that certain technical solutions were rejected by the IETF because they "could be abused by nation states" is deeply political: basically, the IETF is claiming the authority to judge what sovereign states do, define it as an abuse and take measures to prevent it from happening. Is there anything less technical and more political than this? In the end, I think that the distinction was naive at the time it was conceived (or better, the Internet environment then was so small, uniform and specialized that it was possible to only focus on technical arguments, an option that disappeared as soon as the Internet became the main mass communication platform for the planet) and is hypocritical now. Of course this does not apply to every IETF standard, perhaps not even to a majority of them, but there are instances where the new IETF standards fundamentally alter the structure of an existing market or the balancing of powers between States and Internet corporations, yet it is claimed that these are just technical decisions because technology is "objective" and so if you disagree you are just a bad engineer, rather than a stakeholder with different views and needs that should also be accommodated. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Nov 16 06:23:26 2018 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 C4E7C129BBF for ; Fri, 16 Nov 2018 06:23:25 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Tz0mRTVgRbE4 for ; Fri, 16 Nov 2018 06:23:21 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 8BEA1126BED for ; Fri, 16 Nov 2018 06:23:21 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id o89so37607676qko.0 for ; Fri, 16 Nov 2018 06:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z1ktWYIBs+6tsRh1zn23BclWxCreqt7eL7got6TLwCg=; b=XB2gFlaH7XA0vTlQTob/JBFw2mUH+/zDXFQ73aFB+xUMSZRmaaRgWReGEtoWcXMRYZ yp/w3Ve0k8lqDaik3GPIuNmRtBYVhCS3xSvqL3j7EwJmUESlLFPrwsPOkmAubEe5nG26 VOY9u0K7RVUyu6rpJ7xbu+mpZqHZ9X8A3XFWTctzd7BTDteGYtRCyupaY3JuYzF4PvJ6 Yl8iv1yR9VrZpa9wfdq8H/Acz8DIjqqsrgu9Mlv9PyztmbhL0xdTI/zE81RkufcIOBo5 QLCfVw9oH9V6Px6z+ip7lfliUUmTLPMhM+sDZLx5IaJC5hkbK7UsPYjgJfOPFzuWzWFw IH2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z1ktWYIBs+6tsRh1zn23BclWxCreqt7eL7got6TLwCg=; b=lOAyYxfFihkwHn02HdPxfTHN4XxhTxb7MlJk59hmkwIBExC60fNNB8aaf/stpY/pw1 6QwZzZ93NL7b50mGZjXnboaqJJq9UEeIJPhZOgdpFdIkFFKToAw5iJzWL8Qv2m0R1pRw CE/icZwoaMS4LvpDlm8xhGiW3mgT9mbhZD+S5TFgq/O+EkI5q/xJhkuSNrOAiq2TXlYe hHe9LsRLpbp2YYAU1Eiw6DVy+FDrrtyKvN3/+dwgwR/Ow2Bcf5iUhoBZhf+YclcaDyTa 2FHNTva0G7pkZsGQjPTDwCO3X7B8o1vIaMWDApV3G22RNuGz2O3n0qwZVGVAugRBNyce r6ww== X-Gm-Message-State: AGRZ1gLWgMSgArCKpF6HWIa+Fh+IUlxftEkSwQ156zWajSqEyPhSj0ta 8RdF1xmcRum+3Qjiaenc+D9cTPBgqYk6/1f0NTnTWggnghsupA== X-Google-Smtp-Source: AJdET5dgj1h0bqO8yMVj3WuxOpPj6frlfakogvuetGd/LrdGuEdkUTT8imMiTY3hUdH9eb8EJJV0rXXB3+gvwNrpzGY= X-Received: by 2002:aed:3286:: with SMTP id z6mr10314346qtd.203.1542378200318; Fri, 16 Nov 2018 06:23:20 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <1368964404.1469671.1542348988205@mail.yahoo.com> In-Reply-To: <1368964404.1469671.1542348988205@mail.yahoo.com> From: Ted Lemon Date: Fri, 16 Nov 2018 09:22:43 -0500 Message-ID: To: Nalini Elkins Cc: Mallory Knodel , Hrpc Content-Type: multipart/alternative; boundary="000000000000bd6698057ac8e81f" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:23:26 -0000 --000000000000bd6698057ac8e81f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You said this: Some companies also send 50 or 100 people to the IETF. This could be > because they are generous contributors to the common good. I suspect it = is > more likely because they find there is an economic advantage to be gained > by doing so. On Fri, Nov 16, 2018 at 1:16 AM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > Ted, > > > It frustrates me that you feel comfortable impugning the motives of IET= F > participants who really tried very hard to engage on this issue > > I don't know what leads you to say that I am doing that. I am completel= y > at a loss. I have re-read what I wrote and I do not think anything in > what I wrote would lead to your statement. > > I am quite upset by what you are saying. In the future, I think it is > best to not respond to email threads from you. It seems to lead to too > much misunderstanding. If at some point, you want to talk face to face,= I > am always open to that. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > ------------------------------ > *From:* Ted Lemon > *To:* Nalini Elkins > *Cc:* Mallory Knodel ; Hrpc > *Sent:* Thursday, November 15, 2018 1:17 PM > *Subject:* Re: [hrpc] "We try to avoid" > > I'm pretty sure that the motivation for keeping TLS secure is that it > benefits end users by preventing criminals (and businesses) from > eavesdropping on their connections. That was certainly my motivation fo= r > engaging in the discussion. It frustrates me that you feel comfortable > impugning the motives of IETF participants who really tried very hard to > engage on this issue and propose solutions that addressed the use cases > that we were talking about. It was very frustrating to simply be told > "no, you have to break your protocol for us because we won't use that oth= er > protocol that actually addresses our use case and wouldn't break TLS." > > We may be wandering a bit off-topic, but in a sense this is an important > discussion because when we get into a calculus like this, human rights ar= e > very much at risk. > > On Thu, Nov 15, 2018 at 3:59 PM Nalini J Elkins < > nalini.elkins@insidethestack.com> wrote: > > Ted, > > >Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably >possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to >debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > >problem, not a technical problem. Of course for the person dealing wit= h > the problem, it feels like a technical problem, but ultimately >it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, not because there's actually a >technical > problem with TLS 1.3. > > Business problems are realities. No one has unlimited funds. I know my > daughter thinks that money grows on trees, but I would beg to differ. > > In another example, quite a few of our villages in India have only 2g. > This is due to economic realities. We are trying to work with this in > protocol design. It is a reality of life where resources are not infinite= . > > I do not know if you have seen protocol changes / RFCs in certain working > groups which are intended to advantage certain businesses or vendor > products. I know I certainly have. This is certainly business. > > Some companies also send 50 or 100 people to the IETF. This could be > because they are generous contributors to the common good. I suspect it = is > more likely because they find there is an economic advantage to be gained > by doing so. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ________________________________ > From: Ted Lemon > To: Mallory Knodel > Cc: Hrpc > Sent: Thursday, November 15, 2018 7:20 AM > Subject: Re: [hrpc] "We try to avoid" > > > > On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel > wrote: > > But just wondering, what is the original purpose of that statement? > > > > Preventing unmanageable scope creep. When you add business and policy t= o > the mix, it makes it a lot harder to get work done, because they are > matters of opinion, not fact, and competing interests will not be able to > reach consensus. > > I think this is actually a useful thing for HRPC participants to be > bearing in mind: to the extent that what we come with actually has clear > policy implications, it's going to be difficult to get consensus on it. > > Look at the discussion we had over TLS 1.3 back in Prague. There was a > clear technical goal: make connections as secure as reasonably possible > (I'm sure the TLS folks will heckle me for grossly > oversimplifying=E2=80=94sorry!). And there was a competing business goa= l: allow > me to debug my network without retooling completely. The business goal > lost not because it wasn't a real problem, but because it was a business > problem, not a technical problem. Of course for the person dealing with > the problem, it feels like a technical problem, but ultimately it's a > problem because of the practices of the business being affected by the > added security of TLS 1.3, not because there's actually a technical probl= em > with TLS 1.3. > > So when we think about how the wording of this text implicates the work > being done in HRPC, it would be good to be very careful not to jump to > conclusions about what the wording implies. In this case, it's pretty > clear (to me, of course!) that letting the right technical solution win w= as > better for human rights. I think it's possible that this generalizes to > some extent=E2=80=94my complaining about SMTP in the meeting is because a= lthough > SMTP was a good enough technical solution, there were some very serious > technical problems with it that weren't considered, and these problems ca= me > back to haunt us in a big way. You could say the same thing about BGP. > > And having had a week and a half to digest the BGP talk, the conclusion > I've come to is that there's a clear net win for RPKI here. Yes, RPKI > makes it possible for governments to openly blockade peers they don't > like. But when they do so, it will be public, and not something that > happened quietly in a room somewhere as a result of a failed trust > relationship that couldn't be enforced.. RPKI creates problems for huma= n > rights, but they are problems that we can figure out how to deal with. > Not using RPKI creates problems we can't deal with. > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > > > --000000000000bd6698057ac8e81f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You said this:

Some companies also send 50 or 100 people to the IETF.= =C2=A0 This could be because they are generous contributors to the common g= ood.=C2=A0 I suspect it is more likely because they find there is an econom= ic advantage to be gained by doing so.

On Fri, Nov 16, 2018 at 1:16 AM Nalini J Elki= ns <nalini.elkins@in= sidethestack.com> wrote:
Ted,
> It frustrates me that you feel comfortable impugning the mot= ives of IETF participants who really tried very hard to engage on this issu= e

I don't know what leads you t= o say that I am doing that.=C2=A0 =C2=A0I am completely at a loss.=C2=A0 = =C2=A0I have re-read what I wrote and I do not think anything in what I wro= te would lead to your statement.

<= font face=3D"Helvetica Neue, Segoe UI, Helvetica, Arial, Lucida Grande, san= s-serif" id=3D"m_-5202833483195975201yui_3_16_0_ym19_1_1542292386499_34250"= >I am quite upset by what you are saying.=C2=A0 In t= he future, I think it is best to not respond to email threads from you.=C2= =A0 It seems to lead to too much misunderstanding.=C2=A0 =C2=A0If at some p= oint, you want to talk face to face, I am always open to that.
=C2=A0
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com=
(831) 659-8360

=
From: Ted L= emon <mellon@fugue= .com>
To: Nalini = Elkins <nalini.elkins@insidethestack.com>
Cc: Mallory Knodel <mallory@article19.org>; Hrpc <hrpc@irtf.org>
= Sent: Thursday, November 15, 20= 18 1:17 PM
Subject: Re: = [hrpc] "We try to avoid"

I'm pretty sure that the motivation for keeping TLS secu= re is that it benefits end users by preventing criminals (and businesses) f= rom eavesdropping on their connections.=C2=A0 =C2=A0That was certainly my m= otivation for engaging in the discussion.=C2=A0 =C2=A0It frustrates me that= you feel comfortable impugning the motives of IETF participants who really= tried very hard to engage on this issue and propose solutions that address= ed the use cases that we were talking about.=C2=A0 =C2=A0It was very frustr= ating to simply be told "no, you have to break your protocol for us be= cause we won't use that other protocol that actually addresses our use = case and wouldn't break TLS."

We= may be wandering a bit off-topic, but in a sense this is an important disc= ussion because when we get into a calculus like this, human rights are very= much at risk.

On Thu, Nov 15, 2018 at 3:59 PM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
Ted,
>Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0= There was a clear technical goal: make connections as secure as reasonably = >possible (I'm sure the TLS folks will heckle me for grossly oversim= plifying=E2=80=94sorry!).=C2=A0 =C2=A0And there was a competing business go= al: allow me to >debug my network without retooling completely.=C2=A0 = =C2=A0The business goal lost not because it wasn't a real problem, but = because it was a business >problem, not a technical problem.=C2=A0 =C2= =A0Of course for the person dealing with the problem, it feels like a techn= ical problem, but ultimately >it's a problem because of the practice= s of the business being affected by the added security of TLS 1.3, not beca= use there's actually a >technical problem with TLS 1.3.

Business problems are realities.=C2=A0 No one has unlimited funds.=C2=A0 I = know my daughter thinks that money grows on trees, but I would beg to diffe= r.

In another example, quite a few of our villages in India have only 2g.=C2= =A0 This is due to economic realities.=C2=A0 We are trying to work with thi= s in protocol design. It is a reality of life where resources are not infin= ite.

I do not know if you have seen protocol changes / RFCs in certain working g= roups which are intended to advantage certain businesses or vendor products= .=C2=A0 I know I certainly have.=C2=A0 This is certainly business.

Some companies also send 50 or 100 people to the IETF.=C2=A0 This could be = because they are generous contributors to the common good.=C2=A0 I suspect = it is more likely because they find there is an economic advantage to be ga= ined by doing so.

Thanks,

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



________________________________
From: Ted Lemon <mellon@fugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.org>
Sent: Thursday, November 15, 2018 7:20 AM
Subject: Re: [hrpc] "We try to avoid"



On Thu, Nov 15, 2018 at 2:50 AM Mallory Knodel <mallory@= article19.org> wrote:

But just wondering, what is the original purpose of that statement?
>

Preventing unmanageable scope creep.=C2=A0 =C2=A0When you add business and = policy to the mix, it makes it a lot harder to get work done, because they = are matters of opinion, not fact, and competing interests will not be able = to reach consensus.

I think this is actually a useful thing for HRPC participants to be bearing= in mind:=C2=A0 to the extent that what we come with actually has clear pol= icy implications, it's going to be difficult to get consensus on it.
Look at the discussion we had over TLS 1.3 back in Prague.=C2=A0 =C2=A0Ther= e was a clear technical goal: make connections as secure as reasonably poss= ible (I'm sure the TLS folks will heckle me for grossly oversimplifying= =E2=80=94sorry!).=C2=A0 =C2=A0And there was a competing business goal: allo= w me to debug my network without retooling completely.=C2=A0 =C2=A0The busi= ness goal lost not because it wasn't a real problem, but because it was= a business problem, not a technical problem.=C2=A0 =C2=A0Of course for the= person dealing with the problem, it feels like a technical problem, but ul= timately it's a problem because of the practices of the business being = affected by the added security of TLS 1.3, not because there's actually= a technical problem with TLS 1.3.

So when we think about how the wording of this text implicates the work bei= ng done in HRPC, it would be good to be very careful not to jump to conclus= ions about what the wording implies.=C2=A0 =C2=A0In this case, it's pre= tty clear (to me, of course!) that letting the right technical solution win= was better for human rights.=C2=A0 =C2=A0I think it's possible that th= is generalizes to some extent=E2=80=94my complaining about SMTP in the meet= ing is because although SMTP was a good enough technical solution, there we= re some very serious technical problems with it that weren't considered= , and these problems came back to haunt us in a big way.=C2=A0 =C2=A0You co= uld say the same thing about BGP.

And having had a week and a half to digest the BGP talk, the conclusion I&#= 39;ve come to is that there's a clear net win for RPKI here.=C2=A0 =C2= =A0Yes, RPKI makes it possible for governments to openly blockade peers the= y don't like.=C2=A0 =C2=A0But when they do so, it will be public, and n= ot something that happened quietly in a room somewhere as a result of a fai= led trust relationship that couldn't be enforced..=C2=A0 =C2=A0RPKI cre= ates problems for human rights, but they are problems that we can figure ou= t how to deal with.=C2=A0 =C2=A0Not using RPKI creates problems we can'= t deal with.

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


> I hope we are not going t= o consider Corporations as possessing human rights.

Have you so quickly forg= otten Citizen's United?  Since corporations possess free speech rights= why should they not possess "human rights"?

(Obv= iously a joke.)
 
Thanks,

Nalini Elkins
CEO and FounderInside Products, Inc.
www.insidethestack.com
(831) 659-8360

=
From: "Salz, Rich" <rsalz@akamai.com&g= t;
To: Fred Baker <= fredbaker.ietf@gmail.com>; Mark Perkins <marknoumea=3D40yahoo.com@dma= rc.ietf.org>
Cc: Ma= llory Knodel <mallory@article19.org>; Ted Lemon <mellon@fugue.com&= gt;; Hrpc <hrpc@irtf.org>; Nalini Elkins <nalini.elkins@insidethes= tack.com>
Sent: Thu= rsday, November 15, 2018 2:59 PM
= Subject: Re: [hrpc] "We try to avoid"

The name of this RG is human r= ights.

I hope we are not going to cons= ider Corporations as possessing human rights.



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


--000000000000bd6698057ac8e81f-- From nobody Fri Nov 16 06:35:24 2018 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 A33C9130E7F for ; Fri, 16 Nov 2018 06:35:22 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 2yAKMSSq8BG1 for ; Fri, 16 Nov 2018 06:35:20 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 B324B130DD4 for ; Fri, 16 Nov 2018 06:35:19 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id d135so37633145qkc.12 for ; Fri, 16 Nov 2018 06:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Af3XST+Zx8kkMvkusiskkWTAjB2ogWw+/ut6QlytK1o=; b=vZRUWOtH+VzY2uPpt3GLh8sNUdMGZSKk0WuhebSNYX3rVP2BWeHjkj3fdEDJ72W/8C X3fgVflV42AKmQBUVnTyca63IqIquZaHjs8D/kETPWYJ0ptf7BP1PNMIwjJgnxMe5nha 9mVbmhjCuQyZBlVLOAFgPdJVhBOaCc9VrRFhRx1V8CF/uz5imLY9Sfjkyyny/27j6tvf mP9M+qE3LXBjJhmjZxrLgvcCnxTqzTUA4+D8YWReQ4hAv6BmwVU/FNsG24F3pPPq5QT5 04KrAo7dtn4qz0VGT0/gQpJJ//ZTNo2GTIa/2tW6lK7amLv62dfypalTA241aQMD1jSH C4Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Af3XST+Zx8kkMvkusiskkWTAjB2ogWw+/ut6QlytK1o=; b=jANTbAV4cums/uh7ADVtJyk1RlDwdPxAozC12jV7M7TrXlxJnpGcCRiCaKji4gUKip u7A9/9AEvHq+pFQJDUH1ET6GCjouILY4i77eKAqrK+jS5PQyxPrdUIiOtVMjXzkIZQo7 lW3MPh72pHA0sWOdFqAN2+7bWmGCCn9/rjiPIzDRqcSQjpKADU+wDxAou6DvAemIoHun 2dGyWOAoRMlyT/eDdoYO2hBKOGiM/HRZjmRz5gID845DC1iXwyx5udAvS96AMwcPdDy2 ENJFTul0XJFEOmsbXysNgke6ViqcM3Yc49ZrFDu221iSMgCPiL6j+YFdXU/nbZfIzkZy lr7A== X-Gm-Message-State: AGRZ1gIa4CgtZr8uMHzUN2ETLPC4Fb2eoldC+2OwqOsada268AGdrgP5 vEFp0tKIgfajiROyC52yK6cmL//V0zcLpvpKRU1Lcg== X-Google-Smtp-Source: AJdET5cuW9s9S0KkIILzIFpZAM8Pbhbkdqlf7J0jdXXSYk6kLDbnHfLQ13m7JXumu3/r475Tjx7tRm/MvBu1XMtNeo4= X-Received: by 2002:ac8:7518:: with SMTP id u24mr10543097qtq.75.1542378918738; Fri, 16 Nov 2018 06:35:18 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <99198595.14360.1542360131606@appsuite.open-xchange.com> In-Reply-To: <99198595.14360.1542360131606@appsuite.open-xchange.com> From: Ted Lemon Date: Fri, 16 Nov 2018 09:34:42 -0500 Message-ID: To: Vittorio Bertola Cc: Hrpc Content-Type: multipart/alternative; boundary="0000000000008f96bc057ac913fc" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:35:23 -0000 --0000000000008f96bc057ac913fc Content-Type: text/plain; charset="UTF-8" The certain technical aspects of the plan to break TLS to which you refer were rejected because they allow *anyone* to break TLS. You are adding "nation states" to make it political, but nation states are just one example of who can use a broken TLS to violate users' rights. My personal worry is not nation states but identity thieves. And again this illustrates the principle nicely. Because we were arguing over a technical point, people who are afraid of nation-state eavesdropping can agree with people who are afraid of getting ripped off by scammers. The principle is the same regardless of what is is that you fear. By comparison, for example, the ability to eavesdrop has valuable societal benefits in terms of preventing and exposing criminal activity. How would the IETF decide which good to promote and which to reject? The answer is that we would not, and can not. As a policy, the IETF doesn't develop protocols for the purpose of eavesdropping, not so much because we don't think it's a good idea, although certainly many of us don't, but because it's not a problem with a technical solution. There is no way to have a secure transport that enables eavesdropping, any more than you can find a piece of ordinary matter that will levitate itself out of a gravity well. On Fri, Nov 16, 2018 at 4:22 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > > > Il 16 novembre 2018 alle 7.53 Paul Wouters ha scritto: > > > > I think your suggestion that the TLS group did not "see the bigger > > picture" is quite wrong. It did see the bigger picture. It looked at > > the requirements of the enterprise, the requirement of endusers and the > > possible abuse of nation states, and concluded that the requirements for > > "enterprise TLS" were at fundemantal disagreement with enduser safety. It > > also concluded that everything needed for "enterprise customers" could > > be done without protocol changes, provided there was control of the > > enterprise user endpoint. It concluded the all proposed "enterprise" > > or "datacenter" solutions did nothing to ensure it was actually limited > > to that use case and could not be abused by nation states. > > Well, the problem is that the distinction between technology and > policy/business is artificial and often impossible to draw, as many > technical choices have inherent economic and even political implications. > Your reply about TLS illustrates this well: you say that this was a > technical decision, and yet the statement that certain technical solutions > were rejected by the IETF because they "could be abused by nation states" > is deeply political: basically, the IETF is claiming the authority to judge > what sovereign states do, define it as an abuse and take measures to > prevent it from happening. Is there anything less technical and more > political than this? > > In the end, I think that the distinction was naive at the time it was > conceived (or better, the Internet environment then was so small, uniform > and specialized that it was possible to only focus on technical arguments, > an option that disappeared as soon as the Internet became the main mass > communication platform for the planet) and is hypocritical now. Of course > this does not apply to every IETF standard, perhaps not even to a majority > of them, but there are instances where the new IETF standards fundamentally > alter the structure of an existing market or the balancing of powers > between States and Internet corporations, yet it is claimed that these are > just technical decisions because technology is "objective" and so if you > disagree you are just a bad engineer, rather than a stakeholder with > different views and needs that should also be accommodated. > > Regards, > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --0000000000008f96bc057ac913fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The certain technical aspects of the plan to break TLS to = which you refer were rejected because they allow anyone=C2=A0to brea= k TLS.=C2=A0 =C2=A0You are adding "nation states" to make it poli= tical, but nation states are just one example of who can use a broken TLS t= o violate users' rights.=C2=A0 =C2=A0My personal worry is not nation st= ates but identity thieves.=C2=A0 =C2=A0And again this illustrates the princ= iple nicely.=C2=A0 =C2=A0Because we were arguing over a technical point, pe= ople who are afraid of nation-state eavesdropping can agree with people who= are afraid of getting ripped off by scammers.=C2=A0 =C2=A0The principle is= the same regardless of what is is that you fear.

By com= parison, for example, the ability to eavesdrop has valuable societal benefi= ts in terms of preventing and exposing criminal activity.=C2=A0 =C2=A0How w= ould the IETF decide which good to promote and which to reject?=C2=A0 =C2= =A0The answer is that we would not, and can not.=C2=A0 =C2=A0As a policy, t= he IETF doesn't develop protocols for the purpose of eavesdropping, not= so much because we don't think it's a good idea, although certainl= y many of us don't, but because it's not a problem with a technical= solution.=C2=A0 =C2=A0There is no way to have a secure transport that enab= les eavesdropping, any more than you can find a piece of ordinary matter th= at will levitate itself out of a gravity well.



> Il 16 novembre 2018 alle 7.53 Paul Wouters <paul@nohats.ca> ha scritto:
>
> I think your suggestion that the TLS group did not "see the bigge= r
> picture" is quite wrong. It did see the bigger picture. It looked= at
> the requirements of the enterprise, the requirement of endusers and th= e
> possible abuse of nation states, and concluded that the requirements f= or
> "enterprise TLS" were at fundemantal disagreement with endus= er safety. It
> also concluded that everything needed for "enterprise customers&q= uot; could
> be done without protocol changes, provided there was control of the > enterprise user endpoint. It concluded the all proposed "enterpri= se"
> or "datacenter" solutions did nothing to ensure it was actua= lly limited
> to that use case and could not be abused by nation states.

Well, the problem is that the distinction between technology and policy/bus= iness is artificial and often impossible to draw, as many technical choices= have inherent economic and even political implications. Your reply about T= LS illustrates this well: you say that this was a technical decision, and y= et the statement that certain technical solutions were rejected by the IETF= because they "could be abused by nation states" is deeply politi= cal: basically, the IETF is claiming the authority to judge what sovereign = states do, define it as an abuse and take measures to prevent it from happe= ning. Is there anything less technical and more political than this?

In the end, I think that the distinction was naive at the time it was conce= ived (or better, the Internet environment then was so small, uniform and sp= ecialized that it was possible to only focus on technical arguments, an opt= ion that disappeared as soon as the Internet became the main mass communica= tion platform for the planet) and is hypocritical now. Of course this does = not apply to every IETF standard, perhaps not even to a majority of them, b= ut there are instances where the new IETF standards fundamentally alter the= structure of an existing market or the balancing of powers between States = and Internet corporations, yet it is claimed that these are just technical = decisions because technology is "objective" and so if you disagre= e you are just a bad engineer, rather than a stakeholder with different vie= ws and needs that should also be accommodated.

Regards,
--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vitt= orio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--0000000000008f96bc057ac913fc-- From nobody Fri Nov 16 06:36:22 2018 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 D0398130ED0 for ; Fri, 16 Nov 2018 06:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, T_SPF_PERMERROR=0.01] 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 bKOeDyzkfrVi for ; Fri, 16 Nov 2018 06:36:19 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDC3130DD4 for ; Fri, 16 Nov 2018 06:36:19 -0800 (PST) Received: from fifthhorseman.net (NYUFWA-GUESTS-01.NATPOOL.NYU.EDU [192.76.177.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 60CEBF99F for ; Fri, 16 Nov 2018 09:36:15 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 20F7D2076D; Fri, 16 Nov 2018 09:30:49 -0500 (EST) From: Daniel Kahn Gillmor To: Hrpc In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> Date: Fri, 16 Nov 2018 09:30:45 -0500 Message-ID: <87k1ldqelm.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:36:21 -0000 --=-=-= Content-Type: text/plain On Thu 2018-11-15 16:10:27 -0500, Ted Lemon wrote: > This is *precisely* why we say that the IETF's purpose is not to get > involved in that calculus. It's simply out of our possible scope. I think this thread is fascinating. IETF decisions (TLS 1.3 forward secrecy is just one example) very often do have business and policy implications, as this thread alone has clearly indicated. So we "do" business and policy whether we want to pretend we do it or not. I disagree with Ted that the TLS 1.3 forward secrecy decision came down to business/policy on one side and technical decisions on the other. There were mutually-exclusive policy and technical arguments on both sides, and we made a collective decision about which policy and technical arguments were more important. I think that the text Stephane cites (if it says anything meaningful at all) says "don't expect us to come to consensus about business or policy decisions", probably because we know that's basically impossible given the range of competing perspectives and values that we hope will provide concrete input to the IETF processes. But we're making decisions about what structural choices are *possible* on the largest-scale global communications infrastructure available. And we're making decisions that often guide what becomes *common* in that same infrastructure. So of course those decisions have business and policy implications. I think it's better that we can make these decisions keeping this fact in mind, instead of wishing it away or pretending that it ain't so. But i also understand that the engineering community has a storied history of claiming that its work is "technical and apolitical" (up until the point that it claims that it is "revolutionary"), and that's a tough habit to break. just for fun i'll try proposing some (probably terrible) alternate text to see whether that makes things more clear. We try to avoid policy and business questions, as much as possible. I'd turn it into something like: The IETF's work inevitably has business and policy implications, which we struggle with. We appreciate when people raise those concerns as clearly as possible while simultaneously addressing the mechanical and technical impact of their preferred solutions. All the best, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCW+7UlgAKCRBsHx7ezFD6 UyUBAP9eExBgVTkX8oO4LwuX/CMthqedjOp1L9akNTymczYE8wEAie5ICSaZB/HB eiIfoREjTgBV3s+1wanQklXAYueGeQg= =jJlB -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 16 06:45:09 2018 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 67DF1126DBF for ; Fri, 16 Nov 2018 06:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5dKkNiyDHyY for ; Fri, 16 Nov 2018 06:45:03 -0800 (PST) Received: from sonic314-26.consmr.mail.ne1.yahoo.com (sonic314-26.consmr.mail.ne1.yahoo.com [66.163.189.152]) (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 B7599128D68 for ; Fri, 16 Nov 2018 06:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542379501; bh=orD4s9w+HBUa1AhVqnrcZqqhkTJbpf0qWGxkmSF4ZTU=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=a056tHslUl+AoyytmwsOcW5jsetndq8F3Eko99mT67wW22KswG2+qoT0nBupCE/ETQb7YaAtohNrBuyuQKhZMeWPHUH/c5EJB/T1yDzb0ydgK3j19wEsNpF+S3RLbeMVjLXsXxqKKZD/ClMlFm7eSDeVJJaZcDILKIxkSKAPUmkwoL8/kc5Y6cT1ilPccnGuqZMvX21oNOM0ba6mxEzwa25qZE3tKRsDe7FD0dvz9yq2qXlfEdZpwt/26RpFlj/l0Tvu+p4ICSPbkpcDgJEQNKnsZ3t2GUF/PqZhwcVqo2SVke51ZmDeaf03EionYY/BXD+7tZWJd3WHKL/PA6FFFw== X-YMail-OSG: LmKAZM8VM1nG8ogi2pJHU1ReE38vx1Aylh4Jpaw7GG9XPr9ouOP.GTrGUgeE6SC Ii9aVP4VrOqrOYaP1QjcVcNdpSNr0XzhrAFr3J8KMGF1rv3WjBjCJuGNckFC8O_2WKc2P3k7c9Zu BBGMEu1TE6pyBj7PYWuE8ymEOJ_dKXhKRLuFmur6Tx0_qW8sc0wW15ZfysdxZq_kXlxDdx0TJu_5 HgxR8N3Stmloh3Xm_Sa2BgN5fDhCmPiIBn0MB4lKviF_QLryf7UF5ynzan3kLDCGucYAT6sGq6Yd NZp3983IVR9rLLC8i.Rnb07bLLIIikG_KfJ6zqx9N6v41f8ROQZJTWgOeATABCw0pBiGVMEiHO7Q DqFmUWRm4xWZblIcOSOwb4RrCKs4A.sz4fDB5YhtXPflzdX8NxS.543SQlLkTPWfqac7WdcL8T.R hOaW0ojOdMtATG_.BOvDMUU3LBdDF1VZfrovkrNH8.I_BqpqZxBn4IKtlzIPQT7Yu2zpb8h_f9IZ PH3bI0VxC83sYOOoWSu6g3ypyOoEoqWLGKgVgz.FpsNuBSSVUvJnAia4kQGKK13jAJQG.LnGlj35 fog3BA.ltckNGJBMu4tUopwcL2aBKJYxjv8idfmA8W.eymz0trZrAypQVXCH_OA6kl1VToLhOMe0 kPMtDXaG.5taL1SUJo0pO8DiH9m2C4Rcu9C6pg9AXaKE7senwAh9CzMQDXyKDIqQ_rQAdvY3hcyZ uc.x3n8ZoQUsUTLsuIjp.UasbNIEYXk3of6HwispPDSLmQPQnT4oo_kMK30NEAdKsMYQLZj9yy.7 pQq02jDwRfW_X.pw8fnusAvv3D5M.m1g5YpI.73rufW8LUQFAnQzOpDkMWam28QCE9B4qLGY2umt ATlKP4VKPK_hV12lvzOXmLW.dZ5bWL75cBLkXrG6A4UrgT759ijcKZjQuVKA1AtP7YzckMVw9rFR BvkE1StacLoeVmTRebpQ10dHGFnVd5fJ74oCG8dHUkvJy6AfE5jcM7_YEqaZKE2i4VXSzu8XTEnH 7XAkIcvtlifbBzHmbdE2Olsld68x.nAajUBu71lZC6C6zvDQG2NUl.mr8QSjpQlIZ.g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 14:45:01 +0000 Date: Fri, 16 Nov 2018 14:44:58 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Paul Wouters , Hrpc Message-ID: <1845585316.1607419.1542379498804@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1607418_95673553.1542379498802" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:45:06 -0000 ------=_Part_1607418_95673553.1542379498802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > We are working hard to show people the bigger picture and plan long term = but it is not easy. By "people", I=C2=A0meant the management of large enterprises, not the TLS = WG.=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Paul Wouters To: Hrpc =20 Sent: Thursday, November 15, 2018 10:53 PM Subject: Re: [hrpc] "We try to avoid" =20 On Fri, 16 Nov 2018, Nalini J Elkins wrote: >> on the other hand, large corporations can send large delegations, or bec= ome generous donors, to advance their profit making & competitive situation= - Business Case B > > Yes, they *could*. They did. We were lucky it did not change the outcome this time. > We are working hard to show people the bigger picture and plan long term = but it is not easy. I think your suggestion that the TLS group did not "see the bigger picture" is quite wrong. It did see the bigger picture. It looked at the requirements of the enterprise, the requirement of endusers and the possible abuse of nation states, and concluded that the requirements for "enterprise TLS" were at fundemantal disagreement with enduser safety. It also concluded that everything needed for "enterprise customers" could be done without protocol changes, provided there was control of the enterprise user endpoint. It concluded the all proposed "enterprise" or "datacenter" solutions did nothing to ensure it was actually limited to that use case and could not be abused by nation states. What was left was only an argument of "ease of use and money". Frankly, I see this not as a problem but as an excellent opportunity for a new StartUp to deliver TLS1.3 enterprise monitoring support. As long as it is really "prohibitively expensive", there is an opportunity to make a LOT of money. So I simply do not buy the money argument. Let the next Cloudflare or Bluecoat or Palantir fix this. And the encumbents can then likely just buy that startup and make even more money. It is a win-win-win scenario for endusers, the free market and security. Paul _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1607418_95673553.1542379498802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1542379344871_13036">> We are working hard to = show people the bigger picture and plan long term but it is not easy.

By "people", I meant the management of la= rge enterprises, not the TLS WG.
 
Thanks,

Nalini Elkins
CEO a= nd Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-= 8360


= From: Paul Wouters <paul= @nohats.ca>
To: Hrp= c <hrpc@irtf.org>
Sent: Thursday, November 15, 2018 10:53 PM
Subject: Re: [hrpc] "We try to avoid"
 <= /div>

On= Fri, 16 Nov 2018, Nalini J Elkins wrote:

>> on the other hand, large corporations can send large delegatio= ns, or become generous donors, to advance their profit making & competi= tive situation - Business Case B
>
&= gt; Yes, they *could*.

They did. We we= re lucky it did not change the outcome this time.

> We are working hard to show people the bigger picture and = plan long term but it is not easy.

I t= hink your suggestion that the TLS group did not "see the bigger
picture" is quite wrong. It did see the bigger picture. It looked at=
the requirements of the enterprise, the requirement of e= ndusers and the
possible abuse of nation states, and conc= luded that the requirements for
"enterprise TLS" were at = fundemantal disagreement with enduser safety. It
also con= cluded that everything needed for "enterprise customers" could
be done without protocol changes, provided there was control of theenterprise user endpoint. It concluded the all proposed "e= nterprise"
or "datacenter" solutions did nothing to ensur= e it was actually limited
to that use case and could not = be abused by nation states.

What was l= eft was only an argument of "ease of use and money". Frankly,
I see this not as a problem but as an excellent opportunity for a new<= br clear=3D"none">StartUp to deliver TLS1.3 enterprise monitoring support. = As long as it
is really "prohibitively expensive", there = is an opportunity to make a
LOT of money. So I simply do = not buy the money argument. Let the next
Cloudflare or Bl= uecoat or Palantir fix this. And the encumbents can
then = likely just buy that startup and make even more money. It is a
win-win-win scenario for endusers, the free market and security.

Paul


____________________________= ___________________
hrpc mailing list
<= a shape=3D"rect" ymailto=3D"mailto:hrpc@irtf.org" href=3D"mailto:hrpc@irtf.= org">hrpc@irtf.org
https://www.irtf.org/= mailman/listinfo/hrpc


------=_Part_1607418_95673553.1542379498802-- From nobody Fri Nov 16 06:47:12 2018 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 C4EBE126DBF for ; Fri, 16 Nov 2018 06:47:11 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 7OjO5pYCspkS for ; Fri, 16 Nov 2018 06:47:10 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 BB23B128D68 for ; Fri, 16 Nov 2018 06:47:09 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id d135so37696473qkc.12 for ; Fri, 16 Nov 2018 06:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ohGi2W9uaJ/eMUxI+Q+UebKMtkC92MMDTZbCRgAe8Xs=; b=iKU174PTZrrnxTwoA4yqhMx2niJesdV2GUnv4cSYuWaMrfhLGe2bKjc6Dm81RoIz0+ 6nbDaN64UzDXDXNJQAGJg5tr4WZfES2aiEyN7uZJk5cZ7m1MAFAiBhuYEPCCG30rG6eM +32uZtny39DBgKOLmLaExGrngi7RnLYjPnkI8iGticeGXpge4wUejaJTvBAr/YNqAL83 HTuVPgmPHomHHTTIIQ0GEYiMgnJZ0gQVuHh/o8qmWL5GhvMhLfeibftzB4X7Gme+enQG jXbYDnhmBKTbiY+YZatyEUFSSR/57Dt8Q+E22f+BRinSC7IljlpmnxNtciVencEoA1CN q5yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ohGi2W9uaJ/eMUxI+Q+UebKMtkC92MMDTZbCRgAe8Xs=; b=nf9pvSqiBVoQgA/Gf9O73Zu9jqaSH4Ne4tJm55FRFe+b5Gw/jJG5RSnm1ZePoZycmf nKOUU2IKgjdPt/1nM34qbCz2OycnGzCtKc7Xth/OpLThNOSARQ5w9QIhfsifZXJUv6lG 8MSslC7SZoblDJgW8LDRrI2A/8zHgm+ibAWcja8yJrxEAVNvkrtZDS2CfUx9NGbNydOQ kRmX1/uPGlAI5xD6h67QpqJqhf/EO63Rbbt6eQLFHeUwdg/aBNNDJ/LVG22AGytfHAnk MlQJi/2dIS/egPAu7qlaYAxZ5/QKRua7hTOkpChffU0vYTG1shhp72JefNs22aC/A5Y1 FoEA== X-Gm-Message-State: AGRZ1gJPTszAJprpYOX3zgWM6oqv/M9FZoqabRKFk032lRp4gBOFVYMM 0VfJs20SKyygAd36VCZdWm07XhOFFlRXpb71z2oS9HqKyWU= X-Google-Smtp-Source: AJdET5cP8Zh3n6ZYT6OFo8OmWU+pkPUO/J4uX9vjcdwqwzZi7udvXECvxQ/d668kaLvQA8HX0Aq4MV5TGtloUMehPo4= X-Received: by 2002:a37:291:: with SMTP id v17mr10427340qkg.208.1542379628633; Fri, 16 Nov 2018 06:47:08 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> <87k1ldqelm.fsf@fifthhorseman.net> In-Reply-To: <87k1ldqelm.fsf@fifthhorseman.net> From: Ted Lemon Date: Fri, 16 Nov 2018 09:46:32 -0500 Message-ID: To: Daniel Kahn Gillmor Cc: Hrpc Content-Type: multipart/alternative; boundary="000000000000dfc108057ac93dd3" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:47:12 -0000 --000000000000dfc108057ac93dd3 Content-Type: text/plain; charset="UTF-8" Hm. I think that the decision we made has clear policy implications, sure. But was the reason we made it because of those policy implications? >From my perspective, the reason for rejecting it was that it was technically bad: it created an attack surface that could only be mitigated by user action, which as we know from painful experience means an attack surface that can't be mitigated. I don't really like your proposed text. I think we do appreciate it when people raise their non-technical concerns, but I also don't think we can always address their non-technical concerns, and we ought not to suggest otherwise. Sometimes the right way to mitigate the problem with a particular tool for a particular set of use cases is not to change the tool, but to have a second tool. On Fri, Nov 16, 2018 at 9:36 AM Daniel Kahn Gillmor wrote: > On Thu 2018-11-15 16:10:27 -0500, Ted Lemon wrote: > > This is *precisely* why we say that the IETF's purpose is not to get > > involved in that calculus. It's simply out of our possible scope. > > I think this thread is fascinating. > > IETF decisions (TLS 1.3 forward secrecy is just one example) very often > do have business and policy implications, as this thread alone has > clearly indicated. > > So we "do" business and policy whether we want to pretend we do it or > not. > > I disagree with Ted that the TLS 1.3 forward secrecy decision came down > to business/policy on one side and technical decisions on the other. > There were mutually-exclusive policy and technical arguments on both > sides, and we made a collective decision about which policy and > technical arguments were more important. > > I think that the text Stephane cites (if it says anything meaningful at > all) says "don't expect us to come to consensus about business or policy > decisions", probably because we know that's basically impossible given > the range of competing perspectives and values that we hope will provide > concrete input to the IETF processes. > > But we're making decisions about what structural choices are *possible* > on the largest-scale global communications infrastructure available. > And we're making decisions that often guide what becomes *common* in > that same infrastructure. So of course those decisions have business > and policy implications. > > I think it's better that we can make these decisions keeping this fact > in mind, instead of wishing it away or pretending that it ain't so. But > i also understand that the engineering community has a storied history > of claiming that its work is "technical and apolitical" (up until the > point that it claims that it is "revolutionary"), and that's a tough > habit to break. > > just for fun i'll try proposing some (probably terrible) alternate text > to see whether that makes things more clear. > > We try to avoid policy and business questions, as much as possible. > > I'd turn it into something like: > > The IETF's work inevitably has business and policy implications, > which we struggle with. We appreciate when people raise those > concerns as clearly as possible while simultaneously addressing the > mechanical and technical impact of their preferred solutions. > > All the best, > > --dkg > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000dfc108057ac93dd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hm.=C2=A0 =C2=A0I think that the decision we made has clea= r policy implications, sure.=C2=A0 =C2=A0But was the reason we made it beca= use of those policy implications?

From my perspective, t= he reason for rejecting it was that it was technically bad: it created an a= ttack surface that could only be mitigated by user action, which as we know= from painful experience means an attack surface that can't be mitigate= d.

I don't really like your proposed text.=C2= =A0 =C2=A0I think we do appreciate it when people raise their non-technical= concerns, but I also don't think we can always address their non-techn= ical concerns, and we ought not to suggest otherwise.=C2=A0 =C2=A0Sometimes= the right way to mitigate the problem with a particular tool for a particu= lar set of use cases is not to change the tool, but to have a second tool.<= /div>

On Fri, Nov 16, = 2018 at 9:36 AM Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Thu 2018-11-15 16:10:27 -0500, Ted Lemon wrote:
> This is *precisely* why we say that the IETF's purpose is not to g= et
> involved in that calculus.=C2=A0 It's simply out of our possible s= cope.

I think this thread is fascinating.

IETF decisions (TLS 1.3 forward secrecy is just one example) very often
do have business and policy implications, as this thread alone has
clearly indicated.

So we "do" business and policy whether we want to pretend we do i= t or
not.

I disagree with Ted that the TLS 1.3 forward secrecy decision came down
to business/policy on one side and technical decisions on the other.
There were mutually-exclusive policy and technical arguments on both
sides, and we made a collective decision about which policy and
technical arguments were more important.

I think that the text Stephane cites (if it says anything meaningful at
all) says "don't expect us to come to consensus about business or = policy
decisions", probably because we know that's basically impossible g= iven
the range of competing perspectives and values that we hope will provide concrete input to the IETF processes.

But we're making decisions about what structural choices are *possible*=
on the largest-scale global communications infrastructure available.
And we're making decisions that often guide what becomes *common* in that same infrastructure.=C2=A0 So of course those decisions have business<= br> and policy implications.

I think it's better that we can make these decisions keeping this fact<= br> in mind, instead of wishing it away or pretending that it ain't so.=C2= =A0 But
i also understand that the engineering community has a storied history
of claiming that its work is "technical and apolitical" (up until= the
point that it claims that it is "revolutionary"), and that's = a tough
habit to break.

just for fun i'll try proposing some (probably terrible) alternate text=
to see whether that makes things more clear.

=C2=A0 =C2=A0 We try to avoid policy and business questions, as much as pos= sible.

I'd turn it into something like:

=C2=A0 =C2=A0 The IETF's work inevitably has business and policy implic= ations,
=C2=A0 =C2=A0 which we struggle with.=C2=A0 We appreciate when people raise= those
=C2=A0 =C2=A0 concerns as clearly as possible while simultaneously addressi= ng the
=C2=A0 =C2=A0 mechanical and technical impact of their preferred solutions.=

All the best,

=C2=A0 =C2=A0 --dkg
_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000dfc108057ac93dd3-- From nobody Fri Nov 16 06:49:25 2018 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 91802126DBF for ; Fri, 16 Nov 2018 06:49:23 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 qQAvc-bt_hii for ; Fri, 16 Nov 2018 06:49:22 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 E772A12D4EB for ; Fri, 16 Nov 2018 06:49:21 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id a132so37769838qkg.1 for ; Fri, 16 Nov 2018 06:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o0+Q5/2cM0qm0UZO95ShoaWWW3gDtHJPAR52i24PLDE=; b=PY0qHu1qKYdsqZrLS9FBXvGB6Z+r/tL3EyZp6U9SCe8nBISeyW1d+RXBsxSwL8HDKg IBLAiIdEC7xYQc7I2JzoRhMeNB7DWX/JYd1wk+otNwZ5MwF0M4/Md90Aj69s8aSxm950 uUl6D7D5+dGwvoY6hIdIj4vWKf2CmKw6W0mlJaV/8DMRBjfLQSOKD2q+Xg5e4JkS7gBD PjH9Fy6IyhsT6U3Ry/Hoke2d3YdF/Nw3SAQgLZ96tDAQL+OoXE6mPtX9929ZspGafxX4 dU5F0R8SP/pzqnuZWcUt3wJxWaN52msib/moKldIrmaUXHhmZF4CvuxezWLMXrTyXkv+ FK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o0+Q5/2cM0qm0UZO95ShoaWWW3gDtHJPAR52i24PLDE=; b=Gd1A3tYgi+PTZaySbJJvGCX1SQoRf1OrWguqs8649G8oamkrTBCE9vgmS7o2c1AB7J 0aUcUBFpNJngfT9IF72qrDJVqcS7JtIHhxhNDGF5K/Mt+rbH8QS3LeYF+546QESO2p/4 E37/Gu/pyx+sQ4nFbWWYVn9d/FNk3QKKmAFJoK83g5P8Sg8wJhUgwwwSmJUcjQ+N4SEs aB37e3PG/aap7yLZxW8s9RQGdNx/vbO/nF4YLVV7/3h87Z28RgJFM5NIg9fnbJS4OBq5 4VMSUxgkxdm0n5wXHmVPaL2DBKrYo1k3Z+91zMvLOmBQLyF0NF+4+YxylC6bRzjkUK7O ZtlQ== X-Gm-Message-State: AGRZ1gIM6CJoAI5r2ZfrbnZu9ZktyB55JPRCzr1uPh6sIPW6iwefazMz 3iEjoTaV/6Z+64bEuBQuNQmz9a4sNL9deZGI+AQNbHPIT9A= X-Google-Smtp-Source: AJdET5dXB4OEO59WJJGKoVflcrTUCFGDud1YwFj/RNNyJqlQ9zjw18zjVArqDcig7TVuZYsNIzX/fwArDz/Ar8pbv2k= X-Received: by 2002:a37:9ce:: with SMTP id 197mr10080388qkj.164.1542379761026; Fri, 16 Nov 2018 06:49:21 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> In-Reply-To: <1845585316.1607419.1542379498804@mail.yahoo.com> From: Ted Lemon Date: Fri, 16 Nov 2018 09:48:45 -0500 Message-ID: To: Nalini Elkins Cc: Paul Wouters , Hrpc Content-Type: multipart/alternative; boundary="000000000000c40e87057ac94505" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:49:23 -0000 --000000000000c40e87057ac94505 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 16, 2018 at 9:45 AM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > > We are working hard to show people the bigger picture and plan long term > but it is not easy. > By "people", I meant the management of large enterprises, not the TLS WG. > Can you unpack the distinction for me? The TLS WG is made up of participants most of whom work for companies, most of which have agendas. Either we are participating in the IETF process with our best intentions, or we are tools of the corporate overlords. You can't have it both ways, and what you said very clearly implied the latter. --000000000000c40e87057ac94505 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 16= , 2018 at 9:45 AM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
> We are working hard to show people the bigger picture and pla= n long term but it is not easy.
By "people", I=C2= =A0meant the management of large enterprises, not the TLS WG.
=

Can you unpack the distinction= for me?=C2=A0 =C2=A0The TLS WG is made up of participants most of whom wor= k for companies, most of which have agendas.=C2=A0 =C2=A0Either we are part= icipating in the IETF process with our best intentions, or we are tools of = the corporate overlords.=C2=A0 =C2=A0You can't have it both ways, and w= hat you said very clearly implied the latter.=C2=A0
--000000000000c40e87057ac94505-- From nobody Fri Nov 16 06:50:35 2018 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 B5300128BCC for ; Fri, 16 Nov 2018 06:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6RebHjIwUwc for ; Fri, 16 Nov 2018 06:50:31 -0800 (PST) Received: from sonic313-16.consmr.mail.ne1.yahoo.com (sonic313-16.consmr.mail.ne1.yahoo.com [66.163.185.39]) (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 5FFF1126DBF for ; Fri, 16 Nov 2018 06:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542379830; bh=UgkcgaBDRuqHk945EC9YLUYpkMpxJFtXZx9aS4PLuC4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Z0enqpptqKG2Dc8H8TvUSZ+CIWyWwOhI2cABBWR/zUOlAyhtl0tdliS93nwtTgDWptrSzauCLOFdcXct+4HyOfTnO7KV/hs1JHWpMWL7plprGYhRTBlXricgrUHE0t/6cLvV36aljGBZjamBI75Rejll8rBIFOxToowurekL5uYxN66ixFwleIn+/xoKIsI0wogWMXQsZL+IvmeoK/MQIawb6lsAhoSPj47DYfizJSWrVU68BYu5PT8j6TzNFXMDi8ox/rDKgb5eOIwBuaTKwa+ssAgZgEJX6ZGvtcPJFfGQHy69lGYbLhIdcyTtlMkY47NX76KmaaS7UgOrboa4Uw== X-YMail-OSG: XNPhGa4VM1kPv.TzZmgx4CQqKqe1GSFmqVuvYloM2UKh79843lm9FFa7HTbTB0Z 3QwEUGeggbaCaGM.nSCctGT8sUW6NEwQlyRt4CFui.YDucivhK4Y.MDLrFNJ1xnYrmXtYciNp8.O XPRSM7MQGvsO5Ad41lkelRjyi.LxhSJ7DEecc7k1O_6oc_xDApjGPZNIpALjloJcoOfJY1pzWmF5 GWRbTTLy0zNcd_8OYzA1yWxV7g5mIq3XVr8RgLWqF0Sj4Qz0tUjQealPgqG3t34FnSZeGngVB9bX WP7i.ioJA5ZJATcWxrGfgRBnjhzgdHeSWTvuh2xRmu7b42rtM1dSq93F4apHTwzAhaeCPRa7v.gS jP_z0dO3rKszeMCLH3QumjrvwcewCXXJb6rFxHM0_SMJ5cI8gOZPzUHmX_aQ3hsMqbH63rj9GWVf LJi2v04BsL2wiTfDmsVQfohOWGCXJwTqhe.NNZWUybolYHc9E7AIz1q_n1VGz4T3aTnS1R33AzyZ MDfNefwXr6yhBPJU8Mv_08JummxnnAJBzvdhuq8jKUiZK93egzbGoNEX.r7IfvRJjgrSGXMl9Zez oV9M70CQk1_TjFdE6.XAvI9Vz6VvA.53lgCg8xAIvId2iTbCcOiTMY9YXwzqqp2H3Lar76Q8V4JH j55Ggmm9BCkgD4CLz9GtHmjCZcSYvvsLl5uLg6hlLYXNa07oEugaheog0XNpf3FcjJOAdE6fgty4 wOdVhnIFOSlGePkdaBQfDHOQe9XlKm_BU27.J8RtM9Ro2wX_mKdm0buQPU6KAkpbdI1Rlqwiw3GZ LaA6kB79eo3kik50l94XloJDORUP6cLJnOowJuGP6CFoIsQzEBhPQzG6220CKrwGbKHCVircnwuJ 5auYhCl1msbGFnOIUlgjW3jQ8qwJpCGGxiT0XMBxUGKppGeWXJzZ7QTVoN07YjDKV38km1Gos1T0 _1nou7YYZfcR87GnXR6HYi1SPqKEOLxQLGnl_ZXzaXArz_JCrTzAIZM4BP9q.ZAuVau3f5nXL0JF JjCWiP.5UCNeFlY.bopi7CE2Devpgoda_Y9lwhoxgn9XKgO04TYv4g7Q_dzY5jw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 14:50:30 +0000 Date: Fri, 16 Nov 2018 14:50:25 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Daniel Kahn Gillmor , Hrpc Message-ID: <887654641.1623494.1542379825407@mail.yahoo.com> In-Reply-To: <87k1ldqelm.fsf@fifthhorseman.net> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> <87k1ldqelm.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1623493_172736427.1542379825405" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:50:34 -0000 ------=_Part_1623493_172736427.1542379825405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >So we "do" business and policy whether we want to pretend we do it or=C2= =A0not. +100 =C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Daniel Kahn Gillmor To: Hrpc =20 Sent: Friday, November 16, 2018 6:36 AM Subject: Re: [hrpc] "We try to avoid" =20 On Thu 2018-11-15 16:10:27 -0500, Ted Lemon wrote: > This is *precisely* why we say that the IETF's purpose is not to get > involved in that calculus.=C2=A0 It's simply out of our possible scope. I think this thread is fascinating. IETF decisions (TLS 1.3 forward secrecy is just one example) very often do have business and policy implications, as this thread alone has clearly indicated. So we "do" business and policy whether we want to pretend we do it or not. I disagree with Ted that the TLS 1.3 forward secrecy decision came down to business/policy on one side and technical decisions on the other. There were mutually-exclusive policy and technical arguments on both sides, and we made a collective decision about which policy and technical arguments were more important. I think that the text Stephane cites (if it says anything meaningful at all) says "don't expect us to come to consensus about business or policy decisions", probably because we know that's basically impossible given the range of competing perspectives and values that we hope will provide concrete input to the IETF processes. But we're making decisions about what structural choices are *possible* on the largest-scale global communications infrastructure available. And we're making decisions that often guide what becomes *common* in that same infrastructure.=C2=A0 So of course those decisions have business and policy implications. I think it's better that we can make these decisions keeping this fact in mind, instead of wishing it away or pretending that it ain't so.=C2=A0 B= ut i also understand that the engineering community has a storied history of claiming that its work is "technical and apolitical" (up until the point that it claims that it is "revolutionary"), and that's a tough habit to break. just for fun i'll try proposing some (probably terrible) alternate text to see whether that makes things more clear. =C2=A0 =C2=A0 We try to avoid policy and business questions, as much as pos= sible. I'd turn it into something like: =C2=A0 =C2=A0 The IETF's work inevitably has business and policy implicatio= ns, =C2=A0 =C2=A0 which we struggle with.=C2=A0 We appreciate when people raise= those =C2=A0 =C2=A0 concerns as clearly as possible while simultaneously addressi= ng the =C2=A0 =C2=A0 mechanical and technical impact of their preferred solutions. All the best, =C2=A0 =C2=A0 --dkg _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1623493_172736427.1542379825405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>So we "do" business and policy whe= ther we want to pretend we do it or not.

+100

 
Thanks,

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


From: Daniel Kahn Gillmor <dkg@fifthhorseman= .net>
To: Hrpc <= hrpc@irtf.org>
Sent: Friday, November 16, 2018 6:36 AM
Subject: Re: [hrpc] "We try to avoid"
On Thu 2018= -11-15 16:10:27 -0500, Ted Lemon wrote:
> This is *pre= cisely* why we say that the IETF's purpose is not to get
= > involved in that calculus.  It's simply out of our possible scope= .

I think this thread is fascinating.<= br clear=3D"none">
IETF decisions (TLS 1.3 forward secrec= y is just one example) very often
do have business and po= licy implications, as this thread alone has
clearly indic= ated.

So we "do" business and policy w= hether we want to pretend we do it or

not.


I disagree with Ted that the TLS 1.3 forward secrecy decision came downto business/policy on one side and technical decisions on t= he other.
There were mutually-exclusive policy and techni= cal arguments on both
sides, and we made a collective dec= ision about which policy and
technical arguments were mor= e important.

I think that the text Ste= phane cites (if it says anything meaningful at
all) says = "don't expect us to come to consensus about business or policy
decisions", probably because we know that's basically impossible give= n
the range of competing perspectives and values that we = hope will provide
concrete input to the IETF processes.
But we're making decisions about what s= tructural choices are *possible*
on the largest-scale glo= bal communications infrastructure available.
And we're ma= king decisions that often guide what becomes *common* in
= that same infrastructure.  So of course those decisions have business<= br clear=3D"none">and policy implications.

I think it's better that we can make these decisions keeping this fact=
in mind, instead of wishing it away or pretending that i= t ain't so.  But
i also understand that the engineer= ing community has a storied history
of claiming that its = work is "technical and apolitical" (up until the
point th= at it claims that it is "revolutionary"), and that's a tough
habit to break.

just for fun i'll = try proposing some (probably terrible) alternate text
to = see whether that makes things more clear.

    We try to avoid policy and business questions, as much as= possible.

I'd turn it into something = like:

    The IETF's work in= evitably has business and policy implications,
  &nb= sp; which we struggle with.  We appreciate when people raise those
    concerns as clearly as possible while simultan= eously addressing the
    mechanical and techni= cal impact of their preferred solutions.

All the best,

    --dkg
___________________________= ____________________
hrpc mailing list
= hrpc@irtf.org
https://www.irtf.org= /mailman/listinfo/hrpc


------=_Part_1623493_172736427.1542379825405-- From nobody Fri Nov 16 06:53:30 2018 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 DCBB0128D68 for ; Fri, 16 Nov 2018 06:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t04zrosSpSYm for ; Fri, 16 Nov 2018 06:53:26 -0800 (PST) Received: from sonic314-26.consmr.mail.ne1.yahoo.com (sonic314-26.consmr.mail.ne1.yahoo.com [66.163.189.152]) (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 0EBC2128BCC for ; Fri, 16 Nov 2018 06:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542380005; bh=Bl8OFgtcD3Vv9hZvWnRAAXg4P23YdP7LSBE5Iwvfi/U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=l7s/nwJ802LVFG3EsklvreDLUEsEFPIPi/2WbmXxZVZQHJbWsOS0YwXy3yJCb2IjSnmvXLfBZE+AZpPRbCn2FzKrESl6i2+9peq4b55LYkLez21go9Mb8Opa+LtB8xuAIU1PaZaVdNPenzqfpNHqxpwOhJIMo0fm9qOp5/U1hN6bBwNjivcN7te84SP5X/Trz8SCemzCJORTg/vS4lQdxb3z8uNp/fxu58iJyDHAkUfahLFePDQMdfTq7L6xQsnxHtGMHqa8C/iHDYw8WFxLm990kAHjED3/+v4buxHA0YyJV72jh5TinjqrlcSrb2yc+qKjnE8L3/iFV8DCWnA9Ow== X-YMail-OSG: SlS6mMQVM1n591MN7LcwGUYiL91fLF_gTWiqZbVyZpR5PSEt1eY8yfj2s1nKvRh 5umhxViWpF7EeL_NgNIOsj9HImgYpq_9fL2P0F8uKoeQcVez5kO_u6X.j8i2CwYWTM5dFiYxyHci WXiAk_VLS1.BCKO_vQO9KU37g8AtubirSdaLtfr06wqLgvhs4fgyUYCFf4cn9O4Bf2qo3dCtCDJf 8xC6ID6chNaXSnvJ0TklTnth4meLG5neu4kkCByXHkqbZ3.Pry60pWc7MNwEXcyale0Y3ye16qRE H4dAm73t3FJIjyh2NwWZ6Wy2S1mfzGeeqRnH1JOa1haLwRbPlbzomUarCVf2zoXwVc1nLRCJpbGT BiqgkqXHQUxUP3NMGWjlzinpb5uA3ukfKlSiMcqjVd6HdF7iy2ezApcMf3jygCYmp9auFV6HwJsM kJWzHz5eD5sRxXsAWBer.lSJ1sWf4ek8aFSXcFGNOuSTuIY.7YNo6iM1Ihw0k5fQoXt1kyUhlcws WejqTmlCT1jinERe.vzJHcPjuGdefX1fKmYtdQz04LbF..ft0FfjTt.gVKeQwteyMRN7Q9Yz0HZ5 hdCqj21VU8ilvHqvDcEf4mziTd5Zd30Z55zvPh7JXWzvYyo3VHywNifo6JPrkbQHid_ASR23XWiV 3qY72FBNPF5KiIIb_IKl7WlY9jlSMdUz942y9YvJF0vgsP5b85hg89GYMUrJ_oK3lrWbn58fiVZK pCGmBIFTD9Mql1SM.b6V4LRnAEpseTM0WuMWF_I553Om4YWPGP6AOAKAkbCZ8QWa1vE0oZ06CPag E.cui_LKN1sH2NTlCi6LDS6VgZUPs9Qv2tbs.5tUGc4Qd_i_Xool7WCj7bD8YNcQNWGCbAs5K9R_ 3wVuTPndvCBgIRMzQEn2OMN079cD5NZA9YJC3XAV3GaqS4KyuajOywtkDVZaCvqZnizzQrFLnO4h IzDBkm_siUrBAXwmZXcrIgmapPi5z6omMk0mzi_VHRnJdZosJfn0d1UFlKPU0N1CvXw1gGP5rg0s v5YDtb8Vc_ASGwc1UewIoIJcm_cFWd2FhNJ9pFwUUPblnVXmF3dhiTbSgFw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 14:53:25 +0000 Date: Fri, 16 Nov 2018 14:53:23 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Ted Lemon Cc: Paul Wouters , Hrpc Message-ID: <582080648.1641646.1542380003764@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1641644_135517740.1542380003761" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:53:28 -0000 ------=_Part_1641644_135517740.1542380003761 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >=C2=A0Can you unpack the distinction for me?=C2=A0 My comment had absolutely nothing to do with TLS in particular.=C2=A0 I was= responding to a comment by Mark about what corporations could do.=C2=A0 I = was talking about what I am doing with my organization to bring awareness o= f standards activities in general to corporations. =C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Paul Wouters ; Hrpc Sent: Friday, November 16, 2018 6:49 AM Subject: Re: [hrpc] "We try to avoid" =20 On Fri, Nov 16, 2018 at 9:45 AM Nalini J Elkins wrote: > We are working hard to show people the bigger picture and plan long term = but it is not easy.By "people", I=C2=A0meant the management of large enterp= rises, not the TLS WG. Can you unpack the distinction for me?=C2=A0 =C2=A0The TLS WG is made up of= participants most of whom work for companies, most of which have agendas.= =C2=A0 =C2=A0Either we are participating in the IETF process with our best = intentions, or we are tools of the corporate overlords.=C2=A0 =C2=A0You can= 't have it both ways, and what you said very clearly implied the latter.=C2= =A0 =20 ------=_Part_1641644_135517740.1542380003761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Can you unpack the distinction = for me? 

My comment had absolutely nothing to do with TLS in partic= ular.  I was responding to a comment by Mark about what corporations c= ould do.  I was talking about what I am doing with my organization to = bring awareness of standards activities in general to corporations.<= /div>

 
Thanks,<= br>
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.ins= idethestack.com
(831) 659-8360


=
From: Ted Lemon <mellon@fugue.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com> <= br>Cc: Paul Wouters <pa= ul@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16, 2018 6:49 AM
Subject: Re: [hrpc] "We try to avo= id"

On Fri, Nov 16, 2018 at 9:45 AM Nalini= J Elkins <nalini.elkins@insidethestack.com> wrote:
> We are working hard to show people the bigger picture and plan long= term but it is not easy.
By "people", I meant the mana= gement of large enterprises, not the TLS WG.

Can you unpack= the distinction for me?   The TLS WG is made up of participants = most of whom work for companies, most of which have agendas.   Ei= ther we are participating in the IETF process with our best intentions, or = we are tools of the corporate overlords.   You can't have it both= ways, and what you said very clearly implied the latter. 
=


------=_Part_1641644_135517740.1542380003761-- From nobody Fri Nov 16 06:59:16 2018 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 587E412D4EB for ; Fri, 16 Nov 2018 06:59:15 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 2A0lBRToG9XP for ; Fri, 16 Nov 2018 06:59:13 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 A7D0E128BCC for ; Fri, 16 Nov 2018 06:59:13 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id 189so37774693qkj.8 for ; Fri, 16 Nov 2018 06:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oLS5I+wyTeiDDT+XkjjCefwu3ONQcWgIhk+yF6qS9Ps=; b=beiNDIfwC9sI2M/d1gSxBI7MoQNI1CTzASQoMLO4oYKfWcLmlF8CdUucNo2cwJ4dsq bDdcpitzi07Vkx2ul8Mq6w7Z3+/+2WAKD3dJqR6RKjK9i7leHgOgtTzWAgygpKPDuUHW q8B4/HbHm8w28GREo98OkY7sCjNcWAedPPugZXQczapYO9AHPAw3q4tPVlEi8eTjq57n WhT2Y+yRemee1xLH6HguuAX25KCPMiL/+pHObHepU7oyhDiTiUdLTC1G8Fz0FQrO9vAQ PqcyaxAfxRCujp4TGPAKMBYpxwRm2P9dri7/P+ER7DZrSREffdYElqR7Ckh+g+TSPfT9 hNxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oLS5I+wyTeiDDT+XkjjCefwu3ONQcWgIhk+yF6qS9Ps=; b=bcWAUqnK72BYSDy6vUWH2tM7yLZ8vfqmor9ltALzkoqUUuEa/t8fZqo5fQXJ/5yIN4 ahFK9HuZxvislnA01MEwM+I8C5+6wlFfSd59ZPRm2Njd0khkRlPrTOPmMM2m1KXJv18X V9M6yuXa2LZEuH70qP/Al2YrEx97csQ72NqPZOsX1VysAIznLZckmLwzagHZWBzsINTI 1thOdA6bg2sHGjzpfTsR4d3RKhjKK0Pv/wyciDGjLg2ikvWyt8AVwQLxJqL5onzdsA/Y MCoxp3cRtR4+xJ5/qoQ3lRHISaFEqMRR8l5GQ3x0c0U0uY2u0ReY3gRwDNHaUJMget8f J11Q== X-Gm-Message-State: AGRZ1gLKVp5fc1+vtS0P8qtxrOPouNNo4hkCCUUqIuGsB3B9OxlAtH77 L9qY9/n36qyy5FADzUcyWvLq6RIzc2oF8mBjAr5Cm4DJnzM= X-Google-Smtp-Source: AFSGD/U4EgTcYh5zG6momczxVqGF3EhM8RzAStZYNlbaEMxAGX73d12faCQc+YMVNd/abR0DuXEVvzVe7VecqE4cHGc= X-Received: by 2002:ac8:7181:: with SMTP id w1mr3779669qto.271.1542380350941; Fri, 16 Nov 2018 06:59:10 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> In-Reply-To: <582080648.1641646.1542380003764@mail.yahoo.com> From: Ted Lemon Date: Fri, 16 Nov 2018 09:58:34 -0500 Message-ID: To: Nalini Elkins Cc: Paul Wouters , Hrpc Content-Type: multipart/alternative; boundary="000000000000eda766057ac96858" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 14:59:15 -0000 --000000000000eda766057ac96858 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > > Can you unpack the distinction for me? > > My comment had absolutely nothing to do with TLS in particular. > Perhaps not, but it clearly applies to the TLS working group as well as any other. The IETF consensus process is very deliberately designed to address exactly the attack you're describing. It is true that the firewall is not perfect, but it's better than any other SDO's firewall against the same problem; most SDOs actually consider this a feature, not a bug. --000000000000eda766057ac96858 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 16= , 2018 at 9:53 AM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
>=C2=A0Can you unpack the distinction for me?=C2=A0

My comment had absolutely nothing to do with TL= S in particular.

P= erhaps not, but it clearly applies to the TLS working group as well as any = other.

The IETF consensus process is very delibera= tely designed to address exactly the attack you're describing.=C2=A0 = =C2=A0It is true that the firewall is not perfect, but it's better than= any other SDO's firewall against the same problem; most SDOs actually = consider this a feature, not a bug.
--000000000000eda766057ac96858-- From nobody Fri Nov 16 07:04:57 2018 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 E85D3130ED1 for ; Fri, 16 Nov 2018 07:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF9cM7Iy93qB for ; Fri, 16 Nov 2018 07:04:53 -0800 (PST) Received: from sonic314-26.consmr.mail.ne1.yahoo.com (sonic314-26.consmr.mail.ne1.yahoo.com [66.163.189.152]) (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 007BF130DD4 for ; Fri, 16 Nov 2018 07:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542380692; bh=JpziKTfyunTON2MLd15T2FDzhfbU5vuikxICSsmjJkY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=KCa56385OKrcc1gjVouMd2H7MF2VjFkXRG9E8+RlKLrVFdHZE1mT4CSmwGbKpw4DUkDKoS/JDZf1WaqyXAObo/HYtGVITiuHF13hDZ+kF/bM6kJB0gCM2x6m9aD5+5bNGKpHFNeW5eb0TjS6GiF8myoMwokWS2HWi4gKpkxO7XGYlwhqmzTEM/e/7eMpl5WflDIcJfdNOVbHN1qGMf8YNtvtwuxvZZX0UdPLL1vLeR2kV3XK6O5EQ7tUoKTJaVANhjo0ha/uIfEhoGKP0slpXYA5sxhqNHWJVeKmCsWKB/7K0akEagYkvSaRAbX3SYKHmOjCQmzdiTry7ybsYK/TCg== X-YMail-OSG: G.Y4o_IVM1mEcJil8aKxQqGqGWlwimpbhWIZVs1AtzwnSWRAAn_ZtwhxzvXIai5 hOoDm9M.bZ8MxJ3QBuPThTetiwHSpgjk449VrOdSy8AWed5ukDq1SANrjojpWkUk6u6OCxGxcGnS l6VDUYmHj6T_2XKSsBw99MBRQMda8xz3pJWD7dcpLbmyJwIw2BZjRlJCvWptkKBd2tj3HqdrraXo .pRv3mETqPFEOT_zqsXwj2j.tuQxr5HIUrESfbNdkxcrN.1JdlHX_zZxqkD8mixV1O2fqumpZ7kP Yx6rXWYJGTKBjnbvhXA.pNpdOXt0njph08SNuwd71TL1cg1DBwA.atDQLlBnti3IGHSlBw.ykEx5 PgeItzzrSGIkGAdoUNnbIdjys_DpMYmPwGS9QkJ2xApwJFiO9vaPKaZu9hiXZD.YI1BH_e1g2Sg1 fQD_EAAYspZYH7nRUsQ_FnQAvV.ORJwbnk1rXmkH20zuhxlKuNgaEVgfzqn3heeNaWH3q76zv_MQ RZKFPwVNYV_Laqd40TjTwETY9wNoJwumUCkGvWHyvcUOf.Q_.TaEKZbPsM3jPGIUjc5w5aM1hOhp Gs1KZTZzJQtrTPXEfGV42SGwI63hB09wwZ5ThG0ogwivWnWrZCttLwEgqLvaK19F0hWFu_yeHm27 VmunpxefTSdyct3CVqkbAhkLsf8KfPEAJ0mypQBqZLDbAKsq2Zx8EiCU_fQTDuwkEr9OafV.jvIh SpBp69QfHxHmokAFGg2gXuwI4jxSeezc20zR2rTbao0pyyP3g.rs.v7Gxy8kfcNiqsCsaMdmTnxd U2ZgFBay8Dbke1Di9aO0nFCkD.i8awhgN5WJJQ_5RE9yPjItLBDsZippgrNOb4javU6s7CpjUJQG xeh9yyGCqslhHCWy4fvPi4kWPOv1VYFQMkryergwtm6ofe0l7TbqV4aQlcH3Drq3xui9utedGvcY Ulzfx4sXwlg5Wq6i9asR3t45iOW_7j4Ob9x2DkcADnUgoLWA8WpvodVNifu_qVOWyjUMJfP8TEze f8qMq7fhMJhdVrW7KL2QWyW_y7JN0nUIXAPYQzbknkEgE6oK4Eddk4gjvAvAy9Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 15:04:52 +0000 Date: Fri, 16 Nov 2018 15:04:50 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Ted Lemon Cc: Paul Wouters , Hrpc Message-ID: <957752793.1637300.1542380691010@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1637299_201952293.1542380691007" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:04:55 -0000 ------=_Part_1637299_201952293.1542380691007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > exactly the attack you're describing Excuse me?=C2=A0 What is the "attack"?=C2=A0 I have lost you here.=C2=A0Tha= nks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Paul Wouters ; Hrpc Sent: Friday, November 16, 2018 6:59 AM Subject: Re: [hrpc] "We try to avoid" =20 On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins wrote: >=C2=A0Can you unpack the distinction for me?=C2=A0 My comment had absolutely nothing to do with TLS in particular. Perhaps not, but it clearly applies to the TLS working group as well as any= other. The IETF consensus process is very deliberately designed to address exactly= the attack you're describing.=C2=A0 =C2=A0It is true that the firewall is = not perfect, but it's better than any other SDO's firewall against the same= problem; most SDOs actually consider this a feature, not a bug.___________= ____________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1637299_201952293.1542380691007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1542379828980_29234">> exactly the attack you'= re describing

Excuse me?  What is the "attack"?  I have lost you here.
&nbs= p;
Thanks,

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


From: Ted Lemon <mellon@fugue.com>
To: Nalini Elkins <nalini.elkins@insi= dethestack.com>
Cc:= Paul Wouters <paul@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16, 2018 = 6:59 AM
Subject: Re: [hrpc] "We try to avoid"

On Fri, Nov 16, 2018 at 9:53 = AM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:<= br clear=3D"none">
<= div style=3D"color:#000;background-color:#fff;font-family:Helvetica Neue, H= elvetica, Arial, Lucida Grande, sans-serif;font-size:16px;">
> = Can you unpack the distinction for me? 

My co= mment had absolutely nothing to do with TLS in particular.

Perhaps not, = but it clearly applies to the TLS working group as well as any other.
=

The IETF consensus process is very delib= erately designed to address exactly the attack you're describing.  &nb= sp;It is true that the firewall is not perfect, but it's better than any ot= her SDO's firewall against the same problem; most SDOs actually consider th= is a feature, not a bug.
_____________________= __________________________
hrpc mailing list
https://www.irtf.org/mailman/listinf= o/hrpc



------=_Part_1637299_201952293.1542380691007-- From nobody Fri Nov 16 07:05:26 2018 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 097E8130ED1 for ; Fri, 16 Nov 2018 07:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 SwyB71qYKL-e for ; Fri, 16 Nov 2018 07:05:16 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 2F4F7130DD4 for ; Fri, 16 Nov 2018 07:05:13 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 74B026A34E; Fri, 16 Nov 2018 16:05:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1542380711; bh=nCCb10NPROQbQ49/e+8eqNMMHPF77SCRHz7hd0sNsTc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=JEFCaDuANmncClsScoYlsglvJlTKL9WJreI1kQ4XTDk1eKWoIhHJpuE/y1iIWzQIb kyK2ewCHnhG4v3dmwmoa6JXI7PnGqJEKu9fQ5MOnMPhPkdx+EV83qR/B/HtgCL/47/ 5SAV7SfiUKv04VIcY6Fej1KU9NNfTqypwp1YcJz77ytv72wx7CSC3P9RfvXjKYu2s0 ONFl80NqqoiXgZMLTPt22IcIrEdKfa0liQZNUkcuQHOY6QrANbqkoindg8pR39sFMW vrrX+/9rUZW/qKjySxqZJbJAlRb3+p2QX2gYpFMu297ovWcOKAciDoYmVm7Ml8lcrP uNEoNiR0YsheA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 6D18C3C0766; Fri, 16 Nov 2018 16:05:11 +0100 (CET) Date: Fri, 16 Nov 2018 16:05:10 +0100 (CET) From: Vittorio Bertola To: Ted Lemon Cc: Hrpc Message-ID: <2142586273.16461.1542380711384@appsuite.open-xchange.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <99198595.14360.1542360131606@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev19 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:05:19 -0000 Hello Ted, =C2=A0 first of all, I am not arguing that the decision of not having backdoors in= cryptography was wrong - I am just discussing whether it can be qualified = as a purely technical decision "because business models and policy issues a= re out of scope at the IETF". > Il 16 novembre 2018 alle 15.34 Ted Lemon ha scritto:= =20 > =20 >=20 > The certain technical aspects of the plan to break TLS to which you refer= were rejected because they allow anyone=C2=A0to break TLS.=C2=A0 =C2=A0You= are adding "nation states" to make it political, No, I did not add it, it was in the message I was quoting - and it shows th= at while people claim to have taken that decision only on technical argumen= ts, most of them had non-technical issues well clear in their minds. > but nation states are just one example of who can use a broken TLS to vio= late users' rights.=C2=A0 =C2=A0My personal worry is not nation states but = identity thieves.=C2=A0 =C2=A0And again this illustrates the principle nice= ly.=C2=A0 =C2=A0Because we were arguing over a technical point, people who = are afraid of nation-state eavesdropping can agree with people who are afra= id of getting ripped off by scammers.=C2=A0 =C2=A0The principle is the same= regardless of what is is that you fear. But people who are afraid of organized crime, or who work for law enforceme= nt, will disagree and say that you need something different. This kind of c= omposite alliance between different stakeholders is absolutely normal... in= any policy discussion. > By comparison, for example, the ability to eavesdrop has valuable societa= l benefits in terms of preventing and exposing criminal activity.=C2=A0 =C2= =A0How would the IETF decide which good to promote and which to reject?=C2= =A0 =C2=A0The answer is that we would not, and can not.=C2=A0 =C2=A0As a po= licy, the IETF doesn't develop protocols for the purpose of eavesdropping, So it's a policy chosen by the IETF, not a technical issue. > not so much because we don't think it's a good idea, although certainly m= any of us don't, but because it's not a problem with a technical solution.= =C2=A0 =C2=A0 This is not true - in fact, there have been technical proposals to add back= doors into cryptography. It's just that they would create more risks than t= hey would solve, but technically it's entirely possible to have them. > There is no way to have a secure transport that enables eavesdropping, an= y more than you can find a piece of ordinary matter that will levitate itse= lf out of a gravity well. That depends on a definition of "security" which is also a matter of policy= : some people will argue that a transport protocol that can be easily used = by criminals to escape law enforcement is not secure at all. =C2=A0 So I rather like dkg's stance - I think it's much closer to reality. =C2=A0 Ciao, --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com=20 Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Nov 16 07:06:54 2018 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 E164D130ED7 for ; Fri, 16 Nov 2018 07:06:52 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Lyv7Afdv4wZw for ; Fri, 16 Nov 2018 07:06:50 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 9E2F8130DD4 for ; Fri, 16 Nov 2018 07:06:50 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id n12so37809960qkh.11 for ; Fri, 16 Nov 2018 07:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FKWbMF/NpMTG44E3lH+oRfd8L8xmoMOSbR2rZKGuTJ0=; b=ld0F0sq9Vw/ifTW63Duf6rDxfHTxQWOtnoQqRMPsjMA/wDw5Ygc4Cq4nagE1J7QFJo TN1ZVzE886Yb9/Yn/rIyzpyGQxsz7j5BPT+VDI6raCaEwCki9bVP1EM2Ca74SBnu/1VL 60tZM6dJjgLuzgblRSvAYKNc81Zw0Zsy8G6LUNDoBzy30d7dR1UhMxsAy2IaXBx8MouT zQfeS5aeFuTI+YZHex1jSE1tL+qdr3zZXS1+vSFgSwjyNqnDm7caY9fRkKMg+GoRyD0L 6lXacI64jjkD464bC7ylGLtgXdR0VS6oqs4uGuXWpz9DquVda8w3KKuVYeGoaXldq+kz oEwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FKWbMF/NpMTG44E3lH+oRfd8L8xmoMOSbR2rZKGuTJ0=; b=lv0Hz3Rywo6pOKniQRe7do1FCMqf2Isi9TefYQUlsTrk8iwjBTCn5GHVrbmvyWZWm0 D+6yqVgVCKFY/n/WUJ1PQHTg22d55iF2cuh3Vunk6GehElwEYx5BHr96r2gbq2xyLVj4 bAVVOYuVMCd7t08ZO/7h9+dps1kE78QFcP8JbJFBfT3xKuAFHd52focAy7+kKGaG4J2h ++DPu2oI1iE5lVv/Vlr6sl2e09LqpMAkVxsymQwo69TunuVugW18HfBOrmTj/mUg7tSj qQk0trZTz+ZI1hRBw6bzR9gG3i8HGP1ES555GKzGbOL9yfhpj+U1yHpUmyKXkihj3Bs9 ID2A== X-Gm-Message-State: AGRZ1gJXCZx728/bkipm12+kKiNaWEckkOnETGK9U8EGdaxAxmiP6UhU symr/wEHhzDH+7+mnVOrNidXmmSDbpQ0sT9D1M5+1vWs23s= X-Google-Smtp-Source: AFSGD/XuzYRRG+rIG85KMOvqp5rVTVK9ens4uJAgw12aaJmgSpm9u2r7weFvisL8a/iVineA3Q8C9UrCMr4tfl0ErEM= X-Received: by 2002:ac8:7181:: with SMTP id w1mr3817799qto.271.1542380809613; Fri, 16 Nov 2018 07:06:49 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> In-Reply-To: <957752793.1637300.1542380691010@mail.yahoo.com> From: Ted Lemon Date: Fri, 16 Nov 2018 10:06:13 -0500 Message-ID: To: Nalini Elkins Cc: Paul Wouters , Hrpc Content-Type: multipart/alternative; boundary="0000000000004479e4057ac9840a" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:06:53 -0000 --0000000000004479e4057ac9840a Content-Type: text/plain; charset="UTF-8" You described an attack on IETF process where corporations send so many participants to the organization with the intention of overriding the consensus process that they succeed in doing so. On Fri, Nov 16, 2018 at 10:04 AM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > > exactly the attack you're describing > > Excuse me? What is the "attack"? I have lost you here. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > ------------------------------ > *From:* Ted Lemon > *To:* Nalini Elkins > *Cc:* Paul Wouters ; Hrpc > *Sent:* Friday, November 16, 2018 6:59 AM > *Subject:* Re: [hrpc] "We try to avoid" > > On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins < > nalini.elkins@insidethestack.com> wrote: > > > Can you unpack the distinction for me? > > My comment had absolutely nothing to do with TLS in particular. > > > Perhaps not, but it clearly applies to the TLS working group as well as > any other. > > The IETF consensus process is very deliberately designed to address > exactly the attack you're describing. It is true that the firewall is not > perfect, but it's better than any other SDO's firewall against the same > problem; most SDOs actually consider this a feature, not a bug. > _______________________________________________ > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > --0000000000004479e4057ac9840a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You described an attack on IETF process where corporations= send so many participants to the organization with the intention of overri= ding the consensus process that they succeed in doing so.

On Fri, Nov 16, 2018 at 10:04 AM Nalini= J Elkins <nalini.el= kins@insidethestack.com> wrote:
> exactly the = attack you're describing

=
Excuse= me?=C2=A0 What is the "attack"?=C2=A0 I have lost you here.
=C2=A0
Thanks,
=
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360


<= /div>
From: Ted Lemo= n <mellon@fugue.co= m>
To: Nalini Elk= ins <nalini.elkins@insidethestack.com>
Cc: Paul Wouters <paul@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16, 2018 6:59 AM
Subject: Re: [hrpc] "We try to avoid"
=

On Fri, Nov 16, 2018 at 9:53 AM Nalini J = Elkins <nalini.elkins@insidethestack.com&= gt; wrote:
>=C2=A0= Can you unpack the distinction for me?=C2=A0<= /span>

My comment had absolutely nothing to do with TLS in particular.=

<= div>Perhaps not, but it clearly applies to the TLS working group as well as= any other.

The IETF consensus proc= ess is very deliberately designed to address exactly the attack you're = describing.=C2=A0 =C2=A0It is true that the firewall is not perfect, but it= 's better than any other SDO's firewall against the same problem; m= ost SDOs actually consider this a feature, not a bug.
_______________________________________________
h= rpc mailing list
https://www.irtf.org/mailman/listinfo/hrpc



--0000000000004479e4057ac9840a-- From nobody Fri Nov 16 07:12:13 2018 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 2C6D912DD85 for ; Fri, 16 Nov 2018 07:12:11 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 BxthtBIhhzCa for ; Fri, 16 Nov 2018 07:12:09 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 2959A12D4EB for ; Fri, 16 Nov 2018 07:12:09 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id y16so37871859qki.7 for ; Fri, 16 Nov 2018 07:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gna8RSbt5KK6ts6smgWS1fk4bwKspNyzkYBw6Aeeo8w=; b=QMj+oo6CRnAwn62rgSJwCN5tYZ7A0EwePeCBEw4MapXgc8dwrTSI3letFGplgnyUzf KIHdsAr8H4U1kTmp1DTCXZx2vt6zWdbo75MwsACzmzAq77Q983dsQLFyG8NQSiSL26MA q0QLkCcPiJnxgbMQH2YM44cFresBuUPEhuLzG3h3tVFyOAAbm6NgLDYzrtHLZRTSk9xB ggG/abmpbKutGrxxXvSv157TcJUba+1ADOnGjLpPScOOb+OzThHaRSOldDB0rQfjfira SUUylzs05R269IVOQBWyDZzIAfOF1sXamTsRV+eE1g1n7v3Mbr2zVfw/DOrF79jmhpWl Ph8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gna8RSbt5KK6ts6smgWS1fk4bwKspNyzkYBw6Aeeo8w=; b=jF/lGvDF3W0eBDGMNfr1tT1LdTWaXl1NTpbekHWRFnsWd2W2iwLwWmKhnijhMYfBN9 BCqk53NcobgaNJha0fb8pVP5Xr6UJRIF97Epvvoh33uG79tArm8vRnB4ZjfzVBtm4kjU DvQu4s0+pmH7duS5pipe2mz7/FOV2gMz4aVWZr+fUu8cnOi9DB+gj14dTVSumZrq74FZ lDSciCPcJ21X7ZheNPnQwQysscCty7tEeI9WR3daatA462rmmWcV82MlBJhmONfELKmb EYbuVRpoH5WJ+Cs8MyIr+RHI14mVkGfWdjt0vCxTAZlmNPc1qZWWJUViDpRFMdu46kwD Xu6w== X-Gm-Message-State: AGRZ1gJuvpoqfmVOswztio89hD/UGW4a/kgQsJyv+fZsuX+zkV92B2Ex 7bNPtknasxIx1iHFWN7/l2QR1QGKfTR2ygYEHoG5G+3lH3UVVw== X-Google-Smtp-Source: AJdET5cNVAGilr0ULULYRfvpjco8etEgyxpZE8pGIndMiaFEFLFghS2m64BtBjYEfqtUNzpN1VNhRih8Q6vrg0ZuPs8= X-Received: by 2002:ac8:7518:: with SMTP id u24mr10687516qtq.75.1542381128158; Fri, 16 Nov 2018 07:12:08 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <99198595.14360.1542360131606@appsuite.open-xchange.com> <2142586273.16461.1542380711384@appsuite.open-xchange.com> In-Reply-To: <2142586273.16461.1542380711384@appsuite.open-xchange.com> From: Ted Lemon Date: Fri, 16 Nov 2018 10:11:32 -0500 Message-ID: To: Vittorio Bertola Cc: Hrpc Content-Type: multipart/alternative; boundary="00000000000040a3ce057ac99743" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:12:11 -0000 --00000000000040a3ce057ac99743 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 16, 2018 at 10:05 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > but nation states are just one example of who can use a broken TLS to > violate users' rights. My personal worry is not nation states but > identity thieves. And again this illustrates the principle nicely. > Because we were arguing over a technical point, people who are afraid of > nation-state eavesdropping can agree with people who are afraid of getting > ripped off by scammers. The principle is the same regardless of what is > is that you fear. > > But people who are afraid of organized crime, or who work for law > enforcement, will disagree and say that you need something different. This > kind of composite alliance between different stakeholders is absolutely > normal... in any policy discussion. > People who actually understand the problem will not disagree and say you need something different. The problem is that too many people are weighing in on the problem who don't understand the technical issues. Consider: https://www.theatlantic.com/technology/archive/2018/10/president-trump-and-cell-phone-security/574096/ This is not true - in fact, there have been technical proposals to add > backdoors into cryptography. It's just that they would create more risks > than they would solve, but technically it's entirely possible to have them. > I think that we are talking across each other here. Yes, you can make a hammer that doesn't drive nails. How to make a hammer that doesn't drive nails is a technical problem. But if your goal is to make a hammer that drives nails, then the technical problem that you have to consider is how to prevent it from not driving nails, not how to make it both drive nails and not drive nails. --00000000000040a3ce057ac99743 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 16, 2018 at 10:05 AM Vittorio Bertola <<= a href=3D"mailto:vittorio.bertola@open-xchange.com">vittorio.bertola@open-x= change.com> wrote:
> but nation states are just one example of who can use a bro= ken TLS to violate users' rights.=C2=A0 =C2=A0My personal worry is not = nation states but identity thieves.=C2=A0 =C2=A0And again this illustrates = the principle nicely.=C2=A0 =C2=A0Because we were arguing over a technical = point, people who are afraid of nation-state eavesdropping can agree with p= eople who are afraid of getting ripped off by scammers.=C2=A0 =C2=A0The pri= nciple is the same regardless of what is is that you fear.

But people who are afraid of organized crime, or who work for law enforceme= nt, will disagree and say that you need something different. This kind of c= omposite alliance between different stakeholders is absolutely normal... in= any policy discussion.

People who actu= ally understand the problem will not disagree and say you need something di= fferent.=C2=A0 =C2=A0The problem is that too many people are weighing in on= the problem who don't understand the technical issues.=C2=A0 =C2=A0Con= sider: https://www.theatlantic.com/= technology/archive/2018/10/president-trump-and-cell-phone-security/574096/<= /a>

T= his is not true - in fact, there have been technical proposals to add backd= oors into cryptography. It's just that they would create more risks tha= n they would solve, but technically it's entirely possible to have them= .

--00000000000040a3ce057ac99743-- From nobody Fri Nov 16 07:34:52 2018 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 BD7AA12D4E7 for ; Fri, 16 Nov 2018 07:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz5GkZqDLYvz for ; Fri, 16 Nov 2018 07:34:48 -0800 (PST) Received: from sonic313-16.consmr.mail.ne1.yahoo.com (sonic313-16.consmr.mail.ne1.yahoo.com [66.163.185.39]) (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 E530112D4EC for ; Fri, 16 Nov 2018 07:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542382486; bh=4kOBVzjTjAVpqe6BJjjevqcqIckBoXgfve0uy6sJZPE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=p3XRQvwnOvBcv94Zw7K+CqcToMW1PUPxq2v5mmI+a7ZU60t/K+/UCOgKzk7GBkixlgy3IPKPkR6ZWW2cN5EtJl+8FXZI9oqjUbEJlDyTUSL6ZlkvZb8eHGUoR3xGmZf7qkxwmWh7GqV3MvaYTX5gyTZ6TjaZLW/HizWFi2fEpxNIWwHoeAXh9PSQebJevP2cQ+sExkSs2Ot4uNUFmA+HJ8kZMBnKCkiV3/MMb1A9j+NyMPqHQdbrp1ZBxzHIYn6TWXck17MJCWoycz0Ao2fh9rpWaXTbJRrPgHLiEJBle2KOJoFVrcqZncC4cdvVAHI+Q47Ap0tmNKQBrGWcxc4PVw== X-YMail-OSG: KoqpTEAVM1mrePCrutegkNCV9tMnJL0fbhP.tpalOfOL4S1X0WFXKq8DxMYm3HL jhNudpfBuPJ80n1yc4evleFYQ_iOWqsHcYjgGaF6tq1hXsdpIyWh5YmqUDYe7WVEZrgN9LUlOaO1 izWX_rYzqNF8F5EeWBPu85tXykoco1bXwAhR8ks0.j_kZ168KwA7nml7D60I9A8NtbA9jWjEzU1b H2RqNrW85XXEFrjoUN8TTvWQkmYA3PRA5tzgiGY_z4pCdzvuXQTO2pUs7Ed8lJovG3Oxyj4p7ZSf MhHXB2r5RSwm.xaxTt48yhvPBC7Y_c6OdRvUgUj_K77SzE40Q06V5UJM4L4_.A0mAoXEAO8l1NfX BAQjdy31bu0XFlIAeiYFVkofQ9NUAQ_LMcqv0but70zri.doLMSrcVNSZsLpIy7AZvHaPF.5AP7r H6LbzI1UQ9NCZE25S.DSci2JKOfmsAA45KnEs4sBo.tBEJjdv_EVCKf1P9MnXyBkZ4IJE_JbPAm2 8l_Z33tu.16WA1t6dQN_wm6Nturk_Cc0Ok3r5wh9SWzUGuaS5k3noVRjiyJXbSxLOW5yyXKrveGO 9ebM0vw2Tbp_OXKIobOou.UpptLqMm1DaVhJ71hyO40mp4XSVN0o9svbFfss2fR4Do1BUeM3Ix6g Ap6ibRg2MDzSsKOaqFK3H3bUHhVorEphm_wPoaGPiURzO1Zo7TUJzpCgDxbfhCnTtiqAHR1JDuJq J0g2pdunvGUriLxLHaKjRvwcr1RBghTnamDrCPI23EA.AHNK0Wro0Rno8QFycOX.HoZHFidVEqNe b4PCWWQXE4fn0fNJ4UKNrhZpTBui9wEjQQOJwLKwSfQMnoJ7ujgfYI0gCrPmoM3mESJ7DI83Fot2 nSUfYF9A0XxCLw.MRhY5Gn4QxB8tgA6E0aTmYJy4i1QJ678bcXfvS0QDKDL.zDStAjH9TeUrfPD8 4v49lTJAynS2j47EUCgyw83uq2Bk1Uf55acC65fs8UOr7lh6hQTSocB1OzxPRKsOH1kmZr_QmFGz N.HN18rLFHtnFoducNc9h_CEF5wTVczP2Dl5WaaY6C0ssX9X0T9o4vTsz0SRFLnI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 15:34:46 +0000 Date: Fri, 16 Nov 2018 15:34:42 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Ted Lemon Cc: Paul Wouters , Hrpc Message-ID: <938412810.1654763.1542382482874@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1654762_1094599163.1542382482870" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:34:51 -0000 ------=_Part_1654762_1094599163.1542382482870 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > where corporations send so many participants to the organization with the= intention of overriding the consensus process that they succeed in doing s= o. Actually, these people would then be active participants in the IETF, would= they not?=C2=A0 =C2=A0Also, you have far more faith in my abilities than I= do.=C2=A0 =C2=A0 If I only had the eloquence to convince all these corpora= te heads to give me money and people to pull off such a tactic!=C2=A0 Also,= if I had the eloquence to make everyone think all in the same way.=C2=A0 = =C2=A0Enterprises are not a *block*.=C2=A0 They actually have different opi= nions. Also, why are not other companies who send many people attackers?=C2=A0 If,= for example, company x sends 50 people, do they all go from room to room h= umming in unison?=C2=A0 Is that what you are proposing that we do? Why would you NOT want more people participating in the process?=C2=A0 That= is my goal!=C2=A0 =C2=A0If you would like to sit in on the training and ot= her sessions that I do to teach people from organizations how to participat= e in the IETF, you are more than welcome. BTW, I just taught a class / lab on IPv6 where over 132 people from 70+ com= panies signed up.=C2=A0 =C2=A0Lee Howard will be working with me next year = to teach more classes.=C2=A0 =C2=A0One of the people from Google has also o= ffered to teach.=C2=A0 =C2=A0Also talking to ISOC about publicizing.=C2=A0 = =C2=A0Don't we WANT enterprises learning about and using IPv6?=C2=A0 =C2=A0= Hopefully, then these people will engage in the IETF also as a result.=C2= =A0 As I say, if you want to help / sit in / teach, please let me know.=C2= =A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Paul Wouters ; Hrpc Sent: Friday, November 16, 2018 7:07 AM Subject: Re: [hrpc] "We try to avoid" =20 You described an attack on IETF process where corporations send so many par= ticipants to the organization with the intention of overriding the consensu= s process that they succeed in doing so. On Fri, Nov 16, 2018 at 10:04 AM Nalini J Elkins wrote: > exactly the attack you're describing Excuse me?=C2=A0 What is the "attack"?=C2=A0 I have lost you here.=C2=A0Tha= nks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Paul Wouters ; Hrpc Sent: Friday, November 16, 2018 6:59 AM Subject: Re: [hrpc] "We try to avoid" =20 On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins wrote: >=C2=A0Can you unpack the distinction for me?=C2=A0 My comment had absolutely nothing to do with TLS in particular. Perhaps not, but it clearly applies to the TLS working group as well as any= other. The IETF consensus process is very deliberately designed to address exactly= the attack you're describing.=C2=A0 =C2=A0It is true that the firewall is = not perfect, but it's better than any other SDO's firewall against the same= problem; most SDOs actually consider this a feature, not a bug.___________= ____________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_1654762_1094599163.1542382482870 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1542379828980_48780">> where corporations send= so many participants to the organization with the intention of overriding = the consensus process that they succeed in doing so.

Actually, these people would t= hen be active participants in the IETF, would they not?   Also, y= ou have far more faith in my abilities than I do.    If I only ha= d the eloquence to convince all these corporate heads to give me money and = people to pull off such a tactic!  Also, if I had the eloquence to mak= e everyone think all in the same way.   Enterprises are not a *bl= ock*.  They actually have different opinions.

Also, why are not other companies who send= many people attackers?  If, for example, company x sends 50 people, d= o they all go from room to room humming in unison?  Is that what you a= re proposing that we do?

Why would you NOT want more people participating in the process?  = That is my goal!   If you would like to sit in on the training an= d other sessions that I do to teach people from organizations how to partic= ipate in the IETF, you are more than welcome.

BTW, I just taught a class / lab on IPv6 where over 132 people f= rom 70+ companies signed up.   Lee Howard will be working with me= next year to teach more classes.   One of the people from Google= has also offered to teach.   Also talking to ISOC about publiciz= ing.   Don't we WANT enterprises learning about and using IPv6?&n= bsp;  Hopefully, then these people will engage in the IETF also as a r= esult.  As I say, if you want to help / sit in / teach, please let me = know.
 
Thanks,

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


From: Ted Lemon &= lt;mellon@fugue.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: Paul Wouters <paul@nohats.ca&= gt;; Hrpc <hrpc@irtf.org>
S= ent: Friday, November 16, 2018 7:07 AM
Subject: Re: [hrpc] "We try to avoid"

You described an attack on IETF process where corporation= s send so many participants to the organization with the intention of overr= iding the consensus process that they succeed in doing so.

On Fri, Nov = 16, 2018 at 10:04 AM Nalini J Elkins <nalini.elkins@insidethestack.c= om> wrote:
> exactly the attack you're= describing
=
E= xcuse me?  What is the "attack"?  I have lost you here.
 


=
From: Ted Lemon <mellon@fugu= e.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com> Cc: Paul W= outers <paul@nohats.ca>= ;; Hrpc <hrpc@irtf.org><= br clear=3D"none"> Sent: Fr= iday, November 16, 2018 6:59 AM
Subject: Re: [hrpc] "We try to avoid"

On Fri, Nov 16, 2018 at 9:53= AM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:=
<= span>> Can you un= pack the distinction for me? 

My comment had absolutely nothing to do with TLS in particular.<= /span>

Perhaps not, but it clearly applies to the TLS working group as well as = any other.

The IETF consensus proce= ss is very deliberately designed to address exactly the attack you're descr= ibing.   It is true that the firewall is not perfect, but it's be= tter than any other SDO's firewall against the same problem; most SDOs actu= ally consider this a feature, not a bug.
_____= __________________________________________
hrpc mailing l= ist
https://www.irtf.org/mailman/listinfo/hrpc


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


------=_Part_1654762_1094599163.1542382482870-- From nobody Fri Nov 16 07:44:29 2018 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 F22E512F1AB for ; Fri, 16 Nov 2018 07:44:27 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 pmaG_NcifW69 for ; Fri, 16 Nov 2018 07:44:25 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 E413B12D4E7 for ; Fri, 16 Nov 2018 07:44:24 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id o89so38057226qko.0 for ; Fri, 16 Nov 2018 07:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JYjuVTm15crBQ/5Glo9penribqE00/N3WDcs+b58LKA=; b=r4G1BUgXr+l3RylbYEAcQQQJBnWQ2jMw/K0cd6FGGq3/HV4N424sDPrvOjcIMOC20Y 6Yyl4wOGFT5MckxXGdWJYPvzuiGciPoa7vTG+Bk486bDnjkTEv5dbW8/IvA0IVzlE6PW ar6f4h2mUq5+TEjGdEZfVfoqPVCJPjn14VL7DEdX0j8YcRoZ5/jpoNKN7pj4eILnruGQ DeGOodmWTbDV/AwpTAHXFEEdFfvlEBrxm2XCXHEp5S5eoADjiFMQYuslps7FgHjLVAxN cuy/RUKAtGLwWMLnSFIKvMbgGmpXzoAGnCYsnSP/7n947e/GAdAiTqiO64rKlbM380w5 XvbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JYjuVTm15crBQ/5Glo9penribqE00/N3WDcs+b58LKA=; b=cIc3+w9YpLKX5NYaGD0RKHrZePkRKZkTIUsarhGGInMYjoUL/yJcmRa9xRt3s3WNgW 0FpuHRF0Uj8wgGuaw+MGzoJ6uCocADCClPRT2bWqjaXf+/KrnRH/NaKCc5dl1wbtHlqu 9S7W9cg7SFlYmFYTArXl/XkeCloQ8rCqoPDPqmdO/jeRP6aWJ25e0Hp/H7XnsQ0gFG8L rqz/TXB84zw7hEOH5LboyJ9wWmTQO0iRjryF1HjXOZ8cubriTrb7yJ1yqY263hHE9g/q 9X2j/CVX1ZOdEDloMPb2ibaBFC6AtWa+dvJ4bmp6BigS5ehfeeC3yMjQsYc1EAyDhp9U 8APg== X-Gm-Message-State: AGRZ1gLcahNtgT8ClyVDQKVOUUWoMgXfNiGNbxZc4yR33zCUzdRSIkpE 8I+BNdzDzGUwBPqWSyGRZs5UQnFEU3e0E6b4xgxGZg== X-Google-Smtp-Source: AJdET5caAFNm0ndwySVTe6LtrXSxSwwlEjb0Fd7mHi3pu+ygTMIvlMiT2/5+cLH+JAvyXq0VNP99U3gWy688eS+tPok= X-Received: by 2002:aed:3286:: with SMTP id z6mr10619364qtd.203.1542383063919; Fri, 16 Nov 2018 07:44:23 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <938412810.1654763.1542382482874@mail.yahoo.com> In-Reply-To: <938412810.1654763.1542382482874@mail.yahoo.com> From: Ted Lemon Date: Fri, 16 Nov 2018 10:43:47 -0500 Message-ID: To: Nalini Elkins Cc: Paul Wouters , Hrpc Content-Type: multipart/alternative; boundary="000000000000a20c33057aca0a1b" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:44:28 -0000 --000000000000a20c33057aca0a1b Content-Type: text/plain; charset="UTF-8" This is a very weird conversation. I think we agree that there is a potential for this attack. I think we agree that it's not inevitable. I think we agree that we should try to avoid such attacks. I think we agree that we want operators to participate in the IETF, and that includes enterprise operators. My concern is that I'd really like to avoid a situation where we wind up doing things that don't make sense technically because it's more convenient than implementing the right technical solution. On Fri, Nov 16, 2018 at 10:34 AM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > > where corporations send so many participants to the organization with > the intention of overriding the consensus process that they succeed in > doing so. > > Actually, these people would then be active participants in the IETF, > would they not? Also, you have far more faith in my abilities than I do. > If I only had the eloquence to convince all these corporate heads to give > me money and people to pull off such a tactic! Also, if I had the > eloquence to make everyone think all in the same way. Enterprises are not > a *block*. They actually have different opinions. > > Also, why are not other companies who send many people attackers? If, > for example, company x sends 50 people, do they all go from room to room > humming in unison? Is that what you are proposing that we do? > > Why would you NOT want more people participating in the process? That is > my goal! If you would like to sit in on the training and other sessions > that I do to teach people from organizations how to participate in the > IETF, you are more than welcome. > > BTW, I just taught a class / lab on IPv6 where over 132 people from 70+ > companies signed up. Lee Howard will be working with me next year to > teach more classes. One of the people from Google has also offered to > teach. Also talking to ISOC about publicizing. Don't we WANT > enterprises learning about and using IPv6? Hopefully, then these people > will engage in the IETF also as a result. As I say, if you want to help / > sit in / teach, please let me know. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > ------------------------------ > *From:* Ted Lemon > *To:* Nalini Elkins > *Cc:* Paul Wouters ; Hrpc > *Sent:* Friday, November 16, 2018 7:07 AM > *Subject:* Re: [hrpc] "We try to avoid" > > You described an attack on IETF process where corporations send so many > participants to the organization with the intention of overriding the > consensus process that they succeed in doing so. > > On Fri, Nov 16, 2018 at 10:04 AM Nalini J Elkins < > nalini.elkins@insidethestack.com> wrote: > > > exactly the attack you're describing > > Excuse me? What is the "attack"? I have lost you here. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > ------------------------------ > *From:* Ted Lemon > *To:* Nalini Elkins > *Cc:* Paul Wouters ; Hrpc > *Sent:* Friday, November 16, 2018 6:59 AM > *Subject:* Re: [hrpc] "We try to avoid" > > On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins < > nalini.elkins@insidethestack.com> wrote: > > > Can you unpack the distinction for me? > > My comment had absolutely nothing to do with TLS in particular. > > > Perhaps not, but it clearly applies to the TLS working group as well as > any other. > > The IETF consensus process is very deliberately designed to address > exactly the attack you're describing. It is true that the firewall is not > perfect, but it's better than any other SDO's firewall against the same > problem; most SDOs actually consider this a feature, not a bug. > _______________________________________________ > 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 > > > --000000000000a20c33057aca0a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a very weird conversation.=C2=A0 =C2=A0I think we = agree that there is a potential for this attack.=C2=A0 =C2=A0 I think we ag= ree that it's not inevitable.=C2=A0 =C2=A0I think we agree that we shou= ld try to avoid such attacks.=C2=A0 =C2=A0I think we agree that we want ope= rators to participate in the IETF, and that includes enterprise operators.<= div>
My concern is that I'd really like to avoid a situat= ion where we wind up doing things that don't make sense technically bec= ause it's more convenient than implementing the right technical solutio= n.

On Fri, Nov 1= 6, 2018 at 10:34 AM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
> where corporations send so many participants to the organizat= ion with the intention of overriding the consensus process that they succee= d in doing so.

Actually, these people = would then be active participants in the IETF, would they not?=C2=A0 =C2=A0= Also, you have far more faith in my abilities than I do.=C2=A0 =C2=A0 If I = only had the eloquence to convince all these corporate heads to give me mon= ey and people to pull off such a tactic!=C2=A0 Also, if I had the eloquence= to make everyone think all in the same way.=C2=A0 =C2=A0Enterprises are no= t a *block*.=C2=A0 They actually have different opinions.
<= div dir=3D"ltr" id=3D"m_1260745091772550432yui_3_16_0_ym19_1_1542379828980_= 48782">
Also, why are not other companies who s= end many people attackers?=C2=A0 If, for example, company x sends 50 people= , do they all go from room to room humming in unison?=C2=A0 Is that what yo= u are proposing that we do?

Why would you NOT want = more people participating in the process?=C2=A0 That is my goal!=C2=A0 =C2= =A0If you would like to sit in on the training and other sessions that I do= to teach people from organizations how to participate in the IETF, you are= more than welcome.

BTW, I jus= t taught a class / lab on IPv6 where over 132 people from 70+ companies sig= ned up.=C2=A0 =C2=A0Lee Howard will be working with me next year to teach m= ore classes.=C2=A0 =C2=A0One of the people from Google has also offered to = teach.=C2=A0 =C2=A0Also talking to ISOC about publicizing.=C2=A0 =C2=A0Don&= #39;t we WANT enterprises learning about and using IPv6?=C2=A0 =C2=A0Hopefu= lly, then these people will engage in the IETF also as a result.=C2=A0 As I= say, if you want to help / sit in / teach, please let me know.
=C2=A0
Thanks,
=
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
=

=
From: Ted Lemon <mellon@fugue.com>
To: Nalini Elkins <nalini.elkins@insi= dethestack.com>
Cc: Paul Wouters <pau= l@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16, 2018 7:07 AM
Subject: Re: [hrpc] "We try to avoid"

You described= an attack on IETF process where corporations send so many participants to = the organization with the intention of overriding the consensus process tha= t they succeed in doing so.

On Fri, Nov 16, 2018 at 10:04 AM Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:
> e= xactly the attack you're describing

Excus= e me?=C2=A0 What is the "attack"?=C2=A0 I have lost you here.
=C2=A0
Thanks,

Nalini Elkins=
CEO and Founder
Inside Products, Inc.<= br clear=3D"none">www.insidethestack.com
(831) 659-8360


=
From: Ted Lemon <mellon@fugue.com>
<= span style=3D"font-weight:bold">To: Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: Paul Wouters <paul@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, Nov= ember 16, 2018 6:59 AM
Subject: Re= : [hrpc] "We try to avoid"

On Fri, Nov 16, 2018 at 9:53 AM = Nalini J Elkins <nalini.elkins@insidethestack= .com> wrote:
>=C2=A0Can you= unpack the distinction for me?=C2=A0

=
Perhap= s not, but it clearly applies to the TLS working group as well as any other= .

The IETF consensus process is ver= y deliberately designed to address exactly the attack you're describing= .=C2=A0 =C2=A0It is true that the firewall is not perfect, but it's bet= ter than any other SDO's firewall against the same problem; most SDOs a= ctually consider this a feature, not a bug.
__= _____________________________________________
hrpc mailin= g list
https://www.irtf.org/mailman/listinfo/= hrpc



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


--000000000000a20c33057aca0a1b-- From nobody Fri Nov 16 07:46:23 2018 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 5B32A12F1AB for ; Fri, 16 Nov 2018 07:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTNuWlAP6rqr for ; Fri, 16 Nov 2018 07:46:21 -0800 (PST) Received: from sonic313-16.consmr.mail.ne1.yahoo.com (sonic313-16.consmr.mail.ne1.yahoo.com [66.163.185.39]) (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 B919212DD85 for ; Fri, 16 Nov 2018 07:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542383179; bh=s7o8+LGsmnGXaOnFIUTlBA8mHKGcZXplelzJoLPepsU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=OsJ5Szqs07J3Rt82UevGMiHh0sY2JxDK+9kpyQk3fUU2Bm9DPLwkuPTOmCmxTrFKbd8CPB/8HlNXOqqPqnvw5WpdgNLY6NcUxj+J6R0XwM5L/hSRk6EqOxPIj+bMyMoImsiKNJ/dfKR8GvPM+WhlRFAgvHj0sxV6ZkyW4nSjVl9IiNyN1RNOwvkZIr8Xq77V/eOao0i/nACP5clN+jRCm/yy9SRfN8x6i220mhpuAfoNm+Z9MyuDoheGJo2xqvYVG9G4yTiaoAXazqjFH8wBA9xK5t0H/8y5uOTgatOOrdR+0PxBghQqhfUf0ML4NPeVdQiqFRswPFx6i+/JMQBftw== X-YMail-OSG: lSWI35AVM1kgZEPCnwvi3t_JMGrJFJbXnHpA0h6lBKF84A7SI39Qg7IiRF7ZFJh H3FpB.05MQBe8OsJo2jaYyxsIXJu32e81_eawBIcWBITYDJvDmHmLH5BujivkxE1DStmeiUo96nq Eye8_wCpVqDM3DfVuG7qGAJzJCT_Sh0qb6tCPyfnErGjgPV8Pyd.vBwbOx.SZ3_imgnM2RWExz7L Zw3S9Dd0N9MKI9he20SmZT0jxa4jPF5HUG2CCS2jASiETXqvOSynfvqguxuUTpQFshzrL8.U_5YR l1m8BvhKh7t3O8IiwUiHCEiUkLWGmKyrROrsU1GcLqo6M3N6nPwAA.AAx662jMb10Sbg.toUGYDf Doiusu1axlxk_zwykRCBb0t9xg3TjoQPZJu.8wBdK.XqeiGxZI6TWcbRUNP96.ROvHiDRzvmnVXA dDb67vTtYAWjKjIc2dpfIa3M0rAhryO.kuHfKIaPkrvq1QMgoYUljPWHWw30c3OU1UaJDVMln_.1 0h6m6bmxSMQ2_s0z.1ThI9cZLAogI6SaQz1nw5ywN7tscRftxVszKJZ1xi4KLjxd0C.rsVoSRvOu RlpJEveO3ufIH7xZHsFUtBWY0lOhCNFFGuYB8ol_9B.9xAvt08dNMZ_o5LR9bMyF4gyPmnHNkmwF 4bg4F5_nT4zMBHePrg3Wd4qoaJHTMKQ1_03c2H5vhRnSDxGBqI0CT0eX.5bbiXgXeNrxMF9vht2Y hsKA7FojUVZRGHLFayejbH6HKkuSZs3o5WjxDQeODcIIcfwCbxf5B5RHmoqre3JokBWfsOu9p.Ss 4eW1chB8M5tD8lQ_qEIzb4QJfCYCQTkPVLHCVMJ1FOYZ.G13NxqzYZaCdiRlmmPIHsIeM4bLHwMe 2jujV4izdJRkhhjwsNKLhawAl_y7hnsLfwySw2_h21paodNz7q1DMe.OR11A7Pc00FncCilXKf1x sMfKna.DyAVzfUq50LZLYFxaIKQFFLeMNInBBbmeeoQubP6r.7kX4.LJRfCTQb7Dd.1I_GqU30dS i6R6mjVnESkwgpAWXfWN4IlH5C5Ig4dOCahM_0UVQ2nwBXmbTeHK69tQn3QZfC9M- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 15:46:19 +0000 Date: Fri, 16 Nov 2018 15:46:17 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Ted Lemon Cc: Paul Wouters , Hrpc Message-ID: <920193363.1649303.1542383177366@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <938412810.1654763.1542382482874@mail.yahoo.com> < CAPt1N1n402AhVcg0YQU+movgRpvyPSba-pgVapB0P41z_Dx0ww@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1649302_435834424.1542383177358" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:46:22 -0000 ------=_Part_1649302_435834424.1542383177358 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > This is a very weird conversation.=C2=A0 =C2=A0 Yes. >=C2=A0I think we agree that we want operators to participate in the IETF, = and that includes enterprise operators. Great!=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Paul Wouters ; Hrpc Sent: Friday, November 16, 2018 7:44 AM Subject: Re: [hrpc] "We try to avoid" =20 This is a very weird conversation.=C2=A0 =C2=A0I think we agree that there = is a potential for this attack.=C2=A0 =C2=A0 I think we agree that it's not= inevitable.=C2=A0 =C2=A0I think we agree that we should try to avoid such = attacks.=C2=A0 =C2=A0I think we agree that we want operators to participate= in the IETF, and that includes enterprise operators. My concern is that I'd really like to avoid a situation where we wind up do= ing things that don't make sense technically because it's more convenient t= han implementing the right technical solution. On Fri, Nov 16, 2018 at 10:34 AM Nalini J Elkins wrote: > where corporations send so many participants to the organization with the= intention of overriding the consensus process that they succeed in doing s= o. Actually, these people would then be active participants in the IETF, would= they not?=C2=A0 =C2=A0Also, you have far more faith in my abilities than I= do.=C2=A0 =C2=A0 If I only had the eloquence to convince all these corpora= te heads to give me money and people to pull off such a tactic!=C2=A0 Also,= if I had the eloquence to make everyone think all in the same way.=C2=A0 = =C2=A0Enterprises are not a *block*.=C2=A0 They actually have different opi= nions. Also, why are not other companies who send many people attackers?=C2=A0 If,= for example, company x sends 50 people, do they all go from room to room h= umming in unison?=C2=A0 Is that what you are proposing that we do? Why would you NOT want more people participating in the process?=C2=A0 That= is my goal!=C2=A0 =C2=A0If you would like to sit in on the training and ot= her sessions that I do to teach people from organizations how to participat= e in the IETF, you are more than welcome. BTW, I just taught a class / lab on IPv6 where over 132 people from 70+ com= panies signed up.=C2=A0 =C2=A0Lee Howard will be working with me next year = to teach more classes.=C2=A0 =C2=A0One of the people from Google has also o= ffered to teach.=C2=A0 =C2=A0Also talking to ISOC about publicizing.=C2=A0 = =C2=A0Don't we WANT enterprises learning about and using IPv6?=C2=A0 =C2=A0= Hopefully, then these people will engage in the IETF also as a result.=C2= =A0 As I say, if you want to help / sit in / teach, please let me know.=C2= =A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Paul Wouters ; Hrpc Sent: Friday, November 16, 2018 7:07 AM Subject: Re: [hrpc] "We try to avoid" =20 You described an attack on IETF process where corporations send so many par= ticipants to the organization with the intention of overriding the consensu= s process that they succeed in doing so. On Fri, Nov 16, 2018 at 10:04 AM Nalini J Elkins wrote: > exactly the attack you're describing Excuse me?=C2=A0 What is the "attack"?=C2=A0 I have lost you here.=C2=A0Tha= nks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Ted Lemon To: Nalini Elkins =20 Cc: Paul Wouters ; Hrpc Sent: Friday, November 16, 2018 6:59 AM Subject: Re: [hrpc] "We try to avoid" =20 On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins wrote: >=C2=A0Can you unpack the distinction for me?=C2=A0 My comment had absolutely nothing to do with TLS in particular. Perhaps not, but it clearly applies to the TLS working group as well as any= other. The IETF consensus process is very deliberately designed to address exactly= the attack you're describing.=C2=A0 =C2=A0It is true that the firewall is = not perfect, but it's better than any other SDO's firewall against the same= problem; most SDOs actually consider this a feature, not a bug.___________= ____________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 =20 ------=_Part_1649302_435834424.1542383177358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> This is a very weird conv= ersation.   

Yes.

> I think we agree that we want operators to p= articipate in the IETF, and that includes enterprise operators.

Gr= eat!
 
Thanks,

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


From: Ted Lemon <mellon@fugue.com>
To: Nalini Elkins <nalini.elkins@insideth= estack.com>
Cc: Pau= l Wouters <paul@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16, 2018 7:44= AM
Subject: Re: [hrpc= ] "We try to avoid"

<= div id=3D"yiv6639965846">
This is a very weird convers= ation.   I think we agree that there is a potential for this atta= ck.    I think we agree that it's not inevitable.   I t= hink we agree that we should try to avoid such attacks.   I think= we agree that we want operators to participate in the IETF, and that inclu= des enterprise operators.

My concern is t= hat I'd really like to avoid a situation where we wind up doing things that= don't make sense technically because it's more convenient than implementin= g the right technical solution.

On Fri, Nov 16, 2018 at 10:34 AM Na= lini J Elkins <nalini.elkins@insidethestack.com> wrote:
> where corporations send so many participants to= the organization with the intention of overriding the consensus process th= at they succeed in doing so.

Actually, these people would then be activ= e participants in the IETF, would they not?   Also, you have far = more faith in my abilities than I do.    If I only had the eloque= nce to convince all these corporate heads to give me money and people to pu= ll off such a tactic!  Also, if I had the eloquence to make everyone t= hink all in the same way.   Enterprises are not a *block*.  = They actually have different opinions.

Also, why a= re not other companies who send many people attackers?  If, for exampl= e, company x sends 50 people, do they all go from room to room humming in u= nison?  Is that what you are proposing that we do?

Why would you NOT want more pe= ople participating in the process?  That is my goal!   If yo= u would like to sit in on the training and other sessions that I do to teac= h people from organizations how to participate in the IETF, you are more th= an welcome.
=
BTW, I j= ust taught a class / lab on IPv6 where over 132 people from 70+ companies s= igned up.   Lee Howard will be working with me next year to teach= more classes.   One of the people from Google has also offered t= o teach.   Also talking to ISOC about publicizing.   Do= n't we WANT enterprises learning about and using IPv6?   Hopefull= y, then these people will engage in the IETF also as a result.  As I s= ay, if you want to help / sit in / teach, please let me know.=
 
Thanks,

Nali= ni Elkins
CEO and Founder
Inside Produc= ts, Inc.
www.insidethestack.com
(831) 659-8360


From: Ted Lemon <mellon@fugue.com>
To: Nalini El= kins <nalini.elkins@insidethestack.com>
Cc: Paul Wouters <paul@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16= , 2018 7:07 AM
Subj= ect: Re: [hrpc] "We try to avoid"

You described an attack on IETF process where corporations sen= d so many participants to the organization with the intention of overriding= the consensus process that they succeed in doing so.

On Fri, Nov 16, 2018 at 10:04 AM Nalini J Elkins <nalini.el= kins@insidethestack.com> wrote:
> exactly the attack you're describing
=

Excuse me?  What is the "att= ack"?  I have lost you here.
 
Thanks,

Nalini Elkin= s
CEO and Founder
Inside Products, Inc.=
www.insidethestack.com
(831) 659-8360


From: Ted Lemon <mellon@fugue.com>
= To: Nalini Elkins <= nalini.elkins@insidethestack.com>
Cc: Paul Wouters <paul@nohats.ca>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16, 2018 6:59 AM=
Subject: Re: [hrpc] "We try to avoid"

On Fri, Nov 16, 2018 at 9:53 AM Nalini J Elkins = <nalini.elkins@insidethestack.com> wrote:
<= /div>
> Can= you unpack the distinction for me? 
=
My comment had absolutely no= thing to do with TLS in particular.

Perhaps not, but it clearly applies = to the TLS working group as well as any other.

The IETF consensus process is very deliberately designed to add= ress exactly the attack you're describing.   It is true that the = firewall is not perfect, but it's better than any other SDO's firewall agai= nst the same problem; most SDOs actually consider this a feature, not a bug= .
____________________________________________= ___
hrpc mailing list
<= /div>
_______________________________________________
hrpc mailing list
hrpc@irtf.org
https= ://www.irtf.org/mailman/listinfo/hrpc




------=_Part_1649302_435834424.1542383177358-- From nobody Fri Nov 16 07:51:06 2018 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 C9D0F12DD85 for ; Fri, 16 Nov 2018 07:51:04 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 oL244RM2kyN9 for ; Fri, 16 Nov 2018 07:51:02 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 B994B12D4EC for ; Fri, 16 Nov 2018 07:51:02 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gNgOa-0002Cd-BO; Fri, 16 Nov 2018 16:51:00 +0100 To: Stephen Farrell , hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> Date: Fri, 16 Nov 2018 18:50:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OVS6lIpVdQy1Pf2AXlBSUOX0rRqOtAMed" X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 246115766b56dba7f675551df821dbd2 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 15:51:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OVS6lIpVdQy1Pf2AXlBSUOX0rRqOtAMed Content-Type: multipart/mixed; boundary="68HoKVxBVyqLByAiRoPkl7zFzehGkBK48"; protected-headers="v1" From: Mallory Knodel To: Stephen Farrell , hrpc@irtf.org Message-ID: <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> Subject: Re: [hrpc] "We try to avoid" References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> In-Reply-To: --68HoKVxBVyqLByAiRoPkl7zFzehGkBK48 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 16/11/2018 00:59, Stephen Farrell wrote: > On 15/11/2018 07:50, Mallory Knodel wrote: >> But just wondering, what is the original purpose of that statement? >=20 > I think the idea was that it's better (in general) to > develop IETF technologies that interoperate and can be > used with many policies and business/operations models > and to not develop protocols that are specific to one > or a few policies or business models. That makes sense. There are some cases where specific policies are the impetus for a standard and that raised concerns. > That doesn't mean we have to be pseudo-neutral and claim > that all policies and business models are equally ok, but > it does mean we don't need to reach consensus on our > opinions of them. Maybe we do, but in the larger context of also weighing policy against technology. And on a case by case basis, not simply as an exercise on its own. > I suspect there's also an element of it just being more > interesting and tractable for IETFers to stick to the more > fun technical stuff and to not have to deal with often > painful discussions that can be involved when mucking about > with (or stopping people mucking about with) protocols > for purely policy or business reasons. It's basically far > easier (in the IETF) to debate the size of packets and > similar than it is to discuss why someone would want to > do something like break TLS or make money from ad auctions > that expose huge amounts of user data to all bidders. What about the idea of just removing this sentence then? It happens, but not in any unified way, and on a case-by-case basis and so perhaps it's just better not to dwell on whether or not we "do" this and just edit it out. -Mallory --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --68HoKVxBVyqLByAiRoPkl7zFzehGkBK48-- --OVS6lIpVdQy1Pf2AXlBSUOX0rRqOtAMed Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlvu514ACgkQDDKicb08 x4DbbAf/Q+HfOIEaHq5FYP8pv2+6D7wnQmkQy3icVcYqdLPH8l/tEKLu85lZYz5J PysYSNHToewyC6ZYVuoSjdTyJo4lXlK3BmKlsM1/IG2Yvr1g/oKWDR2qSDOvu+jl +WLAmLmtlGWaos1lxxTmjSnXzA7xg3H86Ehbf5quefLBeZI4kGISOGNOkqXX97Zq ac1knIXAEy/t16DZsPrIPwdzZ46mg0QyCWwtk2SnkJIuMC6+Yn3/nYFpPjxQY3DQ 49S/tTDi79P4wjxmC7m0CATwmHd8Pj7ewMzPuWlp/+Erkz2jovf3tlUm6fn7fPbN EF7xBFJscOJVaq12YuvIUOBgc5yMkw== =lmbh -----END PGP SIGNATURE----- --OVS6lIpVdQy1Pf2AXlBSUOX0rRqOtAMed-- From nobody Fri Nov 16 08:04:22 2018 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 24AA1130934 for ; Fri, 16 Nov 2018 08:04:21 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 1MbyXMOS_rrm for ; Fri, 16 Nov 2018 08:04:19 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 1151512D4E7 for ; Fri, 16 Nov 2018 08:04:19 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id r71so38123211qkr.10 for ; Fri, 16 Nov 2018 08:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dZFuOOsrcLxoR1ya6a2Hww2vhZGO4mTKo0r2gTUcC/k=; b=TzedBQ/DOHJKRibL+WxuUciSTY9LZqV62qD9Vmhen0vka7QkZP5Th92GO240OiWLp9 qP0OuR+4gD15BegXkJf4X7JGEwEYTtWKMhdFFhTiTSfQpG//6NtMCvbTXFN5+nb82n91 Omghgp3aJWvE6hsmOEnWZu3XxfgW2hO6zG1PQ9cLzhST6nUjZuqMHI3VNtBAu92PmGHg TE4L3rAALlHxZc33bPh2rXyj2hnMZy5T1RKVfSa1hOvW9VCCAooVOIbNUPjxypRVM5xk N7yDIpb2X2nG0MrY/NNQMm6Iz6iYIS7vGImSDzh0wdsLwVN2O036jlLflsFW67VtRSmc 5j7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dZFuOOsrcLxoR1ya6a2Hww2vhZGO4mTKo0r2gTUcC/k=; b=jsQshYxvthO8AQVfMN+Cm4v6oK9z919XAysU7lFeVFb+X9Zgq46Fo1RAehn9ZLRsd5 3pNjlAYdG+0f8q/0mlabXDkKO0lvEaIzqD+cXgsMCF6n4pWuMSgLQEip0i3h/+9M9xAY VIDaWqBhV4ugJcEbxOm1qOzmVb94GgDiOA0GuY1+ghXTX8iQ5jXLJhLB+Nq4PRylLdh4 ejHQ7Bvrr9cfaahk+IfZpsVcm/i60lq0SZAFY0Zr6o3bIooCN6/pAs1fBcv1WtsaRkWF h9KdauDcLh4qux8j3qNXd2EKeF6s4mNsl49y6Sv490OsQWFNj7u448PTRzkyPa0lNNag BNDw== X-Gm-Message-State: AGRZ1gLvAbeaBVIUy4C+cBex5rZerHxcjF5IU4qHwWh60J0kuQtuT9YA VSNUgQoP+OJPLboe7y30roJb+ajh62QSpnEqURn5oX3z9rA= X-Google-Smtp-Source: AJdET5eccFZzyz3xWSpvUKOyAwvAmECD5weDgJfCDlHwSIEoC2rQeNnn/eRJYiZ5tgUWB9V0WkcSsB1MB2T4zQjjLnY= X-Received: by 2002:a37:c12:: with SMTP id 18mr10419780qkm.317.1542384258095; Fri, 16 Nov 2018 08:04:18 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> In-Reply-To: <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> From: Ted Lemon Date: Fri, 16 Nov 2018 11:03:41 -0500 Message-ID: To: Mallory Knodel Cc: Stephen Farrell , Hrpc Content-Type: multipart/alternative; boundary="000000000000cfb8cd057aca51ac" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 16:04:21 -0000 --000000000000cfb8cd057aca51ac Content-Type: text/plain; charset="UTF-8" I'm sorry, but I totally disagree on removing the sentence. The fact that we are having this conversation is evidence that the sentence is referring to a real and relevant phenomenon. A better approach to this from the perspective of doing research into protocol considerations for human rights would be to write a document describing the issue. It's clear that there's substantial nuance to this, and it would be good to capture that in a document. On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel wrote: > On 16/11/2018 00:59, Stephen Farrell wrote: > > On 15/11/2018 07:50, Mallory Knodel wrote: > >> But just wondering, what is the original purpose of that statement? > > > > I think the idea was that it's better (in general) to > > develop IETF technologies that interoperate and can be > > used with many policies and business/operations models > > and to not develop protocols that are specific to one > > or a few policies or business models. > > That makes sense. There are some cases where specific policies are the > impetus for a standard and that raised concerns. > > > That doesn't mean we have to be pseudo-neutral and claim > > that all policies and business models are equally ok, but > > it does mean we don't need to reach consensus on our > > opinions of them. > > Maybe we do, but in the larger context of also weighing policy against > technology. And on a case by case basis, not simply as an exercise on > its own. > > > I suspect there's also an element of it just being more > > interesting and tractable for IETFers to stick to the more > > fun technical stuff and to not have to deal with often > > painful discussions that can be involved when mucking about > > with (or stopping people mucking about with) protocols > > for purely policy or business reasons. It's basically far > > easier (in the IETF) to debate the size of packets and > > similar than it is to discuss why someone would want to > > do something like break TLS or make money from ad auctions > > that expose huge amounts of user data to all bidders. > > What about the idea of just removing this sentence then? > > It happens, but not in any unified way, and on a case-by-case basis and > so perhaps it's just better not to dwell on whether or not we "do" this > and just edit it out. > > -Mallory > > -- > Mallory Knodel > Head of Digital :: article19.org > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000cfb8cd057aca51ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry, but I totally disagree on removing the sent= ence.=C2=A0 =C2=A0The fact that we are having this conversation is evidence= that the sentence is referring to a real and relevant phenomenon.=C2=A0 = =C2=A0A better approach to this from the perspective of doing research into= protocol considerations for human rights would be to write a document desc= ribing the issue.=C2=A0 =C2=A0It's clear that there's substantial n= uance to this, and it would be good to capture that in a document.
On Fri, Nov 16, 2018 at 10:51 = AM Mallory Knodel <mallory@arti= cle19.org> wrote:
On 16/11= /2018 00:59, Stephen Farrell wrote:
> On 15/11/2018 07:50, Mallory Knodel wrote:
>> But just wondering, what is the original purpose of that statement= ?
>
> I think the idea was that it's better (in general) to
> develop IETF technologies that interoperate and can be
> used with many policies and business/operations models
> and to not develop protocols that are specific to one
> or a few policies or business models.

That makes sense. There are some cases where specific policies are the
impetus for a standard and that raised concerns.

> That doesn't mean we have to be pseudo-neutral and claim
> that all policies and business models are equally ok, but
> it does mean we don't need to reach consensus on our
> opinions of them.

Maybe we do, but in the larger context of also weighing policy against
technology. And on a case by case basis, not simply as an exercise on
its own.

> I suspect there's also an element of it just being more
> interesting and tractable for IETFers to stick to the more
> fun technical stuff and to not have to deal with often
> painful discussions that can be involved when mucking about
> with (or stopping people mucking about with) protocols
> for purely policy or business reasons. It's basically far
> easier (in the IETF) to debate the size of packets and
> similar than it is to discuss why someone would want to
> do something like break TLS or make money from ad auctions
> that expose huge amounts of user data to all bidders.

What about the idea of just removing this sentence then?

It happens, but not in any unified way, and on a case-by-case basis and
so perhaps it's just better not to dwell on whether or not we "do&= quot; this
and just edit it out.

-Mallory

--
Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9=C2=A0 B071 0C32 A271 BD3C C780<= br>
_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000cfb8cd057aca51ac-- From nobody Fri Nov 16 08:09:51 2018 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 59628130934 for ; Fri, 16 Nov 2018 08:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=1.5, T_SPF_PERMERROR=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 WN5eGB0KmE_F for ; Fri, 16 Nov 2018 08:09:48 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61D012F1AB for ; Fri, 16 Nov 2018 08:09:48 -0800 (PST) Received: from fifthhorseman.net (NYUFWA-GUESTS-01.NATPOOL.NYU.EDU [192.76.177.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 1E192F99B; Fri, 16 Nov 2018 11:09:46 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id BAFAE202A8; Fri, 16 Nov 2018 10:38:34 -0500 (EST) From: Daniel Kahn Gillmor To: Ted Lemon Cc: Hrpc In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <1044765548.1272128.1542313543430@mail.yahoo.com> <87k1ldqelm.fsf@fifthhorseman.net> Date: Fri, 16 Nov 2018 10:38:28 -0500 Message-ID: <87h8ghqbgr.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 16:09:50 -0000 --=-=-= Content-Type: text/plain On Fri 2018-11-16 09:46:32 -0500, Ted Lemon wrote: > Hm. I think that the decision we made has clear policy implications, > sure. But was the reason we made it because of those policy implications? yes. the policy outcome that we preferred is: TLS is an end-to-end protocol with the strongest known cryptographic protections for application data confidentiality, and we want to prioritize this capacity so that people can rely on TLS for confidentiality as robustly as possible. Note that this is also a technical argument. The labels "technical" and "policy" aren't mutually-exclusive, which points to at least one problem with my proposed text. > From my perspective, the reason for rejecting it was that it was > technically bad: it created an attack surface that could only be mitigated > by user action, which as we know from painful experience means an attack > surface that can't be mitigated. I agree with this too :) > I don't really like your proposed text. I think we do appreciate it when > people raise their non-technical concerns, but I also don't think we can > always address their non-technical concerns, and we ought not to suggest > otherwise. Does my text claim that we can always address every concern raised? I didn't intend that, and would welcome edits that made that clearer, if you're interested. > Sometimes the right way to mitigate the problem with a particular tool > for a particular set of use cases is not to change the tool, but to > have a second tool. I also agree with this, though understanding which tool is the right tool for any specific context requires understanding the technical, political, and business impacts of the different tools. That means we need to make those tradeoffs as explicit as possible, if we want people to be able to use the protocols we design effectively. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCW+7kdAAKCRBsHx7ezFD6 U87BAQCHEpE07LsTH0Ox6fLOJxzLkn7C4wpdzIQ6RyFfBd1N1AD8CsA2qOe5zwdW Wqp6UyCOZqo55j+t/yNIIJIehGp6mwM= =hSsR -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 16 08:10:21 2018 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 1E38A130934 for ; Fri, 16 Nov 2018 08:10:20 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQk3V_N5jD_Q for ; Fri, 16 Nov 2018 08:10:18 -0800 (PST) Received: from sonic314-26.consmr.mail.ne1.yahoo.com (sonic314-26.consmr.mail.ne1.yahoo.com [66.163.189.152]) (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 47E62130DC5 for ; Fri, 16 Nov 2018 08:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542384616; bh=cyK1tq6SAkTwkrRtP9Be099K0NeBCBdtsRHvVr/gDP0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=BuZnTkAzhIcnvsPIF6D4rKPXglVeWBFq6naIQ+bgauFb73GyTOjEwgSt2gsmzvJ8DJ7LmApD+t0hT15DM70QOMcIZqxtCPCXP/eWbzkBmFOTnlNj5eOzU5C4Lf4UR3yaKt100rVjkO7pNjWuQZDlcrdCmQI3Uk6KddN5r35cjMPNdVuQK9oIpD0tSIRc2OtCAqDFt8vQXq2nDDK1SkwoFpBs9+Ghy66bWIydRBzJfchI6BdUClfbvV8MHlD9f+MaJ/pfdZhQ3krQLbnHjvm57dYZHb5AmaHqIQ8bCqk8zreh2vkoh2cX/wLyfH334Om95OjaILRbc4Jv/3wsGY13ug== X-YMail-OSG: E7v_ZLkVM1m4Vc7SB_4SIOWLiPbom72ma8mbB0QLnnyhf_M8fWKZRNPVEXhUnnd 5_4YDCjlkFmlu2rwU6JebSH.VSXi48yjncbiJpjgyqWd4gNhLW8fotSb4s3NiAHzaaVbnoezGnlV dsXXdXM1MYSLGoLnviGm3jRS4lDxPNQnoaO9JV0xYROMwte_sulm6nijSBFbCnm39PQIAmA.x1fU zsPqGHUm.ElmWSF5KXMaN1UEQaUQpwCk6G8app8nNciOvDrxkdFa8E4MNv1BXLJqOgy1JMb6lyXX mxBSYXPji0pMzpWAEFEs5EBwBW_fdWOWjEX86z1RU90q8m3FeHAek.euIpa8pr8tYZ0IWzureSKY VQaTh4XSuYnnzh6wwQDDVPXpWj2qy7ege.r4NaudlcDEFzj6Sh6uV70fcwNktd38u6xsajh00QJA .CZs569RZbBjza3ubmyyuT_kGg8qaPbEfSY0LkNJwGwlKnyGsQt8uyD6aBKqIrsRLZsPWqgTR7pl F.oXt025xuz4QEF5em0MZmhBtvkmsdELWSGx9KPjIApbRY3NCNJ1hLi_QptinD09mMc6PXgcrP3k FuyKGL9T9IkJoMjTB_qxunZd6w1VNIHW2f4dVi79hsehhp0M9_U0GDyCpx4YgzhfVTc73.triqoI sowVBRDLRjPrdEdnpfJ816gyIGt4v5RIr6tnHE4bVKQOQp6G4rqYaruogNJXUBsh17q_Lk0BMn7H aq6SZuiiLjCU9LBeb8kYlpi_.JxHMQof27uXV7OpxznuIrJQPloUvTelWtXBaGMlnkWMtqf14Urj jec4WgiBykXolCBzsogfcOrV9pObDIDg0y2Iuj6bcUMJjHpxLJq3WHNtMnxkv2vK3mtWuqNHl84B jQHkD0u3KyeCn6XsDqL9.AaVVKMHwsfgnYI6VX3w6TqRudWhoNjgRz.wyj9KG2x4SVeqbPRsW0nX MNvailjO8e85apkKQQCoEy0WWzx.2OSmAIUkv2zqnZFHgS1XUzBXoXFl6BdWXk34lJJ1Pbs08Qhe RCU_T3EEK9YBrw35fUAagXFfug6ZdrgRyrBbfXOX.XvMdIyi_OMnlIK4w7RrXXgUvvoDCUaf1vg- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 16 Nov 2018 16:10:16 +0000 Date: Fri, 16 Nov 2018 16:09:58 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Ted Lemon , Mallory Knodel Cc: Hrpc , Stephen Farrell Message-ID: <1704610958.1701776.1542384598448@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 16:10:20 -0000 Ted, > A better approach to this from the perspective of doing research into protocol considerations for human rights would be to write a document > describing the issue. It's clear that there's substantial nuance to this, OK, everyone sit down! Ted, you and I are in substantial agreement on this. But, guys, I was reflecting last night and wondering if actually what we need is something like a new RG. That is "Business Considerations" just as we have "Privacy Considerations". (Then I got exhausted just thinking about it!) I don't know that this is really a human rights issue. But it is an issue and a big one. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Ted Lemon To: Mallory Knodel Cc: Hrpc ; Stephen Farrell Sent: Friday, November 16, 2018 8:04 AM Subject: Re: [hrpc] "We try to avoid" I'm sorry, but I totally disagree on removing the sentence. The fact that we are having this conversation is evidence that the sentence is referring to a real and relevant phenomenon. A better approach to this from the perspective of doing research into protocol considerations for human rights would be to write a document describing the issue. It's clear that there's substantial nuance to this, and it would be good to capture that in a document. On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel wrote: On 16/11/2018 00:59, Stephen Farrell wrote: >> On 15/11/2018 07:50, Mallory Knodel wrote: >>> But just wondering, what is the original purpose of that statement? >> >> I think the idea was that it's better (in general) to >> develop IETF technologies that interoperate and can be >> used with many policies and business/operations models >> and to not develop protocols that are specific to one >> or a few policies or business models. > >That makes sense. There are some cases where specific policies are the >impetus for a standard and that raised concerns. > >> That doesn't mean we have to be pseudo-neutral and claim >> that all policies and business models are equally ok, but >> it does mean we don't need to reach consensus on our >> opinions of them. > >Maybe we do, but in the larger context of also weighing policy against >technology. And on a case by case basis, not simply as an exercise on >its own. > >> I suspect there's also an element of it just being more >> interesting and tractable for IETFers to stick to the more >> fun technical stuff and to not have to deal with often >> painful discussions that can be involved when mucking about >> with (or stopping people mucking about with) protocols >> for purely policy or business reasons. It's basically far >> easier (in the IETF) to debate the size of packets and >> similar than it is to discuss why someone would want to >> do something like break TLS or make money from ad auctions >> that expose huge amounts of user data to all bidders. > >What about the idea of just removing this sentence then? > >It happens, but not in any unified way, and on a case-by-case basis and >so perhaps it's just better not to dwell on whether or not we "do" this >and just edit it out. > >-Mallory > >-- >Mallory Knodel >Head of Digital :: article19.org >gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > >_______________________________________________ >hrpc mailing list >hrpc@irtf.org >https://www.irtf.org/mailman/listinfo/hrpc > _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc From nobody Fri Nov 16 08:13:54 2018 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 B3892130934 for ; Fri, 16 Nov 2018 08:13:52 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 bhPEbNUgOb8c for ; Fri, 16 Nov 2018 08:13:50 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 28DB412F1AB for ; Fri, 16 Nov 2018 08:13:50 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id y16so38223649qki.7 for ; Fri, 16 Nov 2018 08:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l9ywIRgUN+aHPGrqM8O7Hau+XTu4VXQ1h5GGX+tgr7w=; b=0aZrbbpgYpLnPH2cA9eHtdt6C3J2LTMj1j2feGEB7BNvMY33eEGTODBFvqFgfyqXzp z37dMxao+7/eAJjGhzK4LPK4bgwzjTlqBgSOOqL5Vc8tYcP312MNN5DrV8mHXpmTLjI0 KwPf0UoX7GrK+1d/e2FIaKDY4jwrrLrpyDlTjhplyEVKJDYb5WQBRaGAg0HKoKquNz2J WU2V7817r4jAIlt6zJJTLMHKdPNJgBLXhtC+CW35N/XDj5sPg+/TarCEXf5/DI0DjYXO rO1MCsoNDDRYrF7JGFfWmouL/EYAZKKf49fON7yZ56vXjEXx4XvoAzll/VtSVL2HgzGv iG4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l9ywIRgUN+aHPGrqM8O7Hau+XTu4VXQ1h5GGX+tgr7w=; b=Ws51bRRBXtmf9xydELgVTcCBFai1bEaTTDHR9VwNMI//il3xKhiqHWhxQYTt3Yzdle NKaWPmXOicc4auqIggQopPDrQsV2MkGRqHg4zm01nI/yMgbJUjRIM0Fg9H5iwD3h/bRm O+0Wcv9MwyqZgg+vCoTsHreVZwv6yAoou1beqcF+JFvXfjsuVYftwld+6xeYC6gFlMQa aGGvOElBbetU2pHvD/ghhaOhoZxxGyXT2t3mRdUe4oEuac5/YSCebau9QGhdRhenYoyn ZeBaV6moYO00f1sPnxDZ47fo4QEpvrGDhV9oqGT6YYEl5d14hSztmdGY/fqSyjMLV6Eo 1zBw== X-Gm-Message-State: AGRZ1gIap2SdGOWtmhIObboYxQzkmodn/4+t2Ny21aMmrWqHwh9Kgjbw +8uJCJauNDs2deCbCCkL29hsmZVcC0S+Nk5Cy/LYJcxLzVs= X-Google-Smtp-Source: AFSGD/X3y0QKRDzQIhJ3MC/4IfygVhNmwKsbgqp77IFE//vehIaBKf7Z96kXMVLTOdTUFK/dyMxoyoxIMTANdiDySPk= X-Received: by 2002:ac8:7181:: with SMTP id w1mr4079493qto.271.1542384829215; Fri, 16 Nov 2018 08:13:49 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> <1704610958.1701776.1542384598448@mail.yahoo.com> In-Reply-To: <1704610958.1701776.1542384598448@mail.yahoo.com> From: Ted Lemon Date: Fri, 16 Nov 2018 11:13:12 -0500 Message-ID: To: Nalini Elkins Cc: Mallory Knodel , Hrpc , Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000da5bce057aca7300" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 16:13:53 -0000 --000000000000da5bce057aca7300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think forking more irtf working groups on hrpc-related topics is not going to work=E2=80=94I had to miss several meetings of this sort in Bangko= k due to conflicts, including the second session of hrpc, and I'm sure I'm not alone in that. I do sort of agree that this is out of the current scope, though. What do the chairs think about this? On Fri, Nov 16, 2018 at 11:10 AM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > Ted, > > > > A better approach to this from the perspective of doing research into > protocol considerations for human rights would be to write a document > > describing the issue. It's clear that there's substantial nuance to thi= s, > > OK, everyone sit down! Ted, you and I are in substantial agreement on > this. > > But, guys, I was reflecting last night and wondering if actually what we > need is something like a new RG. That is "Business Considerations" just = as > we have "Privacy Considerations". (Then I got exhausted just thinking > about it!) > > I don't know that this is really a human rights issue. But it is an issu= e > and a big one. > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ________________________________ > From: Ted Lemon > To: Mallory Knodel > Cc: Hrpc ; Stephen Farrell > Sent: Friday, November 16, 2018 8:04 AM > Subject: Re: [hrpc] "We try to avoid" > > > > I'm sorry, but I totally disagree on removing the sentence. The fact > that we are having this conversation is evidence that the sentence is > referring to a real and relevant phenomenon. A better approach to this > from the perspective of doing research into protocol considerations for > human rights would be to write a document describing the issue. It's > clear that there's substantial nuance to this, and it would be good to > capture that in a document. > > On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel > wrote: > > On 16/11/2018 00:59, Stephen Farrell wrote: > >> On 15/11/2018 07:50, Mallory Knodel wrote: > >>> But just wondering, what is the original purpose of that statement? > >> > >> I think the idea was that it's better (in general) to > >> develop IETF technologies that interoperate and can be > >> used with many policies and business/operations models > >> and to not develop protocols that are specific to one > >> or a few policies or business models. > > > >That makes sense. There are some cases where specific policies are the > >impetus for a standard and that raised concerns. > > > >> That doesn't mean we have to be pseudo-neutral and claim > >> that all policies and business models are equally ok, but > >> it does mean we don't need to reach consensus on our > >> opinions of them. > > > >Maybe we do, but in the larger context of also weighing policy against > >technology. And on a case by case basis, not simply as an exercise on > >its own. > > > >> I suspect there's also an element of it just being more > >> interesting and tractable for IETFers to stick to the more > >> fun technical stuff and to not have to deal with often > >> painful discussions that can be involved when mucking about > >> with (or stopping people mucking about with) protocols > >> for purely policy or business reasons. It's basically far > >> easier (in the IETF) to debate the size of packets and > >> similar than it is to discuss why someone would want to > >> do something like break TLS or make money from ad auctions > >> that expose huge amounts of user data to all bidders. > > > >What about the idea of just removing this sentence then? > > > >It happens, but not in any unified way, and on a case-by-case basis and > >so perhaps it's just better not to dwell on whether or not we "do" this > >and just edit it out. > > > >-Mallory > > > >-- > >Mallory Knodel > >Head of Digital :: article19.org > >gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > > > >_______________________________________________ > >hrpc mailing list > >hrpc@irtf.org > >https://www.irtf.org/mailman/listinfo/hrpc > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000da5bce057aca7300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think forking more irtf working groups on hrpc-related t= opics is not going to work=E2=80=94I had to miss several meetings of this s= ort in Bangkok due to conflicts, including the second session of hrpc, and = I'm sure I'm not alone in that.

I do sort of agr= ee that this is out of the current scope, though.=C2=A0 =C2=A0What do the c= hairs think about this?

On Fri, Nov 16, 2018 at 11:10 AM Nalini J Elkins <nalini.elkins@insidethestack.com= > wrote:
Ted,


> A better approach to this from the perspective of doing research into = protocol considerations for human rights would be to write a document
> describing the issue. It's clear that there's substantial nuan= ce to this,

OK, everyone sit down!=C2=A0 =C2=A0Ted, you and I are in substantial agreem= ent on this.

But, guys, I was reflecting last night and wondering if actually what we ne= ed is something like a new RG.=C2=A0 That is "Business Considerations&= quot; just as we have "Privacy Considerations".=C2=A0 (Then I got= exhausted just thinking about it!)

I don't know that this is really a human rights issue.=C2=A0 But it is = an issue and a big one.
Thanks,

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



________________________________
From: Ted Lemon <m= ellon@fugue.com>
To: Mallory Knodel <mallory@article19.org>
Cc: Hrpc <hrpc@irtf.o= rg>; Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sent: Friday, November 16, 2018 8:04 AM
Subject: Re: [hrpc] "We try to avoid"



I'm sorry, but I totally disagree on removing the sentence.=C2=A0 =C2= =A0The fact that we are having this conversation is evidence that the sente= nce is referring to a real and relevant phenomenon.=C2=A0 =C2=A0A better ap= proach to this from the perspective of doing research into protocol conside= rations for human rights would be to write a document describing the issue.= =C2=A0 =C2=A0It's clear that there's substantial nuance to this, an= d it would be good to capture that in a document.

On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel <mallory@article19.org> wrote:
On 16/11/2018 00:59, Stephen Farrell wrote:
>> On 15/11/2018 07:50, Mallory Knodel wrote:
>>> But just wondering, what is the original purpose of that state= ment?
>>
>> I think the idea was that it's better (in general) to
>> develop IETF technologies that interoperate and can be
>> used with many policies and business/operations models
>> and to not develop protocols that are specific to one
>> or a few policies or business models.
>
>That makes sense. There are some cases where specific policies are the<= br> >impetus for a standard and that raised concerns.
>
>> That doesn't mean we have to be pseudo-neutral and claim
>> that all policies and business models are equally ok, but
>> it does mean we don't need to reach consensus on our
>> opinions of them.
>
>Maybe we do, but in the larger context of also weighing policy against<= br> >technology. And on a case by case basis, not simply as an exercise on >its own.
>
>> I suspect there's also an element of it just being more
>> interesting and tractable for IETFers to stick to the more
>> fun technical stuff and to not have to deal with often
>> painful discussions that can be involved when mucking about
>> with (or stopping people mucking about with) protocols
>> for purely policy or business reasons. It's basically far
>> easier (in the IETF) to debate the size of packets and
>> similar than it is to discuss why someone would want to
>> do something like break TLS or make money from ad auctions
>> that expose huge amounts of user data to all bidders.
>
>What about the idea of just removing this sentence then?
>
>It happens, but not in any unified way, and on a case-by-case basis and=
>so perhaps it's just better not to dwell on whether or not we "= ;do" this
>and just edit it out.
>
>-Mallory
>
>--
>Mallory Knodel
>Head of Digital :: article19.org
>gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9=C2=A0 B071 0C32 A271 BD3C C= 780
>
>_______________________________________________
>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
--000000000000da5bce057aca7300-- From nobody Fri Nov 16 09:17:20 2018 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 BB664130DFA for ; Fri, 16 Nov 2018 09:17:18 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 FaHF5attELuj for ; Fri, 16 Nov 2018 09:17:15 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 9D830130DF1 for ; Fri, 16 Nov 2018 09:17:15 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gNhk0-0005eC-DG for hrpc@irtf.org; Fri, 16 Nov 2018 18:17:13 +0100 To: hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= xsFNBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABzShOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+wsGZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI87BTQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAcLBZQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Fri, 16 Nov 2018 18:17:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 98cd051f671ee36aeaf0d6c34a549736 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 17:17:19 -0000 On 11/16/18 5:03 PM, Ted Lemon wrote: > I'm sorry, but I totally disagree on removing the sentence.   The fact that we are having this conversation is evidence that the sentence is referring to a real and relevant phenomenon.   A better approach to this from the perspective of doing research into protocol considerations for human rights would be to write a document describing the issue.   It's clear that there's substantial nuance to this, and it would be good to capture that in a document. Hi Ted, I would argue that this is exactly what draft-irtf-hrpc-political does: it outlines the inherent political and economical considerations in the standards process. Best, Niels > > On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel > wrote: > > On 16/11/2018 00:59, Stephen Farrell wrote: > > On 15/11/2018 07:50, Mallory Knodel wrote: > >> But just wondering, what is the original purpose of that statement? > > > > I think the idea was that it's better (in general) to > > develop IETF technologies that interoperate and can be > > used with many policies and business/operations models > > and to not develop protocols that are specific to one > > or a few policies or business models. > > That makes sense. There are some cases where specific policies are the > impetus for a standard and that raised concerns. > > > That doesn't mean we have to be pseudo-neutral and claim > > that all policies and business models are equally ok, but > > it does mean we don't need to reach consensus on our > > opinions of them. > > Maybe we do, but in the larger context of also weighing policy against > technology. And on a case by case basis, not simply as an exercise on > its own. > > > I suspect there's also an element of it just being more > > interesting and tractable for IETFers to stick to the more > > fun technical stuff and to not have to deal with often > > painful discussions that can be involved when mucking about > > with (or stopping people mucking about with) protocols > > for purely policy or business reasons. It's basically far > > easier (in the IETF) to debate the size of packets and > > similar than it is to discuss why someone would want to > > do something like break TLS or make money from ad auctions > > that expose huge amounts of user data to all bidders. > > What about the idea of just removing this sentence then? > > It happens, but not in any unified way, and on a case-by-case basis and > so perhaps it's just better not to dwell on whether or not we "do" this > and just edit it out. > > -Mallory > > -- > Mallory Knodel > Head of Digital :: article19.org > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9  B071 0C32 A271 BD3C C780 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Fri Nov 16 09:21:23 2018 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 41EEF1292AD for ; Fri, 16 Nov 2018 09:21:21 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 uvD1_V8Z19bo for ; Fri, 16 Nov 2018 09:21:18 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 5DE5C12426A for ; Fri, 16 Nov 2018 09:21:18 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id 189so38584323qkj.8 for ; Fri, 16 Nov 2018 09:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hkeElaJpMmamSu5R/yHh5c2Hv96ulAzRIOHfgIjzRHs=; b=htxMusINLC59Wop4HzXp2qXhFLyEPnufXXZJ8niXaR/qvFwuBxt+bJdRgaUkESukSg hG5uv2exBeSir3PWxj+7JD+FwVDy6d08i2ybrYRs+MZ6erjkmeWiV3sKl0GKPxQye3id dSShLZ6I/Jdw2vbvAW5s+cLNb2bw5/qxuTWMeLWgFzBSSRrVTjY2NGKhbqtFGLl+LGbW /phO3A4tK0bcufU2Bu6sypU57jaJj0+WH4SFNxHhaJh3UrSf/VXyFWIxTziIQX8CqaJn k1G2sekwDS8WhOOh8zAZgxmExjV7/S+/JYz1zKq2VeBzOa/jbQoKNuaiBxTY3scn+tvp lq0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hkeElaJpMmamSu5R/yHh5c2Hv96ulAzRIOHfgIjzRHs=; b=MpP4wgp+HpbnlmtNlg8mnYVpg1yBVxHECMTH3vcGirP70SUi1okxm4mQKcFuvY4mQ7 P2us8lgA9Jj2DtfnekEvGKEZBjm5DZSC/LrqRIfufx3XCgC6wo7poLgE+u3gFnte6Khj ArGHlDov65ctA/urGpgHwmVbUOOAAhz4ZS0grBKPaqVU/KowKjYoH4ZHvsKooh8tzFB7 rnXniefZb3UxIdG7mGr08rs76+OIE5UxpzeMa3JZnx/1Y/128SCwplZfLZ7wHVDQRD8+ lErXtMhYngDxXunXjLX9Dsk8tmXHyIpPk2qKSLgS/GlAXs8K2Lo7CxyHQ4TbbalE+L0a 1KfQ== X-Gm-Message-State: AGRZ1gKd+/mLEMVl4pjkZ87KixIre/X/9MmDgWkBKF63jiwVKx3Fn9xZ j7aAxje015KG9b4o//1xtgUqMPKxCUozvpnfGVIh1lUOvYU= X-Google-Smtp-Source: AJdET5c/qmZ7mioSV/fx8g4sK7Uk3yQ7V0GJ/UzK34OZypkbCDSqnZtFYUEB1clGDMxtWZ1BUYgpl5W5xhIjJJuwD4I= X-Received: by 2002:ac8:18fa:: with SMTP id o55mr11350970qtk.256.1542388877253; Fri, 16 Nov 2018 09:21:17 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <717979c7-fa53-4ca2-c97c-4c7cc12cb7b0@article19.org> In-Reply-To: From: Ted Lemon Date: Fri, 16 Nov 2018 12:20:41 -0500 Message-ID: To: Niels ten Oever Cc: Hrpc Content-Type: multipart/alternative; boundary="0000000000002273ab057acb6595" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 17:21:21 -0000 --0000000000002273ab057acb6595 Content-Type: text/plain; charset="UTF-8" I see why you are making this connection, but if that's the use case that you want hrpc-political to address, it needs a lot of work. I agree that there's an overlap, but I don't think that hrpc-political is directly addressing what Nalini is talking about, at least not as it is currently written. On Fri, Nov 16, 2018 at 12:17 PM Niels ten Oever wrote: > > > On 11/16/18 5:03 PM, Ted Lemon wrote: > > I'm sorry, but I totally disagree on removing the sentence. The fact > that we are having this conversation is evidence that the sentence is > referring to a real and relevant phenomenon. A better approach to this > from the perspective of doing research into protocol considerations for > human rights would be to write a document describing the issue. It's > clear that there's substantial nuance to this, and it would be good to > capture that in a document. > > Hi Ted, > > I would argue that this is exactly what draft-irtf-hrpc-political does: it > outlines the inherent political and economical considerations in the > standards process. > > Best, > > Niels > > > > > On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel > wrote: > > > > On 16/11/2018 00:59, Stephen Farrell wrote: > > > On 15/11/2018 07:50, Mallory Knodel wrote: > > >> But just wondering, what is the original purpose of that > statement? > > > > > > I think the idea was that it's better (in general) to > > > develop IETF technologies that interoperate and can be > > > used with many policies and business/operations models > > > and to not develop protocols that are specific to one > > > or a few policies or business models. > > > > That makes sense. There are some cases where specific policies are > the > > impetus for a standard and that raised concerns. > > > > > That doesn't mean we have to be pseudo-neutral and claim > > > that all policies and business models are equally ok, but > > > it does mean we don't need to reach consensus on our > > > opinions of them. > > > > Maybe we do, but in the larger context of also weighing policy > against > > technology. And on a case by case basis, not simply as an exercise on > > its own. > > > > > I suspect there's also an element of it just being more > > > interesting and tractable for IETFers to stick to the more > > > fun technical stuff and to not have to deal with often > > > painful discussions that can be involved when mucking about > > > with (or stopping people mucking about with) protocols > > > for purely policy or business reasons. It's basically far > > > easier (in the IETF) to debate the size of packets and > > > similar than it is to discuss why someone would want to > > > do something like break TLS or make money from ad auctions > > > that expose huge amounts of user data to all bidders. > > > > What about the idea of just removing this sentence then? > > > > It happens, but not in any unified way, and on a case-by-case basis > and > > so perhaps it's just better not to dwell on whether or not we "do" > this > > and just edit it out. > > > > -Mallory > > > > -- > > Mallory Knodel > > Head of Digital :: article19.org > > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > > > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > > > _______________________________________________ > > hrpc mailing list > > hrpc@irtf.org > > https://www.irtf.org/mailman/listinfo/hrpc > > > > -- > Niels ten Oever > Researcher and PhD Candidate > Datactive Research Group > University of Amsterdam > > PGP fingerprint 2458 0B70 5C4A FD8A 9488 > 643A 0ED8 3F3A 468A C8B3 > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --0000000000002273ab057acb6595 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see why you are making this connection, but if that'= s the use case that you want hrpc-political to address, it needs a lot of w= ork.=C2=A0 =C2=A0I agree that there's an overlap, but I don't think= that hrpc-political is directly addressing what Nalini is talking about, a= t least not as it is currently written.

On Fri, Nov 16, 2018 at 12:17 PM Niels ten Oever <mail@nielstenoever.net> wrote:=


On 11/16/18 5:03 PM, Ted Lemon wrote:
> I'm sorry, but I totally disagree on removing the sentence.=C2=A0 = =C2=A0The fact that we are having this conversation is evidence that the se= ntence is referring to a real and relevant phenomenon.=C2=A0 =C2=A0A better= approach to this from the perspective of doing research into protocol cons= iderations for human rights would be to write a document describing the iss= ue.=C2=A0 =C2=A0It's clear that there's substantial nuance to this,= and it would be good to capture that in a document.

Hi Ted,

I would argue that this is exactly what draft-irtf-hrpc-political does: it = outlines the inherent political and economical considerations in the standa= rds process.

Best,

Niels

>
> On Fri, Nov 16, 2018 at 10:51 AM Mallory Knodel <mallory@article19.org <mail= to:mallory@artic= le19.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 16/11/2018 00:59, Stephen Farrell wrote:
>=C2=A0 =C2=A0 =C2=A0> On 15/11/2018 07:50, Mallory Knodel wrote:
>=C2=A0 =C2=A0 =C2=A0>> But just wondering, what is the original p= urpose of that statement?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I think the idea was that it's better (in = general) to
>=C2=A0 =C2=A0 =C2=A0> develop IETF technologies that interoperate an= d can be
>=C2=A0 =C2=A0 =C2=A0> used with many policies and business/operation= s models
>=C2=A0 =C2=A0 =C2=A0> and to not develop protocols that are specific= to one
>=C2=A0 =C2=A0 =C2=A0> or a few policies or business models.
>
>=C2=A0 =C2=A0 =C2=A0That makes sense. There are some cases where specif= ic policies are the
>=C2=A0 =C2=A0 =C2=A0impetus for a standard and that raised concerns. >
>=C2=A0 =C2=A0 =C2=A0> That doesn't mean we have to be pseudo-neu= tral and claim
>=C2=A0 =C2=A0 =C2=A0> that all policies and business models are equa= lly ok, but
>=C2=A0 =C2=A0 =C2=A0> it does mean we don't need to reach consen= sus on our
>=C2=A0 =C2=A0 =C2=A0> opinions of them.
>
>=C2=A0 =C2=A0 =C2=A0Maybe we do, but in the larger context of also weig= hing policy against
>=C2=A0 =C2=A0 =C2=A0technology. And on a case by case basis, not simply= as an exercise on
>=C2=A0 =C2=A0 =C2=A0its own.
>
>=C2=A0 =C2=A0 =C2=A0> I suspect there's also an element of it ju= st being more
>=C2=A0 =C2=A0 =C2=A0> interesting and tractable for IETFers to stick= to the more
>=C2=A0 =C2=A0 =C2=A0> fun technical stuff and to not have to deal wi= th often
>=C2=A0 =C2=A0 =C2=A0> painful discussions that can be involved when = mucking about
>=C2=A0 =C2=A0 =C2=A0> with (or stopping people mucking about with) p= rotocols
>=C2=A0 =C2=A0 =C2=A0> for purely policy or business reasons. It'= s basically far
>=C2=A0 =C2=A0 =C2=A0> easier (in the IETF) to debate the size of pac= kets and
>=C2=A0 =C2=A0 =C2=A0> similar than it is to discuss why someone woul= d want to
>=C2=A0 =C2=A0 =C2=A0> do something like break TLS or make money from= ad auctions
>=C2=A0 =C2=A0 =C2=A0> that expose huge amounts of user data to all b= idders.
>
>=C2=A0 =C2=A0 =C2=A0What about the idea of just removing this sentence = then?
>
>=C2=A0 =C2=A0 =C2=A0It happens, but not in any unified way, and on a ca= se-by-case basis and
>=C2=A0 =C2=A0 =C2=A0so perhaps it's just better not to dwell on whe= ther or not we "do" this
>=C2=A0 =C2=A0 =C2=A0and just edit it out.
>
>=C2=A0 =C2=A0 =C2=A0-Mallory
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Mallory Knodel
>=C2=A0 =C2=A0 =C2=A0Head of Digital :: article19.org <http://article19.org= >
>=C2=A0 =C2=A0 =C2=A0gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9=C2=A0 B= 071 0C32 A271 BD3C C780
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0hrpc mailing list
>=C2=A0 =C2=A0 =C2=A0= hrpc@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
>

--
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint=C2=A0 =C2=A0 2458 0B70 5C4A FD8A 9488=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0643A 0= ED8 3F3A 468A C8B3

_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--0000000000002273ab057acb6595-- From nobody Fri Nov 16 19:36:11 2018 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 3C7EB130DC9 for ; Fri, 16 Nov 2018 19:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 3F6ly_kTAmc2 for ; Fri, 16 Nov 2018 19:36:07 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 27501128CF2 for ; Fri, 16 Nov 2018 19:36:07 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42xgjm3W9Nz3Dj; Sat, 17 Nov 2018 04:35:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542425761; bh=aG2lozjsFFhU54vFMQsyQEup5+wNyakqU4qMSAG9BvA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DU+JL4+rh+aEwozU6QUkWv4hjVbTjfNmeAcAkwIZc5ai7Tjf92aimkxUWhdXqBjlv FHklllrBkk68SceAsidrLXrqjDbtDbFdV3Bj974bavUSBD0LeRd3OmGuNxFuyNOe8+ DDwFQOGhZ+K1QYh3j8qCV64AVvgsAckCloDNJoW8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NUKK86ddB9tf; Sat, 17 Nov 2018 04:35:46 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 17 Nov 2018 04:35:45 +0100 (CET) Received: from [192.168.100.30] (unknown [113.53.105.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 0A89A4E18C0; Fri, 16 Nov 2018 22:35:44 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0A89A4E18C0 Content-Type: multipart/alternative; boundary=Apple-Mail-6BF20324-346D-458D-8D37-9E62A5BF9D36 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: <920193363.1649303.1542383177366@mail.yahoo.com> Date: Sat, 17 Nov 2018 10:35:37 +0700 Cc: Ted Lemon , Hrpc Content-Transfer-Encoding: 7bit Message-Id: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> To: Nalini J Elkins Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2018 03:36:10 -0000 --Apple-Mail-6BF20324-346D-458D-8D37-9E62A5BF9D36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Nov 16, 2018, at 22:46, Nalini J Elkins wrote: >=20 > > This is a very weird conversation. =20 >=20 > Yes. >=20 > > I think we agree that we want operators to participate in the IETF, and t= hat includes enterprise operators. >=20 > Great! I never said otherwise. They =E2=80=98participated=E2=80=99 and the outcome w= as lack of consensus on a use car they wanted. The process properly rejected= the use case without consensus. Participating does not mean all your wishes= are granted (and I am saying this as someone who saw an important draft die= at the last IETF due to failed consensus) .=20 Instead of taking the advise that their requirement should not happen at the= protocol level but should happen at the implementation level, they went to= ETSI to work around the IETF, even going against previous complains of IETF= to ETSI about ETSI calling their TLS protocol modification =E2=80=9CxxxTLS=E2= =80=9D To me this shows terrible judgement. Not only does it show the participants d= idn=E2=80=99t agree to our process, it shows they invaded IETF with a single= goal and were never going to let themselves be convinced by the technical a= rguments within the IETF. That is, there was only a pretence of participatin= g at the IETF. I think bridges have been burned in this process, at the expensive of a safe= r internet. I for one, will remember this outcome the next time US Bank or t= he Symantec/Patient approaches me for advise. Paul --Apple-Mail-6BF20324-346D-458D-8D37-9E62A5BF9D36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Nov 16, 2018, a= t 22:46, Nalini J Elkins <nalini.elkins@insidethestack.com> wrote:

> This is a very weird co= nversation.   

Yes.

> I think we agree that we want operators to participate in t= he IETF, and that includes enterprise operators.

Great!
<= /div>

I never said otherwise. They =E2=80=98parti= cipated=E2=80=99 and the outcome was lack of consensus on a use car they wan= ted. The process properly rejected the use case without consensus. Participa= ting does not mean all your wishes are granted (and I am saying this as some= one who saw an important draft die at the last IETF due to failed consensus)= . 

Instead of taking the advise that their requirem= ent should not happen at the protocol level but should happen at the impleme= ntation level, they went  to ETSI to work around the IETF, even going a= gainst previous complains of IETF to ETSI about ETSI calling their TLS proto= col modification =E2=80=9CxxxTLS=E2=80=9D

To me this show= s terrible judgement. Not only does it show the participants didn=E2=80=99t a= gree to our process, it shows they invaded IETF with a single goal and were n= ever going to let themselves be convinced by the technical arguments within t= he IETF. That is, there was only a pretence of participating at the IETF.

I think bridges have been burned in this process, at t= he expensive of a safer internet. I for one, will remember this outcome the n= ext time US Bank or the Symantec/Patient approaches me for advise.

<= /div>
Paul
<= /blockquote>
= --Apple-Mail-6BF20324-346D-458D-8D37-9E62A5BF9D36-- From nobody Sat Nov 17 07:50:13 2018 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 3643E128D0C for ; Sat, 17 Nov 2018 07:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGyAgp_l_NDQ for ; Sat, 17 Nov 2018 07:50:06 -0800 (PST) Received: from sonic313-16.consmr.mail.ne1.yahoo.com (sonic313-16.consmr.mail.ne1.yahoo.com [66.163.185.39]) (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 13358126DBF for ; Sat, 17 Nov 2018 07:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542469805; bh=dKuPZf6SWtBwiEdTr4S8c5MNfUTIMEH0od2yWae5Asw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Oqxy8cYFdrYS+8L9WO5HGeNzAm55St4VylQGzoGFs7YPcxYAoEePp5pR9k0i/II3S37SC1NenNKNppf3p3tnAyFW5F+W2QqBFU7Bbw6oRWueBaNOcdFtKtY4qLdfKxfba/2384Ihh4/hf1T+rMuxGNu9gXT56FlGOpMBfzLHKb4o3CWWlaCB7MJCtgVAqMeqRqa1bSGsWQup5/eGrGSKCaT9l20od5zPtRy8fbGztc3gLAhxk5YlJfmqBe0b2JLfsa6VrFOfo6dm/5biX9ffm3dy+KbYxrHe0imtjZFh+9hULKqYbsqWbwBa3uuTWRMuGdCcdpUUUeqgTryvPaVoBQ== X-YMail-OSG: ykpVVCAVM1kJkXaht.vqg4A6xG3GIOo1ryWLckQXSiJvQmMrd4.eBhjxuWVnzkB h9V_ThG9HsUGQqDOerkqsXLU4RFE2SS5yJWsD93kE01gOx6TCMEkfxh7xC4wjtct6rI_0XYlPCR6 cWmq792ubqOhwJoGhXo6UJTO2C.cCLOG5eSCmgBjqz7QT45aOXiCDizgGFfFRls3.noTh_lh9p.y wTsghiJqORDKZM_JYFhz60zPvDJOUINl5jA6WHRWkyiLuF3KNr87qb.V5PRTHSI6waFUsBb0LSvq pNtxfIAyp6ZWUH47lv2P1BXAYisHUTJbLJ1GTD7TDiRMCkTcGVm5zNInp016V57eCNoM1KMX9SeL S6cRkkit5561_zC_MEUeaZLtNU5MIbaV0MhjzK7tZ3kLK.iW_TW0aIICUEJDniM2S2CAiD_dp2Tn UErpbzNhejyRSwo7rprH0MSzsicF5iJmVNm_06xZyCNfDSInHVpEpM0HvZQrgWpnsrCDIQk_CL7R zlpKTaB5zNsVDHGf9bwneuybSVG5DLR1fVj7iEGL2O8S_LRePbvC3Ou1FGHOqP5ETh7osS.rIVib wTBAw5HZEGKaPzUJL0WKo6EIsLzVZ3xs4IAdsjsj8H2SWGRVaaTbxXz8vfpC7zQIPpPDLkymMbJx uZ.IbYOp19xWACglHGjetDFS1BFjQzJAmBzWpAFp_K3FblP4wgY8.DTYUTbOtEx9oN8aYZbMs2GT VzanRf.GdgvGVJHVWRx34533636cbFBfrybK3eu2odTHxaC0rRTkZwxC54YixsgniBVU0mA4TxHz dLDkWY5R86yQkjwDprKC7OKfKNsB3fAal8WkmEewJ4T_uuGMsDqQIvfCxhJUWgG4owkUJfC_5tBc LO40L36ED.DGgP30p9n440_1dYgJtEAencYgL9aGPonmatRQlO7gqlj4BOKr88dBEMUAmNLfyViF KmWdsaNTYf4E8cUmrYb2JD3Xvd8fK_THdCK4_FUgdhhHQfuntgdHAWWh8E.JJERcItiIbweu40Af Tp6SD8KQMiTpUr2zPrxozj85_omCgGr1UldscPiqGLpYheH2eN36rbF_8JKDB35A- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Sat, 17 Nov 2018 15:50:05 +0000 Date: Sat, 17 Nov 2018 15:45:30 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Paul Wouters Cc: Ted Lemon , Hrpc Message-ID: <903392906.2101109.1542469530498@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2101108_1742731644.1542469530491" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2018 15:50:08 -0000 ------=_Part_2101108_1742731644.1542469530491 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, >I never said otherwise. They =E2=80=98participated=E2=80=99 and the outcom= e was lack of consensus on a use car they wanted. The process properly reje= cted the use case without consensus. Participating does not mean all your w= ishes are granted=C2=A0>(and I am saying this as someone who saw an importa= nt draft die at the last IETF due to failed consensus) .=C2=A0 >Instead of taking the advise that their requirement should not happen at t= he protocol level but should happen at the implementation level, they went = =C2=A0to ETSI to work around the IETF, even going against previous complain= s of IETF >to ETSI about ETSI calling their TLS protocol modification =E2= =80=9CxxxTLS=E2=80=9D >To me this shows terrible judgement. Not only does it show the participant= s didn=E2=80=99t agree to our process, it shows they invaded IETF with a si= ngle goal and were never going to let themselves be convinced by the techni= cal arguments >within the IETF. That is, there was only a pretence of parti= cipating at the IETF. >I think bridges have been burned in this process, at the expensive of a sa= fer internet. I for one, will remember this outcome the next time US Bank o= r the Symantec/Patient approaches me for advise. =C2=A0 They went to ETSI at the advice of IETF leadership and senior IETFers.=C2= =A0 =C2=A0People TOLD them to go to another standards organization.=C2=A0= =C2=A0 Others are leading the effort at ETSI.=C2=A0 I am staying at the IETF to tr= y to find a more secure, long-term solution down the road which incorporate= s their needs (and, of course, I want to stay and work on other issues at t= he IETF).=C2=A0 I hope people will work with me. A number of enterprises feel they have their needs in this area.=C2=A0 =C2= =A0Their needs will not go away.=C2=A0 They need to be addressed. I will certainly say that there are hard feelings on both sides.=C2=A0 =C2= =A0In fact, it was as a result of this whole incident, as well as others th= at I have seen at the IETF , that I wrote, along with Henning Schulzrinne, = a draft on "Conflict Resolution at the IETF".=C2=A0 =C2=A0I do not want to = start a discussion of that draft here.=C2=A0 After Thanksgiving, I will pos= t it on the IETF-discuss email list.=C2=A0 This is something that the entir= e community needs to discuss. I hope that we can build bridges.=C2=A0 =C2=A0The Internet is used for busi= ness.=C2=A0 I know that I myself do Internet banking, payment and so on.=C2= =A0 I am not just doing google queries (or looking at the latest episode of= "The Trump Show").=C2=A0 =C2=A0 There are needs that need to be considered= . We need to work together.=C2=A0 =C2=A0I care deeply about the IETF.=C2=A0 I= t is a crucial part of the Internet ecosystem.=C2=A0 I do think we can impr= ove some of our processes.=C2=A0 =C2=A0I hope the fact of my actions in con= tinuing to participate actively on a number of issues at the IETF says that= to you louder than any words could say by themselves. I also care deeply about the enterprises and their needs.=C2=A0 I know them= , they have been my world for the last 30 years.=C2=A0 When an issue gets p= assionate,=C2=A0 people can get tunnel vision and stop listening to others.= =C2=A0 I hope we can learn to change that.=C2=A0 Believe me, I feel that th= ere is plenty of blame to go around on all sides of this issue.=C2=A0 But, = I hope we can learn from it to make our process better.=C2=A0=C2=A0 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Paul Wouters To: Nalini J Elkins =20 Cc: Ted Lemon ; Hrpc Sent: Friday, November 16, 2018 7:36 PM Subject: Re: [hrpc] "We try to avoid" =20 On Nov 16, 2018, at 22:46, Nalini J Elkins wrote: > This is a very weird conversation.=C2=A0 =C2=A0 Yes. >=C2=A0I think we agree that we want operators to participate in the IETF, = and that includes enterprise operators. Great! I never said otherwise. They =E2=80=98participated=E2=80=99 and the outcome= was lack of consensus on a use car they wanted. The process properly rejec= ted the use case without consensus. Participating does not mean all your wi= shes are granted (and I am saying this as someone who saw an important draf= t die at the last IETF due to failed consensus) .=C2=A0 Instead of taking the advise that their requirement should not happen at th= e protocol level but should happen at the implementation level, they went = =C2=A0to ETSI to work around the IETF, even going against previous complain= s of IETF to ETSI about ETSI calling their TLS protocol modification =E2=80= =9CxxxTLS=E2=80=9D To me this shows terrible judgement. Not only does it show the participants= didn=E2=80=99t agree to our process, it shows they invaded IETF with a sin= gle goal and were never going to let themselves be convinced by the technic= al arguments within the IETF. That is, there was only a pretence of partici= pating at the IETF. I think bridges have been burned in this process, at the expensive of a saf= er internet. I for one, will remember this outcome the next time US Bank or= the Symantec/Patient approaches me for advise. Paul _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_2101108_1742731644.1542469530491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

&g= t;I never said otherwise. They =E2=80=98participated=E2=80=99 and the outco= me was lack of consensus on a use car they wanted. The process properly rej= ected the use case without consensus. Participating does not mean all your = wishes are granted 
>(and I am saying this as someone who saw an important dr= aft die at the last IETF due to failed consensus) . 

>Instead of taking the advise that their requirement should not h= appen at the protocol level but should happen at the implementation level, = they went  to ETSI to work around the IETF, even going against previou= s complains of IETF >to ETSI about ETSI calling their TLS protocol modif= ication =E2=80=9CxxxTLS=E2=80=9D

>To me this = shows terrible judgement. Not only does it show the participants didn=E2=80= =99t agree to our process, it shows they invaded IETF with a single goal an= d were never going to let themselves be convinced by the technical argument= s >within the IETF. That is, there was only a pretence of participating = at the IETF.

>I think bridges have been burned in this= process, at the expensive of a safer internet. I for one, will remember th= is outcome the next time US Bank or the Symantec/Patient approaches me for = advise.

 
They went to ETSI at the advice of IETF = leadership and senior IETFers.   People TOLD them to go to anothe= r standards organization.  

Others are leading the eff= ort at ETSI.  I am staying at the IETF to try to find a more secure, l= ong-term solution down the road which incorporates their needs (and, of cou= rse, I want to stay and work on other issues at the IETF).  I hope peo= ple will work with me.

A number of enterprises feel they have th= eir needs in this area.   Their needs will not go away.  The= y need to be addressed.

I will certainly say that there are hard= feelings on both sides.   In fact, it was as a result of this wh= ole incident, as well as others that I have seen at the IETF , that I wrote= , along with Henning Schulzrinne, a draft on "Conflict Resolution at the IE= TF".   I do not want to start a discussion of that draft here.&nb= sp; After Thanksgiving, I will post it on the IETF-discuss email list. = ; This is something that the entire community needs to discuss.

= I hope that we can build bridges.   The Internet is used for busi= ness.  I know that I myself do Internet banking, payment and so on.&nb= sp; I am not just doing google queries (or looking at the latest episode of= "The Trump Show").    There are needs that need to be considered= .

We need to work together.   I care deeply about the= IETF.  It is a crucial part of the Internet ecosystem.  I do thi= nk we can improve some of our processes.   I hope the fact of my = actions in continuing to participate actively on a number of issues at the = IETF says that to you louder than any words could say by themselves.
<= div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1542466791674_17602" style=3D"font-= family: "Helvetica Neue", "Segoe UI", Helvetica, Arial,= "Lucida Grande", sans-serif; font-size: 13px;">
I also ca= re deeply about the enterprises and their needs.  I know them, they ha= ve been my world for the last 30 years.  When an issue gets passionate= ,  people can get tunnel vision and stop listening to others.  I = hope we can learn to change that.  Believe me, I feel that there is pl= enty of blame to go around on all sides of this issue.  But, I hope we= can learn from it to make our process better.  


Thanks,

Nalini Elkin= s
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
= (831) 659-8360


From: Paul Wouters <paul@nohats.ca>
To: Nalini J Elkins <nalini.elkins@in= sidethestack.com>
Cc: Ted Lemon <mellon@fugue.com>; Hrpc <hrpc@irtf.org>
Sent: Friday, November 16, 2018= 7:36 PM
Subject: Re: = [hrpc] "We try to avoid"
=


On Nov 16, 2018, at 22:46, Nalini J Elkins <nalini.el= kins@insidethestack.com> wrote:

> This is a very weird conversation.&n= bsp;  

Yes.

> I think we agree that we want operators = to participate in the IETF, and that includes enterprise operators.<= /div>

Great!=

I never= said otherwise. They =E2=80=98participated=E2=80=99 and the outcome was la= ck of consensus on a use car they wanted. The process properly rejected the= use case without consensus. Participating does not mean all your wishes ar= e granted (and I am saying this as someone who saw an important draft die a= t the last IETF due to failed consensus) . 

Instead of taking the advise that their requirement should not happ= en at the protocol level but should happen at the implementation level, the= y went  to ETSI to work around the IETF, even going against previous c= omplains of IETF to ETSI about ETSI calling their TLS protocol modification= =E2=80=9CxxxTLS=E2=80=9D

To me this show= s terrible judgement. Not only does it show the participants didn=E2=80=99t= agree to our process, it shows they invaded IETF with a single goal and we= re never going to let themselves be convinced by the technical arguments wi= thin the IETF. That is, there was only a pretence of participating at the I= ETF.

I think bridges have been burn= ed in this process, at the expensive of a safer internet. I for one, will r= emember this outcome the next time US Bank or the Symantec/Patient approach= es me for advise.

Paul
_= ______________________________________________
hrpc maili= ng list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc


------=_Part_2101108_1742731644.1542469530491-- From nobody Sat Nov 17 20:19:03 2018 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 70ADB12870E for ; Sat, 17 Nov 2018 20:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 eP1dMSwyiWC4 for ; Sat, 17 Nov 2018 20:18:59 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 1191C1286D9 for ; Sat, 17 Nov 2018 20:18:59 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42yJcp45M7zB0q; Sun, 18 Nov 2018 05:18:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542514730; bh=0SXOxmpMk7PCIlU7utiCP7jJElVuo17es1hQsg1KkOs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=e2MJjHqxPYtp6O0i3KFEbuf/BQlzYpaEmTj9PST6ZYMubPgNPIn2YvsNfn+YYVMuB 5ZQNAkaR2XQopKL4CFluQkCg+NZcTPtqmWXllkLjE7B+1MIoFDRW3bFkklNNmsOHFW SqnV5KZSjjM+b0HTXiYFaA7s88i2S/HnnQ3Vd/+E= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id TDfb48Uj4EMb; Sun, 18 Nov 2018 05:18:47 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 18 Nov 2018 05:18:46 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B975C2EEDB5; Sat, 17 Nov 2018 23:18:45 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B975C2EEDB5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA63B41C3B2D; Sat, 17 Nov 2018 23:18:45 -0500 (EST) Date: Sat, 17 Nov 2018 23:18:45 -0500 (EST) From: Paul Wouters To: Nalini J Elkins cc: Hrpc In-Reply-To: <903392906.2101109.1542469530498@mail.yahoo.com> Message-ID: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 04:19:02 -0000 On Sat, 17 Nov 2018, Nalini J Elkins wrote: [this is turning into a TLS post mortem, and not just hrpc. Chairs: do let us know if we should take this topic elsewhere] > They went to ETSI at the advice of IETF leadership and senior IETFers.   People TOLD them to go to another standards organization.   I cannot speak for the IETF leadership, but I think the advise was likely phrased as "it is a bad idea, and you cannot get it here. try elsewhere if you really want to try this bad idea to be standarized". > A number of enterprises feel they have their needs in this area.   Their needs will not go away.  They need to be addressed. Since the 80s governments wanted backdoors in crypto. Their need has not gone away. Yet we still believe not putting that in algorithm design is the right approach. That is, your undying need in itself is not a justification. Some things just cannot or should not be done. > I will certainly say that there are hard feelings on both sides.   In fact, it was as a result of this whole incident, as well as others that I have seen at > the IETF , that I wrote, along with Henning Schulzrinne, a draft on "Conflict Resolution at the IETF".   I do not want to start a discussion of that draft > here.  After Thanksgiving, I will post it on the IETF-discuss email list.  This is something that the entire community needs to discuss. I have read it but I feel that you are conflating a failed process with not geting your desired outcome. While I do think IETF at times fails in its process, I do not see how it failed on draft-green. > > I hope that we can build bridges.   The Internet is used for business.  I know that I myself do Internet banking, payment and so on.  I am not just doing > google queries (or looking at the latest episode of "The Trump Show").    There are needs that need to be considered.. Those needs were considerated at length, and the outcome was that there was no secure way of covering your needs with protocol changes. The recommendation was to do this at the implementation level. > We need to work together. Working together does not mean you are guaranteed your desired outcome. > I do think we can improve some of our processes. I agree in general we can and should. But frankly, I do not see a process improvement that would have an outcome for biulding a MITM infrastructure that the enterprise people want that is not strictly limited to enterprise or data center only without potential abuse by small criminals or nation states. > I also care deeply about the enterprises and their needs.  I know them, they have been my world for the last 30 years.  When an issue gets passionate,  > people can get tunnel vision and stop listening to others.  I hope we can learn to change that.  Believe me, I feel that there is plenty of blame to go > around on all sides of this issue.  But, I hope we can learn from it to make our process better.   I disagree with "tunnel vision" and "getting passionate" and "make the process better" with respect to the specific "enterprise TLS" needs. You feel this is reaching out to the generic IETF, but to me it appears more as a sign you misunderstood the process and why this outcome was rightfully reached. Paul From nobody Sat Nov 17 20:35:34 2018 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 CA3AC128D68 for ; Sat, 17 Nov 2018 20:35:32 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 DdVv-q8pmmmT for ; Sat, 17 Nov 2018 20:35:31 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 30AE01286D9 for ; Sat, 17 Nov 2018 20:35:31 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id u3-v6so10572669pfm.4 for ; Sat, 17 Nov 2018 20:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=9IMtVFxxdI3c01/W6SBOEecwrwWZKwbxMBmrHfIFCLY=; b=OYv13wHNHpB2MRTTnSo2ATecr2bcofMkMotDJAd3l5appy9gy8zYB5FM8ApjA3tgBF PG8Iq6913eBDRwiyG9UmhSsTnQtguVqyo7Ys/Qx1JJ6+XXagIGQ3iRhaIcQzBcDHpmWR sM6lvBNLQpTWFLb+9mJV0fshImTo433iWZihzXdAGnankbJJEuOMR9Fw/YD8t78kl5M/ Py5xt8J2zE5cjbmF3dkcqf94Whlh0uAbd4bu7RPr5PIHG2aUUyzrdVQFr75zOuFkjKeX AXu/IhcLVckyQsNWMoJ4ZCbasAnAqKcjd+Yx5ciVMvvSfFX5VDQSgRBveIzRh9kr+uVt oYqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9IMtVFxxdI3c01/W6SBOEecwrwWZKwbxMBmrHfIFCLY=; b=A9hYwSY+tLy8qFxg01v2uDwf7cgRZBb13Il2T7TlUxADuZQqNsSPWhg8hYZu0CP83j H0aORe8FYZnfXiL19rAnT5wv8cbDTGxvLrWm9LGSD7AcA927O/UAVo2q+QBVSTTPOxsU ehXF8yAb/joUIw/DFLspIC9tachaWuVXr/3NImh353U91FSMsa7B558GD/Jr+M9wqCl0 os6Jb0eeeSrQu9nD8xqjfYzVYEAlnKRCEWUjl4QWADIvWqt6YNchR+Orh26tcSrnN/HP 2CQYNya9cx2tCfycprDg6xelf9Yx357twFyBONAWXsusiuLAQmGdvkI69C70aDjNPlKi 1xEg== X-Gm-Message-State: AGRZ1gKY6hGxUKZUIrrcXWOXJlFdas6bwMyYYEcAbzPnOdx84iXTc94U sCptkFhBg0sJ2poLlxP7dPql/hFuEg== X-Google-Smtp-Source: AJdET5fDtqb3CGeUb9sFuTEDp1fkt+Vex56UhcXahzQLApe3khTHetRKgUr0CxVZ1c4nofal6bK87A== X-Received: by 2002:a62:b15:: with SMTP id t21mr4645738pfi.136.1542515729897; Sat, 17 Nov 2018 20:35:29 -0800 (PST) Received: from aspen.local (216-67-35-146-radius.dynamic.acsalaska.net. [216.67.35.146]) by smtp.gmail.com with ESMTPSA id g65sm86614684pfa.63.2018.11.17.20.35.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Nov 2018 20:35:28 -0800 (PST) To: hrpc@irtf.org References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> From: Melinda Shore Message-ID: Date: Sat, 17 Nov 2018 19:35:26 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 04:35:33 -0000 On 11/17/18 7:18 PM, Paul Wouters wrote: > I cannot speak for the IETF leadership, but I think the advise was > likely phrased as "it is a bad idea, and you cannot get it here. try > elsewhere if you really want to try this bad idea to be standarized". I don't think it was even that, but rather what you cite a few paragraphs down: > Those needs were considerated at length, and the outcome was that there > was no secure way of covering your needs with protocol changes. The > recommendation was to do this at the implementation level. Indeed. I'll also note that I view forum shopping, as has been done in this case, is a de facto rejection of the recommendation that was given. It's also, by definition, not very consensus-y, so I'm not sure on what basis advice about process failures is being advanced, here. Melinda -- Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis From nobody Sat Nov 17 21:35:24 2018 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 874261298C5 for ; Sat, 17 Nov 2018 21:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB6x4Xegk6UJ for ; Sat, 17 Nov 2018 21:35:20 -0800 (PST) Received: from sonic314-28.consmr.mail.ne1.yahoo.com (sonic314-28.consmr.mail.ne1.yahoo.com [66.163.189.154]) (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 438351286D9 for ; Sat, 17 Nov 2018 21:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542519319; bh=rv3r/A7rLBNsvVP8PbSkW+6ZwGyax7Bd5YPi0a8PhVc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=C4/wX1KtmDzd4+LdH7/3VSu6AE/B8y+ccShBT7YHb/R6VFj227bJUtPk0ngEpXZQdu+XNh0xeXlIvVDqy7d1g2GpNMtzm9tLNfzCx71DHtY/4jvvns4yc4UAjQu1/j7fntNCNFoWCFjVfAblfHtfLsXx9/D+2IZTMR4UFD1+5tfkUPZtPeN5NeyfRghbqP7klZJKO7M6LGC3Kkc9Eom9fD5lq3l4Ag+TcDXXblkAJHIwHkFCYfCq/gJarHqQb7iWLrr4XFmPYRAlCaHLUTvKhaCHjUzBvUOd9a7R6QQ4roihFuHYKfEGnasX7YWKe2ovn+ciRa0BtPL2Zo8dgZfziA== X-YMail-OSG: J9RfjHoVM1lo3H9yiezcTJE8hklSyplIE.orW7S5EbtCo3gUlS1Qdh2Z3dfcIST WbFqWVMR81Z.zs6gHw1UFLQG8HyWKTkIlb3fM8TbMYXjLhR28id41cgYNwB_gAVv.mJapGl23myh GbzhfXicuUbajvZ.TOvH.GLvuk6FMlmBsRBrg7IUlmj6DHlA8VI2UQHsnkUx9Q55zXR__ZH3WBpu _t.ejpPWXmdXtMJ0U5frUYAhSR5t1bZwkKP46W5JhzxaHzV6zzrWh4gpRKOSJvcwdSFSR7xtPsXH ArBtHurfaxvZFla6ZHuO4xrnI31sx5aCAe6T4iKEt1kpC7HCvfAZRgrbQIaT40v88YMxxJYlOErU Cs3ns37O5rzu.E2mlpauAupzitwzpFidtxUD3ttUaPHcAAzaOb7BUPMVrnmq__bPcqZyr1C0Ggsb A3p3hnsuiWqwalcMkEClb3P0TLJ3_u_ZKqrlQYGgE0cd_EouJ50cHuxR7w8OEnVnInuBmDktRyhO byKynMZdVXYsab7HPTsEflNAATjDk65GrBNmScdUgZWlM5iJRVWiE.FCbY2x.mZroUp1yDSaX4XG pr2FH393FeuT.yeQs9umYl60741yyDAcRX3frKG9oWO.vIKd3pvXigzSynNMpT6Ne4t_hu_KO60D HJo2TJNfLAxvoj02lDH1WXAGLDzmZGsq4aKX6uXxA6v3WxhUOeb0OqsFU3v5jTu5ReKxYqS7UglH .bu5fuvogqtmvadLwGdURr1kDAylBn8mfYqFRV7VwINv3v7l5kBMtAkOOEp0RFZUx9RFnrhXfJrP eBT4L4yCloxhfLWcQvZ_aAHiup0WVn0nivWEj28a9ClswPT2LgfC3qTolaFC9vs4dC6hmnXLj8ZL k5mm09Wn7iNIGlVz.5Uy7g1qTUA.eFnpXIy1mM9VTHvcdJoGdmda6T25CKb3EWMA6NRklxwNJd0V Ulnhk_C9X2.UMlmXP7qRXdKA4pIaCjvOZOy34WyzTwF29E14JDNbb5GWs8lSbhdD.PkbiojUT6Yk T63u1g5Y5rUZv914MjbzXDGG9JFXZFp1213SKzWOTiGOSnrW1n531iOor1edq.ny1TXuj Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Nov 2018 05:35:19 +0000 Date: Sun, 18 Nov 2018 05:35:17 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Paul Wouters Cc: Hrpc Message-ID: <85412976.2311161.1542519317145@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2311160_313177972.1542519317141" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 05:35:23 -0000 ------=_Part_2311160_313177972.1542519317141 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, > [this is turning into a TLS post mortem, and not just hrpc. Chairs: do le= t us know if we should take this topic elsewhere] Yes, absolutely happy to take this elsewhere or just have a personal conver= sation. >> They went to ETSI at the advice of IETF leadership and senior IETFers.= =C2=A0 =C2=A0People TOLD them to go to another standards organization.=C2= =A0=C2=A0 >I cannot speak for the IETF leadership, but I think the advise was>likely = phrased as "it is a bad idea, and you cannot get it here. try>elsewhere if = you really want to try this bad idea to be standarized". You should really ask the people involved in the leadership to comment on w= hat was said.As I recall at the time, what was said was along the lines of = if you have needs, thenyou should go to another standards organization to s= ee if you can get them met. It wasvery definitely NOT phrased in the way yo= u have put it. And, truthfully, the way you are phrasing it feels quite disrespectful.=C2= =A0 =C2=A0=C2=A0 >> A number of enterprises feel they have their needs in this area.=C2=A0 = =C2=A0Their needs will not go away.=C2=A0 They need to be addressed. >Since the 80s governments wanted backdoors in crypto. Their need has not>g= one away. Yet we still believe not putting that in algorithm design is>the = right approach. That is, your undying need in itself is not a>justification= . Some things just cannot or should not be done. Again, with all due respect, this is your opinion rather than an indisputab= le fact.=C2=A0 I will tell you that others disagreewith you.=C2=A0 >> I will certainly say that there are hard feelings on both sides.=C2=A0 = =C2=A0In fact, it was as a result of this whole incident, as well as others= that I have seen at>> the IETF , that I wrote, along with Henning Schulzri= nne, a draft on "Conflict Resolution at the IETF".=C2=A0 =C2=A0I do not wan= t to start a discussion of that draft>> here.=C2=A0 After Thanksgiving, I w= ill post it on the IETF-discuss email list.=C2=A0 This is something that th= e entire community needs to discuss. >I have read it but I feel that you are conflating a failed process with no= t geting your desired outcome.=C2=A0 Please do not make assumptions about what I do and don't think.=C2=A0 For e= xample, you don't know that I actually think that draft-green IS the right = solution.=C2=A0 =C2=A0What I have always wanted is for enterprises to have = a voice.=C2=A0 And for the IETF to work with them. >While I do think IETF at times fails in its process, I do not see how it f= ailed on draft-green. The fact that many months after the decision, there are so many hard feelin= gs between so many people that we can hardly talk about this issuewithout i= t erupting into chaos would lead me to think that there is probably a bette= r way.=C2=A0 =C2=A0You and I are talking about different things.This level = of hard feelings is a huge waste of time and energy for many people.=C2=A0 = Not to mention the fact that now there are multiple standardswhich may be i= n conflict.=C2=A0 If you think this is a successful process and outcome, th= en I would beg to differ. I suspect that you are talking about the "process" or "outcome" as that dra= ft-green was not adopted. Please let me know if that is true.=C2=A0 I do=C2= =A0not want to make assumptions about what you are saying.=C2=A0 Because I = certainly do not like people making assumptions about what I am saying.=C2= =A0 =C2=A0 >=C2=A0>> I hope that we can build bridges.=C2=A0 =C2=A0The Internet is use= d for business.=C2=A0 I know that I myself do Internet banking, payment and= so on.=C2=A0 I am not just doing>> google queries (or looking at the lates= t episode of "The Trump Show").=C2=A0 =C2=A0 There are needs that need to b= e considered.. >Those needs were considerated at length, and the outcome was that there wa= s no secure way of covering your needs with protocol changes. The>recommend= ation was to do this at the implementation level. Again, I disagree with you.=C2=A0 I have talked to a number of cryptographe= rs and there may be number of potential ways of doing this without violatin= g thesecurity guarantees of TLS.=C2=A0 But, this is not the time to bring u= p any potential new ideas. >> We need to work together. >Working together does not mean you are guaranteed your desired outcome. Frankly, this feels condescending.=C2=A0 =C2=A0Please give me credit for a = modicum of intelligence.=C2=A0 >> I do think we can improve some of our processes. >I agree in general we can and should. But frankly, I do not see a>process = improvement that would have an outcome for biulding a MITM>infrastructure t= hat the enterprise people want that is not strictly>limited to enterprise o= r data center only without potential abuse>by small criminals or nation sta= tes. The process improvement is not about anything in TLS but about how we go ab= out getting to consensus. >> I also care deeply about the enterprises and their needs.=C2=A0 I know t= hem, they have been my world for the last 30 years.=C2=A0 When an issue get= s passionate,=C2=A0>> people can get tunnel vision and stop listening to ot= hers.=C2=A0 I hope we can learn to change that.=C2=A0 Believe me, I feel th= at there is plenty of blame to go>> around on all sides of this issue.=C2= =A0 But, I hope we can learn from it to make our process better.=C2=A0=C2= =A0 >I disagree with "tunnel vision" and "getting passionate" and "make the>pro= cess better" with respect to the specific "enterprise TLS" needs. You>feel = this is reaching out to the generic IETF, but to me it appears>more as a si= gn you misunderstood the process and why this outcome was>rightfully reache= d. Again, we are talking about very different things.=C2=A0 =C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ------=_Part_2311160_313177972.1542519317141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

> [this is turning into a TLS post mortem, and not just hrpc. Chairs:= do let us know if we should take this topic elsewhere]

Yes, abso= lutely happy to take this elsewhere or just have a personal conversation.


>> They went to ETSI at the ad= vice of IETF leadership and senior IETFers.   People TOLD them to= go to another standards organization.  

>I cannot s= peak for the IETF leadership, but I think the advise was
>likely phrased as "it is a bad ide= a, and you cannot get it here. try
>elsewhere if you really want to try this bad idea to be = standarized".


You should really ask= the people involved in the leadership to comment on what was said.
As I recall at the time, wh= at was said was along the lines of if you have needs, then
you should go to another standards o= rganization to see if you can get them met. It was
very definitely NOT phrased in the way you h= ave put it.

And, truthfully, the way you are phrasing it feels = quite disrespectful.    

=

>> A number of enterprises feel they have their needs in this ar= ea.   Their needs will not go away.  They need to be address= ed.

>Since the 80s governments wanted backdoors in crypto. The= ir need has not
>= gone away. Yet we still believe not putting that in algorithm design is
>the right approach.= That is, your undying need in itself is not a
>justification. Some things just cannot or sh= ould not be done.
Again, with all due respect, this is your opini= on rather than an indisputable fact.  I will tell you that others disa= gree
with you. =


>> I will certainly say th= at there are hard feelings on both sides.   In fact, it was as a = result of this whole incident, as well as others that I have seen at
<= div id=3D"yui_3_16_0_ym19_1_1542516163435_12112">>> the IETF , that I= wrote, along with Henning Schulzrinne, a draft on "Conflict Resolution at = the IETF".   I do not want to start a discussion of that draft
>> here.  A= fter Thanksgiving, I will post it on the IETF-discuss email list.  Thi= s is something that the entire community needs to discuss.

>I have read it but I feel that you are conflati= ng a failed process with not geting your desired outcome. 

<= br id=3D"yui_3_16_0_ym19_1_1542516163435_12118">
Please do not make assumptions about what I do= and don't think.  For example, you don't know that I actually think t= hat draft-green IS the right solution.   
What I have always wanted is for enterprise= s to have a voice.  And for the IETF to work with them.

>While I do think IETF at times fails in its= process, I do not see how it failed on draft-green.

The fact tha= t many months after the decision, there are so many hard feelings between s= o many people that we can hardly talk about this issue
without it erupting into chaos would lea= d me to think that there is probably a better way.   You and I ar= e talking about different things.
This level of hard feelings is a huge waste of time and energ= y for many people.  Not to mention the fact that now there are multipl= e standards
which ma= y be in conflict.  If you think this is a successful process and outco= me, then I would beg to differ.

I suspect that you are talking a= bout the "process" or "outcome" as that draft-green was not adopted. Please= let me know if that is true.  I do 
not want to make assumptions about what you are = saying.  Because I certainly do not like people making assumptions abo= ut what I am saying.   


&= gt; 
>> I= hope that we can build bridges.   The Internet is used for busin= ess.  I know that I myself do Internet banking, payment and so on.&nbs= p; I am not just doing
>> google queries (or looking at the latest episode of "The Trump = Show").    There are needs that need to be considered..

>Those needs were considerated at length, and the outcome was that ther= e was no secure way of covering your needs with protocol changes. The
=
>recommendation was to= do this at the implementation level.

Again, I disagree with you.=   I have talked to a number of cryptographers and there may be number = of potential ways of doing this without violating the
security guarantees of TLS.  But, th= is is not the time to bring up any potential new ideas.


>> We need to work together.

>Worki= ng together does not mean you are guaranteed your desired outcome.

Frankly, this feels condescending.   Please give me credit for = a modicum of intelligence. 


&g= t;> I do think we can improve some of our processes.

>I agr= ee in general we can and should. But frankly, I do not see a
>process improvement that wou= ld have an outcome for biulding a MITM
>infrastructure that the enterprise people want that = is not strictly
>= limited to enterprise or data center only without potential abuse
>by small criminals or nat= ion states.


The process improveme= nt is not about anything in TLS but about how we go about getting to consen= sus.


>> I also care deeply ab= out the enterprises and their needs.  I know them, they have been my w= orld for the last 30 years.  When an issue gets passionate, 
>> people can get = tunnel vision and stop listening to others.  I hope we can learn to ch= ange that.  Believe me, I feel that there is plenty of blame to go
>> around on all = sides of this issue.  But, I hope we can learn from it to make our pro= cess better.  

>I disagree with "tunnel vision" and = "getting passionate" and "make the
>process better" with respect to the specific "enterprise= TLS" needs. You
>= ;feel this is reaching out to the generic IETF, but to me it appears
<= div id=3D"yui_3_16_0_ym19_1_1542516163435_12191">>more as a sign you mis= understood the process and why this outcome was
>rightfully reached.

Again, we are= talking about very different things. 

 
Thanks,

Nalini Elkins
CEO and Founder<= br>Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
<= div class=3D"qtdSeparateBR" id=3D"yui_3_16_0_ym19_1_1542516163435_11878">
------=_Part_2311160_313177972.1542519317141-- From nobody Sat Nov 17 21:43:36 2018 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 984291286D9 for ; Sat, 17 Nov 2018 21:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, REPTO_QUOTE_YAHOO=0.646, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeDzRu01G4pd for ; Sat, 17 Nov 2018 21:43:33 -0800 (PST) Received: from sonic306-8.consmr.mail.bf2.yahoo.com (sonic306-8.consmr.mail.bf2.yahoo.com [74.6.132.47]) (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 29A0812426A for ; Sat, 17 Nov 2018 21:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542519810; bh=k5HC/7ULd9C5Gtoi2Zftrj1DQbnl/+r4X99Owa96tSA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WE1KBwf+Tuaqw015rMrSXMxfYGCBaDIeTAAhwyo6Y+heontN8jUUnrllLc8Vm6murYX7yP+ioPHOrUC3DQUwjtZbBAgnN3lMS6ZV4+Ymze5FDYiOWPdhWd/j6GaCmn+dTZN/XG8LnvBPVmVQjSn5DBkQQcqTtE2SWGYGyTod6BC1CwS99U5BDAtdAwGjOIr4+951awgzCCpVrqQeWp+biiMKS65if62ezKj8pF4SvSOBqNCpNtGJPVMVsQX+4DYbDakjY1lEui8SkC5aXQDZC2a7GC0vUIUlurs1KUC5X6vsroC7Pgjm7jqJdPNxtdnrAq/nsiU8pq41TRQvQQB1Aw== X-YMail-OSG: PnUYFfAVM1nbYp6.oD2QcgeGQsgI4RsP6UrmNYRA0Z0NrNHC8fLxh5jtpVEngZO 9RYwN.vnYldNJxZvvOkIkyWeBsAOTF9C.ieVUpsgwweHquSx3qofs8v32hIHiYDZGgivG75XBuFr 1LvzaYzsPHvR.O6fKm4xaIiBfC.OI5260fV3SUbWlx4mbd0neeLp6G9oajpAb5zksDNzp8C6PZfC GnpppxnAy5AeXjrIksTTfhlCBc7gXaTfCv5ozLwjRTv3HW1GnAnkK7T000Kbg_Ptcp1M2MtZ5Ke. njjJE4XTofcJmdGmNXhuvlMuyGcZ4Jcbp87k1jCXQlBQyFdiA_0EP5isDg5.ZtNMPJBh.2EawXIY RCysoZkDbbsgihxqvLbWg44ExRGVCvlLErGwHarP6Fp.jyPAmljLw7dMBZi7C_It_bmjUapCGNe9 xKGIjutP1GaDEUm21fM1qj_xeCeEu4EOottKuzt85W_pacIFuO_ZvgrKAJx4CJVupO8Bfz9NyYv6 ugOMkpH5EUHixBtuLeKTvHaN2UESiIJK5hpzJusFzmPOWR.UzMX_nC822H0Nx9m9sWg60jAJ0Zt3 olOhGjEidwB1eQI7h.Qnu1OK5D6qJbg64u122a.Mw5eEl78BjAKy6H9qe5RNfwhPPJw33WzU_Bdp h7BCFq8IsuQ1L1CXSixmJLA3_aQCif5vAwkekOrMb.UzlMFXVY0IrwwDplwMvGX6ul6AM9_O.Pry pLCGt0iJLTFeOR.c_YW869scWC9mUmyJB.ovGGkoBmqaU5zkDfL5gm2._liHFITYnbfiSsPFXeRR ltf422Tmj3_cslv7o4sum5yl1bz0xO9u6uB9YXOrbiBX1iFqmUtV851FCJ3vp8Vx7hJ0kwcQAyan tbn7BStzKSwhz2M3GhPVuYYKhDkjU5wOdtwMQ_Z6YfOXNgNjRtsFyG7kZV2iGNvhEeT0BC6KxFRk pid9nICjNAitrBoVghcCTj9kA0naGw1NVkC4P7AJB9H5Lfm2B8KLRsuX5h1u6sHOLpQp0psUUY2h Hyseh2G3qDQUH3aKt84Xp0zIymcSDZeUCMVeEiXmks8UyZTk5_QZkini._hXHyfxFoj5ot37eXTW 03yF13LcyAA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Sun, 18 Nov 2018 05:43:30 +0000 Date: Sun, 18 Nov 2018 05:43:28 +0000 (UTC) From: Bill Jouris Reply-To: "b_jouris@yahoo.com" To: "paul@nohats.ca" Cc: Hrpc Message-ID: <1742878752.2331781.1542519808969@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2331780_1138328557.1542519808964" X-Mailer: WebService/1.1.12729 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/5.35.0; Android/7.1.1; NMF26X; gt58wifi; samsung; SM-T350; 8.02; 1024x768; ) Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 05:43:35 -0000 ------=_Part_2331780_1138328557.1542519808964 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >=C2=A0Some things just cannot or should not be done.=C2=A0 I agree completely.=C2=A0=C2=A0 But it must be noted that this is NOT a purely technical decision.=C2=A0 In= deed, it is inherently a political (or, if you prefer, a moral) judgement.= =C2=A0 Precisely the kind of non-technical factor that, previously in this = thread, were being denounced as outside IETF's proper sphere.=C2=A0=C2=A0 Bill Jouris=C2=A0 Sent from Yahoo Mail on Android=20 =20 On Sat, Nov 17, 2018 at 8:19 PM, Paul Wouters wrote: On= Sat, 17 Nov 2018, Nalini J Elkins wrote: [this is turning into a TLS post mortem, and not just hrpc. Chairs: do let = us know if we should take this topic elsewhere] > They went to ETSI at the advice of IETF leadership and senior IETFers.=C2= =A0 =C2=A0People TOLD them to go to another standards organization.=C2=A0= =C2=A0 I cannot speak for the IETF leadership, but I think the advise was likely phrased as "it is a bad idea, and you cannot get it here. try elsewhere if you really want to try this bad idea to be standarized". > A number of enterprises feel they have their needs in this area.=C2=A0 = =C2=A0Their needs will not go away.=C2=A0 They need to be addressed. Since the 80s governments wanted backdoors in crypto. Their need has not gone away. Yet we still believe not putting that in algorithm design is the right approach. That is, your undying need in itself is not a justification. Some things just cannot or should not be done. > I will certainly say that there are hard feelings on both sides.=C2=A0 = =C2=A0In fact, it was as a result of this whole incident, as well as others= that I have seen at > the IETF , that I wrote, along with Henning Schulzrinne, a draft on "Conf= lict Resolution at the IETF".=C2=A0 =C2=A0I do not want to start a discussi= on of that draft > here.=C2=A0 After Thanksgiving, I will post it on the IETF-discuss email = list.=C2=A0 This is something that the entire community needs to discuss. I have read it but I feel that you are conflating a failed process with not geting your desired outcome. While I do think IETF at times fails in its process, I do not see how it failed on draft-green. >=20 > I hope that we can build bridges.=C2=A0 =C2=A0The Internet is used for bu= siness.=C2=A0 I know that I myself do Internet banking, payment and so on.= =C2=A0 I am not just doing > google queries (or looking at the latest episode of "The Trump Show").=C2= =A0 =C2=A0 There are needs that need to be considered.. Those needs were considerated at length, and the outcome was that there was no secure way of covering your needs with protocol changes. The recommendation was to do this at the implementation level. > We need to work together. Working together does not mean you are guaranteed your desired outcome. > I do think we can improve some of our processes. I agree in general we can and should. But frankly, I do not see a process improvement that would have an outcome for biulding a MITM infrastructure that the enterprise people want that is not strictly limited to enterprise or data center only without potential abuse by small criminals or nation states. > I also care deeply about the enterprises and their needs.=C2=A0 I know th= em, they have been my world for the last 30 years.=C2=A0 When an issue gets= passionate,=C2=A0 > people can get tunnel vision and stop listening to others.=C2=A0 I hope w= e can learn to change that.=C2=A0 Believe me, I feel that there is plenty o= f blame to go > around on all sides of this issue.=C2=A0 But, I hope we can learn from it= to make our process better.=C2=A0=C2=A0 I disagree with "tunnel vision" and "getting passionate" and "make the process better" with respect to the specific "enterprise TLS" needs. You feel this is reaching out to the generic IETF, but to me it appears more as a sign you misunderstood the process and why this outcome was rightfully reached. Paul _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_2331780_1138328557.1542519808964 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Some things just cannot or should not be done. = ;

I agree complet= ely.  

But it must be noted that this is NOT a purely technical decision.&nb= sp; Indeed, it is inherently a political (or, if you prefer, a moral) judge= ment.  Precisely the kind of non-technical factor that, previously in = this thread, were being denounced as outside IETF's proper sphere. &nb= sp;

Bill Jouris 
=


On Sat, Nov = 17, 2018 at 8:19 PM, Paul Wouters
<paul@nohats.ca> wrote:
On Sat, 17 Nov 2018, Nalini J Elkins wrote:

[this is turning into a TLS post mortem, and not just hrpc. Chair= s: do let us know if we should take this topic elsewhere]

> They went to ETSI at the advice of IETF leadership= and senior IETFers.   People TOLD them to go to another standard= s organization.  

I cannot s= peak for the IETF leadership, but I think the advise was
= likely phrased as "it is a bad idea, and you cannot get it here. try
elsewhere if you really want to try this bad idea to be standar= ized".

> A number of enterprises fe= el they have their needs in this area.   Their needs will not go = away.  They need to be addressed.

Since the 80s governments wanted backdoors in crypto. Their need has notgone away. Yet we still believe not putting that in algori= thm design is
the right approach. That is, your undying n= eed in itself is not a
justification. Some things just ca= nnot or should not be done.

> I wil= l certainly say that there are hard feelings on both sides.   In = fact, it was as a result of this whole incident, as well as others that I h= ave seen at
> the IETF , that I wrote, along with Henn= ing Schulzrinne, a draft on "Conflict Resolution at the IETF".   = I do not want to start a discussion of that draft
> he= re.  After Thanksgiving, I will post it on the IETF-discuss email list= .  This is something that the entire community needs to discuss.

I have read it but I feel that you are conf= lating a failed process with not
geting your desired outc= ome. While I do think IETF at times fails in
its process,= I do not see how it failed on draft-green.
>
> I hope that we can build bridges.   The Internet = is used for business.  I know that I myself do Internet banking, payme= nt and so on.  I am not just doing
> google queri= es (or looking at the latest episode of "The Trump Show").    The= re are needs that need to be considered..

Those needs were considerated at length, and the outcome was that there=
was no secure way of covering your needs with protocol c= hanges. The
recommendation was to do this at the implemen= tation level.

> We need to work tog= ether.

Working together does not mean = you are guaranteed your desired outcome.

> I do think we can improve some of our processes.
=
I agree in general we can and should. But frankly, I do = not see a
process improvement that would have an outcome = for biulding a MITM
infrastructure that the enterprise pe= ople want that is not strictly
limited to enterprise or d= ata center only without potential abuse
by small criminal= s or nation states.

> I also care d= eeply about the enterprises and their needs.  I know them, they have b= een my world for the last 30 years.  When an issue gets passionate,&nb= sp;
> people can get tunnel vision and stop listening = to others.  I hope we can learn to change that.  Believe me, I fe= el that there is plenty of blame to go
> around on all= sides of this issue.  But, I hope we can learn from it to make our pr= ocess better.  

I disagree w= ith "tunnel vision" and "getting passionate" and "make the
process better" with respect to the specific "enterprise TLS" needs. You<= br clear=3D"none">feel this is reaching out to the generic IETF, but to me = it appears
more as a sign you misunderstood the process a= nd why this outcome was
rightfully reached.


Paul

____________________________= ___________________
hrpc mailing list
<= a shape=3D"rect" ymailto=3D"mailto:hrpc@irtf.org" href=3D"mailto:hrpc@irtf.= org">hrpc@irtf.org
https://www.irtf.org/= mailman/listinfo/hrpc
------=_Part_2331780_1138328557.1542519808964-- From nobody Sun Nov 18 05:53:18 2018 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 EA313130E1D for ; Sun, 18 Nov 2018 05:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8yoSFbVSFfx for ; Sun, 18 Nov 2018 05:53:11 -0800 (PST) Received: from sonic316-26.consmr.mail.ne1.yahoo.com (sonic316-26.consmr.mail.ne1.yahoo.com [66.163.187.152]) (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 5FA501277BB for ; Sun, 18 Nov 2018 05:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542549190; bh=00a1YBgprMuRDhf7k9dkGU2NoVB7jlNCtFVYMK9Qb+I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qr6TeP0eOI5iAeFLoNbJo9orAvFjCO5iI9ygu3mZitZOGCZbLAeyk2gwQGLaQuASuoqERKBMAXtWYPhFZ9mFMu4iYKjQfljzT8y1ghIAEUb57vypeCkM1EXTHXU4N1XBA/wFoFMAnoHC1B/uaiWOpGHmidaMqaUTdyockgch5B7r7M3wYF5Jo/anMeWaWLrhnxRMvYZrXkLQyEf2aEEJIHWM4xtOUMJZCq5CBpcImX20kZVhUAGZ8KPnkgDkq4h8McFui9HV1b2Y4+fSdD+cwHXU3ToV6qL9hRkOU4YwJgL15IT5ANHB7NhZECQLrv3KIc12pmnULvU2Jzhzr+Aa9w== X-YMail-OSG: ZCMJw9sVM1kfeld7RMQUIIl2HoukROieMur48ULK2KCutSAMHhJ9ZL4YuAX66I_ MI7aQt9zkjEVh7w_5guh1LxUg8enfXwAAMpQ584jrd6ads9ayb.AYcc_Oo3dy0eqNSVYY7zx5wKT e8_o1zr0J2fhCVqnwGV78BxCAE594KitNUxHvfuqrwktD66PoMkjJ0Tw_5No5gYg.BB79W0zi6Ia AXXURi4f6R_xG2Pdm8cTYlS0cVh.P1kmwonwwX._WnPLPLPXFENNmJDvHmDWsqQamb_Np202bJ_u KBJ9ubqvUW35OPW9PXb28XdBD_sHXB0qwYv_MJ0Y17ixkL11T3mHJZUJ_4PMCWqE32bFVX2TCYcC aDUcJXyLWRKIL_tCTrw3YQl._sZe8Sr0N6wXflOuVIeDt2p6u9ihERe_6dCltGxJ3RfGdTKqcsXR Kr2Ze3S4mnM3CrzuUjjYqU0ZHo0QOgvUfqUHWPOT9oRJ7fbNTEraidbFdZAmzuhzfQTK38xFOXlt fMRCdIk8VMRVpHSnPFQJuvfhFg6qAW.8V2Brlh.75jzU8SDrNf20e11uc4HTzBSEl5BzXCig1eS5 rvHPU9dQ2nQFp5f.QSyJ23RbVrtXaM3WvduYv2ZDsugfSp6Yt7OOTPPbqRL_WS0KJ1FzpBqqww.R 7O4OBGNv7TLMbisibU6milfwkMlfCg8eI5RZVuf7GJyorI1_Hgqe71GwAFxc92ySp4iNXvoHHL9J .JP3eyC6a1kqa7c.2yyO.VOteXGxmDW.b41woe_lZ3gQOuHhhE8y7DvuM4RqOeIhPVa5.N6qvF81 z3fjDq3.RNFivGwCmWJQQUeX8yuIaAD8nN6gW7PTwDm32lXvyt68OtjoC1dgoSvKL6F7hC60SgSd efQKUk0lINIalEs5FPHtEgUF2HY4M7ICB5ySHhhRRZ8_S203qpIJt4UxMs5JggV139hqsc4JrCCj Xty_Pb0c2AuzMeekjXnZQbLxob2J.xp1ffomxjlOhU_kIIoa5n9s.v1WTM5iRd8_kHLNGvBfS7WJ OSSs3f_o5MsHh.avERUFKWRLMxfUHV1pZ0S3vwGumoYqrYhNZsYR4I4XuphliBWT7XdAe Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Nov 2018 13:53:10 +0000 Date: Sun, 18 Nov 2018 13:53:07 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Paul Wouters Cc: Hrpc Message-ID: <1600428938.2351944.1542549187250@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2351943_1670394981.1542549187247" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 13:53:15 -0000 ------=_Part_2351943_1670394981.1542549187247 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >I agree in general we can and should. But frankly, I do not see a >process improvement that would have an outcome for biulding a MITM >infrastructure that the enterprise people want that is not strictly >limited to enterprise or data center only without potential abuse>by small= criminals or nation states. Is the "potential abuse by small criminals and nation states" in the TLS ch= arter or is that your political belief at work? Is it that certain political stances are OK to hold and others not OK?=C2= =A0=C2=A0 So you are really telling me that the decision is political / moral, not te= chnical?=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Paul Wouters To: Nalini J Elkins =20 Cc: Hrpc Sent: Saturday, November 17, 2018 8:18 PM Subject: Re: [hrpc] "We try to avoid" =20 On Sat, 17 Nov 2018, Nalini J Elkins wrote: [this is turning into a TLS post mortem, and not just hrpc. Chairs: do let = us know if we should take this topic elsewhere] > They went to ETSI at the advice of IETF leadership and senior IETFers.=C2= =A0 =C2=A0People TOLD them to go to another standards organization.=C2=A0= =C2=A0 I cannot speak for the IETF leadership, but I think the advise was likely phrased as "it is a bad idea, and you cannot get it here. try elsewhere if you really want to try this bad idea to be standarized". > A number of enterprises feel they have their needs in this area.=C2=A0 = =C2=A0Their needs will not go away.=C2=A0 They need to be addressed. Since the 80s governments wanted backdoors in crypto. Their need has not gone away. Yet we still believe not putting that in algorithm design is the right approach. That is, your undying need in itself is not a justification. Some things just cannot or should not be done. > I will certainly say that there are hard feelings on both sides.=C2=A0 = =C2=A0In fact, it was as a result of this whole incident, as well as others= that I have seen at > the IETF , that I wrote, along with Henning Schulzrinne, a draft on "Conf= lict Resolution at the IETF".=C2=A0 =C2=A0I do not want to start a discussi= on of that draft > here.=C2=A0 After Thanksgiving, I will post it on the IETF-discuss email = list.=C2=A0 This is something that the entire community needs to discuss. I have read it but I feel that you are conflating a failed process with not geting your desired outcome. While I do think IETF at times fails in its process, I do not see how it failed on draft-green. >=20 > I hope that we can build bridges.=C2=A0 =C2=A0The Internet is used for bu= siness.=C2=A0 I know that I myself do Internet banking, payment and so on.= =C2=A0 I am not just doing > google queries (or looking at the latest episode of "The Trump Show").=C2= =A0 =C2=A0 There are needs that need to be considered.. Those needs were considerated at length, and the outcome was that there was no secure way of covering your needs with protocol changes. The recommendation was to do this at the implementation level. > We need to work together. Working together does not mean you are guaranteed your desired outcome. > I do think we can improve some of our processes. I agree in general we can and should. But frankly, I do not see a process improvement that would have an outcome for biulding a MITM infrastructure that the enterprise people want that is not strictly limited to enterprise or data center only without potential abuse by small criminals or nation states. > I also care deeply about the enterprises and their needs.=C2=A0 I know th= em, they have been my world for the last 30 years.=C2=A0 When an issue gets= passionate,=C2=A0 > people can get tunnel vision and stop listening to others.=C2=A0 I hope w= e can learn to change that.=C2=A0 Believe me, I feel that there is plenty o= f blame to go > around on all sides of this issue.=C2=A0 But, I hope we can learn from it= to make our process better.=C2=A0=C2=A0 I disagree with "tunnel vision" and "getting passionate" and "make the process better" with respect to the specific "enterprise TLS" needs. You feel this is reaching out to the generic IETF, but to me it appears more as a sign you misunderstood the process and why this outcome was rightfully reached. Paul =20 ------=_Part_2351943_1670394981.1542549187247 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>I agree in general we can = and should. But frankly, I do not see a
>process improvement that would have an outcome for biulding a MITM
>infrastructure that the enterprise= people want that is not strictly
>= ;limited to enterprise or data center only without potential abuse
>by small criminals or nation stat= es.

= Is the "potential abuse by small criminals and nation states" in the TLS = charter or is that your political belief at work?

=
Is it that = certain political stances are OK to hold and others not OK?  

<= /div>
So you are really telling me that the dec= ision is political / moral, not technical?
 
Thanks,

Nalini = Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.co= m
(831) 659-8360


From: Paul Wouters <paul@nohats.ca>
To: Nalini J Elkins <nalini.elkins@in= sidethestack.com>
Cc: Hrpc <hrpc@irtf.org>
Sen= t: Saturday, November 17, 2018 8:18 PM
Subject: Re: [hrpc] "We try to avoid"

On Sat, 17 No= v 2018, Nalini J Elkins wrote:

[this i= s turning into a TLS post mortem, and not just hrpc. Chairs: do let us know= if we should take this topic elsewhere]

> They went to ETSI at the advice of IETF leadership and senior IETFe= rs.   People TOLD them to go to another standards organization.&n= bsp; 

I cannot speak for the IETF= leadership, but I think the advise was
likely phrased as= "it is a bad idea, and you cannot get it here. try
elsew= here if you really want to try this bad idea to be standarized".

> A number of enterprises feel they have th= eir needs in this area.   Their needs will not go away.  The= y need to be addressed.

Since the 80s = governments wanted backdoors in crypto. Their need has not
gone away. Yet we still believe not putting that in algorithm design isthe right approach. That is, your undying need in itself i= s not a
justification. Some things just cannot or should = not be done.

> I will certainly say= that there are hard feelings on both sides.   In fact, it was as= a result of this whole incident, as well as others that I have seen at
> the IETF , that I wrote, along with Henning Schulzrinne= , a draft on "Conflict Resolution at the IETF".   I do not want t= o start a discussion of that draft
> here.  After= Thanksgiving, I will post it on the IETF-discuss email list.  This is= something that the entire community needs to discuss.
I have read it but I feel that you are conflating a failed= process with not
geting your desired outcome. While I do= think IETF at times fails in
its process, I do not see h= ow it failed on draft-green.
>
>= I hope that we can build bridges.   The Internet is used for bus= iness.  I know that I myself do Internet banking, payment and so on.&n= bsp; I am not just doing
> google queries (or looking = at the latest episode of "The Trump Show").    There are needs th= at need to be considered..

Those needs= were considerated at length, and the outcome was that there
was no secure way of covering your needs with protocol changes. The
recommendation was to do this at the implementation level.
> We need to work together.

Working together does not mean you are guarant= eed your desired outcome.

> I do th= ink we can improve some of our processes.

I agree in general we can and should. But frankly, I do not see a
process improvement that would have an outcome for biulding a = MITM
infrastructure that the enterprise people want that = is not strictly
limited to enterprise or data center only= without potential abuse
by small criminals or nation sta= tes.

> I also care deeply about the= enterprises and their needs.  I know them, they have been my world fo= r the last 30 years.  When an issue gets passionate, 
> people can get tunnel vision and stop listening to others. = ; I hope we can learn to change that.  Believe me, I feel that there i= s plenty of blame to go
> around on all sides of this = issue.  But, I hope we can learn from it to make our process better.&n= bsp; 

I disagree with "tunnel vis= ion" and "getting passionate" and "make the
process bette= r" with respect to the specific "enterprise TLS" needs. You
feel this is reaching out to the generic IETF, but to me it appears
more as a sign you misunderstood the process and why this out= come was
rightfully reached.


Paul


------=_Part_2351943_1670394981.1542549187247-- From nobody Sun Nov 18 06:19:43 2018 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 6B5061277BB for ; Sun, 18 Nov 2018 06:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, 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 DDnbaTtzWhTL for ; Sun, 18 Nov 2018 06:19:40 -0800 (PST) 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 F35BF126CC7 for ; Sun, 18 Nov 2018 06:19:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E5CABE39; Sun, 18 Nov 2018 14:19:37 +0000 (GMT) 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 5kKPI013ITGU; Sun, 18 Nov 2018 14:19:36 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 11BD3BE2E; Sun, 18 Nov 2018 14:19:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542550776; bh=g4EmIsbvtct3cxyM+XW0UTdH2gatVqoTRnvHLaym6dU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ynlx2NiRxMV5g0dEfw4bdwEnEk3/BUTvBWX4P4V12l/rB99Q6O6x5oEL8S8aW/030 70CJsqWWsZijyq5vLmTeTSZEtLvrZKnvZJ7/tG1nSe24NfrLiMI1B5Kv6YHkJZWkSs n/qKfs5k7SZswLb7Xjp1KYyWZuUK3w466k9fODxE= To: Nalini J Elkins Cc: Hrpc References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sun, 18 Nov 2018 14:19:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <903392906.2101109.1542469530498@mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jE63VAePYkBsQitygvqFderlsN4fcX1Cy" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 14:19:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jE63VAePYkBsQitygvqFderlsN4fcX1Cy Content-Type: multipart/mixed; boundary="rjegy2gAQqWHcIGtAvtWyTAlAznFzDc0E"; protected-headers="v1" From: Stephen Farrell To: Nalini J Elkins Cc: Hrpc Message-ID: Subject: Re: [hrpc] "We try to avoid" References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> In-Reply-To: <903392906.2101109.1542469530498@mail.yahoo.com> --rjegy2gAQqWHcIGtAvtWyTAlAznFzDc0E Content-Type: multipart/mixed; boundary="------------04947591252F669F9C668C8F" Content-Language: en-GB This is a multi-part message in MIME format. --------------04947591252F669F9C668C8F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/11/2018 15:45, Nalini J Elkins wrote: > They went to ETSI at the advice of IETF leadership and senior > IETFers. People TOLD them to go to another standards organization. I do not believe the above are accurate statements. If they are, please say who said what to whom. If you cannot, it'd be far better to not make such statements that you can't substantiate. My understanding is that the threat of that kind of forum shopping was an argument used by those who wanted to break TLS, as in "if you don't give us what we want, we'll go and do it" ( being either ETSI or ANSI at the time, as we can now see they forum shopped over to ETSI for their rubber stamp). I've no idea where that idea/plan originated but if it did come from IETF leadership (as in IAB or IESG members), then it would be useful to the community to know that. If it did not, then I'd suggest you clarify at least that as some (me included) would like to give nomcom feedback about any IESG or IAB member who gave such "advice." S. --------------04947591252F669F9C668C8F Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------04947591252F669F9C668C8F-- --rjegy2gAQqWHcIGtAvtWyTAlAznFzDc0E-- --jE63VAePYkBsQitygvqFderlsN4fcX1Cy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvxdPcACgkQWrL68XsX K+qovA/9EZo4ypV4CBy0vQIP5JGNzvySmUsYsOP2bNYmFKEa3uB6giwh+1RzXfRR hbOUbfXZNAS7XAYBGxXIw2+6ohwV8/itcqtlwDn/s9H5mwlW6e88FJXXJ36aTNbv jCFelVim5FZzEsu6QmrE3zOzFDeLPXA+snsjaBeAZY81pXl2vvMB/QCyxUTStBE7 oV5I6IQyny6/JuqpaXG7lIDHv90tGlX2C6CM1BTRXWUMlqpDaSnlxV2pMynUvsr1 +FgbfavCZrw+xE911XrHcMAedMh2RbyspUzKMxktUwxukNYjZ/K/84YtsvUiDCgg OnqsvtM9QJk2uMmwhV0ciJjNwDYWGdKWJpGnHQFPYGtM1b/YhRY1dJ2LuoNJRD7x U9da3XjyYo1zi17dns1J+/b/PqLtLhMm1HcIh8HaADScFOTbbEKqOR8QON7Qj0Gc mPWNs/k66wJja/cWSFgkPS4HTdeH05D4y6gYIxTGl0GS6rWoMQPCysTxs7G09cC2 VjMpcDgJbMMJBMGhpRKuwHvTbFm8P5TKKvd8vUFN5gu6uTstiq9/D4AexhfDh0E+ Eoqbj7fuDYz131F/hkoHnLQSiIEVwNTKoHqSJneukG2DMUNG0YXwXeCJiJ/7L3zi iz1+W39TUDK/o5NElzJ6oPr1r2P54DaKkDZtFR8HexaJpo4QxdA= =+Orr -----END PGP SIGNATURE----- --jE63VAePYkBsQitygvqFderlsN4fcX1Cy-- From nobody Sun Nov 18 06:33:17 2018 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 268021294D0 for ; Sun, 18 Nov 2018 06:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rps4-fx1UoSo for ; Sun, 18 Nov 2018 06:33:13 -0800 (PST) Received: from sonic316-26.consmr.mail.ne1.yahoo.com (sonic316-26.consmr.mail.ne1.yahoo.com [66.163.187.152]) (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 3D9401277BB for ; Sun, 18 Nov 2018 06:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542551591; bh=GlDKRDtwg2NIXVJmmNBNmHRv2s55PGm5RYDj71dWR34=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ujFQveiV1QrC4dyj6eETa1tWhhKlyYp1KyhEXI1vsfNSp2Hsb6KrG6xVCkGeE2zFdjegGavFynfsE4XQR7gmMtYpVXHL39gDua7ojPomKqX0zDJV62iaYIPIRZ6AE/JeKRF6vEDVwWyB9oe3/aqskpkb+xk0T9RzC+zgNxB1I6tmqjVNdxxTqU7bHtsUlpeqUeyssi76zS1BQLzekURKYXoBYU0FykjMSpZxnA1tBN79HU5DqpSvifhNlRrwq7XrEwwLLVQCihugtyX6z+paN3h1HwbfJ8Ef8C+sWgMVUjmCXPV/krfbPvwGY1/G6BU54SbymcnJs3U5GRHJ4yydgQ== X-YMail-OSG: Rf.LxFoVM1kyKA3vH7ZM0w7.tZNwa.yGvAsWLRELVehi8JHsWthdNq2hY5btB1z vZbYSPSjlTwJG4r8bxvIv0._YGR3ZntCGyJ0f1XbJEbabV.au7w8gSfC20lNy9XGAq0heeh8rSE1 8QB0_UTRK.i9PbKuht0Z_P9CK4TTBdFnZIVtfojCoI0X5DvE0lCV2zGdgX0WN0SK53ThpBCT2wrl K5k9fePXC4PHv09A9LtdDqbvNXOt4tjqW8WwDqDEFyyWrwoJzjfhJmmHeJw4Fx_ghw1gC1irx_kn KexX_VLNm6uZn_nkhuEswU.i2Go2tBPdgSbt_oqgp_ozBqcbPn5LIFi5el8u5mZKQ3Z0V1EfuFWY lfkqM64eiQ3jGayzanck1yGmGIiYZSmaUrzigXBJzMvwqhANkG1YdGs8cUe9oigDB1_Q0KEbs556 LfbUPx5ACpis1HmKifm10awJHYVBX4H6AhtcvOpETReC5h6.xhNeXYl9xWIZooPtYoEdbN0EIAp8 wU7EakhlyMnWoXUl9DQ4qFhY1ucm_Qtd.VcQSlUWexvxDynsltnV7_cwDLx.8_86D5VvkUC82NnJ ZYoOyovxtVLD93eLvJ4EgzvkyegxmCcd5PP6lkGPbSvgunM8KjL2CU1J7AT1njggOn4EfW2afQXc A0e_QlEU7WSRBQJdwa_HIaEUnfv1M8MwLxDYmDciC1OQUOoppFBN.LYMU3_DLiVcxbe3QepCnztr rU0Lgp15looByG2mt9kj1hc1faJPM_I2_4ehi4.OfKa2OlSY1_VNWOg8Ks5nZ1W1AcRvCyrDKGDe gIAFLG.PTXeU9iBWYrQ2jaiF.gLExxvFNy2jbyb7_lJQMgveNiwxwMDQNq0Q.ouaVV2o2DtVFTy9 U_ml1lMHITmqVdUAWZFrXZZ_HHbFi1cPSMWnd6BPEl6DtONIvcEMqKohBXGxwEdMpC_zRQI5p9Xe dGRbHxCQaYX_07zpfgxSt_mdeUDDLjaILChN0VKj2HyAVMsnMhA1duGa.I3.HoDT..ajOhOrEF0F 5vSeeNqeJZYZe4e7kWrL7SjKOe9rCSIag_mUSkaIATPr2WFv5M8KVlGxVJzEjHPZHXx__ Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Nov 2018 14:33:11 +0000 Date: Sun, 18 Nov 2018 14:33:11 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Stephen Farrell Cc: Hrpc Message-ID: <1581724222.2357992.1542551591129@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2357991_690516433.1542551591127" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 14:33:15 -0000 ------=_Part_2357991_690516433.1542551591127 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > if it did=C2=A0come from IETF leadership (as in IAB or IESG members), the= n=C2=A0it would be useful to the community to know that. Indeed it did.=C2=A0 Our enterprises are frankly not savvy enough to know h= ow to "forum shop".=C2=A0 =C2=A0They did not even know how to spell ETSI. Let me check with them and get exactly who told them that.=C2=A0 =C2=A0=C2= =A0=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Stephen Farrell To: Nalini J Elkins =20 Cc: Hrpc Sent: Sunday, November 18, 2018 6:19 AM Subject: Re: [hrpc] "We try to avoid" =20 On 17/11/2018 15:45, Nalini J Elkins wrote: > They went to ETSI at the advice of IETF leadership and senior > IETFers.=C2=A0 People TOLD them to go to another standards organization. I do not believe the above are accurate statements. If they are, please say who said what to whom. If you cannot, it'd be far better to not make such statements that you can't substantiate. My understanding is that the threat of that kind of forum shopping was an argument used by those who wanted to break TLS, as in "if you don't give us what we want, we'll go and do it" ( being either ETSI or ANSI at the time, as we can now see they forum shopped over to ETSI for their rubber stamp). I've no idea where that idea/plan originated but if it did come from IETF leadership (as in IAB or IESG members), then it would be useful to the community to know that. If it did not, then I'd suggest you clarify at least that as some (me included) would like to give nomcom feedback about any IESG or IAB member who gave such "advice." S._______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_2357991_690516433.1542551591127 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1542549222816_15067">> if it did <= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1542549222816_15069">come from IETF leadership (a= s in IAB or IESG members), then it would be useful to the community to know that.

Indeed it did.&n= bsp; Our enterprises are frankly not savvy enough to know how to "forum sho= p".   They did not even know how to spell ETSI.

Let me check with them and get exactly= who told them that.    
 
Thanks,

Nalini ElkinsCEO and Founder
Inside Products, Inc.
www.insidethestack.com
(83= 1) 659-8360


=
From: Stephen Farr= ell <stephen.farrell@cs.tcd.ie>
To: Nalini J Elkins <nalini.elkins@insidethestack.com>= ;
Cc: Hrpc <hrpc@ir= tf.org>
Sent: Sunda= y, November 18, 2018 6:19 AM
Subject: Re: [hrpc] "We try to avoid"



On 17/11/20= 18 15:45, Nalini J Elkins wrote:
> They went to ETSI a= t the advice of IETF leadership and senior
> IETFers.&= nbsp; People TOLD them to go to another standards organization.
I do not believe the above are accurate statements.

If they are, please say who said what to whom. If y= ou cannot,
it'd be far better to not make such statements= that you can't
substantiate.

My understanding is that the threat of that kind of forum
shopping was an argument used by those who wanted to break
TLS, as in "if you don't give us what we want, we'll go
<there> and do it" (<there> being either ETSI or AN= SI at
the time, as we can now see they forum shopped over= to ETSI
for their rubber stamp).

I've no idea where that idea/plan originated but if it didcome from IETF leadership (as in IAB or IESG members), then=
it would be useful to the community to know that. If it = did
not, then I'd suggest you clarify at least that as so= me (me
included) would like to give nomcom feedback about= any IESG
or IAB member who gave such "advice."


= S.
______________= _________________________________
hrpc mailing list
hrpc@irtf.org
https:/= /www.irtf.org/mailman/listinfo/hrpc


------=_Part_2357991_690516433.1542551591127-- From gisela@berkeley.edu Sun Nov 18 15:19:02 2018 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 EECD5130E29 for ; Sun, 18 Nov 2018 15:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=berkeley-edu.20150623.gappssmtp.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 f9od9QUK85wq for ; Sun, 18 Nov 2018 15:19:01 -0800 (PST) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 A4A7E130E2B for ; Sun, 18 Nov 2018 15:19:01 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id u3-v6so11222822pfm.4 for ; Sun, 18 Nov 2018 15:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=CJcB6cTzxix01mPFDHc08quQrQUg3aZ+A78+nCi3wug=; b=r+HyT+j53CFa6fEEISSDKUnvFJ+7T6Umt+WMin7wcyvaxtozvnmSUZdiY/FlABqz22 Ybfi+mDfPIKJQzYzwtqWi/zmABvjtrwm//0W7yDDrTHQ/PJsffRKsqv0eyW74Iu/9QB5 I7ICZL97sIPxwmXhhKcspzfH20X16da1oSW94rnFa9LgOSSjDy0Lg6XMLfvhYNz5VDuX SB4qpjCjhNaUMEMc54kYznXXJ6fqyUpePOwDXm94pDcZYRf1oR8JiN/DsYC0W4SuHd6R 90R+Dg7HEs65nh3Nu3TMXbyPQ0f9PWoi3xfm8K6EnT9xWlmLdXpN1EAQ773Fi3U0Wvhz 08YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=CJcB6cTzxix01mPFDHc08quQrQUg3aZ+A78+nCi3wug=; b=Xc6L0O9skxyVkK3zGOAVzz5S7xIYA4yylVDmWJy0SjGddCojycEqOpwI64ruJG6f/J eW7aDe3MdCH70M2Giwqd+IaMKnegvngiVcSKQdqoRZmuha8oCgcMdkUIook83q0SRHIn BwoUNpqNBJ1PIt/EQXFAmhORPojLCabFYy9w9ztwJWtmYeIWpgDromqcPHYZyLjZyqfd zftFi+a0X0pzrg6LL9bWhu5KVlYnbuSUb0W/y+X9hu76H5sKMcNtynlbb6YLpcyWk7ZE 7sGmVsJ5IHaz/On8o8oA5BAPidngNeI130/5J/W9gZg8WrnSEkE6juPrS8DEVQUVL65g cbPA== X-Gm-Message-State: AGRZ1gI9MKXYnD+Du+I2QAZkN3aMgzHpDapLmypIR/aX6C6WCuQn6mGk 9ZMldBbCHxpStatdXoVCa8bVT2hOpmY= X-Google-Smtp-Source: AJdET5fR0QD9YGgxT8B8nMCxmipz61m2skNgrg5BpcHU3jj1cowLIbsHfs+6WjwHF4sOvthJhqMHcw== X-Received: by 2002:a63:c447:: with SMTP id m7mr17941075pgg.27.1542583140541; Sun, 18 Nov 2018 15:19:00 -0800 (PST) Received: from ?IPv6:2601:644::7d2a:5d89:79ca:aff9:128d? ([2601:644:0:7d2a:5d89:79ca:aff9:128d]) by smtp.gmail.com with ESMTPSA id x3sm9129807pgk.18.2018.11.18.15.18.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Nov 2018 15:18:59 -0800 (PST) From: Gisela Perez de Acha Chavez Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> Date: Sun, 18 Nov 2018 15:18:58 -0800 To: hrpc@irtf.org X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 23:20:05 -0000 Hi everyone. First of all, apologies for my silence. I started my = master's in Berkeley and the change implied time investment that I had = to handle before coming back to the list.=20 The reason I'm writing this email is because I am trying to get up to = speed regarding the status of association draft, that Niels and I = coauthored.=20 While reading Mallory's notes, and watching the last IETF session, I = want to ask why has the draft been taken back to the list and not moved = to last call. I thought there was a clear process regarding this. So if = I am wrong, please correct me.=20 It would be hugely appreciated if we would develop milestones from = draft-association (and probably other drafts as well), since as an = author it has been quite unclear how to make progress. At several = meetings it has been said that the discussion would be taken to the = list, but that did not really happen. Does this indeed mean we have = reached consensus? Please let me know how we can make progress on this = and what the milestones are. (Also, sorry for the new thread but I needed to write from this new = email account) Happy to be back and discuss these issues further,=20 Cheers Gisela P=C3=A9rez de Acha UC Berkeley=20 Human Rights Lawyer | Journalist | Writer=20 From nobody Sun Nov 18 15:36:12 2018 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 3A039129AB8 for ; Sun, 18 Nov 2018 15:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 wOnUmTQNOkad for ; Sun, 18 Nov 2018 15:36:09 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) (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 A300D126BED for ; Sun, 18 Nov 2018 15:36:09 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id wAINZdtd022898; Sun, 18 Nov 2018 18:35:42 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id wAIMSZ88004349; Sun, 18 Nov 2018 17:28:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23537.59283.637980.721228@gargle.gargle.HOWL> Date: Sun, 18 Nov 2018 17:28:35 -0500 From: bzs@theworld.com To: Paul Wouters Cc: Nalini J Elkins , Hrpc In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 23:36:11 -0000 On November 17, 2018 at 23:18 paul@nohats.ca (Paul Wouters) wrote: > Since the 80s governments wanted backdoors in crypto. Their need has not > gone away. Yet we still believe not putting that in algorithm design is > the right approach. That is, your undying need in itself is not a > justification. Some things just cannot or should not be done. What's stopping them? They should just call their NSA crypto geniuses (and I don't mean that sarcastically they really do hire many crypto geniuses), or equivalent for other countries, or form and fund some sort of multinational research group, and ask them to design something according to their desired specifications and present that to the world. I first got on the net ca 1978 and just about every time I showed it to someone their first question was: Hmm, fascinating, but...who is in charge of all this? Every...single...time. People still imagine there's some core committee in charge of the internet who, if you could just get on the phone and bend their ear, would fix perceived deficiencies. So they yell at Facebook, Google, ICANN, Apple, etc, the headline target du jour, and often just at megaphones aimed nowhere in particular. Next time a govt spokesperson asks for this the right question to ask is: And who are you addressing this request to, specifically? And you'll be shrugged away because they don't know. They think they're running some sort of political campaign at best. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Sun Nov 18 15:37:27 2018 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 3EC5D129AB8 for ; Sun, 18 Nov 2018 15:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 kyJYESLZstT6 for ; Sun, 18 Nov 2018 15:37:23 -0800 (PST) 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 5281F126BED for ; Sun, 18 Nov 2018 15:37:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8760ABE58; Sun, 18 Nov 2018 23:37:21 +0000 (GMT) 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 6xee9CSqhFUm; Sun, 18 Nov 2018 23:37:19 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A0F76BE53; Sun, 18 Nov 2018 23:37:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542584239; bh=vyCcz/iFR+yXQLpPuV0TmAlevY/4b78ezTZZ3Y25mfo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eV4j9eKkWxWtUDipJf+uNDRcnM5fMKPR6RDFFosBat0SLNhwqMnPVkLGqy6eckGMj pLdGi2e8Q1/COHHGHnWDXlyMzTP0VfQEUmLzulMPdTHB9n8LU8NQXyYzdTIaixB33g e712HPjG+o8WxEcnTeaaeElQTDCrvRlP/xbHvMHY= To: Nalini J Elkins Cc: Hrpc References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> <1581724222.2357992.1542551591129@mail.yahoo.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <53ea5d29-f8a8-d103-3323-e239c4e77ae5@cs.tcd.ie> Date: Sun, 18 Nov 2018 23:37:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1581724222.2357992.1542551591129@mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7k0kkyf4k2DWst2lJV63C1YYhLvv4flmr" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 23:37:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7k0kkyf4k2DWst2lJV63C1YYhLvv4flmr Content-Type: multipart/mixed; boundary="3XYawGjeQ12OK7TZFdX9VLXtKoIgqsLDG"; protected-headers="v1" From: Stephen Farrell To: Nalini J Elkins Cc: Hrpc Message-ID: <53ea5d29-f8a8-d103-3323-e239c4e77ae5@cs.tcd.ie> Subject: Re: [hrpc] "We try to avoid" References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <20181114163404.eodmzqdirmfdhwdc@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> <1581724222.2357992.1542551591129@mail.yahoo.com> In-Reply-To: <1581724222.2357992.1542551591129@mail.yahoo.com> --3XYawGjeQ12OK7TZFdX9VLXtKoIgqsLDG Content-Type: multipart/mixed; boundary="------------A33C6DC12A676A1F61E73124" Content-Language: en-GB This is a multi-part message in MIME format. --------------A33C6DC12A676A1F61E73124 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18/11/2018 14:33, Nalini J Elkins wrote: >> if it did come from IETF leadership (as in IAB or IESG members), >> then it would be useful to the community to know that. > Indeed it did. Our enterprises are frankly not savvy enough to know > how to "forum shop". The dearth of technology clue from those claiming a need to break TLS for their enterprise use cases certainly was notable. Personally, I was extremely puzzled by that as I've never dealt with any bank that was so ignorant of the technology that they themselves use in my 20+ years of occasionally dealing with banks. (Dating back to when I wrote code for EDIFACT message signatures in the early 1990's.) > They did not even know how to spell ETSI.=20 They do seem to have fairly speedily found a spell checker;-) > Let > me check with them and get exactly who told them that. Thanks, That'd be good. Or else please do let us know we don't need to worry that IESG/IAB members are advising people on how to do an end-run around IETF processes by getting an ETSI rubber stamp. S. >=20 > Nalini Elkins CEO and Founder Inside Products, Inc.=20 > www.insidethestack.com (831) 659-8360 >=20 > From: Stephen Farrell To: Nalini J Elkins > Cc: Hrpc Sent: > Sunday, November 18, 2018 6:19 AM Subject: Re: [hrpc] "We try to > avoid" >=20 >=20 >=20 > On 17/11/2018 15:45, Nalini J Elkins wrote: >> They went to ETSI at the advice of IETF leadership and senior=20 >> IETFers. People TOLD them to go to another standards >> organization. > I do not believe the above are accurate statements. >=20 > If they are, please say who said what to whom. If you cannot, it'd be > far better to not make such statements that you can't substantiate. >=20 > My understanding is that the threat of that kind of forum shopping > was an argument used by those who wanted to break TLS, as in "if you > don't give us what we want, we'll go and do it" ( > being either ETSI or ANSI at the time, as we can now see they forum > shopped over to ETSI for their rubber stamp). >=20 > I've no idea where that idea/plan originated but if it did come from > IETF leadership (as in IAB or IESG members), then it would be useful > to the community to know that. If it did not, then I'd suggest you > clarify at least that as some (me included) would like to give nomcom > feedback about any IESG or IAB member who gave such "advice." >=20 > S._______________________________________________ hrpc mailing list=20 > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 >=20 >=20 >=20 > _______________________________________________ hrpc mailing list=20 > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >=20 --------------A33C6DC12A676A1F61E73124 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------A33C6DC12A676A1F61E73124-- --3XYawGjeQ12OK7TZFdX9VLXtKoIgqsLDG-- --7k0kkyf4k2DWst2lJV63C1YYhLvv4flmr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvx968ACgkQWrL68XsX K+o52RAAzVj0OOl/8TsUTxIXujZNe9DoS0BglsifU74lYcA/sGtQ3nw/lusN4Ki5 sHN+S6Hck6e0EDpVsz8TCWWqELy/LU6lX7G86jD44gkeETSnEPs0LhI6z/O6NBEs ASfZtOxiTxmfGGaHPHMxErHiLTCgP56waeVIpEN8crtdPXhlNAm7cvU3CPJvpgJC P75LS0EG/jn5quIAV8I15EM33r9E634kD5eXDd5sDb/iTyp/QWYi59ZfwGhWHw4t ajr8JOBgipxT0n6VIEFMCbOFz6sH2byiOLvNgh11B4qlI0EWHbeSlqgjcXi1ti0Z ydfh7a7UI/TQ93aHq1Cn3IFOacb9nXNeEYgUwV+nnhe/hmTJuhtrXbxyh5XsIMim rwBEha9mbkiU5/qtrOTr9MQxDsRn7r0JG6sFG11wL3+WPINSw0ZFgGT3ELI2BozB LmD+xJ70ObMd6FCuLfBO7QUivNEivMnp0PvMfgz/clJVQohymko/NZrNM974wONE 4pgbpfYaZKAdXRFDPA6SxGu0yVryre8VLZUalK4T4qGTF0At5OO1OSs1/Zcr16hB 3Kk7+TTJaUqk12zN0yHBTjssA+fG3q6ID0uOc5cHGvpsgSiSnx/S7zhzAr4+61Ia i6HogMyVhLBIymLU4QwJYxtp22NH7phPABbbqj5I1K5ATmoCjDk= =UFzi -----END PGP SIGNATURE----- --7k0kkyf4k2DWst2lJV63C1YYhLvv4flmr-- From nobody Sun Nov 18 15:50:48 2018 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 C9659126BED for ; Sun, 18 Nov 2018 15:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcqLfTUiCL_3 for ; Sun, 18 Nov 2018 15:50:44 -0800 (PST) Received: from sonic316-27.consmr.mail.ne1.yahoo.com (sonic316-27.consmr.mail.ne1.yahoo.com [66.163.187.153]) (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 9A57F12D4EE for ; Sun, 18 Nov 2018 15:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542585042; bh=8llWd6nk9SO9dR4mPlt6D5X+cV8L5b9D/EWwVQNuCkw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ro/kw2lq3rvDEsLI1GZSqPq1L7JCtCyEIpQXyJ3+a75anlIDD4Dj0NNAA6rjehfmkK8e1VRzrY11bd6QkIFCBJKHbSGwD8U2IqNJKoKoye8ydW7ryhfIwDPQhUegYHR02slwSJ+SczYW7W6O6fqk3G2MDc/7XSjf5mpuUYID+yZ1QXfz70aq1ID+Ea4jf07pEtCg7CAYcDCJGpbNro5AOa9aBS1SxQvaHV3UE691TEs3cOtOfhw7hJahHmMI4B22mXK7d+W/lClPZ1oDKac4+sRhMa4KxERa3HhdBe4fMsA3pKNbqxxUcnKCgxePvbTV6KuOfgrUVuu5GSf4PNQbng== X-YMail-OSG: WjX6dg0VM1lp.qaI0OYhJxW75XiolKbYSJn6eHThNfgy3mlAmqhcOTI4Z_rrzh_ 6kOVzxz5JWBiOe55cb24330J5vGIpLD02uthtjLh1dmSyB8aUKpD98UhpuBaqunRzC2snVnwTSzf ZoVdFTMnXU4w.uW9UJWJzqiBEozamMZfbiHaZKvUuHQzdEsVnN92MGoCBhAEu0i78mHGFSGguDGD VsL._WMLf.SY0NSSlhmw3QJLZQwqYzu_MaRLyGKXtkkYiAxtPKiUQGVdlgmTdl9G1nzxUzpJFRoA 7740td4UC63UAE3B0QW6VGI7i12XIGFL2jJuFyJBpI_YYi3_tfSF6uRiD_6A6W2PhS1k.c2aI_37 Cpx6jTb39yQUpd0botAiwRC.p2FRTRpzKstEsMalNtsaSMdJ2fmyRCF58HavA6ON32EIm5zT9DDD bZNrS8RLsKbPdQNFq66GJ8Jh0d9Ycm6ESYc61Aw9pRMYRYv9V7AzRKnp2AvwApC2HDo_O6haAagk OFoxRzPisivJULNma9Rd.J1PCqKtKXVTMRJg7bSTn_bqKkVtShiLRmmBiUN8280N_e8O.GpOP5ti cIuk0Svdz4LGRe5KiIK_Hnl2hZZSNHCVAvOSRQApsZp39L5H2_geeW56136O4nXgXGVFcrVR_ptq dGitLJrLQvG_D_8oWF38AZl3XSCjWKU0cyrSul2Wt18ecp3I5XsK8cgCR8ujcWDry1ivjxsBKBZk GeEek7WxWxeaj76fF1aBkMWeYRxMheQzX4Z77QpGT6pF.B5uKOu.rs.LfAd71M6k.LsQvzo2nvbu zymqni7HHl61wo8_yxhOBDF54OOmdB0zgD_Ij.rvT95HSe4TRD9UN6DvXfZXqdLp5WXw21GhadU_ yFttgyXxb326Knis3_Fbtm5E4jVdSLt1toOX7jkpYiwP9pwfHfHzQfbM3P7XhlGNLnp1fUrCDV0r qsMp.yawqGBwaOFqOYmU5gLlpSFpH6zu5ZFEtjhp7ZpubWbhYSdGc.8XIpzrX8JbCZVnMgUJaKBp Idst8e4gXrQmAvt9J2A29ZaQMdH.9hX8rcuxMa9bNeuvh1Hx4yf3Q0P_nDGJov3n2JVWD.yg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Nov 2018 23:50:42 +0000 Date: Sun, 18 Nov 2018 23:50:40 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Stephen Farrell Cc: Hrpc Message-ID: <263834870.2536677.1542585040480@mail.yahoo.com> In-Reply-To: <53ea5d29-f8a8-d103-3323-e239c4e77ae5@cs.tcd.ie> References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> <1581724222.2357992.1542551591129@mail.yahoo.com> <53ea5d29-f8a8-d103-3323-e239c4e77ae5@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2536676_1728533064.1542585040477" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 23:50:47 -0000 ------=_Part_2536676_1728533064.1542585040477 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >The dearth of technology clue from those claiming a need to >break TLS for their enterprise use cases certainly was notable. What I meant is that they do not know how the standards world works. They are users of the protocols.=C2=A0 If there is any ignorance, then inth= e interests of getting the best feedback possible, we should behelping them= to express themselves instead of criticizing them.=C2=A0 =C2=A0They are no= vices in this world. They have a great deal of expertise and experience in operating largenetwor= ks.=C2=A0 We need the help of such operators to make our protocolsbetter.= =C2=A0 I am sure there is much about their world that you do not know. I invite you specifically to work with me on the IPv6 and other trainingtha= t I do with enterprise operators.=C2=A0 The more the IETF and enterpriseskn= ow each other and their world, the better I believe we all will be.=C2=A0 = =C2=A0They are not going away.=C2=A0 =C2=A0For engineers, ignoring portions= of realityis a bad idea. I applaud=C2=A0them for stepping into such an intimidating arena as theTLS = Working Group.=C2=A0 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Stephen Farrell To: Nalini J Elkins =20 Cc: Hrpc Sent: Sunday, November 18, 2018 3:37 PM Subject: Re: [hrpc] "We try to avoid" =20 On 18/11/2018 14:33, Nalini J Elkins wrote: >> if it did come from IETF leadership (as in IAB or IESG members), >> then it would be useful to the community to know that. > Indeed it did.=C2=A0 Our enterprises are frankly not savvy enough to know > how to "forum shop". The dearth of technology clue from those claiming a need to break TLS for their enterprise use cases certainly was notable. Personally, I was extremely puzzled by that as I've never dealt with any bank that was so ignorant of the technology that they themselves use in my 20+ years of occasionally dealing with banks. (Dating back to when I wrote code for EDIFACT message signatures in the early 1990's.) > They did not even know how to spell ETSI.=20 They do seem to have fairly speedily found a spell checker;-) > Let > me check with them and get exactly who told them that.=C2=A0 =C2=A0 Thank= s, That'd be good. Or else please do let us know we don't need to worry that IESG/IAB members are advising people on how to do an end-run around IETF processes by getting an ETSI rubber stamp. S. >=20 > Nalini Elkins CEO and Founder Inside Products, Inc.=20 > www.insidethestack.com (831) 659-8360 >=20 > From: Stephen Farrell To: Nalini J Elkins > Cc: Hrpc Sent: > Sunday, November 18, 2018 6:19 AM Subject: Re: [hrpc] "We try to > avoid" >=20 >=20 >=20 > On 17/11/2018 15:45, Nalini J Elkins wrote: >> They went to ETSI at the advice of IETF leadership and senior=20 >> IETFers.=C2=A0 People TOLD them to go to another standards >> organization. > I do not believe the above are accurate statements. >=20 > If they are, please say who said what to whom. If you cannot, it'd be > far better to not make such statements that you can't substantiate. >=20 > My understanding is that the threat of that kind of forum shopping > was an argument used by those who wanted to break TLS, as in "if you > don't give us what we want, we'll go and do it" ( > being either ETSI or ANSI at the time, as we can now see they forum > shopped over to ETSI for their rubber stamp). >=20 > I've no idea where that idea/plan originated but if it did come from > IETF leadership (as in IAB or IESG members), then it would be useful > to the community to know that. If it did not, then I'd suggest you > clarify at least that as some (me included) would like to give nomcom > feedback about any IESG or IAB member who gave such "advice." >=20 > S._______________________________________________ hrpc mailing list=20 > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >=20 >=20 >=20 >=20 >=20 > _______________________________________________ hrpc mailing list=20 > hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >=20 ------=_Part_2536676_1728533064.1542585040477 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>The dearth of technology clue from those claiming a need to=
>break TLS for their enterprise use cases certainly was notable.
=

What I meant is that they do not know how the standards world = works.

They are users of the protocols.  If there is any ignorance, then in=
the interests of ge= tting the best feedback possible, we should be
helping them to express themselves i= nstead of criticizing them.   
They are novices in this world.

They have a great deal of = expertise and experience in operating large
networks.  We need the help of such operators = to make our protocols
better.  I am sure there is much about their world that = you do not know.
I invite you speci= fically to work with me on the IPv6 and other training
that I do with enterprise op= erators.  The more the IETF and enterprises
know each other and their world, t= he better I believe we all will be.   
They are not going away.  &nb= sp;For engineers, ignoring portions of reality
is a bad idea.

I applaud them for steppi= ng into such an intimidating arena as the
TLS Working Group.
 
Thanks,

Nalini El= kins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com<= br>(831) 659-8360



________________________________
From:= Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: Nalini J Elkins &= lt;nalini.elkins@insidethestack.com>
Cc: Hrpc <hrpc@irtf.org><= br>Sent: Sunday, November 18, 2018 3:37 PM
Subject: Re: [hrpc] "We try t= o avoid"





On 18/11/2018 14:33, Nalini J Elkins wrote= :
>> if it did come from IETF leadership (as in IAB or IESG member= s),
>> then it would be useful to the community to know that.
&= gt; Indeed it did.  Our enterprises are frankly not savvy enough to kn= ow
> how to "forum shop".

The dearth of technology clue from t= hose claiming a need to
break TLS for their enterprise use cases certain= ly was notable.
Personally, I was extremely puzzled by that as I've neve= r dealt
with any bank that was so ignorant of the technology that theythemselves use in my 20+ years of occasionally dealing with banks.
(Da= ting back to when I wrote code for EDIFACT message signatures
in the ear= ly 1990's.)

> They did not even know how to spell ETSI.

T= hey do seem to have fairly speedily found a spell checker;-)

> Le= t
> me check with them and get exactly who told them that.  &nbs= p; Thanks,

That'd be good. Or else please do let us know we don't n= eed to
worry that IESG/IAB members are advising people on how to do anend-run around IETF processes by getting an ETSI rubber stamp.

S.<= br>
>
> Nalini Elkins CEO and Founder Inside Products, Inc. > www.insidethestack.com (831) 659-8360
>
> From: Stephen= Farrell <stephen.farrell@cs.tcd.ie> To: Nalini J Elkins
> <= nalini.elkins@insidethestack.com> Cc: Hrpc <hrpc@irtf.org> Sent:> Sunday, November 18, 2018 6:19 AM Subject: Re: [hrpc] "We try to
= > avoid"
>
>
>
> On 17/11/2018 15:45, Nalini = J Elkins wrote:
>> They went to ETSI at the advice of IETF leaders= hip and senior
>> IETFers.  People TOLD them to go to anothe= r standards
>> organization.
> I do not believe the above ar= e accurate statements.
>
> If they are, please say who said wh= at to whom. If you cannot, it'd be
> far better to not make such stat= ements that you can't substantiate.
>
> My understanding is th= at the threat of that kind of forum shopping
> was an argument used b= y those who wanted to break TLS, as in "if you
> don't give us what w= e want, we'll go <there> and do it" (<there>
> being eith= er ETSI or ANSI at the time, as we can now see they forum
> shopped o= ver to ETSI for their rubber stamp).
>
> I've no idea where th= at idea/plan originated but if it did come from
> IETF leadership (as= in IAB or IESG members), then it would be useful
> to the community = to know that. If it did not, then I'd suggest you
> clarify at least = that as some (me included) would like to give nomcom
> feedback about= any IESG or IAB member who gave such "advice."
>
> S.________= _______________________________________ hrpc mailing list
> hrpc@irt= f.org https://www.irtf.org/mailman/listinfo/hrpc

>
>
&= gt;
>
>
> ____________________________________________= ___ hrpc mailing list
> hrpc@irtf.org https://www.irtf.org/mailman/l= istinfo/hrpc
>
------=_Part_2536676_1728533064.1542585040477-- From nobody Sun Nov 18 16:01:32 2018 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 3A84C130E62 for ; Sun, 18 Nov 2018 16:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 cIb4-_3qpfGn for ; Sun, 18 Nov 2018 16:01:21 -0800 (PST) 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 067CC129AB8 for ; Sun, 18 Nov 2018 16:01:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B9EC8BE56; Mon, 19 Nov 2018 00:01:18 +0000 (GMT) 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 vxfWrmLEynJP; Mon, 19 Nov 2018 00:01:15 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8710BE53; Mon, 19 Nov 2018 00:01:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542585674; bh=kWS5uiGITcBfmIr1JAmDEGc9g/IFbAaaQrj8SGndy48=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=O/ALIfSWjelwBRmQ6/I18ZjpQEl5sMrNA4XQvBqDAbu6CWz4fezAsPbr6aj+FDATQ CRmFmm5aGNWraGY7V/y3eZTAak8Zob+TIumCoRhaGCm1iKWi9RSx+cUqzHN2en6Brp JSlrWHxUemupQAM7FZkuzNVUemEnEE87Y4LQ5OcY= To: Nalini J Elkins Cc: Hrpc References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> <1581724222.2357992.1542551591129@mail.yahoo.com> <53ea5d29-f8a8-d103-3323-e239c4e77ae5@cs.tcd.ie> <263834870.2536677.1542585040480@mail.yahoo.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Mon, 19 Nov 2018 00:01:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <263834870.2536677.1542585040480@mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d6KjuY48vP8M7nrnkKaWhbMLyUs4177f0" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 00:01:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d6KjuY48vP8M7nrnkKaWhbMLyUs4177f0 Content-Type: multipart/mixed; boundary="SpfyFBsBhjFWMa7H8tlZ21VGQwojrnbFR"; protected-headers="v1" From: Stephen Farrell To: Nalini J Elkins Cc: Hrpc Message-ID: Subject: Re: [hrpc] "We try to avoid" References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> <1581724222.2357992.1542551591129@mail.yahoo.com> <53ea5d29-f8a8-d103-3323-e239c4e77ae5@cs.tcd.ie> <263834870.2536677.1542585040480@mail.yahoo.com> In-Reply-To: <263834870.2536677.1542585040480@mail.yahoo.com> --SpfyFBsBhjFWMa7H8tlZ21VGQwojrnbFR Content-Type: multipart/mixed; boundary="------------074BB0730BD2D068C3612984" Content-Language: en-GB This is a multi-part message in MIME format. --------------074BB0730BD2D068C3612984 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18/11/2018 23:50, Nalini J Elkins wrote: >> The dearth of technology clue from those claiming a need to break >> TLS for their enterprise use cases certainly was notable. >=20 >=20 > What I meant is that they do not know how the standards world works Fair enough. OTOH what I meant was that the level of ignorance of their own systems demonstrated by the repeated presentation of slide 3 of [1] seemed then, and still seems, incredible. I haven't ever had a meeting with a bank that involved such a lack of knowledge of their own systems. But maybe I've just been lucky in the banks with which I've had meetings. [1] https://datatracker.ietf.org/meeting/99/materials/slides-99-tls-sessb-imp= act-of-tls-13-on-network-ops-00 > They are users of the protocols. If there is any ignorance, then > inthe interests of getting the best feedback possible, we should > behelping them to express themselves instead of criticizing them. I don't see how one can offer meaningful feedback to someone who openly declares ignorance of their own systems to be honest. Not in an IETF context anyway. (Perhaps there's a relevant self-help organisation somewhere for such sysadmins, but the IETF is not that organisation;-) S. > They are novices in this world. They have a great deal of expertise > and experience in operating largenetworks. We need the help of such > operators to make our protocolsbetter. I am sure there is much about > their world that you do not know. I invite you specifically to work > with me on the IPv6 and other trainingthat I do with enterprise > operators. The more the IETF and enterprisesknow each other and > their world, the better I believe we all will be. They are not > going away. For engineers, ignoring portions of realityis a bad > idea. I applaud them for stepping into such an intimidating arena as > theTLS Working Group. Thanks, >=20 > Nalini Elkins CEO and Founder Inside Products, Inc.=20 > www.insidethestack.com (831) 659-8360 >=20 >=20 >=20 > ________________________________ From: Stephen Farrell > To: Nalini J Elkins > Cc: Hrpc Sent: > Sunday, November 18, 2018 3:37 PM Subject: Re: [hrpc] "We try to > avoid" >=20 >=20 >=20 >=20 >=20 > On 18/11/2018 14:33, Nalini J Elkins wrote: >>> if it did come from IETF leadership (as in IAB or IESG members),=20 >>> then it would be useful to the community to know that. >> Indeed it did. Our enterprises are frankly not savvy enough to >> know how to "forum shop". >=20 > The dearth of technology clue from those claiming a need to break TLS > for their enterprise use cases certainly was notable. Personally, I > was extremely puzzled by that as I've never dealt with any bank that > was so ignorant of the technology that they themselves use in my 20+ > years of occasionally dealing with banks. (Dating back to when I > wrote code for EDIFACT message signatures in the early 1990's.) >=20 >> They did not even know how to spell ETSI. >=20 > They do seem to have fairly speedily found a spell checker;-) >=20 >> Let me check with them and get exactly who told them that. >> Thanks, >=20 > That'd be good. Or else please do let us know we don't need to worry > that IESG/IAB members are advising people on how to do an end-run > around IETF processes by getting an ETSI rubber stamp. >=20 > S. >=20 >>=20 >> Nalini Elkins CEO and Founder Inside Products, Inc.=20 >> www.insidethestack.com (831) 659-8360 >>=20 >> From: Stephen Farrell To: Nalini J >> Elkins Cc: Hrpc >> Sent: Sunday, November 18, 2018 6:19 AM Subject: Re: [hrpc] "We try >> to avoid" >>=20 >>=20 >>=20 >> On 17/11/2018 15:45, Nalini J Elkins wrote: >>> They went to ETSI at the advice of IETF leadership and senior=20 >>> IETFers. People TOLD them to go to another standards=20 >>> organization. >> I do not believe the above are accurate statements. >>=20 >> If they are, please say who said what to whom. If you cannot, it'd >> be far better to not make such statements that you can't >> substantiate. >>=20 >> My understanding is that the threat of that kind of forum shopping=20 >> was an argument used by those who wanted to break TLS, as in "if >> you don't give us what we want, we'll go and do it" >> ( being either ETSI or ANSI at the time, as we can now see >> they forum shopped over to ETSI for their rubber stamp). >>=20 >> I've no idea where that idea/plan originated but if it did come >> from IETF leadership (as in IAB or IESG members), then it would be >> useful to the community to know that. If it did not, then I'd >> suggest you clarify at least that as some (me included) would like >> to give nomcom feedback about any IESG or IAB member who gave such >> "advice." >>=20 >> S._______________________________________________ hrpc mailing list >> hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ hrpc mailing list=20 >> hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc >>=20 >>=20 >> _______________________________________________ hrpc mailing list=20 >> hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc --------------074BB0730BD2D068C3612984 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------074BB0730BD2D068C3612984-- --SpfyFBsBhjFWMa7H8tlZ21VGQwojrnbFR-- --d6KjuY48vP8M7nrnkKaWhbMLyUs4177f0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvx/UoACgkQWrL68XsX K+oGbg/+LcfTR3SA7Ppm0ug6uLc3BxW1QyKT6SPL1myV+SYqtb4PX3+cEBF9a5Ru pQnOmqHQM6fPdR7tn3CQOHprMeP3a+aTd3jOG9bW28Nd7cPFcY+yOjJtATqi2+2q cATy3uJgkkGwp2VPRUM/sV4MEaW464oxzBATLNlfpi1ip7O4PxGTTu6D+iMGSpKp N3TD3UDl08HPQXw3B/q/Yi8JPnGQAdB7gmRD3M1z2jcwLyTGoy7XgaAGlCrIoLFL Ya/vnGXpxzdNipPUj2JRrjyvCK7o/xAVYR40XlK+4iZ694WdjZ9ClNuGWbejxE/k tfXBqspyDRv1RFa5FBJ3qAW/4cDf+MfVQs0FOiX+E2CMcByOrCigx2egmvHuWCtx GWMgWr+eS6jQzqOsbLA4vDgQyuLccM1CXyJBO94f6v8GPg/pQjyAwVZ94sYzCTL/ zoVpvBjn+dG1G/gIFqKhWj9j3R+9vqdVJUVOoMsiMzHiNDx3Zg/PZ/+BoYInJslO bv6laej2a1FDWu2iDhs3eoVlrbQrk3OuBvoys6UuxDyPa/YRiIPojpq5bK5euWy9 iBluPX7iB115okbeog5DeDWFkmexOlj9ibJ/urC0Gxw+i6tShR9YxdmjZgAp1tPn 2jn1k8bKGzVrgX3Uu5r+yL2IfSVJkkn0uDcDlX2/3r1M6emgw4s= =qPKz -----END PGP SIGNATURE----- --d6KjuY48vP8M7nrnkKaWhbMLyUs4177f0-- From nobody Sun Nov 18 21:13:38 2018 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 CE1A2128A6E for ; Sun, 18 Nov 2018 21:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 w5YYdpAatxzR for ; Sun, 18 Nov 2018 21:13:35 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 EBB6512D4F0 for ; Sun, 18 Nov 2018 21:13:34 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42yxnQ4XdZzDK8; Mon, 19 Nov 2018 06:13:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542604410; bh=1yivZGh6Ak0/KSCqW7EDErQBqJikC3hKi5jCmPo+miY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pNZp2xZv1B6YMoTiuNtd9w6H1OPElzQVcdRaW4DiIKmuJ+RvthASX2weV7OkFrHnn w/ZVznuGrkkYYfjIV6fKEM1IgHBNJKKOTPg6oRh59/dDGzfU+vqZ3jzEfIkUN8VxQ1 eC8Y57QVo5FiNy8qdD98ahd8WPbEk1/3rCv/o3dA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FpBteYSV-KAu; Mon, 19 Nov 2018 06:13:29 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Nov 2018 06:13:28 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D460E4A2C9E; Mon, 19 Nov 2018 00:13:27 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D460E4A2C9E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C849C41C3B27; Mon, 19 Nov 2018 00:13:27 -0500 (EST) Date: Mon, 19 Nov 2018 00:13:27 -0500 (EST) From: Paul Wouters To: Nalini J Elkins cc: Hrpc In-Reply-To: <1600428938.2351944.1542549187250@mail.yahoo.com> Message-ID: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 05:13:37 -0000 On Sun, 18 Nov 2018, Nalini J Elkins wrote: > >I agree in general we can and should. But frankly, I do not see a > >process improvement that would have an outcome for biulding a MITM > >infrastructure that the enterprise people want that is not strictly > >limited to enterprise or data center only without potential abuse > >by small criminals or nation states. > > Is the "potential abuse by small criminals and nation states" in the TLS charter or is that your political belief at work? A charter cannot cover the denial of every idea that someone might come up with. The way the IETF works is that you suggest to update the charter. In this case, I assume there was no consensus for the charter to be updated to include this request. > Is it that certain political stances are OK to hold and others not OK?   This again mixes up technical with political. Since the first Crypto War, people have tried to come up with a way that ensures the good people can eavesdrop everyone for safetey and security without giving the bad people similar or the same capability as a result. To date, no such solution has been found. Once such a technical solution is found, a charter discussion could be started, but more likely, this would have to involve more then the TLS WG, because the identical case would present itself at various other layers and protocols (eg IPsec) > So you are really telling me that the decision is political / moral, not technical? No I am not. I only touched the technical part. I happen to also believe from a society point of view, that one cannot define good people and bad people or good governments and bad governments as a static concept. So if we could find a technical way, then we would have a really hard non-technical issue at the IETF worth forming a WG over. Paul From nobody Sun Nov 18 21:45:59 2018 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 86297128D68 for ; Sun, 18 Nov 2018 21:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 GQ7gRqAdkorD for ; Sun, 18 Nov 2018 21:45:57 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9FA2C128A6E for ; Sun, 18 Nov 2018 21:45:56 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42yyVh0QdFz3FL; Mon, 19 Nov 2018 06:45:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542606348; bh=IzgcvIHL1WyI24B6DpeD+2UWRg4fjASos8Ls0KhfFIU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=i9SNtS+Er/p+4TmnDWVakS6YuEKqd2yzTSs4lqaMwJQzl/Wi5v4+eAxgjEMnL+X7c L6FJWDAYJOW29g9tGWGRJXtewMEcy7GN87919k3jl2hrQg+L8H2jsc1KrAbyTJRYG5 Ll/lLVXVjCOOHi+uBWpaa/7dKsa/tQe4WUnwKtz0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id y8_Ozt2CWbJu; Mon, 19 Nov 2018 06:45:46 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Nov 2018 06:45:45 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 64E084A2C9E; Mon, 19 Nov 2018 00:45:44 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 64E084A2C9E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 56D3641C3B27; Mon, 19 Nov 2018 00:45:44 -0500 (EST) Date: Mon, 19 Nov 2018 00:45:44 -0500 (EST) From: Paul Wouters To: Nalini J Elkins cc: Hrpc In-Reply-To: <85412976.2311161.1542519317145@mail.yahoo.com> Message-ID: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> <85412976.2311161.1542519317145@mail.yahoo.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 05:45:59 -0000 On Sun, 18 Nov 2018, Nalini J Elkins wrote: > And, truthfully, the way you are phrasing it feels quite disrespectful.     And so do your repeated statements that the IETF has not listened to the enterprise people. > >> A number of enterprises feel they have their needs in this area.   Their needs will not go away.  They need to be addressed. > > >Since the 80s governments wanted backdoors in crypto. Their need has not > >gone away. Yet we still believe not putting that in algorithm design is > >the right approach. That is, your undying need in itself is not a > >justification. Some things just cannot or should not be done. > > Again, with all due respect, this is your opinion rather than an indisputable fact.  I will tell you that others disagree > with you.  They should look into how Bill Clinton went from Clipper Chip to dropping crypto export restrictions. I'm sure some authoritarian or wanna-be-authoritarian regimes disagree with my opinion on the social aspects of citizen monitoring. I am also sure some companies believe their network should not comply to local law, but that does not make it more legal to monitor their employees. I also realise that different laws are posing a contradicting requirement to some enterprises. However, that is is not something the IETF can address. > >I have read it but I feel that you are conflating a failed process with not geting your desired outcome.  > > Please do not make assumptions about what I do and don't think.  For example, you don't know that I actually think that draft-green IS the > right solution.    > What I have always wanted is for enterprises to have a voice.  And for the IETF to work with them. You are mistaken about my assumptions. My only assumption here is that I know the enterprise people's voices were heard, and that you keep repeating they were not. That is why I say you confuse the process with the outcome. I have no opinion about your opinion on draft-green. > > >While I do think IETF at times fails in its process, I do not see how it failed on draft-green. > > The fact that many months after the decision, there are so many hard feelings between so many people that we can hardly talk about this issue > without it erupting into chaos would lead me to think that there is probably a better way.   You and I are talking about different things. > This level of hard feelings is a huge waste of time and energy for many people.  Not to mention the fact that now there are multiple > standards > which may be in conflict.  If you think this is a successful process and outcome, then I would beg to differ. US bank approached me before going public with their requirements. It turned out they approached many more individuals privately at first. I told them during that first meeting that what they wanted was simply impossible. I am sure many more people told them so as well. I do not think we could have done much different at the IETF process when they decided to forge ahead anyway, despite numerous people telling them they would never get conensus for what they were seeking, and that their arguments for "our networks are too big" were seen as mostly a cost-savings requests, and not strong enough to open up a core internet end-to-end security protocol. On top of that, the IETF wrote RFC 8404 where it documented the problems that the enterprise administrators are facing. > >Those needs were considerated at length, and the outcome was that there was no secure way of covering your needs with protocol changes. The > >recommendation was to do this at the implementation level. > > Again, I disagree with you. You mean you disagree with the TLS WG and/or the IETF Security Area. I was not talking about my personal opinion here. > I have talked to a number of cryptographers and there may be number of potential ways of doing this without > violating the > security guarantees of TLS.  But, this is not the time to bring up any potential new ideas. I'm always happy to discuss technical ideas and read drafts. > > >> We need to work together. > > >Working together does not mean you are guaranteed your desired outcome. > > Frankly, this feels condescending.   Please give me credit for a modicum of intelligence.  But do you understand that by saying "we need to work together" that you are implying that "we did not work well together before" ? And that from an IETF point of view, the IETF worked very well with the enterprise people and that the outcome of working together was a lack of consensus? > The process improvement is not about anything in TLS but about how we go about getting to consensus. While I appreciate the efforts of your draft, I am still not convinced there was any way in which we could have gained consensus unless a new technological invention we haven't managed to invent in 20 years would suddenly present itself? So I do question the premise of you writing this draft now. Whether I think we can improve our consensus forming, then yes I think we can and I have a very specific personal case regarding a draft in mind. Although I am not sure a document can address some cultural issues we have within the IETF, it won't hurt to try and formulate things, so I am happy to continue reading updated drafts on this. > >> I also care deeply about the enterprises and their needs.  I know them, they have been my world for the last 30 years.  When an issue gets > passionate,  > >> people can get tunnel vision and stop listening to others.  I hope we can learn to change that.  Believe me, I feel that there is plenty > of blame to go > >> around on all sides of this issue.  But, I hope we can learn from it to make our process better.   > > >I disagree with "tunnel vision" and "getting passionate" and "make the > >process better" with respect to the specific "enterprise TLS" needs. You > >feel this is reaching out to the generic IETF, but to me it appears > >more as a sign you misunderstood the process and why this outcome was > >rightfully reached. > > Again, we are talking about very different things.  You keep bringing up the enterprise case as example for bad consensus forming and now you keep saying you are writing this because of different things. When you bring up "tunnel vission" and the "enterprise use case" in one email, it does seem to be related, and thus in turn that is what upsets me about your emails when it appears these critisisms of tunnel vission and getting passionate seem aimed at the part of the TLS WG that spoke out against the enterprise use case. I will try to feel less personally attacked. but I urge you to better separate these two topics when talking about either topic. Paul From nobody Mon Nov 19 18:57:46 2018 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 A92B6128766 for ; Mon, 19 Nov 2018 18:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9usJ104oG7L for ; Mon, 19 Nov 2018 18:57:40 -0800 (PST) Received: from sonic313-18.consmr.mail.ne1.yahoo.com (sonic313-18.consmr.mail.ne1.yahoo.com [66.163.185.41]) (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 72D8E128CFD for ; Mon, 19 Nov 2018 18:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542682657; bh=kp9X02ij9X6aGSgm/jIVLvWQDaxIZQAunMNdpZibqXU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Nf7TH5dibCgaGQaTz60yhmc516IOD2yXcobF2y2g+2FNTLKGfHk+3iy8yTxhbJGEQh7CAch6GlxTJG5owj5xdMk2Dp0lTLk29onrDKWrVRX1rkhpBSyuqOudgkDb/5WNH1OPqxNwzMQo77Km4EeGvnzOpHk6HrOoDFVHdZVDr7kk75+FVLXVbBbes6KPH0BHKK+JAxcXTdB2eOoMaJrKy9aFy0dzM3iXVt8p3AgWPQfWuWC/GUWUc8BYIBDnBo4x/eopEe9daFQstqmg5PDQqE2gQH6aXWtLdboJQupMN0OC14+xbute7shZ8Uuw4+Wf0641sQ+nQX9QD4xpY6Maew== X-YMail-OSG: lxKFMpoVM1kVG8Vk5e6_m4cLTxBF0NN3xCf3TOO4gveOO3U38yjPj3mG3OCD3TL 3S02Wxy12CTULiNI.Wg8SdOV.CYKWa6fItxV8BdML.SOmVzmlm5pYRqGGsxdlBhWhZTbr3l2.9.5 TTdXoO3salzaU8KFOFHpdAWtO0.HENuqq5xiWU6WfkSZ6TIM8UeCJMNJFox0MdTVix_brGngRX6l 79t7pt7cBSoDZUVVMoSl.BC00SfKtFz_PVkXB168nA7oFNkD053LAeQAKuiGTHuO_RFVYXqJnFsh 8BOi3RGr_SvkQflp8coTnJcZylB0Z4xsjuciT5DYm8vcbdwd54zpc74A0dnDcJrtyVcL3Az0teQi VolBXLVTDmqEw6DgbQe_deHJL6nsn_tDzPYkrPS7R3WTES5hW8hmXHG2Q_KCL847yh.hUYlU8y93 3WRkqjNS1TfdgxzAGsav3Gvwg9F8LoqP.ylmJ0b8JIQ67OlyP_OQHSXU1gksZ3Py1H0WTDkF5oxe feN5PLYU.uHSSS.z2tBo3sq_BHtu86r0t1aOTAtlFywQfuYJgKoAuUW3ZdJ789jiNoATXWVzygo7 jQFr5eMqUZ15a2e51LelUmMyBZbWtg12TZkWQNT3NIoz2rNtJvTuDO98NOUONavZ86jxRavEOr7J XRkO70bawezx8GtlIYm.L3iTx7q4EU6Gq47EJgs6WuB1kXYJcO0AiZi1dxAnKC0.e37CDRZiCFGb fRqIZn_YyZsUE7AcL8V2b8nraNk8wjYx14s2MtJ9OEnP9xdEdo9FPi.QPLE8sBUJTEnYpanmPvgc I0JPrbg7KU7F1B6pUJuPWeputHCWPgTiNDuIg_1GUgmpdXZmAtnd4D0ez2us9HfM.EHqkBKBxBsN zo_dbI3dThRUTYOCXHpFlX9keapJ5U8O3q61HMxmWMtNQHxslxIgU_VhKOHJ0uipU9cPC.rS1769 Pjekiofd_doACINojiEg2jB_SVDc37Uvhs61Sbg0.fu6ASlaQfvGDnO8ydasYEMnlCcogGl2fK72 5SLQK_NJuspdWJamTIkT1B0SQdwTjriJziAnKcp.gsDiY3q5QjZnMXtyMxmp.CiOPoDvKrzE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Tue, 20 Nov 2018 02:57:37 +0000 Date: Tue, 20 Nov 2018 02:57:36 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Paul Wouters Cc: Hrpc Message-ID: <385040095.4192.1542682656806@mail.yahoo.com> In-Reply-To: References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> < C60BD884-A53F-4219-A81F-4B2D7E24E78A@nohats.ca> <903392906.2101109.1542469530498@mail.yahoo.com> <85412976.2311161.1542519317145@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4191_1025673023.1542682656802" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 02:57:45 -0000 ------=_Part_4191_1025673023.1542682656802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> And, truthfully, the way you are phrasing it feels quite disrespectful.= =C2=A0 =C2=A0=C2=A0 >=C2=A0And so do your repeated statements that the IETF has not listened to= the=C2=A0enterprise people. It is not my intention to be disrespectful.=C2=A0 =C2=A0What I feel is that= both parties feel not listened to. If I can put it in terms of Jane and Bob. 1.=C2=A0=C2=A0Jane feels that she is listening to Bob. 2.=C2=A0 Bob feels that he is not being heard by Jane. 3.=C2=A0 Bob feels that he is listening to Jane. 4.=C2=A0 Jane feels that she is not being heard by Bob. I feel that is the situation that we are in. BTW, it is not just the TLS group and the enterprises.=C2=A0 I think that j= ust happens to be the issue that you and I seem to talk about.=C2=A0 =C2=A0= I am sure that you and I will have many differences of opinion in HRPC as w= ell!=C2=A0 I have seen such issues in many WGs : QUIC, v6ops, 6man, and on = and on.=C2=A0 Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Paul Wouters To: Nalini J Elkins =20 Cc: Hrpc Sent: Sunday, November 18, 2018 9:46 PM Subject: Re: [hrpc] "We try to avoid" =20 On Sun, 18 Nov 2018, Nalini J Elkins wrote: > And, truthfully, the way you are phrasing it feels quite disrespectful.= =C2=A0 =C2=A0=C2=A0 And so do your repeated statements that the IETF has not listened to the enterprise people. > >> A number of enterprises feel they have their needs in this area.=C2=A0= =C2=A0Their needs will not go away.=C2=A0 They need to be addressed. >=20 > >Since the 80s governments wanted backdoors in crypto. Their need has not > >gone away. Yet we still believe not putting that in algorithm design is > >the right approach. That is, your undying need in itself is not a > >justification. Some things just cannot or should not be done. >=20 > Again, with all due respect, this is your opinion rather than an indisput= able fact.=C2=A0 I will tell you that others disagree > with you.=C2=A0 They should look into how Bill Clinton went from Clipper Chip to dropping crypto export restrictions. I'm sure some authoritarian or wanna-be-authoritarian regimes disagree with my opinion on the social aspects of citizen monitoring. I am also sure some companies believe their network should not comply to local law, but that does not make it more legal to monitor their employees. I also realise that different laws are posing a contradicting requirement to some enterprises. However, that is is not something the IETF can address. > >I have read it but I feel that you are conflating a failed process with = not geting your desired outcome.=C2=A0 >=20 > Please do not make assumptions about what I do and don't think.=C2=A0 For= example, you don't know that I actually think that draft-green IS the > right solution.=C2=A0 =C2=A0 > What I have always wanted is for enterprises to have a voice.=C2=A0 And f= or the IETF to work with them. You are mistaken about my assumptions. My only assumption here is that I know the enterprise people's voices were heard, and that you keep repeating they were not. That is why I say you confuse the process with the outcome. I have no opinion about your opinion on draft-green. >=20 > >While I do think IETF at times fails in its process, I do not see how it= failed on draft-green. >=20 > The fact that many months after the decision, there are so many hard feel= ings between so many people that we can hardly talk about this issue > without it erupting into chaos would lead me to think that there is proba= bly a better way.=C2=A0 =C2=A0You and I are talking about different things. > This level of hard feelings is a huge waste of time and energy for many p= eople.=C2=A0 Not to mention the fact that now there are multiple > standards > which may be in conflict.=C2=A0 If you think this is a successful process= and outcome, then I would beg to differ. US bank approached me before going public with their requirements. It turned out they approached many more individuals privately at first. I told them during that first meeting that what they wanted was simply impossible. I am sure many more people told them so as well. I do not think we could have done much different at the IETF process when they decided to forge ahead anyway, despite numerous people telling them they would never get conensus for what they were seeking, and that their arguments for "our networks are too big" were seen as mostly a cost-savings requests, and not strong enough to open up a core internet end-to-end security protocol. On top of that, the IETF wrote RFC 8404 where it documented the problems that the enterprise administrators are facing. > >Those needs were considerated at length, and the outcome was that there = was no secure way of covering your needs with protocol changes. The > >recommendation was to do this at the implementation level. >=20 > Again, I disagree with you. You mean you disagree with the TLS WG and/or the IETF Security Area. I was not talking about my personal opinion here. > I have talked to a number of cryptographers and there may be number of po= tential ways of doing this without > violating the > security guarantees of TLS.=C2=A0 But, this is not the time to bring up a= ny potential new ideas. I'm always happy to discuss technical ideas and read drafts. >=20 > >> We need to work together. >=20 > >Working together does not mean you are guaranteed your desired outcome. >=20 > Frankly, this feels condescending.=C2=A0 =C2=A0Please give me credit for = a modicum of intelligence.=C2=A0 But do you understand that by saying "we need to work together" that you are implying that "we did not work well together before" ? And that from an IETF point of view, the IETF worked very well with the enterprise people and that the outcome of working together was a lack of consensus? > The process improvement is not about anything in TLS but about how we go = about getting to consensus. While I appreciate the efforts of your draft, I am still not convinced there was any way in which we could have gained consensus unless a new technological invention we haven't managed to invent in 20 years would suddenly present itself? So I do question the premise of you writing this draft now. Whether I think we can improve our consensus forming, then yes I think we can and I have a very specific personal case regarding a draft in mind. Although I am not sure a document can address some cultural issues we have within the IETF, it won't hurt to try and formulate things, so I am happy to continue reading updated drafts on this. > >> I also care deeply about the enterprises and their needs.=C2=A0 I know= them, they have been my world for the last 30 years.=C2=A0 When an issue g= ets > passionate,=C2=A0 > >> people can get tunnel vision and stop listening to others.=C2=A0 I hop= e we can learn to change that.=C2=A0 Believe me, I feel that there is plent= y > of blame to go > >> around on all sides of this issue.=C2=A0 But, I hope we can learn from= it to make our process better.=C2=A0=C2=A0 >=20 > >I disagree with "tunnel vision" and "getting passionate" and "make the > >process better" with respect to the specific "enterprise TLS" needs. You > >feel this is reaching out to the generic IETF, but to me it appears > >more as a sign you misunderstood the process and why this outcome was > >rightfully reached. >=20 > Again, we are talking about very different things.=C2=A0 You keep bringing up the enterprise case as example for bad consensus forming and now you keep saying you are writing this because of different things. When you bring up "tunnel vission" and the "enterprise use case" in one email, it does seem to be related, and thus in turn that is what upsets me about your emails when it appears these critisisms of tunnel vission and getting passionate seem aimed at the part of the TLS WG that spoke out against the enterprise use case. I will try to feel less personally attacked. but I urge you to better separate these two topics when talking about either topic. Paul _______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_4191_1025673023.1542682656802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1542669679727_40689">>> And, truthfully, th= e way you are phrasing it feels quite disrespectful.    

>&nb= sp;And so do your repeated = statements that the IETF has not listened to the enterprise people.

= It is not my intention to be disrespectful.   What I feel is that= both parties feel not listened to.

If I can put it in terms of Ja= ne and Bob.

1.  Jane feels that she is listeni= ng to Bob.

2.  Bob feels that he is not being heard by Jane.<= /span>
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= ">
3.  Bob feels that he is listening to Jane.

4. = Jane feels that she is not being heard by Bob.

I feel that is th= e situation that we are in.

BTW, it is not just the TLS = group and the enterprises.  I think that just happens to be the issue = that you and I seem to talk about.   I am sure that you and I wil= l have many differences of opinion in HRPC as well!  I have seen such = issues in many WGs : QUIC, v6ops, 6man, and on and on.
 
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insi= dethestack.com
(831) 659-8360


=
From: Paul Wouters <paul@n= ohats.ca>
To: Nalin= i J Elkins <nalini.elkins@insidethestack.com>
Cc: Hrpc <hrpc@irtf.org>
Sent: Sunday, November 18, 2018 9:46= PM
Subject: Re: [hrpc= ] "We try to avoid"

<= div dir=3D"ltr">On Sun, 18 Nov 2018, Nalini J Elkins wrote:

> And, truthfully, the way you are phrasing it fee= ls quite disrespectful.    

And so do your repeated statements that the IETF has not listened to t= he
enterprise people.

> >> A number of enterprises feel they have their needs in this = area.   Their needs will not go away.  They need to be addre= ssed.
>
> >Since the 80s gove= rnments wanted backdoors in crypto. Their need has not
&g= t; >gone away. Yet we still believe not putting that in algorithm design= is
> >the right approach. That is, your undying ne= ed in itself is not a
> >justification. Some things= just cannot or should not be done.
>
> Again, with all due respect, this is your opinion rather than an in= disputable fact.  I will tell you that others disagree
> with you. 

They should lo= ok into how Bill Clinton went from Clipper Chip to
droppi= ng crypto export restrictions.

I'm sur= e some authoritarian or wanna-be-authoritarian regimes disagree
with my opinion on the social aspects of citizen monitoring. I am al= so
sure some companies believe their network should not c= omply to local
law, but that does not make it more legal = to monitor their employees.

I also rea= lise that different laws are posing a contradicting
requi= rement to some enterprises. However, that is is not something the
IETF can address.

> >I= have read it but I feel that you are conflating a failed process with not = geting your desired outcome. 
>
> Please do not make assumptions about what I do and don't think. = ; For example, you don't know that I actually think that draft-green IS the=
> right solution.   
>= What I have always wanted is for enterprises to have a voice.  And fo= r the IETF to work with them.

You are = mistaken about my assumptions. My only assumption here is that I
know the enterprise people's voices were heard, and that you keep=
repeating they were not. That is why I say you confuse t= he process with
the outcome. I have no opinion about your= opinion on draft-green.

>
> >While I do think IETF at times fails in its process, I = do not see how it failed on draft-green.
>
> The fact that many months after the decision, there are so m= any hard feelings between so many people that we can hardly talk about this= issue
> without it erupting into chaos would lead me = to think that there is probably a better way.   You and I are tal= king about different things.
> This level of hard feel= ings is a huge waste of time and energy for many people.  Not to menti= on the fact that now there are multiple
> standards> which may be in conflict.  If you think this is a= successful process and outcome, then I would beg to differ.

US bank approached me before going public with their= requirements. It
turned out they approached many more in= dividuals privately at first.
I told them during that fir= st meeting that what they wanted was simply
impossible. I= am sure many more people told them so as well. I do not
= think we could have done much different at the IETF process when they
decided to forge ahead anyway, despite numerous people telling= them
they would never get conensus for what they were se= eking, and that
their arguments for "our networks are too= big" were seen as mostly a
cost-savings requests, and no= t strong enough to open up a core internet
end-to-end sec= urity protocol.

On top of that, the IE= TF wrote RFC 8404 where it documented the problems
that t= he enterprise administrators are facing.

> >Those needs were considerated at length, and the outcome was th= at there was no secure way of covering your needs with protocol changes. Th= e
> >recommendation was to do this at the implement= ation level.
>
> Again, I disagr= ee with you.

You mean you disagree wit= h the TLS WG and/or the IETF Security Area. I
was not tal= king about my personal opinion here.

&= gt; I have talked to a number of cryptographers and there may be number of = potential ways of doing this without
> violating the> security guarantees of TLS.  But, this is not th= e time to bring up any potential new ideas.

I'm always happy to discuss technical ideas and read drafts.

>
> >> We need = to work together.
>
> >Workin= g together does not mean you are guaranteed your desired outcome.
>
> Frankly, this feels condescending.&n= bsp;  Please give me credit for a modicum of intelligence. 

But do you understand that by saying "we ne= ed to work together" that you
are implying that "we did n= ot work well together before" ? And that from
an IETF poi= nt of view, the IETF worked very well with the enterprise
people and that the outcome of working together was a lack of consensus?
> The process improvement is not abo= ut anything in TLS but about how we go about getting to consensus.

While I appreciate the efforts of your draft, = I am still not convinced
there was any way in which we co= uld have gained consensus unless a new
technological inve= ntion we haven't managed to invent in 20 years would
sudd= enly present itself? So I do question the premise of you writing
this draft now. Whether I think we can improve our consensus form= ing,
then yes I think we can and I have a very specific p= ersonal case regarding
a draft in mind. Although I am not= sure a document can address some
cultural issues we have= within the IETF, it won't hurt to try and
formulate thin= gs, so I am happy to continue reading updated drafts
on t= his.

> >> I also care deeply = about the enterprises and their needs.  I know them, they have been my= world for the last 30 years.  When an issue gets
&g= t; passionate, 
> >> people can get tunnel = vision and stop listening to others.  I hope we can learn to change th= at.  Believe me, I feel that there is plenty
> of= blame to go
> >> around on all sides of this is= sue.  But, I hope we can learn from it to make our process better.&nbs= p; 
>
> >I disagree with= "tunnel vision" and "getting passionate" and "make the
&= gt; >process better" with respect to the specific "enterprise TLS" needs= . You
> >feel this is reaching out to the generic I= ETF, but to me it appears
> >more as a sign you mis= understood the process and why this outcome was
> >= rightfully reached.
>
> Again, w= e are talking about very different things. 

You keep bringing up the enterprise case as example for bad cons= ensus
forming and now you keep saying you are writing thi= s because of
different things. When you bring up "tunnel = vission" and the
"enterprise use case" in one email, it d= oes seem to be related, and
thus in turn that is what ups= ets me about your emails when it appears
these critisisms= of tunnel vission and getting passionate seem aimed
at t= he part of the TLS WG that spoke out against the enterprise use
case. I will try to feel less personally attacked. but I urge you to=
better separate these two topics when talking about eith= er topic.

=
Paul

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

<= br>
------=_Part_4191_1025673023.1542682656802-- From nobody Mon Nov 19 19:52:40 2018 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 3876D127333 for ; Mon, 19 Nov 2018 19:52:37 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 mvbtc6mHaU-U for ; Mon, 19 Nov 2018 19:52:34 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 C4D53124BAA for ; Mon, 19 Nov 2018 19:52:33 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id y16so807807qki.7 for ; Mon, 19 Nov 2018 19:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LbtIT8IwMCw6gwPHARYLl1amd0W6NUO35q2We07uNOE=; b=VJDyNCKLRBfEkzuHVqH0Aj1q+gm0VLamS6wTcsKGcgJc+XwuSQ9Yb3v4dIW+D4jPq7 nsH8V6b20y/MDa1YUnRUXeydh/FcZ4mfS+reUZI8YUHoE33kBmtusOH03agdDcG4E9Uj 5GPCjAN08X+jvSplhC4i17WtfSF1qNYBGODa2Iabh9YxYaB+yekpanA5xLDHjEjk820N ltRe0RCF/RXCZyHwe8m72Xi0OxXo0qadolFVO2KOhWrS4KHc1BjyM2v1FvjVkdwt0oTw CZk6n585XHs3mBFGcFr8xci/zyg+MeFHfyW9TcC2y9gf1CWVUFU7ZrwNXmnV+SDZU5q7 kdXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LbtIT8IwMCw6gwPHARYLl1amd0W6NUO35q2We07uNOE=; b=AcMEAI1BbPErvL/kDcEnB3NfmPCW/sw+CcnS6m+t1RgLpgXPSAtWtjZboVqmSZEAyh auoRYJutxfUIIVjO7LPoZTtLhM91G7R7U9BwScpCQhPBX7aRKebIfGswOyeg3rgrmizf ElGvHNNLQciilSlxaFG2iNwBU6087IH4OEwllc7dEqCZPqQQ/ctsdm8nh4dSz50wggsF +W7YI/KV1jlkIUE/6IYyQl+vi01bIzlBSxUQfnIZSxFFJE/XFGA2607IPnNOJYu8Rzg8 8/o0zQliG2pVcnYV7EhKGgN8LCxzTefxAqXXj8as2n2gFsZK6aAH5vmPF8r0ezL14xmI sloQ== X-Gm-Message-State: AGRZ1gItdQYrO91a3blkp/pwvf6/sM1jDqY+u0lNrSR0oU2U5Frmni1w TAsvifqxMoJ7b7j+LWDlRxVb5JPx0ITYvubkARdncGFlaIY= X-Google-Smtp-Source: AFSGD/Vw+TEDAGwCitbpaNH6+PqTsXMJ396QzhWU0kQZWs253Tqfq0LOErcvsXcCC2eKl40wWI9uPWni9YgoHV13or8= X-Received: by 2002:ac8:7181:: with SMTP id w1mr361874qto.271.1542685952591; Mon, 19 Nov 2018 19:52:32 -0800 (PST) MIME-Version: 1.0 References: <20181114125015.u7htljky6hn2yi4v@nic.fr> <2132865692.1278206.1542315543815@mail.yahoo.com> <612735664.1327555.1542322105746@mail.yahoo.com> <1745543794.1475888.1542349633202@mail.yahoo.com> <1845585316.1607419.1542379498804@mail.yahoo.com> <582080648.1641646.1542380003764@mail.yahoo.com> <957752793.1637300.1542380691010@mail.yahoo.com> <920193363.1649303.1542383177366@mail.yahoo.com> <903392906.2101109.1542469530498@mail.yahoo.com> <85412976.2311161.1542519317145@mail.yahoo.com> <385040095.4192.1542682656806@mail.yahoo.com> In-Reply-To: <385040095.4192.1542682656806@mail.yahoo.com> From: Ted Lemon Date: Mon, 19 Nov 2018 22:51:56 -0500 Message-ID: To: Nalini Elkins Cc: Paul Wouters , Hrpc Content-Type: multipart/alternative; boundary="000000000000345e55057b109061" Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 03:52:37 -0000 --000000000000345e55057b109061 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The problem is that if what it takes for you to "feel heard" is that you get your way, then that's not going to work, as you can quickly see if you game out how this would go in the scenario you offered. So what does it take to "feel heard" and not get your way? This would be something interesting to explore, but I think the answer is that that was not on the table in this particular case=E2=80=94in this case "feeling heard" and "get= ting your way" were synonymous for the particular enterprise folks who tried to change the requirements for TLS 1.3. On Mon, Nov 19, 2018 at 9:57 PM Nalini J Elkins < nalini.elkins@insidethestack.com> wrote: > >> And, truthfully, the way you are phrasing it feels quite > disrespectful. > > > And so do your repeated statements that the IETF has not listened to > the enterprise people. > > It is not my intention to be disrespectful. What I feel is that both > parties feel not listened to. > > If I can put it in terms of Jane and Bob. > > 1. Jane feels that she is listening to Bob. > > 2. Bob feels that he is not being heard by Jane. > > 3. Bob feels that he is listening to Jane. > > 4. Jane feels that she is not being heard by Bob. > > I feel that is the situation that we are in. > > BTW, it is not just the TLS group and the enterprises. I think that just > happens to be the issue that you and I seem to talk about. I am sure th= at > you and I will have many differences of opinion in HRPC as well! I have > seen such issues in many WGs : QUIC, v6ops, 6man, and on and on. > > Thanks, > > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > ------------------------------ > *From:* Paul Wouters > *To:* Nalini J Elkins > *Cc:* Hrpc > *Sent:* Sunday, November 18, 2018 9:46 PM > *Subject:* Re: [hrpc] "We try to avoid" > > On Sun, 18 Nov 2018, Nalini J Elkins wrote: > > > And, truthfully, the way you are phrasing it feels quite disrespectful. > > > And so do your repeated statements that the IETF has not listened to the > enterprise people. > > > >> A number of enterprises feel they have their needs in this area. > Their needs will not go away. They need to be addressed. > > > > >Since the 80s governments wanted backdoors in crypto. Their need has n= ot > > >gone away. Yet we still believe not putting that in algorithm design i= s > > >the right approach. That is, your undying need in itself is not a > > >justification. Some things just cannot or should not be done. > > > > Again, with all due respect, this is your opinion rather than an > indisputable fact. I will tell you that others disagree > > with you. > > They should look into how Bill Clinton went from Clipper Chip to > dropping crypto export restrictions. > > I'm sure some authoritarian or wanna-be-authoritarian regimes disagree > with my opinion on the social aspects of citizen monitoring. I am also > sure some companies believe their network should not comply to local > law, but that does not make it more legal to monitor their employees. > > I also realise that different laws are posing a contradicting > requirement to some enterprises. However, that is is not something the > IETF can address. > > > >I have read it but I feel that you are conflating a failed process wit= h > not geting your desired outcome. > > > > Please do not make assumptions about what I do and don't think. For > example, you don't know that I actually think that draft-green IS the > > right solution. > > What I have always wanted is for enterprises to have a voice. And for > the IETF to work with them. > > You are mistaken about my assumptions. My only assumption here is that I > know the enterprise people's voices were heard, and that you keep > repeating they were not. That is why I say you confuse the process with > the outcome. I have no opinion about your opinion on draft-green. > > > > > >While I do think IETF at times fails in its process, I do not see how > it failed on draft-green. > > > > The fact that many months after the decision, there are so many hard > feelings between so many people that we can hardly talk about this issue > > without it erupting into chaos would lead me to think that there is > probably a better way. You and I are talking about different things. > > This level of hard feelings is a huge waste of time and energy for many > people. Not to mention the fact that now there are multiple > > standards > > which may be in conflict. If you think this is a successful process an= d > outcome, then I would beg to differ. > > US bank approached me before going public with their requirements. It > turned out they approached many more individuals privately at first. > I told them during that first meeting that what they wanted was simply > impossible. I am sure many more people told them so as well. I do not > think we could have done much different at the IETF process when they > decided to forge ahead anyway, despite numerous people telling them > they would never get conensus for what they were seeking, and that > their arguments for "our networks are too big" were seen as mostly a > cost-savings requests, and not strong enough to open up a core internet > end-to-end security protocol. > > On top of that, the IETF wrote RFC 8404 where it documented the problems > that the enterprise administrators are facing. > > > >Those needs were considerated at length, and the outcome was that ther= e > was no secure way of covering your needs with protocol changes. The > > >recommendation was to do this at the implementation level. > > > > Again, I disagree with you. > > You mean you disagree with the TLS WG and/or the IETF Security Area. I > was not talking about my personal opinion here. > > > I have talked to a number of cryptographers and there may be number of > potential ways of doing this without > > violating the > > security guarantees of TLS. But, this is not the time to bring up any > potential new ideas. > > I'm always happy to discuss technical ideas and read drafts. > > > > > >> We need to work together. > > > > >Working together does not mean you are guaranteed your desired outcome= . > > > > Frankly, this feels condescending. Please give me credit for a modicu= m > of intelligence. > > But do you understand that by saying "we need to work together" that you > are implying that "we did not work well together before" ? And that from > an IETF point of view, the IETF worked very well with the enterprise > people and that the outcome of working together was a lack of consensus? > > > The process improvement is not about anything in TLS but about how we g= o > about getting to consensus. > > While I appreciate the efforts of your draft, I am still not convinced > there was any way in which we could have gained consensus unless a new > technological invention we haven't managed to invent in 20 years would > suddenly present itself? So I do question the premise of you writing > this draft now. Whether I think we can improve our consensus forming, > then yes I think we can and I have a very specific personal case regardin= g > a draft in mind. Although I am not sure a document can address some > cultural issues we have within the IETF, it won't hurt to try and > formulate things, so I am happy to continue reading updated drafts > on this. > > > >> I also care deeply about the enterprises and their needs. I know > them, they have been my world for the last 30 years. When an issue gets > > passionate, > > >> people can get tunnel vision and stop listening to others. I hope w= e > can learn to change that. Believe me, I feel that there is plenty > > of blame to go > > >> around on all sides of this issue. But, I hope we can learn from it > to make our process better. > > > > >I disagree with "tunnel vision" and "getting passionate" and "make the > > >process better" with respect to the specific "enterprise TLS" needs.. > You > > >feel this is reaching out to the generic IETF, but to me it appears > > >more as a sign you misunderstood the process and why this outcome was > > >rightfully reached. > > > > Again, we are talking about very different things. > > You keep bringing up the enterprise case as example for bad consensus > forming and now you keep saying you are writing this because of > different things. When you bring up "tunnel vission" and the > "enterprise use case" in one email, it does seem to be related, and > thus in turn that is what upsets me about your emails when it appears > these critisisms of tunnel vission and getting passionate seem aimed > at the part of the TLS WG that spoke out against the enterprise use > case. I will try to feel less personally attacked. but I urge you to > better separate these two topics when talking about either topic. > > > Paul > > _______________________________________________ > 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 > --000000000000345e55057b109061 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The problem is that if what it takes for you to "feel= heard" is that you get your way, then that's not going to work, a= s you can quickly see if you game out how this would go in the scenario you= offered.=C2=A0 =C2=A0So what does it take to "feel heard" and no= t get your way?=C2=A0 =C2=A0This would be something interesting to explore,= but I think the answer is that that was not on the table in this particula= r case=E2=80=94in this case "feeling heard" and "getting you= r way" were synonymous for the particular enterprise folks who tried t= o change the requirements for TLS 1.3.

=
On Mon, Nov 19, 2018 at 9:57 PM Nalini J Elkins <nalini.elkins@insidethestack.= com> wrote:
>> And, truthfully, the way yo= u are phrasing it feels quite disrespectful.=C2=A0 =C2=A0=C2=A0

>= ;=C2=A0And so d= o your repeated statements that the IETF has not listened to the=C2=A0enterprise = people.

It is not my intentio= n to be disrespectful.=C2=A0 =C2=A0What I feel is that both parties feel no= t listened to.

If I can put it in terms of= Jane and Bob.

1.=C2=A0=C2=A0Jane feels t= hat she is listening to Bob.

2.=C2=A0 Bob = feels that he is not being heard by Jane.

=
3.=C2=A0 Bob feels that he is listening to Jane.

4.=C2=A0 Jane feels that she is not being heard by Bob.

I feel that is the situation that we are in.=

BTW, it is not just the TLS group and the enter= prises.=C2=A0 I think that just happens to be the issue that you and I seem= to talk about.=C2=A0 =C2=A0I am sure that you and I will have many differe= nces of opinion in HRPC as well!=C2=A0 I have seen such issues in many WGs = : QUIC, v6ops, 6man, and on and on.
=C2=A0
Thanks,

Nalini Elkins
CEO and F= ounder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360


From: Paul Wouters <paul@nohats.ca>
To: Nalini J Elkins <nalini.elkins@insidethestack.com>
Cc: Hrpc <hrpc@irtf.org>
= Sent: Sunday, November 18, 2018= 9:46 PM
Subject: Re: [h= rpc] "We try to avoid"

On Sun, 18 Nov 2018, Nali= ni J Elkins wrote:

> And, truthfull= y, the way you are phrasing it feels quite disrespectful.=C2=A0 =C2=A0=C2= =A0

And so do your repeated statements= that the IETF has not listened to the
enterprise people.=

> >> A number of enterprises= feel they have their needs in this area.=C2=A0 =C2=A0Their needs will not = go away.=C2=A0 They need to be addressed.
>
> >Since the 80s governments wanted backdoors in crypto. Th= eir need has not
> >gone away. Yet we still believe= not putting that in algorithm design is
> >the rig= ht approach. That is, your undying need in itself is not a
> >justification. Some things just cannot or should not be done.>
> Again, with all due respect, t= his is your opinion rather than an indisputable fact.=C2=A0 I will tell you= that others disagree
> with you.=C2=A0

They should look into how Bill Clinton went from Cli= pper Chip to
dropping crypto export restrictions.

I'm sure some authoritarian or wanna-be-a= uthoritarian regimes disagree
with my opinion on the soci= al aspects of citizen monitoring. I am also
sure some com= panies believe their network should not comply to local
l= aw, but that does not make it more legal to monitor their employees.

I also realise that different laws are posin= g a contradicting
requirement to some enterprises. Howeve= r, that is is not something the
IETF can address.

> >I have read it but I feel that you a= re conflating a failed process with not geting your desired outcome.=C2=A0<= br clear=3D"none">>
> Please do not make assumptio= ns about what I do and don't think.=C2=A0 For example, you don't kn= ow that I actually think that draft-green IS the
> rig= ht solution.=C2=A0 =C2=A0
> What I have always wanted = is for enterprises to have a voice.=C2=A0 And for the IETF to work with the= m.

You are mistaken about my assumptio= ns. My only assumption here is that I
know the enterprise= people's voices were heard, and that you keep
repeat= ing they were not. That is why I say you confuse the process with
the outcome. I have no opinion about your opinion on draft-green.=

>
> >Whil= e I do think IETF at times fails in its process, I do not see how it failed= on draft-green.
>
> The fact th= at many months after the decision, there are so many hard feelings between = so many people that we can hardly talk about this issue
&= gt; without it erupting into chaos would lead me to think that there is pro= bably a better way.=C2=A0 =C2=A0You and I are talking about different thing= s.
> This level of hard feelings is a huge waste of ti= me and energy for many people.=C2=A0 Not to mention the fact that now there= are multiple
> standards
> which= may be in conflict.=C2=A0 If you think this is a successful process and ou= tcome, then I would beg to differ.

US = bank approached me before going public with their requirements. It
turned out they approached many more individuals privately at fir= st.
I told them during that first meeting that what they = wanted was simply
impossible. I am sure many more people = told them so as well. I do not
think we could have done m= uch different at the IETF process when they
decided to fo= rge ahead anyway, despite numerous people telling them
th= ey would never get conensus for what they were seeking, and that
their arguments for "our networks are too big" were see= n as mostly a
cost-savings requests, and not strong enoug= h to open up a core internet
end-to-end security protocol= .

On top of that, the IETF wrote RFC 8= 404 where it documented the problems
that the enterprise = administrators are facing.

> >Th= ose needs were considerated at length, and the outcome was that there was n= o secure way of covering your needs with protocol changes. The
> >recommendation was to do this at the implementation level.>
> Again, I disagree with you.
You mean you disagree with the TLS WG a= nd/or the IETF Security Area. I
was not talking about my = personal opinion here.

> I have tal= ked to a number of cryptographers and there may be number of potential ways= of doing this without
> violating the
> security guarantees of TLS.=C2=A0 But, this is not the time to brin= g up any potential new ideas.

I'm = always happy to discuss technical ideas and read drafts.
=
>
> >> We need to work to= gether.
>
> >Working together= does not mean you are guaranteed your desired outcome.
&= gt;
> Frankly, this feels condescending.=C2=A0 =C2=A0= Please give me credit for a modicum of intelligence.=C2=A0

But do you understand that by saying "we need to = work together" that you
are implying that "we d= id not work well together before" ? And that from
an= IETF point of view, the IETF worked very well with the enterprise
people and that the outcome of working together was a lack of con= sensus?

> The process improvement i= s not about anything in TLS but about how we go about getting to consensus.=

While I appreciate the efforts of you= r draft, I am still not convinced
there was any way in wh= ich we could have gained consensus unless a new
technolog= ical invention we haven't managed to invent in 20 years would
suddenly present itself? So I do question the premise of you writ= ing
this draft now. Whether I think we can improve our co= nsensus forming,
then yes I think we can and I have a ver= y specific personal case regarding
a draft in mind. Altho= ugh I am not sure a document can address some
cultural is= sues we have within the IETF, it won't hurt to try and
formulate things, so I am happy to continue reading updated drafts
on this.

> >> I a= lso care deeply about the enterprises and their needs.=C2=A0 I know them, t= hey have been my world for the last 30 years.=C2=A0 When an issue gets
> passionate,=C2=A0
> >> people= can get tunnel vision and stop listening to others.=C2=A0 I hope we can le= arn to change that.=C2=A0 Believe me, I feel that there is plenty
> of blame to go
> >> around on all= sides of this issue.=C2=A0 But, I hope we can learn from it to make our pr= ocess better.=C2=A0=C2=A0
>
> &g= t;I disagree with "tunnel vision" and "getting passionate&qu= ot; and "make the
> >process better" with= respect to the specific "enterprise TLS" needs.. You
> >feel this is reaching out to the generic IETF, but to me it= appears
> >more as a sign you misunderstood the pr= ocess and why this outcome was
> >rightfully reache= d.
>
> Again, we are talking abo= ut very different things.=C2=A0

You ke= ep bringing up the enterprise case as example for bad consensus
forming and now you keep saying you are writing this because of
different things. When you bring up "tunnel vission"= ; and the
"enterprise use case" in one email, i= t does seem to be related, and
thus in turn that is what = upsets me about your emails when it appears
these critisi= sms of tunnel vission and getting passionate seem aimed
a= t the part of the TLS WG that spoke out against the enterprise use
case. I will try to feel less personally attacked. but I urge you= to
better separate these two topics when talking about e= ither topic.


Paul

____________________________________________= ___
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
--000000000000345e55057b109061-- From nobody Mon Nov 19 22:14:15 2018 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 5565812870E for ; Mon, 19 Nov 2018 22:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, URIBL_BLOCKED=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 s_867EEPk6gd for ; Mon, 19 Nov 2018 22:14:09 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB191277D2 for ; Mon, 19 Nov 2018 22:14:09 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 6062D182CED28 for ; Tue, 20 Nov 2018 06:14:08 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -6, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:41:152:355:379:421:599:800:854:967:973:988:989:1260:1261:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1534:1543:1593:1594:1605:1711:1730:1747:1777:1792:1963:2198:2199:2376:2393:2525:2553:2559:2563:2682:2685:2693:2859:2890:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3808:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4042:4184:4250:4362:4860:5007:6117:6119:6248:7652:7903:8660:9010:9025:9038:10010:10226:10400:10848:10946:11232:11658:11914:12043:12291:12379:12438:12663:12683:12740:12895:13071:13148:13161:13229:13230:13618:13846:13894:14095:14180:14181:14721:21060:21080:21088:21326:21433:21450:21627:21740:21819:30001:30022:30041:30046:30054:30060:30070, 0, RBL:72.221.122.28:@doria.org:.lbl8.mailshell.net-62.14.0.100 64.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules: X-HE-Tag: walk79_4131349eb0c07 X-Filterd-Recvd-Size: 3960 Received: from [192.168.0.16] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf06.hostedemail.com (Postfix) with ESMTPA for ; Tue, 20 Nov 2018 06:14:07 +0000 (UTC) To: hrpc@irtf.org References: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> From: avri@doria.org Message-ID: <2174e149-5a3e-2025-7431-bb943382a583@doria.org> Date: Tue, 20 Nov 2018 01:14:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 181119-2, 11/19/2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 06:14:12 -0000 Hi, A quick reply.  I do not see this draft as having reached consensus in the group and last call is at at the discretion of the co-chairs when they both think the draft is ready and they have the consensus of the group for moving toward publication.  I have not done a consensus call because I do not see consensus as having been reached.  If there is rough consensus in the group that this is a draft is ready for publication then we can move forward.  I do not think we are at that point. Personally, I see the draft as more an analysis and polemic than a research draft at this point. It starts out well with theoretic discussion, a hypothetical position and some outlining of cases, but does not establish a research path and does not suggest any protocol considerations, the goal of the RG.  We are a research group and need for the documents to relate to a research goal. Becoming an RG draft does not mean the next step is publication.  It means that the authors have surrendered their authorship priority and change control to the will of the group.  When I see this document get to the point where the members of the RG feel it is ready for  last call, then, if Mallory and I agree, we can try to aim for last call and publication.  In the meantime I would like to see some discussion of how to do further research on the subject and would like to seem some work on consideration that might be relevant. As for setting up milestones for the work being done, that is a good idea and something that in general we should do.  Thanks for the question. avri On 18-Nov-18 18:18, Gisela Perez de Acha Chavez wrote: > > Hi everyone. First of all, apologies for my silence. I started my master's in Berkeley and the change implied time investment that I had to handle before coming back to the list. > > The reason I'm writing this email is because I am trying to get up to speed regarding the status of association draft, that Niels and I coauthored. > While reading Mallory's notes, and watching the last IETF session, I want to ask why has the draft been taken back to the list and not moved to last call. I thought there was a clear process regarding this. So if I am wrong, please correct me. > > It would be hugely appreciated if we would develop milestones from draft-association (and probably other drafts as well), since as an author it has been quite unclear how to make progress. At several meetings it has been said that the discussion would be taken to the list, but that did not really happen. Does this indeed mean we have reached consensus? Please let me know how we can make progress on this and what the milestones are. > > (Also, sorry for the new thread but I needed to write from this new email account) > > Happy to be back and discuss these issues further, > > Cheers > > Gisela Pérez de Acha > UC Berkeley > Human Rights Lawyer | Journalist | Writer > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc From nobody Mon Nov 19 22:37:11 2018 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 3D6D61277D2 for ; Mon, 19 Nov 2018 22:37:09 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 jFPtk0f8uFr9 for ; Mon, 19 Nov 2018 22:37:06 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FCF128B14 for ; Mon, 19 Nov 2018 22:37:06 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id C69E7181D3368 for ; Tue, 20 Nov 2018 06:37:04 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:41:152:355:379:421:854:966:973:988:989:1260:1261:1277:1311:1313:1314:1345:1381:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:1963:2196:2199:2393:2553:2559:2562:2691:2693:2741:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3872:3874:4184:4250:4362:4385:4641:5007:6117:6119:7652:7901:7903:10004:10400:10848:11658:11914:12663:13018:13019:13071:13161:13229:13618:13894:14180:14877:21060:21063:21080:21324:21433:21627:21740:21771:30054:30056:30070:30090, 0, RBL:72.221.122.28:@doria.org:.lbl8.mailshell.net-62.8.0.100 64.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA_SUMMARY:none X-HE-Tag: twist06_77f9eaf29fe10 X-Filterd-Recvd-Size: 3042 Received: from [192.168.0.16] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf15.hostedemail.com (Postfix) with ESMTPA for ; Tue, 20 Nov 2018 06:37:04 +0000 (UTC) From: avri@doria.org To: hrpc@irtf.org Message-ID: <55154859-31fd-c2c6-d506-40e57acde5dd@doria.org> Date: Tue, 20 Nov 2018 01:36:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 181119-2, 11/19/2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] Concern about the path HRPC is on X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 06:37:09 -0000 Hi, I have been relatively silent during most of the conversations. This was largely because I wanted to see where the discussions went and what emerged that might help in the research goals. At this point I am worried that the group may be losing its way and I do hold myself somewhat responsible for being a bit too hands off in the discussions.  Instead of focusing on research goals, like taking the hypotheses presented in RFC8280 and testing them and measuring results, we are starting to act as if we were an IETF human rights directorate, in the position to tell groups in the IETF what they should and should not be doing about their work.  While individuals are always free to act that way, it is not the job of the HRPC as a research group to do so. I see this as a problem because we are part of the IRTF and not the IETF.  And while we may complete our work at some point and give recommendation to the IETF about establishing Human Rights Protocol Considerations within the IETF, we are not chartered to direct the activities of the IETF WGs in any manner whatsoever.  There is supposed to be a gulf between the IETF and the IRTF.  And while we have made a good start with RFC8280 of a theoretical framework for our work, we have not yet done conclusive work on establishing that there are useful human rights consideration that can be used generally on Internet protocols and architectures.  We may mostly believe it and we  have taken first steps, but are not yet, in my opinion, at the point of having proven the point sufficiently for those who do not approach it with prior belief.  I think we need to find our way back to research goals on both the follow-up to RFC8280 and on the other drafts that have been accepted by the RG as RG docs.  What does it mean to research these issues and what does it take to produce the analysis, evidence and measurements that show the hypothetical work to be worthy of export to the IETF for their ultimate consideration and possible acceptance? Mallory and I, as co-chairs, will be meeting with the Allison Mankin in her role as IRTF chair, to discuss the situation in this group and to start to think about how we get back on track and might take it forward in a research manner.  Thanks avri From nobody Mon Nov 19 22:48:35 2018 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 B34B5128D68 for ; Mon, 19 Nov 2018 22:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 68fdJIJfL3MI for ; Mon, 19 Nov 2018 22:48:30 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F22D1277D2 for ; Mon, 19 Nov 2018 22:48:30 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id DEC2C180644F3 for ; Tue, 20 Nov 2018 06:48:28 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:41:152:355:379:854:960:967:973:988:989:1260:1261:1277:1311:1313:1314:1345:1381:1437:1515:1516:1518:1534:1540:1593:1594:1711:1730:1747:1777:1792:1963:2194:2199:2393:2525:2560:2564:2682:2685:2741:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3352:3865:3866:3867:3868:3870:3871:3872:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4184:4362:5007:7652:8957:9025:9707:10004:10400:10848:10903:11026:11658:11914:12043:12438:12903:13069:13071:13311:13357:13845:13894:14180:14181:14721:14777:21060:21063:21080:21347:21433:21451:21611:21627:21740:21851:30054, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:29, LUA_SUMMARY:none X-HE-Tag: crook50_49f958e48661c X-Filterd-Recvd-Size: 1588 Received: from [192.168.0.16] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf09.hostedemail.com (Postfix) with ESMTPA for ; Tue, 20 Nov 2018 06:48:28 +0000 (UTC) To: hrpc@irtf.org From: avri@doria.org Message-ID: <5365d9e9-8e90-c556-296d-4aa0cae83074@doria.org> Date: Tue, 20 Nov 2018 01:48:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Antivirus: Avast (VPS 181119-2, 11/19/2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] An interesting article analyzing our work and goals, X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 06:48:33 -0000 Hi, A while back, I think it was in Singapore, Milton Mueller presented a dract of his paper to the the group.  they have now published the paper: https://rdcu.be/bbwrN aka _Requiem for a Dream: On Advancing Human Rights via Internet Architecture._ While I do not agree with all of what it says, I do think it is a worthwhile analysis for this group to read, think about and perhaps discuss.  This article is done from a social science perspective and is something we should be able to respond to from an equivalent perspective, especially if we want our work to have scientific adequacy. Thanks avri From nobody Mon Nov 19 22:55:29 2018 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 805D212870E for ; Mon, 19 Nov 2018 22:55:27 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 NXD89C_wIc1P for ; Mon, 19 Nov 2018 22:55:25 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 DEDF31277D2 for ; Mon, 19 Nov 2018 22:55:25 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id t13so461417pgr.11 for ; Mon, 19 Nov 2018 22:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/rYPIiAz1oyMJVmAJ+2fXiF8abGIZrJNNkW3ku9yIiQ=; b=TWJyK2o4iuSjLKWW6OuxzaMbmfNUJRnK/qXLCZ8mSjd7wjv1dyZkgkX7OP0IS/8jOz VhTEFTky4K2ylb6ergz/VqI/cdHIV8kWW5AVCizD2ZyOMAgDw+hugvrmHUD/ZiU5S4C4 VYQm0TbJN1pEQ3rhtoPNCbCLPgCzfgof6t6BfeaZNI0PfWBQlpEXaQRtWUuPxbyfYOFU 5uKVojzFCb3G4fMxk8J5FW81l+GFmCecWyhkjrXB7BMxxbJQbBmNVHtgd5z/zA2/IU87 gxhb0vo6EcFeUOakOjWRtICPEJl+Rin7ll1c7Hq5FhFbAbYysbQOYwod+Fzm+brCya2h DncA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/rYPIiAz1oyMJVmAJ+2fXiF8abGIZrJNNkW3ku9yIiQ=; b=qSTRxNAvqFLSAZQrSWR/EYBBv91QBCV6H/YHNHDezGymrGqaJe0r7c1CmUFUewBvA3 iu2zQQ5okJUeSZHpPywQpka3tiM+HQ1LPLeWzBl2uUz+/aFgLfC4rUFFfMaBbSy4TJLx 4/0aykcoaAoXmL3p9QHNDMqZRam0U5SxvpKhvSJFnKn73IPrVzfoSv1EiklYkB4o/+P9 ZNgVpOrdbMwiowWdPOqTTs8PcUcWzKMvEAzAL9mq1/y6TsICl5Ot9iioyS0DAtg6BASj up4cYdMMNMZ3XH4IeY/DUyo9g+UwpzLE+i9lONpLcAYOwAKc4xujd9rlRVyxy0wXC6+3 5pFw== X-Gm-Message-State: AA+aEWbRLtrUPQF09aZh3Wwp/XqrvQnK0dokX6mzi4pQM+dBeyYK30ES uUnTpiL2FV+9KVVkjMrLXPYM/oh7dA== X-Google-Smtp-Source: AFSGD/VgAYpuHhe1JAdIjbBanCRjszWhpWUJJozB2piC7ZUcpxOqX2fRK3ObdwO2H6vrx4qZFOE0Ew== X-Received: by 2002:a63:b218:: with SMTP id x24mr800992pge.223.1542696924953; Mon, 19 Nov 2018 22:55:24 -0800 (PST) Received: from aspen.local (216-67-35-146-radius.dynamic.acsalaska.net. [216.67.35.146]) by smtp.gmail.com with ESMTPSA id d202sm44569081pfd.58.2018.11.19.22.55.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Nov 2018 22:55:24 -0800 (PST) To: hrpc@irtf.org References: <55154859-31fd-c2c6-d506-40e57acde5dd@doria.org> From: Melinda Shore Message-ID: <270da488-b3b1-2b4e-f973-db6d05be4ebb@nomountain.net> Date: Mon, 19 Nov 2018 21:55:21 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <55154859-31fd-c2c6-d506-40e57acde5dd@doria.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hrpc] Concern about the path HRPC is on X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 06:55:27 -0000 On 11/19/18 9:36 PM, avri@doria.org wrote: > I have been relatively silent during most of the conversations. This was > largely because I wanted to see where the discussions went and what > emerged that might help in the research goals. Hi, and thanks for this. For the little (very little, I suspect) it's worth it seems to me that it's increasingly common for research groups to wander into engineering space. I'm not sure I want to get into a discussion of why that's happening but my general sense is that it's pulled, or threatened to pull, a few RGs off the rails. That is to say, while this may be the most visible instance of the problem it's certainly not alone. I think the human rights protocols reviews have been useful but I've also wondered if they haven't blurred a few lines (plus consumed calories that might have been spent elsewhere). Melinda -- Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis From nobody Mon Nov 19 23:36:38 2018 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 30773130DEE for ; Mon, 19 Nov 2018 23:36:33 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 w0nBrtUtpt6X for ; Mon, 19 Nov 2018 23:36:30 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 2CC3112870E for ; Mon, 19 Nov 2018 23:36:29 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gP0aA-0004Nf-TU for hrpc@irtf.org; Tue, 20 Nov 2018 08:36:27 +0100 To: hrpc@irtf.org References: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> <2174e149-5a3e-2025-7431-bb943382a583@doria.org> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= xsFNBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABzShOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+wsGZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI87BTQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAcLBZQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> Date: Tue, 20 Nov 2018 08:36:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <2174e149-5a3e-2025-7431-bb943382a583@doria.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 67ca9281b58cf5c8a5b2b1d981559170 Archived-At: Subject: Re: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 07:36:37 -0000 On 11/20/18 7:14 AM, avri@doria.org wrote: > Hi, > > A quick reply.  > > I do not see this draft as having reached consensus in the group and > last call is at at the discretion of the co-chairs when they both think > the draft is ready and they have the consensus of the group for moving > toward publication.  I have not done a consensus call because I do not > see consensus as having been reached.  If there is rough consensus in > the group that this is a draft is ready for publication then we can move > forward.  I do not think we are at that point. > > Personally, I see the draft as more an analysis and polemic than a > research draft at this point. It starts out well with theoretic > discussion, a hypothetical position and some outlining of cases, but > does not establish a research path and does not suggest any protocol > considerations, the goal of the RG.  We are a research group and need > for the documents to relate to a research goal. > Thanks a lot for your feedback. As presented during IETF 102 [0] and 103 [1], providing guidelines is a non-objective for this draft. The objective of this draft is the operationalization of the first objective of the charter ('To expose the relation between protocols and human rights, with a focus on the rights to freedom of expression and freedom of assembly'), not to provide guidelines. As discussed the practice of improving the guidelines is pursued in RFC8280, draft-irtf-hrpc-guidelines and through the human rights reviews. So the research goals of this draft is defined by the first objective of the charter. I am not sure what you mean with a research path. I don't think you mean research design, since there are clear research questions, a methodology, case studies, a discussions of the case studies, the provision of conclusions, and suggestions for further research. So if you could tell us a bit more about what you mean with 'establishing a research path', we'll get on it right away! Best, Niels [0] https://datatracker.ietf.org/meeting/102/materials/slides-102-hrpc-slides-association-final-00 slide 4 [1] https://datatracker.ietf.org/meeting/103/materials/slides-103-hrpc-draft-irtf-hrpc-association-00 slide 2 > Becoming an RG draft does not mean the next step is publication.  It > means that the authors have surrendered their authorship priority and > change control to the will of the group.  When I see this document get > to the point where the members of the RG feel it is ready for  last > call, then, if Mallory and I agree, we can try to aim for last call and > publication.  In the meantime I would like to see some discussion of how > to do further research on the subject and would like to seem some work > on consideration that might be relevant. > > As for setting up milestones for the work being done, that is a good > idea and something that in general we should do.  > > Thanks for the question. > > avri > > On 18-Nov-18 18:18, Gisela Perez de Acha Chavez wrote: >> >> Hi everyone. First of all, apologies for my silence. I started my master's in Berkeley and the change implied time investment that I had to handle before coming back to the list. >> >> The reason I'm writing this email is because I am trying to get up to speed regarding the status of association draft, that Niels and I coauthored. >> While reading Mallory's notes, and watching the last IETF session, I want to ask why has the draft been taken back to the list and not moved to last call. I thought there was a clear process regarding this. So if I am wrong, please correct me. >> >> It would be hugely appreciated if we would develop milestones from draft-association (and probably other drafts as well), since as an author it has been quite unclear how to make progress. At several meetings it has been said that the discussion would be taken to the list, but that did not really happen. Does this indeed mean we have reached consensus? Please let me know how we can make progress on this and what the milestones are. >> >> (Also, sorry for the new thread but I needed to write from this new email account) >> >> Happy to be back and discuss these issues further, >> >> Cheers >> >> Gisela Pérez de Acha >> UC Berkeley >> Human Rights Lawyer | Journalist | Writer >> >> >> _______________________________________________ >> 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 > -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Tue Nov 20 00:33:41 2018 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 F022012D4EB for ; Tue, 20 Nov 2018 00:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 sqyo4wFsUvcQ for ; Tue, 20 Nov 2018 00:33:37 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB19A12D4EC for ; Tue, 20 Nov 2018 00:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1767; q=dns/txt; s=iport; t=1542702816; x=1543912416; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2v693ppk4C5PwGj5hnoGhJC6RbEgIuryS5ta3xGeULg=; b=I80yYHJhWGq9Co35ydHYffm6Gm2ke8/TOVSIpG+YyQUgUdEQO+qNLTaI hOH4PsSxMyLfqxJyViyeB31Cm0zTp5URYUPSv1eg+Akczzj9StuMED94s dnFKLcTQW+HVGEBlJrP36ShUwDCbn4dPJ2vCCmH67EtErAzgKwyYoIJwT Q=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAABhxfNb/5NdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGCA4FoMYNulBaCDZc3gXoIAwEBhGwCg3YiNgc?= =?us-ascii?q?NAQMBAQIBAQJtHQuFPQEEASNWBQsCAQhCAgIyJQIEDhODEwGBeQinR4EvhUC?= =?us-ascii?q?EVg+CbYkJDxeBQD+BEScfgh4uiAIxgiYCj1KFWYpECQKEHYF0ixYYkQCXdgI?= =?us-ascii?q?RFIEnJQExgVVwFWUBgkKQWUGNOIEfAQE?= X-IronPort-AV: E=Sophos;i="5.56,256,1539648000"; d="asc'?scan'208";a="485451009" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2018 08:33:35 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wAK8XZgP011881 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Nov 2018 08:33:35 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 20 Nov 2018 02:33:35 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1395.000; Tue, 20 Nov 2018 02:33:35 -0600 From: "Eliot Lear (elear)" To: "avri@doria.org" CC: "hrpc@irtf.org" Thread-Topic: [hrpc] Concern about the path HRPC is on Thread-Index: AQHUgJt8m6AyfHYBI06LjDuRev/g5KVYutEA Date: Tue, 20 Nov 2018 08:33:34 +0000 Message-ID: <1D948CE6-2E8C-4DCB-AA8E-C14CED29DA97@cisco.com> References: <55154859-31fd-c2c6-d506-40e57acde5dd@doria.org> In-Reply-To: <55154859-31fd-c2c6-d506-40e57acde5dd@doria.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.223.202] Content-Type: multipart/signed; boundary="Apple-Mail=_3FFB6D88-4301-45A2-81C3-C36C22BE2AD0"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [hrpc] Concern about the path HRPC is on X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 08:33:39 -0000 --Apple-Mail=_3FFB6D88-4301-45A2-81C3-C36C22BE2AD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Avri. The questions you asked below: > What does it mean to research these issues and what > does it take to produce the analysis, evidence and measurements that > show the hypothetical work to be worthy of export to the IETF for = their > ultimate consideration and possible acceptance? are really good ones. And it seems to me the paper reference you posted = is a great way to start that discussion (its intent, after all). As an = engineer, I tend to gravitate toward engineering conversations. It=E2=80=99= s my comfort zone. I think this is true with others as well. I would = really like to be more of a spectator, and the direction you are taking = gives me confidence that I can be (he says, noting the irony of having = emailed this note in the first place). Eliot --Apple-Mail=_3FFB6D88-4301-45A2-81C3-C36C22BE2AD0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlvzxt4ACgkQh7ZrRtnS ejOFnwgAwC9X/0SBxbedD+B6GUQLGKmswDBE4qDhl85es4wP/G2M5BduHPYfVT2E 4CjSfI73jREwVCAHzPF5bi4z25VaOyK7LPvB2aZgw1jnFASkS543HkAzAT90u0bv 0jk+KJRguLYXIH31rAyMveUsnpjOPt3GLkt4voaUH21gu8DSpbHSQwoZjDWyO92c 6HJSkqjlquPTQM/nWMN2WqVwISTzz4QL9anxiaj5u5zStnLxVxeMLqotak82iG7E yVXb6JaKG+LS+aluLaODspVFaHHzpu3jW+w+2dgltix2Dkx3oz3NSINaiTaQ95uK FtB5jLDpFXlpIfsQf2G3w3ibvz4dzQ== =rnuY -----END PGP SIGNATURE----- --Apple-Mail=_3FFB6D88-4301-45A2-81C3-C36C22BE2AD0-- From nobody Tue Nov 20 03:58:45 2018 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 2B2CF130DFE for ; Tue, 20 Nov 2018 03:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=yzn2sgt1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=au7HjpYS 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 duiKqGlwB30K for ; Tue, 20 Nov 2018 03:58:27 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9E4130DFA for ; Tue, 20 Nov 2018 03:58:27 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.227.86.189]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id wAKBwDox006373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2018 03:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1542715105; x=1542801505; bh=UZ++GT7kglUxEPF32zWl1+7XyYuqWhFyHtlK8BrMy5o=; h=Date:To:From:Subject; b=yzn2sgt1yvLB4R4IpCZF5gGnJC0PsQaP7wJhSKwILGv/3I69O+2yEb8ua8jndtCzO SiJ0GZAhWL3xLV5AxiPAbiKD9rVepJp6r41ioy3oSRgEwNWm958Og4U6MAb8AORlpv ZdRwGnWPRnI6PEBCL3qQT2yCzhR9HDa4gEatQjnc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1542715105; x=1542801505; i=@elandsys.com; bh=UZ++GT7kglUxEPF32zWl1+7XyYuqWhFyHtlK8BrMy5o=; h=Date:To:From:Subject; b=au7HjpYSQc3X8CUyQeJsJ+gWglcEd1jLPcl/Y4guWbIsBkHQ2wzrYcFQc6bDK0Ylf 8/57Lx8MuT1d1s5pFQeBxc2UkZLw4QSmrtNvCWM2/sVvhDa+HUlNJCOlQZUs8CjS3D S2jhvHIB50AV6oe2cs/r6J7ROSQzzNf3EFGcIWYs= Message-Id: <6.2.5.6.2.20181120034642.0b8c0470@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Nov 2018 03:58:03 -0800 To: Nalini J Elkins , hrpc@irtf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 11:58:29 -0000 Hi Nalini, In the message [1] about "TLS for the enterprise" you mentioned that a member(s) of the IAB or the IESG advised that the work could be done in another standards body. Could you please provide some information about that? Regards, S. Moonesamy 1. https://www.ietf.org/mail-archive/web/hrpc/current/msg02123.html From nobody Tue Nov 20 06:47:33 2018 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 09398126BED for ; Tue, 20 Nov 2018 06:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rgbh16EHCSB for ; Tue, 20 Nov 2018 06:47:29 -0800 (PST) Received: from sonic313-16.consmr.mail.ne1.yahoo.com (sonic313-16.consmr.mail.ne1.yahoo.com [66.163.185.39]) (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 A39DE1274D0 for ; Tue, 20 Nov 2018 06:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1542725247; bh=8H4cRUO0xTrJfAYg5e0TmhVIFUcVAXIODaTtlUyPbp4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=XAvZhPW13VRGIBP5iv+AwqMoynImimfGeYbrked6bM1eeElm1ZX7hkjJvigeNYwUaQyXoaO4cuqZjTT/OjE/4SXY/dftLQgq70Mic3sVTg2Gtonpjc194v7eEB3hLgy5J52myR2acyLFiPcAJT7kUdOyXDib0W2N1frQPcXBgGXFNU4Fam9Cklyzymnj1g0tBtTHBkC4zFBnQcinlJ3q7g5rv6A01URDS0bgcwVCrdWTyjQMOQDWgPHEuz7Q2vTKmtaT4+RLzyPg6TceXerYzM05IbJuzzhKoUN9RfrjxwBXDf/Xgjnb4OnQH9849muz7pw6XJjCOqGweuEgmxZvHQ== X-YMail-OSG: oB47IpQVM1kWRqhoLWOX8oFu8v7irBtkrpm4Bh.VYMj0k6UYIvQohIqMPc_8dLP z5LE5GdVkFMSYyS8lXdW78.HIkNHtu_4PO7IRqcucbQM9XE2vphEiYuhhSgKR_T5qZZAvy_El02g 1hsmJz7UIJmiijbLxrXY_toR4_2YdjgIgHs0Q52jZN2Y9VomuzAeQ0FwaDsO0jttUeFSFUbSXuVs z0maeQMqqasQeN1HQayP2SdPfHSAEmu0glsRo3meDUbI8MWZG3ZPSSq18yJXiB1ttr_Xk9S5FZFg bl29IiOjv3XK_FetozHE5xJ73mkTDVURDhuIU8w_4c_BkftnJlXiTtZMps13qqWr9PVLy6Le49j8 NAt0J57_CsvPajRdh_M7vpRmmpqeMdKlmwpVRDIFAc11SHXn5CPvVG3fuux1zZ0Kawk4pTCRYEqn KvDVwRdJmgXJdsBexIgTtkvTUyduMj2F_PeK2N8yi7IvoHkT5V4Q118D.OVI7tY6t7.soTYLn0Lr hLF6kfNLeZ5TgsomppRSPdW1qp_FWx8gXjP1S_WfmR1TwwmZMcNLtdD7ObllkBQJecuKM61QXUIl BhlNOdB8JxaNSfMzz3rZznnr5kTXlHFWtsiB20N8wo0VQNJXJnId3RJ.8qxiAPK9bEWlY2xzjMZ. 5s0T_3fjJtEJfc0l1DHgleveemCuUnb6tXB2fonfwHxP3WUFEj5D_QjihtqwbdK8fM2qQwiAdQal rfRILQ8.rO5Bb5Akvxj6cvWUVHberEztx9Dl._tYLfxDdF_oJSU5JYnvZcaG7Cn_6C1Oj4yxHU1C aU80xjHAKWXn34JHrMSCAiY5FLG4zvprAqRe3fiQMuyfSco3EBLJs3zbyljBb.Ufe34Av_jndiPa xEcToAdLn7fIhLtdJX3g2wsBa_gKwuRYy6aLV2vkTew1jNRFPt26eoPzKIHXopMXdEhHIlLQkEDN hQMI5sg1.qx1UA5q4lI9FF7JpTBrG9dqNhk2UpymgoDOCK1waH4iE3T08ybqYspiGYoBMTXUIx2u qjw9CzqC.e4csJE9zg1gUyplV6Y.amoQx1ZSohw9ktTCmhwmgBgnppGTIsAYzHAqERlfZ Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Tue, 20 Nov 2018 14:47:27 +0000 Date: Tue, 20 Nov 2018 14:47:25 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: S Moonesamy , "hrpc@irtf.org" Message-ID: <1359275169.232600.1542725245033@mail.yahoo.com> In-Reply-To: <6.2.5.6.2.20181120034642.0b8c0470@elandnews.com> References: <6.2.5.6.2.20181120034642.0b8c0470@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_232599_354720765.1542725245031" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] "We try to avoid" X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 14:47:32 -0000 ------=_Part_232599_354720765.1542725245031 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >In the message [1] about "TLS for the enterprise" you mentioned that=C2=A0 >a member(s) of the IAB or the IESG advised that the work could be=C2=A0 >done in another standards body.=C2=A0 Could you please provide some=C2=A0 >information about that? I have talked to the enterprise involved and they will be posting to the li= st themselves.=C2=A0=C2=A0 Best to have this first-hand.=C2=A0=C2=A0=C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: S Moonesamy To: Nalini J Elkins ; hrpc@irtf.org=20 Sent: Tuesday, November 20, 2018 3:58 AM Subject: Re: [hrpc] "We try to avoid" =20 Hi Nalini, In the message [1] about "TLS for the enterprise" you mentioned that=20 a member(s) of the IAB or the IESG advised that the work could be=20 done in another standards body.=C2=A0 Could you please provide some=20 information about that? Regards, S. Moonesamy 1. https://www.ietf.org/mail-archive/web/hrpc/current/msg02123.html =20 ------=_Part_232599_354720765.1542725245031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>= In the message [1] about "TLS for the enterprise" you mentioned that <= br id=3D"yui_3_16_0_ym19_1_1542723797502_43503">
>a member(s) of the IAB or the IES= G advised that the work could be 
>done in another standards body.  Could you please provide some&n= bsp;
>information about that?

I have talked to the = enterprise involved and they will be posting to the list themselves. &= nbsp;

<= /div>
Best to hav= e this first-hand.  
 
Thanks,

Nalini Elkins
CEO and Founde= r
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
=

From: S Moonesamy <sm+ietf@elan= dsys.com>
To: Nalin= i J Elkins <nalini.elkins@insidethestack.com>; hrpc@irtf.org
= Sent: Tuesday, November 20, 2= 018 3:58 AM
Subject: R= e: [hrpc] "We try to avoid"

Hi Nalini,

In= the message [1] about "TLS for the enterprise" you mentioned that
a member(s) of the IAB or the IESG advised that the work= could be
done in another standards body.  = Could you please provide some
information about = that?

------=_Part_232599_354720765.1542725245031-- From nobody Tue Nov 20 20:06:07 2018 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 75CF2130E79 for ; Tue, 20 Nov 2018 20:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 MrL5aY8SF2ld for ; Tue, 20 Nov 2018 20:06:04 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) (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 579DD130DE4 for ; Tue, 20 Nov 2018 20:06:04 -0800 (PST) Received: from pcls8.std.com (pcls8.std.com [192.74.137.148]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id wAL45eDh004702; Tue, 20 Nov 2018 23:05:43 -0500 Received: from pcls8 (localhost [127.0.0.1]) by pcls8.std.com (8.14.5/8.14.5) with ESMTP id wAL3TGfr018939; Tue, 20 Nov 2018 22:29:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23540.53516.854815.145596@gargle.gargle.HOWL> Date: Tue, 20 Nov 2018 22:29:16 -0500 From: bzs@theworld.com To: Niels ten Oever Cc: hrpc@irtf.org In-Reply-To: <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> References: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> <2174e149-5a3e-2025-7431-bb943382a583@doria.org> <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-suse-linux-gnu) Archived-At: Subject: Re: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 04:06:06 -0000 What I don't think anyone has talked about vis a vis process is process. Specifically should there be a process within the IETF to report, complain, argue, and adjudicate a human rights violation which has been allegedly caused or abetted by a protocol or other standard? Creating a process like that might be of a lot more practical use than trying to enumerate and agree on possible indiscretions. And help future design considerations. That still assumes some sort of critical framework within which to judge the legitimacy of such a claim but agreeing this should exist would seem to be progress of a sort. Otherwise all we have are violations by proxy. That is, parties who aren't the harmed or affected parties imagining a harmed party exists and how they were harmed. In legalese that would "lack standing". The other issue it would lead to is "remedy" but in this case the remedy seems straightforward enough: Amend the protocol &c to mitigate the harm, or abandon it as a standard entirely, or conclude the benefits outweigh the harm so no mitigation, etc. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nobody Tue Nov 20 22:59:02 2018 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 79DBE130EDF for ; Tue, 20 Nov 2018 22:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHu8sePp8tuT for ; Tue, 20 Nov 2018 22:58:57 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 28BEB128766 for ; Tue, 20 Nov 2018 22:58:55 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gPMTM-0007fQ-65 for hrpc@irtf.org; Wed, 21 Nov 2018 07:58:52 +0100 To: hrpc@irtf.org References: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> <2174e149-5a3e-2025-7431-bb943382a583@doria.org> <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> <23540.53516.854815.145596@gargle.gargle.HOWL> From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: <6f930dde-db44-f8c1-cbb8-2d4a9f8293c2@article19.org> Date: Wed, 21 Nov 2018 09:58:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <23540.53516.854815.145596@gargle.gargle.HOWL> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: c09395f469c52153b963e4ff2d10f427 Archived-At: Subject: Re: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 06:59:02 -0000 Hi, On 21/11/2018 06:29, bzs@theworld.com wrote: > Specifically should there be a process within the IETF to report, > complain, argue, and adjudicate a human rights violation which has > been allegedly caused or abetted by a protocol or other standard? >=20 > Creating a process like that might be of a lot more practical use than > trying to enumerate and agree on possible indiscretions. And help > future design considerations. >=20 > That still assumes some sort of critical framework within which to > judge the legitimacy of such a claim but agreeing this should exist > would seem to be progress of a sort. >=20 > Otherwise all we have are violations by proxy. I think this is a really good suggestion. I suspect that this exercise would lead us in two directions: 1) A few really big violations happening at the application and content layer, which we could make a tenuous case for being related to some low-layer protocols. 2) Many, many trivial cases that indicate a massive flaw at the protocol level. I'm thinking about how SMTP works and while you won't find quality in the narrative of those violations, you will find quantity. > That is, parties who aren't the harmed or affected parties imagining a > harmed party exists and how they were harmed. In legalese that would > "lack standing". >=20 > The other issue it would lead to is "remedy" but in this case the > remedy seems straightforward enough: Amend the protocol &c to mitigate > the harm, or abandon it as a standard entirely, or conclude the > benefits outweigh the harm so no mitigation, etc. So while I agree that this research would be interesting for the group to do, I am not sure that it would or should spark protocol adjustments. I think it's more likely that we could use these cases to intervene in existing standardisation discussions, but probably we would not be effective at sparking them. Happy to be wrong. -Mallory --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Sun Nov 25 19:23:19 2018 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 499CD1292F1 for ; Sun, 25 Nov 2018 19:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 oW5MfryZOqSW for ; Sun, 25 Nov 2018 19:23:16 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 419F8130EF2 for ; Sun, 25 Nov 2018 19:23:16 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id 80so5472736pge.4 for ; Sun, 25 Nov 2018 19:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IvI8g2xGxWFlZunc26+QLfgulYXKtj9T/0X7B0QE+E0=; b=vXQIrx2L50jdfIb9dl+TYb/FJTaVacspaqfZieKhY3YTffSzbehwqkNQZU8uBPooy0 vsQb6JN1HxC88sl5vGimSvyfaBbPNIY9/C6RBuwXIXw5Y14KUJJt6+QL5X5HPyjLsjSn 9Rb1XHr1o+ekET3hK5nydHGT3/0Vu9TrXhdNLe1zckdj9hiuyVJXPpyNBOCxsm5B2Gzl r+uNRUc1COXinY+fVqZYG2a4kRPIhixoNeXxSl90OEUYr8MjtScarUQ4iZWWT/4+Z4ya 9gsayb0OcdYQb1hzAyaoaw2Afrqn4jfvLGgO8AhqIw/M5K/JVqrPy+zMtGYs0K+A+R3y hQSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IvI8g2xGxWFlZunc26+QLfgulYXKtj9T/0X7B0QE+E0=; b=YXbbNSsEueLrgMfoiSE1kRRBe5OIGkYC8VK3Np4823/LQtn4Pk0GX7FLwMhXTUBGpv l5g71vZzzKfVfDbS741r7YTLGmlWXksMGjr3Yt8rkrzMgf0MqFUwHliwdJYMet76E7kX KZJWUB2tCPkEVH1ISa5pno29krb36/at8VFYhtiN1LsZ/GgrOhmak87XeHNt+8LMg/5n jb99dwVOZbp/kXKalINwAQy5fnApUXBmirr7vf7ckkZ/YpwMaGxtLLLyKllM3F6H54ra SALkKy5br4yVTsJ8FJPwMXs7TrDe+wMoXi/GC/XCXzvB/qU/5qTHK0sSj9Mg7qY+ft0B gt4Q== X-Gm-Message-State: AGRZ1gLrlN93xl4pVPRMqcrCSDnYc4L92S/tgh1o39AR+6jz+Piy8JzN QvZT/kM3+9iq3VjsuObFcuDpwVoLfFJ8WpvPH8dwug== X-Google-Smtp-Source: AJdET5d63qyOI5nivnxFuyPsWupHEH4+KqKm6HCWCz8L5AWdgP4J5bq51fu1KHKx7FTFOGJEnq2rUw0OkoOqF1wMuaQ= X-Received: by 2002:a62:8893:: with SMTP id l141mr25656201pfd.1.1543202595444; Sun, 25 Nov 2018 19:23:15 -0800 (PST) MIME-Version: 1.0 From: Darin Pettis Date: Sun, 25 Nov 2018 21:23:04 -0600 Message-ID: To: "hrpc@irtf.org" Content-Type: multipart/alternative; boundary="000000000000849dce057b88da5f" Archived-At: Subject: [hrpc] Clarification X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 03:23:17 -0000 --000000000000849dce057b88da5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, It was mentioned that there was a question around why some folks worked with ETSI to maintain internal visibility with TLS 1.3 traffic so wanted to clear that up. 1. No one =E2=80=9Cdirected=E2=80=9D anyone to go to ETSI. 2. ETSI found draft green on their own and initiated their own effort to standardize it. Didn=E2=80=99t mean to interupt to rehash TLS but wanted to clear up any co= nfusion. Cheers, Darin --000000000000849dce057b88da5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
It was mentioned that there= was a question around why some folks worked with ETSI to maintain internal= visibility with TLS 1.3 traffic so wanted to clear that up.

1.=C2=A0 No one =E2=80=9Cdirected=E2= =80=9D anyone to go to ETSI. =C2=A0

2.=C2=A0 ETSI found draft green on their own and initiated thei= r own effort to standardize it.

Didn=E2=80=99t mean to interupt to rehash TLS but wanted to clear= up any confusion.

Cheer= s,
Darin
--000000000000849dce057b88da5f-- From nobody Sun Nov 25 19:51:39 2018 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 B10E2130E8C for ; Sun, 25 Nov 2018 19:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Asoym21hYtHh for ; Sun, 25 Nov 2018 19:51:35 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 90BA51292F1 for ; Sun, 25 Nov 2018 19:51:35 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id v11so16116901qtc.2 for ; Sun, 25 Nov 2018 19:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XWOf3g2rvhr0QnMzzumLXUixwRbuXdxG+AcyNHKtOvI=; b=uoMCntaecC3i3Q9q0RNO2uAKseUIF/rYgWwHl9NQ8sUFrJzplB+YiEh5048qstroHa 9LrqWAJbEjzXstcslTY06Y9tE6uzzGC7IDHWQkRVxjluO0Gtr4WTJCc9jAsS3wklc+rR 9vkFKPToSi+cnMIL5vQLYdw+hAScb/4GzJOaOV8q0GclW2MXsCDDN/9seRi2fXlUbcfW /cgwx8BV4dgLgTQqp1M2EIrSq5ee3/cLQRVFr0s2JqipFz7V/92sbTAZAgfSbqELbM2f CqDPKkPtsXSLiBBkxhBWUd6L2TcO8CpNRt40sj4pxEcJ+wskR804y0M1kzOme8//gHIV N9Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XWOf3g2rvhr0QnMzzumLXUixwRbuXdxG+AcyNHKtOvI=; b=LBJNvyPvMw8e9K20htwhglSpvhf7CKVaStf5Tt02MwLkmfnm86P2xvdfMpJLBjbGEs XAQwbTR/CEyhSANhUPfpt6WjL+ruNFZ1n+osT0/50TU9utafoLPALlxcpEmagiqCYyYB 1RC3/8vmrUSnZBJVE/YSBPkvPRrwW4d9lFea2ln/25siCHiWIl6bSIu5mxwBH/8/31Pw +jy1lSHzKnJSnO+GqYxVC1Q6uxJ3l2FxAL346ukZavwHWET+OF9zFXHDk7hvgSEvHyhw +dCVLBzLNZva0Y1OMvC906AO/+NMLq42Dwg/4amKNIxS2ThP4O9hbe9t8DRzNSs4AoMp 3I9A== X-Gm-Message-State: AGRZ1gLZzHCgv8hdP+sPOpLqikN5+EFqJAz+eN3jwSHF/FDYdUKwO7EL yKAR803tT5THFKGv6XkK0a1jZ59fKm/y6r6JrQADDw== X-Google-Smtp-Source: AJdET5d/EOY2hW+7a4PGuW5gbwpp3bDeMw/++9ilfXC9rZXLQCy/ebueqEKATDvFj+uGyO3hkT+1wNXFjkmVXXH7HCY= X-Received: by 2002:ac8:18fa:: with SMTP id o55mr24726758qtk.256.1543204294651; Sun, 25 Nov 2018 19:51:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Sun, 25 Nov 2018 22:50:58 -0500 Message-ID: To: dpp.standards@gmail.com Cc: Hrpc Content-Type: multipart/alternative; boundary="000000000000cc8788057b893fff" Archived-At: Subject: Re: [hrpc] Clarification X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 03:51:38 -0000 --000000000000cc8788057b893fff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "ETSI" found? What does that even mean? Somebody who is a participant in ETSI found it. Why did they standardize it? Just for fun? No. There's a reason why they standardized it. On Sun, Nov 25, 2018 at 10:23 PM Darin Pettis wrote: > Hello, > It was mentioned that there was a question around why some folks worked > with ETSI to maintain internal visibility with TLS 1.3 traffic so wanted = to > clear that up. > > 1. No one =E2=80=9Cdirected=E2=80=9D anyone to go to ETSI. > > 2. ETSI found draft green on their own and initiated their own effort to > standardize it. > > Didn=E2=80=99t mean to interupt to rehash TLS but wanted to clear up any = confusion. > > Cheers, > Darin > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000cc8788057b893fff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"ETSI" found?=C2=A0 =C2=A0What does that even me= an?=C2=A0 =C2=A0Somebody who is a participant in ETSI found it.=C2=A0 =C2= =A0Why did they standardize it?=C2=A0 =C2=A0Just for fun?=C2=A0 =C2=A0No.= =C2=A0 =C2=A0There's a reason why they standardized it.

On Sun, Nov 25, 2018 at 10:23 PM Dari= n Pettis <dpp.standards@gmail= .com> wrote:
Hello,
It was mentioned that there was a question= around why some folks worked with ETSI to maintain internal visibility wit= h TLS 1.3 traffic so wanted to clear that up.

1.=C2=A0 No one =E2=80=9Cdirected=E2=80=9D anyone to = go to ETSI. =C2=A0

2.=C2= =A0 ETSI found draft green on their own and initiated their own effort to s= tandardize it.

Didn=E2= =80=99t mean to interupt to rehash TLS but wanted to clear up any confusion= .

Cheers,
Darin
_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000cc8788057b893fff-- From nobody Sun Nov 25 20:36:16 2018 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 EBF2E130F02 for ; Sun, 25 Nov 2018 20:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKWGpJwuapXH for ; Sun, 25 Nov 2018 20:36:13 -0800 (PST) Received: from sonic313-18.consmr.mail.ne1.yahoo.com (sonic313-18.consmr.mail.ne1.yahoo.com [66.163.185.41]) (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 B967E128BCC for ; Sun, 25 Nov 2018 20:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1543206972; bh=ZkIj+c8CGFUTaAIJnOlW8b+66DDZ+kyp38gskZ3P0uk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=NoXUGWZzwafsnNHmmvPlyOCIg+iXysudiA2OPWtecZMyPuf2JoRWHTet8EsfV3DmA/9Qm/KETxoSqvkUqRWiDg4KC/6z8eblnIPjqyeYlTJ8jlonXCDSllG1YA6qgCm3fblT+kWtxId/SNEQqqVAsFLzy9dSZs/pF5gkULSzZmj/Nh529S3SOJvVVI0awwXFyMnlMW0k47WjjLY7pTOOC2638G66M5o4aGN5zh5LfdoSulAnlIVTheUNKF594qU2Dy7hSYght2cFQMcxFLPw1ULsLAJu0sqGDhBcIbkN3HzjjwFGdQtoaS03LeHEk5iXFsaDjdmA7PJP5ANFGxn5jA== X-YMail-OSG: hboJcX4VM1kwJaw7tKnhLBxnra25zOfDz9zBIS8sMT1lkUgO4VgyeJoZZITEppI YhcaU2.wpLKQadlHvXc3k2FhoGzolPRVVeErxIn7vhvdGxJBsvWQXN72OkFFPqYX42zzcWTYb8Uf C66qq9aDHgJGZf6zXCjo8MeKyrUwSIhSRikchE_UK.gYDT2jJx5pU9ZydoMVBmyq9Zb4EtXfhqGU ggqC8f88xwCBDDFCmynaA2g6zcSWa4lXPakujjAV4E3420nkKgY2fmVNaXW8EP0jEWswXeV_N0Sy 1i11o8ufHnw5h7t8bQeqK0lQjLME7uhs4msZ3ruuTWAMHXd4BRcvIwoldmanjA0TDJAl4SWT_QZR Qb4inj_8z4ip7rrBDbwq9gYiykw4iO19KTPwxhnSN94_dtU1eAfdOXQEqNtPPKrS3vXXNhBfgfun 2ViuOq5ol0OB7C9HDjsMPhpiFlS7HivziqvVf9yOw.ckdH6NSlKQHPaI6jBeMmxmRerE8_aJiooI 5QW19cPvMIyAxZsFeqBaFs3uw6cHjn24nfraWkdwuES3nEcQaltJmkZcUdEecnA29lZPozMU9utR VcmbEwEcUXaOlb9ePeUlL0RmyUZdu9yx9X9BKhly97nAlxLnQ0JXvQOKyZY9b3G1MIoCeucNK2.o FTEtExXeZBdTqSqqOvycrNziL.gp8p7uLk2dv32Cz9IuulJjMjO6mYqpYXziMWNjES5pCySZf28B ysdHZovYsuaEtKy0N7a6NQGksjiVL0y8o_IUvoepxegWPT66e5lcrbcUG6rKXdaR9Bx1zL1IJ14h aj_3X0rimgqCMHTdktX7hDuIBjHWBA6gJaxvSxQiD1SdQTDDiYLN1sphOwR3wyHdzT.za1O6GaEY HSzwQm4sTA7lxReulGyJf3kV3R0GP6v3KMdKihfBlOaLoP6iZh3me2QtJoRFitHDhQlEF6pgEjKN HlKGYVPuXDIDHPRtku5n6x3JrS_PqXYta1KdUad2ZDQkDwd5ij1M7kQK6QFA30aNu78zGf_o9qc1 8yFzuS64.xh_tPo..VKW2JP.gs7JiBuzisug4WW2pS6sC8cn_bR_RCelzbz6tXD4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Mon, 26 Nov 2018 04:36:12 +0000 Date: Mon, 26 Nov 2018 04:36:10 +0000 (UTC) From: Nalini J Elkins Reply-To: Nalini J Elkins To: Darin Pettis , "hrpc@irtf.org" Message-ID: <286628983.2495317.1543206970931@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2495316_1751156851.1543206970929" X-Mailer: WebService/1.1.12729 YahooMailNeo Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Archived-At: Subject: Re: [hrpc] Clarification X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 04:36:16 -0000 ------=_Part_2495316_1751156851.1543206970929 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >1.=C2=A0 No one =E2=80=9Cdirected=E2=80=9D anyone to go to ETSI. I wanted to apologize to the community for any implication that may have be= en taken from what I wrote that IETF leadership "directed" people to go to = another standards group. I misunderstood what was said to me.=C2=A0 =C2=A0So, I wanted to clear that= up. =C2=A0Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Darin Pettis To: "hrpc@irtf.org" =20 Sent: Sunday, November 25, 2018 7:23 PM Subject: [hrpc] Clarification =20 Hello,It was mentioned that there was a question around why some folks work= ed with ETSI to maintain internal visibility with TLS 1.3 traffic so wanted= to clear that up. 1.=C2=A0 No one =E2=80=9Cdirected=E2=80=9D anyone to go to ETSI. =C2=A0 2.=C2=A0 ETSI found draft green on their own and initiated their own effort= to standardize it. Didn=E2=80=99t mean to interupt to rehash TLS but wanted to clear up any co= nfusion. Cheers,Darin_______________________________________________ hrpc mailing list hrpc@irtf.org https://www.irtf.org/mailman/listinfo/hrpc =20 ------=_Part_2495316_1751156851.1543206970929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= span style=3D"font-family: "Helvetica Neue", "Segoe UI"= , Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;= " id=3D"yui_3_16_0_ym19_1_1543195860886_16604">>1.  No one =E2=80= =9Cdirected=E2=80=9D anyone to go to ETSI.

=
I wanted to apologize to the = community for any implication that may have been taken from what I wrote th= at IETF leadership "directed" people to go to another standards group.

I misunderstood what was said to me.   So, I wanted t= o clear that up.
 
Thanks,

Nalini Elkins
CEO and FounderInside Products, Inc.
www.insidethestack.com
(831) 659-8360

From: Dar= in Pettis <dpp.standards@gmail.com>
To: "hrpc@irtf.org" <hrpc@irtf.org>
Sent: Sunday, November 25, 2018 7:= 23 PM
Subject: [hrpc] = Clarification

Hello,
It was mentioned that there was a question around= why some folks worked with ETSI to maintain internal visibility with TLS 1= .3 traffic so wanted to clear that up.

1.  No one =E2=80=9Cdirected=E2=80=9D anyone to go to ETSI.  =

2.  ETSI found draft green = on their own and initiated their own effort to standardize it.
Didn=E2=80=99t mean to interupt to rehash TLS but wanted to cl= ear up any confusion.

Cheers,
Darin
_______________________________________________
hr= pc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc=


------=_Part_2495316_1751156851.1543206970929-- From nobody Mon Nov 26 01:16:12 2018 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 81B21130DE5 for ; Mon, 26 Nov 2018 01:16:11 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 Szxj8QtI8nlZ for ; Mon, 26 Nov 2018 01:16:08 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 AD790127598 for ; Mon, 26 Nov 2018 01:16:07 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gRCzs-0007y3-5w; Mon, 26 Nov 2018 10:16:05 +0100 To: hrpc@irtf.org References: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> <2174e149-5a3e-2025-7431-bb943382a583@doria.org> <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> Cc: Avri Doria From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= xsFNBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABzShOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+wsGZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI87BTQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAcLBZQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <1083c0e4-ee15-5c9b-68eb-7260380e0952@nielstenoever.net> Date: Mon, 26 Nov 2018 10:16:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 3c11394861542ed80f8a69179537bf2c Archived-At: Subject: Re: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 09:16:11 -0000 Hi Avri, On 11/20/18 8:36 AM, Niels ten Oever wrote: > On 11/20/18 7:14 AM, avri@doria.org wrote: >> Hi, >> >> A quick reply.  >> >> I do not see this draft as having reached consensus in the group and >> last call is at at the discretion of the co-chairs when they both think >> the draft is ready and they have the consensus of the group for moving >> toward publication.  I have not done a consensus call because I do not >> see consensus as having been reached.  If there is rough consensus in >> the group that this is a draft is ready for publication then we can move >> forward.  I do not think we are at that point. >> >> Personally, I see the draft as more an analysis and polemic than a >> research draft at this point. It starts out well with theoretic >> discussion, a hypothetical position and some outlining of cases, but >> does not establish a research path and does not suggest any protocol >> considerations, the goal of the RG.  We are a research group and need >> for the documents to relate to a research goal. >> > > Thanks a lot for your feedback. > > As presented during IETF 102 [0] and 103 [1], providing guidelines is a non-objective for this draft. The objective of this draft is the operationalization of the first objective of the charter ('To expose the relation between protocols and human rights, with a focus on the rights to freedom of expression and freedom of assembly'), not to provide guidelines. As discussed the practice of improving the guidelines is pursued in RFC8280, draft-irtf-hrpc-guidelines and through the human rights reviews. So the research goals of this draft is defined by the first objective of the charter. > > I am not sure what you mean with a research path. I don't think you mean research design, since there are clear research questions, a methodology, case studies, a discussions of the case studies, the provision of conclusions, and suggestions for further research. So if you could tell us a bit more about what you mean with 'establishing a research path', we'll get on it right away! > Could you be so kind to indicate what you mean with 'research path' so we can move the document forward? If you have other concrete suggestions we're also happy to work on it, but now we're at a loss at to how to move this document forward. Best, Niels > Best, > > Niels > > > [0] https://datatracker.ietf.org/meeting/102/materials/slides-102-hrpc-slides-association-final-00 slide 4 > > [1] https://datatracker.ietf.org/meeting/103/materials/slides-103-hrpc-draft-irtf-hrpc-association-00 slide 2 > > > >> Becoming an RG draft does not mean the next step is publication.  It >> means that the authors have surrendered their authorship priority and >> change control to the will of the group.  When I see this document get >> to the point where the members of the RG feel it is ready for  last >> call, then, if Mallory and I agree, we can try to aim for last call and >> publication.  In the meantime I would like to see some discussion of how >> to do further research on the subject and would like to seem some work >> on consideration that might be relevant. >> >> As for setting up milestones for the work being done, that is a good >> idea and something that in general we should do.  >> >> Thanks for the question. >> >> avri >> > > > >> On 18-Nov-18 18:18, Gisela Perez de Acha Chavez wrote: >>> >>> Hi everyone. First of all, apologies for my silence. I started my master's in Berkeley and the change implied time investment that I had to handle before coming back to the list. >>> >>> The reason I'm writing this email is because I am trying to get up to speed regarding the status of association draft, that Niels and I coauthored. >>> While reading Mallory's notes, and watching the last IETF session, I want to ask why has the draft been taken back to the list and not moved to last call. I thought there was a clear process regarding this. So if I am wrong, please correct me. >>> >>> It would be hugely appreciated if we would develop milestones from draft-association (and probably other drafts as well), since as an author it has been quite unclear how to make progress. At several meetings it has been said that the discussion would be taken to the list, but that did not really happen. Does this indeed mean we have reached consensus? Please let me know how we can make progress on this and what the milestones are. >>> >>> (Also, sorry for the new thread but I needed to write from this new email account) >>> >>> Happy to be back and discuss these issues further, >>> >>> Cheers >>> >>> Gisela Pérez de Acha >>> UC Berkeley >>> Human Rights Lawyer | Journalist | Writer >>> >>> >>> _______________________________________________ >>> 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 >> > -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Tue Nov 27 04:32:32 2018 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 A5B97127598 for ; Tue, 27 Nov 2018 04:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 RJqpNp8RUopg for ; Tue, 27 Nov 2018 04:32:27 -0800 (PST) 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 0E960130E92 for ; Tue, 27 Nov 2018 04:32:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id 915DA201EF2E for ; Tue, 27 Nov 2018 12:32:23 +0000 (GMT) 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 KgLjQ9c7xXOR for ; Tue, 27 Nov 2018 12:32:19 +0000 (GMT) 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: avri) by mail.gn.apc.org (Postfix) with ESMTPSA id 99E432038E4F for ; Tue, 27 Nov 2018 12:32:18 +0000 (GMT) To: hrpc@irtf.org References: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> <2174e149-5a3e-2025-7431-bb943382a583@doria.org> <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> <1083c0e4-ee15-5c9b-68eb-7260380e0952@nielstenoever.net> From: avri doria Openpgp: preference=signencrypt Autocrypt: addr=avri@apc.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpwF0gBBkB AgAGBQJSV4Z7AAoJEOo+L8tCe36HTvYH/RXrGi8imCvHou7US+pua51wTQrWghz6nEaavtFR +k5wHrf7WdjxEdDaJnb0YZki5IiEyqhHEq9Tb0JMCye4rzgWpvd1Z8JJ2FXmY8EjuRZg1sP3 3bvxm1hM7qsPCTWXzn1eHY3i5zAdtEEk0h+isLmEuuFWhGNwzyb0BC/h84YHylqv7/bMrHUz CtkUKdO2Vx0W8e/EWUDfLJnHtvTFTT1E/koOnWErJfmKhq2G6rMv13XsU7vr9AWZ6vDA3z2o sCHWkA2gkhU7TwHqPkY9HPoekUXlR/n11jBS9Jwx4Dnsyd7pqaRHxoyRqfEWTi8JF+N+XzC3 buf3G3buW3BDmNcJENWp6aLJ/w+n+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2E= Message-ID: Date: Tue, 27 Nov 2018 07:32:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <1083c0e4-ee15-5c9b-68eb-7260380e0952@nielstenoever.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Antivirus: Avast (VPS 181127-0, 11/27/2018), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 12:32:31 -0000 Niels, Thank you for your original note.=C2=A0 And thank you for the resend, whi= ch I guess was due to my not have responded with sufficient alacrity.=C2=A0 Bu= t it was a week leading up to a holiday weekend for many (including me)=C2=A0 = and I wanted to see which, if any, members of the RG disagreed with my claim that we are not seeing support for immediate LC or even that it should be on the RFC path as it is currently constructed. In terms of not including considerations in the Association draft, or at at least analysis of considerations: this is a consensus I do not remember the RG reaching on this RG draft. I understand the editors may not think it necessary, but does the RG agree?=C2=A0 I do not think this issue has been adequately discussed or decided on.=C2=A0 What do others t= hink? Personally, I see it as incomplete without at least an analysis of how the existing considerations affect and are affected by including association in the consideration complex. Are we considering new considerations for every=C2=A0 right (hope not) or are we looking for how= other considerations affect the considerations we are already experimenting with so that we can build a well formed and tested set of human rights considerations. With RFC8280 we established an experimental framework.=C2=A0 We formed a hypothesis based on text analysis and deductive reasoning. In creating the considerations we created a research framework that could be used to test whether the principles that drove those considerations are the right considerations, and would make a human rights difference on th Internet of not. And would it be a positive difference?=C2=A0 I believe w= e still have a ways to go in proving, or at least failing to falsify as the case may be, our hypotheses and our framework. I believe the group has basically accepted the common human rights principle that the various human rights are inextricably interlinked. If that is the case, then any right we begin to work on has to fit within, and modify as necessary, the original framework of RFC8280. I think the Association draft has yet to do this and should.=C2=A0 What do other peop= le think? Or does Association-00 intend to propose abandoning the framework established with RFC8280? I suppose that too could be a reasoned way to proceed, but I do not see that argument in the current draft either. On the cases and examples, I have not seen a RG agreement on the validity of the cases and their description or analysis. I think they may be a good place to start.=C2=A0 In terms of the conclusion, the doc i= s claiming a RG consensus on conclusions I am not sure I have seen.=C2=A0 H= ave I missed consensus on the cases, their analysis and the conclusions we draw from them. Seen some conversation but not enough to convince me that the RG agrees with the narrative. I see LC as time to confirm a consensus seen and give everyone a last chance, not a mechanism for drawing out issues.=C2=A0 We can do consensus calls on various points of disagreement to try and draw out the issues, and perhaps we should as we move forward on these RG drafts. As a co-chair, I think what we have in association-00 is a partial introduction to work we need to do. I think the group=C2=A0 needs to do t= he research, think about how it affects the considerations framework and reach consensus of the various cases and analyses before we can consider publishing this as a RG work effort.=C2=A0 I think we need to do the work= beyond the scholastic hypothesis formation.=C2=A0 This might be a good treatment for a conference paper or a journal article, though, and that might be a useful side track to take if something must be published based on external publication pressure. Thank you avri On 26-Nov-18 04:16, Niels ten Oever wrote: > Hi Avri, > > On 11/20/18 8:36 AM, Niels ten Oever wrote: >> On 11/20/18 7:14 AM, avri@doria.org wrote: >>> Hi, >>> >>> A quick reply.=C2=A0 >>> >>> I do not see this draft as having reached consensus in the group and >>> last call is at at the discretion of the co-chairs when they both thi= nk >>> the draft is ready and they have the consensus of the group for movin= g >>> toward publication.=C2=A0 I have not done a consensus call because I = do not >>> see consensus as having been reached.=C2=A0 If there is rough consens= us in >>> the group that this is a draft is ready for publication then we can m= ove >>> forward.=C2=A0 I do not think we are at that point. >>> >>> Personally, I see the draft as more an analysis and polemic than a >>> research draft at this point. It starts out well with theoretic >>> discussion, a hypothetical position and some outlining of cases, but >>> does not establish a research path and does not suggest any protocol >>> considerations, the goal of the RG.=C2=A0 We are a research group and= need >>> for the documents to relate to a research goal. >>> >> Thanks a lot for your feedback. >> >> As presented during IETF 102 [0] and 103 [1], providing guidelines is = a non-objective for this draft. The objective of this draft is the operat= ionalization of the first objective of the charter ('To expose the relati= on between protocols and human rights, with a focus on the rights to free= dom of expression and freedom of assembly'), not to provide guidelines. A= s discussed the practice of improving the guidelines is pursued in RFC828= 0, draft-irtf-hrpc-guidelines and through the human rights reviews. So th= e research goals of this draft is defined by the first objective of the c= harter. >> >> I am not sure what you mean with a research path. I don't think you me= an research design, since there are clear research questions, a methodolo= gy, case studies, a discussions of the case studies, the provision of con= clusions, and suggestions for further research. So if you could tell us a= bit more about what you mean with 'establishing a research path', we'll = get on it right away! >> > Could you be so kind to indicate what you mean with 'research path' so = we can move the document forward? If you have other concrete suggestions = we're also happy to work on it, but now we're at a loss at to how to move= this document forward. > > Best, > > Niels > > > >> Best, >> >> Niels >> >> >> [0] https://datatracker.ietf.org/meeting/102/materials/slides-102-hrpc= -slides-association-final-00 slide 4 >> >> [1] https://datatracker.ietf.org/meeting/103/materials/slides-103-hrpc= -draft-irtf-hrpc-association-00 slide 2 >> >> >> >>> Becoming an RG draft does not mean the next step is publication.=C2=A0= It >>> means that the authors have surrendered their authorship priority and= >>> change control to the will of the group.=C2=A0 When I see this docume= nt get >>> to the point where the members of the RG feel it is ready for=C2=A0 l= ast >>> call, then, if Mallory and I agree, we can try to aim for last call a= nd >>> publication.=C2=A0 In the meantime I would like to see some discussio= n of how >>> to do further research on the subject and would like to seem some wor= k >>> on consideration that might be relevant. >>> >>> As for setting up milestones for the work being done, that is a good >>> idea and something that in general we should do.=C2=A0 >>> >>> Thanks for the question. >>> >>> avri >>> >> >> >>> On 18-Nov-18 18:18, Gisela Perez de Acha Chavez wrote: >>>> Hi everyone. First of all, apologies for my silence. I started my ma= ster's in Berkeley and the change implied time investment that I had to h= andle before coming back to the list.=20 >>>> >>>> The reason I'm writing this email is because I am trying to get up t= o speed regarding the status of association draft, that Niels and I coaut= hored.=20 >>>> While reading Mallory's notes, and watching the last IETF session, I= want to ask why has the draft been taken back to the list and not moved = to last call. I thought there was a clear process regarding this. So if I= am wrong, please correct me.=20 >>>> >>>> It would be hugely appreciated if we would develop milestones from d= raft-association (and probably other drafts as well), since as an author = it has been quite unclear how to make progress. At several meetings it ha= s been said that the discussion would be taken to the list, but that did = not really happen. Does this indeed mean we have reached consensus? Pleas= e let me know how we can make progress on this and what the milestones ar= e. >>>> >>>> (Also, sorry for the new thread but I needed to write from this new = email account) >>>> >>>> Happy to be back and discuss these issues further,=20 >>>> >>>> Cheers >>>> >>>> Gisela P=C3=A9rez de Acha >>>> UC Berkeley=20 >>>> Human Rights Lawyer | Journalist | Writer=20 >>>> >>>> >>>> _______________________________________________ >>>> 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 Tue Nov 27 10:48:10 2018 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 5B402127133 for ; Tue, 27 Nov 2018 10:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajc4-JrMivUe for ; Tue, 27 Nov 2018 10:48:01 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (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 40BA312D4E9 for ; Tue, 27 Nov 2018 10:48:01 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1gRiOt-0001vI-B8 for hrpc@irtf.org; Tue, 27 Nov 2018 19:47:59 +0100 To: hrpc@irtf.org References: <2D3A1DFB-1DA4-47BF-8F3D-056C52960DF2@berkeley.edu> <2174e149-5a3e-2025-7431-bb943382a583@doria.org> <7d553db6-7d4e-4b02-1c44-9aae51393c2f@nielstenoever.net> <1083c0e4-ee15-5c9b-68eb-7260380e0952@nielstenoever.net> From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= xsBNBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAHNJU1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QG1heWZpcnN0Lm9yZz7CwJgEEwECAEICGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo 9WUFCRAV234ACgkQDDKicb08x4DklAf+ODKRmP6C2MnBz6vL8N8l3vZJUqoRcYXTn3uTpT05 Wou87ZIZ/P/OV2/uOMKkczLQQydj5S8PxbLTeg+U5f/63hdy99ON+K2b4izg7Qasdl1SqXTH q1pmhbrcbLbVKDJ345fdEg7RuMnv4gd3EaT/yQa99zHy8JHaBKaPEUQAa65HTt2Sy2c6L6BA aMZx1TOZ9/cZ7L1gJyytJbEyvg/JLOatJEI4rewUWU2TMSGJijwjAUBagwDPWyxpz+vXdKsD tqRTpY4xvXaeUQo0QXf0c5j1Gcglzv7ywZcyz1MGD1aLS9/CqeB3I4EMbvH/33LS3jNkfKbV XOTSjmo7l22CNc7ATQRMdE1nAQgA4mpP2LjFuAW2li9FPbDYOMzt0MtThXsnvHyY0fDv8FlU qnKgPrMY80VHntnxwqepFS3ncunVX4ipq+fadta+LHpTnbJSmlphBrc9qGJxqcjwf4yo35Xh OXCJFwnaoAwIX237lXRe4Xh6X4VMuJt8jiZdvgpbk/whvQH2grcq8KjCcy1iuL5pBl8ZwYG/ dphitFhQdqEcnc/krIqG4KQgKiUi3K/GR0OeEmw/cscWD7/CLEo7eHiaGQhSOyDQbM+Iu2o/ 6uMXMUPsYlMMqgmVL68zMacO3PE17jx0rQ8oZ7CpBY8YZWOWrzXrtFT8JO9guuCPsvd4KT6y 97y9LRJlPQARAQABwsB8BBgBAgAmAhsMFiEE4+tj4GWjskC82bBxDDKicb08x4AFAlqo9WYF CRAV238ACgkQDDKicb08x4DU4QgAmlyBlFhfU0jpkbyD3HQ+3CJqWdBT422pVIrj3qNT2ehy fWO66Muidmd4Y279uV3p3TQEJOQvnV7FVAC9+bI7AdBy00BAjHgJ5eSQZxKTXUoeeBAsTZHN /HaHewjYWHMvCuuzir/Wt3A6Cehh8gp9I/Vg+oL3dTldVqqgZLgnA83bT/R8fI/e85LDlpdx KJ0+uy/grg3AbH7LUUrmMIC2iO8mQWYuNlizsUZLFvJhCAU2c5l8B5mv2BoWFhL+l7mmNcdF bwBFXon7Ea1jkCnbWVxtXkPYkcuWuMSTJswn9HhZVJWjUonKqUZKAb9PxRzC9crZ+X14tQT3 iJt2a4ZM4w== Message-ID: Date: Tue, 27 Nov 2018 19:47:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 5c4dd3f97b5f9360f98ddb363e9ef1fb Archived-At: Subject: Re: [hrpc] Question About Process - Hi Again X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 18:48:05 -0000 Hi, On 27/11/2018 13:32, avri doria wrote: >=20 > In terms of not including considerations in the Association draft, or a= t > at least analysis of considerations: this is a consensus I do not > remember the RG reaching on this RG draft. I understand the editors may > not think it necessary, but does the RG agree?=C2=A0 I do not think thi= s > issue has been adequately discussed or decided on.=C2=A0 What do others= think? >=20 > Personally, I see it as incomplete without at least an analysis of how > the existing considerations affect and are affected by including > association in the consideration complex. Are we considering new > considerations for every=C2=A0 right (hope not) or are we looking for h= ow > other considerations affect the considerations we are already > experimenting with so that we can build a well formed and tested set of > human rights considerations. I think we don't want new considerations, but it would make sense to perhaps deepen, or address, the existing considerations on association, otherwise there is not much connection between them. One suggestion is to perhaps bring forward the relevant 8280 sections by expanding a paragraph starting with this sentence: "[RFC8280] established the relationship between human rights and Internet protocols, therefore in this document we seek to uncover the relation between two specific human rights and the Internet infrastructure and architecture." > With RFC8280 we established an experimental framework.=C2=A0 We formed = a > hypothesis based on text analysis and deductive reasoning. In creating > the considerations we created a research framework that could be used t= o > test whether the principles that drove those considerations are the > right considerations, and would make a human rights difference on th > Internet of not. And would it be a positive difference?=C2=A0 I believe= we > still have a ways to go in proving, or at least failing to falsify as > the case may be, our hypotheses and our framework. >=20 > I believe the group has basically accepted the common human rights > principle that the various human rights are inextricably interlinked. I= f > that is the case, then any right we begin to work on has to fit within, > and modify as necessary, the original framework of RFC8280. I think the > Association draft has yet to do this and should.=C2=A0 What do other pe= ople > think? Taking this further, I think it wouldn't be much work to achieve what Avri is suggesting. For each of your cases in subsections 6.* you could add a conclusion that offers suggestions for how protocols should protect association and assembly. > Or does Association-00 intend to propose abandoning the framework > established with RFC8280? I suppose that too could be a reasoned way to > proceed, but I do not see that argument in the current draft either. >=20 > On the cases and examples, I have not seen a RG agreement on the > validity of the cases and their description or analysis. I think they > may be a good place to start.=C2=A0 In terms of the conclusion, the doc= is > claiming a RG consensus on conclusions I am not sure I have seen.=C2=A0= Have > I missed consensus on the cases, their analysis and the conclusions we > draw from them. Seen some conversation but not enough to convince me > that the RG agrees with the narrative. I see LC as time to confirm a > consensus seen and give everyone a last chance, not a mechanism for > drawing out issues.=C2=A0 We can do consensus calls on various points o= f > disagreement to try and draw out the issues, and perhaps we should as w= e > move forward on these RG drafts. It might be worth reaching out to experts within working groups that are related to each case in sections 6.* for their feedback, if you haven't done so already. > As a co-chair, I think what we have in association-00 is a partial > introduction to work we need to do. I think the group=C2=A0 needs to do= the > research, think about how it affects the considerations framework and > reach consensus of the various cases and analyses before we can conside= r > publishing this as a RG work effort.=C2=A0 I think we need to do the wo= rk > beyond the scholastic hypothesis formation.=C2=A0 This might be a good > treatment for a conference paper or a journal article, though, and that > might be a useful side track to take if something must be published > based on external publication pressure. I would argue for making this draft good for this group first and then to spin off other sections or versions that might be received well in other journals. I say that mostly because association and assembly are core to our charter and we should get it right. -Mallory >=20 > On 26-Nov-18 04:16, Niels ten Oever wrote: >> Hi Avri, >> >> On 11/20/18 8:36 AM, Niels ten Oever wrote: >>> On 11/20/18 7:14 AM, avri@doria.org wrote: >>>> Hi, >>>> >>>> A quick reply.=C2=A0 >>>> >>>> I do not see this draft as having reached consensus in the group and >>>> last call is at at the discretion of the co-chairs when they both th= ink >>>> the draft is ready and they have the consensus of the group for movi= ng >>>> toward publication.=C2=A0 I have not done a consensus call because I= do not >>>> see consensus as having been reached.=C2=A0 If there is rough consen= sus in >>>> the group that this is a draft is ready for publication then we can = move >>>> forward.=C2=A0 I do not think we are at that point. >>>> >>>> Personally, I see the draft as more an analysis and polemic than a >>>> research draft at this point. It starts out well with theoretic >>>> discussion, a hypothetical position and some outlining of cases, but >>>> does not establish a research path and does not suggest any protocol >>>> considerations, the goal of the RG.=C2=A0 We are a research group an= d need >>>> for the documents to relate to a research goal. >>>> >>> Thanks a lot for your feedback. >>> >>> As presented during IETF 102 [0] and 103 [1], providing guidelines is= a non-objective for this draft. The objective of this draft is the opera= tionalization of the first objective of the charter ('To expose the relat= ion between protocols and human rights, with a focus on the rights to fre= edom of expression and freedom of assembly'), not to provide guidelines. = As discussed the practice of improving the guidelines is pursued in RFC82= 80, draft-irtf-hrpc-guidelines and through the human rights reviews. So t= he research goals of this draft is defined by the first objective of the = charter. >>> >>> I am not sure what you mean with a research path. I don't think you m= ean research design, since there are clear research questions, a methodol= ogy, case studies, a discussions of the case studies, the provision of co= nclusions, and suggestions for further research. So if you could tell us = a bit more about what you mean with 'establishing a research path', we'll= get on it right away! >>> >> Could you be so kind to indicate what you mean with 'research path' so= we can move the document forward? If you have other concrete suggestions= we're also happy to work on it, but now we're at a loss at to how to mov= e this document forward. >> >> Best, >> >> Niels >> >> >> >>> Best, >>> >>> Niels >>> >>> >>> [0] https://datatracker.ietf.org/meeting/102/materials/slides-102-hrp= c-slides-association-final-00 slide 4 >>> >>> [1] https://datatracker.ietf.org/meeting/103/materials/slides-103-hrp= c-draft-irtf-hrpc-association-00 slide 2 >>> >>> >>> >>>> Becoming an RG draft does not mean the next step is publication.=C2=A0= It >>>> means that the authors have surrendered their authorship priority an= d >>>> change control to the will of the group.=C2=A0 When I see this docum= ent get >>>> to the point where the members of the RG feel it is ready for=C2=A0 = last >>>> call, then, if Mallory and I agree, we can try to aim for last call = and >>>> publication.=C2=A0 In the meantime I would like to see some discussi= on of how >>>> to do further research on the subject and would like to seem some wo= rk >>>> on consideration that might be relevant. >>>> >>>> As for setting up milestones for the work being done, that is a good >>>> idea and something that in general we should do.=C2=A0 >>>> >>>> Thanks for the question. >>>> >>>> avri >>>> >>> >>> >>>> On 18-Nov-18 18:18, Gisela Perez de Acha Chavez wrote: >>>>> Hi everyone. First of all, apologies for my silence. I started my m= aster's in Berkeley and the change implied time investment that I had to = handle before coming back to the list.=20 >>>>> >>>>> The reason I'm writing this email is because I am trying to get up = to speed regarding the status of association draft, that Niels and I coau= thored.=20 >>>>> While reading Mallory's notes, and watching the last IETF session, = I want to ask why has the draft been taken back to the list and not moved= to last call. I thought there was a clear process regarding this. So if = I am wrong, please correct me.=20 >>>>> >>>>> It would be hugely appreciated if we would develop milestones from = draft-association (and probably other drafts as well), since as an author= it has been quite unclear how to make progress. At several meetings it h= as been said that the discussion would be taken to the list, but that did= not really happen. Does this indeed mean we have reached consensus? Plea= se let me know how we can make progress on this and what the milestones a= re. >>>>> >>>>> (Also, sorry for the new thread but I needed to write from this new= email account) >>>>> >>>>> Happy to be back and discuss these issues further,=20 >>>>> >>>>> Cheers >>>>> >>>>> Gisela P=C3=A9rez de Acha >>>>> UC Berkeley=20 >>>>> Human Rights Lawyer | Journalist | Writer=20 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc >=20 --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780